We have two methods of ISDN backup in our network. One uses the 'dialer watch' approach and is triggered based upon the loss of a default route at the device. The second method utilizes a floating static default route that activates when the normal default route goes away -AND- there is interesting traffic to send from the site. The first method relies on the 'dialer string' configuration under the BRI interface and can only be tested by failing the primary link. However, the second method utilizes the 'dialer map ip' approach under the 'dialer 1' interface, can be tested while the primary is up by pinging the IP address that is contained in the dialer map statement. Hope this helps.
As Daniel indicates, how you can test the ISDN backup depends on how your environment is configured. In addition to the dialer-watch and floating static route approaches some environments configure backup-interface as a way to implement ISDN backup. This approach requires taking the primary out of service to be able to test the backup.
So if the original poster will give some details of how the router(s) are configured, we might be able to give better advice about how to test it.
Thanks for posting the interface configurations. As I had wondered it does use backup-interface on the frame relay subinterface to initiate dial backup. As I indicated using backup-interface puts the inteface into a dedicated state and the primary must be taken out of service to test the backup. The good news is that in your configuration the ISDN is configured with dialer interfaces to get to the BRI. So the interface that is in the dedicated state is the dialer interface and the BRI interface can be used while the frame relay interface is functional. To be able to test the ISDN you would need to configure another dialer interface (probably dialer2) with most of the same parameters as dialer1. Then you could make a call using dialer2 to test the ISDN without disturbing dialer1 or the frame relay.
I assume that there are some routing statements that would direct traffic toward dialer1 if the frame relay stops working. You would need some similar statements for dialer2 to be able to test.
As a side note: I would have expected the BRI and the dialer1 to be configured with authentication (probably CHAP perhaps PAP) but do not see them. Are they there and you chose not to include them in what you posted, or are they not configured on the BRI or on the dialer1?
N functionality, not the connectivity to the remote end. If you want to verify that the ISDN functions and calls out then you can make a test call off the interface BRI. This will attempt to call a number that you specify. Some carriers offer a special loopback number that they use to test their service. You can try those numbers. If the ISDN dials out (Use debug ISDN q931) you can verify that your ISDN layer function.. It does not test router configurations and will not come up to your remote router..Good Luck...
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...