03-12-2011 05:30 AM
Hi,
We are building a network for the balancing of a radius service using 6509 and CSM module (4.2.6).
We are using the CSM in bridging mode (L2) between the server vlan and the client vlan.
The service has some servers providing radius authentication (UDP/1812) and radius accounting (UDP/1813) services on a VIP.
It seems the CSM works well when distributing the load between the servers, and doing NAT SERVER (the destination IP changes from VIP to the server IP).
However, the return radius ACK from the radius server to the source does not get translated back, and so, the source gets ACK replies from an unknown server, instead of the VIP.
The traffic is of this kind:
[SRC] -> [CSM] -> [RADIUS]
Packet:
SRC IP: SRC SRC IP: SRC
DST IP: VIP DST IP: RADIUS
SRC PORT: N (given number) SRC PORT: N
DST PORT: 1813 DST PORT: 1813
And it works well.
The Ack packet is:
[RADIUS] -> [CSM] -> [SRC]
Packet:
SRC IP: RADIUS SRC IP: RADIUS
DST IP: SRC DST IP: SRC
SRC PORT: 2813 SRC PORT: 2813
DST PORT: N (SAME AS BEFORE) DST PORT: N (SAME AS BEFORE)
Unluckily, the packet does not get translated back, it should change src ip to the VIP address.
Any ideas why this happens?
An excerpt of the cfg follows
vlan 3 client
ip address 1.1.1.30 255.255.255.192 alt 1.1.1.29 255.255.255.192
alias 1.1.1.28 255.255.255.192
!
vlan 4 server
ip address 1.1.1.30 255.255.255.192 alt 1.1.1.29 255.255.255.192
!
serverfarm FARM
nat server
no nat client
real 1.1.1.1
inservice
real 1.1.1.2
inservice
!
vserver SERVER
virtual 1.1.1.4 udp 0 service per-packet
serverfarm FARM
persistent rebalance
inservice
Tks,
Andrea
Solved! Go to Solution.
03-14-2011 08:26 PM
Hello,
The CSM, when in bridge mode and doing server nat you require a catch all vserver for client side traffic (source mac address to return the flow to).. Also, I noticed you are missing a gateway under your server vlan.. This should be added.. Try the below configuration, which i validated in my lab.. Notice how I'm gatching traffic with two nat statements (client/server side flows).. This is a best practice. I will look for the document on cco and post. I believe this will provide you the result you are looking for..
!
vlan 999 client
ip address 10.1.99.100 255.255.255.0
gateway 10.1.99.1
!
vlan 99 server
ip address 10.1.99.100 255.255.255.0
!
natpool TESTPOOL 10.1.99.101 10.1.99.101 netmask 255.255.255.0
!
probe PING icmp
!
real TEST35
address 10.1.99.5
inservice
!
serverfarm GW-NAT
no nat server
nat client TESTPOOL
real 10.1.99.1
inservice
!
serverfarm MCCABE
nat server
no nat client
real name TEST35 80
inservice
!
vserver CATCHALL
virtual 0.0.0.0 0.0.0.0 any
vlan 99
serverfarm GW-NAT
persistent rebalance
inservice
!
vserver test-35
virtual 10.1.99.200 tcp www
serverfarm MCCABE
persistent rebalance
inservice
03-12-2011 09:23 PM
Hello Andrea,
The issue looks to be an asymmetric flow, I guess that the CSM is not the default gateway for this server right?, anyway, you can fix this problem by configuring a natpool and then applying this natpool under the serverfarm as nat client, for example:
natpool test 1.1.1.35 1.1.1.35 netmask 255.255.255.192
serverfarm FARM
nat server
nat client test < --------- HERE
real 1.1.1.1
inservice
real 1.1.1.2
inservice
This should do the trick
Rod
03-13-2011 12:25 PM
Rod,
the CSM is the L2-gateway of the servers (we are using a bridging configuration, for design specs, you can see the conf).
So, every packet should be intercepted from the CSM but the return traffic doesn't get changed on the source ip field.
Yes, I know we can use client nat, but that goes against the need to preserve source and destination ports, that is a requirement of the protocol. The return packets should just be changed on the src ip field, exactly as a load balancer should do (just hide the servers behind).
In the conf I even tried to map the vserver udp on all ports (all the traffic is udp), anyway nothing seems changing.
Is that a hw limit of the CSM? I checked all the manuals and find nothing on it.
Tks,
Andrea
03-14-2011 07:39 AM
Hi Andrea,
Using bridge mode there is no guarantee that the traffic will return to the CSM by its own, I am sure that in this case, the return traffic is bypassing the CSM.
Could you please collect a CSM portchannel capture?
In your example, you have vlan 3 as client and vlan 4 as the server vlan, in your 6500, how these 2 vlans are configured?
Is vlan 3 configured as layer 3 (SVI)? what about vlan 4?
Thanks!
Rod.
03-14-2011 08:26 PM
Hello,
The CSM, when in bridge mode and doing server nat you require a catch all vserver for client side traffic (source mac address to return the flow to).. Also, I noticed you are missing a gateway under your server vlan.. This should be added.. Try the below configuration, which i validated in my lab.. Notice how I'm gatching traffic with two nat statements (client/server side flows).. This is a best practice. I will look for the document on cco and post. I believe this will provide you the result you are looking for..
!
vlan 999 client
ip address 10.1.99.100 255.255.255.0
gateway 10.1.99.1
!
vlan 99 server
ip address 10.1.99.100 255.255.255.0
!
natpool TESTPOOL 10.1.99.101 10.1.99.101 netmask 255.255.255.0
!
probe PING icmp
!
real TEST35
address 10.1.99.5
inservice
!
serverfarm GW-NAT
no nat server
nat client TESTPOOL
real 10.1.99.1
inservice
!
serverfarm MCCABE
nat server
no nat client
real name TEST35 80
inservice
!
vserver CATCHALL
virtual 0.0.0.0 0.0.0.0 any
vlan 99
serverfarm GW-NAT
persistent rebalance
inservice
!
vserver test-35
virtual 10.1.99.200 tcp www
serverfarm MCCABE
persistent rebalance
inservice
03-15-2011 02:11 AM
Hi,
Thanks for the answers,
yes the two vlans are just switched on the catalyst, they enter into the routed process with the other layer-3 vlans.
The default gw of the servers is the csm (the alias ip). We are totally sure there is not an asymmetric routing, the vlan servers talk with other vlans only by being bridged by the CSM.
We tried a similar catch-all configuration in the past days, now we'll check your last configuration: our aim is not to lose "src port" infos when the ACK comes back from the server to the client. We saw that nat client/natpool work as a PAT.
The other problem we had with our original catch-all configuration (listed below) is that we can't have two of them for different vservers/serverfarms (VIP) on the same vlan. We'll check it and we'll let you know
Our "check-all"
natpool NAT_UDP 1.1.1.4 1.1.1.4 netmask 255.255.255.192
serverfarm EXT_UDP_NAT
no nat server
nat client NAT_UDP
predictor forward
vserver EXT_UDP_ALBBE
virtual 0.0.0.0 0.0.0.0 udp 0
serverfarm EXT_UDP_NAT
vlan 4
persistent rebalance
client 1.1.1.1 255.255.255.255
client 1.1.1.2 255.255.255.255
inservice
Andrea
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide