If you have problems on an IPv6 network interface, you use the same troubleshooting commands as with IPv4, namely ifconfig , ping , and traceroute . The only difference between the two is that you use the inet6 option to display only IPv6 interface information. The following ifconfig command displays only the IPv6 interfaces on a system: ultra10# ifconfig -a inet6 lo0: flags=2000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1 inet6 ::1/128 hme0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 inet6 fe80::a00:20ff:feb3:4153/10 hme0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.23.23 netmask ffffff00 broadcast 192.168.23.255 ip.tun0: flags=2200851<UP,POINTOPOINT,RUNNING,MULTICAST,NONUD,IPv6> \ mtu 1480 index 3 inet tunnel src 192.168.23.23 tunnel dst 192.168.24.24 inet6 fe80::c0a8:1717/10 --> fe80::c0a8:1818 As with IPv4 multipathing problems, error messages are written to the /var/adm/messages file, so this should be inspected if problems occur. The majority of problems with IPv6-over-IPv4 tunnels results from incorrect configuration and can be detected with the ifconfig command. You should make sure that you have entered the correct addresses for both the source and destination of the tunnel. The following extract from the ifconfig -a command shows a tunnel that has been configured, but no destination address has been specified. Even though the tunnel will be created, it will not function at all. In this case, the solution is to remove the tunnel completely and reconfigure it with the correct addresses: ultra10# ifconfig -a ip.tun2: flags=2200851<UP,POINTOPOINT,RUNNING,MULTICAST,NONUD,IPv6> \ mtu 1480 index 5 inet tunnel src 192.168.28.66 inet6 fe80::c0a8:1c42/10 --> :: Notice from the code that the IPv4 destination address is missing. Also, the inet6 line of output demonstrates that the tunnel is pointing to an unspecified IPv6 address ( :: ). |