Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[J-series] ISDN Layer 1 and 2 are shown as up but the calls will not connect and unable to bring ISDN Layer 3 up

0

0

Article ID: KB25550 KB Last Updated: 26 Feb 2020Version: 2.0
Summary:
This article describes the issue of being unable to connect to calls, even though ISDN layer 1 and 2 are shown as up. Additionally, ISDN Layer 3 cannot be brought up.
Symptoms:
Unable to bring the ISDN Layer 3 up. The configuration is verified as correct:
cli> show isdn status
Interface: br-2/0/1
Layer 1 status: UP
Layer 2 status: UP
Cause:
Troubleshooting:

Check the output of the following commands:
 
  • show isdn history

  • show isdn calls

The output will be something like this:
user@host> show isdn history
Calling Called Interface Duration Direction
Number Number

551212 5552121 bc-4/0/0:1 58663   Dialing
If the router has an LAPD connection to the switch and an outgoing call is made from the router, it will send call setup messages to the switch. If the switch believes that the packet is valid and there are channels available in the ISDN network, it will forward it on to the router at the far end of the link.

The receiving router will then either accept or reject the call, depending on the contents of the packet. If the receiving router accepts the call setup request, the ISDN call will open and the routers will exchange data packets. If the call does not open, then obviously, no data will be exchanged. To determine whether calls are being opened, use the following command:
show isdn history
The output of the above command contains a record of the last few ISDN calls; successful or not.

The first thing you can see is the duration column.

Duration column

The Duration column immediately indicates whether or not, the call was 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 data was not sent across can be found at a higher protocol level (PPP or IP, IPX and so on). Typically, if the duration of the call was one or two seconds, then the call would have been closed due to a PPP negotiation failure. One of the most common causes of PPP negotiation failure is PAP or CHAP authentication failing.

The next factor to look at is the pppoe traceoptions to see if the authentication is failing. The most common mistake made by customers is the use of the wrong authentication method.

As a result, the ISDN calls never get through; even though the configuration (for interfaces dl, br, and so on) is perfect.
Solution:
Check the authentication method and credentials being used.
#show access
access {
     profile ISDN_Access {
         client ISDN1 chap-secret "$ABC123"; ## SECRET-DATA
         client ISDN2 chap-secret "$ABC123"; ## SECRET-DATA
     }
}
Most of the time, either wrong credentials or the wrong method (PAP or CHAP) will be used. Try tweaking the authentication parameters and when they match, you should be able to establish the ISDN Layer3 connectivity.
Modification History:
2020-02-26: minor non-technical edits.
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search