Re: OT: Bridge Assurance on vPC peer-link

Hey Joe,

See answers under your questions....

Hope it helps
Chris

On 01/07/2013, at 8:45 AM, Joe Astorino <joeastorino1982_at_gmail.com> wrote:

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

The STP process will be running on both the 5ks (internally between each other) and on the 3750X.
It won't be blocking at all unless you haven't configured an ether channel between the 5ks and 3750X.
show spanning tree on the 3750x should show the port channel listed as the Root port and forwarding.

> What has to happen for that to occur?

STP will start blocking when there are multiple links between the 3750X and the 5k switches that aren't in a port channel. It's exactly the same as if you had two 3750X switches connecting multiple ports between each other. Spanning tree would look for loops in the Layer 2 topology and start blocking ports to prevent that.

> Seems the vPC based loop prevention logic is what is running the show.

vPC loop prevention only stops traffic that has come from a vPC port channel member port from returning back down another member port. vPC is facilitating an active/active topology, something that STP can't do. It uses the loop prevention mechanisms to accomplish this.

> Does that whole thing have to somehow break down and fail for STP to step
> in and start blocking links?

STP is still running.
It has to elect a Root bridge, which Nexus vPC pair do between them with their internal STP process. Once this is worked out between the Nexus switches, it uses the Internal STP Root bridge details to then elect a Root bridge with its external STP partners. ie. the 3750x.

vPC doesn't replace STP. It is a technology that allows the virtualization of multiple Nexus chassis into a single Layer 2 device. STP is then overlaid onto vPC. STP will still check the topology for loops and block links appropriately.

> How does that work?
>
> An example would be if you had something like this......

Nexus 5k A-----vPC peer------Nexus 5k B
      | | | |
  Port Chan A Port Chan B
     | | | |
3750X A --------Port Chan C------3750X B

I hope the "diagram" comes out okay.
Imagine that Port channel A and B are dual homed
to each Nexus 5k. They are configured as a vPC port channel on each 5k.

This topology, even though I am using vPC port channel represents a looped topology. vPC will be providing active/active connectivity to each 3750X, but because of the link between the 3750X switches, we have introduced a loop.
The spanning tree domain will converge and move to block one of those links. So vPC loop prevention will stop packets looping back down to the 3750X switches, but STP will be looking to provide a loop free topology across the larger Layer 2 domain.

>
>
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Mon Jul 01 2013 - 09:57:16 ART