Cisco Cisco Catalyst 6500 Series Network Analysis Module (NAM-3) White Paper

 

 

White Paper 

All contents are Copyright © 1992–2010 Cisco Systems, Inc. All rights reserved. This document is Cisco Confidential Information. 4 

The FWSM is the key element of this deployment, as it supervises all the traffic going in and out 
through this environment. Its location and configuration are crucial, as the overall deployment 
configuration flows from it. 

With no FWSM preemption enabled, it is difficult to locate and control the position of the active 
FWSM unit for any given security context, with obvious consequences to the overall environment’s 
configuration. FWSM preemption makes that location and control more predictable. It is therefore 
imperative to configure FWSM preemption in order to deploy a FWSM cluster in this environment.  
This will then help to build a more accurate and stable configuration for the environment, especially 
in the areas of Spanning Tree Protocol (STP), Hot Standby Router Protocol (HSRP), and routing. 

RSTP (Rapid Spanning-Tree Protocol) was used during the testing.  The VSS located in the VSS 
domain with the active FWSM for a security context should be the STP root primary for all the 
VLANS pertaining to that security context. The other VSS should be the STP root secondary. 

  The above STP priority guidelines on the VSS should be the same whether the FWSM 

cluster is deployed in the VSS or in the SS.  When the FWSM cluster is deployed in the 
SS, all the VLANs’ STP priority should be left as default in the SS. 

The SVI interface (in the same VLAN as the outside VLAN of the security context) in the VSS 
located in the VSS domain containing the active FWSM for a particular security context should be 
HSRP active.  The corresponding SVI configured in the other VSS must be HSRP standby. 

It is important to mention that when the FWSM cluster is deployed in the SS, the above 
HSRP guidelines remain the same.  No SVI (related to security contexts) should be 
configured on the SS, which is purely a Layer 2 device. 

At the time of the validation/verification, OSPF was used as the routing protocol between the core 
and the two VSS domains, with no adjacency between the VSS domains. 

  It is important to mention that the above result can be achieved using a routing protocol 

other than OSPF, as long as the implemented design guarantees a traffic flow similar to 
the one described here. 

All the subnets related to the SVI interfaces (in the same VLAN as the outside VLAN of the security 
context) in both VSS domains should be advertised in OSPF to the core. Each SVI interface should 
be configured with an adapted OSPF cost, to ensure that the traffic from the core to a particular 
security context is sent to the correct VSS domain (where the active FWSM unit for that security 
context is located). The SVI on the VSS domain with the active FWSM for a particular security 
context should be configured with a lower OSPF cost than the SVI in the other VSS domain.  The 
redistribution metric must also be lower on the VSS with the active FWSM for a particular security 
context, than that on the other VSS. 

When static routing is used in routed mode, the default routes configured in the FWSM must point 
to the HSRP virtual IP addresses on the VSS. The static routes configured on the VSS to reach the 
inside subnet of each security context must also point to the FWSM outside IP address. 

The above can be achieved with only one OSPF process for a FWSM cluster in active/standby 
mode. However, two OSPF processes are needed for a FWSM cluster in active/active mode, one 
per FWSM security context group.