Bedienungsanleitung Allied Telesis AR300 series

Inhaltszusammenfassung zur Seite Nr. 1

How To | Troubleshoot ISDN Connections
Introduction
Ideally, setting up an ISDN connection is very much a straightforward process:
Connect the router to the ISDN network interface.
Configure ISDN call definitions on the router. See How To Configure ISDN Calls On Allied
Telesis Routers, available from www.alliedtelesis.com/resources/literature/howto.aspx.
Send traffic.
However, for one reason or another, there are occasions when the setup process is not as
smooth as it should be.
So if y

Inhaltszusammenfassung zur Seite Nr. 2

How to troubleshoot ISDN Step 1: Is the router communicating with the ISDN network at the signalling level? When the router is connected to the ISDN network, either by plugging it into an NT1 if the router has an S/T interface, or by plugging it directly into the ISDN network if the router has a U interface, it establishes a low-level connection to the network. Basically, the router and the network device exchange a particular set of waveforms. When the router is satisfied that it has seen

Inhaltszusammenfassung zur Seite Nr. 3

If the interface is not activated, the reason could be one of the following: 1. The interface has been put into NT mode. On the AT-AR041 and AT-AR042 multi-BRI NSM modules it is possible to put the ISDN interface(s) into NT mode so that they can emulate a network switch interface. This can be useful for bench testing network configurations. To see which mode the ISDN interface is currently in, use the command: show bri=n state The first item in the output, Interface Type, will have either t

Inhaltszusammenfassung zur Seite Nr. 4

3. The cable connecting the router to the ISDN network or NTI is faulty. Try a different cable. 4. There is a fault in the ISDN network or the NT1. If options 1, 2 and 3 do not show any faults on the router, then contact your ISDN network provider and see if they can find the fault on their network. Step 2: Is the router communicating with the ISDN network at the LAPD level? Once the router has established a signalling connection with the network, it starts sending LAPD packets. LAPD (Link

Inhaltszusammenfassung zur Seite Nr. 5

If the LAPD is not alive, the reason could be one of the following: 1. The TEI mode has been set incorrectly. On a Basic Rate interface, the TEI mode ought to be automatic, so that the router does not mandate a TEI value to the switch, but will automatically accept whatever value is assigned by the switch. The TEI mode of the BRI interface is shown in the first line of output from the show lapd command. If the value shown in the TEI Mode column is automatic, then the interface has been set

Inhaltszusammenfassung zur Seite Nr. 6

When it comes to diagnosing an ISDN connection, the two most important columns in this table are Duration and Cause. The Duration column The Duration column tells you immediately whether or not the call ever connected. If the entry in this column is CLEARED, then the call never connected. If the entry in this column is a time, then the call did actually connect at the ISDN level. The reason why you were unable to get data across will be found at a higher protocol level (PPP or IP, IPX etc).

Inhaltszusammenfassung zur Seite Nr. 7

Also, a call that is closed due to PAP/CHAP authentication failure has a cause code of 16 because the call worked fine at the ISDN level, and was closed due to an indication from the PPP layer. In this case, if the local router decided that the PAP/CHAP username/ password it received were invalid, then the letter preceding the cause code will be U; if the remote router rejected the username/password sent to it, the letter proceeding the cause code will be N. 17 - User busy This is just like

Inhaltszusammenfassung zur Seite Nr. 8

There is an ISDN call definition on the receiving router that will accept the incoming call, but there is not yet a Layer 2 interface (PPP or Frame Relay) configured to use this call definition. There is an ISDN call definition on the receiving router that will accept the incoming call, and there is a Layer 2 interface configured over the call definition, but this particular call definition is already taken by another incoming call. Once you have tracked down where the configuration error