Catalyst 6500

The Catalyst 6500 is a modular chassis switch manufactured by Cisco Systems since 1999, capable of delivering speeds of up to "400 million packets per second" [http://www.cisco.com/en/US/products/hw/modules/ps2797/ps5138/index.html Cisco Catalyst 6500 Series Supervisor Engine 720] ] .

A 6500 comprises a chassis, power supplies, one or two supervisors, line cards and service modules. A chassis can have 3, 4, 6, 9 or 13 slots each (Catalyst model 6503, 6504, 6506, 6509, or 6513, respectively) with the option of one or two modular power supplies. The supervisor engine provides centralised forwarding information and processing, the line cards provide port connectivity and service modules allow for devices such as firewalls to be integrated within the switch.

Supervisor

The 6500 Supervisor comprises a Multilayer Switch Feature Card (MSFC) and a Policy Feature Card (PFC). The MSFC runs all software processes, such as routing protocols. The PFC makes forwarding decisions in hardware.

The supervisor also includes bootflash for the Cisco IOS software, a connection to the switching fabric and classic bus.

Operating systems

The 6500 currently supports three operating systems. CatOS, Native IOS and Modular IOS.

CatOS

CatOS is supported for layer 2 (switching) operations only. To be able to perform routing functions (e.g. Layer 3) operations, the switch must be run in hybrid mode. In this case, CatOS runs on the Switch Processor (SP) portion of the Supervisor, and IOS runs on the Route Processor (RP) also known as the MSFC. To make configuration changes, the user must then manually switch between the two environments.

While CatOS does have some functionality missing [http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c8441.shtml Comparison of the Cisco Catalyst and Cisco IOS Operating Systems for the Cisco Catalyst 6500 Series Switch] ] , it's generally considered obsolete compared to running a switch in Native Mode.

Native IOS

Cisco IOS can be run on both the SP and RP. In this instance, the user is unaware of where a command is being executed on the switch, even though technically two IOS images are loaded -- one on each processor. This mode is the default shipping mode for Cisco products and enjoys support of all new features and line cards.

Modular IOS

Modular IOS is a version of Cisco IOS that employs a modern UNIX-based kernel to overcome some of the limitations of IOS [http://www.cisco.com/en/US/products/hw/switches/ps708/prod_bulletin0900aecd80313e15.html Cisco Catalyst 6500 Series with Cisco IOS Software Modularity] ] . Additional to this is the ability to perform patching of processes without rebooting the device and in service upgrades.

Methods of operation

The 6500 has five major modes of operation. Classic, cef256, dcef256, cef720 and dcef720.

Classic Bus

The 6500 classic architecture provides 32 Gbit/s centralised forwarding performance [http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper0900aecd803e508c.shtml Cisco Catalyst 6500 Supervisor Engine 32 Architecture] ] . The design is such that an incoming packet is first queued on the line card and then placed on to the global data bus (dBus) and is copied to all other line cards, including the supervisor. The supervisor then looks up the correct egress port, access lists, policing and any relevant rewrite information on the PFC. This is placed on the result bus (rBus) and sent to all line cards. Those line cards for whom the data is not required terminate processing. The others continue forwarding and apply relevant egress queuing.

The speed of the classic bus is 16gb full duplex (hence the 32gb) and is the only supported way of connecting a Supervisor 32 engine to a 6500.

cef256

This method of forwarding was first introduced with the Supervisor 2 engine. When used in combination with a switch fabric module, each line card has an 8gb connections to the switch fabric and additionally a connection to the classic bus. In this mode, assuming all line cards have a switch fabric connection, an ingress packet is queued as before and its headers are sent along the dBus to the supervisor. They are looked up in the PFC (including ACLs etc) and then the result is placed on the rBus. The initial egress line card takes this information and forwards the data to the correct line card along the switch fabric. The main advantage here is that there is a dedicated 8 Gbit/s connection between the line cards. The receiving line card queues the egress packet before sending it from the desired port.

The '256' is derived from a chassis using 2x8gb ports on 8 slots of a 6509 chassis. 16 * 8 = 128 * 2 = 256. The number is doubled to the switch fabric being 'full duplex'.

dcef256

dcef256 uses distributed forwarding. These line cards have 2x8gb connections to the switch fabric and no classic bus connection. Only modules that have a DFC (Distributed Forwarding Card) can use dcef.

Unlike the previous examples, the line cards holds a full copy of the supervisors routing tables locally, as well as its own L2 adjacency table (i.e. MAC addresses). This eliminates the need for any connection to the classic bus or requirement to use the shared resource of the supervisor. In this instance, an ingress packet is queued, but its destination looked up locally. The packet is then sent across the switch fabric, queued in the egress line card before being sent.

cef720

This mode of operation acts identically to cef256, except now there are 2x20gb connections to the switch fabric and there is no need for a switch fabric module (this is now integrated in to the supervisor). This was first introduced in to the Supervisor Engine 720.

The '720' is derived from a chassis using 2x20gb ports on 9 slots of a 6509 chassis. 40 * 9 = 360 * 2 = 720. The number is doubled to the switch fabric being 'full duplex'. The reason we use 9 slots for the calculation instead of 8 for the cef256 is that we no longer need to waste a slot with the switch fabric module.

dcef720

This mode of operation acts identically to dcef256, except now there is 2x20gb connections to the switch fabric.

Power Supplies

The 6500 is able to deliver high densities of PoE across the chassis. Due to this, power supplies are a key element of configuration. 3Com and Nortel, have conducted separate third party evaluations and claim these power supplies are inefficient. [http://www.nortel.com/solutions/conv/collateral/tolly208298_nortel_converged_netenergy_costs_july08.pdf Energy Consumption and Projected Costs for a converged solution] ] [ [http://www.tolly.com/ts/2008/Nortel/TTG208275NortelSummary.pdf Tolly TCO] ] [ [ [http://www.foxbusiness.com/story/markets/industries/telecom/nortel-power-savings-drive-enterprise-customer-adoption/] Nortel Power Savings Drive Enterprise Customer Adoption] [ [http://pressreleases.merinews.com/catFull.jsp?articleID=133778 3Com: Leader in 'green' networking] ]

Chassis Support

The following goes through the various 6500 chassis and their supported power supplies and loads.

6503

The original chassis permits up to 4200W (100A @ 42V) and uses rear-inserted power supplies different from the others in the series. With the introduction of the 6503-E, this was increased to 5000W (119A @ 42V).

6504-E

This chassis permits up to 2700W (119A @ 42V) of power and, like the 6503, uses rear-inserted power supplies

6506, 6509, 6506-E and 6509-E

The original chassis can support up to a maximum of 4000W (90A @ 42V) of power, due to backplane limitations. If a power supply above this is inserted, it will deliver at full power up to this limitation (i.e. a 6000W power supply is supported in these chassis, but will output a maximum of 4000W).

The 6509-NEB-A supports a maximum of 4500W (108A @ 42V).

With the introduction of the 6506-E and 6509-E series chassis, the maximum power supported has been increased to in excess of 14500W (350A @ 42V).

6513

This chassis can support a maximum of 8000W (180A @ 42V). However, to obtain this, we have to run in combined mode (see below). Therefore, we suggest you run in redundant mode to obtain a maximum of 6000W (145A @ 42V).

Power Redundancy Options

The 6500 supports dual power supplies for redundancy. These may be run in one of two modes, redundant or combined mode.

Redundant Mode

When running in Redundant Mode, each power supply provides approximately 50% of its capacity to the chassis. In the event of a failure, the unaffected power supply will then provide 100% of its capacity and an alert will be generated. As there was enough to power the chassis ahead of time, there is no interruption to service in this configuration. This is also the default and recommended way to configure power supplies.

Combined Mode

In combined mode, each power supply provides approximately 83% of its capacity to the chassis. This allows for greater utilisation of the power supplies and potentially increased PoE densities.

In the event of a failure, we power down all devices except the supervisor. During this time, there will be a temporary network outage while we return power to the system. The order at which we do this is as follows:
# First we power up service modules from the top down
# Then we power up line cards from the top most slot to the bottom most. We do _not_ permit PoE at this stage.
# Next we power up PoE from the highest line card and the highest port (i.e. line card 0/port 0) down through to the lowest.

We go through the above until we have hit our power capacity of the remaining power. Normally, a single power supply will be able to power all service modules and line cards, but not give the PoE densities required.

Online Insertion & Removal

OIR is a feature of the 6500 allowing you to hot swap most line cards without first powering down the chassis. The advantage of this is that one may perform an in-service upgrade. However, before attempting this, it is important that one understands the process of OIR and how it may still require a reload.

To prevent bus errors, the chassis has three pins in each slot which correspond with the line card. Upon insertion, the largest of these makes first contact and stalls the bus (as to avoid corruption). As the line card is pushed in further, the middle pin makes the data connection. Finally, the smallest pin removes the bus stall and allows the chassis to continue operation.

However, if any part of this operation is skipped, errors will occur (resulting in a stalled bus and ultimately a chassis reload). Common problems include:
* Line cards being inserted incorrectly (and thus making contact with only the stall and data pins and thus not releasing the bus)
* Line cards being inserted too quickly (and thus the stall removal signal is not received)
* Line cards being inserted too slowly (and thus the bus is stalled for too long and forces a reload).

Therefore, you are strongly advised not to perform OIR outside of maintenance windows. It is also for the above that OIR is commonly referred to as "On Insertion, Reload".

References