Sangoma Line Debugging

Introduction

One of the problems of being in Sangoma's line of business is that so often our products are installed in new Servers, with new DCEs, new cables, new telco lines, new switch settings and new routers or other interfaces at the other end. There are probably several billion combinations of wrong settings for this system, and only one right one.

In simple self defense, we have had to develop the best WAN debugging tools in the business, simply to preserve our sanity and the sanity of our valued customers.

The following will help you eliminate the 1026 possible bad settings and home in on the one that will get you properly connected.

The Monitor programs
In writing this paper, we have assumed that you are using a WANPIPE® router card. For customers using our other API or SNA based products, similar tools are available for line debugging

It is also assumed that the card is actually working properly in the host: There are no error messages on startup or on starting the router, and all the interfaces appear to be working properly.

The basic debugging tools are the Monitor programs: fpipemon for Frame Relay, ppipemon for PPP and cpipemon for CHDLC. They all work the same way.

The monitors are command line driven text applications under Linux®, FreeBSD® and BSDI® and windows applications under Windows® NT and Windows® 9x.

The monitor does not have to run on the same machine as the WANPIPE® card: as long as you can ping the machine, you can use the monitor anywhere.

The monitor works with a type of intelligent ping to a specified UDP port, default 9000. To turn off the monitor set the UDP port for WANPIPE® to 0. The "ping" must get to the WANPIPE® driver, and to do that, you need to specify an address that the routing stack will try to push through the WANPIPE® driver. From the WANPIPE® host, you can use the name of the interface, and we will automatically resolve a good IP address. Otherwise, from a LAN attached machine you will give the address of the other end of the link. You cannot use the address of the WANPIPE® driver itself from "above", because the loopback intercepts the "ping" before it reaches the driver. You can use the WANPIPE® address from "below" because the loopback does not interfere with that.

Under Windows®, set the Name or IP address to use under /File/Select Card. For Linux® and FreeBSD® etc. the IP address is explicit in every command.

For instance:

fpipemon -i 192.168.1.5 -u 9000 -c xm

will return the Modem Status of WANPIPE® using the default UDP port of 9000, and through which the address of 192.168.1.5 can be reached.

If the monitor times out, it is because:

• The IP address you have used is wrong: it cannot reach the driver, or the packet is being intercepted by the loopback. This is by far the most likely cause.
• The UDP port is wrong. The default on both monitor and driver is 9000.
• The card and driver have not really loaded properly. Usually you will have seen some kind of error message on loading.

First base: Is the line alive or dead?
Check the modem status: For the Windows® monitors, the modem status will be found under /Link Status/Modem Status for Frame Relay and similarly for PPP and CHDLC.

For Frame Relay using Linux®, SUN Solaris and FreeBSD® the command is:

The interface name is the name used for the the interface in the configuration setup, e.g. wanpipe1_fr16, the UDP port is also set up in the configuration. The actual command is after the -c, in this case, xm for read the modem status. The commands for ppipemon and cpipemon are mostly identical.

If DCD and CTS are DOWN (LOW), then the line is completely dead.

If DCD and CTS are UP (HIGH), then the receiver sees something that may possibly be a working line. This is a necessary, but not a sufficient condition for a working line.

Second base: Can you transmit and receive?
This is synchronous communications. As such, you can only transmit if there is a clock signal provided. You can learn  a lot about the state of the connection by a transmit test.

Start the line trace on the monitor. The Frame Relay command line for Linux®, SUN Solaris and FreeBSD® is:

The trace should show data being transmitted . This data will be repeated every few seconds, and represents the card's attempt to get a response from the other end of the line. If you do not see any received frames coming back from the network, let the trace run for 2 -3 minutes and then look at the Communications Error Statistics.

Under Windows® you will find them at /Link Monitor/ Comm Error Statistics for Frame Relay and /PPP Statistics/Comm Errors for PPP.

For Frame Relay using Linux®, SUN Solaris and FreeBSD® the command is:

The parameter Number of transmit interrupts missed should be 0. If it is not zero, then there is no transmit clocking on the line.

If this parameter is zero then you probably are set up for the right interface, and the DSU/CSU is providing you with a transmit clock signal.

Look to see if the trace shows receive data. If there is no receive data look again at the Communications Error Statistics. On a good line the count of CRC Errors and Abort Frames should be zero  or close to it. If any of these numbers are increasing rapidly (they will roll over at 255), then the problem is an incorrectly configured line.

If there are no CRC errors or aborts and no received data, then the problem is likely to be problem with the switch or router at the other end of the WAN link. (click here)

Third base: Can you get the link active?
On the trace, you can see data being both transmitted and received. Is the link logically connected?

Under Windows® look at  /Link Monitor/ Link Status for Frame Relay and /PPP Sate/PPP FSM Current State.

For Frame Relay using Linux®, SUN Solaris and FreeBSD® the command is:

If the Frame Relay Link Status is Active, or the PPP FSM Current State is Network Layer, or the CHDLC state is Active, then you have a working logical link to the next node on the network.

For the Point-to-Point topologies of PPP and CHDLC, this is all you need for a working link. For Frame Relay, you need also to make sure that the Logical Channel (DLCI) is active.

Under Windows® look at  /DLCI Monitor/ Configured DLCIs and statistics. The DLCI you have configured during configuration of your WANPIPE(TM) driver should appear in the Active window. If it appears in the Inactive window, then there is a:

problem with the connection or router at the other end of the Frame Relay cloud. (click here)

For Frame Relay using Linux®, SUN Solaris and FreeBSD® the equivalent command is:

*fpipemon -i <interface name or IP address> -u <UDP port, default 9000> -c cl

If there is both transmit and receive traffic, but the Link is not Active (CHDLC) or the PPP State is not at Network Layer (PPP), then the problem is that the two ends of the link have protocol compatibility problems.

If the links and Frame Relay DLCIs are active, you have a working WAN link.

Running for home: Can you ping?

If the links, DLCIs etc. show in the monitor as active, and you still cannot ping, then either:

• You have an IP encapsulation issue.
• You have a routing issue.