Chapter 05: Implementing High Availability and Redundancy in a Campus Network (Part04)

Cisco IOS Server Load Balancing

Cisco IOS Server Load Balancing (SLB) intelligently load balances TCP/IP traffic across multiple servers, as illustrated in Figure 5-52. Cisco IOS SLB is a Layer 4 or Layer 7 switching feature, depending on configuration. Currently, the only Catalyst switch that supports Cisco IOS SLB is the Catalyst 6500 switch. Cisco IOS SLB is a software-based feature. For high-performance, hardware-based server load balancing, Cisco recommends the Cisco Application Control Engine (ACE) service module for the Catalyst 6500 switches. The ACE service module can help to achieve performance up to 16 Gbps. Also, the ACE service module provides security via SSL encryption/decryption and bidirectional support for content inspection.

Figure 5-52: Server Load Balancing

Cisco IOS SLB presents a single virtual server IP address to requesting clients. For example, clients make IP requests, such as HTTP Get, to this virtual IP address. The switch then distributes (load balances) these requests across a series of servers (real servers). The switch load-balancing request is based on numerous factors, such as TCP and UDP protocol, load, and other load-balancing characteristics. Furthermore, the switch forwards requests from clients to the same server when necessary, such as with FTP when a client must communicate with the same server throughout the entire sequence or flow. Generally, client devices resolve the virtual server IP address through DNS.

Using Cisco IOS SLB for redundancy, scalability, and performance (load balancing) provides the following benefits:

• High performance is achieved through the distribution of client requests across a cluster of servers.

• Administration of server applications is easier. Clients know only about virtual servers; no administration is required for real server changes, making Cisco IOS SLB highly scalable.

• Security of the real server is provided because its address is never announced to the external network. Users are familiar only with the virtual IP address. Additionally, filtering of unwanted traffic can be based on both IP address and IP port numbers.

• Ease of maintenance with no downtime is achieved by allowing physical (real) servers to be transparently placed in or out of service while other servers handle client requests.

• Switches detect servers that are not responding and do not forward further requests to those servers until they begin to respond to polls from the switch.

In summary, Cisco IOS SLB enables users to represent a group of network servers (a server farm in a data center) as a single server instance, balance the traffic to the servers, and limit traffic to individual servers. The single server instance that represents a server farm is referred to as a virtual server. Figure 5-53 illustrates a Cisco IOS SLB applied to a server farm in a data center. The virtual web server IP address is 192.168.1.200 on port 80, and the real web servers are 192.168.1.1 and 192.168.1.2. Any request to the virtual web server address is served by the two real servers.

Figure 5-53: SLB Virtual Server and Server Farm

Cisco IOS SLB Modes of Operation

In an SLB environment, clients connect to the IP address of the virtual server. When a client initiates a connection to the virtual server, the SLB function chooses a real server for the connection based on a configured load-balancing algorithm.

Cisco IOS SLB supports the following redirection modes:

• Dispatched mode: Each of the real servers is configured with the virtual server address as a loopback address or secondary IP address. Cisco IOS SLB redirects packets to the real servers at the MAC layer. Because the virtual server IP address is not modified in dispatched mode, the real servers must be Layer 2–adjacent to Cisco IOS SLB, or intervening routers might not route to the chosen real server.

• Directed mode: The virtual server can be assigned an IP address that is not known to any of the real servers in a data center. Cisco IOS SLB translates packets exchanged between a client and a real server, translating the virtual server IP address to a real server address via Network Address Translation (NAT). For more information about Cisco IOS SLB support of different NAT types, refer to the Cisco IOS SLB configuration section of the Cisco product documentation for the Catalyst 6500 switches.

Configuring Cisco IOS SLB involves identifying server farms, configuring groups of real servers in data centers, and configuring the virtual servers that represent the real servers to the clients. The following sections provide a sample configuration of Cisco IOS SLB.

Configuring the Server Farm in a Data Center with Real Servers

The following steps describe how to configure Cisco IOS SLB in a server farm in a data center with real servers:

Step 1	Define the server farm: Switchip slb serverfarm serverfarm-name
Step 2	Associate the real server with the server farm: Switch(config-slb-sfarm)# real ip-address-of-the-real-server
Step 3	Enable the real server defined to be used for the Cisco IOS server farm: Switch(config-slb-real)# inservice

Example 5-21 shows a user configuring two server farms in a data center, PUBLIC and RESTRICTED. The PUBLIC server farm has associated with it three real servers: 10.1.1.1, 10.1.1.2, and 10.1.1.3. The RESTRICTED server farm has two real servers associated with it: 10.1.1.20 and 10.1.1.21. Figure 5-54 visually depicts the configuration.

Figure 5-54: Configuration Scenario of Cisco IOS SLB for Webserver Farms in a Data Center

Example 5-21: Configuring Server Farm with Real Servers

---

Switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# ip slb serverfarm PUBLIC
Switch(config-slb-sfarm)# real 10.1.1.1
Switch(config-slb-real)# inservice
Switch(config-slb-real)# exit
Switch(config-slb-sfarm)# real 10.1.1.2
Switch(config-slb-real)# inservice
Switch(config-slb-real)# exit
Switch(config-slb-sfarm)# real 10.1.1.3
Switch(config-slb-real)# inservice
Switch(config-slb-real)# exit
Switch(config-slb-sfarm)# exit
Switch(config)# ip slb serverfarm RESTRICTED
Switch(config-slb-sfarm)# real 10.1.1.20
Switch(config-slb-real)# inservice
Switch(config-slb-real)# exit
Switch(config-slb-sfarm)# real 10.1.1.21
Switch(config-slb-real)# inservice
Switch(config-slb-real)# end
Switch#

---

Example 5-22 shows a user displaying the status of the server farms PUBLIC and RESTRICTED, the associated real servers, and their status, respectively.

Example 5-22: Displaying SLB Real Servers

---

Switch# show ip slb real

real                    farm name        weight   state          cons
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
10.1.1.1                 PUBLIC           8       OPERATIONAL      0
10.1.1.2                 PUBLIC           8       OPERATIONAL      0
10.1.1.3                 PUBLIC           8       OPERATIONAL      0
10.1.1.20                RESTRICTED       8       OPERATIONAL      0
10.1.1.21                RESTRICTED       8       OPERATIONAL      0

---

Example 5-23 shows a user displaying the configuration and status of server farms PUBLIC and RESTRICTED, respectively.

Example 5-23: Displaying SLB Server Farm

---

Switch# show ip slb serverfarm

server farm      predictor    nat   reals   bind id
– – – – – – – – – – – – – – – – – – – – – – – – –
PUBLIC           ROUNDROBIN   none  3       0
RESTRICTED       ROUNDROBIN   none  2       0

---

Configuring Virtual Servers

The following steps describe how to configure virtual servers in Cisco IOS SLB:

Step 1	Define the virtual server: ip slb vserver vserver-name
Step 2	Configure the IP address of the virtual server: virtual ip-address [network-mask] {tcp | udp} [port-number | wsp | wsp-wtp | wsp-wtls | wsp-wtp-wtls] [service service-name]
Step 3	Associate the primary and secondary server farm to the virtual server: serverfarm primary-serverfarm-name [backup backup-serverfarm-name [sticky]]
Step 4	Enable the virtual server: inservice
Step 5	Specify the clients allowed to access the virtual server: client ip-address network-mask

Example 5-24 shows a user configuring the virtual servers PUBLIC_HTTP and RESTRICTED_HTTP, respectively, with the latter configuration showing how to restrict access to clients in the network 10.4.4.0.

Example 5-24: Configuring Virtual Servers

---

Switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# ip slb vserver PUBLIC_HTTP
Switch(config-slb-vserver)# virtual 10.1.1.100 tcp www
Switch(config-slb-vserver)# serverfarm PUBLIC
Switch(config-slb-vserver)# inservice
Switch(config-slb-vserver)# exit
Switch(config)# ip slb vserver RESTRICTED_HTTP
Switch(config-slb-vserver)# virtual 10.1.1.200 tcp www
Switch(config-slb-vserver)# client 10.4.4.0 255.255.255.0
Switch(config-slb-vserver)# serverfarm RESTRICTED
Switch(config-slb-vserver)# inservice
Switch(config-slb-vserver)# end
Switch#

---

Example 5-25 shows a user verifying the configuration of the virtual servers PUBLIC_HTTP and RESTRICTED_HTTP, respectively.

Example 5-25: Displaying SLB Virtual Servers

---

Switch# show ip slb vserver
slb vserver      prot  virtual               state           cons
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
PUBLIC_HTTP      TCP   10.1.1.100:80         OPERATIONAL    0
RESTRICTED_HTTP  TCP   10.1.1.200:80         OPERATIONAL    0

---

Example 5-26 shows a user verifying the restricted client access and status, respectively.

Example 5-26: Displaying the Current SLB Connections

---

Switch# show ip slb connections
vserver         prot client               real                  state     nat
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
RESTRICTED_HTTP TCP 10.4.4.0:80           10.1.1.20             CLOSING   none

---

Example 5-27 shows a user displaying detailed information about the restricted client access status.

Example 5-27: Displaying Detailed Information for an SLB Client

---

Switch# show ip slb connections client 10.4.4.0 detail
VSTEST_UDP, client = 10.4.4.0:80
 state = CLOSING, real = 10.1.1.20, nat = none
 v_ip = 10.1.1.200:80, TCP, service = NONE
 client_syns = 0, sticky = FALSE, flows attached = 0

---

Example 5-28 shows a user displaying detailed information about the Cisco IOS SLB network status.

Example 5-28: Displaying SLB Statistics

---

Switch# show ip slb stats
Pkts via normal switching:   0
Pkts via special switching:  6
Connections Created:         1
Connections Established:     1
Connections Destroyed:       0
Connections Reassigned:      0
Zombie Count:                0
Connections Reused:          0

---

Summary

Building a resilient and high available network is paramount as most organizations depend on the network for the business operations.

High availability involves several elements: redundancy, technology, people, processes and tools. At the network level, high availability involves making sure that there is always a possible path between two endpoints. High availability minimizes link and node failures to minimize downtime, by implementing link and node redundancy, providing alternate paths for traffic, and avoiding single points of failure.

Redundancy is a balance between too much redundancy, which increases complexity the network structure, and too little redundancy, which creates single points of failure. When uplinks fail, convergence path and convergence time have to be taken into account to evaluate the impact of the failure on the network infrastructure.

On Cisco IOS–based Catalyst switches, RPR, RPR+, SSO, and NSF with SSO are the various modes of Supervisor redundancy available. The preferred mode is the NSF with SSO because it provides both Layer 2 and Layer 3 protocol state syncing between active and standby Supervisors, therefore guaranteeing the least amount of network impact due to failover, if any at all.

Various first hop redundancy protocols exist including HSRP, VRRP, and GLBP. Currently, HSRP is the most popular choice.

HSRP operates with one router acting as active and the other backup router as a standby router. The active, standby, and other HSRP routers use a virtual IP address for redundancy to hosts. If the active router fails, the standby router becomes the active router and takes responsibility of the destination MAC and IP of the virtual IP address. In this manner, HSRP failover is transparent to the host. Routers running HSRP can be configured for preemption such that if a higher-priority HSRP peer comes online, the higher-priority router takes over the active router role. Otherwise, the latest active router remains the active router when new HSRP peers come online.

VRRP is similar to HSRP except that VRRP is an industry standard, whereas HSRP is a Cisco proprietary protocol. GLBP is another Cisco feature in which multiple routers not only act as backup default gateway routers but also share load in forwarding traffic, unlike HSRP and VRRP, where only the active router forwards traffic. Note that HSPR and VRRP can be distributed across VLANs, achieving load balancing using VLANs.

The Cisco IOS SLB features enable load balancing of connections to a group of real servers and therefore provide fault tolerance for the group of real servers. With this feature, hosts connect to a single virtual server, which in turn is supported by many real servers that are transparent to the host. IOS SLB also supports many forms of load balancing and redundancy.

Monitoring the network using SNMP, Syslog, and IP SLA are key element to ensure the high availability of the network and take corrective action to ensure increased availability.