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: - Frame errors
- CRC
errors
- Interface and/or line protocol down
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: - In an IP environment, treat any
Ethernet encapsulation other than ARPA as very suspicious.
- In an IPX environment, check the encapsulations in
use on the servers as this is a common misconfiguration on the
router.
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: - Static maps
- Dynamic
maps (ARP)
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: - Devices may not respond to ARP or
Inverse-ARP requests because this has been specifically
configured, as with the command no frame-relay
inverse-arp.
- The Layer 2 or 3 information that is
cached may have physically changed. A router caches MAC
addresses for 14400 seconds, or 4 hours, by default.
- Invalid ARP replies are received which could be due to
misconfiguration, or as part of a Denial of Service (DoS) or
Man-in-the-middle security attack.
With the
exception of the “man-in-the-middle” attack, all of these
problems will result in similar failure characteristics:
- No Layer 3 communications between directly connected
devices.
- Layer 2 communications will appear ok.
- Appropriate debugs or console messages may indicate
encapsulation failures when a Layer 2 address is required but
can’t be obtained.
- Careful inspection of ARP caches
will reveal no Layer 2 address or an incorrect Layer 2 address.
Useful commands for troubleshooting suspected Layer
2 – Layer 3 mapping problems include: - show arp
– examine ARP cache.
- show cdp neighbor detail
– determine neighbors IP address.
- clear
arp-cache – force relearning of MAC addresses when a NIC
has been changed.
- show frame-relay map –
determine DLCI to IP address mapping.
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: - Framing errors
- Layer 2 to
Layer 3 addressing problems
- Encapsulation
mismatches
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:
- Inability to ping across a failing data link
- Routing protocols reporting the link as being down or
inaccessible
- Routing protocols reporting configured
neighbors as unreachable
- Console messages
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