Remote Collisions

If a collision occurs on the far side of a repeater, the over-voltage state is not observed on the near side of the repeater; what is seen is the beginning of an incomplete message. This shortened message does not have a proper FCS checksum, and is not long enough to meet the 64-byte (after the preamble) minimum requirement for CSMA/CD networks. This message is likely so short that the entire header block (with source and destination address) cannot be seen. Also seen is the "jam" signal occupying the last four octets of the shortened message.

Because a 10Base-T hub is essentially a multiport repeater with a segment dedicated to each station, or host, collisions on 10Base-T are nearly always detected as remote collisions. (A host on the network segment would have to be transmitting to sense a local collision.)

Like local collisions, remote collisions are a part of normal operation on a CSMA/CD network. Remote collisions could be caused by a number of factors:

• Overloaded network segment

• Faulty or marginal NIC

• Ethernet transceiver fault

• Ethernet repeater fault

• Illegal hardware configuration

• Ethernet cable fault

• Bad or poor host termination

• Bad grounding

• Induced noise on the segment (improperly shielded cabling) Late Collisions

Late collisions occur after the first 64 bytes in a frame, but only when the other symptoms of a "local" collision are present at the same time (over-voltage or simultaneous transmit and receive). Late collisions are detected the same as a local collision; however, the detection of the collisions happens too far into the frame. Generally, late collisions are seen only on a coaxial segment. (In 10Base-T networks, the monitoring station must be transmitting simultaneously to see a late collision.) Late collisions are caused by duplex mismatches, a faulty NIC or network that is too long, or exceeding the parameters as identified by network diameter calculations. One of the most probable causes of late collisions is marginal or failed hardware. In 10Base-T networks, late collisions are often detected simply as FCS errors.

The issue with late collisions is that they do not cause the NIC card to automatically attempt to retransmit the collided frame. As far as the NIC is concerned, everything went out fine, and the upper layers of the protocol stack must determine that the frame was lost.

Late collisions register on the Cisco router's Ethernet interface as collisions and are generally the result of extended cable lengths in the network. To summarize, late collisions might be caused by a number of factors, including the following:

• Duplex mismatches

• Faulty or marginal NIC

• Ethernet transceiver fault

• Ethernet repeater fault

• Too many repeaters on the segment (violation of the "5-4-3" rule or number of Class I/II repeaters in use)

• Illegal hardware configuration or cable length

• Ethernet cable fault

• Bad or poor host termination

• Bad grounding

• Induced noise on the segment (improperly shielded cabling)

The following steps should be taken to correct issues with regard to late collisions:

1. Use a protocol analyzer to check for late collisions.

Late collisions should never occur in a properly designed Ethernet network.

Late collisions usually occur when Ethernet cables are too long or when too many repeaters are in the network, violating the "5-4-3" rule.

2. Check the diameter of the network and make sure it is within specifications. Output Queue Drops

On a Cisco router, the number of output queue drops should not exceed 100 in any hour.

No formula exists to determine this number. The output from the show interface ethernet port clearly provides this information, as the following demonstrates.

Last input 0:00:00, output 0:00:00, output hang never Output queue 0/40, 0 drops; input queue 0/75, 2 drops Five minute input rate 61000 bits/sec, 4 packets/sec Five minute output rate 1000 bits/sec, 2 packets/sec

Output queue drops are registered if the interface is not able to clear up the queue as fast as the router is sending (queuing) the packets.

NOTE

The IOS 10.0 and higher code has two output processes. The 9.1 (9.14) and lower code has only one output process.

Drops indicate that the router is overpowering the interface. On a LAN, this would likely be a busy or congested LAN segment, preventing frames from getting out on the wire. These frames usually carry data packets that would be mainly process-switched in the router, such as routing updates, Novell SAPs, access list control, and helpers.

NOTE

Process-switching is defined as an operation that provides full route evaluation and per-packet load balancing across parallel WAN links, with the router making a route selection for each packet. Process-switching is the most resource-intensive switching operation that the CPU can perform. Process-switching is contrasted by fast-switching, which is a Cisco feature whereby a route cache is used to expedite packet switching through a router.

NOTE

If many SAPs need to be sent out, the output process is busy just sending SAPs. This can result in poor performance of other applications on the router.

The output queue can be modified using the interface subcommand hold-queue xx out, where xx is a value. The default for xx is 40. The command path to change this configuration is as follows:

Router>enable Password: Router#:config t

Router(config)#interface en [Where n is the Ethernet interface number] Router(config-if)#hold-queue xx out

Was this article helpful?

0 0

Post a comment