Windows 7 / Getting Started

Network

It will come as no surprise that Exchange is a network-intensive application. Good performance of an Exchange server requires fast connectivity between that server and the other servers in the local site, low latency connectivity to AD, low latency responses to DNS queries, and nonsaturated network connections. Not only that - all of this connectivity needs to be free of errors. To that end, there are other performance objects and counters that can help you learn the status of your network connection. These are shown in Table-4. You can see examples of Performance Monitor displaying the information contained in Table-4. Note especially that one interface does report errors against the Packets Outbound Errors counter, but it does not increase across the captured timeframe.

Table-4: Network I/O Objects, Counters, and Values
Performance ObjectPerformance CounterIdeal Value
Network InterfaceBytes Total/SecFor 10 Mbps NIC, less than 600 KB/sec; for 100Mbps NIC, less than 6 MB/sec; for 1 Gbps NIC, less than 60 MB/sec
Network InterfacePackets Outbound ErrorsZero
Network InterfacePackets Received ErrorsZero
TCPv4 or TCPv6Segments Retransmitted/SecLess than 2 percent of Segments Sent/Sec
TCPv4 or TCPv6Segments Sent/SecN/A

The TCPv4 and TCPv6 protocol objects contain counters that give basic high-level information about TCP connections and packets. TCPv4 is the version of the Transmission Control Protocol (TCP) that we have all known and loved for many years. TCPv6 is enabled by default in Windows Server 2008 and Windows Server 2008 R2. TCPv6 is fully supported by Exchange Server 2010 RTM. The important counter in those objects is Segments Retransmitted/ Sec. Unfortunately, that is not available as a percentage directly as a performance counter. However, as you will see in the next section, System Center Operations Manager can calculate the value for us - the % Segments Retransmitted/Sec. Performance Monitor cannot do that for us directly. When Segments Retransmitted/Sec is greater than zero, it indicates that TCP packets are being resent over the wire. This is generally due to a hardware or cabling fault and can cause network performance to be abysmal.

The Network Interface performance object contains counters that record information at a lower level of the OSI model than the TCP counters do. The Network Interface object records the individual packets received and/or sent across the wire before the packets are handed over to a specific protocol stack (such as TCP, UDP, or ARP). At this lower level, it is necessary to be concerned about the physical limitations of the network interface. Also, protocols such as TCP (upon which all of the email protocols such as SMTP, POP3, and IMAP are built) hide lower-level errors by requesting retransmissions of packets that exhibit errors. The upper-level protocols are not even aware that lower-level errors have occurred, unless they are ''fatal'' - that is, unless they cause the connection between the two computers to be terminated.

Within the Network Interface object, two counters are especially interesting when used to look at errors: Packets Outbound Errors and Packets Received Errors. Nonzero values indicate that errors have occurred ''on the wire'' since the last initialization of the interface. A few errors are normal (as any Ethernet-based protocol will experience an occasional collision-generated error). These values are much more indicative of an ongoing problem if they continue to increase every second - that is, when they are compared to other counters in the object, such as Packets Sent/Sec and Packets Received/Sec. Again, Operations Manager can perform calculations and use nonzero values of these calculations as alerting criteria. However, Performance Monitor does not have that capability natively.

The OSI model is used in the design of networking protocols, such as TCP/IP. The OSI model separates protocols into seven layers: Physical, Data, Network, Transport, Session, Presentation, and Application.
TCP/IP is a reliable connection-oriented protocol. In other words, the lower protocol layers are supposed to ensure that the data that is passed to the upper layers is error free. The upper layers are allowed to leave error detection and correction to the lower layers, thus simplifying the programming required to support the application. This does, however, make it difficult for the upper layers to be aware of issues that may be occurring at the lower layers.
So, a packet is a group of data that is transmitted at the lower layers. If the packet passes all error checking and detection, it is handed off to the upper layers and is then known as a data segment.
[Previous] [Contents] [Next]