ietf
[Top] [All Lists]

Re: www.ietf.org unresponsive over IPv6?

2006-09-01 09:36:51
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(_at_)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(_at_)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(_at_)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(_at_)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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>