SixXS::Sunset 2017-06-06

Ticket ID: SIXXS #990806
Ticket Status: User

PoP: uschi02 - Your.Org, Inc. (Chicago, Illinois)

No incoming traffic on AYIYA tunnel
[us] Shadow Hawkins on Wednesday, 04 March 2009 04:39:39
I have read and followed the "Reporting Problems" section on the Contact page and am providing the following details for this report based on the list of items stated there: User: GDD1-SIXXS Tunnel: T14292 I can see traffic coming out of the AYIYA tunnel (T14292, wheel), but no responses, as evidenced by a ping6/tcpdump to a static tunnel (xen1) on the same PoP: ########################################################################## PING6(56=40+8+8 bytes) 2001:4978:f:bc::2 --> 2001:4978:f:249::2 ^C --- xen1.duzan.org ping6 statistics --- 12 packets transmitted, 0 packets received, 100.0% packet loss ########################################################################## xen1 { ~ } # tcpdump -n -i gif1 host 2001:4978:f:bc::2 tcpdump: WARNING: gif1: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on gif1, link-type NULL (BSD loopback), capture size 96 bytes 22:11:39.304815 IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 0, length 16 22:11:39.304842 IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 0, length 16 22:11:40.313993 IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 1, length 16 22:11:40.314018 IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 1, length 16 22:11:41.303061 IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 2, length 16 22:11:41.303086 IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 2, length 16 22:11:42.308591 IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 3, length 16 22:11:42.308617 IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 3, length 16 22:11:43.283180 IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 4, length 16 22:11:43.283203 IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 4, length 16 22:11:44.279961 IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 5, length 16 22:11:44.279986 IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 5, length 16 22:11:45.310255 IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 6, length 16 22:11:45.310279 IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 6, length 16 22:11:46.296866 IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 7, length 16 22:11:46.296891 IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 7, length 16 22:11:47.300094 IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 8, length 16 22:11:47.300119 IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 8, length 16 22:11:48.293768 IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 9, length 16 22:11:48.293794 IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 9, length 16 22:11:49.308015 IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 10, length 16 22:11:49.308042 IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 10, length 16 22:11:50.297699 IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 11, length 16 22:11:50.297730 IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 11, length 16 ^C 24 packets captured 50 packets received by filter 0 packets dropped by kernel ########################################################################## wheel { /usr/pkgsrc } # tcpdump -i tlp0 src host uschi02.sixxs.net tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tlp0, link-type EN10MB (Ethernet), capture size 96 bytes ########################################################################## Note that there does appear to be a considerable (multi-second) delay in packets reaching the static endpoint. Before the AYIYA tunnel went out entirely, I would occasionally see ping delays of up to 90 seconds (sic). Other traffic over the static tunnel is fine, and the AYIYA tunnel is not seeing any other traffic. There is a NAT router between wheel and the network (Verizon FIOS). OS: NetBSD wheel 4.0.1_PATCH NetBSD 4.0.1_PATCH (WHEEL) #13: Mon Jan 5 08:45:31 EST 2009 root@wheel:/usr2/src/sys/arch/i386/compile/obj.i386/WHEEL i386 aiccu.log ########################################################################## Tunnel Information for T14292: POP Id : uschi02 IPv6 Local : 2001:4978:f:bc::2/64 IPv6 Remote : 2001:4978:f:bc::1/64 Tunnel Type : ayiya Adminstate : enabled Userstate : enabled ifconfig: SIOCAIFADDR: File exists route: writing to routing socket: File exists add net default: gateway 2001:4978:f:bc::1: File exists ####### ####### AICCU Quick Connectivity Test ####### ####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.1.2) ### This should return so called 'echo replies' ### If it doesn't then check your firewall settings ### Your local endpoint should always be pingable ### It could also indicate problems with your IPv4 stack PING wheel.duzan.org (192.168.1.2): 56 data bytes 64 bytes from 192.168.1.2: icmp_seq=0 ttl=255 time=0.144 ms 64 bytes from 192.168.1.2: icmp_seq=1 ttl=255 time=0.154 ms 64 bytes from 192.168.1.2: icmp_seq=2 ttl=255 time=0.154 ms ----wheel.duzan.org PING Statistics---- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.144/0.151/0.154/0.006 ms ###### Did this work? [Y/n] ####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (216.14.98.22) ### These pings should reach the PoP and come back to you ### In case there are problems along the route between your ### host and the PoP this could not return replies ### Check your firewall settings if problems occur PING sixxs.cx01.chi.bb.your.org (216.14.98.22): 56 data bytes 64 bytes from 216.14.98.22: icmp_seq=0 ttl=53 time=34.155 ms 64 bytes from 216.14.98.22: icmp_seq=1 ttl=53 time=35.642 ms 64 bytes from 216.14.98.22: icmp_seq=2 ttl=53 time=35.737 ms ----sixxs.cx01.chi.bb.your.org PING Statistics---- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 34.155/35.178/35.737/0.887 ms ###### Did this work? [Y/n] ####### [3/8] Traceroute to the PoP (216.14.98.22) over IPv4 ### This traceroute should reach the PoP ### In case this traceroute fails then you have no connectivity ### to the PoP and this is most probably the problem traceroute to 216.14.98.22 (216.14.98.22), 64 hops max, 40 byte packets 1 192.168.1.1 (192.168.1.1) 0.536 ms 0.383 ms 0.323 ms 2 L100.VFTTP-10.PHLAPA.verizon-gni.net (72.78.111.1) 6.789 ms 6.918 ms 7.264 ms 3 P2-0.LCR-01.PHLAPA.verizon-gni.net (130.81.39.8) 7.526 ms 6.604 ms 7.296 ms 4 130.81.29.208 (130.81.29.208) 10.363 ms 9.066 ms 10.324 ms 5 so-0-2-0-0.BB-RTR1.NWRK.verizon-gni.net (130.81.19.57) 12.338 ms 11.630 ms 12.438 ms 6 130.81.17.213 (130.81.17.213) 12.307 ms 12.136 ms 12.753 ms 7 130.81.14.42 (130.81.14.42) 14.470 ms 12.145 ms 12.776 ms 8 ae0.cr1.ewr1.us.nlayer.net (69.31.95.141) 14.489 ms 14.362 ms 15.325 ms 9 xe-1-3-0.cr1.lax1.us.nlayer.net (69.22.142.41) 37.076 ms 37.383 ms 37.228 ms 10 tge6-4.ar1.ord1.us.nlayer.net (69.31.111.134) 37.046 ms 37.276 ms 36.985 ms 11 as19255.po1-106.ar1.ord1.us.nlayer.net (69.31.111.22) 37.485 ms 37.188 ms 36.980 ms 12 sixxs.cx01.chi.bb.your.org (216.14.98.22) 37.749 ms 36.775 ms 37.011 ms ###### Did this work? [Y/n] ###### [4/8] Checking if we can ping IPv6 localhost (::1) ### This confirms if your IPv6 is working ### If ::1 doesn't reply then something is wrong with your IPv6 stack PING6(56=40+8+8 bytes) ::1 --> ::1 16 bytes from ::1: Echo Request 16 bytes from ::1, icmp_seq=0 hlim=64 dst=::1%3 time=0.357 ms 16 bytes from ::1: Echo Request 16 bytes from ::1, icmp_seq=1 hlim=64 dst=::1%3 time=0.303 ms 24 bytes from 2001:4978:1e5:1:21f:3cff:fe1b:81a8: Neighbor Advertisement 16 bytes from ::1: Echo Request 16 bytes from ::1, icmp_seq=2 hlim=64 dst=::1%3 time=0.228 ms --- ::1 ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.228/0.296/0.357/0.065 ms ###### Did this work? [Y/n] ###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:4978:f:bc::2) ### This confirms that your tunnel is configured ### If it doesn't reply then check your interface and routing tables PING6(56=40+8+8 bytes) 2001:4978:f:bc::2 --> 2001:4978:f:bc::2 16 bytes from 2001:4978:f:bc::2: Echo Request 16 bytes from 2001:4978:f:bc::2, icmp_seq=0 hlim=64 dst=2001:4978:f:bc::2%12 time=0.365 ms 16 bytes from 2001:4978:f:bc::2: Echo Request 16 bytes from 2001:4978:f:bc::2, icmp_seq=1 hlim=64 dst=2001:4978:f:bc::2%12 time=0.263 ms 16 bytes from 2001:4978:f:bc::2: Echo Request 16 bytes from 2001:4978:f:bc::2, icmp_seq=2 hlim=64 dst=2001:4978:f:bc::2%12 time=0.299 ms --- 2001:4978:f:bc::2 ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.263/0.309/0.365/0.052 ms ###### Did this work? [Y/n] ###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:4978:f:bc::1) ### This confirms the reachability of the other side of the tunnel ### If it doesn't reply then check your interface and routing tables ### Don't forget to check your firewall of course ### If the previous test was succesful then this could be both ### a firewalling and a routing/interface problem PING6(56=40+8+8 bytes) 2001:4978:f:bc::2 --> 2001:4978:f:bc::1 32 bytes from 2001:4978:1e5:1:221:85ff:fec6:feaf: Neighbor Solicitation --- 2001:4978:f:bc::1 ping6 statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss ###### Did this work? [Y/n] n ########################################################################## interfaces ########################################################################## wheel { /usr/pkgsrc } # ifconfig -a tlp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 address: 00:0f:9f:d7:93:9b media: Ethernet autoselect (100baseTX full-duplex) status: active inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255 inet6 fe80::20f:9fff:fed7:939b%tlp0 prefixlen 64 scopeid 0x1 re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 capabilities=3f80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx> enabled=0 address: 00:0c:76:6c:68:67 media: Ethernet autoselect (100baseTX full-duplex) status: active inet 172.16.1.1 netmask 0xffff0000 broadcast 172.16.255.255 inet6 fe80::20c:76ff:fe6c:6867%re0 prefixlen 64 scopeid 0x2 inet6 2001:4978:1e5:1:20c:76ff:fe6c:6867 prefixlen 64 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33192 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 inet 10.1.1.1 -> 10.1.1.2 netmask 0xfffffffc inet6 fe80::20f:9fff:fed7:939b%ppp0 -> prefixlen 64 scopeid 0x9 tun0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1280 inet6 fe80::20f:9fff:fed7:939b%tun0 -> prefixlen 64 scopeid 0xb inet6 fe80::4878:f:bc:2%tun0 -> prefixlen 64 scopeid 0xb tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280 inet6 fe80::20f:9fff:fed7:939b%tun1 -> prefixlen 64 scopeid 0xc inet6 fe80::4878:f:bc:2%tun1 -> prefixlen 64 scopeid 0xc inet6 2001:4978:f:bc::2 -> 2001:4978:f:bc::1 prefixlen 128 wheel { /usr/pkgsrc } # ########################################################################## routes ########################################################################## wheel { /usr/pkgsrc } # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Mtu Interface default 192.168.1.1 UGS 4 12634499 - tlp0 10.1.1.1 127.0.0.1 UGHS 0 71606 33192 lo0 10.1.1.2 10.1.1.1 UH 0 4141862 - ppp0 127/8 127.0.0.1 UGRS 0 0 33192 lo0 127.0.0.1 127.0.0.1 UH 9 3730285 33192 lo0 172.16/16 link#2 UC 8 0 - re0 172.16.1.1 00:0c:76:6c:68:67 UHLc 0 6611099 - lo0 172.16.1.2 00:21:85:c6:fe:af UHLc 6 14862189 - re0 172.16.1.3 00:08:a1:0b:b8:78 UHLc 3 252014 - re0 172.16.64.240 00:00:48:51:d0:13 UHLc 0 9793 - re0 172.16.64.245 00:1c:26:1a:b4:5e UHLc 3 2810538 - re0 172.16.100.4 00:17:a4:70:80:8c UHLc 0 6983 - re0 172.16.100.5 00:1f:3c:1b:81:a8 UHLc 0 1503796 - re0 172.16.255.255 link#2 UHLc 2 52672 - re0 192.168.1/24 link#1 UC 1 0 - tlp0 192.168.1.1 00:1f:90:27:99:3c UHLc 2 24 - tlp0 192.168.1.2 127.0.0.1 UGHS 0 103150 33192 lo0 Internet6: Destination Gateway Flags Refs Use Mtu Interface ::/104 ::1 UGRS 0 0 - lo0 => ::/96 ::1 UGRS 0 0 - lo0 => default 2001:4978:f:bc::1 UGS 0 0 - tun1 ::1 ::1 UH 14 48 33192 lo0 ::127.0.0.0/104 ::1 UGRS 0 0 - lo0 ::224.0.0.0/100 ::1 UGRS 0 0 - lo0 ::255.0.0.0/104 ::1 UGRS 0 0 - lo0 ::ffff:0.0.0.0/96 ::1 UGRS 0 0 - lo0 2001:db8::/32 ::1 UGRS 0 0 - lo0 2001:4978:f:bc::1 2001:4978:f:bc::2 UH 1 0 - tun1 2001:4978:f:bc::2 link#12 UHL 0 0 - lo0 2001:4978:1e5:1::/64 link#2 UC 2 0 - re0 2001:4978:1e5:1:20c:76ff:fe6c:6867 00:0c:76:6c:68:67 UHL 1 0 - lo0 2001:4978:1e5:1:21f:3cff:fe1b:81a8 00:1f:3c:1b:81:a8 UHLc 3 3464000 - re0 2001:4978:1e5:1:221:85ff:fec6:feaf 00:21:85:c6:fe:af UHLc 3 3519486 - re0 2002::/24 ::1 UGRS 0 0 - lo0 2002:7f00::/24 ::1 UGRS 0 0 - lo0 2002:e000::/20 ::1 UGRS 0 0 - lo0 2002:ff00::/24 ::1 UGRS 0 0 - lo0 fc00::/7 ::1 UGRS 0 0 - lo0 fe80::/10 ::1 UGRS 0 0 - lo0 fe80::%tlp0/64 link#1 UC 0 0 - tlp0 fe80::20f:9fff:fed7:939b%tlp0 00:0f:9f:d7:93:9b UHL 0 0 - lo0 fe80::%re0/64 link#2 UC 2 0 - re0 fe80::20c:76ff:fe6c:6867%re0 00:0c:76:6c:68:67 UHL 0 0 - lo0 fe80::21f:3cff:fe1b:81a8%re0 00:1f:3c:1b:81:a8 UHLc 0 4085 - re0 fe80::221:85ff:fec6:feaf%re0 00:21:85:c6:fe:af UHLc 1 7229 - re0 fe80::%lo0/64 fe80::1%lo0 U 0 0 - lo0 fe80::1%lo0 link#3 UHL 0 0 - lo0 fe80::%ppp0/64 link#9 UC 0 0 - ppp0 fe80::20f:9fff:fed7:939b%ppp0 link#9 UHL 0 0 - lo0 fe80::%tun0/64 link#11 UC 0 0 - tun0 fe80::20f:9fff:fed7:939b%tun0 link#11 UHL 0 0 - lo0 fe80::4878:f:bc:2%tun0 link#11 UHL 0 0 - lo0 fe80::%tun1/64 link#12 UC 0 0 - tun1 fe80::20f:9fff:fed7:939b%tun1 link#12 UHL 0 0 - lo0 fe80::4878:f:bc:2%tun1 link#12 UHL 0 0 - lo0 ff01:1::/32 link#1 UC 0 0 - tlp0 ff01:2::/32 link#2 UC 0 0 - re0 ff01:3::/32 ::1 UC 0 0 - lo0 ff01:9::/32 link#9 UC 0 0 - ppp0 ff01:b::/32 link#11 UC 0 0 - tun0 ff01:c::/32 link#12 UC 0 0 - tun1 ff02::%tlp0/32 link#1 UC 0 0 - tlp0 ff02::%re0/32 link#2 UC 0 0 - re0 ff02::%lo0/32 ::1 UC 0 0 - lo0 ff02::%ppp0/32 link#9 UC 0 0 - ppp0 ff02::%tun0/32 link#11 UC 0 0 - tun0 ff02::%tun1/32 link#12 UC 0 0 - tun1 wheel { /usr/pkgsrc } # ##########################################################################
State change: user Locked
[ch] Jeroen Massar SixXS Staff on Wednesday, 04 March 2009 10:23:09
Message is Locked
The state of this ticket has been changed to user
No incoming traffic on AYIYA tunnel
[ch] Jeroen Massar SixXS Staff on Wednesday, 04 March 2009 10:33:36
as evidenced by a ping6/tcpdump to a static tunnel (xen1) on the same PoP:
Which route are those packets taking? Also dumping a gif tunnel doesn't say anything, you need to dump the underlying tunnel. Ping is a bi-directional communication, thus as you have echo+reply there there must be a bi-directional communication.
Note that there does appear to be a considerable (multi-second) delay in
packets reaching the static endpoint. Before the AYIYA tunnel went out
entirely, I would occasionally see ping delays of up to 90 seconds (sic).
Your output doesn't show any latency. Also, it could be in a lot of locations where latency occurs.
wheel { /usr/pkgsrc } # tcpdump -i tlp0 src host uschi02.sixxs.net
Dumping something with only 'src' specified will avoid you from seeing all the ICMP packets that might come back from intermediate nodes that might not want to deliver your packet. Also, does your implementation of tcpdump there pick the IPv4 address, the IPv6 address or both addresses for that hostname?
ifconfig: SIOCAIFADDR: File exists
route: writing to routing socket: File exists
add net default: gateway 2001:4978:f:bc::1: File exists
Those are really odd errors to get, either you are running AICCU twice at the same time or you have something else configured already.
PING6(56=40+8+8 bytes) 2001:4978:f:bc::2 --> 2001:4978:f:bc::1
32 bytes from 2001:4978:1e5:1:221:85ff:fec6:feaf: Neighbor Solicitation
You ping and get neighbor solications for a completely unrelated prefix? That is another very strange thing, it seems to be an address you assigned to another interface than the tunnel.
No incoming traffic on AYIYA tunnel
[us] Shadow Hawkins on Wednesday, 04 March 2009 13:14:51
I have read and followed the "Reporting Problems" section on the Contact page and am providing the following details for this report based on the list of items stated there:
Which route are those packets taking? Also dumping a gif tunnel doesn't say
anything, you need to dump the underlying tunnel.
Here is the underlying tunnel from the remote: ############################################################################### xen1 { ~ } # tcpdump -n -i xennet0 host uschi02.sixxs.net tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on xennet0, link-type EN10MB (Ethernet), capture size 96 bytes 06:58:34.247307 IP 216.14.98.22 > 66.251.193.82: IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 0, length 16 06:58:34.247358 IP 66.251.193.82 > 216.14.98.22: IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 0, length 16 06:58:34.302151 IP 216.14.98.22 > 66.251.193.82: IP6 2001:4978:f:249::1 > 2001:4978:f:249::2: ICMP6, destination unreachable[|icmp6] 06:58:35.263755 IP 216.14.98.22 > 66.251.193.82: IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 1, length 16 06:58:35.263800 IP 66.251.193.82 > 216.14.98.22: IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 1, length 16 06:58:35.317099 IP 216.14.98.22 > 66.251.193.82: IP6 2001:4978:f:249::1 > 2001:4978:f:249::2: ICMP6, destination unreachable[|icmp6] 06:58:36.291013 IP 216.14.98.22 > 66.251.193.82: IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 2, length 16 06:58:36.291063 IP 66.251.193.82 > 216.14.98.22: IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 2, length 16 06:58:36.344266 IP 216.14.98.22 > 66.251.193.82: IP6 2001:4978:f:249::1 > 2001:4978:f:249::2: ICMP6, destination unreachable[|icmp6] 06:58:37.281337 IP 216.14.98.22 > 66.251.193.82: IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 3, length 16 06:58:37.281390 IP 66.251.193.82 > 216.14.98.22: IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 3, length 16 06:58:37.334487 IP 216.14.98.22 > 66.251.193.82: IP6 2001:4978:f:249::1 > 2001:4978:f:249::2: ICMP6, destination unreachable[|icmp6] 06:58:38.251651 IP 216.14.98.22 > 66.251.193.82: IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 4, length 16 06:58:38.251698 IP 66.251.193.82 > 216.14.98.22: IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 4, length 16 06:58:38.304969 IP 216.14.98.22 > 66.251.193.82: IP6 2001:4978:f:249::1 > 2001:4978:f:249::2: ICMP6, destination unreachable[|icmp6] 06:58:39.253998 IP 216.14.98.22 > 66.251.193.82: IP6 2001:4978:f:bc::2 > 2001:4978:f:249::2: ICMP6, echo request, seq 5, length 16 06:58:39.254044 IP 66.251.193.82 > 216.14.98.22: IP6 2001:4978:f:249::2 > 2001:4978:f:bc::2: ICMP6, echo reply, seq 5, length 16 06:58:39.307248 IP 216.14.98.22 > 66.251.193.82: IP6 2001:4978:f:249::1 > 2001:4978:f:249::2: ICMP6, destination unreachable[|icmp6] ^C 18 packets captured 310 packets received by filter 0 packets dropped by kernel ############################################################################### It looks the PoP may not be getting the reverse route set up properly. As for the IPv4 route, the route to the PoP is in the aiccu test output. The route from the PoP to the static endpoint is: ############################################################################### Hop Node Loss% Sent Last Avg Best Worst StDev 1. 216.14.98.21 0.0% 5 3.9 2.8 0.6 5.2 2.1 ge-0.0.0-30.core1.chi.bb.your.org. 2. 206.51.33.15 0.0% 5 1.9 0.9 0.6 1.9 0.6 ChIX.wvfiber.net. 3. 64.127.130.54 0.0% 5 14.5 14.8 13.5 16.4 1.1 nsh-t4-3-2200-chi-vl2200.wvfiber.net. 4. 64.127.130.57 0.0% 5 20.6 25.6 20.6 41.1 8.8 atl-ten3-2-nsh-ten4-1.wvfiber.net. 5. 66.216.8.74 0.0% 5 33.2 33.2 33.1 33.6 0.2 6. 66.113.197.54 0.0% 5 46.0 46.2 45.8 47.5 0.7 e1-13.pr0.tpax.hgtn.net. 7. 66.113.197.90 0.0% 5 35.9 36.9 35.9 37.9 1.0 e1-19.co1.as30217.net. 8. 84.40.24.50 0.0% 5 45.9 46.1 45.8 46.8 0.4 te3-4.co2.as30217.net. 9. 84.40.24.34 0.0% 5 45.9 47.2 45.9 49.7 1.5 e1-1.ar1.as30217.net. 10. 84.40.24.22 0.0% 5 47.3 46.5 45.9 47.3 0.6 iglobal-networks.ar1.as30217.net. 11. 66.251.193.82 0.0% 5 46.5 46.7 46.3 47.8 0.6 xen1.duzan.org. ############################################################################### The route from the PoP to the NAT in front of the AYIYA is: ############################################################################### Hop Node Loss% Sent Last Avg Best Worst StDev 1. 216.14.98.21 0.0% 5 4.5 1.7 0.6 4.5 1.7 ge-0.0.0-30.core1.chi.bb.your.org. 2. 69.31.111.21 0.0% 5 0.5 1.4 0.5 3.7 1.4 po1-106.ar1.ord1.us.nlayer.net. 3. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 4. 69.31.111.82 0.0% 5 0.6 3.0 0.6 11.5 4.8 as19262.xe-1-3-0-312.cr1.ord1.us.nlayer.net. 5. 130.81.17.192 0.0% 5 2.7 3.2 2.6 5.2 1.2 6. 130.81.19.108 0.0% 5 23.9 25.1 23.9 28.8 2.1 7. 130.81.17.2 0.0% 5 28.6 34.0 27.9 50.8 9.6 8. 130.81.29.213 0.0% 5 34.2 31.6 28.6 34.7 2.8 P14-0-0.LCR-03.PHLAPA.verizon-gni.net. 9. 130.81.30.160 0.0% 5 28.9 29.9 28.8 31.9 1.4 P13-0-0.LCR-01.PHLAPA.verizon-gni.net. 10. 130.81.247.239 0.0% 5 35.4 31.0 29.6 35.4 2.5 L1.VFTTP-10.PHLAPA.verizon-gni.net. 11. 71.244.108.167 0.0% 5 38.8 38.1 35.3 42.6 2.8 pool-71-244-108-167.phlapa.fios.verizon.net. ###############################################################################
Your output doesn't show any latency. Also, it could be in a lot of locations
where latency occurs.
True, the latency was just observed as a delay from the tcpdump output in this case. I've never noticed any latency in IPv4 traffic (e.g. traceroutes) to the PoP from either tunnel endpoint, so I was guessing that the delay was in IPv6 handling.
Those are really odd errors to get, either you are running AICCU twice at the
same time or you have something else configured already.
It is possible I forgot to shut down aiccu first on this run, but I've made multiple runs with the same results when I know it was shut down properly.
You ping and get neighbor solications for a completely unrelated prefix? That
is another very strange thing, it seems to be an address you assigned to
another interface than the tunnel.
That address is from my subnet off this AYIYA tunnel, R8009.
No incoming traffic on AYIYA tunnel
[us] Shadow Hawkins on Wednesday, 04 March 2009 21:53:01
The tunnel is fine at the moment.

Please note Posting is only allowed when you are logged in.

Static Sunset Edition of SixXS
©2001-2017 SixXS - IPv6 Deployment & Tunnel Broker