STP Bridge Assurance, replaces UDLD?

[zztopping]

Reading from:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/stp_enha.html#Understanding_Bridge_Assurance

Does Bridge Assurance(only available on 6500 SXI and later it seems) replace UDLD between devices that support it? If not, what are the pros/cons of each? (Other than UDLD being supported on many Catalyst platforms)

[Giuseppe Larosa]

Hello Jonathan,

from the feature description and from a comment from Francois Tallet in another recent thread about loop guard, I think bridge assurance can be seen as an improvement to loop guard rather then a substitute to UDLD.

Hope to help

Giuseppe

[zztopping]

I kept reading yesterday after my post and came to the same conclusion. Thanks!

I tested this in my lab and could not get it to trigger between two 6500 sup720s running SXI(rpvst was turned on, show commands showed BA being turned on)

Also, the docs say that this should only be used between two devices that support BA(and will encounter problems if one side supports and other doesn't), and that BA is enabled globally and not by port.

Isn't this dangerous to have as a global feature to have turned on by default? My initial testing shows no problems, but if you follow the documentation, that may not always be the case.

[Francois Tallet]

Hi,

I don't think UDLD and any STP feature are competing because they operate at different levels. UDLD works at the link level whereas STP works at the port level. Meaning than on a channel, UDLD sees physical links while STP only sees a single port. As a result, STP features and UDLD are complementary. UDLD operates at a lower level and can remove a bad link from the topology, while STP can generally only block it, at best. This is important because once a bad link is gone, STP can start looking for an alternate path, instead of getting stuck with an inconsistent port.

Bridge assurance is rather a replacement for loopguard. Loopguard is a great feature but it still can fail, if the problem is existing before the link comes up. BA is configuration driven but is safer. If you can afford to put it everywhere, you're introducing a little bit more stability in your network. The idea is to get a bridge to drop traffic if it does not hear from its peer, instead of flooding. This behavior is a little bit closer to L3.

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DC_3_0/DC-3_0_IPInfra.html#wp1037297

Regards,

Francois

[zztopping]

I think my question has morphed from comparing it to UDLD(which I understand now) to its interaction with switches that do not support BA.

In my lab, I could not reproduce any problems between 6509s running SXI and a 3750 running 12.2(50)SE1.

The documentation leads me to believe that having BA turned on when you are interconnecting to other switches that do not support BA is very dangerous.

If that is correct, why is it on by default?

[Francois Tallet]

It's a matter of defining dangerous. Basically, if your neighbor does not support BA, the port is going to end up blocking. The rationale behind enabling BA globally is that it forces you to configure all your port types properly (network vs. edge), else they won't forward traffic. You're getting rid of the plug and play aspect...

In a way, not using BA is dangerous in a different way. If you don't configure an host port as edge, it might get temporary loss of connectivity for 30 seconds during network events. Something that might take some time to discover...

Regards,

Francois

[zztopping]

In my lab, it did not block a trunked 3750. For host ports we enable portfast, but do not specify the edge keyword, for trunked switch to switch links we do not specify a role at all.

The docs make it seem like with BA and RPVST turned on, a non-BA switch like the 3750 should be blocked...but in my testing it wasn't, hence my confusion on the matter.

[iyde]

As far as I remember, configuring portfast is telling the switch that this port is an edge port. I.e. you don't have to configure the edge keyword if you have configured portfast.

HTH.

[rzergoi]

Hi

you have to specify the "spaning-tree mode network" on your interface to activate BA on that interface.

Per default all ports are in "spanning-tree mode normal".

The syntax is more helpfull on Nexus switches than on Catalsyt....

Nexus:

spanning-tree port type normal (default) ==> no BA

spanning-tree port type network ==> BA

spanning-tree port type edge ==> Portfast

Catalyst:

no spanning-tree portfast (default) ==> no BA

spanning-tree portfast network ==> BA

spanning-tree portfast (edge) ==> Portfast

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/stp_enha.html#wp1055344

Enabling Bridge Assurance

Release 12.2(33)SXI and later releases support Bridge Assurance. By default, Bridge Assurance is enabled on all network ports on the switch. Disabling Bridge Assurance causes all configured network ports to behave as normal spanning tree ports. To enable or disable Bridge Assurance globally, perform this task:

Command	Purpose
Router(config)# spanning-tree bridge assurance	Enables Bridge Assurance on all network ports on the switch.

This example shows how to enable PortFast Bridge Assurance on all network ports on the switch, and how to configure a network port:

Router(config)# spanning-tree bridge assurance 

Router(config)# interface fastethernet 5/8 

Router(config-if)# spanning-tree portfast network 

regards

Rainer