Re: OT: Bridge Assurance on vPC peer-link

Perhaps I can simply my question. Imagine you have the network I described
(2 nexus 5ks that connect to a 3750 in a vPC configuration). I keep
hearing that STP is run as a failsafe. At what point does STP start making
the decisions and blocking links? What has to happen for that to occur?
Seems the vPC based loop prevention logic is what is running the show.
Does that whole thing have to somehow break down and fail for STP to step
in and start blocking links? How does that work?

On Sat, Jun 29, 2013 at 9:21 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:

> Joe,
> I think this is just helping the vPC *distributed* L2 traffic control to
> prevent loops. Remember that it might be the case that you have more
> than one vPC, and it might even be the case that the connection between
> the two 5Ks goes through different vPCs.
>
> I would not say that the peer link is "forwarding" in the traditional
> sense though.
>
> You might want to check
>
>
> http://www.cisco.com/en/US/products/ps9670/products_tech_note09186a0080bf010e.shtml
>
> for some interesting info.
>
> -Carlos
>
> Joe Astorino @ 28/06/2013 14:52 -0300 dixit:
> > Thanks for the information Chris. I still don't understand it on a nexus
> > vPC peer-link in terms of loop prevention because there is ALREADY a
> loop.
> > It is just that vPC loop protection mechanisms are protecting against it
> > instead of STP.
> >
> > For example, let's say you had this design:
> >
> > Two Nexus 5Ks connected together in a vPC configuration. Then you have a
> > Cisco 3750 downstream that is dual homed to the 5K's. On the 5K end you
> > configure a vPC for the 3750 and on the 3750 you configure a regular old
> > etherchannel. What does the STP topology look like at that point? On
> the
> > 5K1 to 5K2 cross-link (the peer link) both ports are forwarding as one
> side
> > is the DP and the other side is the RP. The 5K1 --> 3750 port channel
> > interface is a DP so that is forwarding. The 5K2 --> 3750 port channel
> > interface is a DP so that is also forwarding. Finally on the 3750, the
> > port-channel interface is it's RP so that is forwarding. So, you have an
> > L2 loop. vPC deals with that loop with it's own mechanisms.
> Essentially,
> > any traffic received on the peer-link can not be sent out a vPC member
> > port.
> >
> > Now...Let's say you are NOT running bridge assurance on the peer-link and
> > the peer-link experiences a unidirectional link issue so that one side or
> > the other is not receiving BPDUs. Why would that even be a problem? The
> > vPC loop prevention logic still stands. Thus, I don't understand the
> point
> > of bridge assurance for protection of unidirectional links or STP failure
> > in this specific case...because STP is not doing the loop prevention in
> the
> > first place.
> >
> > I hope that makes sense and that somebody can shed some light on that
> > specific topic. Thank you all for your time!
> >
> >
> > On Fri, Jun 28, 2013 at 11:59 AM, Christopher Rae <chris.rae07_at_me.com
> >wrote:
> >
> >> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>

-- 
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