Cisco Press
This chapter introduces the reader to firewall load-balancing (FWLB) concepts, technology, and designs. We will talk about motivations behind FWLB solutions, different types of firewalls, and how to load balance them. Reference design options and configurations will be discussed.
At the end of the chapter, we discuss a case study that implements FWLB in a network with multiple secure segments using Cisco’s module-based load balancer for the Catalyst 6500 (Cat6500), the Content Switching Module (CSM). Details of the CSM and Catalyst 6500 configurations are included together with an explanation of various key commands.
Reasons for and Benefits of FWLB
In today’s data centers, the security of the network, servers and application is a key concern. Together with VPN concentrators, Secure Socket Layer (SSL) offload devices, and intrusion detection devices, firewalls are a vital component of secure data center infrastructures. Firewalls are used not just to protect against malicious or unauthorized access from the public segment but also across multiple demilitarized zones (DMZ) and server segments. When a firewall accepts a packet from one segment, it sends the packet through to the other segment. A firewall can modify a packet before passing it through or can send it through unaltered. When a firewall rejects a packet, it usually drops the packet and logs the dropped packet as an event. After a session is established and a flow of packets begins, a firewall can monitor each packet in the flow or allow the flow to continue unmonitored, depending on the policies configured on that firewall.
There are several motivations behind load-balancing firewalls, the key ones being scalability, redundancy, and manageability.
Scalability
Firewalls are physical devices that exist between network segments, typically in a routed design. They perform stateful inspection of sessions going through them from one segment to the other. Firewalls block or permit sessions based on configured security policies and rules. A firewall has limited resources in terms of link speed, memory, and processor power. These factors determine the capacity and capability of the device in terms of session scalability and raw packet-switching performance.
FWLB is necessary when multiple parallel firewalls are deployed to overcome performance limitations in terms of throughput, session rate, and session capacity. FWLB allows you to scale firewall protection by distributing traffic across multiple firewalls on a per-connection basis. In a load-balanced solution, all packets between a pair of IP addresses for a particular session, in either direction, traverse the same firewall. The firewall then allows or denies transmission of individual packets across its interfaces.
Redundancy
One of the primary reasons for FWLB is high availability of the secure path provided by the firewall. Typical firewalls, like Cisco Private Internet Exchange (PIX) firewall, do provide redundancy capability in active/backup fashion. In these scenarios, one firewall is functional and active while the other is in silent mode. Both the firewalls share an interface IP address, thus enabling continuance of traffic flow in case of a device failure.
FWLB takes the firewall redundancy to the next level by load balancing traffic to a group of active and functional firewalls. A firewall failure is detected within seconds by the load balancer, which takes that specific firewall out of rotation. As long as a single firewall within the load-balanced group is functional, the secure path stays connected.
Manageability
Firewall rule and policy changes have always been a difficult task that requires careful planning and change window allocation. This is because a firewall provides security between the public and secure segment, and an improper change can completely block user access or create a bypass of security. The same difficulty also applies to a firewall software upgrade.
FWLB solves this problem and enables easy management of the devices. Since the firewalls are being load balanced in a group, an individual firewall can be taken out of rotation for management purposes. This ensures that the user traffic is not interrupted by firewall changes.
Firewalls can be taken out of rotation by removing them from the firewall farm configured on the CSM or by blocking the probe sent by the CSM. By blocking or dropping the probe packets, the firewall is taken out of rotation dynamically by the CSM.
Types of Firewalls
As we discussed before, firewalls are physical devices that enforce security policies between network segments. There are several types of firewalls, namely:
Packet-based firewalls
Application-based firewalls
Application gateway or proxy firewalls
Layer 2 or stealth firewalls
Packet-Based Firewalls
Packet-based firewalls are first-generation devices that enforce policies on per-packet bases. They do not have any concept of session and have no application layer understanding. A simple form of packet-based firewall is an access control list (ACL) on a router. The ACL blocks or permits IP packets based on source or destination IP addresses or both. There are more complex ACLs available now on routers that can provide stateful inspection.
Load balancing of packet-based firewalls is simple because session state is not maintained on a firewall, so potentially the same TCP connection can be load balanced on a per-packet basis across multiple firewalls. In other words, asymmetric flows are allowed in this environment.
Application-Based Firewalls
Application-based firewalls that are commonly available now can provide stateful inspection of sessions along with network address translation (NAT) functionality. The PIX and Firewall Services Module (FWSM) on the Catalyst 650000 are application-based firewalls. Similar to hardware-based load balancers, application-based firewalls install permitted session information in hardware memory. These firewalls do not allow any packets through them other than those that belong to the inspected and installed sessions in the firewall.
Load balancing of application-based firewalls is complex, as it requires a particular user session to be sent through the same firewall. In other words, if a client TCP SYN is sent through firewall A to reach the server, the TCP SYN ACK from the server to the client should go through firewall A also. Path symmetry needs to be maintained, and this is typically done by using a source or destination address. A hash of the source and destination address is calculated to maintain the symmetry for the client TCP SYN and server TCP SYN ACK response. We will discuss this further in the case study.
Application Gateway or Proxy Firewalls
Application gateway–based firewalls provide stateful inspection of sessions. They are not only session aware, but are also familiar with the application protocols that create sessions; for example, HTTP, SMTP, and FTP. The application-level gateway does more than just filter packets and sessions. It acts as a gateway between the protected network and the Internet. As a gateway, it does not allow any packets to travel directly between the Internet and the protected network.
Application gateway firewalls proxy all user requests and fetch the data by initiating a new connection to the end server. The end server sees the request coming from the firewall’s IP address. The firewall splices the client-side and server-side TCP connection such that the client gets the data from the end server without the Internet-based end server having knowledge of the client’s IP address. This functionality looks similar to NAT but is really above and beyond because the firewall is not just hiding the internal client’s IP address; it is also implementing application-based security policies.
Application gateway firewalls can be implemented transparently, but most are implemented in a proxy fashion. This is why they are also referred to as proxy firewalls.
Load-balancing proxy firewalls require the load balancing of sessions from the internal network to the Internet only. From the Internet to the internal network, packets always make it to the correct firewall, as the destination IP is the firewall’s physical IP. Thus, dynamic symmetry of sessions is ensured.
Layer 2 or Stealth Firewalls
Layer 2 or stealth firewalls are also known as “bump on the wire” firewalls. These firewalls do not have any IP addresses, and they simply bridge traffic between two segments or VLANs. Both segments or VLANs share the same IP subnet and broadcast domain. In other words, these are undetectable Layer 2 devices that can perform Layer 2 forwarding together with packet and session inspection.
Load balancing stealth firewalls is fairly complex but is supported by the Cisco CSM module. For load-balancing stealth firewalls, the firewalls are connected to unique VLANs on either side—that is, the public or private side. The public-side VLANs connect to a particular CSM pair, and the private or internal VLANs connect to another CSM pair. The firewall bridges traffic between the private and public VLANs. That means, even though they are different VLANs, they are the same broadcast domains. CSMs are configured with alias IP addresses on all VLANs, and they balance traffic across the firewalls by forwarding packets to the remote CSM’s alias IP addresses. In other words, the firewall server farm consists of the alias IP addresses on the remote CSM pairs. A stealth firewall is configured so that all traffic moving in both directions across that VLAN moves through the firewall.
Case Study: Firewall Load Balancing
Now that you understand the different types of firewalls and the motivations behind FWLB, you can learn how to deploy a fairly complex FWLB solution over multiple secure segments. When deploying FWLB, it’s critical to learn about the applications flows that would be load balanced to the firewall, whether they are outbound to the Internet or inbound to the DMZ. Applications that require multiple connections, also called buddy connections, such as FTP, need to be considered and accounted for in the design. For these applications, you need to ensure that both the connections belonging to the same user session go through the same firewall.
In this case study, we will examine a specific customer deployment where CSM is used to load balance firewalls with three secure segments, namely an INET, a DMZ, and a LAN segment. The idea behind the following case study is to understand not only the concepts but the implementation details. To fully understand the sample deployment, we will look at:
Server and application requirements
Security requirements
Infrastructure requirements
Design options
Test and verification
Server and Application Requirements
Server and application requirements for this case study are defined as follows:
The servers should be directly managed in the DMZ from management stations in the LAN segment.
Servers should also be able to initiate sessions for application software patches and driver upgrades.
The number of servers in the DMZ is about 300.
The primary application that is being load balanced in the DMZ is HTTP and HTTPS based.
Persistence is needed for the HTTPS-based application.
TCP-based probes are OK.
Direct access to the DMZ servers from the LAN is made using long-lived flows a minimum of three hours of idle timeout.
FTP is used between LAN and DMZ segment servers.
Security Requirements
The security requirements for this case study are as follows:
The main requirement is to load balance flows to the firewalls from all the three segments.
It is critical that each network path through the firewall be verified before sending connections over it; that is, a LAN’s user traffic should only be sent toward the DMZ over a firewall that has its DMZ segment interface functional.
FTP and other applications with multiconnections should be sent across the same firewall.
High availability is critical.
Firewalls do not share state tables; that is, each firewall is unaware of the session states of the other firewalls.
Infrastructure Requirements
Layer 2 and Layer 3 infrastructure requirements for this case study are as follows:
Minimal disruption to the Interior Gateway Protocol (IGP) domain
Seamless integration of the CSM in the current Layer 2 and Layer 3 infrastructure
Robust failover necessary in case of firewall failure
In the data center design, to meet the previously mentioned requirements, the CSMs are configured in a combination of bridge and router modes.
FWLB Design Considerations
Following are some of the key aspects of the design that you need to consider for a successful deployment:
Use appropriate ICMP probes to track all links of the firewalls. One can easily drop traffic if all paths are not watched.
Configure the port-channel between the Catalysts for the server and client VLANs. This port-channel should exclude the CSM fault-tolerant (FT) VLAN.
Configure another port-channel with at least two Fast Ethernet interfaces for the CSM FT VLAN.
The Multilayer Switching Feature Card (MSFC) should only have Layer 3 presence on either the client- or server-side VLAN of the CSM. As discussed in Chapter 3, this restriction can be removed by using policy-based routing (PBR) on the MSFC.
MSFC should route relevant traffic to the alias IP of the CSMs.
CSMs should route relevant traffic to the HSRP group IP of the MSFC.
Distribute the firewalls and the servers across both the Catalyst 6500s. Must not have single point of failure. Measures, such as port-channeling, are required to avoid split brains, which occurs when both devices in an active/standby pair become active.
In FWLB, virtual IPs (VIPs) within the virtual server configuration act as the routes. Make sure proper subnetting and so on are used. It is very easy to create routing loops.
The VLAN X option in the virtual server configuration is highly significant. This is to ensure that connections from appropriate VLANs hit the VIP address. In other words, this provides you with more control in enhancing security and in preventing routing loops.
FWLB Probes
In order to ensure that the path through a firewall is available, ICMP probes are used. ICMP probes are configured with the address command within the probe to define which address needs to be pinged. The address keyword enables the CSM to send the probe to the defined address and not to the real IP (the firewall’s IP). CSM uses the real server’s MAC address to send the probe across each firewall. In the following example, the address is the alias IP address of the CSMs in the DMZ segment. The CSM makes sure it sends the ICMP echo across all the links of the firewalls. The receiving CSM sends back the response on the link on which the request was received. This way, all the paths are monitored by the CSM.
Within the probe configurations, interval, failed, and retries values can be adjusted to achieve the desired effect. For example, a probe with an interval value of 5, a retries value of 3, and a failed value of 30 sends a probe every 3 seconds, and a failure of 3 consecutive probes results in the server being marked as failed or down. So it takes 15 seconds to mark a server down. The probes are sent again after a delay of 30 seconds to see if the server is back in service or not.
Cat6500_01(config-module-csm)#probe DMZ icmp Cat6500_01(config-slb-probe-icmp)#? SLB ICMP probe config address probe destination IP address default Set a command to its defaults exit exit probe submode failed time in seconds between probes of failed server interval time in seconds between probes no Negate a command or set its defaults receive maximum time in seconds to wait for a reply from real server retries number of consecutive errors before marking real server failure Cat6500_01(config-slb-probe-icmp)# ! probe DMZ icmp address 11.8.200.65 interval 5 ! serverfarm OUT_DMZ no nat server no nat client real 11.8.200.43 inservice real 11.8.200.44 inservice real 11.8.200.45 inservice probe DMZ !
Traffic to the Firewalls
To load balance traffic across the firewalls, create a server farm with the IP addresses of the firewalls. Firewalls must be Layer 2-adjacent to the CSM. MSFC must not have a Layer 3 interface on the firewall VLAN. To route traffic across the firewalls, the user needs to create a virtual server with a VIP that defines the route through the firewall. Traffic destined to the specified VIP would be load balanced across the firewall group. Notice that in the following configuration example, a VLAN tag 10 is configured on the virtual server DMZ. This configuration command ensures that only traffic from VLAN 10 (client VLAN) should be considered by the virtual server. This is used for security purposes and also to prevent routing loops.
! serverfarm OUT_DMZ no nat server no nat client real 11.8.200.43 inservice real 11.8.200.44 inservice real 11.8.200.45 inservice probe DMZ ! vserver DMZ virtual 173.73.248.0 255.255.248.0 any vlan 10 serverfarm OUT_DMZ replicate csrp sticky replicate csrp connection persistent rebalance inservice !
The replicate csrp sticky command is not needed in the above configuration, as there is no sticky group configured. This command is used to synchronize sticky data tables between active and standby CSMs.
Traffic from the Firewalls
CSM is not a router. It would not know what to do with any IP packet unless configured using virtual servers or static routes and gateways. We need the following configuration to make the CSM handle the traffic originated from the firewall VLAN (12) appropriately. This is a catch-all virtual server that says the following: predictor-forward any packet that comes in from VLAN 12 for which I do not have a flow. Predictor-forward means route as defined; in this case, it’s the default gateway. The any key word in the virtual configuration refers to any IP protocol.
! serverfarm OUT_FW_CSM no nat server no nat client predictor forward ! vserver OUT_FW_CSM virtual 0.0.0.0 0.0.0.0 any vlan 12 serverfarm OUT_FW_CSM replicate csrp sticky replicate csrp connection persistent rebalance inservice !
Router or Secure Mode
Router mode (also known as Secure mode) is configured on the CSM by having two different subnets on the client and server VLANs respectively. Direct access to the servers from the client VLAN is not allowed in Router mode. An example can be seen on CSM1 and CSM2. Router mode is used in the Internet segment for security enhancement. Similarly, Bridge mode would have worked as well.
module ContentSwitchingModule 2 vlan 10 client ip address 11.8.200.226 255.255.255.224 gateway 11.8.200.230 alias 11.8.200.225 255.255.255.224 ! vlan 12 server ip address 11.8.200.34 255.255.255.224 alias 11.8.200.33 255.255.255.224 !
The configuration shows that alias IP 11.8.200.33 is used by the PIXs as their upstream default gateway.
Bridge Mode
Bridge mode is configured on the CSM by having the same subnet and IP address on both the client and server VLANs. Examples can be seen on both the DMZ CSM and the LAN CSM. Bridge mode enables broadcast traffic to seamlessly pass through the CSM and also allows direct access of the servers from the front end.
module ContentSwitchingModule 2 vlan 14 client ip address 11.8.200.66 255.255.255.224 alias 11.8.200.65 255.255.255.224 ! vlan 114 server ip address 11.8.200.66 255.255.255.224 route 173.73.248.0 255.255.248.0 gateway 11.8.200.80 !
FWLB Algorithms
Any load-balancing method available on the CSM can be used for FWLB. Typically, the default balancing method, round robin, is used. Since support of multiconnection protocols, such as FTP, is required in this design, we will be using predictor IP hash in our configuration. For multiconnection protocols where some connections are open by clients and others by servers and you need to make sure all the connections belonging to the same session go through the same firewall, you will have to use source IP hash for incoming connection and destination IP hash for outgoing, or vice versa.
Cat6500_01(config-module-csm)#serverfarm OUT_DMZ Cat6500_01(config-slb-sfarm)#pre Cat6500_01(config-slb-sfarm)#predictor ? forward forwarding based on destination lookup hash hashing algorithms ip-hash Source IP address hash algorithm (Please use hash address source) leastconns least connections algorithm roundrobin roundrobin algorithm (default) Cat6500_01(config-slb-sfarm)#predictor ha Cat6500_01(config-slb-sfarm)#predictor hash ? address IP source/dest address hash algorithm url URL hash algorithm Cat6500_01(config-slb-sfarm)#predictor hash add Cat6500_01(config-slb-sfarm)#predictor hash address ? /nn or A.B.C.D IP address hash network mask destination Destination IP address hash algorithm source Source IP address hash algorithmCat6500_01(config-slb-sfarm)#predictor hash address
Configuration Details of the INET Segment
Following are detailed CSM and Catalyst 6509 configurations of the INET segment.
CSM Configurations
Following is the complete CSM configuration, which is used in the INET segment. This configuration shows the VLAN configuration, probes, server farms, and virtual servers.
module ContentSwitchingModule 2 vlan 10 client ip address 11.8.200.226 255.255.255.224 gateway 11.8.200.230 alias 11.8.200.225 255.255.255.224 ! vlan 12 server ip address 11.8.200.34 255.255.255.224 alias 11.8.200.33 255.255.255.224 ! probe DMZ icmp address 11.8.200.65 interval 5 ! probe LAN icmp address 11.8.200.97 interval 5 ! serverfarm OUT_DMZ no nat server no nat client predictor hash address source real 11.8.200.43 inservice real 11.8.200.44 inservice real 11.8.200.45 inservice probe DMZ ! serverfarm OUT_LAN no nat server no nat client predictor hash address source real 11.8.200.43 inservice real 11.8.200.44 inservice real 11.8.200.45 inservice probe LAN ! serverfarm OUT_FW_CSM no nat server no nat client predictor forward ! vserver DMZ virtual 173.73.248.0 255.255.248.0 any vlan 10 serverfarm OUT_DMZ replicate csrp sticky replicate csrp connection persistent rebalance inservice ! vserver DMZ_V2 virtual 11.8.200.64 255.255.255.224 any vlan 10 serverfarm OUT_DMZ replicate csrp sticky replicate csrp connection persistent rebalance inservice ! vserver LAN virtual 11.0.0.0 255.0.0.0 any vlan 10 serverfarm OUT_LAN replicate csrp sticky replicate csrp connection persistent rebalance inservice ! vserver OUT_FW_CSM virtual 0.0.0.0 0.0.0.0 any vlan 12 serverfarm OUT_FW_CSM replicate csrp sticky replicate csrp connection persistent rebalance inservice !
Catalyst 6509 Layer 3 Configurations
Following are the Layer 3 configurations on the Catalyst 6509. The interface VLAN 10 is the one that links the CSM with the MSFC. VLAN 11 connects the MSFC with the edge router.
! interface Vlan10 ip address 11.8.200.231 255.255.255.224 no ip redirects standby 1 ip 11.8.200.230 standby 1 priority 105 standby 1 preempt standby 1 track Vlan11 ! interface Vlan11 ip address 173.73.245.6 255.255.255.0 no ip redirects standby 2 ip 173.73.245.10 standby 2 priority 105 standby 2 preempt standby 2 track GigabitEthernet1/1 standby 2 track Vlan10 ! ip default-gateway 173.73.245.1 ! ip classless ip route 0.0.0.0 0.0.0.0 173.73.245.1 ip route 11.0.0.0 255.0.0.0 11.8.200.225 ip route 173.73.0.0 255.255.0.0 11.8.200.225
Configuration Details of the DMZ Segment
Following are detailed CSM and Catalyst 6500 configurations of the DMZ segment.
CSM Configurations
Following is the CSM configuration used in the DMZ segment. Notice in this segment that the CSM performs dual tasks. It load balances server-originated traffic to the LAN and INET segment across the firewalls and also load balances inbound HTTP and HTTPS requests across the application server farm.
module ContentSwitchingModule 2 vlan 14 client ip address 11.8.200.66 255.255.255.224 alias 11.8.200.65 255.255.255.224 ! vlan 114 server ip address 11.8.200.66 255.255.255.224 route 173.73.248.0 255.255.248.0 gateway 11.8.200.80 ! probe INTERNET icmp address 11.8.200.33 interval 5 ! probe LAN icmp address 11.8.200.97 interval 5 ! probe WEB tcp interval 10 ! ! serverfarm DMZ_INTERNET no nat server no nat client predictor hash address destination real 11.8.200.75 inservice real 11.8.200.76 inservice real 11.8.200.77 inservice probe INTERNET ! serverfarm DMZ_LAN no nat server no nat client predictor hash address destination real 11.8.200.75 inservice real 11.8.200.76 inservice real 11.8.200.77 inservice probe LAN ! serverfarm WEB nat server no nat client real 173.73.248.121 inservice real 173.73.248.122 inservice real 173.73.248.123 inservice probe WEB ! serverfarm OUT_FW_CSM no nat server no nat client predictor forward ! ! vserver DMZ_INTERNET virtual 0.0.0.0 0.0.0.0 any vlan 114 serverfarm DMZ_INTERNET replicate csrp sticky replicate csrp connection persistent rebalance inservice ! vserver DMZ_LAN virtual 11.0.0.0 255.0.0.0 any vlan 114 serverfarm DMZ_LAN replicate csrp sticky replicate csrp connection persistent rebalance inservice ! vserver WEB-80 virtual 173.73.248.120 tcp www serverfarm WEB replicate csrp sticky replicate csrp connection persistent rebalance inservice ! vserver WEB-443 virtual 173.73.248.120 tcp https serverfarm WEB sticky 240 replicate csrp sticky replicate csrp connection persistent rebalance inservice ! vserver OUT_FW_CSM virtual 173.73.248.0 255.255.248.0 any vlan 14 serverfarm OUT_FW_CSM replicate csrp sticky replicate csrp connection persistent rebalance inservice !
Catalyst 6509 Layer 3 Configurations
Following are the Layer 3 configurations on the Catalyst 6509. Interface VLAN 114 is the one that links the CSM with the MSFC. VLAN 248 is the server VLAN that exists on the MSFC. Since the default gateway of the MSFC is the CSM, all traffic from the servers going toward the INET or LAN segment passes through the CSM.
interface Vlan114 ip address 11.8.200.81 255.255.255.224 no ip redirects standby 3 ip 11.8.200.80 standby 3 priority 105 standby 3 preempt ! interface Vlan248 ip address 173.73.248.2 255.255.255.0 no ip redirects standby 1 ip 173.73.248.1 standby 1 priority 105 standby 1 preempt ! interface Vlan249 ip address 173.73.249.2 255.255.255.0 no ip redirects standby 2 ip 173.73.249.1 standby 2 priority 105 standby 2 preempt ! ip default-gateway 11.8.200.65 ip classless ip route 0.0.0.0 0.0.0.0 11.8.200.65
Configuration Details of the LAN Segment
The following sections provide the detailed CSM and Catalyst 6500 configurations of the LAN segment. This is the segment that connects the data center with the corporate network.
CSM Configurations
Following is the CSM configuration used in the LAN segment. Notice that in the following configuration the idle timeout is increased to 3 hours. This ensures that the user sessions from the LAN to the DMZ are not removed by the CSM even when the user is idle for up to 10,800 seconds. The default idle timeout in the CSM is 1 hour. Similar idle timeout adjustments would need to be made in the DMZ CSM configuration.
module ContentSwitchingModule 2 vlan 15 client ip address 11.8.200.98 255.255.255.224 alias 11.8.200.97 255.255.255.224 ! vlan 115 server ip address 11.8.200.98 255.255.255.224 route 11.0.0.0 255.0.0.0 gateway 11.8.200.102 ! probe INTERNET icmp address 11.8.200.33 interval 5 ! probe DMZ icmp address 11.8.200.65 interval 5 ! serverfarm LAN_DMZ no nat server no nat client predictor hash address source real 11.8.200.107 inservice real 11.8.200.108 inservice real 11.8.200.109 inservice probe DMZ ! serverfarm LAN_INTERNET no nat server no nat client predictor hash address destination real 11.8.200.107 inservice real 11.8.200.108 inservice real 11.8.200.109 inservice probe INTERNET ! serverfarm OUT_FW_CSM no nat server no nat client predictor forward ! vserver LAN_DMZ_V1 virtual 173.73.248.0 255.255.248.0 any vlan 115 idle 10800 serverfarm LAN_DMZ replicate csrp sticky replicate csrp connection persistent rebalance inservice ! vserver LAN_DMZ_V2 virtual 11.8.200.64 255.255.255.224 any vlan 115 idle 10800 serverfarm LAN_DMZ replicate csrp sticky replicate csrp connection persistent rebalance inservice ! vserver LAN_INTERNET virtual 0.0.0.0 0.0.0.0 any vlan 115 serverfarm LAN_INTERNET replicate csrp sticky replicate csrp connection persistent rebalance inservice ! vserver LAN_INTERNET_2 virtual 11.8.200.224 255.255.255.224 any vlan 115 serverfarm LAN_INTERNET replicate csrp sticky replicate csrp connection persistent rebalance inservice ! vserver OUT_FW_CSM virtual 11.0.0.0 255.0.0.0 any vlan 15 serverfarm OUT_FW_CSM replicate csrp sticky replicate csrp connection persistent rebalance inservice !
Catalyst 6509 Layer 3 Configurations
Following are the Layer 3 configurations on the Catalyst 6509. Interface VLAN 115 is the one that links the CSM with the MSFC. VLAN 200 is used to connect the MSFC to the internal corporate routers.
interface Vlan115 ip address 11.8.200.103 255.255.255.224 no ip redirects standby 1 ip 11.8.200.102 standby 1 priority 105 standby 1 preempt standby 1 track Vlan200 ! interface Vlan200 ip address 11.8.200.130 255.255.255.224 no ip redirects standby 2 ip 11.8.200.129 standby 2 priority 105 standby 2 preempt standby 2 track Vlan115 ! ip default-gateway 11.8.200.97 ip classless ip route 0.0.0.0 0.0.0.0 11.8.200.97 ip route 11.0.0.0 255.0.0.0 11.8.200.135 ip route 11.8.200.32 255.255.255.224 11.8.200.97 ip route 11.8.200.64 255.255.255.224 11.8.200.97 ip route 11.8.200.224 255.255.255.224 11.8.200.97
Test and Verification
As mentioned before, each data center environment is unique with respect to the number of sockets used, the duration of TCP or UDP connections, activity in each session in terms of packets per second, idle timeouts, and so on. Thus, it is critical to test and verify the FWLB and SLB environments with the particular applications.
Following are a few critical test cases that you should verify after a new deployment or a major or minor infrastructure change—including a CSM or firewall code upgrade.
Verification of the firewall path by making sure all the probes are working correctly
Verification of traffic flow between all segments; that is, INET, DMZ, and LAN
Verification of active and passive FTP between LAN and DMZ
Content retrieval from the HTTP and HTTPS servers
A server-initiated session to a back-end database or internal server
A server-initiated backup or data replication session
Application daemon failure and detection by the CSM
Primary CSM failure, measurement of the recovery time
Primary Catalyst 6509 failure, measurement of the recovery time
Summary
This chapter introduced FWLB concepts, technology, products, and implementation details. This chapter covered motivations behind FWLB, provided an overview of different flavors of firewalls, and explained how to load balance each type.
In order to combine all the concepts of FWLB from the perspective of the CSM platform, this chapter also provided a case study. This case study focused on the deployment scenario of a real-world solution using the CSM to load balance firewalls with three secure segments. The CSM configurations have been provided and explained to introduce the reader to the CLI.
Chapter 6, “Transparent and Proxy Cache Load Balancing,” introduces caching terminology, technology, and methodology, together with a complete case study of cache load balancing using CSM on the Catalyst 6500.
Copyright © 2007 Pearson Education. All rights reserved.
