10-17-2007 04:51 AM
My load balancing is not working, I believe it is due to the fact that the class map i have created for L7 is not being treated as an L7 class map.
From doc: "The ACE treats as a Layer 3 and Layer 4 policy any policy map that ... has the default class configured as the class map, and there are no Layer 7 policy actions configured"
This is what I have configured so I must change it. However, it is not http or ftp (it's LDAP). Here is my attempt..
class-map match-any L7_Class
description L7 class map for VIP-A
2 match port tcp eq xxx
ace/Context1(config)# policy-map type loadbalance first-match L7_Policy
ace/Context1(config-pmap-lb)# class ?
class-default Specify actions for default class-map
ace/Context1(config-pmap-lb)# class L7_Class
Error: Specified class-map is not consistent with the policy-map type
ace/Context1(config-pmap-lb)# exit
ace/Context1(config)# class-map type ?
ftp Configure ftp class-map
http Configure http class-map
management Configure management traffic class-map
How can I get this to work?
10-17-2007 07:20 AM
looks like you got confused.
Your class-map is ok.
So personally, I would only have a single match per class-map when talking about vip.
Makes it easier to change something later on if a service requires special action that the other does not.
class-map match-all VIP-122-80-2
2 match virtual-address 192.168.20.122 tcp eq www
Then you need a serverfarm with your real servers
serverfarm host linux1-80
rserver linux1 80
inservice
rserver linux1-24 80
inservice
THen you need to assign the serverfarm to a loadbalance policy.
Here, if you need some L7 matching, you will create some L7 class-map. If not, just use the class default
policy-map type loadbalance first-match SF_Linux1_SRC
class class-default
serverfarm linux1
Finally, link everything together with another policy-map. It's a multimatch policy - different from the other one.
policy-map multi-match SLB1
class VIP-122-80
loadbalance vip inservice
loadbalance policy SF_Linux1_SRC
loadbalance vip icmp-reply
Finally, apply the policy to an interface or you can also apply it globally to the entire box.
Hope this helps.
Gilles.
10-17-2007 09:01 AM
Hi Gilles,
As far as I can tell that is what I have, but it is not working.
rserver host M-Old
ip address 1.1.8.11
inservice
rserver host M-Old-2
ip address 1.1.8.12
inservice
rserver host S
serverfarm host A
rserver M-Old 389
backup-rserver M-Old-2 389
inservice
rserver M-Old-2 389
class-map match-any Class
2 match virtual-address 1.1.3.13 tcp eq 389
! not in use
class-map match-any L7_Class
description L7 class map for VIP-A
2 match port tcp eq 389
policy-map type loadbalance first-match A_L7_Policy
class class-default
serverfarm A
policy-map multi-match VIP-A
class Class
loadbalance vip inservice
loadbalance policy A_L7_Policy
loadbalance vip icmp-reply active
loadbalance vip advertise active
interface vlan 500
ip address 1.1.2.7 255.255.255.240
no shutdown
interface vlan 511
ip address 1.1.3.12 255.255.255.248
service-policy input VIP-A
no shutdown
ip route 0.0.0.0 0.0.0.0 1.1.2.3
ip route 1.1.8.0 255.255.255.0 1.1.3.11 (real server subnet)
ip route 1.1.7.0 255.255.255.0 1.1.3.11 (source of request)
vcp-sd-ace-1/CUR# sh service-policy
Policy-map : IDV_VIP-A
Status : ACTIVE
-----------------------------------------
Interface: vlan 511
service-policy: IDV_VIP-A
class: IDV_Class
loadbalance:
L7 loadbalance policy: IDV-A_L7_Policy
VIP Route Metric : 77
VIP Route Advertise : ENABLED-WHEN-ACTIVE
VIP ICMP Reply : ENABLED-WHEN-ACTIVE
VIP State: INSERVICE
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
vcp-sd-ace-1/CUR# sh stat
+------------------------------------------+
+------- Connection statistics ------------+
+------------------------------------------+
Total Connections Created : 184
Total Connections Current : 0
Total Connections Destroyed: 0
Total Connections Timed-out: 184
Total Connections Failed : 0
vcp-sd-ace-1/CUR# sh tcp stat
TCP statistics:
Rcvd : 822 total, 0 errors
Sent : 0 total, 0 RST flag segments
0 active opens, 0 passive opens
Connections: 0 attempts-failed, 0 established resets, 0 currently establised
the real server has nothing in it's tcp dump for the connection. The session in in SYN_SENT. The client can ping the VIP, and i can ping the real server from the context. Is it not binding (LDAP) because of something to do with NAT? It NATs by default right? and you turn it off with transparent command? The client must get the response from the VIP, not the real, for the bind to occur.
And yes, I am confused (and tired)! :)
Any thoughts?
10-18-2007 12:03 AM
one problem is your one-armed setup.
Clients and servers come to ACE on the same interface and are not directly attached to ACE.
So, the servers will see traffic from the client and will respond directly to the client as expected, but the response will bypass the ACE module which will break the connection.
Like for any loadbalancer, you need to guarantee that the response from the server to the client goes through the loadbalancer.
In your case this will be difficult because both clients and servers are remote and attached to the same interface.
You may want to move the ACE module so that it shares a vlan with the servers.
Now, the 2nd problem is that it seems no traffic is coming into the ACE module for the class-map.
There is no hit on your policy.
Again, most probably a routing issue.
I would suggest you get a sniffer trace and start sniffing in front of the ace module.
You will see that you are missing traffic.
Gilles.
10-18-2007 12:19 AM
one: Agreed, this is not the ideal set up. It is temporary until the servers are installed in the new site where my ACE is. I will need to have the remote location as backup for a while though so would like this to work. Why does the server not respond to the VIP, isn't that where it would see the request coming from?
two: they can ping the VIP. Does this not prove routing? I will look into the possibility of the port being blocked somewhere.
10-18-2007 09:21 AM
I have spanned a port on the 6509 and can see the traffic targetting the VIP on the correct port. They can ping the VIP, so routing must be OK. How can I confirm that app traffic is reaching the interface in the context? And I have confirmed that the traffic matches the class-map for the VIP, so I cannot understand what has gone wrong here.
10-18-2007 10:59 AM
Apologies for the harrassment. I have confirmed that the traffic is hitting the interface in the context:
On ACE
interface vlan 511
ip address 1.1.3.12 255.255.255.248
alias 1.1.3.14 255.255.255.248
access-group input TEST
service-policy input VIP-A
no shutdown
Before LDAP Bind attempt...
access-list:TEST, elements: 1, status: ACTIVE
remark :
access-list TEST line 8 extended permit ip any host 1.1.3.13 (hitcount=0)[0x56ef4ddc]
After LDAP Bind attempt: note it count of 6
access-list:TEST, elements: 1, status: ACTIVE
remark :
access-list TEST line 8 extended permit ip any host 1.1.3.13 (hitcount=6)[0x56ef4ddc]
I'm pretty sure it's something on the policy. are we sure I don't need to add more to the L7 Class map?
10-18-2007 11:15 AM
I have hits on the policy! The application of the access list seems to have sorted that. Now I need to put NAT on and will hope for the best.
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