Re: [load balancing] Alteon UDP load balancing issue

From: Henrik Lantz <henrik [izzat] onyx.nu>
Date: Thu Jun 26 2008 - 03:32:26 EDT

Marwan,

This was news to me. I'll try disabling DAM and see what happens - I've got extra VIPs set up for the direct access anyway, so I assume that this is just in there as stale config.

Thanks for the tip, I'll let you know how it comes out!

   // Henrik

Original Message -----------------------
You cannot load balance a stateless protocol like UDP and have DAM
enabled. By its nature, UDP cannot be recorded in the session table of
the alteon. You have to disable DAM on the Alteon 180e. In the new
Applications Switches, you can enable DAM globally and have it disabled
on particular service ports such as UDP.

 

Instead of DAM, you can use Proxy IP to connect directly to the servers.

 

Hope this helps.

 

 

Marwan Aboukhater

Systems Engineer-Canada

Radware Inc.

________________________________

From: lb-l-bounces@vegan.net [mailto:lb-l-bounces@vegan.net] On Behalf
Of Henrik Lantz
Sent: Wednesday, June 25, 2008 3:26 PM
To: lb-l@vegan.net
Subject: [load balancing] Alteon UDP load balancing issue

 

Hi folks,

 

I am a former frequent reader of/contributor to the lb-l list that is
now returning after a few years' absence seeking assistance from the
general expertise here. For a project I'm working on, I've salvaged a
pair of (very) old Alteon 180Es that I am using until I can get my shiny
new 3408s delivered (they are on order...); but I've run into an issue
with regards to UDP load balancing. I am under a lot of heat right now
to get this working before I get the new load balancers, so if anyone
has any ideas about this I'd be most grateful.

 

The platform serves two applications; one HTTP service that is running
fine, and a new UDP-based application that is not working for me.
Beside this, I have a couple of extra VIPs set up to allow for direct
access (SSH/FTP/proprietary protocols, all TCP) to the individual real
servers, and they are also working. The real servers that are supposed
to serve the UDP requests also make outgoing connections, and this is
handled without problems. Both Alteons are ACESwitch 180E, running
WebOS 10.0.30.8 (not using the BWM feature that caused that version to
get retracted). The Alteons are connected with two separate ports to my
Cisco Cat 6509s, one for the "Outside" VLAN with all the VIPs, and one
for the "Inside" VLAN with the real servers connected (off the Ciscos,
not directly to the Alteons). There is also a cross-connect trunk with
both VLANs between the Alteons and they are of course trunked between
the Ciscos as well. STP is disabled on the Alteons, allowing the Cats
to handle it. I've engineered it so that the ports between RtrB and
LB-02 are blocking on both VLANs. RtrA and LB-01 are HSRP/VRRP masters
in all instances.

 

Now, config for the offending portion:

 

--{snip, snip}--

/c/slb
 on
/c/slb/adv
 direct ena
 matrix dis
 grace ena

/c/slb/real 151
 ena
 rip 192.168.0.200
 name "UDPServerA"
/c/slb/real 152
 ena
 rip 192.168.0.201
 name "UDPServerB"

/c/slb/group 200
 health icmp
 add 151
 add 152
 name "UDPServers - Load Balanced"

/c/slb/port 1
 client ena
 server ena
/c/slb/port 2
 client ena
 server ena
 proxy ena
 pip xx.yy.36.41
/c/slb/port 9
 client ena
 server ena

/c/slb/virt 150
 ena
 vip xx.yy.36.40
 dname "UDPServers - Load Balanced"
/c/slb/virt 150/service 3700
 group 200
 udp enabled

 

/c/slb/filt 25
 dis
 action allow
 proto udp
 sport 3700

/c/slb/filt 100
 ena
 action nat
 dip 192.168.0.0
 dmask 255.255.255.0
 nat source
 invert ena

/c/slb/port 2
 filt ena
...

 add 25
 add 100
...

--{dius 'dius}--

 

Now, here's what I am seeing:

 

1) Wireshark capture on Inside VLAN between Alteon and server looks
fine: I see the UDP request coming in, with the client IP as source
address and the RIP as the destination, then moments later the response
with the RIP as the source and the client IP as the destination. All
fine.

 

2) When ENABLING filter 25 and capturing on the Outside VLAN, I see the
request with the client IP as source and the VIP as destination, then
the response comes back with the RIP as source and the client address as
the destination IP. Shouldn't the Alteon maintain state of the UDP
session and substitute it with the VIP coming back?

 

3) When DISABLING filter 25 and capturing on the Outside VLAN, things
get really weird. The requests flows as before, client IP -> VIP; but
the RESPONSE comes back as sourced by zz.qq.36.41 (see the PIP on port
2), where zz = xx + 128 and qq = yy + 40. I assume this is because it's
hitting the NAT filter 100, but then two questions pose themselves - 1)
as above, shouldn't the Alteon maintain state of UDP sessions, and 2)
why the bastardized PIP as a source address?

 

Can anybody spot anything I'm doing wrong here? It's the first time I'm
attempting to load balance a UDP service, so I am hoping it's something
glaringly obvious to anyone has seen it before...

 

And just for the record - I have tried shutting the load balancer that
is normally the master down and run only on the other one; they both
exhibit the exact same behaviour and use the exact same source IP for
the UDP response when filter 25 is disabled. I have rebooted both load
balancers, individually and simultaneously. I have no more addresses
available in the xx.yy.36.32/28 pool that I can assign as PIPs to be
able to activate VMA.

 

I'm tearing my hair out over this one.

 

Comments? Questions? Solutions (please)?

 

 

Thanks a lot in advance,

 

 

     Henrik
_______________________________________________
lb-l mailing list
lb-l@vegan.net
http://vegan.net/mailman/listinfo/lb-l
Searchable Archive: http://vegan.net/lb/archive
http://lbdigest.com Load Balancing Digest
http://lbwiki.com Load Balancing Wiki
Received on Thu Jun 26 03:32:55 2008

This archive was generated by hypermail 2.1.8 : Thu Jun 26 2008 - 03:32:56 EDT