Chapter 16 – Troubleshooting TCP/IP

  • Artigo

Published: February 28, 2006 | Updated: April 19, 2006

Writer: Joe Davies

Abstract

This chapter describes how to troubleshoot problems with connectivity, name resolution, and Transmission Control Protocol (TCP) session creation using the set of tools and capabilities provided in Microsoft® Windows Server™ 2003 and Windows® XP. A network administrator must know how to methodically analyze a TCP/IP-related networking problem in terms of the various layers of the TCP/IP model and use the appropriate tools to be effective in isolating and resolving issues with successful communication on an TCP/IP network.

For a download of the entire "TCP/IP Fundamentals for Microsoft Windows" online book, which contains a version of this chapter that has been updated for Windows Vista and Windows Server 2008, click here.

On This Page

Chapter Objectives
Identifying the Problem Source
Windows Troubleshooting Tools
Troubleshooting IPv4
Troubleshooting IPv6
Chapter Summary
Chapter Glossary

Chapter Objectives

After completing this chapter, you will be able to:

  • List the common questions to ask when troubleshooting.

  • List the set of TCP/IP troubleshooting tools provided with Windows Server 2003 and Windows XP and describe how each is used to obtain troubleshooting information.

  • List and describe the guidelines, tools, and techniques for troubleshooting Internet Protocol version 4 (IPv4) communications including IPv4 connectivity, Domain Name System (DNS) name resolution for IPv4 addresses, Network basic input/output system (NetBIOS) name resolution, and IPv4-based TCP sessions.

  • List and describe the guidelines, tools, and techniques for troubleshooting Internet Protocol version 6 (IPv6) communication including IPv6 connectivity, DNS name resolution for IPv6 addresses, and IPv6-based TCP sessions.

Identifying the Problem Source

A logical approach is helpful when troubleshooting any problem. Some common questions to ask during troubleshooting include the following:

  • What works?

  • What does not work?

  • How are the things that do and do not work related?

  • Have the things that do not work ever worked?

  • If so, what has changed since it last worked?

The answers to these questions can indicate where to begin troubleshooting, possibly allowing you to isolate the component, layer, or configuration issue that is causing the problem.

Windows Troubleshooting Tools

Windows Server 2003 and Windows XP provide a full set of configuration, administration, and diagnostic tools and services that can be used to troubleshoot TCP/IP problems, as listed in Table 16-1.

Table 16-1 Tools and Services for Troubleshooting TCP/IP

Tool

Description

Arp

Allows viewing and editing of the Address Resolution Protocol (ARP) cache.

Hostname

Displays the host name of the computer.

Ipconfig

Displays the current TCP/IP configuration for both IPv4 and IPv6. Also used to manage Dynamic Host Configuration Protocol (DHCP)-allocated IPv4 address configurations, display or flush the DNS client resolver cache, and register DNS names.

Nbtstat

Displays NetBIOS over TCP/IP (NetBT) configuration and allows management of the NetBIOS name cache.

Netsh

Configuration tool for many network services. For each network service, there is a context containing commands specific for that service. For the netsh interface ip and netsh interface ipv6 contexts, displays and administers TCP/IP protocol settings on either the local computer or a remote computer.

Netstat

Displays protocol statistics and information on current TCP connections.

Nslookup

Performs DNS queries and displays the results.

Ping

Sends Internet Control Message Protocol (ICMP) Echo or Internet Control Message Protocol for IPv6 (ICMPv6) Echo Request messages to test reachability.

Route

Allows viewing of the IPv4 and IPv6 routing tables and editing of the IPv4 routing table.

Tracert

Sends ICMP Echo or ICMPv6 Echo Request messages to trace the network route taken by IPv4 or IPv6 packets to a specific destination.

Pathping

Sends ICMP Echo or ICMPv6 Echo Request messages to trace the route an IPv4 or IPv6 packet takes to a destination and displays information on packet losses for each router and link in the path.

SNMP service

Provides status and statistical information to Simple Network Management System (SNMP) management systems.

Event Viewer

Records errors and events.

Performance Logs and Alerts

Logs TCP/IP core protocol performance and sends alerts (the SNMP service must be installed).

Network Monitor

Captures and displays the contents of TCP/IP packets sent to and from computers running Windows Server 2003.

Netdiag

Runs a series of diagnostics test on networking components. Netdiag is installed as part of the Windows XP and Windows Server 2003 Support Tools in the Support\Tools folder of the Windows XP or Windows Server 2003 product CD-ROM.

Telnet

Tests TCP connection establishment between two nodes.

Ttcp

Listens for and sends TCP segment data or UDP messages between two nodes.Ttcp.exe is provided with Windows XP Service Pack 2 in the Valueadd\Msft\Net\Tools folder of the Windows XP Service Pack 2 CD-ROM.

Troubleshooting IPv4

The following sections describe the tools and techniques used to identify a problem at successive layers of the TCP/IP protocol stack that is using an IPv4 Internet layer. Depending on the type of problem, you might do one of the following:

  • Start at the bottom of the stack and move up.

  • Start at the top of the stack and move down.

The following sections are organized from the top of the stack and describe how to:

  • Verify IPv4 connectivity.

  • Verify DNS name resolution for IPv4 addresses.

  • Verify NetBIOS name resolution.

  • Verify IPv4-based TCP sessions.

Although not specified in the following sections, you can also use Network Monitor to capture IPv4 traffic to troubleshoot many problems with IPv4-based TCP/IP communications. Network Monitor is provided with Microsoft Systems Management Server and as an optional network component with Windows Server 2003. However, to correctly interpret the display of IPv4 packets in Network Monitor, you must have an advanced knowledge of the protocols included in each packet.

Verifying IPv4 Connectivity

You can use the following tasks to troubleshoot problems with IPv4 connectivity:

  • Repair the connection

  • Verify configuration

  • Manage configuration

  • Verify reachability

  • View and manage the IPv4 routing table

  • Verify router reliability

Repair the Connection

The Network Connection Repair feature can be used to quickly renew IPv4 network connection settings in an attempt to correct common configuration problems. Network Connection Repair performs a series of tasks that attempt to renew the connection as if it were just initialized. To access Network Connection Repair, do the following:

  1. Click Start, click Control Panel, and then double-click Network Connections.

  2. Right-click the connection that you want to repair, and then click Repair.

You can also click Repair on the Support tab for the status of a network connection.

The tasks that are performed by Network Connection Repair are the following:

  • Checks whether DHCP is enabled and, if enabled, sends a broadcast DHCPRequest message to refresh the IPv4 address configuration.

  • Flushes the ARP cache. This is equivalent to the arp -d * command.

  • Flushes and reloads the DNS client resolver cache with entries from the Hosts file. This is equivalent to the ipconfig /flushdns command.

  • Re-registers DNS names using DNS dynamic update. This is equivalent to the ipconfig /registerdns command.

  • Flushes and reloads the NetBIOS name cache with #PRE entries in the Lmhosts file. This is equivalent to the nbtstat -R command.

  • Releases and then re-registers NetBIOS names with the Windows Internet Name Service (WINS). This is equivalent to the nbtstat -RR command.

Verify Configuration

To check the current IPv4 settings for the correct address configuration (when manually configured) or an appropriate address configuration (when automatically configured), you can use the following:

  • ipconfig /all

    The display of the ipconfig /all command includes IPv4 addresses, default gateways, and DNS settings for all interfaces. The Ipconfig tool only works on the local computer.

  • netsh interface ip show config

    The display of the netsh interface ip show config command includes DNS and WINS servers per interface. Netsh can also be used to show the configuration of a remote computer by using the –r RemoteComputerName command line option. For example, to display the configuration of the remote computer named FILESRV1, use the netsh –r filesrv1 interface ip show config command.

  • Support tab on the Status dialog box on a network connection

    To get the status of a network connection, double-click the connection in the Network Connections folder, and then click the Support tab. The Support tab lists the address type (DHCP or manually configured), the IPv4 address, subnet mask, and default gateway. Click Details on the Support tab to display the media access control (MAC) address, DHCP lease information, DNS servers, and WINS servers.

Manage Configuration

To make changes to the IPv4 address configuration, you can use the following:

  • Network Connections folder

    From the Network Connections folder, you can make changes to the properties of the Internet Protocol (TCP/IP) component for the appropriate network connection.

  • netsh interface ip set commands

    You can use the netsh interface ip set address command to configure the address type (DHCP or manually configured), the IPv4 address, subnet mask, and default gateway. You can use the netsh interface ip set dns command to configure the source of DNS server addresses (DHCP or manually configured), a DNS server address, and DNS registration behavior. You can use the netsh interface ip set wins command to configure the source of WINS server addresses (DHCP or manually configured) and a WINS server address.

    You can also use the –r RemoteComputerName command line option of the Netsh tool to manage the IPv4 configuration of a remote computer.

  • Ipconfig commands to manage DHCP addresses

    You can use the following commands to manage DHCP addresses:

    • ipconfig /release

    • ipconfig /renew

    • ipconfig /showclassid

    • ipconfig /setclassid

For more information about using Ipconfig commands to manage DHCP address configurations, see Chapter 6, "Dynamic Host Configuration Protocol."

Verify Reachability

To verify reachability with a local or remote destination, try the following:

  • Check and flush the ARP cache

    To display the current contents of the ARP cache, use the arp –a command. To flush the ARP cache, use the arp –d * command. This command also removes static ARP cache entries.

  • Ping the default gateway

    Use the Ping tool to ping your default gateway by its IPv4 address. You can obtain the IPv4 address of your default gateway from the display of the ipconfig, netsh interface ip show config, or route print commands. Pinging the default gateway tests whether you can reach local nodes and whether you can reach the default gateway, which is used to forward IPv4 packets to remote nodes. This step might not succeed if the default gateway is filtering all ICMP messages.

  • Ping a remote destination by its IPv4 address

    If you are able to ping your default gateway, ping a remote destination by its IPv4 address. This step might not succeed if the destination is filtering all ICMP messages. Filtering of ICMP messages is prevalent on the Internet.

  • Trace the route to the remote destination

    If you are unable to ping a remote destination by its IPv4 address, there might be a routing problem between your node and the destination node. Use the tracert –d IPv4Address command to trace the routing path to the remote destination. The –d command line option prevents the Tracert tool from performing a DNS reverse query on every near-side router interface in the routing path, which speeds up the display of the routing path. This step might not succeed if the intermediate routers or the destination are filtering all ICMP messages. Filtering of ICMP messages is prevalent on the Internet.

Check Packet Filtering

The problem with reaching a destination node might be due to the configuration of Internet Protocol security (IPsec) or packet filtering on the source node, intermediate routers, or destination node that is preventing packets from being sent, forwarded, or received.

On the source node, check for the following:

  • Active IPsec policies with the IP Security Monitor snap-in

  • For computers running Windows Server 2003, Routing and Remote Access IPv4 packet filters on routing interfaces with the Routing and Remote Access snap-in

On intermediate IPv4 routers that are running Windows XP, check for the following:

  • Active IPsec policies with the IP Security Monitor snap-in

On intermediate IPv4 routers that are running Windows Server 2003 and Routing and Remote Access, check for the following:

  • Active IPsec policies with the IP Security Monitor snap-in

  • Routing and Remote Access IPv4 packet filters on routing interfaces with the Routing and Remote Access snap-in

  • NAT/Basic Firewall routing protocol component of Routing and Remote Access

On intermediate IPv4 routers or firewalls that are from third-party hardware vendors, check for the configuration of packet filters—also called access lists—and IPsec policies and filters.

On the destination node that is running Windows XP or Windows Server 2003, check for the following:

  • Active IPsec policies with the IP Security Monitor snap-in

  • Whether Internet Connection Firewall or Windows Firewall is enabled

  • TCP/IP filtering

On the destination node that is running Windows Server 2003 and Routing and Remote Access, check for the following:

  • Active IPsec policies with the IP Security Monitor snap-in

  • Routing and Remote Access IPv4 packet filters on routing interfaces with the Routing and Remote Access snap-in

  • NAT/Basic Firewall routing protocol component of Routing and Remote Access

  • Whether Internet Connection Firewall or Windows Firewall is enabled

  • TCP/IP filtering

For more information about IPsec and packet filtering components, see Chapter 13, "Internet Protocol Security (IPsec) and Packet Filtering."

View and Manage the Local IPv4 Routing Table

The inability to reach a local or remote destination might be due to incorrect or missing routes in the IPv4 routing table. To view the IPv4 routing table, use the route print or netstat –r commands. Verify that you have a route corresponding to your local subnet and, if a default gateway is configured, a default route. If you have multiple default routes with the same lowest metric, then change your IPv4 configuration so that only one exists and is using the interface that connects to the network with the largest number of subnets, such as the Internet.

To add a route to the IPv4 routing table, use the route add command. To modify an existing route, use the route change command. To remove an existing route, use the route delete command.

Verify Router Reliability

If you suspect a problem with router performance, use the pathping –d IPv4Address command to trace the route a packet takes to a destination and display information on packet losses for each router and link in the path. The –d command line option prevents the Pathping tool from performing a DNS reverse query on every near-side router interface in the routing path, which speeds up the display of the routing path.

Verifying DNS Name Resolution for IPv4 Addresses

If reachability using IPv4 addresses works but reachability using host names does not, then you might have a problem with host name resolution, which is typically an issue with configuration of the DNS client or problems with DNS registration.

You can use the following tasks to troubleshoot problems with DNS name resolution:

  • Verify DNS configuration

  • Display and flush the DNS client resolver cache

  • Test DNS name resolution with the Ping tool

  • Use the Nslookup tool to view DNS server responses

Verify DNS Configuration

On the node having DNS name resolution problems, verify the following:

  • Host name

  • Primary DNS suffix

  • DNS suffix search list

  • Connection-specific DNS suffixes

  • DNS servers

You can obtain this information from the display of the ipconfig /all command. To obtain information about which DNS names should be registered in DNS, use the netsh interface ip show dns command.

To register the appropriate DNS names as IPv4 address resource records (also known as A resource records) with DNS dynamic update, use the ipconfig /registerdns command.

Display and Flush the DNS Client Resolver Cache

TCP/IP checks the DNS client resolver cache before sending DNS name queries. If a positive cache entry for name exists, the corresponding IPv4 address is used. If a negative cache entry for the name exists, DNS name queries are not sent.

To display the contents of the DNS client resolver cache, use the ipconfig /displaydns command. To flush the contents of the DNS client resolver cache and reload it with the entries in the Hosts file, use the ipconfig /flushdns command.

Test DNS Name Resolution with Ping

To test DNS name resolution, use the Ping tool and ping a destination by its host name or fully qualified domain name (FQDN). The Ping tool display shows the FQDN and its resolved IPv4 address. If the host on which the Ping tool is being used is using both IPv4 and IPv6 and the DNS query returns both IPv4 and IPv6 addresses, the Ping tool will use IPv6 addresses before IPv4 addresses. To force the Ping tool to use an IPv4 address, use the –4 Ping command option.

Use the Nslookup Tool to View DNS Server Responses

If the Ping tool is using the wrong IPv4 address, flush the DNS client resolver cache with the ipconfig /flushdns command and use the Nslookup tool to determine the set of addresses returned in the DNS Name Query Response message. At the Nslookup > prompt, use the set d2 command to display the maximum amount of information about the DNS response messages. Then, use Nslookup to look up the desired FQDN and display the details of the DNS response message. Look for A records in the detailed display of the DNS response messages.

Verifying NetBIOS Name Resolution

If reachability using IPv4 addresses works but reachability using NetBIOS names does not, then you might have a problem with NetBIOS name resolution, which is typically a problem with NetBIOS over TCP/IP configuration or WINS registration.

The following tools and tasks can be used to troubleshoot problems with NetBIOS name resolution:

  • Verify NetBT configuration

  • Display and reload the NetBIOS name cache

  • Test NetBIOS name resolution with Nbtstat

Verify NetBIOS over TCP/IP configuration

On the node having NetBIOS name resolution problems, verify the following:

  • NetBIOS computer name

  • NetBIOS node type

  • Primary WINS server

  • Secondary WINS server

  • Whether NetBIOS over TCP/IP is disabled

You can obtain this information from the display of the ipconfig /all command. To obtain information about the NetBIOS scope ID assigned to each interface, use the nbtstat -c command. To verify whether Lmhosts lookup is enabled, check the WINS tab for the advanced properties of the Internet Protocol (TCP/IP) component.

To display the local NetBIOS name table, use the nbtstat –n command. To display the NetBIOS name table of a remote computer, use the nbtstat –a ComputerName or nbtstat –A IPv4Address commands.

To release and re-register the NetBIOS names of the node in WINS, use the nbtstat -RR command.

Display and Reload the NetBIOS Name Cache

The NetBIOS name cache is checked before sending WINS or broadcast name queries. If an entry exists for a resolved name, TCP/IP uses the corresponding IPv4 address. To display the contents of the NetBIOS name cache, use the nbtstat -c command. To flush the contents of the NetBIOS name cache and reload it with the #PRE entries in the Lmhosts file, use the nbtstat -R command.

Test NetBIOS Name Resolution with Nbtstat

To test NetBIOS name resolution, use the nbtstat –a ComputerName command. This command displays the NetBIOS name table of a computer specified by its NetBIOS computer name.

Verifying IPv4-based TCP Sessions

If reachability and name resolution are working but you cannot establish a TCP session with a destination host, use the following tasks:

  • Check for packet filtering

  • Verify TCP session establishment

  • Verify NetBIOS sessions

Check for Packet Filtering

As previously discussed in the "Verifying IPv4 Communications" section of this chapter, packet filtering by the source node, intermediate routers, and the destination node can prevent TCP sessions from completing. Use the information in the "Verifying IPv4 Communications" section of this chapter to check for packet filtering or IPsec policies at the source node, intermediate routers and firewalls, and the destination node.

In many cases, packet filtering is configured to allow specific types of traffic and discard all others, or to discard specific types of traffic and accept all others. As an example of the former case, a firewall or Web server might be configured to allow only HyperText Transfer Protocol (HTTP) traffic and discard all other traffic destined for the Web server. This means that you will be able to view Web pages on the Web server, but not ping the Web server or access its shared folders and files.

Verify TCP Session Establishment

To verify that a TCP connection can be established using the known destination TCP port number, you can use the telnet IPv4Address TCPPort command. For example, to verify whether the Web server service on the computer with the IPv4 address of 131.107.78.12 is accepting TCP connections, use the telnet 131.107.78.12 80 command.

If the Telnet tool is successful in creating a TCP connection, the command prompt window will clear and, depending on the protocol, display some text. This window allows you to type in commands to the service to which you have connected. Type Control-C to exit the Telnet tool. If the Telnet tool cannot successfully create a TCP connection, it displays the message "Connecting To IPv4Address...Could not open connection to the host, on port TCPPort: Connect failed".

To test TCP connections, you can also use Port Query, a free tool from Microsoft to help troubleshoot TCP/IP connectivity issues for specific types of TCP and UDP traffic. Port Query has a command-line version (Portqry.exe) (available at PortQry Command Line Port Scanner Version 2.0) and a graphical user interface version (Portqueryui.exe) (available at PortQryUI - User Interface for the PortQry Command Line Port Scanner). Both versions run on Windows 2000, Windows XP, and Windows Server 2003-based computers.

Another tool that you can use to test TCP connection establishment is Test TCP (Ttcp). With Ttcp, you can both initiate TCP connections and listen for TCP connections. You can also use the Ttcp tool for UDP traffic. With Ttcp, you can configure a computer to listen on a specific TCP or UDP port without having to install the application or service on the computer. This allows you to test network connectivity for specific traffic before the services are in place.

For more information about Port Query and Ttcp, see Testing Network Paths for Common Types of Traffic.

Verify NetBIOS Sessions

To verify that you have established NetBIOS sessions, you can use the nbtstat –s command, which displays the NetBIOS session table.

Troubleshooting IPv6

The following sections describe the tools and techniques used to identify a problem at successive layers of the TCP/IP protocol stack using an IPv6 Internet layer. Depending on the type of problem, you might do one of the following:

  • Start at the bottom of the stack and move up.

  • Start at the top of the stack and move down.

The following sections are organized from the top of the stack and describe how to:

  • Verify IPv6 connectivity.

  • Verify DNS name resolution for IPv6 addresses.

  • Verify IPv6-based TCP sessions.

Although not specified in the following sections, you can also use Network Monitor to capture IPv6 traffic to troubleshoot many problems with IPv6-based communications. Network Monitor is provided with Microsoft Systems Management Server and as an optional network component with Windows Server 2003. However, to correctly interpret the display of IPv6 packets in Network Monitor, you must have detailed knowledge of the protocols included in each packet.

Verifying IPv6 Connectivity

You can use the following tasks to troubleshoot problems with IPv6 connectivity:

  • Verify configuration

  • Manage configuration

  • Verify reachability

  • View and manage the IPv6 routing table

  • Verify router reliability

Verify Configuration

To check the current IPv6 settings for the correct address configuration (when manually configured) or an appropriate address configuration (when automatically configured), you can use the following:

  • ipconfig /all

    The display of the ipconfig /all command includes IPv6 addresses, default routers, and DNS settings for all interfaces. The Ipconfig tool only works on the local computer.

  • netsh interface ipv6 show address

    This command only displays the IPv6 addresses assigned to each interface. Netsh can also be used to show the configuration of a remote computer by using the –r RemoteComputerName command line option. For example, to display the configuration of the remote computer named FILESRV1, use the netsh –r filesrv1 interface ipv6 show address command.

Manage Configuration

To manually configure IPv6 addresses, use the netsh interface ipv6 set address command. In most cases, you do not need to manually configure IPv6 addresses because they are automatically assigned for hosts through IPv6 address autoconfiguration.

To make changes to the configuration of IPv6 interfaces, use the netsh interface ipv6 set interface command. To add the IPv6 addresses of DNS servers, use the netsh interface ipv6 add dns command.

You can use the –r RemoteComputerName command line option of the Netsh tool to manage the IPv6 configuration of a remote computer.

Verify Reachability

To verify reachability with a local or remote destination, try the following:

  • Check and flush the neighbor cache

    Similar to the Address Resolution Protocol (ARP) cache, the neighbor cache stores recently resolved link-layer addresses. To display the current contents of the neighbor cache, use the netsh interface ipv6 show neighbors command. To flush the neighbor cache, use the netsh interface ipv6 delete neighbors command.

  • Check and flush the destination cache

    The destination cache stores next-hop IPv6 addresses for destinations. To display the current contents of the destination cache, use the netsh interface ipv6 show destinationcache command. To flush the destination cache, use the netsh interface ipv6 delete destinationcache command.

  • Ping the default router

    Use the Ping tool to ping your default router by its IPv6 address. You can obtain the link-local IPv6 address of your default router from the display of the ipconfig, netsh interface ipv6 show routes, route print, or nbtstat -r commands. Pinging the default router tests whether you can reach local nodes and whether you can reach the default router, which forwards IPv6 packets to remote nodes.

    When you ping the default router, you must specify the zone identifier (ID) for the interface on which you want the ICMPv6 Echo Request messages to be sent. The zone ID is the interface index of the default route (::/0) with the lowest metric, from the display of the netsh interface ipv6 show routes or route print commands.

    This step might not succeed if the default router is filtering all ICMPv6 messages.

  • Ping a remote destination by its IPv6 address

    If you are able to ping your default router, ping a remote destination by its IPv6 address. This step might not succeed if the destination is filtering all ICMPv6 messages.

  • Trace the route to the remote destination

    If you are unable to ping a remote destination by its IPv6 address, there might be a routing problem between your node and the destination node. Use the tracert –d IPv6Address command to trace the routing path to the remote destination. The –d command line option prevents the Tracert tool from performing a DNS reverse query on every near-side router interface in the routing path, which speeds up the display of the routing path. This step might not succeed if the intermediate routers or the destination are filtering all ICMPv6 messages.

Check Packet Filtering

The problem with reaching a destination node might be due to the configuration of Internet Protocol security (IPsec) or packet filtering on the source node, intermediate routers, or destination node that is preventing packets from being sent, forwarded, or received.

On the source node, check for IPsec for IPv6 policies that have been configured with the Ipsec6 tool.

On intermediate IPv6 routers that are running Windows XP or Windows Server 2003, check for IPsec for IPv6 policies that have been configured with the Ipsec6 tool.

For third-party intermediate IPv6 routers or firewalls, check for the configuration of IPv6-based packet filters and IPsec policies.

On the destination node, check for the following:

  • IPsec for IPv6 policies that have been configured with the Ipsec6 tool

  • The simple IPv6 firewall

    IPv6 for Windows Server 2003 includes support for a simple firewall on an interface. When enabled, IPv6 drops incoming TCP Synchronize (SYN) segments and drops all unsolicited incoming UDP messages. You can configure the simple firewall with the netsh interface ipv6 set interface interface= NameOrIndex firewall=enabled|disabled command.

  • Internet Connection Firewall for IPv6

    The Internet Connection Firewall for IPv6 is included with the Advanced Networking Pack for Windows XP, a free download for Windows XP with SP1.

  • Windows Firewall

    The Windows Firewall is included with Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1.

For more information about these packet filtering components, see Chapter 13, "Internet Protocol Security (IPsec) and Packet Filtering."

View and Manage the Local IPv6 Routing Table

The inability to reach a local or remote destination might be due to incorrect or missing routes in the IPv6 routing table. To view the IPv6 routing table, use the route print, netstat –r, or netsh interface ipv6 show routes commands. Verify that you have a route corresponding to your local subnet and, if automatically configured with a default router, a default route. If you have multiple default routes with the same lowest metric, you might need to modify your IPv6 router configurations so that the default route with the lowest metric uses the interface that connects to the network with the largest number of subnets.

To add a route to the IPv6 routing table, use the netsh interface ipv6 add route command. To modify an existing route, use the netsh interface ipv6 set route command. To remove an existing route, use the netsh interface ipv6 delete route command.

Verify Router Reliability

If you suspect a problem with router performance, use the pathping –d IPv6Address command to trace the path to a destination and display information on packet losses for each router and link in the path. The –d command line option prevents the Pathping tool from performing a DNS reverse query on every near-side router interface in the routing path, which speeds up the display of the routing path.

Verifying DNS Name Resolution for IPv6 Addresses

If reachability using IPv6 addresses works but reachability using host names does not, you might have a problem with host name resolution, which is typically a problem with the configuration of the DNS client or problems with DNS registration.

You can use the following tasks to troubleshoot problems with DNS name resolution:

  • Verify DNS configuration

  • Display and flush the DNS client resolver cache

  • Test DNS name resolution with the Ping tool

  • Use the Nslookup tool to view DNS server responses

Verify DNS Configuration

On the node having DNS name resolution problems, verify the following:

  • Host name

  • The primary DNS suffix

  • DNS suffix search list

  • Connection-specific DNS suffixes

  • DNS servers

You can obtain this information from the display of the ipconfig /all command. To obtain information about which DNS names should be registered in DNS, use the netsh interface ip show dns command.

By default, IPv6 configures the well-known site-local addresses of DNS servers at FEC0:0:0:FFFF::1, FEC0:0:0:FFFF::2, and FEC0:0:0:FFFF::3 on each interface that receives a router advertisement. To add the IPv6 addresses of additional DNS servers, use the netsh interface ipv6 add dns command.

To register the appropriate DNS names as IPv6 address resource records (also known as AAAA resource records) with DNS dynamic update, use the ipconfig /registerdns command.

Display and Flush the DNS Client Resolver Cache

TCP/IP checks the DNS client resolver cache before sending DNS name queries. If a positive cache entry exists for a resolved name, the corresponding IPv6 address is used. If a negative cache entry for the name exists, DNS name queries are not sent.

To display the contents of the DNS client resolver cache, use the ipconfig /displaydns command. To flush the contents of the DNS client resolver cache and reload it with the entries in the Hosts file, use the ipconfig /flushdns command.

Test DNS Name Resolution with Ping

To test DNS name resolution, use the Ping tool and ping a destination by its host name or FQDN. The Ping tool display shows the FQDN and its corresponding IPv6 address.

Use the Nslookup Tool to View DNS Server Responses

If the Ping tool is using the wrong IPv6 address, flush the DNS client resolver cache and use the Nslookup tool to determine the set of addresses returned in the DNS Name Query Response message. At the Nslookup > prompt, use the set d2 command to display the maximum amount of information about the DNS response messages. Then, use Nslookup to look up the desired FQDN. Look for AAAA records in the detailed display of the DNS response messages.

Verifying IPv6-based TCP Sessions

If reachability and name resolution are working but you cannot establish a TCP connection with a destination host, use the following tasks:

  • Check for packet filtering

  • Verify TCP connection establishment

Check for Packet Filtering

As previously discussed in the "Verifying IPv6 Communications" section of this chapter, packet filtering by the source node, intermediate routers, and the destination node can prevent TCP connections from being established. Use the information in the "Verifying IPv6 Communications" section of this chapter to check for packet filtering or IPsec policies at the source node, intermediate routers and firewalls, and the destination node.

In many cases, packet filtering is configured to allow specific types of traffic and discard all others, or to discard specific types of traffic and accept all others. As an example of the former case, a firewall or Web server might be configured to allow only HTTP traffic and discard all other traffic destined for the Web server. This means that you will be able to view Web pages on the Web server, but not ping it or access its shared folders and files.

Verify TCP Session Establishment

To verify that a TCP connection can be established using a known destination TCP port number, you can use the telnet IPv6Address TCPPort command. For example, to verify whether the Web server service on the computer with the IPv6 address of 3FFE:FFFF::21AD:2AA:FF:FE31:AC89 is accepting TCP connections on TCP port 80, use the telnet 3ffe:ffff::21ad:2aa:ff:fe31:ac89 80 command.

If the Telnet tool can successfully create a TCP connection, the command prompt window will clear and, depending on the protocol, display some text. This window allows you to type in commands to the service to which you have connected. Type Control-C to exit the Telnet tool. If the Telnet tool cannot successfully create a TCP connection, it displays the message "Connecting To IPv6Address...Could not open connection to the host, on port TCPPort: Connect failed".

Another tool that you can use to test TCP connection establishment is Test TCP (Ttcp). With Ttcp, you can both initiate TCP connections and listen for TCP connections. You can also use the Ttcp tool for UDP traffic. With Ttcp, you can configure a computer to listen on a specific TCP or UDP port without having to install the application or service on the computer. This allows you to test network connectivity for specific traffic before the services are in place.

For more information about Ttcp, see Testing Network Paths for Common Types of Traffic.

Chapter Summary

The chapter includes the following pieces of key information:

  • To try and isolate the components that might be at fault when approaching a troubleshooting issue, you should determine what works, what does not work, whether it has ever worked, and what has changed since it last worked.

  • Windows provides the following tools for troubleshooting TCP/IP problems: Arp, Hostname, Ipconfig, Nbtstat, Netsh, Netstat, Nslookup, Ping, Route, Tracert, Pathping, SNMP service, Event Viewer, Performance Logs and Alerts, Network Monitor, and Netdiag.

  • Troubleshoot IPv4 communications by verifying IPv4 connectivity, verifying DNS name resolution for IPv4 addresses, verifying NetBIOS name resolution, and verifying IPv4-based TCP sessions.

  • Troubleshoot IPv6 communications by verifying IPv6 connectivity, verifying DNS name resolution for IPv6 addresses, and verifying IPv6-based TCP sessions.

Chapter Glossary

address resolution – The IPv4 (using ARP) or IPv6 (using neighbor discovery) process that resolves the MAC address for a next-hop IP address on a link.

Address Resolution Protocol – A protocol that uses broadcast traffic on the local subnet to resolve an IPv4 address to its MAC address.

ARP – See Address Resolution Protocol.

ARP cache – A table for each interface of static or dynamically resolved IPv4 addresses and their corresponding MAC addresses.

default gateway – A configuration parameter for IPv4 that is the IPv4 address of a neighboring IPv4 router. Configuring a default gateway creates a default route in the IPv4 routing table.

default route – A route that summarizes all possible destinations and is used for forwarding when the routing table does not contain any other more specific routes for the destination. For example, if a router or sending host cannot find a subnet route, a summarized route, or a host route for the destination, IP selects the default route. The default route is used to simplify the configuration of hosts and routers. For IPv4 routing tables, the default route is the route with the network destination of 0.0.0.0 and netmask of 0.0.0.0. For IPv6 routing tables, the default route has the address prefix ::/0.

default router – A configuration parameter for IPv6 that is the link-local address of a neighboring IPv6 router. Default routers are automatically configured by IPv6 router discovery.

destination cache – A table for destination IPv6 addresses and their previously determined next-hop addresses.

DNS – See Domain Name System (DNS).

DNS client resolver cache – A RAM-based table that contains both the entries in the Hosts file and the results of recent DNS name queries.

DNS server – A server that maintains a database of mappings of DNS domain names to various types of data, such as IP addresses.

Domain Name System (DNS) – A hierarchical, distributed database that contains mappings of DNS domain names to various types of data, such as IP addresses. DNS enables the specification of computers and services by user-friendly names, and it also enables the discovery of other information stored in the database.

Host name – The name of a computer or device on a network. Users specify computers on the network by their host names. To find another computer, its host name must either appear in the Hosts file or be known by a DNS server. For most Windows-based computers, the host name and the computer name are the same.

Host name resolution – The process of resolving a host name to a destination IP address.

Hosts file – A local text file in the same format as the 4.3 BSD UNIX /etc/hosts file. This file maps host names to IP addresses, and it is stored in the systemroot\System32\Drivers\Etc folder.

Lmhosts file – A local text file that maps NetBIOS names to IP addresses for hosts that are located on remote subnets. For Windows-based computers, this file is stored in the systemroot\System32\Drivers\Etc folder.

negative cache entries – Host names added into the DNS client resolver cache that were queried but that could not be resolved.

neighbor cache – A cache maintained by every IPv6 node that stores the on-subnet IPv6 address of a neighbor and its corresponding MAC address. The neighbor cache is equivalent to the ARP cache in IPv4.

NBNS – See NetBIOS name server (NBNS).

NetBIOS name - A 16-byte name of a process using NetBIOS.

NetBIOS name cache – A dynamically maintained table that resides on a NetBIOS-enabled host and that stores recently resolved NetBIOS names and their associated IPv4 addresses.

NetBIOS name resolution – The process of resolving a NetBIOS name to an IPv4 address.

NetBIOS name server (NBNS) – A server that stores NetBIOS name to IPv4 address mappings and resolves NetBIOS names for NetBIOS-enabled hosts. WINS is the Microsoft implementation of a NetBIOS name server.

routing table – The set of routes used to determine the next-hop address and interface for IP traffic sent by a host or forwarded by a router.

Windows Internet Name Service (WINS) – The Microsoft implementation of a NetBIOS name server.

WINS – See Windows Internet Name Service (WINS).