Can ACE provide Load balanced Services from other Load balanced Servers

[RAMAN AZIZIAN]

Hello subject matter experts,

I like to find out if the ACE can provide load balanced services that can be called from other load balanced servers.

For example in our customer's network we are using Foundry LB to provide SLB (Server Load-balance) to LDAP using multiple Real servers.  Customer also has another application that uses LDAP services.

We recently had a problem with implementation of a application residing on the same physical switch requiring LB access to other applications on the same switch.  The LDAP / IDMAX problem occurs when a real server below the SLB makes a request to a VIP on  the SLB, The SLB picks one of the real servers supporting the VIP and sends the packet to it.  If the real server is on the adjacent switch, all works correctly as the return packet flows thru the SLB.  If the real server is on the same switch as the server that is making the request, the return packet flows directly thru the L2 switch, bypassing the SLB.  This creates a problem as the SLB never sees the return packet, and the SLB times out the connection.

Basically the Real server becomes a "Client" which sends out an request for another application via SLB.

We are deploying the ACE module using the VSS protocol (6509). The ACE modules have not been provisioned, since this will be a multi-Transition/Activity. But the above has been one of the concerns the customer has brought to our attention.

I wasn't sure if the ACE can have a real server associated with an Server Farm, be associated with another Server farm. Bascially real servers in one farm being Load-Balanced to another farm.

I would greatly appreciate any feedback/suggestions/recomendation you can provide. I have attached an sketch if your interested.

Best Regards,

Raman Azizian

[Peter Koltl]

Yes, you can have SLB client traffic from the real server but you need src NAT on ACE to avoid the asymmetric traffic you described.

[Sean Merrow]

Hello Raman,

As Peter pointed out, you'll need to perform source NAT on client connections when the clients are on the same IP subnet as the real servers that will take the connections.  This way, the real servers taking the connection will view the source IP address of the connection as an IP that is owned by the ACE, and this will force the server to send the response back to the ACE rather than back to the local host that intiated the connection.

I have attached a sample configuration that shows how to do this on the ACE.  With this example, only real servers that initiate connections will be NAT'd by the ACE, clients connecting to the VIP from  remote subnets will not be NAT'd.

Hope this helps,

Sean

[RAMAN AZIZIAN]

Sean and Peter,

Thanks for taking the time to provide your feedback.

Unfortunetly Source NAT is not accepted by the customer since it will not give them the capability to determine who the connections (servers) are coming from. If I use source NAT, then as you know all connections will apear from one source, unless I mis-understand how source NAT works.

LDAP is the protocol they point to since it is a directory container, and I just need to figure out how I can either "Replicate the structured data" they are looking for to their server, or come up with a "Work around" to utilize the resources of LDAP via SLB.

If you happen to come up with another suggestion, please kindly share it with me...

Best regards, and thanks again..

Raman

[Sean Merrow]

Hi Raman,

If this was HTTP load balancing, I would suggest to you to have the ACE insert the client's real source IP in the HTTP header as X-Forwarded-For.  However, since this is LDAP load balancing, this can't be done.

One thing is for sure, if you want to load balance clients and servers on the same subnet, you need to have some mechanism in place to have the server responses be sent back to the ACE, not directly back to the initiating clients.

The when-all-else-fails option is to use Policy-Based Routing (PBR) on the switch.  Here, you would have the switch forward any LDAP response from the server (source port 389) to the ACE.  If this still is not an option, then you would have to configure your infrastructure such that the response has no place to go other than the ACE.  And if that is not possible, then I'm not sure you will be able to actually load balance the LDAP connections.

Hope this helps.

Sean

[wasiimcisco]

I am also facing the same issue and my one post is already on the forum for technical help.

I have servers which are behind the windows load balancer. Everything is working fine but I am not able to open Web page on VIP address. I can ping, remote desktop on virtual IP address configured in ACE but when I try to open the web portal on virtual IP address it is not working.

[Peter Koltl]

No problem. Use static NAT with one-to-one mapping. Assign a phantom address to each rserver/client. ('nat static' command.) NAT != PAT

[RAMAN AZIZIAN]

Peter,

I think this may just work. Now I just have to go and find a sample config and the security associated with it.

Thanks again for your help!

Raman

[RAMAN AZIZIAN]

Hello fellow specialist,

This request has now resurfaced in my radar from my customer and I am planning on staging it in the lab so I can verify it is working correctly.

The requirements have changed (I know your shocked ;-) )

I like to find out does Source NAT impose any limitation if the Real Server needs to communicate with another Real Server in the same server farm, broadcast domain, and Subnet ? I also have a requirement for Real servers from Server Farm communicating with another Real Server located at another Server farm within the same broadcast domain, IP Subnet.

Here's a high-level config parameter:

Device: 6509 with ACE module, 10/100/1000 Line card, Sup card

Topology is : Bridge mode

VLAN Bridge: V351 bridged to V451

L3 Subnet: 192.168.1.0 /24

VIP Facing Client: 192.168.1.10 /24

VIP facing Real servers: ????? (can it be the same VIP as the client VIP)

Default Route: L3 VLAN 192.168.1.1 on the sup card

Here's my list of questions if someone has time to answer. As always thanks for your input.

1) If there are multiple VIPs and Server farm on a Context, should there be a NAT address associated with each, Serverfarm (NAT model: 1 for many)

2) Should ACL be applied only in the "input" direction on each side of the ACE (Client facing, and Server Facing)

3) Will the SRC NAT resolve the asymetric routing/forwarding, since the devices on the wire can see each other in their ARP table, and not by pass the SLB (VIP)?

4) Should this model, SRC NAT, be utilized in "Routed Mode" or will it support both "Routed mode" ,and "Bridge Mode".

5) Can anyone share a config that they have implemented in their lab or provide a suggestion on how to obtain one?

Thanks again for all your help. Let me know if you need any additional information on the topology.

Raman Azizian

[Peter Koltl]

1) In my conception, a static NAT address is assigned to each server when they send something to a VIP address (i. e. they send client-type traffic). So the src address is translated. (For complete understanding, the dst VIP address is also implicitly translated to a rserver address but we omit mentioning it when talking about NAT.) If you wish, you may easily modify the config to dynamic NAT. You don't set up NAT for server farms, you set it up for IP addresses (or subnets).

2. input ACL is enough

  access-group input permitanyany

  access-group input BPDU

3) Don't worry, no asymmetry. However, NAT is performed only if the servers send the traffic to a VIP address. All the other inter-server traffic (file copy etc.) with real addresses will be direct but that shouldn't be a problem. This traffic will not flow through the ACE. For SLB traffic the replies will go to NAT'ed address for which the ACE is the ARP responder.

4) NAT works also in bridged mode.

5)

class-map match-any NATclassSERVER56
match source-address 192.168.1.56 255.255.255.255
class-map match-any NATclassSERVER57
match source-address 192.168.1.57 255.255.255.255
class-map match-any NATclassSERVER29
match source-address 192.168.1.29 255.255.255.255
class-map match-any NATclassSERVER39
match source-address 192.168.1.39 255.255.255.255

policy-map type loadbalance first-match L7sysb
  class class-default
    serverfarm SFsysb

policy-map multi-match POLbackbone351
  class VSsysb
    loadbalance vip inservice
    loadbalance policy L7sysb
    loadbalance vip icmp-reply active

policy-map multi-match POLserver451
  class NATclassSERVER56
    nat static 192.168.1.121 netmask 255.255.255.255 vlan 451
  class NATclassSERVER57
    nat static 192.168.1.122 netmask 255.255.255.255 vlan 451
  class NATclassSERVER29
    nat static 192.168.1.123 netmask 255.255.255.255 vlan 451
  class NATclassSERVER39
    nat static 192.168.1.124 netmask 255.255.255.255 vlan 451
  class VSsysb
    loadbalance vip inservice
    loadbalance policy L7sysb
    loadbalance vip icmp-reply active