Section 8-3. Firewall Load Balancing in Hardware

8-3. Firewall Load Balancing in Hardware

FWLB is used to balance traffic flows to one or more firewall farms. A firewall farm is a group of firewalls that are connected in parallel or that have their inside (protected) and outside (unprotected) interfaces connected to common network segments.

FWLB requires a load-balancing device to be connected to each side of the firewall farm. A firewall farm with inside and outside interfaces would then require two load-balancing deviceseach making sure that traffic flows are directed toward the same firewall for the duration of the connection.

FWLB can be performed in hardware with a CSM on the Catalyst 6500 switch platform. The CSM is a very robust and high-performance device, using the ASLB features to distribute connections to both server and firewall farms.

The CSM has no firewall farm concept. Rather, it treats a firewall farm as a regular server farm where the physical firewalls are configured as real servers in the farm. The CSM itself has logical interfaces that are configured as the gateway or next-hop addresses toward and away from a firewall farm.

To load-balance traffic, the CSM is configured with a virtual server that represents the firewall farm. As new traffic flows arrive at the virtual server, the CSM computes a hash value according to a predefined algorithm. This hash value determines which firewall is used within the firewall farm.

The CSM is flexible with how firewalls are connected and where they are located. Firewalls can reside on a single VLAN or subnet, or they can each reside on a unique subnet. As well, the firewalls can be more than one router hop away from the CSM.

The CSM can operate in the following modes, based on its placement between a firewall farm and the clients:

Single subnet (bridge) mode The clients and the firewall farm members all reside on one common IP subnet. However, each side of the CSM (client and server) must be assigned to unique VLANs that share the same IP subnet. The CSM distributes inbound connections to the firewalls by substituting the destination MAC address to match the next firewall to be used while bridging the packets from the client to the server VLAN.
This mode can be useful when you need to implement load-balancing needs in an existing network where it isn't feasible to move the clients or the firewalls to different IP subnets. In other words, it isn't possible to wedge a router between the clients and the firewalls. Instead, transparent or "stealth" Layer 2 firewalls are used in the firewall farm.
Secure (router) mode The clients and the firewall farm members are located on different IP subnets and VLANs. In this case, traditional Layer 3 or "routed mode" firewalls are used in the firewall farm.
The CSM distributes inbound connections to the firewalls by forwarding the packets just as a router would do. The CSM maintains an ARP cache of all the firewalls and substitutes the destination MAC address to point to the appropriate firewall.
Because the client and firewall farm IP subnets are different, the CSM must know enough routing information to distribute and forward connections to the firewalls. This becomes especially important when the firewalls are located more than one router hop away from the CSM.

CSM FWLB can detect a firewall failure by monitoring probe activity. One probe is configured and is used on all members of the firewall farm in succession. The CSM automatically inserts the target IP address of each firewall. The CSM also periodically gathers ARP data from each firewall and uses that information to detect firewall failures.

Multiple CSM FWLB devices can also use stateful backup for redundancy. Backup devices keep state information dynamically and can take over immediately if a failure occurs.

NOTE

The CSM is a standalone device installed in a Catalyst 6500 chassis. The CSM interfaces with the switch through a 6-Gbps channel that acts as a trunk carrying multiple VLANs. As soon as packets are handed off to the CSM, they are effectively isolated from the switch until the CSM sends them back.

As you might expect, FWLB can be performed by two separate CSMs, in either one or two physical switch chassis. However, the CSM architecture also allows FWLB using only a single CSM in one switch chassis. You can configure many separate virtual servers and firewall farms within one CSM so that all the FWLB devices needed to surround a firewall farm can be present in that CSM. This makes high-performance FWLB more cost-effective but limits the redundancy to a single CSM.

FWLB in Hardware Configuration Notes

FWLB is configured in two halves. One FWLB device must be placed on the outside of the firewall farm, and another is placed on the inside. Each FWLB device distributes connections toward the firewall. Therefore, the outside FWLB balances connections going into the firewall farm's outside interfaces (inbound). The inside FWLB acts similarly for connections going into the firewall farm's inside interfaces (outbound).

The CSM is configured differently from IOS FWLB because it supports only generic server farms that act as firewall farms. A virtual server and its server farm must be configured for each direction in which packets will be sent. Therefore, on each side of the firewall, you must configure the CSM with two virtual servers that either load-balance or just forward traffic in the inbound and outbound directions.

This might sound a bit complicated, but it really isn't. Figure 8-5 shows how CSM FWLB devices use the various virtual servers. (For the purposes of this discussion, assume that two separate CSMs are being used.) On the outside of the firewall farm, that CSM needs one virtual server to distribute connections into a firewall farm's outside interfaces in the inbound direction. A second "generic" virtual server takes care of the outbound traffic coming from the firewall farm. This virtual server is actually a simple traffic forwarder that makes no load-balancing decisions.

Figure 8-5. CSM FWLB Operation Surrounding a Firewall Farm

The inside CSM also has two virtual servers:

One virtual server simply forwards inbound traffic toward the internal secure network.
One virtual server is a true load balancer that distributes outbound connections to the firewalls' inside interfaces.

TIP

If only one CSM can be used to provide FWLB around a firewall farm, how much network functionality can be put into a single Catalyst 6500 chassis? Plenty! That chassis can contain the usual Supervisor and line cards, along with the CSM, and up to four FWSMs. In other words, the outside public network and the inside secure network can exist on that switch as separate isolated VLANs, and the CSM provides robust load balancing to multiple high-performance firewall modulesall without compromising security.

The following sections present configuration steps for only one side (inside or outside) of the firewall farm. You need to repeat the sequence of steps for the FWLB functions on the other side of the firewall farm, too, assuming that you are working with firewalls that have dual (outside and inside) interfaces.

If you have more protected networks (DMZs, for example), you can apply the same concepts to the firewall farm's other interfaces. Follow the steps listed for the inside FWLB configuration for any other interfaces needed, because these are all more secure interfaces than the outside.

Also notice that the configuration steps assume you are using two separate CSMs. These same steps easily apply to a single CSM scenario just by using all the commands (inside and outside FWLB) to configure that one CSM.

CSM FWLB Configuration

Because firewall load balancing with CSMs requires several different server farms and virtual servers, it is easy to forget what pieces need to be configured. Configure the inside and outside CSMs one at a time, and keep track of your progress in each by following the virtual servers and server farms that are shown in Figure 8-5. You need to repeat this configuration process for the inside and outside CSM.

1.	Enter CSM server load-balancing mode: Switch(config)# ip slb mode csm A Catalyst 6500 switch can support SLB functionality on the route processor (RP) or Supervisor in the native IOS software. If a CSM is installed, you should use this command to convert the switch to using the CSM for all the SLB configuration commands. After you issue this command, the switch needs to be reloaded, and all existing IOS SLB commands are automatically removed.
2.	Select the CSM module: Switch(config)# module csm slot-number The native IOS CLI begins CSM configuration mode for the CSM located at slot-number in the switch chassis. To end this mode, use the exit command. To find the appropriate slot number, use the show module all command.
3.	Define connectivity away from the firewall farm. Identify the outside network VLAN: Switch(config-module-csm)# vlan vlan-id client The VLAN number is given as vlan-id (2 to 4095; VLAN 1 cannot be used). This VLAN must already be defined on the switch. Defining the VLAN as client means that the CSM expects new inbound connections to originate from clients there. These connections are distributed into a server-type VLAN where the firewall farm is located. TIP The CSM doesn't have a special configuration mode for firewall farms or FWLB. When configuring a CSM for FWLB, always consider the client-side VLAN of the CSM to be away from the firewalls. The server-side VLAN of the CSM is always closest or directly connected to the firewall farms. Assign a primary IP address: Switch(config-slb-vlan-client)# ip address ip-address netmask One IP address can be defined per VLAN on the CSM. This address is used as the next-hop gateway for inbound traffic, as well as for management traffic (probes, for example) and ARP requests. TIP For the outside CSM, make sure the hosts or routers on the outside public (unsecure) network use this address as their next-hop gateway to reach the inside (secure) network. Likewise, for the inside CSM, make sure the inside (secure) hosts and routers use this address as their default gateway to the public network. (Outside CSM only) Define a default gateway: Switch(config-slb-vlan-client)# gateway ip-address A next-hop default gateway or router address is given by ip-address. You can repeat this command to define up to seven gateways per VLAN, or 255 gateways per CSM. Gateways are usually used on the client-side VLAN to forward outbound traffic to the next-hop router in the public network. Exit client VLAN mode: Switch(config-slb-vlan-client)# exit
4.	Define connectivity toward the firewall farm. Identify the nearest firewall farm VLAN: Switch(config-module-csm)# vlan vlan-id server This is the VLAN that is used to connect this CSM to the firewalls in the firewall farm. The VLAN number is given as vlan-id (2 to 4095; VLAN 1 cannot be used). This VLAN must already be defined on the switch. Defining the VLAN as server means that the CSM distributes new connections to firewall "servers" in the firewall farm. TIP The firewalls in a firewall farm can all be located on the same IP subnet and VLAN as the CSM. In this case, only one server VLAN needs to be defined on the CSM. Having each firewall located on a separate IP subnet and VLAN is also valid. This can occur when the firewalls are located in different geographic locations or when they need to be logically isolated from each other. In this case, you need to create a server VLAN for each firewall in the farm. Each server VLAN is assigned an IP address that correlates to a specific firewall's interface. Assign a primary IP address: Switch(config-slb-vlan-server)# ip address ip-address netmask One IP address can be defined per VLAN on the CSM. For the outside CSM, this address is used as the next-hop gateway for outbound traffic from the firewalls. Likewise, for the inside CSM, this address is the next hop for inbound traffic from the firewalls. The CSM also uses this address as a source address when it generates management traffic (probes, for example) and ARP requests. TIP Make sure all the firewalls in the farm are configured with the outside CSM's server-side VLAN IP address as their default gateway. The firewalls should also have the inside CSM's server-side address as their next-hop gateway to reach the inside (secure) networks. That way, the firewalls can easily forward packets to the appropriate CSM, which in turn forwards them to the public or secure network. (Optional) Define additional IP addresses: Switch(config-slb-vlan-server)# alias ip-address netmask You can define an additional IP address and subnet on a server-side VLAN if necessary. This is similar to configuring a secondary IP address on a router interface. By repeating this command, you can add up to 255 additional addresses to a VLAN. (Optional) Define static routes to reach distant networks: Switch(config-slb-vlan-server)# route ip-address netmask gateway gw-ip-address You can define a static route when the CSM needs to know how to reach firewalls that are more than one router hop away. Define the route by the network ip-address and netmask using next-hop gateway address gw-ip-address. The gateway must reside on the same local network as the CSM server VLAN. You do not need to use this command if each firewall is connected to the same IP subnet as a CSM server VLAN. In this case, no routing information is needed to reach the firewalls.
5.	Define a probe for a firewall farm: Switch(config-module-csm)# probe probe-name icmp The probe is named probe-name (a text string of up to 15 characters) and can be referenced by other FWLB commands. TIP You don't have to configure a target IP address for a CSM probe. Rather, the CSM uses the probe definition and substitutes each firewall's IP address from the firewall farm. Every firewall is automatically probed in this fashion. Notice that this makes detecting complete firewall operation somewhat difficult. Ideally, you should send and receive ICMP packets that have passed all the way through a firewall to be sure it is completely functional. You normally use a target address of the far-side firewall interface or another device on the other side. This isn't possible on the CSM; only the nearest firewall interface (the one configured in the firewall farm) is probed. At the least, if ICMP replies are received, you can safely assume that the firewall's outside interface is up and running. TIP The CSM is somewhat unique with regard to probes. Even if no probes are defined and configured, it uses ARP requests that it regularly sends every 5 minutes to determine if each firewall in a farm is alive. If the firewall doesn't send an ARP reply, it is marked as failed. Although this is automatic, it isn't very timely, because 5 minutes could pass before the CSM realizes there is a problem with a firewall. During that time, new connections could have been assigned to the dead firewall. You should always define and use a probe for each firewall farm. Although you can't configure the target IP addresses used by probes, you can tune the probe interval and the number of retries before a failure is declared. (Optional) Set the amount of time between probes: Switch(config-slb-probe-icmp)# interval seconds Probes are sent toward the target at intervals of seconds (5 to 65535 seconds; the default is 120 seconds). (Optional) Set how long to wait for a probe reply: Switch(config-slb-probe-icmp)# receive receive-timeout The CSM waits receive-timeout (1 to 65535 seconds; the default is 10 seconds) for an ICMP reply to be received before considering the probe failed. (Optional) Define the criteria for a failure: Switch(config-slb-probe-icmp)# retries retry-count With a CSM, the target has failed if retry-count (0 to 65535; the default is 3) probes go unanswered. (Optional) Wait to retry a failed firewall: Switch(config-slb-probe-icmp)# failed failed-interval After a CSM has determined that a firewall has failed, it waits failed-interval (5 to 65535 seconds; the default is 300 seconds) before sending another probe.
6.	Define the firewall farm. Assign a name to the firewall farm: Switch(config-module-csm)# serverfarm serverfarm-name The CSM views a firewall farm as just another form of a server farm, referenced by serverfarm-name (a text string of up to 15 characters). Identify one or more firewalls in the farm: Switch(config-slb-sfarm)# real ip-address Switch(config-slb-real)# inservice The firewall interface nearest to the CSM can be found at IP address ip-address. By default, the CSM does not use the firewall unless it is placed in service with the inservice command. To remove a firewall from service, use the no inservice command. Choose a firewall load-balancing method: Switch(config-slb-sfarm)# predictor hash address {source \| destination} 255.255.255.255 On a CSM located outside relative to the firewall farm (the unsecure side), the algorithm should use only the source addresses. On an inside CSM, the destination hash algorithm should be used. Here, you should set the netmask option to 255.255.255.255 so that all address bits are used in the hash algorithm. In this fashion, inbound and outbound connections are distributed according to the largest and most diverse population of addressesthose found on the public network. TIP The CSM has a very robust load-balancing capability that can be based on source or destination addresses, a round-robin fashion, or the actual connection loads on each firewall. For firewall load balancing, the source and destination address hashes are the most useful and predictable. You might be inclined to use one of the more dynamic hash algorithms so that the firewalls are loaded evenly. These algorithms include weighted round robin, which assigns a number of new connections to one firewall before moving on to the next one, and weighted least connections, which assigns new connections to the firewall that is least used at any given time. Or you might have a mix of firewall models in a firewall farm, where some have a higher throughput than others and should be used more. In any event, the dynamic hash algorithms don't lend themselves to FWLB because multiple FWLB devices always surround a firewall farm. The outside FWLB device can do a nice, accurate job of evenly distributing the load to the outside of the firewall farm, but its information about the firewall loads, weighting, and number of active connections is not passed to the inside FWLB device. The same is true of the inside FWLB device. This makes it possible for some firewalls to be overloaded by a combination of inside and outside FWLB devices while others are underutilized. Disable server NAT: Switch(config-slb-sfarm)# no nat server By default, server NAT is enabled for a CSM server farm (including a firewall farm). However, NAT is never needed when load balancing to firewalls. The FWLB device should just pass IP addresses through unaltered. Use one or more probes to detect failures within the firewall farm: Switch(config-slb-sfarm)# probe probe-name The probe that is defined by probe-name (a text string) is used to periodically check each firewall in the firewall farm. The probe inherits each firewall's IP address from the list of real servers to use as a target address. You can define more than one probe, but a firewall is declared down if it fails just one probe. A firewall must pass all probes to be recovered again.
7.	Define a virtual server to handle traffic toward the firewall farm. Name the virtual server: Switch(config-module-csm)# vserver virtual-server-name The virtual server is given the name virtual-server-name (a text string of up to 15 characters). Assign the virtual server to a firewall server farm: Switch(config-slb-vserver)# serverfarm serverfarm-name FWLB uses the virtual server as the front end for the server farm named serverfarm-name (a text string of up to 15 characters). Define the virtual server's IP address: Switch(config-slb-vserver)# virtual ip-address [network-mask] any The virtual server appears as IP address ip-address (the default is 0.0.0.0) with network-mask (the default is 255.255.255.255; 1 bits match, and 0 is a wildcard). In the default case (0.0.0.0 255.255.255.255), no destination addresses are ever matched, so no traffic is accepted. In most cases, you can just define the virtual server to accept any destination (0.0.0.0 0.0.0.0), as long as you specify the ingress VLAN in Step 7d. The any keyword allows all protocols to be load-balanced. However, it is good practice to be more specific by defining the virtual server to accept only the IP subnets that are behind the firewall farm on the inside (secure) network. (Optional) Allow traffic only from a source VLAN to use the virtual server: Switch(config-slb-vserver)# vlan vlan-number By default, traffic from all VLANs is allowed to reach the firewalls through the virtual server. To restrict the access, specify a vlan-number (2 to 4095) that is to be allowed. This is usually the CSM VLAN that connects away from the firewalls. After it is defined, all other VLANs are restricted from accessing the virtual server. Allow FWLB to begin using the virtual server: Switch(config-slb-vserver)# inservice By default, FWLB does not use the virtual server unless it is placed in service. To remove a virtual server from service, use the no inservice command. (Optional) Use SLB stateful backup: Switch(config-slb-vserver)# replicate csrp {sticky \| connection} CSM replicates its connection information using Content Switching Replication Protocol (CSRP). You can replicate the sticky connection database or the regular connection database. To replicate both, choose each one in a separate replicate csrp command.
8.	Define a generic server farm for traffic away from the firewall farm. Assign a name to the generic server farm: Switch(config-module-csm)# serverfarm serverfarm-name The CSM sees the network away from the firewall farm as a server farm. Here, the server farm represents the Internet or public network to the outside CSM and the internal (secure) network to the inside CSM. TIP You must also configure traffic away from the firewall farm for load balancing with a generic serverfarm having no real servers. Instead, a generic virtual server is used to forward all traffic through the generic server farm according to the CSM's internal routing tables. (Optional) Choose a load-balancing method: Switch(config-slb-sfarm)# predictor forward Here, the algorithm uses only forward mode without computing hash values. This merely forwards traffic destined away from the firewall farm according to the CSM's internal routing table. Disable server NAT: Switch(config-slb-sfarm)# no nat server By default, server NAT is enabled for a CSM server farm. In the case of firewall load balancing, NAT is not required, because packets should be presented to and from the firewalls unaltered.
9.	Define a generic virtual server for traffic away from the firewall farm. Name the virtual server: Switch(config-module-csm)# vserver virtual-server-name The virtual server is given the name virtual-server-name (a text string of up to 15 characters). Assign the virtual server to the generic server farm: Switch(config-slb-vserver)# serverfarm serverfarm-name FWLB uses the virtual server as the front end for the generic server farm named server farm-name (a text string of up to 15 characters). Let the virtual server accept all outbound traffic: Switch(config-slb-vserver)# virtual 0.0.0.0 0.0.0.0 any The virtual server matches any destination IP address so that traffic gets forwarded away from the firewall farm. (Optional) Allow traffic only from a source VLAN to use the virtual server: Switch(config-slb-vserver)# vlan vlan-number By default, traffic from all VLANs is forwarded out through the virtual server. To restrict the access, specify a vlan-number (2 to 4095) that is to be allowed. This is usually the CSM VLAN that connects to the firewall farm. After it is defined, all other VLANs are restricted from accessing the virtual server. (Optional) Use sticky connections to maintain client/server firewall mapping: Switch(config-slb-vserver)# sticky duration [group group-id] [netmask netmask] [source \| destination \| both] Switch(config-slb-vserver)# reverse-sticky group-id After a CSM builds a connection from a client to a real server (firewall) through a virtual server, it can make the connection "sticky" to permit subsequent client/server connections to use the same firewall. This is important for some applications, where one connection sets up the appropriate conditions for a second connection. This is commonly done with protocols such as H.323, where "buddy" ports or additional connections are negotiated and initiated. You can enable sticky connections with the sticky command, where connections are held in the sticky database for duration (1 to 65535 minutes). By using the group keyword, you can organize the connections in the database as groups if certain types of connections should be held together. The group-id is 0 by default, but it can be 1 to 255. Connections are flagged as "sticky" according to IP address criteria. You can provide a subnet mask designation with netmask netmask, where 1 bits signify the address bits that are eligible for stickiness. The actual address used can be source, destination, or both. With firewall load balancing, sticky connections usually need to be extended further. This is because a CSM is configured with two virtual serversone to load-balance connections toward the firewall farm and another to load-balance connections away from the firewall farm. In practice, these virtual servers work independently so that connections that are marked sticky through one virtual server do not appear sticky to the other virtual server. To remedy this, you can enable reverse sticky connections with the reverse-sticky command. This is done on a per-group basis, where group-id (0 to 255) identifies the group created with the sticky command. As connections are load-balanced and made sticky in one direction, sticky entries are automatically made for them in the reverse direction. In effect, this provides a common sticky database for all the virtual servers. Allow FWLB to begin using the virtual server: Switch(config-slb-vserver)# inservice By default, the virtual server is not used until it is placed in service. To remove a virtual server from service, use the no inservice command.

CSM Firewall Load-Balancing Example

The network from the example in section 8-2 is reused here so that you can get a feel for the difference between IOS FWLB and CSM configurations.

To perform firewall load balancing, you need two load-balancing devices:

One located externally with respect to the firewall farm
One located internally with respect to the firewall farm

Figure 8-6 shows a network diagram for this example using CSMs as FWLB devices. Remember that in the case of CSMs, you have the flexibility to use two separate modules (in the same or different chassis) on each side of the firewall farm or a single CSM that simply connects to both sides of the firewall farm.

Figure 8-6. Network Diagram for the CSM FWLB Example

The firewall farm consists of three real firewalls.

The outside (unprotected) interfaces of the three firewalls are at 192.168.100.3, 192.168.100.4, and 192.168.100.5. On the outside, the default gateway to the public network is 192.168.1.1, and the external CSM FWLB device (Catalyst A) is at 192.168.1.2.

The inside (protected) interfaces of the three firewalls are at 192.168.200.3, 192.168.200.4, and 192.168.200.5. The internal CSM FWLB device performs firewall load balancing for outbound traffic to the firewall farm. On the internal secure network (192.168.199.0/24), one server is in use at 192.168.199.100. This server supports both inbound HTTP and Telnet connections.

Ping probes are used by both external and internal FWLB devices to test for firewall operation.

CSM Components Needed

Before we look at the actual configuration commands, you should understand the many logical pieces of the two CSMs that are used for FWLB. Remember that the CSM thinks of everything in terms of a server farm and its virtual server front end.

For the outside CSM, keep in mind that both inbound (toward the firewall farm and the inside secure network) and outbound (away from the firewall farm, toward the public network) connections exist. You need a server farm and virtual server pair in each of these directions. These are labeled as follows:

Inbound connections:
- FW-INBOUND The server farm composed of individual firewalls ("real servers") and their outside interfaces.

- V-INBOUND The virtual server that distributes inbound connections among the firewall farm.
Outbound connections:
- PUBLIC A generic server farm that simply forwards all traffic toward the public network.

- V-OUTBOUND-100 The virtual server that accepts outbound connections from VLAN 100 (outside interfaces of the firewall farm).

The inside CSM is very similar, requiring the following inbound and outbound pairs of server farms and virtual servers:

Inbound connections:
- INTERNAL A generic server farm that simply forwards all traffic toward the internal (secure) network.

- V-INBOUND-200 The virtual server that accepts inbound connections from VLAN 200 (inside interfaces of the firewall farm).
Outbound connections:
- FW-OUTBOUND The server farm composed of individual firewalls ("real servers") and their inside interfaces.

- V-OUTBOUND The virtual server that distributes outbound connections among the firewall farm.

Basic Firewall Configuration

This section begins with the firewall configurations. Firewalls A and B are FWSMs installed in the Catalyst A chassis. Firewall C is an external Cisco PIX Firewall connected to Catalyst A through a Gigabit Ethernet link. These configuration commands are shown here to give you a basic idea of all the pieces that must be configured for FWLB. Notice that all three firewalls have identical security policies configured. This is important, because any of the three firewalls could be assigned con-nections from any pair of inside and outside hosts.

 Firewall(config)# hostname fwsm-a fwsm-a(config)# nameif vlan100 outside security0 fwsm-a(config)# nameif vlan200 inside security100 fwsm-a(config)# ip address outside 192.168.100.3 255.255.255.0 fwsm-a(config)# ip address inside 192.168.200.3 255.255.255.0 fwsm-a(config)# icmp permit 192.168.100.0 255.255.255.0 outside fwsm-a(config)# icmp permit 192.168.200.0 255.255.255.0 inside fwsm-a(config)# static (inside,outside) 192.168.199.0 192.168.199.0 netmask   255.255.255.0 0 0 fwsm-a(config)# object-group icmp-type ICMP fwsm-a(config-icmp)# icmp-object echo fwsm-a(config-icmp)# icmp-object echo-reply fwsm-a(config-icmp)# icmp-object time-exceeded fwsm-a(config-icmp)# icmp-object unreachable fwsm-a(config-icmp)# exit fwsm-a(config)# access-list acl_out permit tcp any host 192.168.199.100 eq telnet fwsm-a(config)# access-list acl_out permit tcp any host 192.168.199.100 eq www fwsm-a(config)# access-list acl_out permit icmp any host 192.168.199.100   object-group ICMP fwsm-a(config)# access-list acl_in permit tcp 192.168.199.0 255.255.255.0 eq   telnet any fwsm-a(config)# access-list acl_in permit tcp 192.168.199.0 255.255.255.0 eq www   any fwsm-a(config)# access-list acl_in permit icmp 192.168.199.0 255.255.255.0 any   object-group ICMP fwsm-a(config)# access-list acl_in permit icmp 192.168.200.0 255.255.255.0 any   object-group ICMP fwsm-a(config)# access-group acl_out in interface outside fwsm-a(config)# access-group acl_in in interface inside fwsm-a(config)# route outside 0.0.0.0 0.0.0.0 192.168.100.1 1 fwsm-a(config)# route inside 192.168.199.0 255.255.255.0 192.168.200.1 1 ________________________________________________________________ Firewall(config)# hostname fwsm-b fwsm-b(config)# nameif vlan100 outside security0 fwsm-b(config)# nameif vlan200 inside security100 fwsm-b(config)# ip address outside 192.168.100.4 255.255.255.0 fwsm-b(config)# ip address inside 192.168.200.4 255.255.255.0 fwsm-b(config)# icmp permit 192.168.100.0 255.255.255.0 outside fwsm-b(config)# icmp permit 192.168.200.0 255.255.255.0 inside fwsm-b(config)# static (inside,outside) 192.168.199.0 192.168.199.0 netmask   255.255.255.0 0 0 fwsm-b(config)# object-group icmp-type ICMP fwsm-b(config-icmp)# icmp-object echo fwsm-b(config-icmp)# icmp-object echo-reply fwsm-b(config-icmp)# icmp-object time-exceeded fwsm-b(config-icmp)# icmp-object unreachable fwsm-b(config-icmp)# exit fwsm-b(config)# access-list acl_out permit tcp any host 192.168.199.100 eq telnet fwsm-b(config)# access-list acl_out permit tcp any host 192.168.199.100 eq www fwsm-b(config)# access-list acl_out permit icmp any host 192.168.199.100   object-group ICMP fwsm-b(config)# access-list acl_in permit tcp 192.168.199.0 255.255.255.0 eq   telnet any fwsm-b(config)# access-list acl_in permit tcp 192.168.199.0 255.255.255.0 eq www   any fwsm-b(config)# access-list acl_in permit icmp 192.168.199.0 255.255.255.0 any   object-group ICMP fwsm-b(config)# access-list acl_in permit icmp 192.168.200.0 255.255.255.0 any   object-group ICMP fwsm-b(config)# access-group acl_out in interface outside fwsm-b(config)# access-group acl_in in interface inside fwsm-b(config)# route outside 0.0.0.0 0.0.0.0 192.168.100.1 1 fwsm-b(config)# route inside 192.168.199.0 255.255.255.0 192.168.200.1 1 ________________________________________________________________ Firewall(config)# hostname pix-c pix-c(config)# interface gb-ethernet0 1000full pix-c(config)# interface gb-ethernet1 1000full pix-c(config)# nameif gb-ethernet0 outside security0 pix-c(config)# nameif gb-ethernet1 inside security100 pix-c(config)# ip address outside 192.168.100.5 255.255.255.0 pix-c(config)# ip address inside 192.168.200.5 255.255.255.0 pix-c(config)# icmp permit 192.168.100.0 255.255.255.0 outside pix-c(config)# icmp permit 192.168.200.0 255.255.255.0 inside pix-c(config)# static (inside,outside) 192.168.199.0 192.168.199.0 netmask   255.255.255.0 0 0 pix-c(config)# object-group icmp-type ICMP pix-c(config-icmp)# icmp-object echo pix-c(config-icmp)# icmp-object echo-reply pix-c(config-icmp)# icmp-object time-exceeded pix-c(config-icmp)# icmp-object unreachable pix-c(config-icmp)# exit pix-c(config)# access-list acl_out permit tcp any host 192.168.199.100 eq telnet pix-c(config)# access-list acl_out permit tcp any host 192.168.199.100 eq www pix-c(config)# access-list acl_out permit icmp any host 192.168.199.100   object-group ICMP pix-c(config)# access-list acl_in permit tcp 192.168.199.0 255.255.255.0 eq telnet   any pix-c(config)# access-list acl_in permit tcp 192.168.199.0 255.255.255.0 eq www   any pix-c(config)# access-list acl_in permit icmp 192.168.199.0 255.255.255.0 any   object-group ICMP pix-c(config)# access-list acl_in permit icmp 192.168.200.0 255.255.255.0 any   object-group ICMP pix-c(config)# access-group acl_out in interface outside pix-c(config)# access-group acl_in in interface inside pix-c(config)# route outside 0.0.0.0 0.0.0.0 192.168.100.1 1 pix-c(config)# route inside 192.168.199.0 255.255.255.0 192.168.200.1 1

Outside CSM FWLB Configuration

This section shows the configuration for the outside CSM. Notice that this is all done from the Catalyst 6500 CLI, because the commands pertaining to the CSM are automatically downloaded to it. This section begins with the preliminary commands to define VLANs and connectivity. Notice that the Catalyst switch handles routing only from the public network to the outside CSM. The outside and inside CSMs handle all other traffic forwarding from VLAN 10 on to the inside (secure) network. This effectively isolates the inside and outside networks, although they might be present in the same switch chassis.

 Switch(config)# hostname CatalystA ! Define the VLANs CatalystA(config)# vlan 10 CatalystA(config-vlan)# name Public-Network CatalystA(config)# vlan 100 CatalystA(config-vlan)# name FW-outside CatalystA(config)# vlan 200 CatalystA(config-vlan)# name FW-inside CatalystA(config)# vlan 400 CatalystA(config-vlan)# name Internal-Network ! Pass the VLANs to the two FWSMs CatalystA(config)# firewall module 3 vlan-group 1 CatalystA(config)# firewall module 4 vlan-group 1 CatalystA(config)# firewall vlan-group 1  100,200 ! Set up the outside connection to PIX Firewall-C CatalystA(config)# interface GigabitEthernet8/1 CatalystA(config-if)# description PIX-C outside CatalystA(config-if)# no ip address CatalystA(config-if)# switchport CatalystA(config-if)# switchport access vlan 100 CatalystA(config-if)# switchport mode access CatalystA(config-if)# spanning-tree portfast ! Define the Catalyst presence only on VLAN 10; CSM will handle everything beyond ! this CatalystA(config-if)# interface Vlan10 CatalystA(config-if)# ip address 192.168.1.2 255.255.255.0 ! Now define a way to get out to the public network CatalystA(config)# ip default-gateway 192.168.1.1 CatalystA(config)# ip route 0.0.0.0 0.0.0.0 192.168.1.1 ! For the internal (secure) network, define a route that points to the outside CSM CatalystA(config)# ip route 192.168.199.0 255.255.255.0 192.168.1.1

Now, the actual outside CSM commands are addressed. The ip slb mode csm command should already be used to force the switch to perform all SLB functions on the CSM instead of using the route processor. (Remember that a CSM performs generic SLB; FWLB is possible by having SLB on each side of a firewall farm.)

 ! Configure the outside CSM on CatalystA CatalystA(config)# module ContentSwitchingModule 7 CatalystA(config-module-csm)# vlan 10 client CatalystA(config-slb-vlan-client)# ip address 192.168.1.3 255.255.255.0 CatalystA(config-slb-vlan-client)# gateway 192.168.1.2 CatalystA(config-slb-vlan-client)# exit ! CatalystA(config-module-csm)# vlan 100 server CatalystA(config-slb-vlan-server)# ip address 192.168.100.1 255.255.255.0 CatalystA(config-slb-vlan-server)# exit ! ! Define a probe to detect failures within the firewall farm CatalystA(config-module-csm)# probe FARM-PROBE-OUTSIDE icmp CatalystA(config-slb-probe-icmp)# interval 15 CatalystA(config-slb-probe-icmp)# exit ! ! Define the inbound firewall farm CatalystA(config-module-csm)# serverfarm FW-INBOUND CatalystA(config-slb-sfarm)# no nat server CatalystA(config-slb-sfarm)# no nat client CatalystA(config-slb-sfarm)# probe FARM-PROBE-OUTSIDE CatalystA(config-slb-sfarm)# predictor hash address source CatalystA(config-slb-sfarm)# real 192.168.100.3 CatalystA(config-slb-real)# inservice CatalystA(config-slb-real)# exit CatalystA(config-slb-sfarm)# real 192.168.100.4 CatalystA(config-slb-real)# inservice CatalystA(config-slb-real)# exit CatalystA(config-slb-sfarm)# real 192.168.100.5 CatalystA(config-slb-real)# inservice CatalystA(config-slb-real)# exit ! ! Define the front end of the inbound FW farm CatalystA(config-module-csm)# vserver V-INBOUND CatalystA(config-slb-vserver)# virtual 0.0.0.0 0.0.0.0 any CatalystA(config-slb-vserver)# vlan 10 CatalystA(config-slb-vserver)# serverfarm FW-INBOUND CatalystA(config-slb-vserver)# inservice CatalystA(config-slb-vserver)# exit ! ! Define the outbound forwarder CatalystA(config-module-csm)# serverfarm PUBLIC CatalystA(config-slb-sfarm)# no nat server CatalystA(config-slb-sfarm)# no nat client CatalystA(config-slb-sfarm)# predictor forward CatalystA(config-slb-sfarm)# exit ! ! Define the front end to the outbound forwarder CatalystA(config-module-csm)# vserver V-PUBLIC-100 CatalystA(config-slb-vserver)# virtual 0.0.0.0 0.0.0.0 any CatalystA(config-slb-vserver)# vlan 100 CatalystA(config-slb-vserver)# serverfarm PUBLIC CatalystA(config-slb-vserver)# inservice !

Inside CSM Configuration

This section covers the configuration for the inside CSM. At this point, you should notice that you are still configuring things on Catalyst A. Only one physical CSM acts as both outside and inside FWLB devices.

First, here are the commands to define VLANs and connectivity:

 ! Set up the inside connection to PIX Firewall-C CatalystA(config)# interface GigabitEthernet8/2 CatalystA(config-if)# description PIX-C inside CatalystA(config-if)# no ip address CatalystA(config-if)# switchport CatalystA(config-if)# switchport access vlan 200 CatalystA(config-if)# switchport mode access CatalystA(config-if)# spanning-tree portfast ! Set up the inside connection the example server 192.168.199.100 CatalystA(config)# interface GigabitEthernet8/3 CatalystA(config-if)# description Inside Server CatalystA(config-if)# no ip address CatalystA(config-if)# switchport CatalystA(config-if)# switchport access vlan 400 CatalystA(config-if)# switchport mode access CatalystA(config-if)# spanning-tree portfast

Next are the actual inside CSM commands:

 ! Configure the inside CSM (also on CatalystA) CatalystA(config)# module ContentSwitchingModule 7 CatalystA(config-module-csm)# vlan 400 client CatalystA(config-slb-vlan-client)# ip address 192.168.199.1 255.255.255.0 CatalystA(config-slb-vlan-client)# exit ! CatalystA(config-module-csm)# vlan 200 server CatalystA(config-slb-vlan-server)# ip address 192.168.200.1 255.255.255.0 CatalystA(config-slb-vlan-server)# exit ! ! Define a probe to detect failures within the firewall farm CatalystA(config-module-csm)# probe FARM-PROBE-INSIDE icmp CatalystA(config-slb-probe-icmp)# interval 15 ! ! Define the outbound firewall farm CatalystA(config-module-csm)# serverfarm FW-OUTBOUND CatalystA(config-slb-sfarm)# no nat server CatalystA(config-slb-sfarm)# no nat client CatalystA(config-slb-sfarm)# probe FARM-PROBE-INSIDE CatalystA(config-slb-sfarm)# predictor hash address destination CatalystA(config-slb-sfarm)# real 192.168.200.3 CatalystA(config-slb-real)# inservice CatalystA(config-slb-real)# exit CatalystA(config-slb-sfarm)# real 192.168.200.4 CatalystA(config-slb-real)# inservice CatalystA(config-slb-real)# exit CatalystA(config-slb-sfarm)# real 192.168.200.5 CatalystA(config-slb-real)# inservice CatalystA(config-slb-real)# exit ! ! Define the front end of the outbound FW farm CatalystA(config-module-csm)# vserver V-OUTBOUND CatalystA(config-slb-vserver)# virtual 0.0.0.0 0.0.0.0 any CatalystA(config-slb-vserver)# vlan 400 CatalystA(config-slb-vserver)# serverfarm FW-OUTBOUND CatalystA(config-slb-vserver)# inservice CatalystA(config-slb-vserver)# exit ! ! Define the inbound forwarder CatalystA(config-module-csm)# serverfarm INTERNAL CatalystA(config-slb-sfarm)# no nat server CatalystA(config-slb-sfarm)# no nat client CatalystA(config-slb-sfarm)# predictor forward CatalystA(config-slb-sfarm)# exit ! ! Define the front end to the inbound forwarder CatalystA(config-module-csm)# vserver V-INBOUND-200 CatalystA(config-slb-vserver)# virtual 192.168.199.100 255.255.255.255 any CatalystA(config-slb-vserver)# vlan 200 CatalystA(config-slb-vserver)# serverfarm INTERNAL CatalystA(config-slb-vserver)# inservice !

Displaying Information About CSM FWLB

You can use the switch commands listed in Table 8-3 to display helpful information about a CSM FWLB configuration and its status.

Table 8-3. Commands to Display CSM FWLB Configuration and Status
Command Syntax	Display Function
`Switch#` `show module csm` `slot` `serverfarms` `[name` `serverfarm-name] [detail]` or `Switch#` `show module csm` `slot` `vserver` `[detail]`	Firewall farm status
`Switch#` `show module csm` `slot` `real` `[sfarm` `sfarm-name]`	Status of firewalls in a farm
`Switch#` `show module csm` `slot` `conns` `[vserver` `virtserver-name] [client` `ip-address] [detail]`	Load-balancing connections to firewalls
`Switch#` `show module csm` `slot` `probe icmp` `[name` `probe_name] [detail]`	Probe information
`Switch# show module csm slot sticky [groups` `\|` `client` `ip_address]`	Sticky connections

CSM FWLB Output Example

For the network shown in Figure 8-6, you can display the status of the inside (outbound) firewall farm as follows:

 Switch# show module csm 7 reals real                  server farm      weight  state          conns/hits ------------------------------------------------------------------------- 192.168.200.3         FW-OUTBOUND      8       OPERATIONAL    0 192.168.200.4         FW-OUTBOUND      8       OPERATIONAL    0 192.168.200.5         FW-OUTBOUND      8       FAILED         0 Switch#

Notice that two of the three firewalls are working, but the third is in a FAILED state. It hasn't answered probes or ARP requests from the CSM.

Now, suppose the third firewall is restored to service. You can use the same command to watch the connection load that has been distributed to each firewall. Remember that the number of connections shown represents only the new connections that have originated on one side of the firewall farm. The return traffic for those connections is always forwarded back through the same firewalls, so it isn't recorded as additional connections.

For example, the show module csm mod reals command has been issued after each new outbound connection. Here, the destination IP addresses have been incremented just to show how the con-nections build and are distributed among the firewalls in the farm:

 Switch# show module csm 7 reals real                  server farm      weight  state          conns/hits ------------------------------------------------------------------------- 192.168.200.3         FW-OUTBOUND      8       OPERATIONAL    0 192.168.200.4         FW-OUTBOUND      8       OPERATIONAL    0 192.168.200.5         FW-OUTBOUND      8       OPERATIONAL    0 Switch# show module csm 7 reals real                  server farm      weight  state          conns/hits ------------------------------------------------------------------------- 192.168.200.3         FW-OUTBOUND      8       OPERATIONAL    1 192.168.200.4         FW-OUTBOUND      8       OPERATIONAL    0 192.168.200.5         FW-OUTBOUND      8       OPERATIONAL    0 Switch# show module csm 7 reals real                  server farm      weight  state          conns/hits ------------------------------------------------------------------------- 192.168.200.3         FW-OUTBOUND      8       OPERATIONAL    1 192.168.200.4         FW-OUTBOUND      8       OPERATIONAL    1 192.168.200.5         FW-OUTBOUND      8       OPERATIONAL    0 Switch# show module csm 7 reals real                  server farm      weight  state          conns/hits ------------------------------------------------------------------------- 192.168.200.3         FW-OUTBOUND      8       OPERATIONAL    1 192.168.200.4         FW-OUTBOUND      8       OPERATIONAL    1 192.168.200.5         FW-OUTBOUND      8       OPERATIONAL    1 Switch# show module csm 7 reals real                  server farm      weight  state          conns/hits ------------------------------------------------------------------------- 192.168.200.3         FW-OUTBOUND      8       OPERATIONAL    2 192.168.200.4         FW-OUTBOUND      8       OPERATIONAL    1 192.168.200.5         FW-OUTBOUND      8       OPERATIONAL    1

As long as the destination addresses are increasing by 1, the connections are distributed in a round-robin fashion. In actual use, the source and destination addresses can vary greatly, causing the hash algorithm to distribute the connections in an unpredictable fashion. The idea is that there should be a large distribution of address values, causing the connections to be distributed more or less equally among the firewalls.

The CSM must also build an ARP cache so that it can communicate with other devices. To display the MAC and IP address associations it has built, you can use the show module csm mod arp command:

 Switch# show module csm 7 arp Internet Address  Physical Interface  VLAN      Type       Status --------------------------------------------------------------------  192.168.199.1    00-02-FC-E0-7E-B2   400       --SLB--    local  192.168.200.1    00-02-FC-E0-7E-B2   200       --SLB--    local  192.168.200.3    00-0B-46-B3-4E-40   200       REAL       up(0 misses)  192.168.200.4    00-0B-5F-0C-8A-C0   200       REAL       up(0 misses)  192.168.200.5    00-90-27-6C-3D-0A   200       REAL       up(0 misses)  192.168.199.100  00-50-E2-C6-F6-80   400       LEARNED    up(0 misses) Switch#

fThe --SLB-- entries are the CSM VLAN interfaces, the REAL entries are the configured firewall addresses, and the LEARNED entries have been learned from traffic on a VLAN.

To see a quick summary of how the CSM probes have been configured, use the show module csm mod probe icmp command:

 Switch# show module csm 7 probe icmp probe               type      interval retries failed  open   receive --------------------------------------------------------------------- FARM-PROBE-INSIDE   icmp      10       2       300            10 Switch#

Here, the probe is using ICMP at 10-second intervals. The probe waits 10 seconds to receive a reply and declares the firewall failed after two probes go unanswered. Finally, as soon as a firewall is in the failed state, the CSM waits 300 seconds before trying to probe again.

You might also be interested in monitoring the connections that are load-balanced by a CSM. The show module csm mod conns command displays a list of the active connections:

 Switch# show module csm 7 conns     prot vlan source                destination           state ---------------------------------------------------------------------- In  TCP  400  192.168.199.100:13825    10.1.17.9:23       ESTAB Out TCP  200  10.1.17.9:23          192.168.199.100:13825 ESTAB In  TCP  400  192.168.199.100:13313    10.1.17.8:23       ESTAB Out TCP  200  10.1.17.8:23          192.168.199.100:13313 ESTAB In  TCP  400  192.168.199.100:12801    10.1.17.7:23       ESTAB Out TCP  200  10.1.17.7:23          192.168.199.100:12801 ESTAB In  TCP  400  192.168.199.100:11265    10.1.17.4:23       ESTAB Out TCP  200  10.1.17.4:23          192.168.199.100:11265 ESTAB

Each is shown with the In and Out VLANs, so you can see the connection traffic in both directions. Notice that the CSM doesn't have a way to display a connection and the firewall that has been assigned to handle it.