Guest

Cisco CSS 11000 Series Content Services Switches

Configuring Global Load Balancing on the CSS 11000

Hierarchical Navigation

Document ID: 12607

Updated: Dec 06, 2002

   Download PDF
   Print

Contents

Introduction

The Cisco content services switches (CSSs) employ the Content and Application Peering Protocol (CAPP), which allows the switches to exchange content information. The CAPP session is guaranteed and secure. When combined with the built-in DNS server of the switch, it allows for a powerful automatic global load balancing solution. CAPP ensures that the least loaded site/server is used for requested Web site.

Network Diagram

Network Diagram

Description

The "foo.com" company has web sites in France and in the United States. They want clients serviced by the site used by that clients DNS-proxy server for the DNS lookup. It is hoped that the DNS-proxy servers in the US will select the CSS in the US for their DNS queries, and the DNS-proxy servers in France will use the CSS in France for their DNS queries. DNS-proxy servers in other locations would hopefully use the CSS that is closest to them. There is no requirement for DNS-proxy servers to use the nearest Name Server when they receive a list of NS records for a domain. If either site's servers go down, the clients are forwarded to the other site.

You can view the DNS server information with the show dns-server stats command and show dns-server dbase command to see the entries in the host table. The show app commands give information on the sessions established between the switches. Showing the rules on either switch (show rule-summary command) reveals that each switch has shared information about its local rules with its peer. These rules show up as "rule_name@remote_switch." You can even use the secure connection to issue a command line interface (CLI) command on the remote switch. For example, to see the rule on the other switch use the rcmd remote_addr show rule-summary command.

To balance the traffic strictly based on the the "load" at each site, you would want to omit the command dnsbalance preferlocal from both configs. This will allow even load balancing, but will result in some users reaching a "distant" site. Please note that some browsers will make a new DNS query every 30 minutes regardless of the recent web-browser activity.

Configurations

FooFrance Switch Configuration 
!Generated MAY  2 17:29:11

!Active version: ap0310029s

configure

!*************************** GLOBAL ***************************

  bridge spanning-tree disabled

  dns-server

  host css-france 10.1.1.254               ; Static host entry (not required)
  ip route 0.0.0.0 0.0.0.0 192.168.1.254 1 ; Connect to our "Internet"
  app                                      ; Enable the Application Peering Protocol
                                           ; Establish an encrypted session between CSS's
  app session 192.168.1.254 14 authChallenge mysecret encryptMd5hash

!************************** CIRCUIT **************************

circuit VLAN1

  ip address 10.1.1.254 255.255.255.0
  ip address 192.168.1.253 255.255.255.0

!************************** SERVICE **************************

service FrSrvr1

  ip address 10.1.1.1
  keepalive uri "/index.html"
  keepalive type http
  active

service FrSrvr2

  ip address 10.1.1.2
  keepalive uri "/index.html"
  keepalive type http
  active

!*************************** OWNER ***************************

owner foo.com

  dns both                             ; Send and Accept DNS

  content WebServers
    vip address 10.1.1.100
    protocol tcp
    port 80
    add service FrSrvr1
    add service FrSrvr2
    dnsbalance preferlocal       ; use local VIP unless all local
                                 ; servers are down.
    url "/*"
    active

fooUS Switch Configuration 
!Generated MAY  2 15:59:56

!Active version: ap0310027b

configure

!*************************** GLOBAL ***************************

  bridge spanning-tree disabled

  dns-server                            ; Enable the DNS server

  ip route 0.0.0.0 0.0.0.0 10.1.1.254 1 ; Establish a route to our "Internet"
  host css-us 192.168.1.254             ; Static host entry (not required)
  app                                   ; Enable Application Peering Protocol
                                        ; Establish secure connection to French CSS
  app session 192.168.1.253 14 authChallenge mysecret encryptMd5hash

!************************** CIRCUIT **************************

circuit VLAN1

  ip address 10.1.1.253 255.255.255.0
  ip address 192.168.1.254 255.255.255.0

!************************** SERVICE **************************

service USSvr1
  ip address 192.168.1.1
  keepalive uri "/index.html"
  keepalive type http
  active

service USSvr2
  ip address 192.168.1.2
  keepalive type http
  keepalive uri "/index.html"
  active

!*************************** OWNER ***************************

owner foo.com

  dns both                              ; Accept and Send DNS

  content WebServers
    protocol tcp
    port 80
    vip address 192.168.1.100
    add service USSvr1
    add service USSvr2
    dnsbalance preferlocal            ; Fault Tolerance- Only if all local
                                      ; servers are down, return the remote VIP.
    add dns www.foo.com               ; Add a DNS record for our VIP
    url "/*"
    balance leastconn
    active

Tests

Verify the CSSs are communicating with each other by using a show app session command on the French switch. 
App Session Information 'no hostname':

Session ID: 836d2040  IP Address: 192.168.1.254  State: APP_SESSION_UP
Verify that all the services attached to the two switches are up using the show service summary command. There is an additional "service" that was learned from the remote switch. The service with the "@" is actually the collection of services on that remote switch. 

Service Name                     State     Conn  Weight  Avg   State
                                                         Load  Transitions

FrSrvr1                          Alive         0      1     2           16
FrSrvr2                          Alive         0      1     2           16
WebServers@192.168.1.100         Alive         0      1     2            0
The show dns-server stats command shows the resolutions that were sent to the local Virtual IP (VIP) and the remote VIP. 


DNS Server SCM database Statistics:

DNS Name:         Content Name:     Location:        Resolve Local:  Remote:

----------------------------------------------------------------------------

css-france        HOST TABLE        10.1.1.254       0               0

www.foo.com       WebServers        10.1.1.100       9
                                    @192.168.1.100                   4

Repeat using the US switch's console. The host table shows the resolution from its standpoint. Point the web browser to www.foo.com using the French client. It will resolve to the local VIP. Unplug (or suspend) all the servers on the French CSS. Click on a link on the page. The CSS has redirected the browser seamlessly to a server on the remote CSS. Reconnect the French CSS. You continue to stay on the US CSS maintaining state. If you open a new browser session (or re-enter the URL), the CSS binds to a French server. Disconnect the servers on the French CSS. Issue a monitor show summary command on the French CSS CLI. Use a web stressing application (for example, MS Web Application Stress) to hit the site www.foo.com. Reconnect the French servers. Note the CSS verifies the servers are back online using the HTTP keepalive. Once they are up, it load balances over the French servers and stops sending the clients to the US CSS. 


Global Bypass Counters:
   No Rule Bypass Count:     7186
   Acl Bypass Count:         0


Owner            Content Rules    State     Services         Service Hits


foo.com          WebServers       Active    FrSrvr1          14973
                                            FrSrvr2          14972
                                            WebServers@192.1 7165

Related Information

Updated: Dec 06, 2002
Document ID: 12607