Backup load command puts Bri Int in stanby mode with Protocol down

[tteslicko]

When I put the backup load command and designated bri 0 as the backup on the serial int, I notice that this happened on show int:

BRI0 is standby mode, line protocol is down

Hardware is BRI with U interface

and this happened on show isdn stat:

Newburgh-6>sh isdn stat

The current ISDN Switchtype = basic-dms100

ISDN BRI0 interface

Layer 1 Status:

DEACTIVATED

Layer 2 Status:

Layer 2 NOT Activated

Spid Status:

TEI Not Assigned, ces = 1, state = 1(terminal down)

spid1 configured, spid1 NOT sent, spid1 NOT valid

Layer 3 Status:

0 Active Layer 3 Call(s)

Activated dsl 0 CCBs = 0

Question now is will this backup interface still know enough to dial in the event of an outright primary line failure. (Live Environment....)

I guess I better make sure that the modem works(..sweat...)

[Richard Burts · Accepted solution]

This is normal behavior. When you configure the serial interface to use BRI as backup interface, the IOS puts the BRI into standby. In this state the BRI can not place a call and can not receive a call. If the primary serial interface fails (goes protocol down) then the BRI will come out of standby and go active.

While it is configured as standby there is not much you can do to test the BRI and make sure that it works. I have known some customers who want to test the BRI to be sure that it can work if they need it. So on a periodic basis they change the config to remove the BRI as backup to the serial, place a test call on the BRI (or receive a test call), and then put the backup interface back into the config.

HTH

Rick

[tteslicko]

Really informative...I was just about to deduce that it could only be used for either or. There is a real haze around Cisco Documentation sometimes. Thanks much buddy!!

[jduffek]

best bet is to create a dialer profile, bind the bri to that profile and use the dialer interface(profile) as the backup interface...that way l1 doesn't get killed on your isdn...some providers will shut down thier end if yours is down for X amount of time.

jd.

[tteslicko]

I am of the opinion that the bandwidth on the Serial interface is still in use or balancing the load of the traffic. Is this not the case. I would think it would have to be. The slimmer backup line would take up the overflow only. Otherwise how would you expect a backupline to handle all the traffic that the primary couln't handle.

[tteslicko]

here's the deal here. The backup load threshold etc. puts the badboy into Standby. However,when i administratively bring the Serial Line on the UK side down to test regular backup function, it will not bring up the Bri Int out of Standby mode. I think that is precisely the reason you can't ping or test, or bring it up therefore by interesting packets. The commands at present are:

interface Serial0/0

description MCI CKT#ZABHJVW90001

bandwidth 256

backup delay 0 900

backup interface BRI0/0

backup load 70 20

no ip address

encapsulation frame-relay

no fair-queue

!

interface Serial0/0.102 point-to-point

bandwidth 256

ip address 10.250.130.2 255.255.255.0

frame-relay interface-dlci 102

!

(omitted)

dialer-list 1 protocol ip permit

[Richard Burts]

You have encountered one of the interesting aspects of using backup interface. The IOS is really quite smart here. It knows that the backup interface is to provide protection if there is a problem. When it sees you shut down the primary interface, it says that you must have intended for it to be down (since you entered the shutdown command on purpose) so it is not a problem and it does not bring the BRI out of standby. To be able to test the BRI you must produce a real failure situation. When I have needed to do this I would unplug the serial to force the backup to come active. This is one of the attractive aspects of using dialer profiles which will allow you to test functionality of the BRI without requiring an actual failure of the primary interface.

One other comment: I would suggest that you move the backup interface commands to the subinterface instead of having them on the main interface as you do here. If the backup interface is on the main interface then the main interface will have to fail before the backup will activate. As long as you can talk to the provider's frame relay switch the main interface will be up whether or not you can talk to the other end. If you move the backup interface commands to the subinterface then the backup will become active if the subinterface goes to protocol down state. With point to point subinterfaces (and especially if you use frame relay end to end keepalive) the subinterface will fail if you lose connectivity to the other end - which is probably what you want the backup interface to do.

HTH

Rick

[tteslicko]

thank you much..I read and re-read your original corrsespondence and i figured that, that just may be what you were getting at when you mentioned difficulty in testing. Right now. They were in a bind and wanted to utilize some of the ISDN bandwidth till British Telephone gets there with a new x.21 type of DSU. I couldn't see how I was going to get it to load balance by magic. Maximum paths seemed to have no effect. So I gave it static maps out to the remote netowrk that only work after the threshold is exceeded on the Serial line. Desperate..hey?? This in fact though sends all outbound traffic to those specified networks out the backup , thereby off loading some of the primary. After a clear counters and show int, they looked pretty decently balanced. Anyhooo...Thanks Big Man!!