non-intrusive test on Backup Interface.

[calopez]

Hello,

I would like to perform a NON-INTRUSIVE testing of a backup-interface..but I am not sure if removing the Backup Interface command from the Primary interface will cause disruption..i.e. routing switched to backup, etc.

Here is the config.. Has anyone done non-disruptive testing on this scenario? I want to ensure no problems are caused as a result of my testing the backup serial interface:

Routing protocol used OSPF.

interface Serial0

no ip address

encapsulation frame-relay IETF

no ip mroute-cache

no logging event subif-link-status

logging event dlci-status-change

bandwidth 1544

no fair-queue

frame-relay lmi-type ansi

!

interface Serial0.2 point-to-point

backup delay 60 120

backup interface Serial1

ip address xx.xx.xx.xx 255.255.255.248

ip ospf network point-to-multipoint

bandwidth 512

no cdp enable

frame-relay interface-dlci 16

!

interface Serial1

ip address xx.xx.xx.xx 255.255.255.248

encapsulation ppp

no ip route-cache

ip ospf network point-to-multipoint

no ip mroute-cache

no logging event subif-link-status

bandwidth 1544

no cdp enable

ppp authentication chap

Thanks.

[tepatel]

Removing the "backup interface serial1" will bring the serial 1 interface out of "standby" mode and will become up/up (assuming correct config and connection). Now traffic will/will not go thru that link depending on the routing setup. Now you can configure both the links with equal ospf cost so that the traffic will be load balanced between those links. That is the best way to test. Else what exactly you mean by "non-disruptive"?

[calopez]

thanks for the reply. I meant by non-disruptive that no production traffic would flow over the backup link.. But since the backup Serial1 link has a lower cost than the primary link, then that would mean that OSPF will try to route production traffic over the backup link. Again, txs for the reply and mentioning the ospf cost.

[vcjones · Accepted solution]

Non-disruptive testing of "backup interface" configurations is a royal pain (not to mention a security nightmare). And if the need is to verify the correctness of the configuration (rather than the operation of the backup link) you must use disruptive testing. But if you just want to make sure the dial link still works what you can do is:

1 - Configure so the cost of the backup link is higher than the primary link.

2 - Configure a route through the backup interface to a test IP address never used in production.

3 - Remove the backup interface statement from the primary interface.

4 - From the remote router, ping the test IP address added in step 2.

5 - Verify that OSPF neighbor relations are established on the backup link.

6 - Restore the backup interface statement on the primary link (and any other "backup" statements which used to be there, such as delays).

7 - Verify that the backup link dropped correctly.

8 - Work on the justification to management to modify the configuration to use DDR or dialer watch so testing can be safely automated or executed by less skilled admins without needing the enable password/secret.

Good luck and have fun! Take a look at the dial backup white papers on my web site for some ideas, or if you're a real glutten for punishment, read chapters 4 and 5 in my book

Vincent C Jones

www.networkingunlimited.com