Supporting TCPIP Networking
|
| < Day Day Up > |
|
Supporting TCP/IP Networking
The Netsh shell provides two contexts for working with TCP/IP. You use the Interface IP context to view TCP/IP statistics and to change settings. You use the Diag context to diagnose TCP/IP problems. The use of these contexts assumes that the necessary TCP/IP network components are already installed on the computer you are working with. If TCP/IP network components aren’t installed, install them as discussed in Chapter 16 of the Microsoft Windows Server 2003 Administrator’s Pocket Consultant (Microsoft Press, 2003).
Obtaining and Saving the TCP/IP Configuration
If you’ve worked with Windows for a while, you probably know that you can type ipconfig at a command prompt to get basic Windows IP configuration information, such as
Windows IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix:
IP Address: 192.168.1.50
Subnet Mask: 255.255.255.0
Default Gateway: 192.168.1.1
As you can see, this information shows the IP address, subnet mask, and default gateway being used for the Local Area Connection Ethernet adapter. When you want more details, you type ipconfig /all to display additional information including the physical (MAC) address of the adapter, DHCP status, DNS servers used, and host information, such as
Windows IP Configuration
Host Name: salespc09
Primary Dns Suffix: cpandl.com
Node Type: Unknown
IP Routing Enabled: No
WINS Proxy Enabled: No
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix:
Description: Linksys LNE100TX Fast Ethernet
Physical Address: EA-BF-C2-D4-EF-12
Dhcp Enabled: Yes
Autoconfiguration Enabled: Yes
IP Address: 192.168.1.35
Subnet Mask: 255.255.255.0
Default Gateway: 192.168.1.1
DHCP Server: 192.168.1.50
Lease Obtained: Sunday, January 18, 2006 1:25 PM
Lease Expires: Monday, January 26, 2006 1:25 PM
Here a computer with the fully qualified DNS name salespc09.cpandl.com is configured to use DHCP and has an IP address of 192.168.1.35 with subnet mask 255.255.255.0. Because the IP address was dynamically assigned, it has specific Lease Obtained and Lease Expiration date and time stamps.
If you type netsh interface ip show config at a command prompt, you can obtain similar, albeit abbreviated, configuration information, such as
Configuration for interface "Local Area Connection"
DHCP enabled: No
IP Address: 192.168.1.50
SubnetMask: 255.255.255.0
Default Gateway: 192.168.1.50
GatewayMetric: 1
InterfaceMetric: 0
Statically Configured DNS Servers: 192.168.1.56
Statically Configured WINS Servers: None
Register with which suffix: Primary only
As you can see, these are all ways to obtain similar information about the TCP/ IP configuration.
Netsh also gives you the means to save the IP configuration so that the settings can be recreated simply by running a Netsh script. If you want to save the IP settings to a file, type:
netsh interface ip dump > FileName
where FileName is the name of the file to which you want to write the IP configuration information. When you dump the IP configuration, the file contents will be similar to those in Listing 15-1.
Listing 15-1: IP Configuration Script
 |
# ----------------------------------
# Interface IP Configuration
# ----------------------------------
pushd interface ip
# Interface IP Configuration for "Local Area Connection"
set address name="Local Area Connection" source=static
addr = 192.168.1.50 mask=255.255.255.0
set address name="Local Area Connection" gateway=192.168.1.1
gwmetric=1
set dns name="Local Area Connection" source=static addr=192.168.1.56
register = PRIMARY
set wins name ="Local Area Connection" source=static addr=none
popd
# End of interface IP configuration
|
Listing 15-1 is a Netsh script that you can run using the syntax
netsh -c "interface ip" -f FileName
Consider the following example:
netsh -c "interface ip" -f corpsvr02-ipconfig.txt
In this example, you run a Netsh script called corpsvr02-ipconfig.txt using the Interface IP context to apply the IP configuration defined in the script. One of the key reasons for creating a configuration dump is so that you have a backup of the IP configuration. If the configuration is altered incorrectly in the future, you could restore the original configuration from the script.
Examining IP Address and Interface Configurations
The Netsh Interface IP context provides several commands for viewing IP address and interface configurations. Here, an interface refers to a network adapter used by a computer to communicate over TCP/IP. Most computers have two interfaces: a local loopback interface and a Local Area Connection interface.
The local loopback interface is a pseudo interface that uses the IP address 127.0.0.1 and a network mask of 255.0.0.0. All IP messages sent over this interface are looped back to the computer and are not sent out over the network.
The Local Area Connection interface is created automatically when you install TCP/IP networking. There will be one such interface for each network adapter. By default the first interface is named Local Area Connection, the second is Local Area Connection 2 and so on.
At the Windows command line, you can view IP address configuration information by typing netsh interface ip show ipaddress. The output should be similar to the following:
MIB-II IP Address Entry
IP Address Mask BC Fmt Reasm Sz Interface
--------------- ------- ------ -------- -----------------
127.0.0.1 255.0.0.0 1 65535 Loopback
192.168.1.50 255.255.255.0 1 65535 Local Area Connection
| Note | Any interface that is disabled won’t be listed, meaning the interface is not available and cannot be configured. |
This information lists the IP address and mask for each interface configured on the computer. The reassembly size value, specified in the Reasm Sz column, indicates the reassembly size of IP datagrams is 65,535 bytes. This means IP datagrams sent or received using this interface are also 65,535 bytes in size. Blocks of data aren’t usually sent as 65,535 byte chunks of data, however. Instead, they are separated into fragments, which are reassembled upon receipt into a complete IP datagram. We’ll discuss IP datagram fragmentation in more detail in a moment.
To view more detailed information about interfaces, type netsh interface ip show interface. The output shows the detailed configuration of each interface, such as
MIB-II Interface Information
------------------------------------------------------
Index: 65539
User-friendly Name: Local Area Connection
GUID Name: {BG333345-F234-4335-25FB-43D3456B4464}
Type: Ethernet
MTU: 1500
Speed: 100000000
Physical Address: EA-BF-C2-D4-EF-12
Admin Status: Up
Operational Status: Operational
Last Change: 583112798
In Octets: 396173
In Unicast Packets: 1323
In Non-unicast Packets: 377
In Packets Discarded: 0
In Erroneous Packets: 0
In Unknown Protocol Packets: 0
Out Octets: 926667
Out Unicast Packets: 1351
Out Non-unicast Packets: 134
Out Packets Discarded: 0
Out Erroneous Packets: 0
Output Queue Length: 0
Description: Intel(R) PRO/100 VE Network Connection
| Note | As before, any interface that is disabled won’t be listed as an interface available or configured on the computer. |
| Tip | All Interface IP SHOW commands allow you to set the Rr= parameter to the number of seconds to use as a refresh interval. For example, if you wanted the interface statistics to be refreshed automatically every 30 seconds you would type netsh interface ip show interface rr=30. Once you set a refresh rate, you use Ctrl+C to exit the command so that no more updates are made. |
Here, the Local Area Connection interface is configured for Ethernet networking. The Ethernet maximum transmission unit (MTU) is 1,500 bytes when using Ethernet II encapsulation. This means each block of data transmitted is 1,500 bytes in length, with 20 bytes of this data block used for the IP header. The remaining 1,480 bytes are used as the IP payload for the data block. Thus, an IP datagram of 65,535 bytes would need to be fragmented in many smaller data blocks for transmission. These fragments would then be reassembled on the destination node.
Several other important parameters are given as well, including the following:
-
Speed Speed refers to the transmission speed used by the interface. In this case it is 100,000,000 (100 megabits per second). You may also see a speed of 10,000,000 (10 megabits per second) and other speeds as well.
-
Physical Address Physical Address is the MAC address encoded on the network adapter. The MAC address is used to uniquely track every device transmitting data over IP networks.
-
Operational Status The status of the interface. Unfortunately, this usually reads as Operational even if there is a problem with the interface. For example, if the network cable is unplugged the interface won’t report this as an error.
The interface details also provide useful information about the type of packets being received (in packets) and being sent (out packets). In general, packets are either unicast or nonunicast. Unicast packets are sent or received using a specific IP address. Nonunicast packets are sent or received to multiple IP addresses, and usually represent broadcast traffic. If a routing or delivery error occurs along the transmission path or at the destination, the computer discards the problem datagram and this action is recorded. In packets that were created using an unknown networking protocol are marked as Unknown Protocol Packets. Packets containing general errors are marked as erroneous.
Working with TCP Internet Control and Error Messages
Each packet sent over IP is a datagram, meaning that it is an unacknowledged and nonsequenced message forwarded by routers to a destination IP address. Each router receiving a datagram decides how best it should be forwarded. This means different datagrams can take different routes between the sending IP address (the source node) and the destination IP address (the destination node). It also means the return route for individual datagrams can be different as well.
Although IP provides end-to-end delivery capabilities for IP datagrams, it does not provide any facilities for reporting routing or delivery errors encountered. Errors and control messages are tracked by the Internet Control Message Protocol (ICMP). You can view ICMP statistics by typing netsh interface ip show icmp. The output from this command looks like this:
MIB-II ICMP Statistics
------------------------------------------------------
INPUT
Messages: 20302
Errors: 120
Destination Unreachable: 45
Time Exceeded: 88
Parameter Problems: 0
Source Quench: 4
Redirects: 6
Echo Requests: 966
Echo Replies: 966
Time Stamp Requests: 0
Time Stamp Replies: 0
Address Mask Requests: 0
Address Mask Replies: 0
OUTPUT
Messages: 20302
Errors: 120
Destination Unreachable: 45
Time Exceeded: 88
Parameter Problems: 0
Source Quench: 4
Redirects: 6
Echo Requests: 966
Echo Replies: 966
Time Stamp Requests: 0
Time Stamp Replies: 0
Address Mask Requests: 0
Address Mask Replies: 0
| Tip | These statistics can be refreshed automatically. Add the Rr=RefreshRate parameter, where RefreshRate is the number of seconds to use as the refresh interval. |
Here, you see detailed statistics on IP datagram messages being received (input messages) and those being sent (output messages). Decoding these statistics is easy if you know what you are looking for. The most basic type of IP datagram message is Echo. It is used to send a simple message to an IP node and have an Echo Reply echoed back to the sender. Many TCP/IP network commands use Echo and Echo Reply to provide information about the reachability and the path taken to a destination IP node.
Any error that occurs during transfer of an IP datagram, in or out, is recorded as an error. IP attempts a best-effort delivery of datagrams to their destination IP nodes. If a routing or delivery error occurs along the transmission path or at the destination, a router or the destination node discards the problem datagram and tries to report the error by sending a “Destination Unreachable” message.
A time to live (TTL) value is set in an IP datagram before it is sent. This value represents the maximum number of hops to use between the source and the destination nodes. “Time exceeded” messages are sent back to the IP datagram originator when the TTL value of the datagram expires. Typically this means there are more links than expected between the source and the destination node. Here, you’d need to increase the TTL value to successfully send traffic between the source and destination node. An expired TTL could also be an indicator of a routing loop in the network. Routing loops occur when routers have incorrect routing information and forward IP datagrams in such a way that they never reach their destinations.
A router or destination node sends a “Parameter Problem” message when an error occurs while processing in the IP header within an IP datagram. The IP header error causes the IP datagram to be discarded and if there are no other ICMP messages that can be used to describe the error that occurred, the “Parameter Problem” message is sent back to the source node. Typically this indicates an incorrect formatting of the IP header or incorrect arguments in IP option fields.
When a router becomes congested whether due to a sudden increase of traffic, a slow or sporadic link, or inadequate resources, it will discard incoming IP datagrams. When it does this, the router might send a “Source Quench” message back to the originator of the IP datagram telling the originator that datagrams are arriving too quickly to be processed. The destination node can also send “Source Quench” messages back to the originator for similar reasons. This isn’t done for each datagram discarded; rather, it is done for segments of messages or not all. The Internet Engineering Task Force’s (IETF) RFC 1812 recommends that “Source Quench” messages not be sent at all because they create more traffic on an already crowded circuit. If received, however, the originator will resend the related TCP segment at a slower transmission rate to avoid the congestion.
When subnetting is used, the first part of the IP address cannot be used to determine the subnet mask. To discover its subnet mask, an IP node sends an “Address Request” message to a known router or uses either an all-subnets- directed broadcast or a limited broadcast IP address. A router responding to the message sends an “Address Reply” message, which contains the subnet mask for the network segment on which the “Address Request” message was received. If an IP node doesn’t know its IP address it can also send an “Address Request” message with a source IP address of 0.0.0.0. The receiver of this message assumes the source IP node uses a class-based subnet mask and responds accordingly using a broadcast.
Before data is transmitted over TCP, the receiver advertises how much data it can receive at one time. This value is called the TCP window size. When transferring data, the TCP window size determines how much data can be transmitted before the sender has to wait for an acknowledgment from the receiver. The TCP window size is a 16-bit field, allowing for a maximum receive window size of 65,535 bytes. This means that a source node could send up to that amount of data in a single TCP window. Using the TCP window scale option, a receiver can advertise a larger window size of up to approximately 1 GB.
To calculate the retransmission time-out (RTO) value to use, TCP tracks the round-trip time (RTT) between TCP segments on an ongoing basis. Normally, the RTO is calculated once for every full window of data sent. In many network environments, this approach works well and prevents having to retransmit data. However, in a high-bandwidth environment or if there are long delays in any environment, this technique doesn’t work so well. One sampling of data for each window cannot be used to determine the current RTO correctly and prevent unnecessary retransmission of data.
To allow for calculating the RTT and in turn the RTO on any TCP segment, a timestamp value based on the local clock is sent in a “Timestamp Request” message. The acknowledgement for the data on the TCP segment echoes back the timestamp, which allows the RTT to be calculated using the echoed timestamp and the time that the segment’s acknowledgement arrived. These messages are recorded as Timestamp Requests and Timestamp Replies.
The final type of ICMP message of import in troubleshooting is the “Redirect” message. Redirect messages are used to tell the senders of IP datagrams about a more optimal route from the sender to the destination node. Because most hosts maintain minimal routing tables, this information is used to improve message routing while decreasing transfer times and errors. So when you see “Redirect” messages, you know traffic is being rerouted to a destination node.
Examining Fragmentation, Reassembly and Error Details
To dig deeper into IP datagram fragmenting and reassembly, you can type netsh interface ip show ipstats. The output should look similar to the following:
MIB-II IP Statistics
------------------------------------------------------
Forwarding is: Enabled
Default TTL: 128
In Receives: 24219
In Header Errors: 0
In Address Errors: 250
Datagrams Forwarded: 0
In Unknown Protocol: 0
In Discarded: 0
In Delivered: 23969
Out Requests: 20738
Routing Discards: 0
Out Discards: 0
Out No Routes: 0
Reassembly Timeouts: 60
Reassembly Required 0
Reassembled Ok: 0
Reassembly Failures: 0
Fragments Ok: 0
Fragments Failed: 0
Fragments Created: 0
As you can see the IP statistics show the default TTL value for out packets created on this computer for transmission. Here, the TTL value is 128. This means that there can be up to 128 links between this computer and the destination computer. If packets use more hops than that, the packets would be discarded and a “Time Exceeded” message would be sent back to the computer.
The In Receives value specifies how many inbound packets have been received. The actual number of packets used is represented by the In Delivered value and the difference between these values is due to in packets:
-
Received with errors, designated as either In Header Errors or In Address Errors.
-
Forwarded to other IP nodes, designated as Datagrams Forwarded
-
Using an unknown protocol, designated as In Unknown Protocol
-
Discarded, such as when a packet’s TTL is exceeded, designated as In Discarded
Here, there is a 250-datagram difference between the In Receives and In Delivered values, due to 250 inbound packets with addressing errors.
The number and disposition of outbound packets is also recorded. The number of packets being transmitted out is listed as Out Requests. Any errors coming back as a result of those transmissions are recorded according to type. If a router or other node sends back a “Destination Unreachable” message, this is usually recorded as a Routing Discard. Other types of error messages, such as “Parameter Problem” or “Source Quench” messages, might be recorded as Routing Discards or Out Discards. If there is no route out or if a “No Route” message is returned, they might be recorded as Out No Routes.
When data is transmitted outside the local network over routers, it is typically fragmented and reassembled as mentioned previously. Statistics for the reassembly of the original datagrams is recorded and so is the status of received fragments.
Examining Current TCP and UDP Connections
Firewalls and proxy servers can affect the ability to connect a system on the local network to systems on remote networks. Typically an administrator will have to open TCP or UDP ports to allow remote communications between a computer on the local network and the remote computer or network. Each type of application or utility that you use may require different ports to be opened. A complete list of TCP and UDP ports used by well-known services is stored in \%SystemRoot%\System32\Drivers\Etc\Services.
Sometimes, however, the tool you want to work with won’t have a well-known service associated with it and you may need to experiment a bit to find out what TCP or UPD ports it works with. One way to do this is to start the tool and use a TCP or UPD listener to see what ports become active.
Working with TCP
TCP ports are made available using a passive open, which basically says the port is available to receive requests. When a client wants to use an available port, it must try to establish a connection. A TCP connection is a two-way connection between two clients using Application Layer protocols on an IP network. The TCP endpoints are identified by an IP address and TCP port pair. There is a local TCP endpoint and a remote TCP endpoint, which can be used to identify loopback connections from the local machine to the local machine as well as standard connections from the local machine to a remote machine somewhere on the network. TCP connections are established using a three-way handshake. Here’s how that works:
-
A client wanting to use a port sends an active open request (SYN).
-
The local client acknowledges the request, sending a SYN-ACK.
-
To which the client wanting to use the port sends a final acknowledgement (ACK).
Data passed over a TCP connection is apportioned into segments. Segments are sent as IP datagrams that contain a TCP header and TCP data. When a connection is established, the maximum segment size (MSS) is also set. Typically, the maximum value for the MSS is 65,495 bytes, which is 65,535 bytes for the IP datagram minus the minimum IP header (20 bytes) and the minimum TCP header (20 bytes). Technically speaking SYN, SYN-ACK, and ACK messages are SYN, SYN-ACK, and ACK segments.
You can view current TCP connection statistics by typing netsh interface ip show tcpconn. Refresh the statistics automatically by adding the Rr=RefreshRate parameter. The output shows you which TCP ports are being listened on, which TCP ports have established connections, and which ports are in a wait state, as shown in this example:
MIB-II TCP Connection Entry Local Address Local Port Remote Address Remote Port State
------------------------------------------------------------------------
0.0.0.0 42 0.0.0.0 18520 Listen
0.0.0.0 53 0.0.0.0 16499 Listen
0.0.0.0 88 0.0.0.0 45165 Listen
0.0.0.0 135 0.0.0.0 2176 Listen
0.0.0.0 389 0.0.0.0 2256 Listen
0.0.0.0 1025 0.0.0.0 43054 Listen
0.0.0.0 1026 0.0.0.0 35016 Listen
0.0.0.0 1028 0.0.0.0 53398 Listen
0.0.0.0 3069 0.0.0.0 43189 Listen
0.0.0.0 3268 0.0.0.0 43230 Listen
0.0.0.0 3269 0.0.0.0 36957 Listen
127.0.0.1 389 127.0.0.1 1033 Established
127.0.0.1 389 127.0.0.1 1034 Established
127.0.0.1 389 127.0.0.1 1035 Established
127.0.0.1 389 127.0.0.1 1039 Established
127.0.0.1 1033 127.0.0.1 389 Established
127.0.0.1 1034 127.0.0.1 389 Established
127.0.0.1 1035 127.0.0.1 389 Established
127.0.0.1 1039 127.0.0.1 389 Established
127.0.0.1 3073 0.0.0.0 10251 Listen
192.168.1.50 135 192.168.1.56 1040 Listen
192.168.1.50 139 0.0.0.0 12369 Listen
192.168.1.50 389 192.168.1.50 3287 Established
192.168.1.50 3287 192.168.1.50 389 Established
192.168.1.50 3289 192.168.1.50 135 Wait
192.168.1.50 290 192.168.1.50 1025 Wait
Entries for 0.0.0.0 represent TCP broadcasts. Entries for 127.0.0.1 represent local loopback ports used by the local computer. You’ll also see entries on the physical IP address used by the computer back to the computer. Here, these are shown with the local and remote IP address set to 192.168.1.50. The entries you are most interested in are those in which the remote IP address is different from the local IP address; these represent connections to other systems and networks.
The Local Port and Remote Port columns show you how local TCP ports are mapped to remote TCP ports. For example, in this output local port 135 on IP address 192.168.1.50 is mapped to the remote port 1040 on IP address 192.168.1.56. Each TCP connection also has a state. The most common state values are summarized in Table 15-2.
| State | Description |
|---|---|
| Closed | No TCP connection currently exists. |
| Listen | An Application Layer protocol has issued a passive open function call to permit incoming connection requests on the specified port. This doesn’t create any TCP traffic. |
| Syn Sent | A client using an Application Layer protocol has issued an active open function call (SYN), which creates and sends the first segment of the TCP three-way handshake. |
| Syn Rcvd | A client using an Application Layer protocol has received the SYN and sent back an acknowledgement (SYN-ACK). |
| Established | The final ACK has been received and the TCP connection is established. Data can be transferred in both directions. |
| Wait | The TCP connection has been terminated and this has been acknowledged by both the local and remote client (FIN-ACK). |
You can view additional TCP statistics by typing netsh interface ip show tcpstats. The output should be similar to the following:
MIB-II TCP Statistics
------------------------------------------------------
Timeout Algorithm: Van Jacobson's Algorithm
Minimum Timeout: 300
Maximum Timeout: 120000
Maximum Connections: Dynamic
Active Opens: 381
Passive Opens: 443
Attempts Failed: 0
Established Resets: 26
Currently Established: 25
In Segments: 27852
Out Segments: 27518
Retransmitted Segments: 611
In Errors: 0
Out Resets: 4
The TCP statistics detail the following:
-
Minimum and maximum timeout values in use
-
Total number of active and passive opens since TCP/IP networking was started on the computer.
-
Any connections that were attempted but failed
-
Any connections that were established then reset
-
The total number of connections currently established
-
The number of TCP segments sent (in segments) and received (out segments)
-
The number of segments that had to be retransmitted
-
The number of segments with errors that were received (in errors)
Working with UDP
Unlike TCP which is connection-oriented, UDP is connectionless, meaning that UDP messages are sent without negotiating a connection. UDP ports are completely separate from TCP ports, even for the same port number. Because UDP messages are sent without sequencing or acknowledgement, they are unreliable, in stark contrast to TCP, which is very reliable. When you work with UPD, you have only a local address and local port pair, which represent the ports being listened on. You can view the related listener entries by typing netsh interface ip show udpconn. The output will be similar to the following:
MIB-II UDP Listener Entry
Local Address LocalPort
-------------------------------------------------
0.0.0.0 42
0.0.0.0 445
0.0.0.0 500
0.0.0.0 1030
0.0.0.0 1032
0.0.0.0 1701
0.0.0.0 3002
0.0.0.0 3103
0.0.0.0 3114
0.0.0.0 4500
127.0.0.1 53
127.0.0.1 123
127.0.0.1 1036
127.0.0.1 3101
127.0.0.1 3102
192.168.1.50 53
192.168.1.50 67
192.168.1.50 137
192.168.1.50 138
192.168.1.50 389
192.168.1.50 464
192.168.1.50 2535
Entries for 0.0.0.0 represent UDP broadcast ports. Entries for 127.0.0.1 represent local loopback ports used by the local computer. Entries on the physical IP address for a network adapter are ports which are listening for connections.
UPD messages are sent as IP datagrams and consist of a UDP header and UDP message data. You can view additional UDP statistics by typing netsh interface ip show udpstats. The output should be similar to the following:
MIB-II UDP Statistics
---------------------------------------
In Datagrams: 42640
In Invalid Port: 732
In Erroneous Datagrams: 20
Out Datagrams: 72217
The UDP statistics detail:
-
The total number of datagrams received on UDP ports.
-
The number of datagrams received on invalid ports and discarded.
-
The number of erroneous datagrams that were received and discarded.
-
The number of datagrams sent over UDP ports.
|
| < Day Day Up > |
|
EAN: 2147483647
Pages: 114