Ticket ID: SIXXS #990806 Ticket Status: User PoP: uschi02 - Your.Org, Inc. (Chicago, Illinois)
No incoming traffic on AYIYA tunnel
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
Jeroen Massar on Wednesday, 04 March 2009 10:23:09
The state of this ticket has been changed to user
No incoming traffic on AYIYA tunnel
Jeroen Massar 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
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
Shadow Hawkins on Wednesday, 04 March 2009 21:53:01
The tunnel is fine at the moment.
Posting is only allowed when you are logged in. |