- NANOG - lists.nanog.org

Linux shaping packet loss
by Chris 11 Dec '09

11 Dec '09

Hi All, It would be appreciated if anyone using TC on Linux for shaping could please help with an intermittent problem on an egress interface. I'm seeing about ten per cent of packet loss for all classes at seemingly quiet times and random parts of the day using about forty classes and 250Mbps. I've isolated it to the egress HTB qdisc. Any TC experts out there have a spare minute please ? Any thoughts on the RED qdisc ? Thanks very much, Chris

15 21

Linux Network Generator
by Joseph Jackson 10 Dec '09

10 Dec '09

Hey list, I've been doing some stress testing of a router this week using Network Traffic Generator from http://sourceforge.net/projects/traffic/ and while it works well I was wondering what other generators you all have used and find helpful. Maybe something that Traffic doesn't do like provide response times and other stats.. tho I realize iperf would be a better app for that.

1 0

Cogent admin request
by Chris Cariffe 09 Dec '09

09 Dec '09

if there's a Cogent NOC admin here, can you please contact me privately, off the list. thanks. -c

1 0

Leaving public peering?
by Lasher, Donn 09 Dec '09

09 Dec '09

This year I've been seeing what appears to be an increasing trend among service providers.. making the decision to leave public peering. I'm sure others on this list as seeing that trend as well. I have a couple of guesses, but I'm curious , and I wanted to get some other thoughts as to the "why". I don't have exact numbers, but off the top of my head, I'd guess somewhere around two dozen of our peers have left various peering exchanges. Quick couple I checked still appear to be operational as a company, so I'm willing to remove "death" as a valid reason. I realized that paid transit is down at almost obscene levels, but is that enough of a reason to increase hop-count, latencies, etc? Why disconnect from public mostly-free peering? -donn

11 11

AT&T blocking individual IP addresses
by Scott Howard 09 Dec '09

09 Dec '09

As of about an hour ago AT&T appear to have started blocking access to a few of our IP addresses. This is being done at a /32 level, and the IP addresses above and below are still allowed through. Has anyone seen them do this before, or know who I need to contact to get it fixed? AT&T won't talk to me as I'm not a customer... Traceroute to the blocked IPs from AT&T all end at : 5 cr2.phlpa.ip.att.net (12.122.3.226) [MPLS: Labels 20559/17406 Exp 0] 116 msec 20 msec 20 msec 6 cr2.cl2oh.ip.att.net (12.122.2.209) [MPLS: Labels 20527/17406 Exp 0] 24 msec 20 msec 20 msec 7 cr1.cl2oh.ip.att.net (12.122.2.125) [MPLS: Labels 0/17406 Exp 0] 24 msec 20 msec 20 msec 8 cr82.dtrmi.ip.att.net (12.123.139.154) [MPLS: Label 16623 Exp 0] 24 msec 20 msec 20 msec 9 gar4.dtrmi.ip.att.net (12.122.102.89) 20 msec 20 msec 20 msec 10 12.87.238.238 [AS 7018] 24 msec 20 msec 24 msec 11 12.87.238.237 [AS 7018] !A * * Traceroute to the neighboring IP addresses don't go anywhere near the above path, so it's apparently a blackhole of sorts. Scott.

3 5

ARIN/RIPE NCC Joint Statement on ASN Assignment Discrepancies
by John Curran 09 Dec '09

09 Dec '09

ARIN and the RIPE NCC have worked together to research the issues with the Autonomous System Number (ASN) range AS1707-AS1726. Below is our analysis of what happened and a plan to resolve these issues. It appears that prior to 1993, Renater was issued AS1707 with an AS name of "ASNBLOCKA". This is the name format used to assign a block of ASNs, but the DDN NIC (the Defense Data Network Network Information Center, which was responsible for ASN assignments until 1993) recorded only a single assignment of AS1707, rather than the entire block of 20 ASNs (AS1707-AS1726), as would have been expected. AS1712 was never registered in the DDN NIC database. Since the proper registration was never recorded, this mistake carried over from the InterNIC database into ARIN's database at ARIN’s inception in 1997. The ASN range was not transferred to the RIPE NCC along with AS1707 because AS1708-AS1726 appeared to be unassigned, and thus remained with ARIN. Because this is simply an error in registry data and Renater is the actual registrant of this entire range of ASNs (AS1707-AS1726), ARIN will work with its customers who received ASNs from this range in July and August of 2009 to provide them with replacement ASNs. While we understand that this may cause some difficulty for these customers, we feel that this is the best path forward given the circumstances. RIPE NCC and ARIN will update their respective databases and work with the IANA to ensure that the ASN registry data is properly updated for this range. To prevent future issues, ARIN and RIPE NCC will implement two new processes for issuing new ASNs: checking all other RIR databases to ensure that the ASN is not previously registered, and checking BGP routing tables to ensure the ASN is not already found in an announced AS-path. ASNs that fail either of these conditions will not be issued until the discrepancy has been addressed. Regards, John Curran, President and CEO, ARIN Axek Pawlik, Managing Director, RIPE NCC

1 1

Earthlink SMTP Admin Contact?
by Ryan Gelobter 09 Dec '09

09 Dec '09

Any chance there's someone from Earthlink on nanog or anyone that has contact information? We have a large IP block that is being listed as dynamic by Earthlink's mail servers causing mail to be returned and have gotten nowhere with the normal procedures or the abuse mailbox at (866) 525-8194. Feel free to contact me off-list. Thanks, Ryan G IT Assistant/Support Technician Limestone Networks, Inc. r.gelobter(a)limestonenetworks.com<mailto:r.gelobter@limestonenetworks.com> www.limestonenetworks.com<http://www.limestonenetworks.com> Simple. Solid. Superior.

4 4

"Cool" ISPs
by Steven Bellovin 09 Dec '09

09 Dec '09

Some folks on this list may be interested in Ars Technica's take on "cool" ISPs: http://arstechnica.com/tech-policy/news/2009/12/the-coolest-isp-in-the-worl… (note: I neither endorse nor condemn any of the ideas, ISPs, etc. In other words, don't blame me if you disagree...) --Steve Bellovin, http://www.cs.columbia.edu/~smb

2 1

RE: SPF Configurations
by Jeffrey Negro 08 Dec '09

08 Dec '09

Thanks for your input on this. My main concern is mail filters at the end users side thinking that our mail servers are spoofing our customer's domain. I'll check into MAAWG as well Jeffrey Negro, Network Engineer Billtrust - Improving Your Billing, Improving Your Business www.billtrust.com 609.235.1010 x137 jnegro(a)billtrust.com -----Original Message----- From: Joe St Sauver [mailto:joe@oregon.uoregon.edu] Sent: Friday, December 04, 2009 11:25 AM To: Jeffrey Negro Subject: Re: SPF Configurations #Some customers insist on #making the FROM address use their domain name, but the emails leave our #mail servers on our domain. Then your IPs or outbound mail servers should be listed on the customer's SPF record... assuming they also send their own mail, they obviously also want to list their own mail servers. #SPF seems to be the way we could possibly avoid more spam filters, SPF only provides a way of avoiding spoofing, it does not necessarily enhance your IP reputation or your domain reputation #and delivery rate is very important to our company. Are you involved with MAAWG? (see www.maawg.org) Regards, Joe

13 18

Historical traceroute logging
by Justin Shore 07 Dec '09

07 Dec '09

Does anyone know of any tools that can do repeated traceroutes over time to a remote IP and log the results for later viewing/comparison? I'd like to do a traceroute several times a day and store the details in CVS or somewhere accessible down the road. Alerting to major path changes would be nice but not critical. The ability to compare traceroute output down the road would also be nice but also not critical. I'm more interested in the path than the individual hops' RTTs. What's prompting this is a major change in RTTs for several hours yesterday to an ITSP with a site in the south. We share a common upstream (L3) and have in the past always transited that provider to get to each other. I showed a route change for the specific /23 in question in my border routers' RIBs. The adjacent /23 originating from the same ITSP but in a different part of the country did not change (and neither did RTTs to the hosts we monitor in that /23). The site claimed nothing changed on their end and that they know of no changes upstream. BGP Play shows a route change from Level3 to Internap during the time in question (thought the times don't line up exactly) which most likely caused the more than double RTTs we were seeing. My Cacti Advanced Ping graphs caught the problem in all its glory. Nagios alerted me to the high RTT times as well. What I didn't get during that period of time was a traceroute to the site in question. I'd like to run a traceroute several times a day and find some way to store the output and work with it later if needed. I'd prefer OSS but commercial apps would be considered too. I'm sure I'm not the first to have a need to check traceroutes like that. How do the rest of you handle it? Thanks Justin

6 5