One arm basic load balancing not working.. need help to verify config..

[steven.pw.lau]

Hi..

I'm trying out ACE Appliance 4710 and I've setup a basic configuration to load balance a server using one arm deployment with source NAT'ing.

Client facing side is 172.16.1.0/24
Server facing side is 192.168.1.0/24

I've one server which can be accessed with the URL https://172.16.1.10:8443 (I'm not doing SSL offloading) and the VIP for this server is 192.168.1.10.

Can anyone help me verify my config where has gone wrong? I need to be able to load balance using a custom port on the server rather than port 80.

I've not been able to access this webpage via https://192.168.1.10:8443 via the below ACE 4710 config.
However, I've no problem accessing this device using https://172.16.1.10:8443.

The below show service-policy shows all the connections being dropped.

Many Thanks!!

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

access-list everyone line 8 extended permit ip any any
access-list everyone line 16 extended permit icmp any any

probe icmp ICMP
  interval 15
  passdetect interval 60

rserver host web1
  ip address 172.16.1.10
  inservice

serverfarm host webfarm
  probe ICMP
  rserver web1 8443
    inservice

class-map type management match-any REMOTE_ACCESS
  2 match protocol ssh any
  3 match protocol telnet any
  4 match protocol snmp any
  5 match protocol http any
  6 match protocol https any
  7 match protocol icmp any

class-map match-all webfarm_CLASS1
  2 match virtual-address 192.168.1.10 any

policy-map type management first-match REMOTE_MGMT_ALLOW_POLICY
  class REMOTE_ACCESS
    permit

policy-map type loadbalance first-match L4_SLB_POLICY1
  class class-default
    serverfarm webfarm

policy-map multi-match L4_SLB_POLICY_MM
  class webfarm_CLASS1
    loadbalance vip inservice
    loadbalance policy L4_SLB_POLICY1
    loadbalance vip icmp-reply active
    nat dynamic 10 vlan 10

interface vlan 10
  description -- Client-facing VLAN & Management VLAN --
  ip address 192.168.1.100 255.255.255.0
  access-group input everyone
  nat-pool 10 192.168.1.20 192.168.1.32 netmask 255.255.255.0 pat
  service-policy input REMOTE_MGMT_ALLOW_POLICY
  service-policy input L4_SLB_POLICY_MM
  no shutdown

interface vlan 110
  description -- Server-facing VLAN --
  ip address 172.16.1.100 255.255.255.0
  no shutdown

ip route 0.0.0.0 0.0.0.0 192.168.1.50

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

When I try to connect to https://192.168.1.10:8443, I get the below result.

ACE01/Test# sh rserver

rserver              : web1, type: HOST
state                : OPERATIONAL (verified by arp response)
---------------------------------
                                                ----------connections-----------
       real                  weight state        current    total              
   ---+---------------------+------+------------+----------+--------------------
   serverfarm: webfarm
       172.16.1.10:8443      8      OPERATIONAL  1          1                 

rserver              : web2, type: HOST
state                : INACTIVE
---------------------------------
                                                ----------connections-----------
       real                  weight state        current    total              
   ---+---------------------+------+------------+----------+--------------------

ACE01/Test# sh service-policy

Policy-map : L4_SLB_POLICY_MM
Status     : ACTIVE
-----------------------------------------
Interface: vlan 1 10
  service-policy: L4_SLB_POLICY_MM
    class: webfarm_CLASS1
      nat:
        nat dynamic 10 vlan 10
        curr conns       : 0         , hit count        : 0        
        dropped conns    : 0        
        client pkt count : 0         , client byte count: 0                  
        server pkt count : 0         , server byte count: 0                  
        conn-rate-limit      : 0         , drop-count : 0        
        bandwidth-rate-limit : 0         , drop-count : 0        
      loadbalance:
        L7 loadbalance policy: L4_SLB_POLICY1
        VIP ICMP Reply       : ENABLED-WHEN-ACTIVE
        VIP State: INSERVICE
        Persistence Rebalance: DISABLED
        curr conns       : 1         , hit count        : 41       
        dropped conns    : 39       
        client pkt count : 651       , client byte count: 38340              
        server pkt count : 0         , server byte count: 0                  
        conn-rate-limit      : 0         , drop-count : 0        
        bandwidth-rate-limit : 0         , drop-count : 0        
      compression:
        bytes_in  : 0                          bytes_out : 0                  
        Compression ratio : 0.00%
                Gzip: 0               Deflate: 0        
      compression errors:
        User-Agent  : 0               Accept-Encoding    : 0        
        Content size: 0               Content type       : 0        
        Not HTTP 1.1: 0               HTTP response error: 0        
        Others      : 0       

[litrenta]

Problem here is that it is not really one arm. In one arm client and server traffic is on the same vlan. Your client traffic comes in on vlan 10 but your server lives on vlan 110 and is layer 2 adjacent to the ace. Hence the traffic will not be natted since vlan 10 is not used as the egress to the server.

If you don't want to have the server point to ace as default gateway then you need to change nat.

put a nat pool on vlan 110 such as:

interface vlan 110
  description -- Server-facing VLAN --
  ip address 172.16.1.100 255.255.255.0

  nat-pool 1 172.16.1.101 172.10.16.101 netmask 255.255.255.0 pat

  access-group input everyone
  no shutdown

then use it in you l4 policy map

policy-map multi-match L4_SLB_POLICY_MM
  class webfarm_CLASS1
    loadbalance vip inservice
    loadbalance policy L4_SLB_POLICY1
    loadbalance vip icmp-reply active
    nat dynamic 1 vlan 110

regards

[steven.pw.lau]

Got it...

Correct me if I'm wrong.. if I want to do a proper one-arm deployment, I would need to modify the config to the below..

Remove vlan 110 from the Test context in the ACE appliance..

Then have the server's default gateway pointing at the switch's SVI..

--------------Switch-----vlan 110------server (default gw = switch vlan110's SVI)

                 |

                 | vlan 10 (nat dynamic 10 vlan 10)

                 |

              ACE

Also, is my L4 load balancing policy correct?

I mean do I really need to configure

serverfarm host webfarm
  probe ICMP
  rserver web1 8443
    inservice

Or I can leave out the 8443 port number?

Thanks.

[litrenta · Accepted solution]

yes if you really want to do one arm then vlan 110 would be removed from the ace, and the server would be pointing to an svi for vlan 110 as its default gateway. and you would nat on vlan 10 on the ace.

as far as the serverfarm config if you want the ace to do port redirection then you would need the port on the serverfarm.

say the client hits the vip on port 443 and you want to send it to the server on port 8443 then you would need the port on the serverfarm

if client hits the vip on 8443 then you would not need it.

regards

[steven.pw.lau]

Many thanks for pointing this out...

I did the changes today and it's all working now.

However, there are some glitches. I'm not sure whether it's the ACE appliance behaviour or not as once I've made changes, it seems that I'm getting ARP_FAILED with "show rserver". However, I can ping to the server from the ACE appliance as well as "show probe " shows successful probes "passed".

I did a reboot on the ACE and then it's working. "show rserver" displays OPERATIONAL.

[chrhiggi]

Steven-

This is common when you modify an interface where an Rserver lived (i.e. move the ip from vlan 200 to 300 without rebooting.)

These are tracked under the following bugs:

CSCsi61783 fixed in 2(1.6) and beyond on the ACE module.
CSCte78786 fixed in 3(2.6) and beyond on the ACE 4710 Appliance.

Information on the bugs can be found in the Bug Toolkit:
http://tools.cisco.com/Support/BugToolKit/action.do?hdnAction=searchBugs

There are other flavors of the same type of issue but caused by different triggers which are fixed in other versions.  Most are fixed in the most recent versions for the module and appliance codes.

Regards,

Chris Higgins