Your shopping cart is empty!
For both real life and the exams, troubleshooting Frame Relay problems often means that you need to look at all the routers’ configurations and make sure that the configurations meet the requirements. The LMI types must match or be autosensed, the Layer 3 mapping information has been learned or statically maped, the right DLCI values have been associated with each subinterface. To be well prepared for the CCNA exams, you should review and memorize the many Frame Relay configuration options and what each option means.
The exams may have Frame Relay questions that require you to determine a problem without looking at the configuration.
A Suggested Frame Relay Troubleshooting Process
To isolate a Frame Relay problem, the process should start with some pings. Optimally, pings from an end-user host on a LAN, to another host on a remote LAN, can quickly determine if the network currently can meet the true end goal of delivering packets between computers. If that ping fails, a ping from one router to the other router’s Frame Relay IP address is the next step. If that ping works, but the end user’s ping failed, the problem has something to do with Layer 3 issues. However, if a ping from one router to another router’s Frame Relay IP address fails, the problem is most likely related to the Frame Relay network.
The engineer should ping the Frame Relay IP addresses of all the other routers on the other end of each VC to determine the following: Do the pings fail for all remote routers’ Frame Relay IP addresses, or do some fail and some work?
If a Frame Relay router’s pings fail for all remote routers whose VCs share a single access link, do the following:
Step 1: Check for Layer 1 problems on the access link between the router and the local Frame Relay switch (all routers).
Step 2: Check for Layer 2 problems on the access link, particularly encapsulation and LMI.
After resolving any problems in the first two steps, or if the original ping tests showed that the Frame Relay router can ping some, but not all, of the other Frame Relay routers whose VCs share a single access link, follow these steps:
Step 3: Check for PVC problems based on the PVC status and subinterface status.
Step 4: Check for Layer 2/3 problems with both static and dynamic (Inverse ARP) mapping.
Step 5: Check for Layer2/3 problems related to a mismatch of end-to-end encapsulation (cisco or ietf).
Step 6: Check for other Layer 3 issues, including mismatched subnets.
Layer 1 Issues on the Access Link (Step 1)
If a router’s physical interface used for the Frame Relay access link is not in an “up and up” state, the router cannot send any frames over the link. If the interface has a line status (the first interface status code) of down, the interface most likely has a Layer 1 issue.
Frame a Layer 1 perspective, a Frame Relay access link is merely a leased line between a router and a Frame Relay switch. As such, the exact same Layer 1 issues exist for this link as for a point-to-point leased line. Because the possible root causes and suggested troubleshooting steps mirror what should be done on a leased line.
Layer 2 Issues on the Access Link (Step 2)
If a router’s physical interface line status is up, but the line protocol status is down, the link typically has a Layer 2 problem between the router and the local Frame Relay switch. With Frame Relay interfaces, the problem is typically related to either the encapsulation command or the Frame Relay LMI.
If a router’s serial interface configuration omits the encapsulation frame-relay interface subcommand, but the physical access link is working, the physical interface settles into an up/down state. If the configuration is unavailable, the show interfaces command can be used to see the configured encapsulation type, which is listed in the first few lines of command output.
The other potential problem relates to the LMI. LMI status messages flow in both directions between a router (DTE) and Frame Relay switch (DCE) for two main purposes:
* For the DCE to inform the DTE about each VC’s DLCI and its status.
* To provide a keepalive function so that the DTE and DCE can easily tell when the access link can no longer pass traffic.
A router places the physical link in an up/down state when the link physically works but the router ceases to hear LMI messages from the switch. With the interface not in an up/up state, the router does not attempt to send any IP packets out the interface, so all pings should fail at this point.
The normal legitimate purpose for the LMI keepalive function is that if the link really is having problems, and cannot pass any data, the router can notice the loss of keepalive messages and bring the link down. This allows the router to use an alternative route, if one exists. However, a router might cease to receive LMI messages and bring down the interface because of the following mistakes:
* Disabling LMI on the router (with the no keepalive physical interface subcommand), but leaving it enabled on the switch or vice versa.
* Configuring different LMI types on the router (with the frame-relay lmi-type type physical interface subcommand) and the switch.
You can check for both encapsulation and LMI using the show frame-relay lmi command. This command lists only output for interfaces that have the encapsulation frame-relay command configured, so you can confirm whether the encapsulation frame-relay command is configured on the correct serial interfaces. This command also lists the LMI type used by the router, and it shows counters for the number of LMI messages sent and received.
show frame-relay lmi lists three important fields: Num Status Enq. Sent, Num Status msgs Rcvd, and Num Status Timeouts. If there is a discrepancy in these numbers, then you probably have an LMI misconfiguration. The timeouts counter counts the number of times the router expected to receive a periodic LMI message from the switch but did not.
If repeated use of show frame-relay lmi shows that the number of status messages received remains the same, the likely cause, other than a nonworking link, is that the LMI types do not match. The best solution is to allow for LMI autosense by configuring the no frame-relay lmi-type type physical interface subcommand, or configuring the same LMI type that is used by the switch.
PVC Problems and Status (Step 3)
The goal at this step in the troubleshooting process is to discover the DLCI of the PVC used to reach a particular neighbor and then find out if the PVC is working. To determine the correct PVC, particularly if little or no configuration or documentation is available, you have to start with the failed ping command. It identifies the IP address of the neighboring router. Based on the neighbor’s IP address, a few show command scan link the neighbor’s IP address with the associated connected subnet, the connected subnet with the local router’s interface, and the local router’s interface with the possible DLCIs. Also, the Frame Relay mapping information can identify the specific PVC.
Step 3a: Discover the IP address and mask of each Frame Relay interface/subinterface (show interfaces, show ip interface brief), and calculate the connected subnets.
Step 3b: Compare the IP address in the failed ping and pick the interface/subinterface whose connected subnet is the same subnet.
Step 3c: Discover the PVCs assigned to that interface or subinterface (show frame-relay pvc).
Step 3d: If more than one PVC is assigned to the interface or subinterface, determine which PVC is used to reach a particular neighbor (show frame-relay map).
Find the Connected Subnet and Outgoing Interface (Steps 3a and 3b)
Any time you ping the Frame Relay IP address of a neighboring router, that IP address should be in one of the subnets also connected to the local router. To find the interface used on a local router when forwarding packets to the remote router, you just have to find that common connected subnet.
Find the PVCs Assigned to That Interface (Step 3c)
show frame-relay pvc directly answers the question of which PVCs have been assigned to which interfaces and subinterfaces. If the command is issued with no parameters, the command lists about ten lines of output for each VC, with the end of the first line listing the associated interface or subinterface.
Determine Which PVC is Used to Reach a Particular Neighbor (Step 3d)
If the router’s configuration associates more than one PVC with one interface or subinterface, the next step is to figure out which of the PVCs is used to send traffic to a particular neighbor.
You cannot always find the answer without looking at other documentation. show frame-relay map can correlate the next-hop IP address and DLCI. Unfortunately, if the router relies on Inverse ARP, the local router cannot learn the mapping information right now either, so the mapping table may not have any useful information in it. However, if static mappings is used, the correct PVC/DLCI can be identified.
Routers use four different PVC status codes. A router learns about two of the possible status values, active and inactive, via LMI messages from the Frame Relay switch. The switch’s LMI messages lists all DLCIs for all configured PVCs on the access link, and whether the PVC is currently usable (active) or not (inactive).
The first of the two PVC states that is not learned using LMI is called the static state. If the LMI is disabled, the router does not learn any information from the switch about PVC status. So, the router lists all its configured DLCIs in the static state, meaning statically configured. The router does not know if the PVCs will work, but it can at least send frames using those DLCIs and hope that the Frame Relay network can deliver them.
The other PVC state, deleted, is used when LMI is working but the switch’s LMI message does not mention anything about a particular DLCI value. If the router has configuration for a DLCI (frame-relay interface-dlci), but the switch’s LMI message does not list that DLCI, the router lists that DLCI in a deleted state. This state means that the router has configured the DLCI, but the switch has not. The deleted state may mean that the router or switch has been misconfigured, or that the Frame Relay switch has not yet been configured with the correct DLCI.
Routers only send data over PVCs in an active or static state. Even if the PVC is in a static state, there is no guarantee that the Frame Relay network can actually send frames over that PVC, because the static state implies that LMI is turned off, and the router has not learned any status information.
If no problems are found on the router, other than an inactive PVC, the problem may be in the Frame Relay provider’s network and you may have to call them.
Finding the root cause of a problem related to a PVC in a deleted state is easy. The deleted status means that the Frame Relay switch’s configuration and the router’s configuration do not match, with the router configuring a DLCI that is not also configured on the switch.
Subinterfaces have a line status and protocol status code, just like physical interfaces. Because subinterfaces are virtual, the status codes and their meanings differ ea bit from physical interfaces.
Frame Relay configuration associates one or more DLCIs with a subinterface using two commands: frame-relay interface-dlci and frame-relay map. Of all the DLCIs associated with a subinterface, IOS uses the following rules to determine the status of a subinterface:
* down/down: All the DLCIs associated with the subinterface are inactive or deleted, or the underlying physical interface is not in an up/up state.
* up/up: At least one of the DLCIs associated with the subinterface is active or static.
It is useful to look at subinterface status when troubleshooting, but keep in mind that just because a subinterface is up, if it is a multipoint subinterface, the up/up state does not necessarily mean that all DLCIs associated with the subinterface are working.
Frame Relay Mapping Issues (Step 4)
If the routers still cannot ping each other’s Frame Relay IP addresses, the next thing to check is the Frame Relay address mapping information, which maps DLCIs to next-hop IP addresses.
On point-to-point subinterfaces:
* These subinterfaces do not need Inverse ARP or static mapping, because IOS simply thinks that the subnet defined on the subinterface is reachable via the only DLCI on the subinterface.
* The show frame-relay map command output still lists these subinterfaces, but with no next-hop IP address.
On physical interfaces and multipoint subinterfaces:
* They need to use either Inverse ARP or static mapping.
* The show frame-relay map command should list the remote router’s Frame Relay IP address and the local router’s local DLCI for each PVC associated with the interface or subinterface.
* If you’re using static mapping, the broadcast keyword is needed to support a routing protocol.
End-to-End Encapsulation (Step 5)
The end-to-end encapsulation on a PVC refers to the headers that follow the Frame Relay header, with two options: the Cisco-proprietary header and an IETF standard header.
A mismatched encapsulation setting on the routers on opposite ends of the link might cause a problem in one particular case. If one router is a Cisco router, using Cisco encapsulation, and the other router is a non-Cisco router, using IETF encapsulation, pings may fail because of the encapsulation mismatch. However, two Cisco routers can understand both types of encapsulation, so it should not be an issue in networks with only Cisco routers.
Mismatched Subnet Numbers (Step 6)
If two routers on either end of the PVC have mistakenly configured IP addresses in different subnets, the routers will not be able to ping one another, and the routing protocols will not become adjacent. As a last step, you should confirm the IP addresses on each router, and the masks, and ensure that they connect to the same subnet. Just use show ip interface brief/show interfaces, to verify.