Cisco Cisco IOS Software Release 12.2(18)SXF
Features
18
Cisco IOS Release 12.2(18)SXF5
If you have configured all-port virtual servers (that is, virtual servers that accept flows destined for all
ports except GTP ports), flows can be passed to servers for which no application port exists. When the
servers reject these flows, IOS SLB might fail the servers and remove them from load balancing. This
situation can also occur in slow-to-respond AAA servers in RADIUS load-balancing environments. To
prevent this situation, you can disable automatic server failure detection.
ports except GTP ports), flows can be passed to servers for which no application port exists. When the
servers reject these flows, IOS SLB might fail the servers and remove them from load balancing. This
situation can also occur in slow-to-respond AAA servers in RADIUS load-balancing environments. To
prevent this situation, you can disable automatic server failure detection.
Note
If you disable automatic server failure detection using the no faildetect inband command, Cisco
strongly recommends that you configure one or more probes.
strongly recommends that you configure one or more probes.
If you specify the no faildetect inband command, the faildetect numconns command is ignored, if
specified.
specified.
Automatic Unfail
When a real server fails and is removed from the list of active servers, it is assigned no new connections
for a length of time specified by a configurable retry timer. After that timer expires, the server is again
eligible for new virtual server connections and IOS SLB sends the server the next qualifying connection.
If the connection is successful, the failed server is placed back on the list of active real servers. If the
connection is unsuccessful, the server remains out of service and the retry timer is reset. The
unsuccessful connection must have experienced at least one retry, otherwise the next qualifying
connection would also be sent to that failed server.
for a length of time specified by a configurable retry timer. After that timer expires, the server is again
eligible for new virtual server connections and IOS SLB sends the server the next qualifying connection.
If the connection is successful, the failed server is placed back on the list of active real servers. If the
connection is unsuccessful, the server remains out of service and the retry timer is reset. The
unsuccessful connection must have experienced at least one retry, otherwise the next qualifying
connection would also be sent to that failed server.
Backup Server Farms
A backup server farm is a server farm that can be used when none of the real servers defined in a primary
server farm is available to accept new connections. When configuring backup server farms, keep in mind
the following considerations:
server farm is available to accept new connections. When configuring backup server farms, keep in mind
the following considerations:
•
A server farm can act as both primary and backup at the same time.
•
The same real server cannot be defined in both primary and backup at the same time.
•
Both primary and backup require the same NAT configuration (none, client, server, or both). In
addition, if NAT is specified, both server farms must use the same NAT pool.
addition, if NAT is specified, both server farms must use the same NAT pool.
DFP Agent Subsystem Support
IOS SLB supports the DFP Agent Subsystem feature, also called global load balancing, which enables
client subsystems other than IOS SLB to act as DFP agents. With the DFP Agent Subsystem, you can
use multiple DFP agents from different client subsystems at the same time.
client subsystems other than IOS SLB to act as DFP agents. With the DFP Agent Subsystem, you can
use multiple DFP agents from different client subsystems at the same time.
For more information about the DFP Agent Subsystem, refer to the DFP Agent Subsystem feature
document for Cisco IOS Release 12.2(18)SXD.
document for Cisco IOS Release 12.2(18)SXD.
Dynamic Feedback Protocol for IOS SLB
With IOS SLB Dynamic Feedback Protocol (DFP) support, a DFP manager in a load-balancing
environment can initiate a TCP connection with a DFP agent. Thereafter, the DFP agent collects status
information from one or more real host servers, converts the information to relative weights, and reports
the weights to the DFP manager. The DFP manager factors in the weights when load balancing the real
servers. In addition to reporting at user-defined intervals, the DFP agent sends an early report if there is
a sudden change in a real server’s status.
environment can initiate a TCP connection with a DFP agent. Thereafter, the DFP agent collects status
information from one or more real host servers, converts the information to relative weights, and reports
the weights to the DFP manager. The DFP manager factors in the weights when load balancing the real
servers. In addition to reporting at user-defined intervals, the DFP agent sends an early report if there is
a sudden change in a real server’s status.