• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

Outbound IPv6 Trace Routes

Started by avongauss, June 05, 2008, 05:35:17 PM

Previous topic - Next topic


I know this is probably something on my side, but for the life of me I can't seem to figure it out and would appreciate any thoughts.  I recently switched from the NY tunnel broker to the new Miami tunnel broker and everything is working great except for outbound IPv6 trace routes.  Using the new Miami tunnel, when I do an outbound trace route I do not receive back the intermediary hosts, just the final destination.  What seems odd to me is that I am able to trace route to my host through the Miami tunnel as shown in the last trace route.  I've tried disabling all iptable rules on the Linux host, but it didn't make a difference.  At this point I can't say for sure if this was occurring using the NYC tunnel, I am assuming during the change over I forgot to reconfigure something on the host, but I can't seem to figure it out at the moment.  Again, any thoughts are welcome.  Thanks!

Example from Miami to HE:

traceroute to ipv6.tunnelbroker.net (2001:470:0:63::2), 30 hops max, 40 byte packets
1  * * *
2  * * *
3  * * *
4  * * *
5  * * *
tunnelbroker.com (2001:470:0:63::2)  276.364 ms  173.176 ms  173.242 ms

Example from Newark to HE:

traceroute to ipv6.tunnelbroker.net (2001:470:0:63::2), 30 hops max, 40 byte packets
avongaussnj.tunnel.tserv4.nyc4.ipv6.he.net (2001:470:1f06:61d::1)  11.226 ms  13.153 ms  17.455 ms
gige-g3-8.core1.nyc4.he.net (2001:470:0:5d::1)  17.560 ms  17.553 ms  21.242 ms
10gigabitethernet3-1.core1.sjc2.he.net (2001:470:0:33::1)  98.529 ms  98.532 ms  98.527 ms
10gigabitethernet1-1.core1.fmt1.he.net (2001:470:0:2f::1)  98.582 ms  98.577 ms  98.608 ms
tunnelbroker.com (2001:470:0:63::2)  98.510 ms  98.504 ms  98.498 ms

Example from Newark to Miami:

traceroute to 2001:470:5:3::5 (2001:470:5:3::5), 30 hops max, 40 byte packets
avongaussnj.tunnel.tserv4.nyc4.ipv6.he.net (2001:470:1f06:61d::1)  14.380 ms  16.899 ms  18.333 ms
gige-g3-8.core1.nyc4.he.net (2001:470:0:5d::1)  18.825 ms  18.822 ms  20.609 ms
10gigabitethernet2-3.core1.ash1.he.net (2001:470:0:36::1)  24.599 ms  24.594 ms  24.621 ms
10gigabitethernet1-1.core1.mia1.he.net (2001:470:0:4b::2)  49.885 ms  49.879 ms  49.912 ms
5  2001:470:0:8c::2 (2001:470:0:8c::2)  49.907 ms  49.900 ms  49.934 ms
6  2001:470:5:3::5 (2001:470:5:3::5)  118.919 ms  107.232 ms  111.479 ms


Must be on your machine because a trace from the Miami tunnel-server to your side of a NYC tunnel reports every hop:

traceroute6 to 2001:470:1f06:61d::2 (2001:470:1f06:61d::2) from 2001:470:0:8c::2, 64 hops max, 12 byte packets
1  2001:470:0:8c::1  0.325 ms  0.254 ms  0.139 ms
2  10gigabitethernet5-4.core1.ash1.he.net  34.212 ms  28.057 ms  28.072 ms
3  10gigabitethernet1-2.core1.nyc4.he.net  34.213 ms  34.934 ms  34.215 ms
4  1g-bge0.tserv4.nyc4.ipv6.he.net  35.968 ms  35.960 ms  36.114 ms
5  avongaussnj-pt.tunnel.tserv4.nyc4.ipv6.he.net  37.684 ms  57.456 ms  45.183 ms


Thank you both for responding.  I definitely agree it is probably something on my side, I've just been having a dandy of a time trying to figure out what would allow inbound but not allow outbound other than iptables.  I've tried reconnecting to the NYC broker with the same results and I did see the thread on TTL affecting trace routes.  The TTL in the stanza has always been set, but I did try the command referenced in the thread with the same results. 


Not an answer, but a little more information in case someone else runs in to this situation.  It would seem that the default configuration of K/Ubuntu 8.04 is the source of this issue.  The host in question was upgraded via fresh install from Ubuntu 7.10 to Ubuntu 8.04 about a month before the tunnel was switched and I probably did not try to do a trace route from the host during that period to realize it was no longer working.  I have since restaged the host to openSuSE for other reasons and it does not exhibit the problem, however another workstation that is running Kubuntu 8.04 is still exhibiting the problem.