Section 8-2. Firewall Load Balancing in Software

8-2. Firewall Load Balancing in Software

Firewall Load Balancing (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 is performed in software on the Catalyst 6500 switch platform, only in native IOS (also called supervisor IOS). This is known as the IOS Server Load Balancing (IOS SLB or IOS FWLB) feature. If a Catalyst 6500 is already in place in a network, it can also be used as a firewall load-balancing device through further IOS configuration.

IOS FWLB works by acting as the gateway or next-hop address that routes traffic toward one or more firewalls. It computes a hash value on each new inbound traffic flow, based on the source and destination IP addresses and ports. This hash value determines which firewall will be used within the firewall farm. This is called a route lookup.

All the firewall interfaces grouped as a firewall farm must be located in a common Layer 2 VLAN and IP subnet. This is because the IOS FWLB device can modify only the Layer 2 information in packets passing through it. The IOS FWLB device substitutes the MAC address of the target firewall for the destination address in each packet.

IOS FWLB can detect a firewall failure by monitoring probe activity. Each probe is used to determine the state of every firewall in the farm.

You can add the Hot Standby Router Protocol (HSRP) to provide a stateless backup redundancy when multiple IOS FWLB devices are positioned on each side of the firewall farm. If one device fails, a redundant device can take over its function for the next inbound connection.

Multiple IOS FWLB devices can also use stateful backup for redundancy when they are placed together on the same side of a firewall farm. Backup devices keep state information dynamically and can take over immediately if a failure occurs.

TIP

You can mix different types of FWLB devices around a firewall farm. For example, an IOS FWLB (Catalyst 6500 native IOS) might balance traffic to the outside interfaces of a firewall farm, and an FWLB hardware platform handles traffic to the inside interfaces. In this case, it is not possible to provide either stateless or stateful backup, because the different types have different support for the backup protocols. To use these backup methods, you must use the same FWLB method on both sides of the firewall farm.

IOS FWLB Configuration Notes

IOS 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).

Figure 8-2 illustrates this by showing two separate IOS FWLB devices on the two sides (inside and outside) of the firewall farm.

Figure 8-2. IOS FWLB Placement Surrounding a Firewall Farm

As soon as a new inbound connection is assigned to a firewall in the farm, how does the return traffic find its way back? For each connection, remember that both forward and reverse traffic must pass through the same firewall so that the stateful inspection can work properly. When the connection is assigned to a firewall in the forward direction, the FWLB device on the other side of the firewall farm simply relays the return traffic using that same firewall in the farm.

TIP

Some applications automatically open connections on other ports during their normal operation. A firewall might not follow these new connections as a part of its normal stateful inspection, except that the fixup or inspection engine feature allows it to inspect and track additional "helper" or "buddy" connections for some application protocols.

This concept must also be extended to FWLB. An IOS FWLB device uses sticky connections to keep any newly forming buddy connections heading toward the same firewall that has already been inspecting the original application connection. In other words, as soon as a connection has been opened and assigned to a firewall, any new connections between the same two hosts also are assigned to that firewall.

As you might expect, sticky connections must be supported on every FWLB device so that they can be properly inspected in every direction.

It is entirely possible to define more than one firewall farm on an IOS FWLB device. This would apply to networks that have several distinct firewall farms, each protecting a unique customer network, server farm, or other entity.

At this point, it might be tempting to try to use a single IOS FWLB platform to operate on both sides of one firewall farm. After all, it is possible to define two different firewall farms on an IOS FWLB device. Why not define an outside and an inside firewall farm, without going to the expense of using a second FWLB device? The problem with this idea is that it isn't very secure. FWLB occurs on the same platform that performs routing on both the outside and inside networks. Therefore, it is all too easy for the Catalyst 6500 to route packets from outside to inside without even going through the firewall farm. In other words, it is too possible to bypass the firewalls completely. Two physically separate IOS FWLB platforms should be used to completely isolate the two sides of the network.

The configuration steps are also presented here for one side of the firewall farm only (inside or outside). You need to repeat the sequence of steps for the IOS FWLB device on the other side of the firewall farm, too. Figure 8-3 illustrates this concept by separating the inside and outside FWLB devices. The top half of the figure shows how the outside IOS FWLB device should be configured to load-balance inbound connections to the firewall farm. The bottom half shows the inside FWLB device that handles the outbound connections.

Figure 8-3. Separating the Outside and Inside IOS FWLB Functions for Configuration

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

IOS FWLB Configuration

You can use the following steps to configure IOS FWLB on one device. Remember that FWLB requires a load-balancing device on each side of the firewall farm. Be sure to repeat the entire configuration process for the outside and inside IOS FWLB platforms.

1.	Define connectivity away from the firewall farm: Router(config)# vlan vlan-id Router(config)# interface vlan vlan-id Router(config-if)# ip address ip-address subnet-mask Router(config-if)# no shutdown The FWLB must be able to route packets to and from the network farthest from the firewall farm. For the outside FWLB device, this would be the public network. For the inside FWLB device, this would be the internal (secure) network. You can use the commands shown to define a VLAN and then a switched virtual interface (SVI) so that the VLAN has a Layer 3 presence on the switch.
2.	Define connectivity toward the firewall farm: Router(config)# vlan vlan-id Router(config)# interface vlan vlan-id Router(config-if)# ip address ip-address subnet-mask Router(config-if)# no shutdown All firewalls in the firewall farm must have their outside interfaces residing on one VLAN, vlan-id, and their inside interfaces residing on another. Therefore, you need to define the VLAN on this side of the firewall, as well as its Layer 3 SVI presence. TIP An IOS FWLB device uses the IOS SLB feature. Therefore, it is also possible to use the inside FWLB device to load-balance traffic to server farms located on the secured inside network. Additional configuration is required to do this. For more information, refer to Chapter 10 of Cisco Field Manual: Catalyst Switch Configuration by Dave Hucaby and Steve McQuerry.
3.	Define routes to any networks on the other side of the firewall farm: Router(config)# ip route inside-network subnet-mask fw-outside-address Here, the outside FWLB device must know about any networks that lie on the other side of the firewall farm. You can easily accomplish this by defining static routes that use the firewalls as the next hop. If you do not define these routes, the FWLB device has no idea where to find the inside protected networks. The firewall farm itself has no single virtual IP address. Therefore, configure one of these static routes using each of the physical firewalls in the firewall farm as the gateway address. NOTE If multiple gateway addresses are configured for the same static route, does the Catalyst switch attempt to load-balance packets based on routing decisions rather than the FWLB algorithm? No, because the switch looks up the route only to find a next-hop address. Any of the firewall addresses are fine, because the FWLB algorithm still selects a target firewall and substitutes the destination MAC address according to the FWLB rules. You define multiple routes so that every physical firewall is known as a next-hop gateway. In case one firewall is down or is removed from service in the firewall farm, a route can be found using the other firewalls.
4.	Define a probe to detect a firewall failure. You should define a unique probe for each physical firewall in the firewall farm so that individual firewall failures can be detected. To do this, repeat Steps 4a through 4d for each firewall. Name the probe: Router(config)# ip slb probe name ping The probe is named name (a text string of up to 15 characters) and can be referenced by other FWLB commands. The probe uses ping (ICMP) packets to see if the target answers. Define a target address for the probe: Router(config-slb-probe)# address ip-address Ping requests are sent to the target address. If the target replies, it is assumed to be active and functional. TIP The probe's purpose is to detect whether a firewall in the firewall farm is alive. Therefore, you can choose a firewall's outside interface address as the target for the outside FWLB device. This determines if the outside interface is up and active. However, it doesn't determine if the firewall is inspecting traffic as it should. You must also make sure that the firewall has been configured to allow ICMP packets to be received and answered by its own interface address. (Optional) Set the time between probes: Router(config-slb-probe)# interval seconds Probes are sent toward the target at intervals of seconds (1 to 65535 seconds; the default is 1 second). (Optional) Define the criteria for a failure: Router(config-slb-probe)# faildetect retry-count With IOS FWLB, a firewall is considered to have failed if retry-count (1 to 255; the default is 10) consecutive ping probes go unanswered.
5.	Define the firewall farm: Router(config)# ip slb firewallfarm firewallfarm-name The collection of firewalls is referenced by firewallfarm-name (a text string of up to 15 characters).
6.	Identify a firewall in the farm. Define the firewall's IP address: Router(config-slb-fw)# real ip-address The firewall is directly connected (the same logical subnet) to the load-balancing device with an interface at IP address ip-address. For example, this is the outside firewall interface address when configuring the outside FWLB device. Use a probe to detect a firewall failure: Router(config-slb-fw-real)# probe probe-name The probe that is defined by probe-name (a text string) is used periodically to see if the firewall has failed. A different probe is needed for each firewall, because the firewall's IP address is configured in the probe definition. You can define more than one probe for a firewall by repeating this command. The firewall is declared down if it fails just one probe. A firewall must pass all probes to be recovered again. Allow FWLB to begin using the firewall: Router(config-slb-fw-real)# inservice By default, FWLB does not use the real firewall unless it is placed in service. To remove a firewall from service, use the no inservice command. Assign a relative weight to the firewall: Router(config-slb-fw-real)# weight weighting-value By default, each real firewall in the farm is given an equal weight so that the load balancing is symmetric. You can adjust the firewall weighting so that a firewall with more capacity or higher performance is given more connections than one with lesser capacity. You can assign the real firewall a weighting-value (1 to 255; the default is 8) that is relative to the other real firewalls. A higher weighting results in more load given to the firewall.
7.	(Optional; outside FWLB only) Define one or more flows that will be sent to the firewall farm: Router(config-slb-fw)# access [source source-ip-address network-mask] [destination destination-ip-address network-mask] When multiple firewall farms exist, traffic can be identified by address and sent through the appropriate firewall farm. A traffic flow is defined by its source and destination addresses and subnet masks. If either the source or destination keywords are omitted, they default to 0.0.0.0 with a mask of 0.0.0.0, signifying all addresses and networks. This is the default behavior. In other words, the default assumes that only one firewall farm exists, and all inbound traffic is destined to pass through it. For example, the following command could be used to route traffic destined for the network 192.168.77.0/24 through the firewall farm being configured: Router(config-slb-fw)# access destination 192.168.77.0 255.255.255.0
8.	(Optional) Choose an FWLB method: Router(config-slb-fw)# predictor hash address [port] By default, IOS FWLB computes a hash value from a flow's source and destination IP addresses to select a destination firewall. This usually works well, because the number of source hosts on the outside public network is quite large and causes the hash function to take on many different values. If you find that the number of unique outside and inside addresses is small, the connections might not be balanced well across the members of the firewall farm. In this case, you can use the port keyword to use the source and destination addresses, as well as the source and destination TCP or UDP port numbers, in the selection decision. Port numbers vary greatly, so the chances of choosing a different firewall with each new connection are much greater.
9.	(Optional) Use stateful backup to recover from a failure: Router(config-slb-fw)# replicate casa listening-ip remote-ip port-number [interval] [password [0\|7] password [timeout]] The redundant FWLB devices use the Cisco Appliance Services Architecture (CASA) structure to exchange and replicate state information. This is sent from the listening-ip address (an interface on the local device) to the remote-ip address (an interface on the backup device) using port-number (1 to 65535). Replication messages are sent at interval seconds (1 to 300; the default is 10). You can use a password (a text string; use 0 if it's unencrypted, the default, or 7 if it's encrypted) for MD5 authentication with the backup device. The optional timeout (0 to 65535 seconds; the default is 180 seconds) defines a time period when the password can be migrated from an old value to a new one. During this time, both old and new passwords are accepted. For example, suppose CASA is first configured to use the password BigSecret with a timeout of 300 seconds (5 minutes) with the following command: Router(config-slb-fw)# replicate casa 10.1.1.1 10.1.1.2 4000 password 0 BigSecret 300 The password is migrated to NewBigSecret with the following command: Router(config-slb-fw)# replicate casa 10.1.1.1 10.1.1.2 4000 password 0 NewBigSecret 300 As soon as this command is entered, the local FWLB device begins to accept both BigSecret and NewBigSecret as passwords. After 300 seconds has elapsed, only the new NewBigSecret password is accepted.
10.	(Optional) Adjust the TCP or UDP connection parameters: Router(config-slb-fw)# {tcp \| udp} You might need to make adjustments to both TCP and UDP, depending on how connections should be handled. In this case, this command can be repeated to configure each independently. (Optional; TCP only) Hold connections open after they are terminated: Router(config-slb-fw-protocol)# delay duration After a TCP connection is terminated, the connection context can be maintained for duration (1 to 600 seconds; the default is 10 seconds). This can be useful when packets arrive out of sequence and the connection is closed before the last missing data packet arrives. (Optional; TCP only) Hold connections open after no activity: Router(config-slb-fw-protocol)# idle duration When an absence of packets is detected for a connection, the connection is kept open for duration (10 to 65535 seconds; the default is 3600 seconds, or 1 hour) before an RST is sent. (Optional) Specify the maximum number of connections: Router(config-slb-fw-protocol)# maxconns number At any given time, the firewall is limited to number (1 to 4294967295; the default is 4294967295) active connections. (Optional) Assign subsequent connections from a source address to the same firewall: Router(config-slb-fw-protocol)# sticky duration [netmask netmask] For a given IP address, connections are assigned to the last-used firewall for duration (0 to 65535 seconds). A netmask can be given such that all source addresses within the mask are assigned to the same firewall. Sticky connections are very useful for applications that open connections on other ports for control or data channels. Examples of this include FTP, H.323, and RTSP. The firewall must be able to inspect these additional connections too, so they must be sent through the same firewall.
11.	Allow FWLB to begin using the firewall farm as a whole: Router(config-slb-fw)# inservice By default, FWLB doesn't use the firewall farm unless it is placed in service. To remove a firewall farm from service, use the no inservice command.

IOS Firewall Load-Balancing Example

FWLB requires two load-balancing devices:

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

Figure 8-4 shows a network diagram for this example. Note that this same example is also used in section 8-3 to show how IOS FWLB and the CSM are configured in similar scenarios.

Figure 8-4. Network Diagram for the IOS 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 IOS 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 IOS 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.

Basic Firewall Configuration

This section shows the firewall configurations first. Firewalls A and B are Firewall Services Modules (FWSMs) installed in the Catalyst A chassis. Firewall C is an external Cisco PIX Firewall, connected to Catalyst A through a Gigabit Ethernet link. The configuration commands in this section 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 connections 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 IOS FWLB Configuration

This section shows the configuration for the outside load-balancing device. Notice that this is all done from the Catalyst 6500 (Catalyst A) CLI, because the switch Supervisor performs both the multilayer switching and IOS FWLB functions.

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

 Switch(config)# hostname CatalystA ! Define the VLANs CatalystA(config)# vlan 10 CatalystA(config-vlan)# name Public-Network CatalystA(config-vlan)# vlan 100 CatalystA(config-vlan)# name FW-outside CatalystA(config-vlan)# vlan 200 CatalystA(config-vlan)# name FW-inside CatalystA(config-vlan)# exit ! 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 a trunk to the inside IOS FWLB Catalyst CatalystA(config)# interface GigabitEthernet8/1 CatalystA(config-if)# description Inside networks for IOS FWLB Catalyst B CatalystA(config-if)# no ip address CatalystA(config-if)# switchport CatalystA(config-if)# switchport trunk encapsulation dot1q CatalystA(config-if)# switchport trunk native vlan 2 CatalystA(config-if)# switchport trunk allowed vlan 200 CatalystA(config-if)# switchport trunk on CatalystA(config-if)# switchport mode trunk ! Set up the connection to PIX Firewall-C CatalystA(config-if)# interface GigabitEthernet8/2 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 IOS FWLB presence on VLAN 100 CatalystA(config-if)# interface Vlan100 CatalystA(config-if)# ip address 192.168.100.1 255.255.255.0 ! Define the IOS FWLB presence on the public network CatalystA(config-if)# interface Vlan10 CatalystA(config-if)# ip address 192.168.1.2 255.255.255.0 CatalystA(config-if)# exit ! 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 uses each firewall CatalystA(config)# ip route 192.168.199.0 255.255.255.0 192.168.100.3 CatalystA(config)# ip route 192.168.199.0 255.255.255.0 192.168.100.4 CatalystA(config)# ip route 192.168.199.0 255.255.255.0 192.168.100.5

Next, here are the actual IOS FWLB configuration commands:

 ! Define a ping probe for firewall A outside CatalystA(config)# ip slb probe FW-A ping CatalystA(config-slb-probe)# address 192.168.100.3 CatalystA(config-slb-probe)# interval 10 CatalystA(config-slb-probe)# faildetect 2 CatalystA(config-slb-probe)# exit ! Define a ping probe for firewall B outside CatalystA(config)# ip slb probe FW-B ping CatalystA(config-slb-probe)# address 192.168.100.4 CatalystA(config-slb-probe)# interval 10 CatalystA(config-slb-probe)# faildetect 2 CatalystA(config-slb-probe)# exit ! Define a ping probe for firewall C outside CatalystA(config)# ip slb probe FW-C ping CatalystA(config-slb-probe)# address 192.168.100.5 CatalystA(config-slb-probe)# interval 10 CatalystA(config-slb-probe)# faildetect 2 CatalystA(config-slb-probe)# exit ! ! Define the actual firewall farm CatalystA(config)# ip slb firewallfarm FW-INBOUND CatalystA(config-slb-fw)# inservice ! Firewall A CatalystA(config-slb-fw)# real 192.168.100.3 CatalystA(config-slb-fw-real)# probe FW-A CatalystA(config-slb-fw-real)# inservice CatalystA(config-slb-fw-real)# exit ! Firewall B CatalystA(config-slb-fw)# real 192.168.100.4 CatalystA(config-slb-fw-real)# probe FW-B CatalystA(config-slb-fw-real)# inservice CatalystA(config-slb-fw-real)# exit ! Firewall C CatalystA(config-slb-fw)# real 192.168.100.5 CatalystA(config-slb-fw-real)# probe FW-C CatalystA(config-slb-fw-real)# inservice CatalystA(config-slb-fw-real)# exit !

Inside IOS FWLB Configuration

This section covers the configuration for the inside load-balancing device (Catalyst B).

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

 Switch(config)# hostname CatalystB ! Define the VLANs CatalystB(config)# vlan 200 CatalystB(config-vlan)# name FW-inside CatalystB(config-vlan)# vlan 400 CatalystB(config-vlan)# name Internal-Network CatalystB(config-vlan)# exit ! Set up a trunk to the outside Catalyst CatalystB(config)# interface GigabitEthernet8/1 CatalystB(config-if)# description Inside networks from IOS FWLB Catalyst A CatalystB(config-if)# no ip address CatalystB(config-if)# switchport CatalystB(config-if)# switchport trunk encapsulation dot1q CatalystB(config-if)# switchport trunk native vlan 2 CatalystB(config-if)# switchport trunk allowed vlan 200 CatalystB(config-if)# switchport trunk on CatalystB(config-if)# switchport mode trunk ! Set up the connection to PIX Firewall-C CatalystB(config-if)# interface GigabitEthernet8/2 CatalystB(config-if)# description PIX-C inside CatalystB(config-if)# no ip address CatalystB(config-if)# switchport CatalystB(config-if)# switchport access vlan 200 CatalystB(config-if)# switchport mode access CatalystB(config-if)# spanning-tree portfast ! Define the IOS FWLB presence on VLAN 200 CatalystB(config-if)# interface Vlan200 CatalystB(config-if)# ip address 192.168.200.1 255.255.255.0 ! Define the IOS FWLB presence on the inside (secure) network CatalystB(config-if)# interface Vlan400 CatalystB(config-if)# ip address 192.168.199.1 255.255.255.0 CatalystB(config-if)# exit ! Now define a way to get out to the public network ! Define default routes that use each firewall's inside interface as a gateway CatalystB(config)# ip route 0.0.0.0 0.0.0.0 192.168.200.3 CatalystB(config)# ip route 0.0.0.0 0.0.0.0 192.168.200.4 CatalystB(config)# ip route 0.0.0.0 0.0.0.0 192.168.200.5

Next, here are the actual IOS FWLB commands:

 ! Define a ping probe for firewall A inside CatalystB(config)# ip slb probe FW-A ping CatalystB(config-slb-probe)# address 192.168.200.3 CatalystB(config-slb-probe)# interval 10 CatalystB(config-slb-probe)# faildetect 2 CatalystB(config-slb-probe)# exit ! Define a ping probe for firewall B inside CatalystB(config)# ip slb probe FW-B ping CatalystB(config-slb-probe)# address 192.168.200.4 CatalystB(config-slb-probe)# interval 10 CatalystB(config-slb-probe)# faildetect 2 CatalystB(config-slb-probe)# exit ! Define a ping probe for firewall C inside CatalystB(config)# ip slb probe FW-C ping CatalystB(config-slb-probe)# address 192.168.200.5 CatalystB(config-slb-probe)# interval 10 CatalystB(config-slb-probe)# faildetect 2 CatalystB(config-slb-probe)# exit ! ! Define the actual firewall farm CatalystB(config)# ip slb firewallfarm FW-OUTBOUND CatalystB(config-slb-fw)# inservice ! Firewall A CatalystB(config-slb-fw)# real 192.168.200.3 CatalystB(config-slb-fw-real)# probe FW-A CatalystB(config-slb-fw-real)# inservice CatalystB(config-slb-fw-real)# exit ! Firewall B CatalystB(config)# real 192.168.200.4 CatalystB(config-slb-fw-real)# probe FW-B CatalystB(config-slb-fw-real)# inservice CatalystB(config-slb-fw-real)# exit ! Firewall C CatalystB(config)# real 192.168.200.5 CatalystB(config-slb-fw-real)# probe FW-C CatalystB(config-slb-fw-real)# inservice CatalystB(config-slb-fw-real)# exit !

Displaying Information About IOS FWLB

Table 8-2 lists the switch commands you can use to display helpful information about IOS firewall load-balancing configuration and status.

Table 8-2. Commands to Display IOS FWLB Configuration and Status
Command Syntax	Display Function
`Router#` `show ip slb firewallfarms` `[detail]`	Firewall farm status
`Router#` `show ip slb reals`	Status of firewalls in a farm
`Router#` `show ip slb reals` `[sfarm` `firewall-farm-name]` `detail`	Firewall weight and connection counters
`Router#` `show ip slb conn` `[firewall` `firewallfarm-name] [detail]`	Load-balancing connections to firewalls
`Router#` `show ip slb probe` `[name` `probe_name] [detail]`	Probes
`Router#` `show ip slb sticky`	Sticky connections

IOS FWLB Output Example

For the sample network shown in Figure 8-4, the outside firewall farm status is as follows:

 Router# show ip slb firewallfarms name FW-INBOUND firewall farm    hash        state         reals ------------------------------------------------ FW-INBOUND       IPADDR      INSERVICE     3 Router# show ip slb firewallfarms name FW-INBOUND detail FW-INBOUND, hash = IPADDR, state = INSERVICE, reals = 3   FirewallTCP7:    sticky: <none>    idle = 3600, delay = 10, syns = 11, syn drop = 0    maxconns = 4294967295, conns = 11, total conns = 11   FirewallDG8:    sticky: <none>    idle = 3600    maxconns = 4294967295, conns = 0, total conns = 2653   Real firewalls:     192.168.100.3, weight = 8, OPERATIONAL, conns = 3     192.168.100.4, weight = 8, OPERATIONAL, conns = 5     192.168.100.5, weight = 8, OPERATIONAL, conns = 3   Total connections = 11

Here, the firewall farm FW-INBOUND has three "real" firewalls, each weighted equally using a hash algorithm based on IP addresses. Notice that after 11 connections (most from different source addresses to a single destination address), the connection load has been distributed rather equally across all the firewalls in the farm.

The sections of output beginning with FirewallTCP7 and FirewallDG8 show parameters set for the TCP and UDP protocols (DG stands for datagram).

To see a detailed history of each firewall's activity within the firewall farm, enter the following command to get the resulting output:

 Router# show ip slb reals sfarm FW-INBOUND real                  farm name        weight  state          conns ------------------------------------------------------------------- 192.168.100.3         FW-INBOUND       8       OPERATIONAL    4 192.168.100.4         FW-INBOUND       8       OPERATIONAL    6 192.168.100.5         FW-INBOUND       8       OPERATIONAL    5 Router# show ip slb reals sfarm FW-INBOUND detail 192.168.100.3, FW-INBOUND, state = OPERATIONAL, type = firewall   conns = 4, dummy_conns = 0, maxconns = 4294967295   weight = 8, weight(admin) = 8, metric = 0, remainder = 0   total conns established = 99036, hash count = 3   server failures = 0   interface Vlan100, MAC 000b.46b3.4e40 192.168.100.4, FW-INBOUND, state = OPERATIONAL, type = firewall   conns = 6, dummy_conns = 0, maxconns = 4294967295   weight = 8, weight(admin) = 8, metric = 0, remainder = 0   total conns established = 99383, hash count = 10   server failures = 0   interface Vlan100, MAC 000b.5f0c.8ac0 192.168.100.5, FW-INBOUND, state = OPERATIONAL, type = firewall   conns = 5, dummy_conns = 0, maxconns = 4294967295   weight = 8, weight(admin) = 8, metric = 0, remainder = 0   total conns established = 99532, hash count = 3   server failures = 0   interface Vlan100, MAC 0090.2744.5c66

To check on the progress of the firewall probes, you might enter the following command to get the resulting output:

 Router# show ip slb probe Server:Port         Target:Port           State       Outages  Current  Cumulative ---------------------------------------------------------------------------------- 192.168.100.3:0     192.168.100.3:0       OPERATIONAL 0        never    00:00:00 192.168.100.4:0     192.168.100.4:0       OPERATIONAL 0        never    00:00:00 192.168.100.5:0     192.168.100.5:0       OPERATIONAL 0        never    00:00:00 Router# Router# show ip slb probe detail FW-A, ping, address = 192.168.100.3, interval = 10, faildetect = 2   FW-INBOUND, type = firewall     target = 192.168.100.3:0, real = 192.168.100.3:0, virtual = 0.0.0.0:0 ALL       state = OPERATIONAL, status = 33, operation id = 25       outages = 0, failures = 374, successes = 98690, tests = 376       current = never, cumulative = 00:00:00 FW-B, ping, address = 192.168.100.4, interval = 10, faildetect = 2   FW-INBOUND, type = firewall     target = 192.168.100.4:0, real = 192.168.100.4:0, virtual = 0.0.0.0:0 ALL       state = OPERATIONAL, status = 33, operation id = 26       outages = 0, failures = 806, successes = 98604, tests = 808       current = never, cumulative = 00:00:00 FW-C, ping, address = 192.168.100.5, interval = 10, faildetect = 2   FW-INBOUND, type = firewall     target = 192.168.100.5:0, real = 192.168.100.5:0, virtual = 0.0.0.0:0 ALL       state = OPERATIONAL, status = 33, operation id = 27       outages = 0, failures = 995, successes = 98565, tests = 996       current = never, cumulative = 00:00:00 Router#

In the shaded portions, for example, probe FW-A sent to firewall A (192.168.100.3) has succeeded 98,690 times and had 374 failures. The probe has been sent at 10-second intervals, causing the firewall to be declared in failure after two missed probes.

Sometimes, you might need to figure out which firewall in the farm is handling a specific flow or connection. For example, suppose a series of Telnet connections have been opened from a variety of client addresses, all to the same server. You can see the active connections with the output from the show ip slb conn command. Each active connection is listed, along with the "real" server or firewall that is handling that connection:

 Router# show ip slb conn vserver         prot client                real                  state     nat ------------------------------------------------------------------------------- FirewallTCP7    TCP  10.1.17.4:23       192.168.100.3         ESTAB     none FirewallTCP7    TCP  10.1.17.5:23       192.168.100.4         ESTAB     none FirewallTCP7    TCP  10.1.17.9:23       192.168.100.5         ESTAB     none FirewallTCP7    TCP  10.1.17.8:23       192.168.100.4         ESTAB     none FirewallTCP7    TCP  10.1.17.6:23       192.168.100.5         ESTAB     none FirewallTCP7    TCP  10.1.17.7:23       192.168.100.3         ESTAB     none FirewallTCP7    TCP  10.1.17.11:23      192.168.100.4         ESTAB     none FirewallTCP7    TCP  10.1.17.10:23      192.168.100.3         ESTAB     none FirewallTCP7    TCP  10.1.17.229:3580   192.168.100.4         ESTAB     none Router#