As you work with TCP/IP networks, you will probably
run into some problems. Hardware will fail, users will make changes to
their systems that inhibit communication, and applications or updates
might install with unintended consequences. Regardless of whether the
changes are malicious or unintended, if they impact your TCP/IP
infrastructure, you will need to troubleshoot the problems and find
solutions quickly and efficiently. There is no one "right" way to do
this. There are lots of tools and lots of methods of implementing those
tools to help you discover the source of the problem and then craft a
solution that will work for your environment. The best advice we can
give you regarding your ability to troubleshoot TCP/IP problems doesn't
include a troubleshooting methodology. It's this:
"Know your network!"
If you clearly understand the operation of your network, it will be much easier to troubleshoot problems as they arise.
We have used a simple
methodology for troubleshooting TCP/IP for a long, long time. We
occasionally tweak it a little and add some new tools. Depending on the
circumstance, we might change the protocol just a little bit, but the
basic operations stay the same. Please keep in mind there is no one
"right" way to do this; this just happens to be one of the ways we use.
The vast majority of
problems that we have investigated related to TCP/IP have begun with the
same complaint: "I can't connect to ..."
Whether it is a
network resource, the Internet, a printer, a file share, or any number
of other things, when we hear that phrase, the TCP/IP alarm bells sound.
If TCP/IP problems are primarily problems of connectivity, then you
would be well served to make your primary efforts focus on discovering
and resolving connectivity problems.
1. Verify Connectivity for IPV6
The first thing
you will want to do when troubleshooting TCP/IPV6 is to verify that
TCP/IP is actually set up and configured correctly. This is generally
where you will find the cause and can implement a solution. Consider the
following steps when verifying connectivity for TCP/IPV6:
Check
the physical hardware. Check the network cable. Is it plugged in? Check
the connections at switches, hubs, and routers. Don't laugh—you will
solve a lot of TCP/IPV6 problems right here in step 1. You might even be
well served to simply unplug the cable and plug it back in on the
off-chance that the cable somehow became loose even if it looks
connected.
Verify the function and configuration of the network interface, using the following commands:
ipconfig /all
This will display the status and configuration of the IPV6 interface.
Verify that the interface has an address and is in fact enabled. Check
the DNS settings for the interfaces to be certain that they are
configured correctly.
netsh interface ipv6 show address This will show you the TCP/IP address of the IPV6 interface, as shown in Figure 1.
In the event that there is in fact a problem in the TCP/IP configuration, you can change the configuration using the netsh interface ipv6 set command.
We always start here
because statistically we have found that many of the problems related to
IPV6 have to do with configuration. Once you get the configuration
right, TCP/IP works correctly, and your user's connectivity will be
restored.
2. Verify Responsiveness
Of course, not every problem
is going to be fixed with a simple check of the hardware and address
configuration. Responsiveness is also important. Responsiveness takes
into account that communication takes at least two endpoints. If either
of the endpoints fails to respond, then the communication cannot take
place. If you have checked the local configuration and everything is in
order, you should check that the machine is responding.
IPV6 uses something called a neighbor cache
to store link layer addresses that have been resolved recently. If for
some reason the neighbor cache holds incorrect information, it can
impede connectivity. You can flush the neighbor cache with no negative
effects to TCP/IP:
netsh interface ipv6 delete neighbors
If you are thinking to yourself, "Hey, that's a lot like the ARP cache from IPV4," you are right!
There is another cache you should also check in conjunction with responsiveness, called the destination cache. The destination cache is used to maintain a list of next hop addresses for addresses recently used. As shown in Figure 2, you can view the contents of the destination cache using the following command:
netsh interface ipv6 show destinationcache
As shown in Figure 3, if you decide you want to delete the cache, you can do so with the following command:
netsh interface ipv6 delete destinationcache
Both of the previous
steps, deleting the neighbor cache and deleting the destination cache,
act as preemptive actions to eliminate the possibility that your machine
is being incorrectly directed to a link address that is not going to
respond. To truly troubleshoot responsiveness, you will need to start
sending packets onto the network and watching for responses. There are a
couple of tools that are uniquely suited for this exercise.
PING uses the
Internet Control Message Packet to send echo request packets to a host
and then measures the response time as the host responds to those echo
requests. This tool can be incredibly valuable in verifying
responsiveness in IPV6. Traditionally, when you use the PING
tool, you begin with the process of pinging the local host address and
then move on to the local IP address, then an IP address on the same
subnet, next the default gateway of the local router, and finally an
address on another network segment. You might have learned that you can
skip right to pinging a remote host on another segment; if you get a
response, you know everything in the cascade is working. As tempting as
that is, in the event that you do not receive a response from the remote
host, you really don't know anything about where your problem is
located. Start with the local host, and work your way through the list.
When you don't receive a response, you have reached the area that is
having the problem.
One more very important point concerning PING
is that ICMP packets can be considered a security risk, and often
network administrators will configure their computers to not accept or
respond to ping echo request packets. If you ping a machine and get no
response, make certain that the reason you are not getting a response is
because there really is no connectivity, not that the system you pinged
does not support ping packets. This process of removing or limiting
response to specific packet types is often termed packet filtering. Packet filtering is a common reason for lack of responsiveness.
If you are confident
that TCP/IP has been installed and is configured correctly and you are
still not getting connectivity, it may well be an issue of filtering.
Consider checking the following:
Windows Firewall rules
IPsec policies
Remote access policies
IPV6 packet filters
Router policies
