May 2003 - Test - lists.nanog.org

Re: PMTU and Broken Servers
by Jeff McAdams 10 May '03

10 May '03

Blah...forgot to send this to nanog as well...it seems there is a lack of understanding of why this works in some situations and not in others, so attempted to spread some knowledge here. Also Sprach Leo Bicknell >but I find it slightly (emphasis on the slightly) that someone would >turn on PMTU discovery, and then filter it out right in front of the >boxes where they turned it on. As someone else mentioned...it happens all the time...disconnect between server and network admins probably, or something along those lines (or just general cluelessness) >Also, it seems to me most DSL users are behind PPPoE links with lower >MTU, and should get hit by the same problem. No. The trick, here, is that the PPPoE (typically) terminates on the same system that's terminating the TCP connection, so the PPPoE end system can see that the PMTU is going to be, at most, 1492, so it can use a lower Maximum Segment Size in TCP to start the whole scenario off at the 1492 MTU size and try to go down from there. You're seeing the problem because the tunnel is not terminated on the system that's also terminating the TCP connection, so the TCP processing can't know about the 14xx MTU somewhere out there except through PMTU (which is broken in this case), so it can't set the corresponding MSS to compensate for it initially. >The temporary hack is to have tunnelbox1 clear the DF bit on all >incoming packets, which just causes the packets to get fragmented going >down the tunnel. A minor performance hit, but it works. An only slightly better hack would be to have the tunnel and/or firewall twiddle the MSS on outgoing TCP connections to compensate for the lower tunnel MTU. Still pretty gross, but won't have as much of an effect on the TCP performance. >Are the servers really that broken (PMTU enabled, ICMP Can't Fragement >filtered)? Yes. The last time I ran into this, my test site was www.harvard.edu (!)...though that's been a year or more ago, so they may have resolved their issues since then. We ran into plenty more sites that had the problem, but that's the one that sticks out in my mind because, like I said, it was the one that I used as a site to try to connect to as a test. >Does the head end box of DSL services generally do something to work >around this (ie, clear the DF bit)? Am I just being an idiot and >missing something obvious? I wouldn't say idiot, or missing anything obvious...but you were missing the whole MSS issue. I've never thought the behavior was intuitive or obvious...but once you think about it becomes a "Why didn't I think of that?" sorta thing. -- Jeff McAdams "He who laughs last, thinks slowest." -- anonymous

5 6

AS1 Network peering
by Flash 10 May '03

10 May '03

This is my first posting after lurking for quite some time so please be gentle. I wanted to know if anyone else felt the pain of the former Genuity AS1 de-peering with a number of key nap's Wednesday May 7th. Unfortunately one of our EBGP peers is AS3356 which appears to have picked up a number of the peerings that AS1 disconnected from. Since Level3 and Genuity are one in the same now was this event the merging of portions of AS1 into AS3356 ? Gordon AS13407

2 1

Noc Contact List
by /micah mcnelly 09 May '03

09 May '03

I am looking for a current NOC contact listing for US/CANADA. There are a few people that I need to get ahold of right away. respect, /micah style.net

2 1

RE: Noc Contact List
by Kris Foster 09 May '03

09 May '03

See Jared's list at http://puck.nether.net/netops/ <http://puck.nether.net/netops/> Kris -----Original Message----- From: /micah mcnelly [mailto:micah@style.net] Sent: Friday, May 09, 2003 2:37 PM To: nanog(a)merit.edu Subject: Noc Contact List I am looking for a current NOC contact listing for US/CANADA. There are a few people that I need to get ahold of right away. respect, /micah style.net

1 0

RCN/Erols Peering Contact
by Leo Bicknell 09 May '03

09 May '03

If you are one, and could drop me a note off list that would be grand. :) -- Leo Bicknell - bicknell(a)ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org

1 0

Re: PMTU and Broken Servers
by ddragon＠hushmail.com 09 May '03

09 May '03

"Dalvenjah" you are in direct violation of the NANOG AUP. Please come into compliance by posting with your real name, as opposed to your IRC nickname, otherwise you'll be removed from the list. If we are to believe that "Dajvenjah Foxfire" is your real name, please provide proof of your legal name change, or a birth certificate, for NANOG review. >>>>>> "bicknell" == Leo Bicknell <bicknell(a)ufp.org> writes: > > bicknell> This is a new problem to me, but I'm sure people have > bicknell> run into it before. Are the servers really that broken > bicknell> (PMTU enabled, ICMP Can't Fragement filtered)? Does >the > bicknell> head end box of DSL services generally do something >to > bicknell> work around this (ie, clear the DF bit)? Am I just > bicknell> being an idiot and missing something obvious? > >I first saw this about four years ago with a web site running behind >a load balancing device. It was -- and probably still is -- another >issue of default configuration hell. The web servers were configured >by default to do Path MTU discovery, while the load balancer had >no concept of passing the ICMP Need Fragment packet back to the >appropriate server. > >(There may still be no good way to do this; if I remember right, >> >the ICMP Need Fragment packet contains only IPs and not ports; >the host sending the ICMP packet will be using its IP and the outside >IP of the load balancer, giving the load balancer no good way to >determine where to pass the ICMP packet, unless the load balancer >is guaranteeing that all data from a particular IP goes to a particular >server -- also not a default configuration.) > >It's a hard call for which to make the default; PMTU makes sense, >> >obviously, unless you're running behind a load balancer. It's another >one of those things that probably isn't documented anywhere, or >if it is, >it's buried in an appendix that nobody gets to. > >The only solution is to mail the folks maintaining the web sites >you >can't get to with a short explanation of what you think the problem >is, >and hope they look into it and fix it. Not unlike smurf relays and >networks that don't filter outgoing source addresses. }:> > >-dalvenjah > >-- > > > Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Big $$$ to be made with the HushMail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427

1 0

RE: 69/8 was Re: Re[4]: The in-your-face hijacking example, was: Re: Who is announcing bogons?
by Todd A. Blank 08 May '03

08 May '03

Hey Jon, Things have really quieted down over here. We have a good chunk of our CIDR that comes from 69/8 deployed and get very few complaints lately. Thanks for all the help and for your efforts on regarding issue. Sincerely, Todd A. Blank CTO IPOutlet LLC -----Original Message----- From: jlewis(a)lewis.org [mailto:jlewis@lewis.org] Sent: Sunday, May 04, 2003 5:47 PM To: Scott Granados Cc: richard(a)mandarin.com; nanog(a)merit.edu Subject: 69/8 was Re: Re[4]: The in-your-face hijacking example, was: Re: Who is announcing bogons? On Sat, 3 May 2003, Scott Granados wrote: > You may remove any 138.121.0.0/16 space transiting 26346 I just removed it > all. > > Atrivo is presently only transiting 69.1.78.0/24 via 26346 which is space I > assigned him from my netblock. I don't mean to hijack the thread, but as an early victim of 69/8 space, are you still getting many complaints from customers about reachability issues from that space? According to http://69box.atlantic.net/cgi-bin/bogon there are still hundreds of networks with outdated bogon filters blocking/ignoring 69/8. ---------------------------------------------------------------------- Jon Lewis *jlewis(a)lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

2 1

FW: Official Notice: Information Update Required
by Ray Burkholder 08 May '03

08 May '03

Do other people get these vague notices from Network Solutions? How am I supposed to figure out to which account they are referring? When I click on the link, I get a generic login page, so don't know which of a dozen accounts I might need to update. How do you figure out what they want updated? I've '....' out the specific codes in my message, but assume there are unique to the recipient. Are these magical codes some sort of Network Solution's version of spammer's qualification that you do indeed exist when clicked on? Ray Burkholder -----Original Message----- From: Network Solutions, Inc. [mailto:NetworkSolutions.14207@info1.networksolutions.com] Sent: May 8, 2003 10:30 To: awc(a)viaccess.net Subject: Official Notice: Information Update Required --------------------------------------------------------- In accordance with our Privacy Policy, we are sending you this account notification. --------------------------------------------------------- Dear Network Solutions(R) Customer, The Internet Corporation for Assigned Names and Numbers (ICANN) is the non-profit corporation responsible for accrediting domain name registrars. ICANN requires domain name registration customers to keep their account information current. ICANN mandates that outdated contact information can be grounds for domain name cancellation. To comply with this requirement, please verify, and if necessary, update your account records. To confirm your current account information: * Go to http://info1.networksolutions.com/t/..... * Click on WhoIs in the upper right hand corner of the page * Type your domain name in the WhoIs Search box * Your account information will be displayed If your information is not current, please log in to Account Manager to make any needed updates: http://info1.networksolutions.com/t/.... Thank you for your attention to this matter. Network Solutions Customer Support ------------------------------------------------------------ Please do not reply to this message, as we cannot issue a response. For any customer service inquiries, please click below: mailto:customerservice@networksolutions.com If you would like to unsubscribe from certain e-mail promotions, click below: http://info1.networksolutions.com/us/..... Please note, in accordance with our Privacy Policy, we will continue to send you notices and other important information affecting your account or services in order to fulfill our service obligations to you. Copyright (c) 2003 Network Solutions, Inc. All rights reserved. [[ZVTV-RGJ4-RLOE0O-T]]

2 1

Good (cheap) 2000Mb/s solution?
by Deepak Jain 08 May '03

08 May '03

I need a good, cheap (its temporary) solution to run 2000mb/s over a single pair of multimode fiber (SX handoffs). I'd ideally like to put in two GEs, and get two out. I could use 10G gear, or OC48 gear, but I was hoping for something less pricey since this only has two run about 200ft between two buildings. Any suggestions? I will be glad to summarize for anyone who wants it. Thanks, Deepak Jain AiNET

10 11

Re: PMTU and Broken Servers
by Joe St Sauver 08 May '03

08 May '03

Hi Leo, #The tunnel between the tunnelboxes is a lower (1480) MTU. Originally #the user couldn't access some servers, turns out the firewall was #filtering ICMP Can't Fragment messages, preventing PMTU from working #in the server->user direction (tunnelbox1 would generate Can't #Fragement, firewall would filter). This is actually a more broadly present problem than you might think. I talked about this in the context of a jumbo frames presentation ("Practical Issues Associated with 9K MTUs") I did for the February NLANR/I2 Joint Techs in Miami; see: http://darkwing.uoregon.edu/~joe/jumbos/ (PDF and PowerPoint versions provided) #I find it slightly #(emphasis on the slightly) that someone would turn on PMTU discovery, #and then filter it out right in front of the boxes where they turned #it on. Different folks are probably driving the server network configuration and the firewall/border router configuration process. Disconnect is not inconceivable in that scenario by any means. #This is a new problem to me, but I'm sure people have run into it #before. Are the servers really that broken (PMTU enabled, ICMP #Can't Fragement filtered)? Yes, it is a huge issue potentially. Regards, Joe St Sauver (joe(a)oregon.uoregon.edu) Univeristy of Oregon Computing Center

1 0