Re: Performance Issues - PTR Records

2011-11-03 Thread Larry Blunk

On 11/02/2011 05:57 PM, Matt Chung wrote:

I work for a regional ISP and very recently there has been an influx of
calls reporting "slowness" when accessing certain websites (i.e
google.com/voice/b) via HTTP.  After performing a tcpdump and analyzing the
session, I have been able to pinpoint the latency at the application
layer.  After the tcp session has been established, it takes up to 15-20
seconds before the application begins sending data.   The root of the
problem was that the PTR record for our customer(s) address does not
exist.  As soon as the record is created, latency from the application is
eliminated.  This is analogous to latency when accessing a server over SSH
when no PTR is available.

A seperate packet capture from another customer exhibiting similar
performance behavior showed many TCP retransmissions.  At first glance, I
assumed this was network related however this correlates with the
application not responding and inducing retransmissions at the TCP layer
(different symptoms, same problem).

Historically, there was no compelling reason to create PTR records for our
CPE however more and more applications seem to be dependent on it.
Although we will be assigning a record for each address, my question is why
is the application (specifically HTTP) dependent on a reverse record ?
What is the purpose?

Hope this is helpful as well



  We recently encountered a similar issue with a customer.
The sites that had slowness issues were configured to
use the traditional Google Analytics javascript instead
of the newer asynchronous code.
  The problem was not the lack of a PTR record, but rather
the in-addr delegation was pointing to lame servers that were
no longer responding (hence the long timeouts as the
Google servers attempted to perform reverse lookups
on the client IP's).  As others have pointed out, as long
as there's a valid nameserver responding, a lack of PTR
record would not cause issues as an NXDOMAIN record would
be sent back immediately and the Google Analytics server
will move on.


 -Larry Blunk
  Merit





Re: whois.radb.net returning blank results

2013-03-04 Thread Larry Blunk


  Apologies, issues seem to have been caused by a slowish
memory leak in IRRd and the process had begun to swap
heavily when a regular maintenance thread ran.

 Regards,
   Larry


On 03/04/2013 12:40 PM, Christopher Morrow wrote:

On Mon, Mar 4, 2013 at 11:55 AM, Job Snijders  wrote:

Hi,

NRTM  still works according to my mirrors. So for up 2 date data, you could use 
irr.ring.nlnog.net:

Alice:~ job$ whois -h irr.ring.nlnog.net 198.41.0.0 | wc -l
  437
Alice:~ job$


also, radb seems to have come back from the dead:
$ whois -h 198.108.0.18 216.239.32.0 | wc -l
7

huzzah!


Kind regards,

Job


On Mar 4, 2013, at 5:36 PM, Christopher Morrow  wrote:


On Mon, Mar 4, 2013 at 11:24 AM, Nick Hilliard  wrote:

whois -h whois.radb.net 198.41.0.0



fgets: Connection reset by peer


:( larry blunk has helped in the past to fix this...









Re: Windows UDP packet generator software?

2011-12-22 Thread Larry Blunk

On 12/22/2011 02:36 PM, Sean Harlow wrote:

iperf might be able to do what you need and there are Windows builds available, 
but I'm not sure if it has a mode where it's not flooding the network trying to 
test maximum speed.  Is there a reason that standard ICMP pings aren't 
appropriate if you just want packet loss info?  Obviously every platform worth 
using has ping built in.
--
Sean Harlow
s...@seanharlow.info



 In UDP mode, iperf sends at 1 Mbps by default.  You change
the rate with the -b flag.   There's an iperf-2.0.5-cygwin
build floating around for Windows.




NANOG list attack

2015-10-26 Thread Larry Blunk

 All,
   Just wanted to apologize for the attack over the weekend.  The
posts came from a email address that was subscribed to the list, so
it was not subjected to moderation.  While a filter was added
to block further posts (which were made in a short time window),
there were existing message queues that were not cleared in a
timely basis.

  As Job Snijders (a fellow Communications Committee member) noted
in an earlier post, we will be implementing some additional protection
mechanisms to prevent this style of incident from happening again. We
will be more aggressively moderating posts from addresses who have
not posted recently, in addition to other filtering mechanisms.

 Regards,
   Larry Blunk
   NANOG Communications Committee
   adm...@nanog.org


Re: ATT BGP - Advertising my network on accident

2010-06-25 Thread Larry Blunk


  Looks like the prefix in question is 208.91.48.0/22
and it was briefly announced by 7018 yesterday, but
that announcement seems to be gone now.   I see 11734
is announcing 208.91.48.0/22 + 208.91.48.0/24 now,
but not 208.91.49.0/24 - 208.91.51.0/24.




On 06/25/2010 10:17 AM, Christopher Morrow wrote:

On Fri, Jun 25, 2010 at 10:12 AM, Dennis Burgess
  wrote:
   

Have you found a contact at ATT to get this stopped?
 

I'm fairly certain JayB at least reads nanog... the OP didn't mention
if this was 7018, 7132 or the ATT_ENS AS with the route though :(

   

-Original Message-
From: Eric Williams [mailto:ewilli...@connectria.com]
Sent: Friday, June 25, 2010 8:56 AM
To: nanog@nanog.org
Subject: Re: ATT BGP - Advertising my network on accident

This issue has been resolved by breaking up the /22 into /24's.  Thanks
to all for the advise.

Maybe next time I will take someone's advise and advertise one of ATT's
/8's.





From:
Eric Williams/Connectria
To:
nanog@nanog.org
Date:
06/24/2010 02:37 PM
Subject:
ATT BGP - Advertising my network on accident


AT&T is currently advertising my address space to the internet
accidentally via BGP which they should not be.  Since they are
advertising
my address space on accident, we are dead in the water.  Does anybody
out
there work for ATT or know of the number I can call in order to have
them
stop advertising my /22 ASAP



 
   





Re: ????[00275] ?????????????

2009-04-28 Thread Larry Blunk



   Unfortunately,  the require_explicit_destination option
was not set in the MailMan config for the NANOG list.
This has been corrected. 



 Regards,
  Larry Blunk
  Merit




Marc-Antoine.Chabot wrote:

Interesting.. It's bouncing from a yahoo.co.jp group to the Nanog list.

Anyone know a live contact for abuse at [NANOG]?
*grin*

-Original Message-
From: Colin Alston [mailto:karna...@karnaugh.za.net] 
Sent: Tuesday, April 28, 2009 9:11 AM

To: NANOG list
Subject: Re: [00275] ?

On 2009/04/28 02:58 PM Steven Walker wrote:
  

Sorry about that NANOG.  I though it was more junk from the HK spammers.



Don't NANOG people have far better ways to deal with spammers than 
yelling at them?



  





Re: IPv6 Addressing Help

2009-08-14 Thread Larry Blunk

Randy Bush wrote:

/126 - Router p2p



/127, see

MATSUZAKI Yoshinobu gave a talk describing the ping pong attack on /127
at a ripe or apricot or both.  both web sites are absolutely horrid at
letting one find talks (see nanog for an example of good).

randy

  


 Here's a link to the talk --

http://archive.apnic.net/meetings/26/program/apops/matsuzaki-ipv6-p2p.pdf


-Larry




Re: RADB service outage

2008-12-02 Thread Larry Blunk



Apologies for the RADB downtime. Service was down
from roughly 7:45PM - 8:51PM EST last night. We've been
having some issues due to heavy querying from
a PlanetLab project and are currently working
with them to resolve the issue.


-Larry Blunk
Merit Network


Shin Yamasaki wrote:
> Hi,
>
> It seems Merit's RADB service is not working.
>
> Both Web and command-line accesses aren't available.  On the Web, it
> only returns the following string: "Number of objects found: 1"  On the
> command-line, nothing is returned.
>
> Not only us but also other folks here in Japan are affected.
>
> If someone from Merit sees this, please take a look at the system and
> take appropriate action.
>
> Thank you in advance,
>
>   




Re: prefix hijack by ASN 8997

2008-09-23 Thread Larry Blunk

Scott Weeks wrote:

-- [EMAIL PROTECTED] wrote: --
From: Marshall Eubanks <[EMAIL PROTECTED]>

So, do you think this was lots of little tests / hijacks / mistakes ?  
Or did it just not propagate very far ?

-

According to Andree Toonk (and someone confirmed privately) ASN 8997 leaked a 
full table to ASN 3267 (who didn't filter!).  The only upstream of ASN 3267 I 
saw in bgplay was ASN 174 (Cogent) who seems to have filtered, but I can't 
confirm.  So I guess that the impact would've only been to the peers downstream 
of ASN 3267.

scott





-
Andree Toonk <[EMAIL PROTECTED]>

Not a false positive, It actually was detected by the RIS box in Moscow 
(rrc13). Strange that it's not visible in RIS search website, but it's 
definitely in the raw data files.
Looking at that raw data from both routeviews and Ripe, it looks like 
they (AS8997) 'leaked' a  full table,  i.e. :

--

  


  I did some analysis of updates on routeviews.
The only routeviews peer I saw leaking  the routes
was AS3277 (out of 42 peers).   There were roughly
117,000 prefixes with origin AS8997 with the path
going through AS3267 to AS3277.   The initial
announcements were seen at 09:29:32 UTC and
updates with the correct path were seen starting
at about 09:36:42 UTC (last ones seen at 09:43:42).

-Larry






Re: Who has AS 1712?

2009-11-23 Thread Larry Blunk

Bill Woodcock wrote:

  On Mon, 23 Nov 2009, Stephane Bortzmeyer wrote:
> % whois -h whois.ripe.net AS1712
> as-name:FR-RENATER-ENST
> 
> % whois -h whois.arin.net AS1712 
> OrgName:Twilight Communications 


That would be ARIN, rather than RIPE:

http://www.iana.org/assignments/as-numbers/as-numbers.xml
"1708-1728   Assigned by ARIN   whois.arin.net"

> And, yes, AS 1712 is actually used by both and announced :-(

Ouch, that's unfortunate.  


-Bill


  


 It's not just AS1712.   AS1707 - AS1726 appear to all
have been allocated to Renater.AS1707 was ERX'd to
RIPE on Sep 9, 2002, but it appears that AS1708-AS1726
were missed and have subsequently been reallocated
by ARIN (between Aug 18 and Aug 21, 2009)

-Larry




Re: Who has AS 1712?

2009-11-24 Thread Larry Blunk

John Curran wrote:

On Nov 23, 2009, at 10:50 AM, Christopher Morrow wrote:

  

In all seriousness though, how does this get fixed?



It's being addressed now, but requires both RIPE and ARIN to work with the respective ASN holders.  Standby for an update once that step has been completed. The more interesting question is how this could happen, and we're busy looking into that at present. 


The AS 1707 assignment goes back to Internic days (i.e. pre-1997) but the remainder of 
the ASN block (AS 1708 to AS 1728) is marked "assigned by ARIN" at the IANA but 
had not actually been assigned until very recently.  (ARIN did a reconciliation in July 
2009 of all ASNs marked as “assigned by ARIN” with our own internal records to find out 
whether any holes existed, and began assigning such ASNs in August 2009, including AS 
numbers in the range 1708 thru 1726).

We're working with RIPE to determine how these numbers were put into usage via 
the RIPE DB, and will come up with appropriate steps to prevent recurrence once 
we fully understand the root cause.

/John

John Curran
President and CEO
ARIN

  


FWIW,
  I searched for any historical registrations from this block
in the RADB and found a number of routes with an origin
of AS1717.   They date from 1995 and were registered for the
Université Pierre et Marie Curie by Renater.  They have long
since been removed from the RADB.
Here's an example --

route: 132.166.0.0/15
descr: RENATER_CIDR
descr: Universite Pierre et Marie Curie
descr: 4 place Jussieu 75252 PARIS CEDEX 05
descr: FRANCE
origin: AS1717
advisory: AS690 1:1800 2:1239(144) 3:1133 4:1674
comm-list: COMM_NSFNET
mnt-by: MAINT-AS1717
changed: ren...@renater.fr 950510
source: RADB


   -Larry Blunk
Merit











Re: 1.0.0.0/8 route from MERIT ?

2010-03-02 Thread Larry Blunk


Christopher Morrow wrote:

On Tue, Mar 2, 2010 at 3:50 AM, Tomoya Yoshida  wrote:
  

Thank you Geoff.

I asked because I could see 1/8 of merit AS237 but couldn't see
of origin AS36561 for those two in database.
Even if it's an experiment and sort term, It's better to be registerd
in right origin I think. # It could be guessed but...



which databases?

morr...@localhost:~$ whois -h rr.arin.net 1.2.3.0
% This is the ARIN Routing Registry.

% Note: this output has been filtered.

% Information related to '1.2.3.0/24AS36561'

route:  1.2.3.0/24
descr:  YouTube, Inc.
descr:  901 Cherry Ave
descr:  San Bruno, CA 94066
descr:  US
origin: AS36561
mnt-by: MNT-YOUTU
source: ARIN # Filtered


morr...@localhost:~$ whois -h rr.arin.net 1.1.1.0
% This is the ARIN Routing Registry.

% Note: this output has been filtered.

% Information related to '1.1.1.0/24AS36561'

route:  1.1.1.0/24
descr:  YouTube, Inc.
descr:  901 Cherry Ave
descr:  San Bruno, CA 94066
descr:  US
origin: AS36561
mnt-by: MNT-YOUTU
source: ARIN # Filtered

These ought to then get around to other IRR-ish-things when their
propogation times hit, yes?

-Chris
  



I'm not positive that this is still the case, but I believe that
there can be quite a bit of latency in mirroring due to the
way RIPE database code (which ARIN uses) works.   The
last object(s) registered are not pushed to the mirror stream until
the next object(s) are registered.I believe RIPE regularly pushes
a dummy object in order to keep it's mirrors more regularly
synced.   I don't think that ARIN does this.   It's a bigger issue
for ARIN as their routing registry is updated less frequently
than the RIPE routing registry.

   According to our logs, the objects were not mirrored on
the RADB server until about 2.5 hours after Tomoya posted
his email (the objects were picked up from the ARIN
mirror at 05:37:42 -0500 (EST)  March 2).



--Larry



  

When RPKI comes, is it no problem??

   -tomoya


On Tue, 2 Mar 2010 19:17:45 +1100
Geoff Huston  wrote:

|Hi,
|
|As I noted in the previous note quoted below, APNIC are undertaking a second 
experiment with these two /24 routes originated by AS 36561. These two /24s 
appear to be the major attractors in the 1.0.0.0/8 space. YouTube have 
generously provided assistance for this second experiment, and we are very 
grateful for their help!
|
|  Geoff Huston
|  APNIC
|
|
|
|
|On 02/03/2010, at 6:59 PM, Tomoya Yoshida wrote:
|
|> Are these from youtube also?
|>
|> 1.1.1.0/24 *[BGP/170] 07:04:22, MED 0, localpref 100
|>  AS path: 2914 3356 36561 I
|> 1.2.3.0/24 *[BGP/170] 07:01:21, MED 0, localpref 100
|>  AS path: 2914 3356 36561 I
|>
|>  tomoya
|>
|>
|> On Thu, 25 Feb 2010 14:34:02 +1100
|> Geoff Huston  wrote:
|>
|> |
|> |On 25/02/2010, at 6:13 AM, Alex H. Ryu wrote:
|> |
|> |>
|> |> Today I jumped into one of our routers, and I found that 1.0.0.0/8 is
|> |> announced from AS237, which is MERIT.
|> |>
|> |>
|> |>NetworkNext HopMetric LocPrf Weight Path
|> |> *>  1.0.0.0/8  4.59.200.5  0  60 0  (65001
|> |> 65105) 3356 7018 237 i
|> |>
|> |> Is this supposed to be?
|> |> I thought 1.0.0.0/8 is allocated to APNIC.
|> |
|> |Yes, this is supposed to be. This is one of a number of planned experiments 
in advertising all and selected parts of 1/8 in the coming weeks.
|> |
|> |Geoff Huston
|> |APNIC
|>
|> --
|> Tomoya Yoshida 
|>

--
Tomoya Yoshida 






  





Re: 10GBase-t switch

2010-03-12 Thread Larry Blunk

Mirko Maffioli wrote:

I'm searching for a switch with at least one 10Gbase-T ethernet port
and some gigabit ethernet for lab test.
>From cisco web site i've seen for example a 3560 model with X2 module
and CX4 port but nothing with 10Gb-T.

Unfortunately my budget couldn't arrive to nexus or cat6500

Do you have some other vendor model i can check?

Bye
Mirko

  


  I noticed that no one has actually quite answered this original question
(on a budget, multiple GigE's, at least one 10GBase-T).There
seem to be at least a couple possible options at this point --

 The Dell PowerConnect 6224 lists a dual port 10GBase-T module option
for $1349.   Also, they seem to be releasing sFlow support shortly --
http://en.community.dell.com/forums/p/19304811/19635923.aspx

 The SMC 8824M has a single port 10GBase-T module
option (SMC10BTMOD) for around $800 with up to 2
modules per switch.  They apparently have a promo where
you can get a 10GBase-T PCI-E card for free if you order
one of these modules (SMC10BTMOD-BUND).

-Larry




Re: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million

2011-03-24 Thread Larry Blunk

On 03/24/2011 10:06 AM, Joe Provo wrote:

On Thu, Mar 24, 2011 at 01:27:29PM +, Tony Finch wrote:

Jay Nakamura  wrote:


666,624 is kind of odd number, isn't it?  That comes out to a
/13,/15,/19,/21 and a /22.

> From the court documents I gather that it is a collection of miscellaneous
blocks that Nortel acquired over the years, presumable via corporate M&A.
However there isn't (as far as I can see) a list of the actual blocks. See
docket 5143 at http://chapter11.epiqsystems.com/NNI/docket/Default.aspx


Exhibit B expressly indicates they were listed but filed under seal;
interesting to request that.  Previous documents indicate they used a
third party to shop things around, who got a $200k retainer and is
getting paid 5% of the sale.



   Docket #4435, Exhibit B has more information on the IP address
broker, Addrex, Inc., of Reston, Va.   Here's the president and
related companies --

http://www.linkedin.com/pub/charles-m-lee/22/414/a94
http://www.denuo.com
http://www.addrex.net
http://www.depository.net