Modifying test script for AICCU (Windows 7-specific)
Shadow Hawkins on Saturday, 31 October 2009 05:44:02
I'm trying to troubleshoot my AYIYA tunnel in Windows 7; however, certain commands that used to work in Windows Vista were changed in 7 (specifically, tracert6 was replaced by tracert). I am still having issues routing traffic to the tunnel.
The current test log (aiccu.log) follows.
Tunnel Information for T23765:
PoP Id : usqas01
IPv6 Local : 2001:4830:1600:20f::2/64
IPv6 Remote : 2001:4830:1600:20f::1/64
Tunnel Type : ayiya
Adminstate : enabled
Userstate : enabled
Name : My First Tunnel
#######
####### AICCU Quick Connectivity Test
#######
####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.1.102)
### 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
Pinging 192.168.1.102 with 32 bytes of data:
Reply from 192.168.1.102: bytes=32 time<1ms TTL=128
Reply from 192.168.1.102: bytes=32 time<1ms TTL=128
Reply from 192.168.1.102: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.1.102:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
######
####### [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
Pinging 66.117.47.228 with 32 bytes of data:
Reply from 66.117.47.228: bytes=32 time=13ms TTL=55
Reply from 66.117.47.228: bytes=32 time=11ms TTL=55
Reply from 66.117.47.228: bytes=32 time=17ms TTL=55
Ping statistics for 66.117.47.228:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 11ms, Maximum = 17ms, Average = 13ms
######
####### [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
Tracing route to iad0-sixxs.hotnic.net [66.117.47.228]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms SAITCLEWRT54GS [192.168.1.1]
2 * * * Request timed out.
3 8 ms 9 ms 9 ms 68.85.80.249
4 8 ms 8 ms 9 ms 68.85.67.149
5 14 ms 9 ms 16 ms pos-1-7-0-0-cr01.mclean.va.ibone.comcast.net [68.86.90.37]
6 15 ms 11 ms 18 ms ge-5-1-125.ipcolo1.Washington1.Level3.net [63.210.62.157]
7 10 ms 11 ms 11 ms ae-33-89.car3.Washington1.Level3.net [4.68.17.133]
8 9 ms 12 ms 25 ms CARPATHIA-H.car3.Washington1.Level3.net [4.79.169.26]
9 10 ms 12 ms 11 ms 209.222.144.164
10 17 ms 20 ms 15 ms iad0-sixxs.hotnic.net [66.117.47.228]
Trace complete.
######
###### [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
Pinging ::1 with 32 bytes of data:
Reply from ::1: time<1ms
Reply from ::1: time<1ms
Reply from ::1: time<1ms
Ping statistics for ::1:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
######
###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:4830:1600:20f::2)
### This confirms that your tunnel is configured
### If it doesn't reply then check your interface and routing tables
Pinging 2001:4830:1600:20f::2 with 32 bytes of data:
Reply from 2001:4830:1600:20f::2: time<1ms
Reply from 2001:4830:1600:20f::2: time<1ms
Reply from 2001:4830:1600:20f::2: time<1ms
Ping statistics for 2001:4830:1600:20f::2:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
######
###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:4830:1600:20f::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 (both IPv4 and IPv6) of course
### If the previous test was succesful then this could be both
### a firewalling and a routing/interface problem
Pinging 2001:4830:1600:20f::1 with 32 bytes of data:
Destination host unreachable.
Request timed out.
Request timed out.
Ping statistics for 2001:4830:1600:20f::1:
Packets: Sent = 3, Received = 0, Lost = 3 (100% loss),
######
###### [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.
######
###### [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
######
###### 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.
I can reach kame.net just fine (dancing turtle and all); however, trying to reach your own site via IPv6 is a non-starter. (IPv4 works, though).
Posting is only allowed when you are logged in. |