|
uschi02 down?
![[us]](/s/countries/us.gif) Shadow Hawkins on Monday, 10 March 2008 10:56:38
Before I go looney trying to fix something that's not broken (which may have already happened, as it's been 3 trying days)...
Over the last 3 days I've managed to sneak maybe a dozen packets through on ipv6. aiccu starts as expected, my routing table looks clean, my ifconfig output is clean, I've tried a few dozen reboots, and so on. As far as I can tell, uschi02 is not routing packets or is unreachable via ipv6.
If anyone can either confirm that uschi02 is having problems, or can spot something that looks wrong in my setup here, I would be very happy either way.
The nitty gritty:
aiccu start output:
Tunnel Information for T14177:
POP Id : uschi02
IPv6 Local : 2001:4978:f:a2::2/64
IPv6 Remote : 2001:4978:f:a2::1/64
Tunnel Type : 6in4-heartbeat
Adminstate : enabled
Userstate : enabled
ping6 2001:4978:f:a2::1
PING 2001:4978:f:a2::1(2001:4978:f:a2::1) 56 data bytes
--- 2001:4978:f:a2::1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2001ms
tshark -i aiccu (during that ping6)
Capturing on aiccu
0.000000 2001:4978:f:a2::2 -> 2001:4978:f:a2::1 ICMPv6 Echo request
1.001486 2001:4978:f:a2::2 -> 2001:4978:f:a2::1 ICMPv6 Echo request
2.001418 2001:4978:f:a2::2 -> 2001:4978:f:a2::1 ICMPv6 Echo request
ifconfig aiccu && ifconfig eth1
aiccu Link encap:IPv6-in-IPv4
inet6 addr: 2001:4978:f:a2::2/64 Scope:Global
inet6 addr: fe80::4773:a108/64 Scope:Link
inet6 addr: fe80::a00:164/64 Scope:Link
UP POINTOPOINT RUNNING NOARP MTU:1280 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:744 (744.0 b)
eth1 Link encap:Ethernet HWaddr 00:40:33:D3:65:0D
inet addr:71.115.161.8 Bcast:71.115.161.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:72388 errors:0 dropped:0 overruns:0 frame:0
TX packets:60670 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:80864755 (77.1 Mb) TX bytes:7129756 (6.7 Mb)
Interrupt:19 Base address:0xa000
ip6tables -L (No, not my normal ip6tables config, only flushed/and default Accepted for testing)
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
and to save lots and lots of text here, protocol 41 is default accepted.
And finally, to round things out, my gateway (2001:4978:f:a2::1) is not pingable from the online tools I've tried.
uschi02 down?
Shadow Hawkins on Monday, 10 March 2008 14:04:58
Well, it must have been down. It appears to be working now (no changes at my end).
uschi02 down?
Carmen Sandiego on Monday, 10 March 2008 16:41:07
It was probably acting up for a sec.
BTW thanks guys for getting uschi02 up running and stable a was just about to switch tunnels and subnets heck I already had requested them and they were approved was just to lazy to switch =P but again thanks.
uschi02 down?
When the PoP says 'up' it is fully working, thus your tunnel should work also, when it is configured correctly. uschi02 has been unstable, but the hardware/software combination problem has been resolved and it should now be running perfectly fine.
As for problems, we have this nice long Reporting Problems checklist on the contact page, if there is a problem, and you have checked that list, and it still is the case, don't hesitate to open a ticket and supply the information from that checklist, as then we can look at it. Please use it, as we really can't help out if users don't report problems that might slip through the detection system.
uschi02 down?
Shadow Hawkins on Monday, 10 March 2008 22:32:12
I also am unable to ping the tunnel endpoint on uschi02.
#######
####### AICCU Quick Connectivity Test
#######
####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (75.73.246.176)
### 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 75.73.246.176 (75.73.246.176) 56(84) bytes of data.
64 bytes from 75.73.246.176: icmp_seq=0 ttl=64 time=0.475 ms
64 bytes from 75.73.246.176: icmp_seq=1 ttl=64 time=0.292 ms
64 bytes from 75.73.246.176: icmp_seq=2 ttl=64 time=0.277 ms
--- 75.73.246.176 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.277/0.348/0.475/0.090 ms, pipe 2
######
Did this work? [Y/n] y
####### [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 216.14.98.22 (216.14.98.22) 56(84) bytes of data.
64 bytes from 216.14.98.22: icmp_seq=0 ttl=51 time=19.1 ms
64 bytes from 216.14.98.22: icmp_seq=1 ttl=51 time=24.0 ms
64 bytes from 216.14.98.22: icmp_seq=2 ttl=51 time=18.2 ms
--- 216.14.98.22 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 18.242/20.482/24.037/2.546 ms, pipe 2
######
Did this work? [Y/n] y
####### [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), 30 hops max, 38 byte packets
1 * * *
2 ge-9-2-ur02.hennepintown.mn.minn.comcast.net (68.85.164.77) 7.737 ms 7.009 ms *
3 te-2-1-ur01.shakopee.mn.minn.comcast.net (68.86.232.69) 7.568 ms 13.596 ms *
4 te-2-1-ur01.chaska.mn.minn.comcast.net (68.86.232.65) 9.125 ms 8.159 ms 8.033 ms
5 68.87.174.210 (68.87.174.210) 8.003 ms 8.638 ms 13.626 ms
6 te-9-4-ar01.roseville.mn.minn.comcast.net (68.86.91.142) 10.396 ms 10.448 ms 9.784 ms
7 COMCAST-IP-SERVICES-LLC-Chicago.TenGigabitEthernet2-3.ar5.CHI1.g (64.209.88.254) 19.738 ms 19.323 ms 20.168 ms
8 TenGigabitEthernet2-3.ar5.CHI1.gblx.net (64.209.88.253) 19.629 ms 19.566 ms 20.241 ms
9 te4-2-10G.ar2.CHI2.gblx.net (67.17.106.134) 20.395 ms 18.963 ms 17.946 ms
10 64.213.176.242 (64.213.176.242) 20.421 ms 18.438 ms 18.549 ms
11 your.org.ge2-5.br02.chc01.pccwbtn.net (63.218.5.38) 18.643 ms 22.185 ms 22.397 ms
12 sixxs.cx01.chi.bb.your.org (216.14.98.22) 19.680 ms 19.546 ms 21.241 ms
######
Did this work? [Y/n] y
###### [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
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=0 ttl=64 time=0.185 ms
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.146 ms
64 bytes from ::1: icmp_seq=2 ttl=64 time=0.153 ms
--- ::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.146/0.161/0.185/0.019 ms, pipe 2
######
Did this work? [Y/n] y
###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:4978:f:c7::2)
### This confirms that your tunnel is configured
### If it doesn't reply then check your interface and routing tables
PING 2001:4978:f:c7::2(2001:4978:f:c7::2) 56 data bytes
64 bytes from 2001:4978:f:c7::2: icmp_seq=0 ttl=64 time=0.224 ms
64 bytes from 2001:4978:f:c7::2: icmp_seq=1 ttl=64 time=0.177 ms
64 bytes from 2001:4978:f:c7::2: icmp_seq=2 ttl=64 time=0.166 ms
--- 2001:4978:f:c7::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.166/0.189/0.224/0.025 ms, pipe 2
######
Did this work? [Y/n] y
###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:4978:f:c7::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
PING 2001:4978:f:c7::1(2001:4978:f:c7::1) 56 data bytes
--- 2001:4978:f:c7::1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2000ms
######
Did this work? [Y/n] n
uschi02 down?
Which establishes that you can't ping6 the remote end of the tunnel.
Now if you would actually take the little bit of time and read the Contact pages Reporting Problems Checklist and include useful information, we might be able to look at it and see if your setup is simply broken or not.
uschi02 down?
Shadow Hawkins on Tuesday, 11 March 2008 03:04:22
I'm having the same issue as the previous poster (remote tunnel endpoint unreachable). I have two tunnels to uschi02, one static, one heartbeat. The static one works perfectly, the heartbeat one configures correctly, but no packets are transferred.
uschi02 down?
"Me too", "It is broken", but you mention "heartbeat", thus ever considered checking the clock on your computer if it is set correctly (including timezone of course)?
Please actually read, and use, the Reporting Problems Checklist, without it, noone can help...
Also, if you are really thinking that it is a PoP issue, and you are able to supply the information, then open a ticket on it.
uschi02 down?
Shadow Hawkins on Thursday, 13 March 2008 02:10:59
It wasn't a clock thing -- maybe an artifact of uschi02's reboot. Anyway, it fixed itself 10 minutes after I wrote that message with no intervention on my part and has been working perfectly since.
uschi02 down?
Shadow Hawkins on Friday, 14 March 2008 04:34:20
The connection is also working for me now as well.
|
![[ch]](/s/countries/ch.gif)
on Monday, 10 March 2008 18:22:35
Posting is only allowed when you are