3. Check the Routing Table for IPV6
If you find yourself unable
to connect to remote resources using IPV6, one of the things you will
want to check is the routing table. Specifically, you will be looking
for routes that have been incorrectly identified or erroneously entered
into the routing table. Use ROUTE PRINT, as shown in Figure 4.
NETSTAT -R
NETSH INTERFACE IPV6 SHOW ROUTE
Each of these commands will
show you the IPV6 entries on the routing table. To correct or enter a
missing route, you will need to use the following:
NETSH INTERFACE IPV6 SET ROUTE, ROUTE ADD, or ROUTE CHANGE.
It is also possible to remove erroneous or incorrect routes using this:
NETSH INTERFACE IPV6 DELETE ROUTE command or ROUTE DELETE.
In each of these cases, it
is important that you have a clear understanding of what the correct
routing table entries should look like and that you are able to
recognize entries that are not correct or are simply not there. As we
discussed earlier, you really need a good knowledge of the way things
are supposed to work in your network infrastructure in order to
troubleshoot them effectively.
4. Validate DNS Name Resolution for IPV6 Addresses
If the IPV6 addressing
configuration and response checks out, you will want to move up and
check on the resolution of host names to TCP/IP addresses, which means
DNS. DNS resolves host names to IP addresses for both IPV4 and IPV6. You
can perform some simple tasks to ensure that IPV6 host name to IP
address resolution is occurring properly.
First verify that your DNS
server has been configured to resolve host names to IPV6 addresses and
that it is acting upon name resolution requests that it receives. To
begin, use the HOSTNAME utility to check the host name of the server and to check the DNS suffix.
Next, open the DNS Manager
tool, and verify that all your configured DNS servers appear on the DNS
Manager's list of authoritative servers. You can also use the DNS
Manager to check the process of forwarding in the event that a host name
cannot be resolved to an IP address on the local DNS server. If you
need to make changes to the DNS suffix or to connection-specific DNS
suffix information, you can do it using DNS Manager.
5. Flush the DNS Cache
Each IPV6 client maintains a list of recently resolved DNS to IPV6 addresses. This list is called the DNS resolver cache.
If for some reason a record in the cache had an incorrect address for a
given host name, it would limit connectivity. In cases like this, you
can flush the contents of the DNS resolver cache using IPCONFIG /FLUSHDNS. See Figure 5.
This command will remove all
entries from the cache and force the machine to resolve the address with
recursive queries sent to the local DNS server hierarchy and get the
correct host name to IP address information.
You can quickly check for the function of DNS resolution using the PING tool. PING can be used in conjunction with IP addresses, host names, or FQDNs. For example:
PING Computer 1
or
PING www.microsoft.com
6. Test IPV6 TCP Connections
So, what if everything works
from an IP perspective but you still cannot get a TCP connection to
occur between systems? In the majority of cases, this is a problem with
packet filtering. You will need to check the same
locations for TCP filtering. Since you will be checking your filters
when you are validating IP connectivity, it makes sense to check for TCP
filters at the same time. If you didn't check for TCP filtering
earlier, it is time to do it now.
One of the easiest ways to check TCP connections is with the TELNET tool. TELNET is a command-line tool that establishes TCP connections between systems. TELNET uses a syntax similar to the PING command; simply use the TELNET command followed by the IPV6 address.
If the connection is possible, TELNET will create it. TELNET
connects to a service, so once you connect to a machine, you can
execute commands against the machine to test, configure, or view the
contents of the remote machine. TELNET
is sometimes seen as a potential security risk, so please don't be
surprised if the local firewalls or security policies do not allow TELNET
packets. If they do not, you may be able to test TCP connectivity with a
tool called Test TCP (TTCP). This tool allows you to build TCP
connections and also monitor for incoming TCP connection requests. You
can configure a computer to "listen" for TCP connections on a specific
port, which is good because you can test TCP connections without having
any specific services installed or configured.