Route My World!

A CCNA/CCNP Blog

Archive for May 26th, 2008

ICND2 OECG Chapter 14 Frame Relay Troubleshooting

Posted by Aragoen Celtdra on 26th May 2008

Some tips on what to look for when troubleshooting Frame Relay problems:

  • LMI types must match or be autosensed.
  • Layer 3 mapping has been learned or statically mapped.
  • The right DLCI values have been associated with each subinterface.

Suggested Frame Relay Troubleshooting Process

Typically, the first step that should undertaken when experiencing problems on the network is to issue a ping command. First, try pinging a host on one LAN using and end device from another LAN. If that fails, ping from one router to the other router’s Frame Relay IP. If that works but the end users fail, the problem might lie on some Layer 3 configuration or proper functionality. If the router to router ping fails, there could be a problem on the Frame Relay itself.

Here’s a few steps to undertake:

  1. Check Layer 1 problems on the access link (link between the routers and their corresponding Frame Relay switch)
  2. Check Layer 2 problems. Most commonly, it is an encapsulation or LMI problem
  3. Check for PVC problems based on the PVC status and subinterface status
  4. Check for Layer 2/3 problems with both static and dynamic (Inverse ARP) mapping.
  5. Check for Layer 2/3 problems related to a mismatch of end-to-end encapsulation (cisco or ietf)
  6. Check for Layer 3 problems, such as mismatched subnets

Layer 1 Issues on the Access Link

  • A Frame Relay access link is merely a leased line between a router and the Frame Relay switch from a Layer 1 perspective.
  • Layer 1 issues will usually be indicated by a “down” interface line status.
  • For Layer 1 troubleshooting, see Chapter 12 of the CCNA/ICND2 OECG, page 446

Layer 2 Issues on the Access Link

  • If the interface is in “up/down”, the link typically has problems between the router and the FR switch.
  • Problem is either on the encapsulation command or the Frame Relay LMI
  • If the encapsulation frame-relay command is omitted on the serial interface of a router, while the physical interface is working, the interface goes on an “up/down” state.
    • To see the configuration for the encapsulation type, use the show interfaces command.
  • LMI problems will also put the interface status on an up/down state.
    • To summarize again, LMI status messages has two main purposes:
      • DCE (FR switch) informs the DTE (router) about each VC’s DLCI and its status
      • To provide keepalive functions so that the DTE and DCE can easily tell when the access link can no longer pass traffic.
    • The normal purpose for the LMI keepalive function is to notice loss of messages received from the FR switch so that the router can bring down the interface that is problematic. This lets the router to choose an alternative route to pass data.
    • Configuration mistakes for LMI can also cause problems:
      • Disabling LMI on the router (using the no keepalive physical interface subcommand), but leaving LMI enabled on the switch, or vice versa.
      • Configuring mismatching LMI types on the router and the FR switch.
  • Check both encapsulation and LMI configurations using the show frame-relay lmi command.
    • This will list output for interfaces that have the encapsulation frame-relay command
    • At the same time, you can also confirm if the encapsulation frame-relay command is appropriately configured on the right serial interfaces.
      • NOTE: DTEs receive Status Messages from DCEs and sends Status Inquiries to DCEs

PVC Problems and Status

In troubleshooting this area, we need to make sure that we find the correct DLCI of the PVC in question.

Follow the following list to determine the DLCI used to send frames to the failed destination:

  • Using some show commands such as show interfaces and sh ip int brief, discover the ip address and mask of each Frame Relay interfaces and determine the connected subnets.
    • Anytime you ping the Frame Relay IP address of a neighboring router, the 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.
  • Compare the ip address of the failed ping command to the interface with the same connected subnet
    • After finding the results of the show commands above, just find the interface on the local router with an IP address in the same subnet as the IP address of the neighboring router and note what interface it’s configured on.
  • Use the command show frame-relay pvc to the discover the PVC assigned to that interface.
    • Once the interface/subinterface has been discovered on the previous steps, the show frame-relay pvc can tell you what DLCI is assigned to that interface.
  • If more than one PVC is assigned to the interface, determine the PVC using show frame-relay map command.
    • This command can help discover the correct DLCI to IP address. Unfortunately, if the local router relies on Invers ARP to get its DLCI, it cannot learn the mapping information right now because it is the interface that is down – therefore it cannot learn. This is where outside documentation can be helpful
  • PVC Status:
    • Active – PVC is currently useable. Learned through LMI status message
    • Inactive – PVC is down. Also learned through LMI status message
    • Static – Means DLCI is statically configured. If the LMI is disabled, the router doesn’t learn any information from the FR switch about PVC status. So the router lists all its configured DLCIs in the static state.
      • Implies that LMI is turned off.
      • The router can still send frames using those DLCIs but there is no way to tell if the frames can be delivered
    • Deleted – used when LMI is working but the switch’s LMI message does not mention anything about a particular DLCI value.
      • This state means that the router has configured the DLCI, but the switch has not
      • If the router has configurations for a DLCI (e.g frame-relay interface-dlci command), but the switch’s LMI message does not list the DLCI, the router lists that DLCI in a deleted state.
      • In real life, 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.
  • Subinterface Status
    • Just like physical interfaces, they have line/protocol status.
    • However, they are virtual, thus their meanings are a bit different.
    • Frame Relay configs assocatiate one or more DLCIs with a subinterface using the following commands:
      • frame-relay interface-dlci
      • frame-relay map
    • IOS follows the following rules to determine status:
      • down/down – All the DLCIs associated wiht the subinterface are inactive or deleted, or the underlying physical interfaces is not in an up/up state.
      • up/up – at least one of the DLCIs associated wiht the subinterface is active or static.
    • Note that in a mulitipoint subinterface where one of the PVCs is inactive but another is “up and up”, IOS leaves the subinterface in an up/up state.

Checking for Layer 2/3 Problems: Frame Relay Mapping Issues

  • On point-to-point 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:
    • Need to use either Invers ARP or static mapping
    • The show frame-relay map command should show the remote router’s FR IP address and the local router’s local DLCI for each PVC associated with the inerface or subinterface
    • If using static mapping, the broadcast keyword is needed to support a routing protocol.

Checking for Layer 2/3 Problems Related to Encapsulation

  • Make sure that the encapsulation used are matching.
  • If one router is a Cisco router using cisco incapsulation, and the other router is a non-Cisco router, using ietf encapsulation, the ping may fail because of a mismatch.

Layer 3 Issues: Mismatched Subnet Number

  • Confirm the IP addresses on each router, and the masks, and ensure that they connect to the same subnet.
  • To confirm, use show ip interface brief and show interfaces commands

Posted in Frame Relay | No Comments » | Print This Post

 

Route My World! is Digg proof thanks to caching by WP Super Cache