Unfortunately, issues with poor or incorrect routes are common. Most often they are a result of administrative errors in configuring the network. Occasionally, the routing protocol being used leads to the problem. It may seem surprising that many low cost routers and most servers that act as routers use the RIP (routing information protocol). That protocol is over thirty years old. Routers and servers that use the protocol choose the destination path based on the number of hops (links between routers). However, no provision is made to assess the speed or throughput of a link. Consequently, links might be in a path that is very slow when an alternative path is not being used. The best way to spot a slow link is probably to use a tool like trace route.
One factor that can be important is the network router discarding packets. Among routers, there is no provision for retransmission. So, the client or the server must determine that the routers have discarded packets. When they do, they will generally retransmit the packets. But you will recall that we pointed out that this retransmission can happen significantly later and cause TCP to slow down its rate of delivery by a large factor. So, why would routers discard packets? There are two main reasons. First, a packet arrives at a router and it is corrupted. That is, it has been damaged and the router detects that some information it contains is incorrect. It won’t try to determine the correct information. That would use valuable processor cycles. It discards the packet. In certain instances, it will send a packet called an ICMP (Internet Control Message Protocol) packet back to the source indicating the discard. But the packet is lost. The second thing that can happen is that the router simply becomes too congested (that is, busy). Nearly all routers will reach a threshold where they begin to randomly discard traffic in order to do as much correct routing as they can. Again, the impact on TCP applications in the client or the server can be devastating.
Printing problems are often associated with routing errors. For example, if a client is logged into a server that is on the other side of a WAN link, but chooses to print to a local printer, the print file may go across the WAN link to the print spooler (queue). When the printer is available, the file will return across the WAN link to reach the printer. This is a remarkably common occurrence and usually creates slow printing because WAN links tend to have limited bandwidth.
Another common problem results when devices on a network with a multi-homed router are misconfigured. Look at Figure 19. The network administrator originally had the phones with addresses ending .1 through .126 on one network. When the administrator ran out of addresses he decided to add the range from .130 through .190 by giving the router a second address 192.168.0.129 with a 26 bit mask. Apparently the users at .5 and at .83 found out that the user at .133 their desk and look up how to change the phone configuration. They changed their configuration to be consistent with the phone at .133. This will introduce a series of possible problems. If the phone is smart enough to discover the misconfiguration, it may do what a Windows® client would do. In the case .83, the phone would indicate that the configured default router (.1) is not on the local network.
However, devices such as phones have a very limited operating systems. It is much more likely that the phone will allow the configuration to be activated. In this case, traffic between .5 and .83 will be routed. If the router is not overworked, this misconfiguration could be hidden for years. However, when the router becomes overly congested with bursty traffic, it could begin to drop packets in calls between these two stations.
図 19: Incorrect Configuration
Packet loss along the route can be hidden. For example, suppose a pair of layer two switches are connected directly by a fiber or twisted pair connection. Because no other devices except the switches are normally monitoring such a link, bit errors can occur that cause the link to corrupt data frames. This problem will be dealt with by the end stations. If the applications that are losing the frames are TCP based, the effect will be significant. If the administrator of the network is using the link for VoIP transport, minor frame loss will not likely be evident in the quality of the calls. This can cause the administrator to search elsewhere for the cause and miss the actual source of the degradation in performance. Other causes of packet loss can be an over subscribed quality of service technique, bad NIC cards in routers, or intermediate wireless links (such as wireless bridges).