Re: Performance Issues - PTR Records
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
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?
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
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
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] ?????????????
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
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
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
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?
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?
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 ?
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
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
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