[c-nsp] Fabricpath on Nexus

[Tim Stevenson]

Please see inline below:

At 06:43 PM 3/28/2011, Tony Varriale uttered:

>On 3/28/2011 3:09 PM, Tim Stevenson wrote:
> >
> > For one thing you could provide up to 256 10G links between two boxes,
> > something you could not do with STP.
> >
>Is this 16 links active per path?  If so, what's the LACP game being played?
> >
>
>Tim and/or Lincoln, I was hoping you could comment on a couple of other
>things.
>
>1) The configuration guide recommends that all L2 FP gateways be
>configured as 8192 priority but do not specify them needing to be root.
>I'm guessing the docs want the gateways to be root.


Correct. I'll follow up with the doc team.


>  I think that would
>have some design implications (FHRP, as well as having to actively take
>root away from your existing bridge(s)).  Would you comment on why this
>is?  All ports need to be designated?  I assumed it was an optimal
>traffic flow to/from the FP domain and the ability to proactively stop
>loops.


Basically, the FP 'cloud' appears as a single unified root switch to 
any connected STP domains. Not only do the edge switches need to be 
root, but they should ideally use the same bridge priority as well.

Clearly this is a transitional benefit, being able to connect any 
arbitrary STP domains to your FP network. The end-goal would be to 
have no STP bridges, just FP switches, and hosts connected directly 
to FP edge ports.

We have the STP interop, and features like VPC+, to ease that 
transition and not make you rip & replace your entire network before 
you get any benefit.



>2) In the docs, it states that the FP network automatically presents a
>single bridge to all CE devices.  I assume when you enable FP on the
>gateways, it plays a vPC peer switch game of the single bridge ID
>presentation.  Or, something similar?


It's basically just a static BID (c84c.75fa.6000). All edge ports 
must be designated. If an edge switch is not root & we receive a 
superior BPDU, we block the port automatically.



>3) In the docs it recommends not to use the vPC peer switch feature.  Is
>this because of the multipath calc in the FP domain?  Any implications
>from a STP role change here?


Hm. Don't know offhand where that recommendation comes from, I can 
check into it. Maybe Lincoln knows.


>4) QoS?


FP requires new hardware (F1). That hardware is designed to be able 
to look at the appropriate offsets in order to make intelligent 
decisions based on COS/DSCP as well as the full L2/L3/L4 headers, 
regardless of whether FP encap is present or not.


>5) PLVAN type feature?

You can configure FP edge ports into PVLANs. A few guidelines here:
http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/fabricpath/configuration/guide/fp_advanced.html#wp1928818


Hope that helps,
Tim




>Thanks!
>
>tv
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
><https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at 
><http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/




Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Distinguished Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.