|
Ticket ID: SIXXS #632225 Ticket Status: User PoP:
Endpoint doesn't ping but tunnel is up (comcast <-> uschi01)
![[us]](/s/countries/us.gif) Carmen Sandiego on Wednesday, 19 December 2007 03:03:59
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:
I just received the notice that my tunnel has not been replying to pings, which is odd since I have not modified the configuration on that cisco router and the tunnel still appears to be working.
However, using the traceroute tools, I get no output for IPv6 traceroute to either the SixXS or my IPv6 side of the tunnel. Tracing to my IPv4 address gets this:
IPv4 traceroute
IPv4 traceroute from uschi01.sixxs.net @ OCCAID Inc., AS30071 to 76.20.141.48 :
Hop Node Loss% Sent Last Avg Best Worst StDev
1. 66.39.212.1 0.0% 5 0.7 0.6 0.5 0.7 0.1
505.ge0-0.cr1.ord1.us.occaid.net.
2. 66.225.203.129 0.0% 5 1.1 1.7 1.0 3.9 1.3
unknown.ord.scnet.net.
3. 216.104.32.195 0.0% 5 1.2 1.3 1.1 1.7 0.3
csw00.ord02.singlehop.net.
4. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0
Tracing from my router takes a strange path (through the UK?):
rtr1#traceroute 66.39.212.2
Type escape sequence to abort.
Tracing the route to uschi01.sixxs.net (66.39.212.2)
1 73.116.56.1 32 msec 12 msec 16 msec
2 ge-1-4-ur02.holt.mi.michigan.comcast.net (68.86.140.149) 12 msec 16 msec 12 msec
3 te-9-3-ur01.holt.mi.michigan.comcast.net (68.86.140.74) 36 msec 12 msec 16 msec
4 te-8-1-ar01.holt.mi.michigan.comcast.net (68.86.140.78) 12 msec 12 msec 16 msec
5 68.85.235.206 20 msec 16 msec 20 msec
6 68.86.90.110 20 msec 24 msec 24 msec
7 pos-0-2-0-0-cr01.cleveland.oh.ibone.comcast.net (68.86.85.33) 32 msec 28 msec 24 msec
8 pos-0-7-0-0-cr01.pittsburgh.pa.ibone.comcast.net (68.86.85.46) 32 msec 32 msec 28 msec
9 * *
te-0-4-0-7-cr01.mclean.va.ibone.comcast.net (68.86.84.93) 36 msec
10 te-1-1-pr01.ashburn.va.ibone.comcast.net (68.86.84.94) 36 msec 36 msec 36 msec
11 xe-3-1-0.was11.ip.tiscali.net (213.200.84.117) 36 msec 36 msec 32 msec
12 so-6-1-0.lon11.ip.tiscali.net (213.200.80.26) 116 msec 112 msec 116 msec
13 crt1-the-gi0-2.router.uk.catalyst2.net (213.200.77.6) 112 msec 128 msec 112 msec
14 * * *
15 * * *
16 dontmatter.midphase.com (205.234.148.199) 120 msec 116 msec 120 msec
17 uschi01.sixxs.net (66.39.212.2) 120 msec 120 msec 116 msec
From a box on another ASN (2914), I can ping my IPv4 endpoint just fine (it looks like pings to 66.39.212.2 are perhaps filtered, but from my other machine the traceroute also appears to go across the atlantic and then back again).
Endpoint doesn't ping but tunnel is up (comcast <-> uschi01)
Carmen Sandiego on Wednesday, 19 December 2007 04:00:50
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:
I too just received an e-email about my tunnel not responding to pings; I also run a Cisco router (1811) and haven't changed any configuration related to ipv6 or the tunnel interface. As with the above post, the tunnel seems to be working despite receiving the "Tunnel downtime" e-mail. I am NOT on Comcast, however, but rather a Purdue University (AS17). The ID of the tunnel in question is T10689.
Below are the traceroutes using the Sixxs provided traceroute utilities:
The IPv6 traceroute shows no results, just as the above poster mentioned.
--------------------------------------------------------------------------------
IPv4 traceroute
IPv4 traceroute from uschi01.sixxs.net @ OCCAID Inc., AS30071 to 128.211.207.90 :
Hop Node Loss% Sent Last Avg Best Worst StDev
1. 66.39.212.1 0.0% 5 0.6 0.6 0.5 0.7 0.1
505.ge0-0.cr1.ord1.us.occaid.net.
2. 66.225.203.129 0.0% 5 1.1 1.2 1.1 1.3 0.1
unknown.ord.scnet.net.
3. 216.104.32.195 0.0% 5 1.1 1.1 1.1 1.2 0.0
csw00.ord02.singlehop.net.
4. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0
--------------------------------------------------------------------------------
Here is the traceroute from the router to the PoP:
dorm1811#traceroute 66.39.212.2
Type escape sequence to abort.
Tracing the route to uschi01.sixxs.net (66.39.212.2)
1 hill-c45a-c4507-01-207b.tcom.purdue.edu (128.211.207.1) 0 msec 4 msec 0 msec
2 erht-5b-c6509-01-4022.tcom.purdue.edu (172.19.252.1) 0 msec 0 msec 4 msec
3 tel-210-c6509-01-4081.tcom.purdue.edu (192.31.0.101) 4 msec 0 msec 0 msec
4 tel-210-m10i-01-campus.tcom.purdue.edu (192.5.40.54) 8 msec 0 msec 4 msec
5 gigapop-ctc-inet-t640.tcom.purdue.edu (192.5.40.179) 0 msec 4 msec 4 msec
6 ge-2-0-0.2045.rtr.chic.net.internet2.edu (149.165.254.7) 28 msec 8 msec 8 msec
7 ge3-32-1000M.ar4.LON3.gblx.net (64.208.110.189) 8 msec 8 msec 8 msec
8 nlayer.ge-7-0-0.ar1.DCA3.gblx.net (208.51.117.126) 40 msec 40 msec 40 msec
9 * * *
10 * * *
11 dontmatter.midphase.com (205.234.148.199) 44 msec 44 msec 44 msec
12 uschi01.sixxs.net (66.39.212.2) 48 msec 44 msec 44 msec
Endpoint doesn't ping but tunnel is up (comcast <-> uschi01)
Carmen Sandiego on Wednesday, 19 December 2007 23:22:45
I should have also included my tunnel ID: 11752
I also looked through some logs of my offsite monitoring of my cable modem connection, and it doesn't appear to be dropping packets or experiencing downtime.
My tunnel is working, though (I am submitting this over the tunnel).
Thanks for your time and assistance!
Endpoint doesn't ping but tunnel is up (comcast <-> uschi01)
You are both showing IPv4 traceroutes, while we perform IPv6 ICMP Echo/Reply tests from the PoP.
Endpoint doesn't ping but tunnel is up (comcast <-> uschi01)
Carmen Sandiego on Thursday, 20 December 2007 10:18:10
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:
Anyway, it seems to have come back after 2007-12-19 01:15:02 CET (the "Last Dead" time) without any intervention on my end. But just to clarify...
--------------------------------------------------------------------------------
this was what the SixXS traceroute utility gave me when I tried it last evening:
IPv6 traceroute
IPv6 traceroute from uschi01.sixxs.net @ OCCAID Inc., AS30071 to 2001:4830:1500:8d::2 :
Hop Node Loss% Sent Last Avg Best Worst StDev ASN Organisation
When the ASN of a prefix is blank then the prefix doesn't have an route6 entry in the registries.
(It still gives me the same output at present, actually).
--------------------------------------------------------------------------------
This was the traceroute from my router to the PoP:
dorm1811#trace 2001:4830:1500:8d::1
Type escape sequence to abort.
Tracing the route to gw-142.chi-01.us.sixxs.net (2001:4830:1500:8D::1)
1 gw-142.chi-01.us.sixxs.net (2001:4830:1500:8D::1) 48 msec 64 msec 44 msec
--------------------------------------------------------------------------------
This was the ping test I tried last evening:
dorm1811#ping 2001:4830:1500:8d::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:4830:1500:8D::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/44/48 ms
--------------------------------------------------------------------------------
This is the ping test I am trying right now:
dorm1811#ping 2001:4830:1500:8d::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:4830:1500:8D::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/44/44 ms
--------------------------------------------------------------------------------
I'm not sure why the PoP thought the tunnel was down when it was actually working properly. Any idea why this might have been so? Thank you much.
Endpoint doesn't ping but tunnel is up (comcast <-> uschi01)
You might for once actually try and read the "Reporting Problems" list instead of just stating "it is broken".
As for a good FAQ tip, see My tunnel goes down after some idletime. My tunnelendpoint also is a NAT/Connection Tracker
Endpoint doesn't ping but tunnel is up (comcast <-> uschi01)
Carmen Sandiego on Thursday, 20 December 2007 17:16:25
As I mentioned, the IPv6 Traceroute tool (from the POP to me) doesn't display any output.
I didn't think an IPv6 trace from my tunnel endpoint to the pop endpoint would be interesting (or a ping from my router to the endpoint) - both are fine and were working.
For completeness, here is the output:
rtr1#ping 2001:4830:1500:CA::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:4830:1500:CA::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 116/117/120 ms
rtr1#traceroute 2001:4830:1500:CA::1
Type escape sequence to abort.
Tracing the route to gw-203.chi-01.us.sixxs.net (2001:4830:1500:CA::1)
1 gw-203.chi-01.us.sixxs.net (2001:4830:1500:CA::1) 120 msec 120 msec 120 msec
rtr1#
Anyway, the problem seems to have corrected itself.
Endpoint doesn't ping but tunnel is up (comcast <-> uschi01)
The problem hasn't been resolved, you just don't notice it now as you are generating traffic on the tunnel and thus causing the connection tracking entries to not expire.
As mentioned in the previous comment: As for a good FAQ tip, see My tunnel goes down after some idletime. My tunnelendpoint also is a NAT/Connection Tracker
Endpoint doesn't ping but tunnel is up (comcast <-> uschi01)
Carmen Sandiego on Friday, 21 December 2007 16:54:32
It would be nice if an IOS configuration example were added to that FAQ.
I had read it, but assumed (incorrectly I guess) that it didn't apply to a static tunnel configuration on a cisco router.
Thanks for your time and your help!
Endpoint doesn't ping but tunnel is up (comcast <-> uschi01)
It applies to most/all devices who are doing connection tracking.
You might notice the text stating:
"If your platform is not listed here check the manual of the platform for a similar solution and contact the vendor of your platform when in doubt."
State change: user
The state of this ticket has been changed to user
|
![[ch]](/s/countries/ch.gif)
on Thursday, 20 December 2007 00:53:59
Posting is only allowed when you are