Cannot create L7 Class

danger_mousie · ‎10-17-2007

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?

Gilles Dufour · ‎10-17-2007

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.

danger_mousie · ‎10-17-2007

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?

Gilles Dufour · ‎10-18-2007

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.

danger_mousie · ‎10-18-2007

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.

danger_mousie · ‎10-18-2007

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.

danger_mousie · ‎10-18-2007

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?

danger_mousie · ‎10-18-2007

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.