At times the framing problems may be minor and the interface may not recognize that a framing error has occurred. However, a misread bit will result in the Layer 2 frame having an invalid Cyclic Redundancy Check or CRC. This error will also be seen as an incrementing error count with the show interfaces command. In this case the CRC error count will be incrementing. Depending on the severity of the framing problem, the interface may be able to interpret some of the frames. Too many invalid frames may prevent valid keepalives from being exchanged, causing the show interfaces command to report: Interface is up, line protocol is down In summary, the following are all symptoms of a framing or related clocking problem:
Content 4.1 Characteristics of Data Link Layer Problems 4.1.5 Encapsulation errors While framing errors result in communication problems because an interface has trouble recognizing the bit positions, an encapsulation error occurs because the bits placed in a particular field by the sender are not what the receiver expects to see. This condition occurs when the encapsulation at one end of a WAN link is different from the encapsulation in use at the far end. If the protocol is one that expects to see appropriately formatted keepalives or correctly structured negotiation frames, such as PPP, then it is likely that the interface will enter the following state: Interface is up, line protocol is down However, if the Layer 2 protocol is a broadcast medium such as Ethernet, then keepalives are not exchanged between DTE devices and the interface will remain in the state: Interface is up, line protocol is up This will be so, even if incompatible Ethernet encapsulation types are being used. Fortunately, in an IP environment it is rare to change the Ethernet encapsulation type to anything other than the default ARPA. Ethernet encapsulation type mismatches are most likely to occur in an IPX environment where the default Ethernet encapsulation has changed over the years with different versions of Novell’s Netware server operating system. In the case of Ethernet, there are no tell tale signs that Ethernet encapsulation mismatches exist as the interface simply ignores encapsulation types for which it is not configured. The following guidelines should be adopted when troubleshooting Ethernet problems:
Content 4.1 Characteristics of Data Link Layer Problems 4.1.6 Layer 2 to Layer 3 address mapping errors When a Layer 3 packet is to be forwarded to a next hop address, the packet is encapsulated within a frame and a Layer 2 destination address is applied to the frame. Precisely how this Layer 2 address is determined depends on the Layer 2 protocol being used. For a point-to-point protocol such as PPP or HDLC, there are only two devices on each link. These protocols have no need to specifically address the far end device as there is only one possible recipient of the frame. In the case of PPP the frame always contains the all 1’s broadcast address and is therefore intended for any device at the far end of the link. Because of the nature of point-to-point protocols, it is unlikely that a Layer 2 to Layer 3 address mapping error will occur. In topologies such as point-to-multipoint, Frame Relay, or broadcast Ethernet, it is essential that an appropriate Layer 2 destination address be given to the frame. This will ensure its arrival at the correct destination. In order to achieve this, the network device must match a destination Layer 3 (IP) address with the correct Layer 2 address. Two mechanisms can be used to achieve this: When using static maps, an incorrect map is a common mistake. In an Ethernet environment this can easily occur when a NIC is replaced, since the NIC determines the MAC address. In a Frame-Relay environment it is possible for DLCIs to be incorrectly assigned by the Telco. In either case, simple configuration errors can result in a mismatch of Layer 2 and Layer 3 addressing information. In a dynamic environment, the mapping of Layer 2 and Layer 3 information can fail for the following reasons: With the exception of the “man-in-the-middle” attack, all of these problems will result in similar failure characteristics: Useful commands for troubleshooting suspected Layer 2 – Layer 3 mapping problems include:
Content 4.1 Characteristics of Data Link Layer Problems 4.1.7 Critical characteristics – no network layer connectivity Total failure of Layer 2 always results in a loss of network layer connectivity as the Layer 2 frames are required to encapsulate and transmit packets. Layer 2 failures include: Regardless of the cause of the Layer 2 problem, the Layer 3 symptom will be the same; a loss of connectivity. This could reveal itself in a number of ways: These symptoms are similar to those experienced when Layer 3 fails. It is necessary for the troubleshooter to distinguish between a Layer 2 and a Layer 3 failure. To specifically test Layer 2 connectivity use the show cdp neighbors command. If two neighboring devices can see each other using the show cdp neighbors command and yet it is not possible to ping between the devices, there are two explanations. First, the problem may lay with Layer 2 to Layer 3 addressing, or, second, it is in fact a Layer 3 problem.
Content 4.1 Characteristics of Data Link Layer Problems 4.1.8 Upper layer component operation A failure at the data-link layer will have a profound effect on those layers above it. A failure at the data-link layer level can be either total or intermittent. A total failure at the data-link layer level will completely prevent communication at higher layers. However, the effects of intermittent errors at the data-link layer will depend on the particular Layer 2 protocol in use. If the Layer 2 protocol is designed to implement reliable communications such as X.25, then it may be difficult to identify Layer 2 problems from the behavior of the upper layers. This is because the Layer 2 protocol will simply retransmit any lost frames. If frames are