Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Windows Server 2008 R2 : Troubleshoot IPV6 (part 1) - Verify Connectivity for IPV6 & Verify Responsiveness

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
7/2/2012 3:23:08 PM
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:

  1. 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.

  2. 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.

Figure 1. Results of netsh interface ipv6 show address

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

Figure 2. Results of 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

Figure 3. Results of 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

Other -----------------
- Windows Server 2008 R2 : Troubleshoot TCP/IP
- Microsoft SQL Server 2008 R2 : Using Replication and Database Mirroring Together, Using Database Snapshots from a Mirror for Reporting
- Microsoft SQL Server 2008 R2 : Migrate to Database Mirroring 2008 as Fast as You Can
- System Center Configuration Manager 2007 : Site Maintenance (part 3) - Obsolete Records
- System Center Configuration Manager 2007 : Site Maintenance (part 2) - Data Discovery Record (DDR) Retention
- System Center Configuration Manager 2007 : Site Maintenance (part 1) - Site Maintenance Tasks
- Backing Up the Exchange Server 2007 Environment : Using and Understanding the Windows Backup Utility
- Backing Up the Exchange Server 2007 Environment : Leveraging Local Continuous Replication
- Windows Server 2008 Server Core : Monitoring the File System with the FSUtil Command (part 4) - Transaction, USN & Volume
- Windows Server 2008 Server Core : Monitoring the File System with the FSUtil Command (part 3) - Reparse-Point, Resource & Sparse
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server