Backup Interface Command

lamav · ‎08-15-2009

Has anyone ever used this command?

I know it is typically used in a DDR environment, where the primary interface will have the "backup interface bri0" command configured under it to notify the router that the BRI0 interface is a backup to the primary serial interface.

I believe -- not sure about this -- that for the backup interface to come up, the primary interface will have to go to at least an 'up, down' state.

Anyway, I am wondering if it can be applied to etherne interfaces. Here is the topology I am dealing with:

Think of a triangle, with a Cisco 7606 at the top and two L@ appliances at the bottom.

Specfically, I have a Cisco 7606 router with a Ten GigabitEthernet interface configured as a router-on-a-stick configuration - 4 subinterfaces -- and it terminates on an L2 appliance that is for all intents and purposes a switch, but it performs carrier ethernet services, like PBB-TE tunneling.

In addition, there is another Ten GigabitEthernet interface configured as a route-on-a-stick on the same router - (4 subinterfaces, same IP addresses) and it teminates on another L2 carrier ethernet appliance that we would like for it to act as a standby to the other one.

Both L2 appliances have a trunk between them.

So, the objective is to keep one TE interface on the 7606 UP and the other to the secondary L2 appliance in a standby state using something like a backup interface mechanism.

Can this be done? With sub-interfaces involved, where would the "backup interface GE x/x/x" command be placed, assuming this is even feasible? Would it be under the main interface or under each of the subinterfaces?

example:

interface TE9/2

no ip address

backup interface TE9/3

interface 9/2.1

encap dot1q

ip address 1.1.1.1 255.2552.255.0

interface 9/2.2

encap dot1q

ip address 2.2.2.2 255.255.255.0

..and so on..

THEN...

interface TE9/3

no ip address

interface 9/3.1

encap dot1q

ip address 1.1.1.1 255.2552.255.0

interface 9/3.2

encap dot1q

ip address 2.2.2.2 255.255.255.0

I dont have access to my lab in NY, so I cant test the damn thing.

Choice 2 may be to use SVIs for the vlans, create a single trunk interface (no subinterface stuff), and then create another trunk to the other L2 appliance.

I think if this can be done, we wouldnt need the backup interface command becaus STP would shut one of those trunk ports down in the first place, so if the primary trunk ever went down, the other would come up...

Any thoughts?

The 7606 is running STP and so do the L2 appliances.

Giuseppe Larosa · ‎08-16-2009

Hello Victor,

I would take a different approach.

>> The 7606 is running STP and so do the L2 appliances.

I would configure both interfaces as L2 trunks and I would move L3 config to SVI interfaces.

Then STP will be able to manage the redundancy keeping one L2 trunk in forwarding state and the other one in blocking for all the involved vlans.

This should happen because on an 802.1Q trunk a cisco switch uses proprietary BPDUs with a multicast destination that should be forwarded by the L2 appliances transparently (because they cannot understand it it is not IEEE STP).

if the L2 appliances can interoperate with a form a STP it can even be better and you can control what link is in blocking state in normal conditions.

Hope to help

Giuseppe

lamav · ‎08-16-2009

Hey, Giuseppe:

Long time...

So, you are advocating for what I describe as choice 2, correct?

But, what do you tink of choice 1 (backup interface option)...would like to at least have some of your thoughts.

Also, you say...

"This should happen because on an 802.1Q trunk a cisco switch uses proprietary BPDUs with a multicast destination that should be forwarded by the L2 appliances transparently (because they cannot understand it it is not IEEE STP)."

Can you elaborate on this? Interesting...

Thanks

Giuseppe Larosa · ‎08-16-2009

Hello Victor,

I took a two weeks vacation with no internet access for family peace. :)

I was referring to the L2 tunneling tecnique introduced with PVST+: by using a different proprietary encapsulation LLC SNAP and a different multicast destination PVST+ BPDUs are treated as user multicast traffic by 802.1D standard switches allowing two cisco switches to talk with other devices in the middle.

So you should be fine using STP in any form and L2 trunks.

on low end switches there is something similar to backup interface that are called flex links and are seen as an alternative to STP.

see

http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/flexlink.html

I would use STP.

Hope to help

Giuseppe

lamav · ‎08-16-2009

Giueseppe....interetsing stuff. Didnt know that...where did you learn that from?

Anyway, I agree that leaving it to STP is the way to go.

How would STP treat a router on a stick interface? Even if we wanted to go with the STP solution, could the interface be left as-is or would we have to go with SVIs and a pure dotiq interface?

Thanks

Victor

Giuseppe Larosa · ‎08-16-2009

Hello Victor,

I've learned about flex links here in the forums but I didn't test it up to now.

To use correctly STP I would go with L2 trunks and SVIs to separate L2 and L3 functions and to have a single ip address per subnet that is what the device supports/expects.

Hope to help

Giuseppe