locked
Using Cisco CSM as a Load Balancer RRS feed

  • Question

  • Are there any examples of the config required on a Cisco CSM to be used as the hardware load balancer for OCS.

     

    It is unclear to me whether "SNAT" is equivalent to the CSM "client NAT" or "server NAT".

     

    It would be good to understand exactly how the traffic flows, and therefore be able to understand the exact NAT requirement.

    Friday, November 30, 2007 4:30 AM

All replies

  •  

    Cisco CSM is actually DNAT device. Please contact Cisco if you want to configure it as an SNAT device.
    Wednesday, July 9, 2008 5:30 AM
  • This is for a CSS.

     

    DNAT Config:

    This section defines the servers that will be load balanced.  In this example, we are load balancing to 2 servers (172.17.22.75 & 172.17.22.75)

    service LCS_1 <===== What you are load balancing to (i.e. application, protocol, IP, etc)
      ip address 172.17.22.75
      protocol tcp
      keepalive type tcp <====== Protocol used for the health check.  What determines if the app, etc is available.
      keepalive port 5060 < ====== Port used for the health check.  If not available, it will stop sending traffic to this server
                                                       (default every 5 secs.  will wait for 3 failures to fail)
      active

    service LCS_2
      ip address 172.17.22.76
      protocol tcp
      keepalive type tcp
      keepalive port 5060
      active

    owner LCS
      content LCS
        vip address 172.18.10.110 <==== Note that the VIP is on a different subnet from the servers. This is a requirement for DNAT.
        add service LCS_1 <==== Adding the servers we defined above to the VIP
        add service LCS_2
        protocol tcp <===== Instead of whole IP it is load balancing just TCP.  This is optional.  You could use UDP or omit this to balance all protocols.
        advanced-balance sticky-srcip
        balance leastconn <=== Does least connection load balancing
        sticky-inact-timeout 600 <=== Cleanup period for stale connections in seconds
        active


    To change the above configuration to SNAT, the VIP will have to be changed to an IP on the same subnet as the servers and the following will be added to the config on the CSS.

    SNAT Config

    service LCS_1 <===== What you are load balancing to (i.e. application, protocol, IP, etc)
      ip address 172.17.22.75
      protocol tcp
      keepalive type tcp <====== Protocol used for the health check.  What determines if the app, etc is available.
      keepalive port 5060 < ====== Port used for the health check.  If not available, it will stop sending traffic to this server
                                                       (default every 5 secs.  will wait for 3 failures to fail)
      active

    service LCS_2
      ip address 172.17.22.76
      protocol tcp
      keepalive type tcp
      keepalive port 5060
      active

    owner LCS
      content LCS
        vip address 172.17.22.77 <==== Note that the VIP is on a different subnet from the servers. This is a requirement for DNAT.
        add service LCS_1 <==== Adding the servers we defined above to the VIP
        add service LCS_2
        protocol tcp <===== Instead of whole IP it is load balancing just TCP.  This is optional.  You could use UDP or omit this to balance all protocols.
        advanced-balance sticky-srcip
        balance leastconn <=== Does least connection load balancing
        sticky-inact-timeout 600 <=== Cleanup period for stale connections in seconds
        active

    group LCS_Servers  <======= THIS IS THE SOURCE NAT RULE PART
      vip address 172.17.22.77
      add destination service LCS_1
      add destination service LCS_2
      active

    NOTES: The "add destination service" (under group LCS_Servers) command will NAT the traffic that is heading towards the Server, being load balanced to your servers. All traffic that is incoming to the server will be NATed to the VIP configured.

    If you don’t use groups, the servers will see the source ip (clients), but when you use group the source IP will be the VIP address of the group, so the servers will think that the VIP is the IP that is requesting the information, then when the CSS recieves the information from the server, the CSS will send it to the respective client.

    Wednesday, July 9, 2008 12:30 PM
  • Hi Mark,

    Load balancing is an exact science as far as LCS is concerned. Let's break down the supported topologies and NAT modes.. ANY OEM of hardware load balancer is supported if it can be connected in two topologies that are supported: 1) as an independent node on the network (a one-arm topology) or 2) as an intermediary device between the Front End servers and the rest of the network (a two-arm topology).

     

    Only two NAT modes are supported for LCS, DNAT (Destination NAT - RECOMMENDED) and SNAT (Source NAT) and there’s certain topologies that work with those NAT configs. For DNAT: two-arms and one or two IP subnets behind the load balancer is supported or one arm and two IP subnets is supported. For SNAT: two-arms and one or two IP subnets behind the load balancer is supported or one arm and one or two IP subnets is supported.

     

    Below is a list of load balancer connectivity requirements for setting up a LCS 2005 pool:

    1. The load balancer MUST expose an ARP-able Virtual IP Address (VIP)
    2. The load balancer MUST provide TCP-level affinity. This means that the load balancer must ensure that TCP connections established with one Front End server will guarantee that all subsequent traffic on that connection will go to the same Front End.
    3. TCP idle timeout should be set to 20 minutes as a best practice.
    4. Front Ends within a pool MUST be capable of routing to each other. There can be no NAT device in this path of communication. Any such device will prevent successful intra-pool communication over RPC.
    5. Front Ends MUST have access to the Active Directory environment.
    6. Front Ends MUST have static IP addresses that can be used to configure them in the load balancer. In addition, these IP addresses must have DNS registrations.
    7. Administration machines MUST be able to route to both the Pool FQDN as well as the Front End FQDN of every Front End in the pool(s) to be managed. In addition, there can be no NAT device in the path of communication to the Front Ends.

    Hope this helps with your support case..


    Stu Osborn

    Tuesday, August 19, 2008 9:35 PM