|
Ticket ID: SIXXS #1260129 Ticket Status: User PoP: usqas01 - OCCAID Inc. (Ashburn, Virginia)
Issues passing v6 packets through usqas01
![[us]](/s/countries/us.gif) Shadow Hawkins on Tuesday, 17 November 2009 17:05:02
I'm having issues passing packets through the usqas01 tunnel. I have tried to connect from multiple machines at multiple locations. I can ping localhost, my end of the tunnel, but I cannot ping the other end of the tunnel.
When I connect from other locations, the heartbeat IP updates, but I cannot pass any packets through the sixxs interface. All firewalls are disabled for the purposes of these tests.
The tunnel worked successfully last week, but this week, no dice. What other information could I provide to assist in the troubleshooting process?
cwawak@ignignokt:~$ sudo aiccu start
sock_getline() : "200 SixXS TIC Service on noc.sixxs.net ready (http://www.sixxs.net)"
sock_printf() : "client TIC/draft-00 AICCU/2007.01.15-console-linux Linux/2.6.31-14-generic"
sock_getline() : "200 Client Identity accepted"
sock_printf() : "get unixtime"
sock_getline() : "200 1258472886"
sock_printf() : "starttls"
sock_getline() : "400 This service is not SSL enabled (yet)"
TIC Server does not support TLS but TLS is not required, continuing
sock_printf() : "username CWO2-SIXXS"
sock_getline() : "200 Choose your authentication challenge please"
sock_printf() : "challenge md5"
sock_getline() : "200 *****"
sock_printf() : "authenticate md5 *****"
sock_getline() : "200 Succesfully logged in using md5 as CWO2-SIXXS (Christopher Wawak) from *****"
sock_printf() : "tunnel list"
sock_getline() : "201 Listing tunnels"
sock_getline() : "T23995 ***** heartbeat usqas01"
sock_getline() : "202 <tunnel_id> <ipv6_endpoint> <ipv4_endpoint> <pop_name>"
sock_printf() : "tunnel show T23995"
sock_getline() : "201 Showing tunnel information for T23995"
sock_getline() : "TunnelId: T23995"
sock_getline() : "Type: 6in4-heartbeat"
sock_getline() : "IPv6 Endpoint: *****"
sock_getline() : "IPv6 POP: *****"
sock_getline() : "IPv6 PrefixLength: 64"
sock_getline() : "Tunnel MTU: 1280"
sock_getline() : "Tunnel Name: My First Tunnel"
sock_getline() : "POP Id: usqas01"
sock_getline() : "IPv4 Endpoint: heartbeat"
sock_getline() : "IPv4 POP: 66.117.47.228"
sock_getline() : "UserState: enabled"
sock_getline() : "AdminState: enabled"
sock_getline() : "Password: ****"
sock_getline() : "Heartbeat_Interval: 60"
sock_getline() : "202 Done"
Succesfully retrieved tunnel information for T23995
sock_printf() : "QUIT Down where we belong"
Tunnel Information for T23995:
POP Id : usqas01
IPv6 Local : *****/64
IPv6 Remote : *****/64
Tunnel Type : 6in4-heartbeat
Adminstate : enabled
Userstate : enabled
heartbeat_socket() - IPv4 : *****
[HB] HEARTBEAT TUNNEL ***** sender 1258472886 *****
[HB] HEARTBEAT TUNNEL ***** sender 1258472886 *****
####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (*****)
### 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 **** (****) 56(84) bytes of data.
64 bytes from *****: icmp_seq=1 ttl=64 time=0.026 ms
64 bytes from *****: icmp_seq=2 ttl=64 time=0.024 ms
64 bytes from *****: icmp_seq=3 ttl=64 time=0.021 ms
--- **** ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.021/0.023/0.026/0.006 ms
######
Did this work? [Y/n] y
####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (66.117.47.228)
### 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 66.117.47.228 (66.117.47.228) 56(84) bytes of data.
64 bytes from 66.117.47.228: icmp_seq=1 ttl=53 time=6.51 ms
64 bytes from 66.117.47.228: icmp_seq=2 ttl=53 time=7.40 ms
64 bytes from 66.117.47.228: icmp_seq=3 ttl=53 time=6.69 ms
--- 66.117.47.228 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 6.517/6.872/7.400/0.380 ms
####### [3/8] Traceroute to the PoP (66.117.47.228) 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 66.117.47.228 (66.117.47.228), 30 hops max, 60 byte packets
<first few hops snipped>
6 ae-33-89.car3.Washington1.Level3.net (4.68.17.133) 5.577 ms ae-13-69.car3.Washington1.Level3.net (4.68.17.5) 4.971 ms ae-23-79.car3.Washington1.Level3.net (4.68.17.69) 4.967 ms
7 CARPATHIA-H.car3.Washington1.Level3.net (4.79.169.26) 6.162 ms 6.108 ms 6.179 ms
8 209.222.144.164 (209.222.144.164) 6.492 ms 6.540 ms 6.479 ms
9 iad0-sixxs.hotnic.net (66.117.47.228) 7.016 ms 6.706 ms 7.082 ms
###### [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=1 ttl=64 time=0.030 ms
64 bytes from ::1: icmp_seq=2 ttl=64 time=0.025 ms
64 bytes from ::1: icmp_seq=3 ttl=64 time=0.032 ms
--- ::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.025/0.029/0.032/0.003 ms
###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (****)
### This confirms that your tunnel is configured
### If it doesn't reply then check your interface and routing tables
PING ****(****) 56 data bytes
64 bytes from ****: icmp_seq=1 ttl=64 time=0.034 ms
64 bytes from ****: icmp_seq=2 ttl=64 time=0.024 ms
64 bytes from ****: icmp_seq=3 ttl=64 time=0.029 ms
--- **** ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.024/0.029/0.034/0.004 ms
###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (*****)
### 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 ****(*****) 56 data bytes
--- ***** ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2007ms
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
{tunnel subnet}::/64 :: Un 256 0 1 sixxs
fe80::/64 :: U 256 0 0 eth1
fe80::/64 :: Un 256 0 0 sixxs
::/0 {remote endpoint ip} UG 1024 0 0 sixxs
::/0 :: !n -1 1 419 lo
::1/128 :: Un 0 1 62 lo
{local endpoint ip}/128 :: Un 0 1 0 lo
ff00::/8 :: U 256 0 0 eth1
ff00::/8 :: U 256 0 0 sixxs
::/0 :: !n -1 1 419 lo
Issues passing v6 packets through usqas01
Shadow Hawkins on Wednesday, 18 November 2009 19:39:30
Tried switching from heartbeat to ayiya, same behavior.
Issues passing v6 packets through usqas01
Shadow Hawkins on Tuesday, 24 November 2009 20:23:36
I am having the same exact problem with the same POP. I created a ticket about it a while ago, but I was told it wasn't having any problems.
Issues passing v6 packets through usqas01
Shadow Hawkins on Tuesday, 24 November 2009 20:28:15
I can confirm that I am having the exact same problem.
This is on a setup that has worked before with uschi02 (Which is down currently), so I am reluctant to say that there is something wrong on my setup. (Just changed the tunnel_id and the rest is the same).
State change: user
The state of this ticket has been changed to user
Issues passing v6 packets through usqas01
No heartbeat or ayiya packets are arriving on the PoP, then indeed it does not work. Check your firewall etc etc etc.
Issues passing v6 packets through usqas01
Shadow Hawkins on Tuesday, 08 December 2009 19:58:25
I have a question. How is it possible that the same configuration allows me to route ipv6 packets to uschi02 but not usqas01?
I am trying to figure out if there could be an actual issue on my side and which could it be. I have no firewall, almost everything else has the basic defaults that work with uschi02, but not with usqas01. So I am at loss here. what else could be involved, except usqas01?
Issues passing v6 packets through usqas01
Because they are different PoPs and thus require different tunnel parameters?
Issues passing v6 packets through usqas01
Shadow Hawkins on Wednesday, 09 December 2009 05:54:42
Right. But when using AYIYA it is autoconfigured, right? The only setting I have to change is tunnel_id. Is that correct? Or am I forgetting something else?
When I change the tunnel_id to the one I was assigned in usqas01, it doesn't work. With uschi02, does work.
What else should I change in my config? Everything else is set to:
# AICCU Configuration
# Login information
username user
password ***
# Interface names to use
# ipv6_interface is the name of the interface that will be used as a tunnel interface.
# On *BSD the ipv6_interface should be set to gifX (eg gif0) for proto-41 tunnels
# or tunX (eg tun0) for AYIYA tunnels.
ipv6_interface tun0
# The tunnel_id to use
# (only required when there are multiple tunnels in the list)
#uschi02
#tunnel_id ***
#usqas01
tunnel_id ***
# Be verbose?
verbose true
# Daemonize?
daemonize false
# Automatic Login and Tunnel activation?
automatic true
# Require TLS?
# When set to true, if TLS is not supported on the server
# the TIC transaction will fail.
# When set to false, it will try a starttls, when that is
# not supported it will continue.
# In any case if AICCU is build with TLS support it will
# try to do a 'starttls' to the TIC server to see if that
# is supported.
requiretls false
Issues passing v6 packets through usqas01
When I change the tunnel_id to the one I was assigned in usqas01, it doesn't work. With uschi02, does work.
Maybe because your configuration is wrong!?
Can't say anything about it without proper details. If you need help though, please try the forums. The ticket tracker is for reporting actual problems.
|
![[ch]](/s/countries/ch.gif)
on Friday, 04 December 2009 16:20:27
Posting is only allowed when you are