Trouble shooting

 

Verification:

1, The first step is always to confirm that the interfaces are properly configured.

The show interfaces command displays how the encapsulation is set up, along with useful Layer 1 and Layer 2 status information, including:

  • LMI DLCI
  • LMI type
  • Frame Relay DTE/DCE type

2, The next step is to look at some LMI statistics using the show frame-relay lmi command. The figure displays a sample output that shows the number of status messages exchanged between the local router and the local Frame Relay switch. Ensure that the counters between status messages being sent and received are incrementing. This validates that there is active communication between the DTE and the DCE.

Also look for any non-zero Invalid items. This helps isolate the problem of Frame Relay communications between the carrier’s switch and the client router.

3, Use the show frame-relay pvc [interface interface] [dlci]command to view PVC and traffic statistics. This command is also useful for viewing the number of BECN and FECN packets received by the router. The PVC status can be active, inactive, or deleted.

The show frame-relay pvc command displays the status of all the PVCs configured on the router. You can also specify a particular PVC.

After the statistics are gathered, use the clear counters command to reset the statistics counters.

Wait 5 or 10 minutes after clearing the counters before issuing the show commands again.

Note any additional errors. If you need to contact the carrier, these statistics help in resolving the issues.

4, To clear dynamically created Frame Relay maps that are created using Inverse ARP, use the clear frame-relay inarp command, as shown in Figure 1.

A final task is to confirm whether the frame-relay inverse-arp command resolved a remote IPv4 address to a local DLCI. Use the show frame-relay map command to display the current map entries and information about the connections.

Frame Relay for IPv6 uses Inverse Neighbor Discovery (IND) to obtain a Layer 3 IPv6 address from a Layer 2 DLCI.

Example: Verify Inverse ARP

The output shows the following information:

  • 10.1.1.9 is the IPv4 address of the remote router, dynamically learned via the Inverse ARP process.
  • 302 is the decimal value of the local DLCI number.
  • 0x12E is the hex conversion of the DLCI number, 0x12E = 302 decimal.
  • 0x48E0 is the value as it would appear on the wire because of the way the DLCI bits are spread out in the address field of the Frame Relay frame.
  • Broadcast/multicast is enabled on the PVC.
  • LMI type is cisco.
  • PVC status is active.

When an Inverse ARP request is made, the router updates its map table with three possible LMI connection states( PVC status). These states are:

  • ACTIVE – Indicates a successful end-to-end (DTE to DTE) circuit.
  • INACTIVE – Indicates a successful connection to the switch (DTE to DCE) without a DTE detected on the other end of the PVC. This can occur due to incorrect configuration on the switch.
  • DELETED – Indicates that the DTE is configured for a DLCI that the switch does not recognize as valid for that interface.
Debug

If the verification procedure indicates that your Frame Relay configuration is not working properly, the next step is to troubleshoot the configuration.

Use the debug frame-relay lmi command to determine whether the router and the Frame Relay switch are sending and receiving LMI packets properly.

Look at the figure to examine the output of an LMI exchange.

  • out is an LMI status message sent by the router.
  • in is a message received from the Frame Relay switch.
  • A full LMI status message is a type 0.
  • An LMI exchange is a type 1.
  • dlci 102, status 0x2 means that the status of DLCI 102 is active.

The possible values of the status field are as follows:

  • 0x0 – The switch has this DLCI programmed, but for some reason it is not usable. The reason could possibly be the other end of the PVC is down.
  • 0x2 – The Frame Relay switch has the DLCI and everything is operational.
  • 0x4 – The Frame Relay switch does not have this DLCI programmed for the router, but that it was programmed at some point in the past. This could also be caused by the DLCIs being reversed on the router, or by the PVC being deleted by the service provider in the Frame Relay cloud.
Pages: 1 2 3