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@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, tstev...@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.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
