[Top] [Table Of Contents] [Prev] [Next] [Index]

Solving Frame Relay Problems        6


Use  Table 6-1 to identify and diagnose common Frame Relay problems.  
Table 6-1 Common Frame Relay Problems

Problem

Possible Cause

Possible Solution

The Frame Relay connection is not establishing.

  See "Preliminary Frame Relay Troubleshooting" on page 6-2.

  See "Diagnosing Frame Relay Problems with the DLCI List" on page 6-5.

The traceroute command reaches its target but ping does not (or vice versa).

Incorrect routing.

Use the show routes to-dest command to determine the routing (page 6-3).

This is a common routing problem over Frame Relay connections.

The show W1 command shows that the Frame Relay port does not have an ESTABLISHED status.

The PortMaster detects LMI packets being sent but not receiving any from the telephone company switch.

 See "Diagnosing an Inactive Frame Relay Connection" on page 6-8.

The Frame Relay port has an ESTABLISHED status, but the PortMaster cannot ping another node on the Frame Relay cloud.

 See "Determining Why You Cannot Ping Other Frame Relay Nodes" on page 6-10.

The PortMaster cannot detect IPX over the Frame Relay connection.

Incorrect routing table flag.

 See "IPX and Frame Relay" on page 6-11.

You need to break a Frame Relay connection.

 

 See "Diagnosing Subinterface Problems" on page 6-12.

Problems with Frame Relay subinterfaces.

 See "Diagnosing Subinterface Problems" on page 6-12.

Preliminary Frame Relay Troubleshooting

If you are having trouble with a Frame Relay connection, do the following:

  1. Wait a few moments.

    The process of establishing a Frame Relay link, learning the DLCI list, and learning the IP address through Inverse ARP can sometimes take a few moments.

  2. Use the show W1 command on the Frame Relay port to check the following:

    For information about configuring a PortMaster for Frame Relay, see the PortMaster Configuration Guide.

  3. Verify that you are using the correct cables and that they are attached securely to the correct PortMaster port.

    Not all WAN ports are capable of the same speeds. On an IRX-114 ports S1 and S3 can support up to T1/E1 speeds, while ports S2 and S4 can support only speeds up to 64Kbps.

  4. On the IRX and PortMaster 2R, verify the following:

  5. Verify that the CSU/DSU is providing the clock signal to the PortMaster.

    The CSU/DSU can generate the clock signal or receive it from the carrier.

  6. Verify that the CSU/DSU is configured properly.

  7. Monitor the Local Management Interface (LMI) or Annex-D keepalive packets.

    See "Monitoring LMI or Annex-D Packets" on page 6-4.

  8. If you have a Cisco router on the other end of the Frame Relay connection, verify that the following has been done:

Diagnosing Frame Relay Routing Problems

Because traceroute (UDP) takes its source address from the outbound interface and ping (ICMP) takes its source address from the Ether0 interface, routing can become confused. If either traceroute or ping reaches its target and the other does not, use the show route-to-dest command to determine if the outbound interface address and the Ether0 address are being routed differently. This is a common routing problem over Frame Relay connections.

For more information about this command, see "Finding a Particular Route" on page 3-22, or the PortMaster Command Line Reference.

Monitoring LMI or Annex-D Packets

The output from the set debug 0x51 command shows LMI or Annex-D packets being sent and received. Three successful exchanges of packets (sent and received) are required for a PortMaster to establish a Frame Relay connection.

To check packet transmissions, do the following:

  1. Make a note of the current keepalive timer setting. Then change the keepalive timer to once per second to speed up the troubleshooting process:

  2. Set the administrative console and the debug value:

    Command> set console
    Setting CONSOLE to admin session

    Command> set debug 0x51
    Setting debug value to 0x51

  3. Check the debug output:
The following is sample output from a successful LMI packet exchange:
(W1) LMI: Sending Sequence Exchange - Sequence 174
(W1) LMI: Received Sequence Exchange - Sequence 173
(W1) LMI: Sending Sequence Exchange - Sequence 175
(W1) LMI: Received Sequence Exchange - Sequence 174
(W1) LMI: Sending Full Status Enquiry - Sequence 176
(W1) LMI: Received Full Status - Sequence 175
DLCI List: 16

(W1) LMI: Sending Sequence Exchange - Sequence 177
(W1) LMI: Received Sequence Exchange - Sequence 176
(W1) LMI: Sending Sequence Exchange - Sequence 178
(W1) LMI: Received Sequence Exchange - Sequence 177

If you see only "Received Sequence Exchange" messages, the PortMaster is receiving packets from the remote end of the connection, but is unable to respond. The source of the problem is likely to be a misconfigured port, or a problem with the CSU/DSU. Use the show W1 command to verify that the modem status is DCD+ CTS+, and that the clock speed is correct. See the PortMaster Command Line Reference for more information about the show W1 command.
If you see only "Sending Sequence Exchange" messages, the PortMaster is sending packets to the remote end of the connection, but is not receiving a response. The source of the problem is likely to be with the remote end of the connection.
  1. Turn off debugging:

    Command> reset console
    Console RESET

    Command> set debug off

  2. Reset the keepalive timer interval to 10 seconds, or to the setting you noted in Step 1.
The 10-second setting lessens traffic for other users of the frame switch at the telephone company:
Command> set w1 lmi 10

Command> set w1 annex-d 10

Diagnosing Frame Relay Problems with the DLCI List

Use the DLCI list to help you diagnose problems with a Frame Relay connection:

Getting the DLCI List from the Telephone Company

Because Frame Relay terminology can be confusing, you can easily get the wrong DLCI numbers. Confirm with the telephone company that you have the correct DLCI numbers for each end.

If you are using static DLCIs, swap the DLCIs used at either end of the connection to see if this establishes a connection.

For example, if you are using DLCI 16 on the local router with an IP address of 192.168.20.2, and DLCI 17 on the remote router with an IP address of 148.168.65.34, do the following:

  1. Reconfigure the local router to use DLCI 17:

    Command> set W1 dlcilist 17:192.168.20.2

    Command> reset W1

  2. Reconfigure the remote router to use DLCI 16:

    Command> set W1 dlcilist 16:148.168.65.34

    Command> reset W1

Getting the DLCI List from set debug 0x51 Output

To get the DLCI list from set debug 0x51 output, do the following:

  1. Set the administrative console and the debug value:

    Command> set console
    Setting CONSOLE to admin session

    Command> set debug 0x51
    Setting debug value to 0x51

  2. Check the debug output.
After approximately six exchanges, the Frame Relay switch returns all the DLCI numbers programmed into it.
The following sample output illustrates LMI packet exchange. The DLCI number is 16:
(W1) LMI: Sending Sequence Exchange -Sequence 174
(W1) LMI: Received Sequence Exchange -Sequence 173
(W1) LMI: Sending Sequence Exchange -Sequence 175
(W1) LMI: Received Sequence Exchange -Sequence 174
(W1) LMI: Sending Full Status Enquiry -Sequence 176
(W1) LMI: Received Full Status - Sequence 175
DLCI List: 16
(W1) LMI: Sending Sequence Exchange -Sequence 177
(W1) LMI: Received Sequence Exchange -Sequence 176
(W1) LMI: Sending Sequence Exchange -Sequence 178
(W1) LMI: Received Sequence Exchange -Sequence 177

  1. Turn off debugging:

    Command> set debug off

    Command> reset console
    Console RESET

Getting the DLCI List with show arp

This command shows the static or dynamic DLCI numbers associated with their IP addresses. The DLCIs in the following example are 18, 19 and 17. The frm1 and frm4 keywords identify Frame Relay interfaces.

Command> show arp frm1
162.154.110.227 at 04:21 (18)
162.154.110.228 at 04:31 (19)


Command> show arp frm4
162.154.110.234 at 04:11 (17)

Diagnosing Frame Relay Problems with ifconfig

To verify that Frame Relay interfaces are operational, use the ifconfig command. The following example shows that the Frame Relay interfaces frm1 and frm4 are both operational:

Command> ifconfig

ether0: flags=1106<IP_UP,IPX_UP,BROADCAST,PRIVATE,OSPF>
inet 162.154.110.5 netmask ffffffe0 broadcast 162.154.110.31
area 0.0.0.0 ospf-state DR
ipxnet 95C66E00 ipxframe ETHERNET_802.2 mtu 1500

frm1: flags=1814<IP_UP,IPX_UP,FRAME_RELAY>
inet 162.154.110.225 netmask fffffff8
ipxnet 95C66EE0 mtu 1500

frm4: flags=198c<IP_UP,IPX_UP,FRAME_RELAY,PRIVATE,COMPRESS>
inet 162.154.110.233 netmask fffffffc
ipxnet 95C66EE8 mtu 1500

Diagnosing an Inactive Frame Relay Connection

If show W1 command output does not show a status of ESTABLISHED for the Frame Relay port, the connection is not active. (See "Displaying Port Errors and Status" on page 1-2, and the PortMaster Command Line Reference for information on the show W1 command.)

Do the following to set up debugging on the Frame Relay port:

  1. Set the polling interval for the keepalive timer to once per second to speed up the troubleshooting process:

  2. Set the administrative console and the debug value:

    Command> set console
    Setting CONSOLE to admin session

    Command> set debug 0x51
    Setting debug value to 0x51

  3. Check the debug output
The output allows you to monitor LMI activity. If the PortMaster can detect that LMI packets are being sent but is not receiving any from the telephone company switch, the output looks like the following example:
Enabling port S1
(S1) LMI: Sending Full Status Enquiry - Sequence 2
(S1) LMI: Sending Full Status Enquiry - Sequence 3
(S1) LMI: Sending Full Status Enquiry - Sequence 4

  1. If the PortMaster is detecting, but not receiving, LMI packets, verify that the PortMaster can send and receive data.
Put the CSU/DSU into a local loopback to cause each packet sent to the CSU/DSU to be looped back to the Frame Relay WAN port. This configuration is for testing purposes only; the line will not function while the CSU/DSU is in a local loopback.
  1. Look for the message "LMI: Apparent Loop."
If you see the message, the following is true:
  1. If you do not see the "LMI: Apparent Loop" message, do the following:

a. If you are using an IRX, PortMaster 2R, or PortMaster 2ER check that the RS-232-V.35 DIP switch (located next to the WAN port) is set correctly.

b. Verify that all cables are securely connected and that interface pinouts match the cable in points and directions. See the cable specifications in the hardware installation guide that came with your PortMaster.

c. Verify that the cable that came with the unit is attached to the PortMaster.

d. Replace hardware such as cables, CSU/DSU, and so on, with hardware you know is working correctly.

e. Check the ComOS release version. If a ComOS release prior to 3.7 is in use, upgrade to the current ComOS version. See the downloading instructions at http://www.livingston.com.
  1. If you get apparent loops and the port status is not ESTABLISHED, do the following:

a. Check that the CSU/DSU is set for external clocking. The telephone company provides the clock signal. You should also verify your CSU/DSU settings with the manufacturer.

b. Have the telephone company test the line, and ask for a printed copy of the test results.

Determining Why You Cannot Ping Other Frame Relay Nodes

If the show W1 command shows a state of ESTABLISHED but you still cannot ping other nodes on the Frame Relay cloud, you might have a connectivity problem. Use the following steps to determine the cause of the problem:

  1. Double-check the configuration for the port.

a. Make sure the same network number is in use for the entire cloud.

b. Verify that you have the proper netmask on the interface.
  1. Make sure you have the right signaling type (either LMI or Annex-D).
Reset the port after each setting.
  1. Use the traceroute command as follows.

a. Trace the route from your workstation to a router in the Frame Relay cloud.

b. Trace the route from the router in the cloud to your workstation.

c. Check for a gap in the list of router addresses displayed by the two traceroute commands.
 See "Tracing a Route" on page 3-21 for instructions on using traceroute.
  1. Make sure the gateway is set to the next upstream router.
The gateway should never be more than one hop away.
  1. Use ping again.
If you can ping the closest upstream link but nothing further, you might have a routing problem. See Chapter 3, "Solving Networking Problems."

IPX and Frame Relay

If you cannot detect IPX over a Frame Relay link or cannot get a list of NetWare servers via SLIST or NLIST, do the following to diagnose the problem:

  1. List the IPX routing table to see a list of IPX routes and where they are being routed.
 

Command> show ipxroute

Network

Gateway

Flag

Met

Ticks

Interface

--------

---------------

----

----

------

---------

00000000

00000008:00C005001C19

NS

1

0

ether0

00000008

00000008:00C005001C19

NLC

1

1

ether0

0A000100

0A000100:00C005001C19

NLC

1

1

ether0

See the PortMaster Command Line Reference for an explanation of show ipxroute command output.
  1. Check for an NS flag in the first entry.
This flag indicates a static network route. If you see this flag, do the following:

a. Reset your IPX gateway: Command> set ipxgateway Ipxaddress
IPX gateway reset


b. Reboot the PortMaster to clear the routing table: Command> save all
Command> reboot


c. Repeat Step 1.
If no NS flag appears, the PortMaster is configured correctly.
Note ¯ The ComOS requires that all IPX networks be known. The default network is not supported.

  1. Show the Service Advertising Protocol (SAP) table and check for entries from other servers and routers.
Use the Interface column to identify the interface through which the SAP packet entered the PortMaster and determine the packet's source-the Frame Relay network, the Ethernet, or the PortMaster itself.
 

Command> show sap

 

Server

Svc

Network

 

Host

Sock

Hops

Interface

--------

---

----------

 

-------------

----

------

----------

tie

5F2

000000AA:

 

00C0050101B2:

066B

1

frm1

ywing

5F2

00000008:

 

00C0050161A7:

066B

1

ether0

xwing

5F2

00000008:

 

00C00501200E:

066B

1

ether0

falcon

5F2

000000AA:

 

00C005021D12:

066B

1

frm1

calamari

5F2

00000008:

 

00C005001C19:

066B

1

Internal

If you see SAPs from the other side, your PortMaster is configured correctly.
  1. Set up IPX packet traces on both ends of the Frame Relay connection and observe exactly what the packets are doing.
 See "Tracing IPX Packets" on page 3-16 for instructions.

Diagnosing Subinterface Problems

Packets received on a subinterface can be identified as belonging to that subinterface only if the DLCI is properly entered in the DLCI table for that location. If you are having problems, do the following:

  1. Wait a few moments.
Subinterfaces come up after the primary interface. This process can take a few moments.
  1. Use the ifconfig command to verify that the primary interface and the subinterface are functioning.
In the following example, both frm1 (the primary interface) and frm3 (the subinterface) are functioning as indicated by the IP_UP and FRAME_RELAY flags:
Command> ifconfig

ether0: flags=6<IP_UP,IPX_DOWN,BROADCAST,LISTEN>
inet 149.198.64.250 netmask ffffff00 broadcast 149.198.64.255 mtu 1500

ether1: flags=12<IP_DOWN,IPX_DOWN,BROADCAST>
inet 0.0.0.0 netmask ffffff00 broadcast 0.0.0.255 mtu 1500

frm1: flags=814<IP_UP,IPX_DOWN,FRAME_RELAY>
inet 192.168.152.17 netmask fffffff8 mtu 1500

frm3: flags=98c<IP_UP,IPX_DOWN,FRAME_RELAY,PRIVATE,COMPRESS>
inet 192.168.152.33 netmask fffffffc mtu 1500

  1. Use the show S0 command to check the errors on the port being used by the primary interface.
Abort, cyclic redundancy check (CRC), or frame errors indicate a possible problem with the primary interface, which must be resolved before you can troubleshoot the subinterface. See "Displaying Port Errors and Status" on page 1-2for more information.
In the following example, port S1 shows no errors.
Command> show s1

----------------------- Current Status - Port S1 ---------------------------

Status: ESTABLISHED
Input: 681 Abort Errors: 0
Output: 1408 CRC Errors: 0
Pending: 0 Overrun Errors: 0
TX Errors: 0 Frame Errors: 0
Modem Status: DCD+ CTS+

Active Configuration Default Configuration
-------------------- ---------------------

Port Type: Netwrk Netwrk (Hardwired)
Line Speed: Ext 56000 Ext Clock
Modem Control: off off
Local Address: 192.168.152.17 192.168.152.17
Netmask: 255.255.255.248 255.255.255.248
Interface: frm1 (FRM,Routing) (FRM,Routing)
Mtu: 1500 0
Dial Group: 10
LMI Poll Int: 10 (seconds)

IP DLCI's: DLCI Address
----- ------------
16 192.168.152.18


Sub-Interface:

  1. Use the show location command to verify the following:

In the following example, the DLCI for the subinterface is 17:
Command> show location sub1
Location: sub1 Type: Sub-Interface
IP Address: 192.168.152.33 Netmask: 255.255.255.252
Protocol: Frame Relay Options: Quiet, VJ-Comp
Group: 10 Mtu: 1500

IP DLCI's: DLCI Address
----- ------------
17 192.168.152.34

  1. Check the packet count and errors on the subinterface with the show netstat command:

     

    Command> show netstat

     

     

     

     

     

    Name

    Ipkts

    Ierrs

    Opkts

    Oerrs

    Collis

    Resets

    Queue

    ether0

    72

    0

    39

    0

    0

    0

    0

    ether1

    0

    0

    0

    0

    0

    0

    0

    frm1

    0

    0

    1

    0

    0

    0

    0

    frm3

    0

    0

    0

    0

    0

    0

    0

  2. Verify that each DLCI has an associated IP address.
Replace Interface with the name of the Frame Relay interface. A list of interfaces can be shown with the ifconfig command (see Step 2). Verify that each DLCI has an associated IP address.
Command> show arp frm1
162.154.110.227 at 04:21 (18)
162.154.110.228 at 04:31 (19)


Command> show arp frm4
162.154.110.234 at 04:11 (17)
See the PortMaster Configuration Guide for information about how to configure the DLCI list.
  1. Reset the port if you change the DLCI list.

  2. Monitor the LMI or Annex-D keepalives.

    This verifies that the DLCI you have entered are correct. See "Getting the DLCI List from set debug 0x51 Output" on page 6-6.

  3. If you have a Cisco router on the other end of your connection, verify that one of the following has been done:



[Top] [Table Of Contents] [Prev] [Next] [Index]

spider@livingston.com
Copyright © 1998, Lucent Technologies. All rights reserved.