Re: OT: Bridge Assurance on vPC peer-link

Hey Joe,

Remember that bridging assurance is only compatible with switching platforms that support it (ie. N7K,6500). It isnt supported on other catalyst platforms and you would have to use the "spanning tree port type normal" command with switches that cant participate in BA.

It basically is sending and waiting to receive BPDUs from switching neighbors that support bridging assurance. So in the case of the 7ks, it is sending BPDUs and waiting to see if its vPC peer switch is sending BPDUs. If say one core of fibre gets cut on the vPC peer link(if you had a single vPC peer link member) , it puts that port into an inconsistent state. It is almost performing a similar role to UDLD.
But, bridging assurance goes a step further on the 7k and also effects forwarding of VLANs across the vPC peer link.
If you configure a VLAN on one of the 7k pair, and not the other, then bridging assurance will block the transmission of VLAN traffic for that specific VLAN on the vPC peer link.
When you run the command "sh vpc" you will see that the Layer 2 consistance check has failed because the configurations between the two Nexus 7000 dont match.
So the Nexus also uses BA to maintain consistency in what traffic is forwarded between the
7k pair of switches even if there is a configuration mismatch.
This is especially important as the Nexus 7ks form a single Layer 2 logical switch when vPC is configured. They maintain Layer 2 consistency between each other.
Thats why if the peer link fails, the Nexus 7k Master will disable the slave 7k switch via the vPC keep alive link to maintain Layer 2 integrity.
Only the Master switch will forward traffic.
Also remember that to other devices participating in the spanning tree domain, they see the 7k pair of switches as a single L2 switch.
Even though that the other switches think that they connect with a single STP neighbor, in actual fact the 7ks run their own internal STP process and elect a root bridge between them.
I would say that BA is used to provide L2 consistency for this internal STP process as well.

Hope this helps

Cheers
Chris Rae

On 28/06/2013, at 10:38 PM, Joe Astorino <joeastorino1982_at_gmail.com> wrote:

> So I've been preparing for a Nexus DC project and have run into learning
> about Bridge Assurance. I get what the protocol does in a traditional STP
> sense - If I stop receiving BPDU's from a neighboring switch, I assume
> there is a problem and move the port to inconsistent state. This works
> great for protecting against unidirectional links in a traditional STP
> environment. Very much like loop guard
>
> In the traditional sense, this makes perfect sense to me...port is in
> blocking state to prevent a bridging loop, stops receiving BPDUs from it's
> designated port, transitions to forwarding and causes a loop. Bridge
> assurance can fix that issue.
>
> What I'm struggling to understand is it's default application on a vPC
> peer-link. From what I understand both sides of the peer-link are ALWAYS
> forwarding. One side is always the designated port while the other is the
> root port. So...let's say I have this situation - SW1 peer link is the
> designated port and SW2 peer link is the root port. Say SW1 has a failure
> of sorts or there is a unidirectional link such that SW1 is sending BPDUs
> but SW2 does not receive them. Since both switch peer-links are ALREADY
> forwarding, what's the difference? It's not like I am going to transition
> from blocking to forwarding and cause a bridging loop. The loop prevention
> is still being done by the vPC rules (never forward a frame that came over
> the peer-link to vPC member ports)
>
> What am I missing?
>
> --
> Regards,
>
> Joe Astorino
> CCIE #24347
> http://astorinonetworks.com
>
> "He not busy being born is busy dying" - Dylan
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Fri Jun 28 2013 - 23:59:32 ART