|
Ticket ID: SIXXS #996770 Ticket Status: Resolved PoP: uschi02 - Your.Org, Inc. (Chicago, Illinois)
pings to PoP-side v6 address fail, possibly causing tunnel to be marked down
![[us]](/s/countries/us.gif) Carmen Sandiego on Wednesday, 11 March 2009 06:02:29
I can't ping the ::1 (PoP-side) IPv6 address from either the tunnel itself or a third party host, and it's possible that this is causing noc.sixxs.net to think my tunnel is "down" when it's definitely passing data just fine.
==========
XP SP3, with v6v4tunnel static tunnel set up:
netsh interface ipv6>dump
#========================
# Interface configuration
#========================
pushd interface ipv6
install
reset
add route prefix=::/0 interface="SixXS" metric=0 publish=yes
add route prefix=2001:4978:f:b8::1/64 interface="SixXS" metric=0
add v6v4tunnel interface="SixXS" localaddress=66.156.66.24 remoteaddress=216.14.
98.22
add address interface="SixXS" address=2001:4978:f:b8::2
popd
# End of interface configuration
# ----------------------------------
# ISATAP Configuration
# ----------------------------------
pushd interface ipv6 isatap
popd
# End of ISATAP configuration
# ----------------------------------
# 6to4 Configuration
# ----------------------------------
pushd interface ipv6 6to4
reset
set state state=disabled
popd
# End of 6to4 configuration
==========
XP firewall set to allow bidirectional ICMP[v6]:
netsh firewall>show icmpsetting
ICMP configuration for Domain profile:
Mode Type Description
-------------------------------------------------------------------
Enable 2 Allow outbound packet too big
Enable 3 Allow outbound destination unreachable
Enable 4 Allow outbound source quench
Enable 5 Allow redirect
Enable 8 Allow inbound echo request
Enable 9 Allow inbound router request
Enable 11 Allow outbound time exceeded
Enable 12 Allow outbound parameter problem
Enable 13 Allow inbound timestamp request
Enable 17 Allow inbound mask request
ICMP configuration for Standard profile:
Mode Type Description
-------------------------------------------------------------------
Enable 2 Allow outbound packet too big
Enable 3 Allow outbound destination unreachable
Enable 4 Allow outbound source quench
Enable 5 Allow redirect
Enable 8 Allow inbound echo request
Enable 9 Allow inbound router request
Enable 11 Allow outbound time exceeded
Enable 12 Allow outbound parameter problem
Enable 13 Allow inbound timestamp request
Enable 17 Allow inbound mask request
==========
From the tunnel's side, pinging the local IP6 works, pinging the remote IP6 does not (it seems to be returning a DEST_UNREACH response!?), and pinging an external host works:
(local IP6)
ping6 2001:4978:f:b8::2
Pinging 2001:4978:f:b8::2
from 2001:4978:f:b8::2 with 32 bytes of data:
Reply from 2001:4978:f:b8::2: bytes=32 time<1ms
Reply from 2001:4978:f:b8::2: bytes=32 time<1ms
Reply from 2001:4978:f:b8::2: bytes=32 time<1ms
Reply from 2001:4978:f:b8::2: bytes=32 time<1ms
Ping statistics for 2001:4978:f:b8::2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
(PoP IP6)
ping6 2001:4978:f:b8::1
Pinging 2001:4978:f:b8::1
from 2001:4978:f:b8::2 with 32 bytes of data:
Reply from 2001:4978:f:b8::1: Destination address unreachable.
Reply from 2001:4978:f:b8::1: Destination address unreachable.
Reply from 2001:4978:f:b8::1: Destination address unreachable.
Reply from 2001:4978:f:b8::1: Destination address unreachable.
Ping statistics for 2001:4978:f:b8::1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
(external host)
ping6 www.sixxs.net
Pinging www.m.sixxs.net [2001:838:1:1:210:dcff:fe20:7c7c]
from 2001:4978:f:b8::2 with 32 bytes of data:
Reply from 2001:838:1:1:210:dcff:fe20:7c7c: bytes=32 time=131ms
Reply from 2001:838:1:1:210:dcff:fe20:7c7c: bytes=32 time=128ms
Reply from 2001:838:1:1:210:dcff:fe20:7c7c: bytes=32 time=133ms
Reply from 2001:838:1:1:210:dcff:fe20:7c7c: bytes=32 time=127ms
Ping statistics for 2001:838:1:1:210:dcff:fe20:7c7c:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 127ms, Maximum = 133ms, Average = 129ms
==========
From outside the tunnel, pinging my IP6 works, but pinging the PoP IP6 does not:
(my IP6)
$ ping6 2001:4978:f:b8::2
PING6(56=40+8+8 bytes) 2001:4f8:4:7:230:48ff:fe31:43f2 --> 2001:4978:f:b8::2
16 bytes from 2001:4978:f:b8::2, icmp_seq=0 hlim=120 time=91.479 ms
16 bytes from 2001:4978:f:b8::2, icmp_seq=1 hlim=120 time=86.776 ms
16 bytes from 2001:4978:f:b8::2, icmp_seq=2 hlim=120 time=86.061 ms
16 bytes from 2001:4978:f:b8::2, icmp_seq=3 hlim=120 time=86.737 ms
--- 2001:4978:f:b8::2 ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 86.061/87.763/91.479/2.499 ms
(PoP IP6)
$ ping6 2001:4978:f:b8::1
PING6(56=40+8+8 bytes) 2001:4f8:4:7:230:48ff:fe31:43f2 --> 2001:4978:f:b8::1
--- 2001:4978:f:b8::1 ping6 statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
pings to PoP-side v6 address fail, possibly causing tunnel to be marked down
Carmen Sandiego on Wednesday, 11 March 2009 06:35:35
Eep. Forgot a few points.
==========
By "marked down" I mean that packet loss is showing as 100% in the graphs, and I'm getting the periodicc e-mails about the tunnel being supposedly "down" in spite of it responding to pings on my end.
==========
Here's traceroute out of the tunnel to ftp.netbsd.org, and back in from there. Note how the ::1 address *is* showing up for the TTL_EXCEEDED response on the way out, and its external interface is showing on the way in.
(tunnel -> outside)
tracert6 -d ftp.netbsd.org
Tracing route to ftp.netbsd.org [2001:4f8:4:7:230:48ff:fe31:43f2]
from 2001:4978:f:b8::2 over a maximum of 30 hops:
1 35 ms 34 ms 39 ms 2001:4978:f:b8::1
2 26 ms 29 ms 26 ms 2001:4978:1:400::ffff
3 26 ms 29 ms 29 ms 2001:470:0:7f::1
4 85 ms 96 ms 91 ms 2001:470:0:3c::1
5 91 ms 86 ms 85 ms 2001:470:0:32::2
6 90 ms 84 ms 92 ms 2001:470:0:38::2
7 87 ms 119 ms 127 ms 2001:4f8:0:1::45:2
8 86 ms 92 ms 98 ms 2001:4f8:0:4::1
9 91 ms 140 ms 126 ms 2001:4f8:4:7:230:48ff:fe31:43f2
(outside -> tunnel)
$ traceroute6 -n 2001:4978:f:b8::2
traceroute6 to 2001:4978:f:b8::2 (2001:4978:f:b8::2) from 2001:4f8:4:7:230:48ff:fe31:43f2, 64 hops max, 12 byte packets
1 2001:4f8:4:7:20b:60ff:fea1:9c1b 0.454 ms 1.108 ms 0.891 ms
2 2001:4f8:0:4::3 4.42 ms 1.469 ms 1.256 ms
3 2001:504:d::10 2.288 ms 2.111 ms 2.28 ms
4 2001:470:0:32::1 2.981 ms 3.103 ms 2.979 ms
5 2001:470:0:3c::2 68.891 ms 60.575 ms 63.424 ms
6 2001:470:0:7f::2 61.089 ms 61.132 ms 60.84 ms
7 2001:4978:1:400:202:b3ff:feb4:5974 67.641 ms 71.074 ms 68.041 ms
8 * * *
9 * * *
==========
Even though ICMP ECHO_REQ pings work, you can see that TTL_EXCEED traceroute it's working on the way in. If I completely *drop* the Windows Firewall, I can get that to work too:
[...]
8 2001:4978:f:b8::2 86.714 ms * 86.125 ms
However, that's obviously not the best solution, and it doesn't seem to affect ping behavior in any case.
I can't seem to line up the timing of this change with any major config changes here. I did start fiddling back and forth with trying AICCU when the symptoms started to appear; but as that didn't seem to fix anything, I went back to a blank slate (netsh interface ipv6 reset) and set it up as v6v4tunnel static tunneling again. Have I perhaps missed something when reconfiguring the tunnel?
pings to PoP-side v6 address fail, possibly causing tunnel to be marked down
Carmen Sandiego on Wednesday, 11 March 2009 18:31:03
Huh, no changes on my side, but I did notice that uschi02 went through a "PoP Down" cycle. As of this writing, pings to the tunnel broker seem to work, and my packet loss isn't showing 100% on the graph.
I think this is resolved.
State change: resolved
The state of this ticket has been changed to resolved
pings to PoP-side v6 address fail, possibly causing tunnel to be marked down
uschi02 is physically moving soon to a new datacenter and hardware, when that is done we'll check up on issues. Hopefully though we have the new sixxsd ready so that that will become much easier.
|
![[ch]](/s/countries/ch.gif)
on Wednesday, 11 March 2009 20:45:21
Posting is only allowed when you are