Re: www.ietf.org unresponsive over IPv6?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 01, 2006 at 02:48:10PM +0200, Jeroen Massar wrote:
> 
> How sure are you these have a MTU of 1500? Best way to test is to do 
> ping6's in the form of "ping6 -M do -s 1500 <target>" and decrementing 
> per 10 or 20 till it doesn't respond anymore and then increasing again.
> 
> >19:  52.ge0-0.cr2.lhr1.uk.occaid.net          asymm 18  16. 63ms pmtu 1480

These seem to be OK.

> Maybe a traceroute6 interface on http://noc.ietf.org/ could help debug 
> these issues easier? I'll send the secretariat a separate message about 
> that, also that they might want to ask Neustar join up with GRH 
> (http://www.sixxs.net/tools/grh/) to make debugging easier as then we at 
> least have ASpaths also which might help here.

I think that would be helpful.   I think IETF could support nice diagnostics
if showcasing v6 connectivity.
 
> Check your neighbor cache after the traceroute/path or even a full TCP 
> connect has completed, you should have an entry similar to:
> 
> jeroen@purgatory:~$ ip -6 ro sho cache
> 2001:503:c779:b::d1ad:35b4 via 2001:7b8:5:10:74::1 dev eth1  metric 0
>     cache  expires 429sec mtu 1480 advmss 1440 hoplimit 4294967295
> 
> The 1480 is noted here, check that that is the case.

Well, I can see www.ipv6tf.org fine, but www.ietf.org hangs in the
browser, but both seem to negotiate 1480 MTU:

For www.ipv6tf.org

$ /usr/sbin/tracepath6 www.ipv6tf.org
 1?: [LOCALHOST]                      pmtu 1500
 1:  2001:630:d0:f102::2                        1.231ms 
 2:  zaphod.6core.ecs.soton.ac.uk               4.443ms 
 3:  ford.6core.ecs.soton.ac.uk                 1.849ms 
 4:  2001:630:c1:100::1                         1.982ms 
 5:  2001:630:c1:10::1                          2.681ms 
 6:  no reply
 7:  no reply
 8:  no reply
 9:  po9-0.cosh-scr.ja.net                      7.729ms 
10:  po2-0.lond-scr.ja.net                      9.693ms 
11:  po0-0.lond-scr4.ja.net                    10.444ms 
12:  gi0-1.lond-isr4.ja.net                     5.880ms 
13:  2001:630:0:10::52                          6.636ms 
14:  uk6x.ipv6.btexact.com                      8.269ms 
15:  uk6x.ipv6.btexact.com                    asymm 14  11.370ms pmtu 1480
15:  v6-tunnel-consulintel.ipv6.btexact.com   asymm 16  68.662ms 
16:  no reply
17:  no reply
<snip>

Indicates 1480, and I get the 1480 MTU in my cache:

[tjc@login ~]$ /sbin/ip -6 ro sho cache
2001:630:d0:f102:20e:cff:fe09:e058 via 2001:630:d0:f102:20e:cff:fe09:e058 dev eth0  metric 0 
    cache  mtu 1500 rtt 27ms rttvar 20ms cwnd 3 advmss 1440
2001:7f9:1000:1::103 via fe80::214:1bff:fe3d:2c00 dev eth0  metric 0 
    cache  expires 557sec mtu 1480 advmss 1440

Then doing the same to www.ietf.org 

$ /usr/sbin/tracepath6 www.ietf.org
 1?: [LOCALHOST]                      pmtu 1500
 1:  2001:630:d0:f102::2                        1.297ms 
 2:  zaphod.6core.ecs.soton.ac.uk               1. 94ms 
 3:  ford.6core.ecs.soton.ac.uk                 1.984ms 
 4:  2001:630:c1:100::1                         2. 35ms 
 5:  2001:630:c1:10::1                          2.746ms 
 6:  no reply
 7:  no reply
 8:  no reply
 9:  po9-0.cosh-scr.ja.net                      3. 16ms 
10:  po2-0.lond-scr.ja.net                      6. 13ms 
11:  po0-0.lond-scr4.ja.net                     5.876ms 
12:  gi0-1.lond-isr4.ja.net                     8.529ms 
13:  2001:630:0:10::52                          8.918ms 
14:  ge-2-24.r01.londen03.uk.bb.gin.ntt.net     8.277ms 
15:  xe-0-1-0.r23.londen03.uk.bb.gin.ntt.net  asymm 16   8.742ms 
16:  xe-0-2-0.r22.londen03.uk.bb.gin.ntt.net  asymm 17   8.823ms 
17:  1d-uk6x.ipv6.btexact.com                  12. 38ms 
18:  52.ge0-0.cr2.lhr1.uk.occaid.net           16.152ms 
19:  52.ge0-0.cr2.lhr1.uk.occaid.net          asymm 18  12.347ms pmtu 1480
19:  v3323-mpd.cr1.ewr1.us.occaid.net          88.965ms 
20:  ge-0-1-0.cr1.iad1.us.occaid.net           93.819ms 
21:  unknown.occaid.net                       100.504ms 
22:  no reply
23:  no reply
<snip>

Suggests 1480, and that's in the cache:

[tjc@login ~]$ /sbin/ip -6 ro sho cache
2001:503:c779:b::d1ad:35b4 via fe80::214:1bff:fe3d:2c00 dev eth0  metric 0 
    cache  expires 591sec mtu 1480 advmss 1440
2001:630:d0:f102:20e:cff:fe09:e058 via 2001:630:d0:f102:20e:cff:fe09:e058 dev eth0  metric 0 
    cache  mtu 1500 rtt 27ms rttvar 20ms cwnd 3 advmss 1440
2001:7f9:1000:1::103 via fe80::214:1bff:fe3d:2c00 dev eth0  metric 0 
    cache  expires 329sec mtu 1480 advmss 1440

So both behave the same apparently in terms of PMTU discovery.

I just wondered if it might be an Apache thing because have run into
things like SENDFILE optimisation issues before.   But you've ruled
that out I think.

> >$ /usr/sbin/traceroute6 www.ietf.org
> >traceroute to www.ietf.org (2001:503:c779:b::d1ad:35b4) from 
> >2001:630:d0:f102:230:48ff:fe23:58df, 30 hops max, 16 byte packets
> > 1  2001:630:d0:f102::2 (2001:630:d0:f102::2)  1.883 ms  2.719 ms  4.513 ms
> > 2  zaphod.6core.ecs.soton.ac.uk (2001:630:d0:f001::1)  4.462 ms  2.485 ms 
> > 2.886 ms
> > 3  ford.6core.ecs.soton.ac.uk (2001:630:d0:f000::1)  3.444 ms  0.648 ms  
> > 0.64 ms
> > 4  2001:630:c1:100::1 (2001:630:c1:100::1)  1.235 ms  1.104 ms  0.962 ms
> > 5  2001:630:c1:10::1 (2001:630:c1:10::1)  1.21 ms  1.138 ms  1.186 ms
> > 6  * * *
> > 7  2001:630:c1::1 (2001:630:c1::1)  4.982 ms  2.891 ms  2.138 ms
> > 8  2001:630:c1::1 (2001:630:c1::1)  2.562 ms  2.189 ms  2.662 ms
> 
> These hops are weird IMHO, 7 & 8 should not be duplicate, prolly a Cisco 
> IOS located there as there are some releases which didn't decrement the 
> TTL when going from Ethernet->ATM or some other weird interface changeover.

Yeah, it's a Cisco MPLS network used by our regional academic network.
 
> jeroen@purgatory:~$ tracepath6 2001:630:d0:f102::2
>  1?: [LOCALHOST]                      pmtu 1500
>  1:  2001:7b8:5:10:74::1                       33.450ms
>  2:  i49.ge-0-1-0.jun1.kelvin.ipv6.network.bit.nl asymm  3  33.178ms
>  3:  jun1.telecity.ipv6.network.bit.nl        asymm  4  34.478ms
>  4:  ge-0.ams-ix.amstnl02.nl.bb.verio.net     asymm  5  34.595ms
>  5:  xe-0-2-0.r22.amstnl02.nl.bb.gin.ntt.net   34.464ms
>  6:  p64-2-0-0.r23.londen03.uk.bb.gin.ntt.net  42.452ms
>  7:  xe-3-1.r01.londen03.uk.bb.gin.ntt.net    asymm  6  42.515ms
>  8:  ge-0.ukerna.londen03.uk.bb.gin.ntt.net   asymm  7  42.596ms
>  9:  fa1-1.lond-isr4.ja.net                   asymm  8  43.537ms
> 10:  gi4-0-1.lond-scr4.ja.net                 asymm  9  44.426ms
> 11:  po0-0.lond-scr.ja.net                    asymm 10  44.597ms
> 12:  po2-0.cosh-scr.ja.net                    asymm 11  46.558ms
> 13:  po0-0.cosham-bar.ja.net                  asymm 12  46.572ms
> 14:  lense.site.ja.net                        asymm 13  46.602ms
> 15:  no reply
> 16:  2001:630:c1:1::1                         asymm 15  47.266ms
> 17:  2001:630:c1:10::2                        asymm 16  48.727ms
> 18:  2001:630:c1:100::2                       asymm 17  48.722ms
> 19:  internal-router.6core.ecs.soton.ac.uk    asymm 18  48.714ms
> 20:  internal-router.6core.ecs.soton.ac.uk    asymm 18  48.597ms !H
>      Resume: pmtu 1500
> 
> Seems also to think it is a MTU of 1500, though the traceroute doesn't 
> finalize.

Try to www.ecs.soton.ac.uk maybe.
 
I guess we should take this offline or to the IPv6 ops list.

Thanks for the far end help :)    Whatever's happening changed quite
recently.  Just curious as to what... I believe we follow the ICMPv6
filtering recommendations text here, and the above suggests PMTU 
discovery is acting reasonably.

-- 
Tim/::1

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]