SixXS::Sunset 2017-06-06

Ticket ID: SIXXS #580717
Ticket Status: User

PoP: usbos01 - OCCAID Inc. (Boston, Massachusetts)

Tunnel T12678 non-functional
[ca] Shadow Hawkins on Friday, 21 September 2007 04:53:21
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: For the last few days; I have not been able to maintain my T12678 Tunnel reliably; however the same system where AICCU has been reconfigured to my T12680 Tunnel is able to work as expected; I also am not able to connect my T12678 tunnel on the "known-good" system (which has no problems with the T12680 tunnel). This is on CentOS 5 with current updates; running a rebuilt version of aiccu from the fedora 7 repo's (src rpm rebuilt with 'rpmbuild --rebuild'. ----------------- T12678 autotest ------------------------------------- leetrum@nullptr:~$ cat /tmp/t12678.log ####### ####### AICCU Quick Connectivity Test ####### ####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (206.248.171.173) ### 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 206.248.171.173 (206.248.171.173) 56(84) bytes of data. 64 bytes from 206.248.171.173: icmp_seq=1 ttl=64 time=1.53 ms 64 bytes from 206.248.171.173: icmp_seq=2 ttl=64 time=1.52 ms 64 bytes from 206.248.171.173: icmp_seq=3 ttl=64 time=1.37 ms --- 206.248.171.173 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 1.378/1.480/1.535/0.072 ms ###### ####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (216.93.250.26) ### 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.93.250.26 (216.93.250.26) 56(84) bytes of data. 64 bytes from 216.93.250.26: icmp_seq=1 ttl=52 time=26.6 ms 64 bytes from 216.93.250.26: icmp_seq=2 ttl=52 time=26.9 ms 64 bytes from 216.93.250.26: icmp_seq=3 ttl=52 time=25.0 ms --- 216.93.250.26 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 25.074/26.214/26.949/0.838 ms ###### ####### [3/8] Traceroute to the PoP (216.93.250.26) 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 sh: traceroute: command not found ###### ###### [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.043 ms 64 bytes from ::1: icmp_seq=2 ttl=64 time=0.046 ms 64 bytes from ::1: icmp_seq=3 ttl=64 time=0.047 ms --- ::1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.043/0.045/0.047/0.005 ms ###### ###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:4830:1100:42::2) ### This confirms that your tunnel is configured ### If it doesn't reply then check your interface and routing tables PING 2001:4830:1100:42::2(2001:4830:1100:42::2) 56 data bytes 64 bytes from 2001:4830:1100:42::2: icmp_seq=1 ttl=64 time=0.038 ms 64 bytes from 2001:4830:1100:42::2: icmp_seq=2 ttl=64 time=0.062 ms 64 bytes from 2001:4830:1100:42::2: icmp_seq=3 ttl=64 time=0.067 ms --- 2001:4830:1100:42::2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 0.038/0.055/0.067/0.015 ms ###### ###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:4830:1100:42::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:4830:1100:42::1(2001:4830:1100:42::1) 56 data bytes From 2001:4830:1100:42::2 icmp_seq=1 Destination unreachable: Address unreachable From 2001:4830:1100:42::2 icmp_seq=2 Destination unreachable: Address unreachable From 2001:4830:1100:42::2 icmp_seq=3 Destination unreachable: Address unreachable --- 2001:4830:1100:42::1 ping statistics --- 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 1999ms ###### ###### [7/8] Traceroute6 to the central SixXS machine (noc.sixxs.net) ### This confirms that you can reach the central machine of SixXS ### If that one is reachable you should be able to reach most IPv6 destinations ### Also check http://www.sixxs.net/ipv6calc/ which should show an IPv6 connection ### If your browser supports IPv6 and uses it of course. traceroute to noc.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c) from 2001:4830:1100:42::2, 30 hops max, 24 byte packets 1 cl-67.bos-01.us.sixxs.net (2001:4830:1100:42::2) 0.066 ms !H 0.038 ms !H 0.029 ms !H ###### ###### [8/8] Traceroute6 to (www.kame.net) ### This confirms that you can reach a Japanese IPv6 destination ### If that one is reachable you should be able to reach most IPv6 destinations ### You should also check http://www.kame.net which should display ### a animated kame (turtle), of course only when your browser supports and uses IPv6 traceroute to www.kame.net (2001:200:0:8002:203:47ff:fea5:3085) from 2001:4830:1100:42::2, 30 hops max, 24 byte packets 1 cl-67.bos-01.us.sixxs.net (2001:4830:1100:42::2) 0.054 ms !H 0.037 ms !H 0.028 ms !H ###### ###### ACCU Quick Connectivity Test (done) ### Either the above all works and gives no problems ### or it shows you where what goes wrong ### Check the SixXS FAQ (http://www.sixxs.net/faq/ ### for more information and possible solutions or hints ### Don't forget to check the Forums (http://www.sixxs.net/forum/) ### for a helping hand. ### Passing the output of 'aiccu autotest >aiccu.log' is a good idea. leetrum@nullptr:~$ route -A inet6 -n Kernel IPv6 routing table Destination Next Hop Flags Metric Ref Use Iface ::1/128 :: U 0 36 1 lo 2001:4830:1100:42::2/128 :: U 0 4 1 lo 2001:4830:1100:42::/64 :: U 256 1 0 sixxs 2001:4830:111a:69::/64 :: UA 256 26 0 eth0 fe80::cef8:abad/128 :: U 0 0 1 lo fe80::218:8bff:fede:5a2f/128 :: U 0 0 1 lo fe80::21c:26ff:fe0f:68eb/128 :: U 0 50 1 lo fe80::84e9:90ff:fe3a:c477/128 :: U 0 0 1 lo fe80::b8fa:94ff:fe7a:b6b4/128 :: U 0 0 1 lo fe80::/64 :: U 256 0 0 tap0 fe80::/64 :: U 256 0 0 tap1 fe80::/64 :: U 256 0 0 br0 fe80::/64 :: U 256 0 0 eth0 fe80::/64 :: U 256 0 0 sixxs ff00::/8 :: U 256 0 0 tap0 ff00::/8 :: U 256 0 0 tap1 ff00::/8 :: U 256 0 0 br0 ff00::/8 :: U 256 0 0 eth0 ff00::/8 :: U 256 0 0 sixxs ::/0 2001:4830:1100:42::1 UG 1024 3 0 sixxs -------------------------- snip ----------------------------------------- ---------------------- T12680 test -------------------------------------- leetrum@nullptr:~$ cat /tmp/t12680.log ####### ####### AICCU Quick Connectivity Test ####### ####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.69.155) ### 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 192.168.69.155 (192.168.69.155) 56(84) bytes of data. 64 bytes from 192.168.69.155: icmp_seq=1 ttl=64 time=0.035 ms 64 bytes from 192.168.69.155: icmp_seq=2 ttl=64 time=0.033 ms 64 bytes from 192.168.69.155: icmp_seq=3 ttl=64 time=0.040 ms --- 192.168.69.155 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.033/0.036/0.040/0.003 ms ###### ####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (216.93.250.26) ### 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.93.250.26 (216.93.250.26) 56(84) bytes of data. 64 bytes from 216.93.250.26: icmp_seq=1 ttl=52 time=26.4 ms 64 bytes from 216.93.250.26: icmp_seq=2 ttl=52 time=28.1 ms 64 bytes from 216.93.250.26: icmp_seq=3 ttl=52 time=24.2 ms --- 216.93.250.26 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 24.211/26.277/28.139/1.615 ms ###### ####### [3/8] Traceroute to the PoP (216.93.250.26) 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 sh: traceroute: command not found ###### ###### [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.043 ms 64 bytes from ::1: icmp_seq=2 ttl=64 time=0.048 ms 64 bytes from ::1: icmp_seq=3 ttl=64 time=0.044 ms --- ::1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.043/0.045/0.048/0.002 ms ###### ###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:4830:1100:43::2) ### This confirms that your tunnel is configured ### If it doesn't reply then check your interface and routing tables PING 2001:4830:1100:43::2(2001:4830:1100:43::2) 56 data bytes 64 bytes from 2001:4830:1100:43::2: icmp_seq=1 ttl=64 time=0.034 ms 64 bytes from 2001:4830:1100:43::2: icmp_seq=2 ttl=64 time=0.051 ms 64 bytes from 2001:4830:1100:43::2: icmp_seq=3 ttl=64 time=0.058 ms --- 2001:4830:1100:43::2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.034/0.047/0.058/0.012 ms ###### ###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:4830:1100:43::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:4830:1100:43::1(2001:4830:1100:43::1) 56 data bytes 64 bytes from 2001:4830:1100:43::1: icmp_seq=1 ttl=64 time=28.8 ms 64 bytes from 2001:4830:1100:43::1: icmp_seq=2 ttl=64 time=29.2 ms 64 bytes from 2001:4830:1100:43::1: icmp_seq=3 ttl=64 time=28.3 ms --- 2001:4830:1100:43::1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 28.314/28.820/29.255/0.411 ms ###### ###### [7/8] Traceroute6 to the central SixXS machine (noc.sixxs.net) ### This confirms that you can reach the central machine of SixXS ### If that one is reachable you should be able to reach most IPv6 destinations ### Also check http://www.sixxs.net/ipv6calc/ which should show an IPv6 connection ### If your browser supports IPv6 and uses it of course. traceroute to noc.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c) from 2001:4830:1100:43::2, 30 hops max, 24 byte packets 1 gw-68.bos-01.us.sixxs.net (2001:4830:1100:43::1) 28.907 ms 29.659 ms 28.459 ms 2 bbr01-ve402.bstn01.occaid.net (2001:4830:e1:b::1) 28.729 ms 29.452 ms 28.126 ms 3 bbr01-p1-0.whkn01.occaid.net (2001:4830:ff:15c4::1) 35.197 ms 35.38 ms 35.379 ms 4 bbr01-p2-0.lndn01.occaid.net (2001:4830:fe:1010::1) 106.633 ms 105.129 ms 106.34 ms 5 2001:7f8:4::2331:1 (2001:7f8:4::2331:1) 106.19 ms 104.981 ms 103.627 ms 6 ge-3-1-44.bb2.bru1.be.gbxs.net (2a01:300:30:7::1) 113.206 ms 110.041 ms 112.094 ms 7 ge-3-5.bb2.bru1.be.gbxs.net (2a01:300:30::2) 115.732 ms 111.544 ms 116.65 ms 8 so-7-0-0.bb1.ams3.nl.gbxs.net (2a01:300:30:6::2) 115.219 ms 116.469 ms 123.459 ms 9 ams-ix2.ipv6.concepts.nl (2001:7f8:1::a501:2871:2) 116.427 ms 122.992 ms 202.411 ms 10 2001:838:0:13::1 (2001:838:0:13::1) 176.017 ms 126.787 ms 117.162 ms 11 2001:838:0:12::2 (2001:838:0:12::2) 125.928 ms 120.873 ms 119.921 ms 12 noc.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c) 123.497 ms 123.782 ms 119.276 ms ###### ###### [8/8] Traceroute6 to (www.kame.net) ### This confirms that you can reach a Japanese IPv6 destination ### If that one is reachable you should be able to reach most IPv6 destinations ### You should also check http://www.kame.net which should display ### a animated kame (turtle), of course only when your browser supports and uses IPv6 traceroute to www.kame.net (2001:200:0:8002:203:47ff:fea5:3085) from 2001:4830:1100:43::2, 30 hops max, 24 byte packets 1 gw-68.bos-01.us.sixxs.net (2001:4830:1100:43::1) 28.16 ms 30.093 ms 28.948 ms 2 bbr01-ve402.bstn01.occaid.net (2001:4830:e1:b::1) 28.763 ms 29.132 ms 28.33 ms 3 bbr01-p1-0.nwrk01.occaid.net (2001:4830:ff:15c4::1) 35.719 ms 32.004 ms 36.504 ms 4 bbr01-g1-0.asbn01.occaid.net (2001:4830:ff:f150::2) 43.115 ms 42.003 ms 41.722 ms 5 xe-0.equinix.asbnva01.us.bb.gin.ntt.net (2001:504:0:2::2914:1) 40.267 ms 39.443 ms 43.444 ms 6 ae-0.r20.asbnva01.us.bb.gin.ntt.net (2001:418:0:2000::8d) 40.507 ms 43.801 ms 40.155 ms 7 as-0.r20.snjsca04.us.bb.gin.ntt.net (2001:418:0:2000::1de) 121.583 ms 118.53 ms 123.798 ms 8 as-2.r20.tokyjp01.jp.bb.gin.ntt.net (2001:218:0:2000::ce) 239.995 ms 239.971 ms 239.954 ms 9 xe-3-2.a15.tokyjp01.jp.ra.gin.ntt.net (2001:218:0:6000::10e) 223.83 ms 222.313 ms 219.921 ms 10 ge-8-2.a15.tokyjp01.jp.ra.gin.ntt.net (2001:218:2000:5000::82) 231.91 ms 229.597 ms 228.122 ms 11 ve-4.nec2.yagami.wide.ad.jp (2001:200:0:1c04:230:13ff:feae:5b) 232.003 ms 231.729 ms * 12 lo0.alaxala1.k2.wide.ad.jp (2001:200:0:4800::7800:1) 226.124 ms 227.778 ms 220.174 ms 13 orange.kame.net (2001:200:0:8002:203:47ff:fea5:3085) 223.783 ms 224.152 ms 224.068 ms ###### ###### ACCU Quick Connectivity Test (done) ### Either the above all works and gives no problems ### or it shows you where what goes wrong ### Check the SixXS FAQ (http://www.sixxs.net/faq/ ### for more information and possible solutions or hints ### Don't forget to check the Forums (http://www.sixxs.net/forum/) ### for a helping hand. ### Passing the output of 'aiccu autotest >aiccu.log' is a good idea. leetrum@nullptr:~$ leetrum@nullptr:~$ route -A inet6 -n Kernel IPv6 routing table Destination Next Hop Flags Metric Ref Use Iface ::1/128 :: U 0 36 1 lo 2001:4830:1100:43::2/128 :: U 0 2 1 lo 2001:4830:1100:43::/64 :: U 256 1 0 sixxs 2001:4830:111a:69::/64 :: UA 256 26 0 eth0 fe80::218:8bff:fede:5a2f/128 :: U 0 0 1 lo fe80::21c:26ff:fe0f:68eb/128 :: U 0 50 1 lo fe80::4830:1100:43:2/128 :: U 0 0 1 lo fe80::84e9:90ff:fe3a:c477/128 :: U 0 0 1 lo fe80::b8fa:94ff:fe7a:b6b4/128 :: U 0 0 1 lo fe80::/64 :: U 256 0 0 tap0 fe80::/64 :: U 256 0 0 tap1 fe80::/64 :: U 256 0 0 br0 fe80::/64 :: U 256 0 0 eth0 fe80::/64 :: U 256 0 0 sixxs ff00::/8 :: U 256 0 0 tap0 ff00::/8 :: U 256 0 0 tap1 ff00::/8 :: U 256 0 0 br0 ff00::/8 :: U 256 0 0 eth0 ff00::/8 :: U 256 0 0 sixxs ::/0 2001:4830:1100:43::1 UG 1024 3 0 sixxs ------------------------------ snip ------------------------------------- ----------------------------- aiccu.conf --------------------------------- # Under control from debconf, please use 'dpkg-reconfigure aiccu' to reconfigure username <removed> password <removed> #protocol tic #server tic.sixxs.net tunnel_id T12680 #tunnel_id T12678 # AICCU Configuration # Login information (defaults: none) #username <your nichandle/username> #password <your password> # Protocol and server to use for setting up the tunnel (defaults: none) #protocol <tic|tsp|l2tp> #server <server to use> # Interface names to use (default: aiccu) # 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 sixxs # The tunnel_id to use (default: none) # (only required when there are multiple tunnels in the list) #tunnel_id Txxxx # Be verbose? (default: false) verbose false # Daemonize? (default: true) # Set to false if you want to see any output # When true output goes to syslog # # WARNING: never run AICCU from DaemonTools or a similar automated # 'restart' tool/script. When AICCU does not start, it has a reason # not to start which it gives on either the stdout or in the (sys)log # file. The TIC server *will* automatically disable accounts which # are detected to run in this mode. # daemonize true # 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 # PID File #pidfile /var/run/aiccu.pid # Add a default route (default: true) #defaultroute true # Script to run after setting up the interfaces (default: none) #setupscript /usr/local/etc/aiccu-subnets.sh # Make heartbeats (default true) # In general you don't want to turn this off # Of course only applies to AYIYA and heartbeat tunnels not to static ones makebeats true # Don't configure anything (default: false) #noconfigure true # Behind NAT (default: false) # Notify the user that a NAT-kind network is detected behindnat true # Local IPv4 Override (default: none) # Overrides the IPv4 parameter received from TIC # This allows one to configure a NAT into "DMZ" mode and then # forwarding the proto-41 packets to an internal host. # # This is only needed for static proto-41 tunnels! # AYIYA and heartbeat tunnels don't require this. #local_ipv4_override ---------------------- snip ----------------------------------- Thank-you in advance for you assistance! - Shawn
Tunnel T12678 non-functional
[ch] Jeroen Massar SixXS Staff on Friday, 21 September 2007 11:39:51
The working tunnel is AYIYA based, as such it uses UDP and heartbeats which makes it work through most firewalls and NATs. The non-working tunnel is proto-41 and you might have a firewall on your own machine or between you and the PoP which is blocking packets for you.
Tunnel T12678 non-functional
[ca] Shadow Hawkins on Friday, 21 September 2007 16:02:57
Hi Jeroen, The non-working tunnel was AYIYA based; I changed it to attempt to remedy the problem; if I change it back I am left with 1 credit (and no way to change it again); do you recommend I change it back and re-test? Thanks! - Shawn
Tunnel T12678 non-functional
[ca] Shadow Hawkins on Friday, 21 September 2007 16:05:20
I should further mention that I have explored the firewall issue around protocol 41 (even going as far as changing my firewall to a linux-based firewall so that I can explicitly forward protocol-41 packets to the host in question); I do have a log target that logs everything just before it hits the policy drop target; and don't see anything around protocol-41 being logged... Cheers, Shawn
Tunnel T12678 non-functional
[ca] Shadow Hawkins on Saturday, 22 September 2007 02:29:08
Hi Again, After changing the tunnel type back to ayiya it seems to be working again; after some research it seems that I may have started to muck with this while there was a problem with OCCAID; and compounded things... Thank you for all of your help, Cheers, Shawn
Tunnel T12678 non-functional
[ch] Jeroen Massar SixXS Staff on Saturday, 22 September 2007 02:58:35
If you explicitly have to forward protocol-41 then you are doing some NAT circumvention and that clearly can be causing issues.
State change: user Locked
[ch] Jeroen Massar SixXS Staff on Saturday, 22 September 2007 02:57:07
Message is Locked
The state of this ticket has been changed to user

Please note Posting is only allowed when you are logged in.

Static Sunset Edition of SixXS
©2001-2017 SixXS - IPv6 Deployment & Tunnel Broker