[c-nsp] Using DFC cards on a L2 6500/7600 system
Tim Stevenson
tstevens at cisco.com
Fri Jun 15 11:05:18 EDT 2007
At 03:35 PM 6/15/2007 +0300, Tassos Chatzithomaoglou observed:
>Watching the latest emails about DFC cards, i was wondering if the
>addition of WS-F6700-DFC3BXL cards to WS-X67xx modules would
>help a 6500/7600 in nay case, when used exclusively as a L2 switch
>(plus 802.1q tunneling/QoS/ACLs).
>
>
>According to CCO:
>
>The Cisco? Catalyst? 6500 Series Distributed Forwarding Card 3
>(DFC3), including WS-F6700-DFC3A (DFC3A), WS-F6700-DFC3B (DFC3B),
>WS-F6700-DFC3BXL (DFC3BXL), is an optional daughter card for
>CEF720-based line cards such as WS-X6704-10GE, WS-X6724-SFP,
>WS-X6748-SFP, and WS-X6748-GE-TX. The DFC3 provides localized
>forwarding decisions for each line card and scales the aggregate
>system performance to reach up to 400 mpps. The new DFC3B and
>DFC3BXL offer enhancements to support Multiprotocol Label Switching
>(MPLS) and Access Control Entries (ACE) counters on the Cisco 6700
>Series line cards. The DFC3BXL also has improved scalability to
>support one million IPv4 routes and 256-KB NetFlow entries.
>
>
>Does the 400 mpps forwarding performance have any relationship with
>L2 switching?
Yes, it is the same.
>Can you enable and use netflow on a L2 switch?
Yes, you can enable bridged NF. There are some limitations to this,
the most commonly annoying one is, the in & out ifindex are the same
(the vlan ID where the packet was bridged). Ie, the L2 switchports
are NOT provided.
Also, there are negative interactions between NF & other features,
like uflow policing. Lastly, in current s/w you must have an SVI with
an IP configured & in the up/up state to do bridged NDE, which is
obviously undesired (at best). This should be fixed in future s/w.
>Something i could think of is probably "better" QoS characteristics.
>
>6509#sh int gi1/1 capabilities | inc Model|QOS
> Model: WS-X6724-SFP
> QOS scheduling: rx-(1q8t), tx-(1p3q8t) <- CFC
>
>6509#sh int gi8/1 capabilities | inc Model|QOS
> Model: WS-X6724-SFP
> QOS scheduling: rx-(2q8t), tx-(1p3q8t) <- DFC3BXL
>
Yes, adding DFC changes the ingress queueing capability.
>Also when using non-fabric & fabric modules (yep, i know that's a
>no), the fabric ones with DFCs use "dCEF/flow through" as a
>Switching Mode, while the fabric ones without DFCs use
>"Crossbar/CEF/truncated". Is there any advantage of this on L2 switching?
Well, yes, this indicates the card is isolated from whatever happens
on the bus, so it operates w/maximum efficiency regardless of whether
a classic card is present or not.
>6509#sh platform hardware capacity system
>System Resources
> PFC operating mode: PFC3BXL
> Supervisor redundancy mode: administratively sso, operationally sso
> Switching resources: Module Part
> number Series CEF mode
> 1 WS-X6724-SFP CEF720
> CEF
> 2 WS-X6724-SFP CEF720
> CEF
> 6 WS-SUP720-3BXL supervisor
> CEF
> 8 WS-X6724-SFP CEF720
> dCEF
> 9 WS-X6408A-GBIC classic
> CEF
>
>6509#sh fabric switching-mode
>Global switching mode is Truncated
>dCEF mode is not enforced for system to operate
>Fabric module is not required for system to operate
>Modules are allowed to operate in bus mode
>Truncated mode is allowed, due to presence of DFC, CEF720 module
>
>Module Slot Switching Mode
> 1 Crossbar
> 2 Crossbar
> 6 Bus
> 8 dCEF
> 9 Bus
>
>
>6509#sh platform hardware capacity fabric
>Switch Fabric Resources
> Bus utilization: current: 0%, peak was 67% at 15:39:57 EET Thu Feb 15 2007
> Fabric utilization: Ingress Egress
> Module Chanl Speed rate peak rate peak
> 1 0 20G 0% 1% @09:35 15Feb07 1% 26%
> @16:36 15Feb07
> 2 0 20G 1% 3% @23:13 13Jun07 1% 1%
> @15:40 24May07
> 6 0 20G 0% 11% @06:41 30Mar07 0% 26%
> @16:36 15Feb07
> 8 0 20G 0% 26% @16:36 15Feb07 0% 11%
> @06:41 30Mar07
> Switching mode:
> Module Switching mode
> 1
> truncated
> 2
> truncated
> 6
> flow through
> 8
> compact
>
>
>
>Is there something else i'm missing?
Not really - DFCs give you fully distributed fwding for every type of
traffic, including L2. Most of the tables are symmetric across all
fwding engines (MAC & NF tables excepted).
A couple potential downsides with DFCs include:
- Layer 2 distributed etherchannels (EC configured as L2 port/trunk
with ports on different linecards): there have been a variety of
problems with this configuration so if you have it, run the latest
SXF rebuild to make sure you have all the fixes, and turn on the mac
table sync process as well (mac-address-table synchronize), it's off
by default.
- policing: each forwarding engine does aggregate policing
independently, so vlan-based agg policing (ingress or egress) is
enforced by each fwding engine to the configured rate, resulting in n
* rate packets potentially passing through the system, where n is the
# of fwding engines in the box
- CoPP/CPU RLs: CoPP & the CPU rate limiters essentially suffer from
the same limit as above for policing, the configured rates are
enforced per fwding engine so the CPU inband port is presented w/n *
rate packets.
HTH,
Tim
>--
>Tassos
>_______________________________________________
>cisco-nsp mailing list cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Data Center BU
Cisco Systems, 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.
More information about the cisco-nsp
mailing list