Cisco Cisco IOS Software Release 12.2(14)ZA
Features
13
Cisco IOS Release 12.2(14)ZA5
Port-Bound Servers
When you define a virtual server, you must specify the TCP or UDP port handled by that virtual server.
However, if you configure NAT on the server farm, you can also configure port-bound servers.
Port-bound servers allow one virtual server IP address to represent one set of real servers for one service,
such as HTTP, and a different set of real servers for another service, such as Telnet.
However, if you configure NAT on the server farm, you can also configure port-bound servers.
Port-bound servers allow one virtual server IP address to represent one set of real servers for one service,
such as HTTP, and a different set of real servers for another service, such as Telnet.
Packets destined for a virtual server address for a port that is not specified in the virtual server definition
are not redirected.
are not redirected.
IOS SLB supports both port-bound and non-port-bound servers, but port-bound servers are
recommended.
recommended.
IOS SLB firewall load balancing does not support port-bound servers.
Route Health Injection
By default, a virtual server’s IP address is advertised (added to the routing table) when you bring the
virtual server into service (using the inservice command). If you have a preferred host route to a
website’s virtual IP address, you can advertise that host route, but you have no guarantee that the
IP address is available. However, you can use the
virtual server into service (using the inservice command). If you have a preferred host route to a
website’s virtual IP address, you can advertise that host route, but you have no guarantee that the
IP address is available. However, you can use the
command to configure IOS SLB to advertise
the host route only when IOS SLB has verified that the IP address is available. IOS SLB withdraws the
advertisement when the IP address is no longer available. This function is known as route health
injection.
advertisement when the IP address is no longer available. This function is known as route health
injection.
Sticky Connections
Sometimes, a client transaction can require multiple consecutive connections, which means new
connections from the same client IP address or subnet must be assigned to the same real server. These
connections are especially important in firewall load balancing, because the firewall might need to
profile the multiple connections in order to detect certain attacks.
connections from the same client IP address or subnet must be assigned to the same real server. These
connections are especially important in firewall load balancing, because the firewall might need to
profile the multiple connections in order to detect certain attacks.
You can use the optional sticky command to enable IOS SLB to force connections from the same client
to the same load-balanced server within a server farm. For firewall load balancing, the connections
between the same client-server pair are assigned to the same firewall. New connections are considered
to be sticky as long as the following conditions are met:
to the same load-balanced server within a server farm. For firewall load balancing, the connections
between the same client-server pair are assigned to the same firewall. New connections are considered
to be sticky as long as the following conditions are met:
•
The real server is in either OPERATIONAL or MAXCONNS_THROTTLED state.
•
The sticky timer is defined on a virtual server or on a firewall farm.
This binding of new connections to the same server or firewall is continued for a user-defined period
after the last sticky connection ends.
after the last sticky connection ends.
To get the client-server address sticky behavior needed for “sandwich” firewall load balancing, you must
enable sticky on both sides of the firewall farm. In this configuration, client-server sticky associations
are created when an initial connection is opened between a client-server address pair. After this initial
connection is established, IOS SLB maintains the sticky association in the firewall load-balancing
devices on either side of the farm, and applies the sticky association to connections initiated from either
the client or server IP address, by both firewall load-balancing devices.
enable sticky on both sides of the firewall farm. In this configuration, client-server sticky associations
are created when an initial connection is opened between a client-server address pair. After this initial
connection is established, IOS SLB maintains the sticky association in the firewall load-balancing
devices on either side of the farm, and applies the sticky association to connections initiated from either
the client or server IP address, by both firewall load-balancing devices.
Client subnet sticky is enabled when you specify a subnet mask on the sticky command. Subnet sticky
is useful when the client IP address might change from one connection to the next. For example, before
reaching IOS SLB, the client connections might pass through a set of NAT or proxy firewalls that have
no sticky management of their own. Such a situation can result in failed client transactions if the servers
do not have the logic to cope with it. In cases where such firewalls assign addresses from the same set
of subnets, IOS SLB's sticky subnet mask can overcome the problems that they might cause.
is useful when the client IP address might change from one connection to the next. For example, before
reaching IOS SLB, the client connections might pass through a set of NAT or proxy firewalls that have
no sticky management of their own. Such a situation can result in failed client transactions if the servers
do not have the logic to cope with it. In cases where such firewalls assign addresses from the same set
of subnets, IOS SLB's sticky subnet mask can overcome the problems that they might cause.