Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: nsp: ipv6

Comcast6.net PMTU broken

 

 

nsp ipv6 RSS feed   Index | Next | Previous | View Threaded


ryan at u13

Apr 17, 2012, 2:24 PM

Post #1 of 5 (1893 views)
Permalink
Comcast6.net PMTU broken

From a host behind a 6in4 tunnel a request to www.comcast6.net hangs. It looks like a PMTU brokenness issue since the connection is established and the request is sent successfully.

Requesting the same page from a host with a 1500B path MTU succeeds.

nova-dhcp-host111:tmp ryan$ wget http://www.comcast6.net
--2012-04-17 17:17:16-- http://www.comcast6.net/
Resolving www.comcast6.net (www.comcast6.net)... 2001:558:1002:4:68:87:29:36, 68.87.29.36
Connecting to www.comcast6.net (www.comcast6.net)|2001:558:1002:4:68:87:29:36|:80... connected.
HTTP request sent, awaiting response... ^C


This only happens with 2001:558:1002:4:68:87:29:36. 2001:558:1004:9:69:242:76:78 (which I've seen listed for www.comcast6.net though I do not see it in DNS currently) does not have this problem


ryan at u13

Apr 17, 2012, 2:57 PM

Post #2 of 5 (1801 views)
Permalink
Re: Comcast6.net PMTU broken [In reply to]

On Apr 17, 2012, at 5:24 PM, Ryan Rawdon wrote:

> From a host behind a 6in4 tunnel a request to www.comcast6.net hangs. It looks like a PMTU brokenness issue since the connection is established and the request is sent successfully.


I've gotta follow-up to my original message and say I'm not quite sure what is going on. Doing more testing I am sporadically having the symptom shown below mixed in with attempts which outright fail to connect (coupled with at least one person on IRC who isn't able to connect to the same address). I am so far unable to reproduce it from other sites with a 1280 MTU

Foot in mouth - looks like it is not necessarily a PMTU issue.

>
> Requesting the same page from a host with a 1500B path MTU succeeds.
>
> nova-dhcp-host111:tmp ryan$ wget http://www.comcast6.net
> --2012-04-17 17:17:16-- http://www.comcast6.net/
> Resolving www.comcast6.net (www.comcast6.net)... 2001:558:1002:4:68:87:29:36, 68.87.29.36
> Connecting to www.comcast6.net (www.comcast6.net)|2001:558:1002:4:68:87:29:36|:80... connected.
> HTTP request sent, awaiting response... ^C
>
>
> This only happens with 2001:558:1002:4:68:87:29:36. 2001:558:1004:9:69:242:76:78 (which I've seen listed for www.comcast6.net though I do not see it in DNS currently) does not have this problem


jeroen at unfix

Apr 17, 2012, 3:04 PM

Post #3 of 5 (1748 views)
Permalink
Re: Comcast6.net PMTU broken [In reply to]

On 2012-04-17 23:24 , Ryan Rawdon wrote:
> From a host behind a 6in4 tunnel a request to www.comcast6.net hangs. It looks like a PMTU brokenness issue since the connection is established and the request is sent successfully.
>
> Requesting the same page from a host with a 1500B path MTU succeeds.
>
> nova-dhcp-host111:tmp ryan$ wget http://www.comcast6.net

Try 'tracepath6' it will show you which hop is not returning a packet
too big for that path if needed. Also one can use a series of "ping6 -s
<size> -M do" to check if packets pass or not (if the destination allows
pings of course).

Greets,
Jeroen


owens at nysernet

Apr 17, 2012, 5:05 PM

Post #4 of 5 (1770 views)
Permalink
Re: Comcast6.net PMTU broken [In reply to]

On Tue, Apr 17, 2012 at 05:24:35PM -0400, Ryan Rawdon wrote:
> From a host behind a 6in4 tunnel a request to www.comcast6.net hangs. It looks like a PMTU brokenness issue since the connection is established and the request is sent successfully.

If you have access to an ipfw-based machine (OSX definitely counts, other BSDs as well, but not Linux) then the definitive way to test is with scamper:

[cookiemonster:~] owens% sudo /usr/local/bin/scamper -F ipfw -I "tbit -M 1280 -u 'http://www.comcast6.g.comcast.net' 2001:558:1002:4:68:87:29:36"
tbit from 2620:f:1:1201:21b:63ff:fea4:4d92 to 2001:558:1002:4:68:87:29:36
server-mss 1440, result: pmtud-success
app: http, url: http://www.comcast6.g.comcast.net/
[ 0.050] TX SYN 64 seq = 0:0
[ 0.073] RX SYN/ACK 64 seq = 0:1
[ 0.100] TX 60 seq = 1:1
[ 0.150] TX 245 seq = 1:1(185)
[ 0.174] RX 60 seq = 1:186
[ 0.174] RX 1500 seq = 1:186(1440)
[ 0.174] RX 1500 seq = 1441:186(1440)
[ 0.200] TX PTB 1280 mtu = 1280
[ 0.223] RX 1280 seq = 1:186(1220)
[ 0.223] RX 1280 seq = 1221:186(1220)
[ 0.250] TX 60 seq = 186:1221
[ 0.273] RX 500 seq = 2441:186(440)
[ 0.273] RX 1280 seq = 2881:186(1220)
[ 0.300] TX FIN 60 seq = 186:2441
[ 0.323] RX 60 seq = 4101:187
[ 0.323] RX 1280 seq = 4101:187(1220)
[ 0.323] RX 500 seq = 5321:187(440)
[ 0.350] TX FIN 60 seq = 186:2881
[ 0.374] RX 1280 seq = 5761:187(1220)
[ 0.374] RX 1280 seq = 6981:187(1220)
[ 0.399] TX FIN 60 seq = 186:4101
[ 0.423] RX 500 seq = 8201:187(440)
[ 0.450] TX 60 seq = 187:5321
[ 0.474] RX 1280 seq = 8641:187(1220)
[ 0.474] RX 1280 seq = 9861:187(1220)
[ 0.474] RX 500 seq = 11081:187(440)
[ 0.500] TX 60 seq = 187:5761
[ 0.550] TX 60 seq = 187:6981
[ 0.573] RX 1280 seq = 11521:187(1220)
[ 0.573] RX 1280 seq = 12741:187(1220)
[ 0.574] RX 280 seq = 13961:187(220)
[ 0.600] TX 60 seq = 187:8201
[ 0.623] RX 280 seq = 14181:187(220)
[ 0.623] RX FIN 889 seq = 14401:187(829)
[ 0.650] TX 60 seq = 187:8641
[ 0.700] TX 60 seq = 187:9861
[ 0.750] TX 60 seq = 187:11081
[ 0.800] TX 60 seq = 187:11521
[ 0.850] TX 60 seq = 187:12741
[ 0.900] TX 60 seq = 187:13961
[ 0.950] TX 60 seq = 187:14181
[ 1.000] TX 60 seq = 187:14401


Here's the odd thing though - the first time I tested, I saw the response above. Successive tests have resulted in 'pmtud-toosmall', which indicates that the server didn't send any individual packets above 1280 bytes. I wonder if there are more than one server behind a balancer, and somewhat different behavior?

Bill.


mjl at luckie

Apr 18, 2012, 9:03 AM

Post #5 of 5 (1739 views)
Permalink
Re: Comcast6.net PMTU broken [In reply to]

> Here's the odd thing though - the first time I tested, I saw the
> response above. Successive tests have resulted in 'pmtud-toosmall',
> which indicates that the server didn't send any individual packets
> above 1280 bytes. I wonder if there are more than one server behind
> a balancer, and somewhat different behavior?

The first time the webserver is tested it does not know what the path
MTU to a particular client is, so it uses the MTU of the outbound
interface. When the PMTU is lowered, the webserver caches that value
for subsequent connections for a short time.

Matthew

nsp ipv6 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.