12-13-2010 07:25 PM
This question is regarding Firewall load balacing using Cisco ACE 4710 appliance
Is it possible to use any other predictor method other then hash based source (or) destination based load-balancing when using FWLB?
If I am using reverse-sticky groups (along with mac-sticky) then will it be possible to use least-connections or least-loaded predictor methods or even round-robin predictor for Firewall Load Balancing?
Thanks in advance for your prompt response!
12-14-2010 01:27 AM
Hi Hussain,
For FWLB, it is recommend that you use only the hash address source and the hash address destination predictors. Using any other predictor with FWLB may fail and block traffic, especially for applications that have separate control and data channels, for example, FTP.
Source IP hashing also provides a simple stateless way to stick a client to the same real server in SLB environments.
Typically, the default balancing method, round robin,also can be used. Since support of multiconnection protocols, such as FTP as I said above, is required in firewall loadbalancing design, you have to use predictor hash in your 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.
The default (netmask) is 255.255.255.255. The hash value is produced with the following algorithm:
ip_addr = (Src_or_Dest_Ip_addr & Cfg_Netmask) hash_index = (ip_addr) + (ip_addr >> 8) + ip_addr >> 16) + (ip_addr >> 24);
Also The packet will be dropped if hashing picks a firewall and if either of the following is true:
The max-conn reached for that firewall
Source and/or Destination IP Hash (Subnet Mask Configurable)
Source or destination IP hash method maps the IP address in the request to a real in a server farm. The configuration options are shown below.
predictor hash address [source | destination] [netmask]
!--- Source/Destination IP hash or predictor hash address.
The default (netmask) is 255.255.255.255. The hash value is produced with the following algorithm:
ip_addr = (Src_or_Dest_Ip_addr & Cfg_Netmask) hash_index = (ip_addr) + (ip_addr >> 8) + ip_addr >> 16) + (ip_addr >> 24);
Also for detail configuration examples for hash predictor kindly refer the below mentioned URL:
http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/v3.00_A1/configuration/slb/guide/fwldbal.html#wpxref70632Least Least connections—Selects the server with the fewest number of active connections based on the server weight. For the least-connections predictor, you can configure a slow-start mechanism to avoid sending a high rate of new connections to servers that you have just put into service.
Least loaded—Selects the server with the lowest load based on information obtained from Simple Network Management Protocol (SNMP) probes. To use this predictor, you must associate an SNMP probe with it.
Also, you want the return traffic going back to the same FW as it came in. This is done by specifying the command "mac-sticky enable" in the last post where you have asked this question.
The mac-sticky feature ensures that the ACE sends return traffic to the same upstream device through which the connection setup from the original client was received. When you enable this feature, the ACE uses the source MAC address from the first packet of a new connection to determine the device to send the return traffic. This guarantees that the ACE sends the return traffic for load-balanced connections to the same device originating the connection. By default, the ACE performs a route lookup to select the next hop to reach the client.
This feature is useful when the ACE receives traffic from Layer 2 and Layer 3 adjacent stateful devices, like firewalls and transparent caches, guaranteeing that it sends return traffic to the correct stateful device that sourced the connection without any requirement for source NAT. For more information on firewall load balancing, see the Cisco Application Control Engine Module Security Configuration Guide.
To enable the mac-sticky feature for a VLAN interface, use the mac-sticky enable command in interface configuration mode. By default, the mac-sticky feature is disabled on the ACE. The syntax of this command is:
mac-sticky enable
For example, to enable the mac-sticky feature, enter:
host1/Admin(config-if)# mac-sticky enable
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.
Check the following URL for FWLB config in detail:
Use the following additional URL readings to take design decisions which will be good for your FWLB design:
http://fengnet.com/book/CNF/ch11lev1sec2.html
http://www.brocade.com/support/Product_Manuals/ServerIron_ADXFirewall_LoadBalancingGuide/HA.4.3.html
Also get few more design hints from
Firewall Load Balancing with One CSM Configuration Example
Configuring Firewall Load Balancing in CSM
http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/csm/4.2.x/configuration/guide/fwldbal.html
http://pluscom.ru/cisco_product/cc/td/doc/product/lan/cat6000/cfgnotes/csm_3_2/icn/fwldbal.htmConfiguring Firewall Load Balancing in CSS
http://fengnet.com/book/CNF/ch11lev1sec2.html#iddle1633
Configuring Reverse-Sticky for Firewalls
http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/csm/4.2.x/configuration/guide/fwldbal.html#wp1038436
http://www.brocade.com/support/Product_Manuals/ServerIron_ADXFirewall_LoadBalancingGuide/index.htmlKindly rate.
http://www.hoggnet.com/Links/Load%20Balancing%20Links.htm
HTH
Sachin Garg
12-14-2010 06:02 AM
Thank you for the detailed response Sachin!
So just to summarize, if the environment uses FTP (or) other similar protocols that require multiple connections on different ports as part of the connection set-up process the only option for FWLB is source (or) destination address hash as the predictor.
If there is NO FTP (or) similar application in use, then least-connection predictor can be used combined with mac-sticky and reverse-sticky methods for FWLB?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide