This Technical Note describes troubleshooting tips for the Netopia Routers.
This Technical Note focuses on troubleshooting techniques for a Netopia Router using Frame Relay Data Link Encapsulation.
Below is a list of hardware and firmware loads that this Technical Note is based upon:
| Hardware | Firmware/Version | Installed Options |
| R5300/R5200/R5100 | 4.8.4 or later | T1, DDS or v.35 SA card |
| 4522/4522XL/4622/4721 | 5.3.4 or later | N/A |
None.
Frame Relay is an OSI Layer 2 data link protocol. Simply put frame relay allows a device to send information over a wide area network by dividing information into frames. Each frame has an address which a network device reads and forwards to the frames destination.
How do you troubleshoot frame relay with a Netopia router? Well the Netopia provides you with a couple of key features and logs that you can use in order better understand and troubleshoot frame relay events.
First thing to do when troubleshooting Frame Relay at the datalink layer is to double check that the router is synched on the physical layer. There is no reason to troubleshoot the Data Link Layer if the Physical Layer has not been cleared. Please refer to this technote on clearing the Physical Layer, NIR_036. If you have a green Ready Light on the Netopia then you are prepared to use this technote and move on to troubleshooting the data link layer.
Lets first start with choosing the data link encapsulation. Most users configure their profiles from 'Easy Setup' so for the purposes of this technote we will assume you are using 'Easy Setup'. >From the main menu go to 'Easy Setup' then you will see the field labeled 'Data Link Encapsulation...' hit Enter and choose Frame Relay.
(NOTE: For users of Cisco routers if you have Frame Relay chosen as a data link encapsulation be aware that this is Frame Relay IETF not Cisco Frame Relay. Cisco routers default encapsulation is generally 'Frame Relay' which is Cisco Frame Relay. Make sure the Cisco's data link encapsulation is Frame Relay IETF not just Frame Relay. Netopia routers can not be configured for Cisco Frame Relay).
If you have the Netopia set for Frame Relay the next parameter to be mindful of is the LMI type. In the Netopia LMI is configured via the Frame Relay Management Type within the second screen of 'Easy Setup'. From the main menu go to 'Easy Setup' then 'Next Screen'. Your choices are ANSI Annex D, ANSI Annex A, and LMI "Gang of Four". (The choice of LMI is very rare so in all likelihood you only have real world choices Annex A or Annex D. Ansi Annex D should always be your first choice. If you are not sure which LMI type to choose always start with ANSI Annex D. LMI is an integral part of most Frame Relay networks. For the purposes of this technote we will assume that your Frame Relay provider is using LMI. Always check with the telephone company or the Frame Relay Cloud provider for the LMI type configured on their frame relay switches. (There may be cases on some Frame Relay networks where LMI is not configured however these cases are more exceptions than the rule)
LMI Status: The Netopia has two main logs for detecting LMI problems. The first is the 'LMI Status' indicator. You can find this by starting from the main menu go to the 'Statistics/ Logs', and 'General Statistics' and look under LMI Status. Are you seeing send and receive LMI packets?
If the router incrementing LMI rx (received) and TX (transmit) packets then you know the Netopia is receiving LMI packets from the Frame Switch. If you see the transmit portion incrementing only then the Netopia is transmitting LMI but not receiving LMI packets. This may be the root of your Frame Relay problem.
Troubleshooting LMI: If you know that LMI is configured on your frame relay providers network and you are seeing NO increment on the LMI Status rx then check two different configuration items in your router.
1. LMI type: Double check this with your telephone company or frame relay provider.
2. The number of channels the T-1 line is configured for in the line properties. Go back to the main menu and the 'Easy Setup' profile. In the first screen of 'Easy Setup' how many channels is the Netopia configured for? For example if you have the Netopia configured for 2 Channels (128k as per the telephone companies instruction) try setting the Netopia to a full T-1 or 24 channels. Reboot the router and then recheck the LMI Status. Are you now seeing LMI rx packets?
Many telephone companies set the channels of the T-1 at a full 24 channels but cap the data rate via a Committed Information Rate or CIR on their network. Even though your CIR may be only 128k the T-1 physical properties may need to be configured for a full T-1. The provider may actually let you burst up to a full T-1 but will only guarantee 128k to their customers at any time. You need to know if this is truly a fractional T-1 line or a full T-1 which is being capped upstream on the frame relay providers network. As a rule of thumb first configure the channels for 64k/(your line speed)= # of channels. If this formula does not work then try setting the T-1 for a full T-1 at 24 channels. If neither of these changes allows you to start receiving LMI then call your Frame Relay provider and recheck the LMI type and number of channels configured for your T-1 line. Also ask to have a Frame Relay Switch technician double check the Frame Switch configuration for your Permanent Virtual Circuit (PVC). Explain to the telephone company that you are not receiving LMI from the frame switch but you are configured for the correct LMI type.
If the router is now receiving LMI packets then recheck the events in the 'Wan Event History'. Are you now detecting a DLCI? If so is the DLCI activated or does it just read "DCLI detected"? If you are detecting, activating, and attaching to a remote ip address then you may have your Frame Relay connection up and running. Do the appropriate Layer 3 trouble shooting such as pinging and telneting to remote devices from inside the Netopia router. You can find these utilities from the main menu Utilities--->Ping, or Utilities--->telnet. If you are successful with tests run from the router then you can check your Layer 3 and above tests (ping, trace route, and telnet) from workstations on the LAN.
Go to the 'Statistics and Logs' then 'Wan Event History'. The following are examples of Wan Event History from a properly working Netopia router connected with Frame Relay encapsulation in which a DLCI is NOT statically configured (this configuration is relying on inverse arp for the DLCI attachment). Netopia tech support recommends NOT defining DLCI's when first trouble shooting frame relay. Let the Netopia auto detect your DLCI values via LMI. If this does not work you may have quickly determined the root of your problem. Your DLCI values and T1 activation messages will be different depending on your connection.
DLCI Detected...DLCI Activated...DCLI Attachment:
-Date-----Time-----Event---------------------------------
11/28/01 09:48:58 IP: DLCI 18 attached to 172.16.1.2
11/28/01 09:48:53 FR: DLCI 18 active
11/28/01 09:47:53 FR: DLCI 18 detected
11/28/01 09:47:43 >>WAN: T1 1 activated at 128 Kbps
This is what you will see in a properly working frame relay configuration. At this point you could try some Layer 3 testing via a ping test to the remote ip where the DLCI is attaching. Can you ping the ip address the DLCI is attached to in the Wan Events? If so now do any appropriate Layer 3 IP connectivity testing (i.e. trace route or ping) to hosts and devices beyond the default gateway of the Netopia. Can you ping the DNS severs at your ISP? Can you ping your favorite web site by IP address? Can you ping the same address by name? If you can ping by IP but not by name then you are probably experiencing a DNS failure and not a Layer 2 or Layer 3 IP connectivity failure.
DLCI Detected...DLCI Activated...NO DCLI Attachment:
11/30/01 13:28:49 FR: DLCI 18 active
11/30/01 13:27:49 FR: DLCI 18 detected
11/30/01 13:27:39 >>WAN: T1 1 activated at 128 Kbps
11/30/01 13:27:36 --Device restarted---------------
This is commonly associated with two different problems. The first being that the router or remote device does not support inverse arp. The Netopia is trying to inverse arp in order to attach the DLCI (which is being detected) with the Remote IP Address of the remote device .The remote router may not support inverse arp. The Netopia's inverse arp is not obtaining a response. Try going to the main menu 'Quick Menus' then 'Frame Relay DLCI Configuration'. Hit Enter on 'Display/Change DLCI'. If you know the DLCI that is being detected in the Wan Event History you can statically define your DLCI in this field. Go to 'Add DLCI'. Change the DLCI to the value that you are detecting in the 'Wan Event History'. For instance in the example provided we would make the DLCI 18 and change the remote IP to 172.16.1.2. We would only know this value if the ISP informed us what the default gateway of the Netopia router should be for their network. In this case the default gateway and the remote ip are the same value since we only have one active PVC.
The screen will appear like the following:
DLCI Name: DLCI 18
DLCI Enabled: Yes
DLCI Number (16-991): 18
Remote IP Address: 172.16.1.2
You have now statically defined the DLCI, associating a DLCI with a remote IP. (If you are familiar with Cisco routers, this would be similar to a Frame Relay Map command) You should see events similar to ones listed below:
-Date-----Time-----Event--------------------------
12/20/01 12:35:15 FR: DLCI 18 active
12/20/01 12:35:15 IP: DLCI 18 attached to 172.16.1..2
12/20/01 12:34:04 FR: DLCI 18 statically defined
12/20/01 12:34:04 >>WAN: T1 1 activated at 128 Kbps
12/20/01 12:34:01 --Device restarted---------------
Note: If the DLCI is statically defined within the Netopia, the WAN Events will indicate DLCI attached whether or not the the router has detected and actually attached to the remote router. If the DLCI is not statically defined, the router will attempt to use inverse arp to detect the Remote IP Address. Thus, an attachment in WAN events when the DLCI is not statically defined is an accurate indication that the Netopia has received a response from a remote device. Whether this is the IP or device you intended to attach to or not is an important note. It is possible that the PVC was created to the wrong router. This may be indicated by an DLCI attachment to an incorrect IP address. Check with the administrator of the remote router to be sure that you are attaching to the correct IP address.
-Date-----Time-----Event---------------------------
11/30/01 13:27:49 FR: DLCI 18 detected
11/30/01 13:27:39 >>WAN: T1 1 activated at 128 Kbps
11/30/01 13:27:36 --Device restarted---------------
This is the rarest of all the described scenarios. If the DLCI is being detected but not activated this may be a problem with the frame switch up stream. There is no setting in the Netopia which would not allow the DLCI to be activated. If normally detected the DLCI should be activated. Contact your Frame Relay provider to double check the configuration of your local frame switch.
By following the troubleshooting steps in this Technical Note, this should eliminate connection or communication problems between the Netopia Router and remote equipment over a Leased Line. If the Leased Line still does not work properly, please contact the Telephone Company or Leased Line provider. They will be able to check the Leased Line configuration and perform loopback and bit-error tests to determine the source of any Leased Line problem.