Section 10-2. SLB Firewall Load Balancing


10-2. SLB Firewall Load Balancing

  • Firewall load balancing balances 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.

  • Firewall load balancing requires a load-balancing device (IOS SLB) 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. Figure 10-3 illustrates the basic firewall load-balancing concept.

    Figure 10-3. Firewall Load-Balancing Concept


  • Firewall load balancing is performed by computing a hash value of each new traffic flow (source and destination IP addresses and ports). This is called a route lookup.

  • The firewall load-balancing device then masquerades as the IP address for all firewalls in the firewall farm.

  • Firewall load balancing can detect a firewall failure by monitoring probe activity.

  • The HSRP can be used to provide a "stateless backup" redundancy for multiple firewall load-balancing devices. If one device fails, a redundant device can take over its function.

  • Multiple firewall load-balancing devices can also use "stateful backup" for redundancy. Backup devices keep state information dynamically and can take over immediately if a failure occurs.

Configuration

1.

(CSM only) Define client-side and server-side VLANs.

a. Start configuring a CSM module:

IOS

N/A

CSM

 (global) 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.

b. Define each of the VLAN types:

IOS

N/A

CSM

 (csm) vlan vlan-id {client | server} 


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 in the VLAN database. The VLAN type, client or server, defines where the clients or servers are located as seen by the CSM. You must define both client-side and server-side VLANs before the CSM can be used properly.

TIP

The CSM doesn't have a special configuration mode for firewall farms or firewall load balancing. Instead, the same concept of client-side and server-side load balancing is used. When configuring a CSM for firewall load balancing, 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.

c. (Optional) Assign a primary IP address:

IOS

N/A

CSM

 (csm-vlan) ip address ip-address netmask 


One IP address can be defined per VLAN on the CSM. This address is used for management traffic (probes, for example) and ARP requests.

d. (Optional) Assign an additional secondary IP address:

IOS

N/A

CSM

 (csm-vlan) alias ip-address netmask 


Additional IP addresses allow the CSM to communicate with servers on a different IP network without using a router.

e. (Optional) Select a default gateway:

IOS

N/A

CSM

 (csm-vlan) gateway ip-address 


A next-hop default gateway or router address is given by ip-address. This command can be repeated to define up to 7 gateways per VLAN or 255 gateways per CSM. Gateways are usually used on the client-side VLAN, although they can be used on the server-side if needed.

f. (Optional) Define static routes to reach distant networks:

IOS

N/A

CSM

[View full width]

 (csm-vlan) route ip-address netmask gateway  gw-ip-address 


A static route can be defined when the CSM needs to know how to reach servers that are more than one router hop away. Define the route by the network ip-address and netmask, using gateway address gw-ip-address. The gateway must reside on the same local network as the CSM VLAN.

g. Repeat Steps b to f for each client-side and server-side VLAN.

2.

Define a firewall farm.

a. Assign a name to the firewall farm:

IOS

 (global) ip slb firewallfarm firewallfarm-name 

CSM

 (csm) serverfarm serverfarm-name 


In IOS SLB, the collection of firewalls is referenced by firewallfarm-name (text string up to 15 characters). A CSM, however, views a firewall farm as just another form of a server farm, referenced by serverfarm-name (text string up to 15 characters).

TIP

Recall that firewall load balancing requires two load-balancing devicesone on each side of the firewall farm. For IOS SLB, the firewall farm is configured as a firewallfarm, consisting of real servers or firewalls. Load balancing is then based on the firewall "routes" that are configured into each load-balancing device. SLB has no concept of virtual servers with firewall load balancing.

The CSM, however, views firewall load balancing as an extension of regular load balancing. You should configure the firewall farm as a serverfarm of real servers. Virtual servers are configured to load balance traffic toward the firewall farm. Traffic away from the firewall farm must also be configured for load balancing, with a generic serverfarm having no real servers. Instead, a generic virtual server forwards all traffic through the generic server farm according to the CSM's internal routing tables.

b. Identify one or more firewalls in the farm.

- Specify the firewall's IP address:

IOS

 (firewall-farm) real ip-address 

CSM

 (server-farm) real ip-address 


The firewall is directly connected (same logical subnet) to the load-balancing device with an interface at IP address ip-address.

- (Optional; IOS SLB only) Assign a relative capacity weight:

IOS

 (real-firewall) weight weighting-value 

CSM

N/A


The real firewall is assigned a weighting-value (1 to 255; default 8) that indicates its capacity relative to other real firewalls in the firewall farm. These values are statically defined and are based on what you think the firewall can handle, relative to the others. The weight values are only used for round-robin or least-connections algorithms.

- (Optional; IOS SLB only) Define one or more probes to detect a firewall failure:

IOS

 (real-firewall) probe probe-name 

CSM

N/A


The probe that is defined by probe-name (text string) is used periodically to determine whether the firewall has failed. Even if more than one probe is defined, the firewall is declared down if it fails just one probe. A firewall must pass all probes in order to be recovered again.

TIP

You must also define the probes separately, as described in section "10-3: SLB Probes." Ping probes are the most useful for firewall load balancing. For each firewall in the firewall farm, configure a probe to send ping packets that pass completely through the firewall, destined for the firewall load-balancing device on the other side. This tests both "inside" and "outside" interfaces of the firewall, requiring them to be active and operational so that the ping probe is reflected from the other side. Be sure that the firewall is configured to allow ICMP ping packets to pass through.

- Allow load balancing to begin using the firewall:

IOS

 (real-firewall) inservice 

CSM

 (real-server) inservice 


By default, the real firewall is not used by SLB unless it is placed in service. To remove a firewall from service, use no inservice.

c. (Optional; IOS SLB only) Define one or more flows that will be sent to the firewall farm:

IOS

[View full width]

 (firewall-farm) access [source source-ip-address  network-mask] [destination destination-ip-address  network-mask] 

CSM

N/A


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 source or destination keywords are omitted, they default to 0.0.0.0 with a mask of 0.0.0.0signifying all addresses and networks. This is the default behavior.

With a CSM, traffic is load balanced to a firewall farm by using a virtual server and load-balancing algorithms.

d. (Optional) Choose a firewall load-balancing method:

IOS

 (firewall-farm) predictor hash address [port] 

CSM

[View full width]

 (server-farm) predictor hash address source 255 .255.255.255 

-OR-

[View full width]

 (server-farm) predictor hash address destination  255.255.255.255 


By default IOS SLB uses the source and destination IP addresses of a flow to select a destination firewall. Use the port keyword to use the source and destination addresses, and the source and destination TCP or UDP port numbers, in the selection decision.

On a CSM located "outside" relative to the firewall farm (unsecure side), the algorithm should use only the source addresses. Here, the netmask option is set to 255.255.255.255 so that all address bits are used in the hash algorithm. On a CSM located "inside" relative to the firewall farm (secure side), you should use destination addresses with a 255.255.255.255 address mask. The hash algorithm provides the best load-balancing distribution when it is based on the large population of addresses furthest away from the firewall farm. (This assumes that the size of the network and the number of hosts and IP addresses increase as you move out from the firewall farm.)

e. (CSM only) Disable server NAT:

IOS

N/A

CSM

 (server-farm) no nat server 


By default, server NAT is enabled for a CSM server farm. In the case of firewall load balancing, the firewall farm is considered a server farm. However, NAT is never required when load balancing to firewalls.

f. (Optional; CSM only) Define one or more probes to detect failures within the firewall farm:

IOS

N/A

CSM

 (server-farm) probe probe-name 


The probe that is defined by probe-name (text string) periodically checks each firewall (real server) within the firewall farm. The probe inherits each real server IP address to use as a target address. Even if more than one probe is defined, a firewall is declared down if it fails just one probe. A firewall must pass all probes in order to be recovered again.

TIP

You must also define the probes separately, as described in section "10-3: SLB Probes." Ping probes are the most useful for firewall load balancing.

Unlike IOS SLB firewall load balancing, the CSM only offers probes that can be used on a server farm as a whole. In other words, you cannot define probes with unique target addresses. Ideally, probes should be configured so that a ping packet passes completely through the firewall, destined for the firewall load-balancing device on the other side. This would test both "inside" and "outside" interfaces of the firewall, requiring them to be active and operational so that the ping probe is reflected from the other side.

CSM probes can only inherit the target addresses from each real server defined in a server farm. This is always the nearest firewall interface, so total firewall operation can't be determined from a probe.

g. (Optional) Use stateful backup to recover from a failure:

IOS

[View full width]

 (firewall-farm) replicate casa listening-ip  remote-ip port-number [interval] [password [0|7]  password [timeout]] 

CSM

N/A


The redundant load-balancing devices use 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, default 10).

A password (text string; use 0 if unencrypted, the default, or 7 if encrypted) can be used for MD5 authentication with the backup device. The optional timeout (0 to 65,535 seconds; default 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.

h. (Optional; IOS SLB only) Adjust the TCP or UDP connection parameters.

- Enter the TCP or UDP configuration mode:

IOS

 (firewall-farm) {tcp | udp} 

CSM

N/A


You might need to make adjustments to both TCP and UDP. In this case, this command can be repeated to configure each independently.

- (Optional; TCP only) Hold connections open after they are terminated:

IOS

 (firewall-farm-protocol) delay duration 

CSM

N/A


After a TCP connection is terminated, the connection context can be maintained for duration (1 to 600 seconds, default 10 seconds). This can be useful when packets arrive out of sequence, and the connection is reset before the last data packet arrives.

- (Optional) Hold connections open after no activity:

IOS

 (firewall-farm-protocol) idle duration 

CSM

N/A


When an absence of packets is detected for a connection, the connection is kept open for duration (10 to 65,535 seconds, default 3600 seconds or 1 hour) before an RST is sent.

- (Optional) Specify the maximum number of connections:

IOS

 (firewall-farm-protocol) maxconns number 

CSM

N/A


At any given time, the real server is limited to number (1 to 4,294,967,295; default 4,294,967,295) active connections.

- (Optional) Assign connections from the same IP address to the same firewall:

IOS

[View full width]

 (firewall-farm-protocol) sticky duration [netmask  netmask] 

CSM

N/A


For a given IP address, connections are assigned to the last-used firewall for duration (0 to 65,535 seconds). A netmask can be given such that all source addresses within the mask are assigned to the same firewall.

i. (IOS SLB only) Allow firewall load balancing to begin using the firewall:

IOS

 (firewall-farm) inservice 

CSM

N/A


By default, the firewall is not used by firewall load balancing unless it is placed in service. To remove a firewall from service, use no inservice. A CSM server farm is inherently in service.

3.

(CSM only) Define a virtual server to handle traffic toward the firewall farm.

a. Name the virtual server:

IOS

N/A

CSM

 (csm) vserver virtual-server-name 


The virtual server is given the name virtual-server-name (text string up to 15 characters).

b. Assign the virtual server to a firewall server farm:

IOS

N/A

CSM

 (virtual-server) serverfarm serverfarm-name 


SLB uses the virtual server as the front end for the server farm named serverfarm-name (text string up to 15 characters).

c. Define the virtual server capabilities:

IOS

N/A

CSM

 (virtual-server) virtual ip-address [network-mask] any 


The virtual server appears as IP address ip-address (default 0.0.0.0) with network-mask (default 255.255.255.255; 1-bit matches, 0 is wildcard). In the case of a firewall farm, you can set the ip-address and network-mask to be that of an entire internal network of servers. This allows the virtual server to represent many real machines, while actually load balancing the traffic to the firewalls (real servers). The any keyword allows all protocols to be load balanced.

d. (Optional) Allow traffic only from a source VLAN to use the virtual server:

IOS

N/A

CSM

 (virtual-server) 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 the "outside" network, farthest away from the firewalls. After this has been defined, all other VLANs are restricted from accessing the virtual server.

e. Allow SLB to begin using the virtual server:

IOS

N/A

CSM

 (virtual-server) inservice 


By default the virtual server is not used by SLB unless it is placed in service. To remove a virtual server from service, use no inservice.

f. (Optional) Use SLB stateful backup:

IOS

N/A

CSM

 (virtual-server) replicate csrp {sticky | connection} 


CSM replicates its connection information using the CSRP. The sticky connection database or the regular connection database can be replicated. To replicate both, choose each one in a separate replicate csrp command.

4.

(CSM only) Define a generic server farm for traffic away from the firewall farm.

a. Assign a name to the generic server farm:

IOS

N/A

CSM

 (csm) serverfarm serverfarm-name 


The CSM sees the network away from the firewall farm as a server farm. On the CSM "outside" of the firewall farm, this is usually toward the Internet or public network. On the CSM "inside" the firewall farm, this might be other internal networks or actual server farms.

TIP

Traffic away from the firewall farm must also be configured for load balancing, with a generic serverfarm having no real servers. Instead, a generic virtual server forwards all traffic through the generic server farm according to the CSM's internal routing tables.

b. (Optional) Choose a load-balancing method:

IOS

N/A

CSM

 (server-farm) predictor forward 


On a CSM located "outside" relative to the firewall farm (unsecure side), the algorithm should use only the forward mode. This mode forwards traffic destined away from the firewall farm according to the CSM's internal routing table.

On a CSM located "inside" relative to the firewall farm (secure side), traffic is usually destined toward an internal network or actual server farm. In this case, normal server farm load balancing can be used.

c. Disable server NAT:

IOS

N/A

CSM

 (server-farm) no nat server 


By default server NAT is enabled for a CSM server farm. In the case of firewall load balancing, the firewall farm is considered a server farm. However, NAT is never required when load balancing to firewalls.

5.

(CSM only) Define a generic virtual server to handle traffic away from the firewall farm.

a. Name the virtual server:

IOS

N/A

CSM

 (csm) vserver virtual-server-name 


The virtual server is given the name virtual-server-name (text string up to 15 characters).

b. Assign the virtual server to a firewall server farm:

IOS

N/A

CSM

 (virtual-server) serverfarm serverfarm-name 


SLB uses the virtual server as the front end for the generic server farm named serverfarm-name (text string up to 15 characters).

c. Define the virtual server capabilities:

IOS

N/A

CSM

[View full width]

 (virtual-server) virtual ip-address [network-mask]   any 


The virtual server appears as IP address ip-address (default 0.0.0.0) with network-mask (default 255.255.255.255; 1-bit matches, 0 is wildcard). To represent the outer public network (the Internet, for example), use virtual 0.0.0.0 0.0.0.0 any.

d. (Optional) Allow traffic only from a source VLAN to use the virtual server:

IOS

N/A

CSM

 (virtual-server) 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 to the firewall farm. After this has been defined, all other VLANs are restricted from accessing the virtual server.

e. Allow SLB to begin using the virtual server:

IOS

N/A

CSM

 (virtual-server) inservice 


By default the virtual server is not used by SLB unless it is placed in service. To remove a virtual server from service, use no inservice.

Firewall Load-Balancing Example

To perform firewall load balancing, two load-balancing devices are neededone located externally and one located internally with respect to the firewall farm. Figure 10-4 shows a network diagram for this example.

Figure 10-4. Network Diagram for the Firewall Load-Balancing Example


The firewall farm consists of two real firewalls. Their "outside" (unprotected) interfaces are at 192.168.1.2 and 192.168.1.3. Their "inside" (protected) interfaces are at 192.168.100.2 and 192.168.100.3. On the outside, the default gateway is 10.5.1.1, and the external SLB device is at 10.5.1.2.

The internal SLB device performs firewall load balancing for outbound traffic to the firewall farm. As well, it provides normal server load balancing for an internal server farm. The real servers are 10.70.1.10 and 10.70.1.20, and the virtual server appears as 10.5.1.80.

Ping probes are used by both external and internal SLB devices to test for firewall operation. An HTTP probe tests each of the real servers in the server farm. These use the default GET method and are sent every 240 seconds.

The configuration for the external load-balancing device is shown first:

IOS

 (global) ip slb firewallfarm Outside (firewall-farm) real 192.168.1.2 (real-firewall) weight 8 (real-firewall) probe Ping1 (real-firewall) inservice (real-firewall) exit (firewall-farm) real 192.168.1.3 (real-firewall) weight 8 (real-firewall) probe Ping2 (real-firewall) inservice (real-firewall) exit (firewall-farm) inservice (firewall-farm) exit (global) ip slb probe Ping1 ping (probe) address 192.168.100.1 (probe) interval 10 (probe) faildetect 4 (global) ip slb probe Ping2 ping (probe) address 192.168.100.1 (probe) interval 10 (probe) faildetect 4 (probe) exit 

CSM

[View full width]

 (global) module csm 3 (csm) vlan 10 client (csm-vlan) ip address 10.5.1.2 255.255.255.0 (csm-vlan) gateway 10.5.1.1 (csm-vlan) exit (csm) vlan 100 server (csm-vlan) ip address 192.168.1.1 255.255.255.0 (csm-vlan) exit (csm) serverfarm Outside (server-farm) real 192.168.1.2 (real-server) inservice (real-server) exit (server-farm) real 192.168.1.3 (real-server) inservice (real-server) exit (server-farm) predictor hash address source 255 .255.255.255 (server-farm) no nat server (server-farm) probe Ping1 (server-farm) exit (csm) vserver Voutside (virtual-server) serverfarm Outside (virtual-server) virtual 10.5.1.0 255.255.255.0 any (virtual-server) vlan 10 (virtual-server) inservice (virtual-server) exit (csm) serverfarm Internet (server-farm) predictor forward (server-farm) no nat server (server-farm) exit (csm) vserver Vinternet (virtual-server) serverfarm Internet (virtual-server) virtual 0.0.0.0 0.0.0.0 any (virtual-server) vlan 100 (virtual-server) inservice (virtual-server) exit (csm) probe Ping1 ping (probe) address 192.168.1.1 (probe) retries 4 (probe) exit 


Now the configuration for the internal load-balancing device is shown:

IOS

 (global) ip slb firewallfarm Inside (firewall-farm) real 192.168.100.2 (real-firewall) weight 8 (real-firewall) probe Ping1 (real-firewall) inservice (real-firewall) exit (firewall-farm) real 192.168.100.3 (real-firewall) weight 8 (real-firewall) probe Ping2 (real-firewall) inservice (real-firewall) exit (firewall-farm) inservice (firewall-farm) exit (global) ip slb serverfarm Servers (server-farm) nat server (server-farm) probe HTTP1 (server-farm) real 10.70.1.10 (real-server) inservice (real-server) exit (server-farm) real 10.70.1.20 (real-server) inservice (real-server) exit (global) ip slb vserver Vservers (virtual-server) serverfarm Servers (virtual-server) virtual 10.5.1.80 tcp 0 (virtual-server) inservice (virtual-server) exit (global) ip slb probe Ping1 ping (probe) address 192.168.1.1 (probe) interval 10 (probe) faildetect 4 (probe) exit (global) ip slb probe Ping2 ping (probe) address 192.168.1.1 (probe) interval 10 (probe) faildetect 4 (probe) exit (global) ip slb probe HTTP1 http (probe) port 80 (probe) interval 240 (probe) request 

CSM

[View full width]

 (global) module csm 3 (csm) vlan 102 client (csm-vlan) ip address 10.70.1.1 255.255.255.0 (csm-vlan) exit (csm) vlan 101 server (csm-vlan) ip address 192.168.100.1 255.255.255.0 (csm-vlan) exit (csm) serverfarm Inside (server-farm) real 192.168.100.2 (real-server) inservice (real-server) exit (server-farm) real 192.168.100.3 (real-server) inservice (real-server) exit (server-farm) predictor hash address destination  255.255.255.255 (server-farm) no nat server (server-farm) probe Ping1 (server-farm) exit (csm) vserver Vinside (virtual-server) serverfarm Inside (virtual-server) virtual 0.0.0.0 0.0.0.0 any (virtual-server) vlan 102 (virtual-server) inservice (virtual-server) exit (csm) serverfarm Servers (server-farm) real 10.70.1.10 (real-server) inservice (real-server) exit (server-farm) real 10.70.1.20 (real-server) inservice (real-server) exit (server-farm) probe HTTP1 (server-farm) exit (csm) vserver Vservers (virtual-server) serverfarm Servers (virtual-server) virtual 10.5.1.80 tcp 0 (virtual-server) vlan 101 (virtual-server) inservice (virtual-server) exit (csm) probe Ping1 ping (probe) address 192.168.1.1 (probe) retries 4 (probe) exit (csm) probe HTTP1 http (probe) interval 240 (probe) request 


Displaying Information About Firewall Load Balancing

Table 10-2 lists some switch commands that you can use to display helpful information about SLB firewall load-balancing configuration and status.

Table 10-2. Commands to Display SLB Firewall Load-Balancing Configuration and Status Information

Display Function

Switch OS

Command

Status of firewalls in a farm

IOS

 (exec) show ip slb reals 

CSM

 (exec) show module csm slot real [sfarm sfarm-name] 

Firewall weight and connection counters

IOS

 (exec) show ip slb reals detail 

CSM

[View full width]

 (exec) show module csm slot real [sfarm  sfarm-name] detail 

Firewall farm status

IOS

 (exec) show ip slb firewallfarm 

CSM

[View full width]

 (exec) show module csm slot serverfarms [name  serverfarm-name] [detail] 

-OR-

 (exec) show module csm slot vserver [detail] 

Load-balancing connections to firewalls

IOS

[View full width]

 (exec) show ip slb conns [firewall  firewallfarm-name] [detail] 

CSM

[View full width]

 (exec) show module csm slot conns [vserver  virtserver-name] [client ip-address] [detail] 

Probes

IOS

 (exec) show ip slb probe [name probe_name] [detail] 

CSM

[View full width]

 (exec) show module csm slot probe [http | icmp |  telnet | tcp | ftp | smtp | dns] [name probe_name]  [detail] 

Sticky connections

IOS

 (exec) show ip slb sticky 

CSM

[View full width]

 (exec) show module csm slot sticky [groups |  client ip_address] 




Cisco Field Manual. Catalyst Switch Configuration
Cisco Field Manual. Catalyst Switch Configuration
ISBN: 1587050439
EAN: N/A
Year: 2001
Pages: 150

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net