Re: OT: Bridge Assurance on vPC peer-link

Hey Joe,

Can you clarify what you mean by "ALREADY a loop"?

Remember that vPC peer link best practice (oops did I just say that ;) ),
calls for multiple 10Gb links coming off different line cards in the same
Nexus 7k. These links are then bundled into a layer 2 port channel and
configured as a trunk between the 7k pair.
So from a 7k perspective there are no loops.
Once the vPC configuration is complete both chassis share L2 state across the
vPC peer link.

In your example below, dont confuse the 7k to 7k vPC peer link connection with
the vPC MCEC port channel to the 3750X.
When the vPC port channel member ports are configured (one one each 7k
chassis), the form a single port channel between the chassis (a vPC port
channel). You can see this when you issue the command "sh vpc" you will see
the vPC port channels listed, their state and what VLANs are being forwarded
across them. If there was a configuration mismatch you would also see these
listed. So from a Nexus switch pair perspective they have a single port
channel to a single 3750X.
Once you have configured the etherchannel on the 3750X and as long as both the
7k and the 3750X have managed to negotiate the port channel (ie. LACP or PAgP)
then the port channel will come up. The STP topology will have no loops as
there will just be a single switch (3750X) with a single connection
(etherchannel) to another single switch (7k x 2 operating as a single L2
switch via vPC).

Remember the 7k pair of switches form a single L2 switch because of vPC, much
like a pair of 6500s form a single logical/L3 switch through the VSS feature.
The main difference is that with the Nexus (and the applies to the 5k as well)
you have to configure each Nexus individually for vPC whereas the 6500 is
configured as one single switch with VSS.
Nexus vPCs main role is to provide an active/active, non-blocking layer 2
network topology.
STP is a fail safe mechanism for vPC because vPC controls the traffic flow
across the vPC port members using different hashing algorithms to control
load.

The vPC loop avoidance mechanism is an interesting discussion and one that
seems to have alot of confusion. In a steady state network traffic doesnt
cross the vPC peer link but it doesnt mean it cant. OSPF can form an adjacency
across the vPC peer and route traffic.
What the loop avoidance does is stop traffic that just existed say one of the
3750X uplinks, looping back down another vPC MCEC switch link. It doesnt mean
it cant or wont pass across the vPC peer link of there was a link failure for
example.

Also, Bridging assurance is an STP enhancement like LoopGuard, BPDUGuard etc
etc. It is there to cater for specific failure scenarios that will arise on
the Nexus.
You might find that the Nexus cant accurately detect its vPC peer switch has
gone down without Bridging Assurance. The Nexus vPC technology has tight
controls around looping that traditional STP hasnt been able to cater for.
That why the vPC slave switch get practically shut down when the vPC peer
link drops because of all the potential loops vPC has been containing.

This Cisco Best practice guide has some interesting info I thought might
help....

http://www.cisco.com/en/US/docs/switches/datacenter/sw/design/vpc_design/vpc_
best_practices_design_guide.pdf#page7

Cheers
Chris Rae

On 29/06/2013, at 1:52 AM, Joe Astorino <joeastorino1982_at_gmail.com> wrote:

> 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
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>
>
>
> --
> 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
Received on Sat Jun 29 2013 - 13:29:13 ART