Introduction
This document lists FAQ on Catalyst 6500 Switches.
Questions
Q. What is the CFC used for?
A. The WS-F6700-CFC is a daughtercard that provides centralized forwarding for the 67xx linecards. The CFC is the base requirement for 67xx linecard operation and is a zero cost option. As the name implies, the CFC is only used for centralized forwarding. The centralized forwarding rate for the Catalyst 6500 is 30 Mpps, max. The CFC does not provide any local forwarding capabilities. The centralized forward capability is inherent to the baseboard and any daughtercards provide additional (non-standard) functionality.
Q. Can we have both CFC and DFC daughtercard on a module?
A. The DFC3 daughtercard provides distributed forwarding (dCEF). The CFC and DFC3 each use the same linecard connector - so they are mutually exclusive on a particular module. When a DFC3 is added to a 67xx linecard, the CFC will need to be removed.
Q. What happens when you mix different versions of PFC3x and DFC3x?
A. The PFC3 is the ASIC-based forwarding engine daughtercard for the Sup720; the DFC3 is the ASIC-based forwarding engine daughtercard for various fabric-enabled linecards (CEF256, CEF720). The PFC3/DFC3 'generation' is built upon a forwarding architecture internally known as EARL7. Within this generation, there are three different versions - A, B, and BXL these are all based on the same fundamental technologies but that each have incremental functionality ( A is the standard offering, B is the intermediate option, and BXL is the high-end option).
Q. What are the different versions of PFC3x and DFC3x available?
A. WS-F6K-PFC3A (Default on Sup720)
WS-F6K-PFC3B (Default on Sup720-3B; field upgradeable on Sup720)
WS-F6K-PFC3BXL (Default on Sup720-3BXL; field upgradeable on Sup720)
WS-F6700-DFC3A (Base dCEF forwarding engine for the CEF720 Series modules)
WS-F6700-DFC3B (Intermediate dCEF forwarding engine for the CEF720 Series modules)
WS-F6700-DFC3BXL (dCEF forwarding engine with the highest scalability for the CEF720 Series modules)
WS-F6K-DFC3A (Base dCEF forwarding engine for the CEF256/dCEf256 Series modules)
WS-F6K-DFC3B (Intermediate dCEF forwarding engine for the CEF256/dCEf256 Series modules)
WS-F6K-DFC3BXL (dCEF forwarding engine with the highest scalability for the CEF256/dCEf256 Series modules)
Q. What are the benefits of using DFC?
A. There are many:
- Performance is the biggest and most obvious reason for implementing DFCs. You move from a 30 Mpps centralized forwarding system anywhere up to a 400Mpps distributed forwarding system. This forwarding performance is for all L2 bridging, L3 routing, ACLs, QoS, and Netflow features (i.e. not just L3).
- The performance benefit of buying a DFC is most applicable when using the 67xx series modules. This is because these modules have enough ports and enough bandwidth to generate much more than the 30Mpps centralized forwarding engine has available. A 67xx-series module without a DFC is subject to the same centralized performance characteristics of all other centralized forwarding modules - i.e. 30 Mpps maximum for the whole system.
- For minimizing the impact that a classic module has in a system: Classic modules do affect the centralized forwarding performance of a system. Modules enabled with DFCs have their own forwarding engine and are not subject to this performance degradation. So for performance conscious customers who need to use a classic module (for whatever reason), the inclusion of a DFC will mitigate any performance issues/concerns.
- Increase the number of Netflow entries in the system. The system learns netflow entries on a per DFC/PFC-basis. So, if we have 256K netflow entries on a PFC3BXL/DFC3BXL, then we can scale the system to 256K * the number of PFC3BXL/DFC3BXL's.
- Increase the number of port-based QoS aggregate policers. A single PFC/DFC can support 1023 aggregate policers. So with 'x' number of PFC/DFCs, we can support 1023 times 'x' number of policers.
- The addition of a DFC module effectively disconnects a module from the DBus. As such, a DFC-enabled module is not subject to the bus stall mechanism that occurs when a module is inserted or removed from the chassis. During these Online Insertion and Removal (OIR) events, the DBus is temporarily paused for just enough time to ensure that the insertion/removal process does not cause any data corruption on the backplane. This protection mechanism causes a very brief amount of packet loss (sub-second, but dependent on the time it takes to fully insert a module). A module with a DFC onboard is not directly affected by this stall mechanism and will not have any packet loss on OIR.
Q. What are the memory options on a CEF720 module?
A. The 6700 Series linecards come with a base/default of 256MB DRAM. This is card memory that is used by both the base card as well as any DFC3x. The DFC3 for a 6700 series module can be WS-F6700-DFC3A, WS-F6700-DFC3B or WS-F6700-DFC3BXL.
If you don't have a DFC3, the card only uses the DRAM for linecard operation and to store firmware code. When a DFC3 is present, the same DRAM memory is also used for storing a local copy of the s/w CEF tables.
As of now, the only requirement for 1GB DRAM on the 67xx cards is for using > 256K routes with the DFC3BXL. This 1GB DRAM comes by default when you purchase a DFC3BXL.
It is worth noting that this DRAM is on the baseboard - so you do not need to order any separate memory if you add a WS-F6700-DFC3A or WS-F6700-DFC3B.
Q. What is RP on a Supervisor?
A. The RP (Route Processor) is one of two CPU's on the Supervisor that performs Control Plane functions on the switch. A Control Plane function is a feature that is run in software. The RP is responsible for running Layer 3 Control Plane features such as Routing Protocols (BGP, OSPF, EIGRP, etc.), Logging, Data Link Switching, Multicast Routing Protocols, Netflow Data Export, SNMP and more.
Q. What is SP on a Supervisor?
A. The SP (Switch Processor) is the second of two CPU's on the Supervisor that perform Control Plane functions on the switch. A Control Plane function is a feature that is run in software. The SP is responsible for running Layer 2 Control Plane features such as Spanning Tree Protocols (PVST+, MST, 802.1s, etc.), VLAN Trunking Protocol (VTP), Cisco Discovery Protocol (CDP) and more.
Q. Can all uplink ports on Sup32 be active at the same time?
A. YES - on both the Sup32-8GE and Sup32-10GE, all uplink ports can be active at the same time.
Q. Can all uplink ports on Sup720 be active at the same time?
A. NO - on all Sup720 modules, there are three GE front ports - two x GE SFP and one x GE-TX. Port 1 is designated as a GE SFP port. Port 2 can be either the GE SFP or GE-TX port. Activating one of these ports disables the use of the other. In this regard, the Sup720 can either have 2 x GE SFP ports active, or, 1 x GE SFP + 1 x GE-TX active.
Q. Can the 6503 chassis support WS-X67xx linecards?
A. NO - if you require a 3 slot chassis to support a 67xx series linecard then you must use the 6503-E.
Q. Can I use a WS-X67xx linecard in a 6513 chassis?
A. YES - but there are architectural considerations:
WS-X6724-SFP can be installed in any slot since it has a single fabric channel. All remaining WS-X67XX linecards must be installed in slots 9-13 since they have dual fabric channels.
Q. Does the Sup32 support dCEF256 and CEF720 linecards?
A. NO - These linecards require the switch fabric their forwarding operation.
Q. Are the FAN2 and E-Fan interchangeable in the E series and non-E series chassis?
A. NO - each is keyed differently. The E-FAN can only be installed in an E series chassis. The FAN2 can only be installed in the non-E series chassis.
Q. Is the VS-SUP-2T supported in the 6509-V-E-chassis?
A. Yes - Please see Cisco catalyst 6500 Sup 2T.
Related Information
.png "Arumugam Muthaiah"){kind=avatar}
