Firewall Load Balancing


Firewalls can realize performance benefits from Cisco content switching by using Firewall Load Balancing (FWLB) technologies. Although most firewalls can be scaled inherently by supporting stateful failover to a standby unit, you can increase performance by load balancing requests across multiple active firewalls using the CSS or CSM.

CSS Firewall Load Balancing

To control traffic flowing in both directions across a group of firewalls, you must sandwich the group within two CSSs. The CSSs distribute requests over the firewalls and maintain the connection state flowing through the firewalls. The content switches use the state to intelligently switch packets from existing connections to the same firewall. Figure 11-3 illustrates how you can sandwich your firewalls between two CSSs.

Figure 11-3. CSS Firewall Load Balancing


Note

You can provide CSS redundancy by installing two CSSs on both the inside and outside of the firewall group and configure the highly available features that you learned about in Chapter 10. This way you avoid having two single points of failure with the CSSs that are shown in Figure 11-3.


In Figure 11-3, consider an incoming TCP SYN segment from the Internet:

  1. The CSS A decides which firewall to switch the request to, based on the configured SLB policy (for example, round-robin or hashing the source and destination IP addresses).

  2. CSS A creates a connection entry for the request in its state table.

  3. The selected firewall processes the request, creates a connection entry in its connection table, and forwards the TCP SYN segment to the CSS B.

  4. CSS B simply forwards the packet to the destination: If the destination is a virtual server, the request is load-balanced to the server according to the rules specified for the server farm; otherwise, the packet is routed using the content switch's routing table.

  5. CSS B also creates a connection entry in its connection table.

  6. The server processes the request and sends a TCP SYN-ACK response back to CSS B.

  7. CSS B looks up the connection in its connection table based on the information in the IP and TCP headers in the response, and updates the connection state with the SYN-ACK.

  8. CSS B forwards the packet to the appropriate firewall based on the existing entry in its connection table.

  9. The firewall updates its state with the SYN-ACK packet and forwards it to CSS A.

  10. CSS A routes the request to the Internet per normal routing and updates its connection state.

  11. The client's ACK then completes the TCP full-handshake over the same path as the original SYN segment.

Configuring FWLB differs slightly from configuring standard server load balancing (SLB) because the traffic is not destined to the firewall, but to services behind the firewall. To configure firewalls on the CSS, use the command:

 ip firewall index local_firewall_address remote_firewall_address remote_switch_address 


You must configure the same index values on both CSSs. To add routes to back-end servers that you want to load balance across your firewalls, use the command:

 ip route ip_address subnet_mask firewall index distance 


Example 11-11 gives a sample FWLB configuration based on the topology in Figure 11-3.

Example 11-11. CSS FWLB

 CSS A ip firewall 1 10.1.10.2 10.1.20.2 10.1.20.1 ip route 10.1.30.0/24 firewall 1 ip firewall 2 10.1.10.3 10.1.20.3 10.1.20.1 ip route 10.1.30.0/24 firewall 2 interface e1  bridge vlan 10 interface e2  bridge vlan 10 circuit vlan 10  ip address 10.1.10.1 255.255.255.0 CSS B ip firewall 1 10.1.20.2 10.1.10.2 10.1.10.1 ip route 0.0.0.0/0 firewall 1 ip firewall 2 10.1.20.3 10.1.10.3 10.1.10.1 ip route 0.0.0.0/0 firewall 2 interface e1  bridge vlan 20 interface e2  bridge vlan 20 interface e3  bridge vlan 30 circuit vlan 20  ip address 10.1.20.1 255.255.255.0 circuit vlan 30  ip address 10.1.30.1 255.255.255.0 

Note

Firewalls have drastically improved in performance over the past few years. The content switch must be at least X times more powerful than the firewalls being balanced, where X is the number of firewalls being balanced. Although the CSS supports FWLB, the CSM is preferable for FWLB for new deployments because its performance is better than the CSS in terms of bandwidth and flow-handling capabilities. Also, the CSS does not support reverse sticky for Active-FTP, as you will learn in the next section.


CSM Firewall Load Balancing

As you will quickly learn, with the CSM in router-mode, virtual servers are required for any traffic to pass through it. As a result, the configurations are generally more complicated than those of the CSS, but can be much more flexible. For example, the CSM enables you to configure complex designs, including single-CSM FWLB and stealth-firewall load balancing, which are not possible with the CSS.

Figure 11-4 gives a basic dual-CSM FWLB topology.

Figure 11-4. Dual-CSM FWLB


To achieve the FWLB design in Figure 11-4, you can use the configuration in Example 11-12.

Example 11-12. Dual-CSM FWLB

 ! MSFC shared by both CSMs interface vlan 10  ip address 10.1.10.4 255.255.255.0  no shutdown ! CSM A mod csm 5 vlan 10 client  ip address 10.1.10.1 255.255.255.0  gateway 10.1.10.4 vlan 11 server  ip address 10.1.10.1 255.255.255.0 serverfarm forward  description ** Used to forward outgoing connections from the web servers **  no nat server  no nat client  predictor forward serverfarm out-firewalls  description ** Contains the outside interfaces of the firewalls **  no nat server  no nat client  predictor hash address source 255.255.255.255  real 10.1.10.2   backup real 10.1.10.3   inservice  real 10.1.10.3   backup real 10.1.10.2   inservice vserver in-connections  description ** Distributes incoming connections from clients across firewalls **  virtual 10.1.20.0 255.255.255.0 any  vlan 10  serverfarm out-firewalls  inservice vserver out-connections  description ** Forwards outgoing connections from the web servers according to routing table **  virtual 0.0.0.0 0.0.0.0 any  serverfarm forward  vlan 11  inservice ! CSM B mod csm 6 vlan 20 client  ip address 10.1.20.1 255.255.255.0 vlan 21 server  ip address 10.1.20.1 255.255.255.0 serverfarm in-firewalls  description ** Contains the inside firewall interfaces **  no nat server  no nat client  predictor leastconns  real 10.1.20.2   backup real 10.1.20.3   inservice  real 10.1.20.3   backup real 10.1.20.2   inservice serverfarm web-farm  description ** Contains the two web servers **  nat server  no nat client  real 10.1.20.10   inservice  real 10.1.20.11   inservice vserver out-connections  description ** Distributes outgoing connections initiated from the web servers across the                 available firewalls **  virtual 0.0.0.0 0.0.0.0 any  vlan 20  serverfarm in-firewalls  inservice vserver web-vip  description ** Distributes incoming connections initiated from external clients across web                 servers **  virtual 10.1.20.100 255.255.255.0 www  vlan 21  serverfarm web-farm  inservice 

Note

In Figure 11-4, CSM A and CSM B are installed within the same chassis as the MSFC, in slots five and six, respectively.


When a client initiates a connection from the Internet to the web server virtual IP (VIP) 10.1.20.100 on CSM B, CSM A is the first CSM to receive the packet and performs a virtual server lookup, matching the client's TCP SYN packet to the VIP called in-connections. This VIP distributes incoming connections from clients across the available firewalls in the server farm "out-firewalls" using the least connections predictor, which will produce even more distribution across your firewalls than source IP hashing. Single-connection TCP protocols, such as SMTP and BGP, require only one TCP connection for the application to work. As a result, you do not require hashing or sticking of subsequent application requests that occur over different TCP connections to the originally selected firewall.

The server farm "out-firewalls" contains the outside IP addresses of the firewalls you are load balancing. For example, say that CSM A selects Firewall B for the new connection. Then, CSM A creates a new connection in its connection table and forwards the packet to Firewall B. Firewall B also creates a new connection in its connection table and forwards the packet to CSM B. CSM B creates a new connection in its connection table and performs a virtual server lookup, matching the virtual server called "web-vip." CSM B then performs delayed binding with the client and eventually load balances the request to a real web server (for example, Web01). Web01 responds with a TCP SYN-ACK that traverses the same firewall as the original SYN did due to the existing connection entry in CSM B's connection table.

Note

If your firewalls support stateful failover, you can use the backup real real server configuration command to specify the backup firewall.


When either back-end web server requires the initiation of a connection to the Internet, CSM B first receives the TCP SYN segment (assuming you configure the reals with CSM B as their default gateway), performs a virtual server lookup, and matches its VIP called "out-connections." This VIP distributes connections initiated from web servers across the available firewalls in the server farm "in-firewalls" using destination IP address hashing. As with using source hashing for incoming requests, you should use destination hashing for outgoing requests to distribute the connections across the firewalls more evenly.

Note

The CSM also supports UDP-based protocols for FWLB.


Similar to "out-firewalls" configured on CSM A, the server farm "in-firewalls" on CSM B contains the inside IP addresses of the firewalls you are load balancing. In this case, say that CSM B chooses Firewall A. Then both CSM B and Firewall A create a connection state entry for the new connection in their connection tables and forward the segment upstream. When CSM A receives the TCP SYN, it matches the segment with the VIP called "out-connections" and forwards the packet to the Internet using its internal routing table, as the server farm "forward" stipulates.

Configuring Reverse Stickiness

Recall the sticky features that you learned in Chapter 10. You can configure stickiness when you require load balancing multiple TCP flows of a session to the same server as the original flow, to retain information stored about the flow on the server. The same principle is true with FWLB. For applications that require multiple connections in the same direction within the same application session, such as HTTP and Passive-FTP, you can use IP session stickiness or distribution via address hashing to ensure that multiple TCP sessions stick to the same firewall. That is, you can apply the same "forward" sticky configuration that you learned in Chapter 10 to FWLB.

However, for applications that open connections in both directions within the same session, such as Active-FTP, you must use IP reverse-sticky to ensure that TCP connections in the reverse direction take the same firewall. In the previous example, CSM A chose Firewall B for the client connection, but CSM B chose Firewall A for the server-initiated connection. With applications such as Active-FTP, you will require CSM B to choose Firewall B so that your firewall can reconcile the FTP data and control "buddy" connections for security purposes. Refer to Figure 11-5 to understand how IP reverse-sticky works.

Figure 11-5. IP Reverse-Sticky


Configuring IP reverse-sticky on CSMB enables it to store a sticky entry in its sticky table during the initial connection made by the client. IP reverse-sticky forces CSMB to override its normal load balancing decision-making process for subsequent connection requests made by the real servers to clients located in its sticky database.

To configure IP reverse-sticky on CSMB, you can use the configuration in Example 11-13, as applicable to the previous HTTP configuration on CSM B; however, HTTP virtual servers do not normally require reverse-stickyActive-FTP is the most common application to use reverse-sticky.

Example 11-13. IP Reverse-Sticky

 sticky 77 netmask 255.255.255.255 address destination timeout 100          vserver out-connections  virtual 0.0.0.0 0.0.0.0 any  vlan 20  serverfarm in-firewalls  sticky 100 group 77                                                        inservice vserver web-vip  virtual 10.1.20.100 255.255.255.0 www  vlan 21  serverfarm web-farm  reverse-sticky 77                                                          inservice 

In Figure 11-5 you can see that, when the incoming client connection via Firewall B matches the virtual server "web-vip," CSM B creates a sticky entry with the client's source IP address (10.1.10.99) and the real server (Firewall B) in the sticky database. Subsequent TCP connections from the back-end real servers trigger CSM B to perform a sticky table lookup on the destination IP address of the request. If a real server initiates a connection to 10.1.10.99, CSM B forwards the TCP SYN request through Firewall B, thus overriding the normal outgoing load-balancing method of destination hashing.

Configuring Single-CSM FWLB

In a single-CSM FWLB configuration, as Figure 11-6 suggests, you must connect the inside and outside interfaces of the firewalls directly to the CSM.

Figure 11-6. Single-CSM FWLB


Example 11-14 gives a single-CSM FWLB configuration.

Example 11-14. Configuring FWLB with a Single CSM

 mod csm 4  vlan 10 client   description *** Client's initiate connections from VLAN 10   ip address 10.1.10.1 255.255.255.0  vlan 20 server   description *** VLAN 20 contains the firewalls outside interfaces    ip address 10.1.20.1 255.255.255.0  vlan 30 server   description *** VLAN 30 contains the firewalls inside interfaces   ip address 10.1.30.1 255.255.255.0  vlan 40 server description *** Internal subnet for web servers    ip address 10.1.40.1 255.255.255.0 serverfarm forward   no nat server   no nat client   predictor forward serverfarm in-firewalls  description ** Contains the inside interfaces of the firewalls **   no nat server  no nat client  predictor hash address source 255.255.255.255  real 10.1.20.10   inservice  real 10.1.20.11   inservice serverfarm out-firewalls  description ** Contains the outside interfaces of the firewalls **  no nat server  no nat client  predictor hash address destination 255.255.255.255  real 10.1.30.10   inservice  real 10.1.30.11   inservice serverfarm web-farm  description ** Contains the web servers **  nat server  no nat client  real 10.1.40.10   inservice  real 10.1.40.11   inservice vserver in-connections  description ** Distributes incoming connections across the two firewalls **  virtual 10.1.40.0 255.255.255.0 any  vlan 10  serverfarm out-firewalls  inservice vserver out-conns-20  description ** Routes outgoing connections from the web servers from VLAN 20 to the                 Internet according to the routing table **    virtual 0.0.0.0 0.0.0.0 any    serverfarm forward    vlan 20    inservice vserver out-conns-40  description ** Distributes outgoing connections from the web servers from VLAN 40 across                 the two firewalls **  virtual 0.0.0.0 0.0.0.0 any  vlan 40  serverfarm in-firewalls  inservice vserver web-vip  description ** Distributes incoming connections from the Internet from VLAN 30 across the                 two web servers **  virtual 10.1.40.100 255.255.255.0 www  vlan 30  serverfarm web-farm  inservice 

When the CSM receives a client TCP SYN segment from the client VLAN 10 for the VIP 10.1.40.100, it performs a virtual server lookup and matches it to virtual server "in-connections." The CSM then load balances the request across the two firewalls that are shown in Figure 11-6 and chooses Firewall B. The CSM forwards the request out on VLAN 20, and Firewall B forwards it back on VLAN 30. The CSM receives the request on VLAN 30, performs another virtual server lookup, and matches the virtual server called "web-vip." The CSM load balances the request to the realreturn traffic from the real flows through the same firewall given the existing CSM connection table entry.

Server-originated connections arrive to the CSM from VLAN 40, match the VIP "out-conns-40," and are load balanced to the firewalls. The firewalls forward the outgoing connection requests back to the CSM on VLAN 20. The CSM matches the VIP "out-conns-20" and forwards the request to the client using its routing table.

Note

To configure stealth-mode FWLB, refer to your product documentation on Cisco.com.




Content Networking Fundamentals
Content Networking Fundamentals
ISBN: 1587052407
EAN: 2147483647
Year: N/A
Pages: 178

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