Hi, This is correct; you cannot have the VIP and real using the same IP in the config. This will be seen as a Dup IP from the ACE perspective since it owns the VIP IP. How you do this is to configure the server with a unique IP from the subnet configured on the ACE server vlan. This is what you use to define the real in the config. The server IP needs to be L2 adjacent to the ACE for this to work. The transparent keyword tells the ACE to just L2 forward the traffic to the Mac address the real resolves to, but keeps the vip IP as the destination. This is why the server needs to be L2 adjacent to the ACE so that it can see the REALs actual mac address.  Without the transparent keyword we NAT the VIP address to the REAL that gets the connections. You will also need to create a loopback IP using the same address as the vip on the server. The reason you need to use a loopback IP is so that the server does not arp for this address. You do not want the server to advertise that it owns this address since it is already assigned to the ACE VIP. The link below is for IOS server load balancing but the loopback samples are still relevant. http://www.cisco.com/c/en/us/support/docs/routers/7200-series-routers/10567-37.html#topic1 I hope this information is helpful Best regards Jim ... View more

Rick, I think you have it backwards class-map match-any L4-CLASS-TESTPOC-validate   10 match access-list ACL_name class-map match-any L4-CLASS-TESTPOC-SSL   10 match virtual-address 5.5.5.5 tcp eq https policy-map multi-match CLIENT-VIPS   class L4-CLASS-TESTPOC-validate       loadbalance vip inservice       loadbalance policy TESTPOC-SSL-POLICY       loadbalance vip icmp-reply       loadbalance vip advertise active       nat dynamic 251 vlan 555       appl-parameter http advanced-options TEST_HTTP_MAP       ssl-proxy server TEST_POC_SSL_PROXY L4-CLASS-TESTPOC-SSL       loadbalance vip inservice       loadbalance policy TESTPOC-SSL-VALIDATE_DROP-POLICY       loadbalance vip icmp-reply       loadbalance vip advertise active       nat dynamic 251 vlan 555       appl-parameter http advanced-options TEST_HTTP_MAP the idea is if you are one of the ACL matches you are allowed to use the /login/validate url. the original l7 class allowed this so you would put this under the match on ACL. The new loadbalance policy has a match for /login/validate but rather than sending it to a serverfarm the ACE will just drop this. This is just to make sure that if a non-approved IP tries to hit this URL they fail. Does that make it clearer? Thank you Jim ... View more

Rick, What about just using two different class-maps. the first one would match on an ACL for the specific users that you want to hit the login/vlidate page. build out the ACL and  create the class-map to match on. access-list ACL_name extended permit tcp host x.x.x.x host 5.5.5.5 eq tcp 443 Add all of the approved IPs to this list. class-map match-any L4-CLASS-TESTPOC-validate   10 match access-list ACL_name Add the L7 policy under this class. Then have your existing class-map placed under the one above in the muilti-match policy. class-map match-any L4-CLASS-TESTPOC-SSL   10 match virtual-address 5.5.5.5 tcp eq https and under the L7 match for validate you can just drop the traffic rather than sending it to a serverfarm. policy-map type loadbalance http first-match TESTPOC-SSL-VALIDATE_DROP-POLICY   class L7CLASS-login-validate     drop class L7CLASS-login     sticky-serverfarm TEST_POC     action URLREWRITE   class L7CLASS-MYHOME     serverfarm APPSRV_30450_POC     action URLREWRITE The class-map matching on the ACL would be hit first. If the user is one of the allowed IPs in the list it will match and they can get to the loging/validate page, or anywhere eles. If they are not one of these users they drop to the next L4 class (the existing one) and this time if they try to go to the login/validate page the ACE will just drop it. they can go anywhere else but this page. This way you do the matching on the L4 class and  not in the L7 policy. L7 policy is just to inforce that that non approved IPs will get dropped if they try to hit this page. could this work for you? Best regards Jim ... View more

Lubomir, Can you provide some samples of what the incorrect URLs would look like as well as correct ones? You are correct that we can instruct the ACE to ignore some characters in a string but the rest of the regex must still match exactly for the class to be hit. Regards Jim ... View more

Lubomir, Unfortunately I cannot think of a way to do this. Anything that does not match your L7 class-maps will be sent to class class-default. Unless you can come up with some kind of regex match that will cover all possible incoirrect URLs I do not really see how this could work. Best regards Jim ... View more

Lubomir, It sounds like what you need is to create the L7 class-map to match on the correct url and loadbalance this to the serverfarm. Then in this same L7 policy use class class-default to redirect all other URLs to the correct location. Hope that helps Best regards Jim ... View more

Not all versions of code may display the reason for the config sync failure. I would first verify that all certs and keys are the same on both modules. This is the most common reason for this issue. If they are the same the next step I would take is to compare the two running configs to see if there are any differences. You can use a tool such as winmerge to compare. If you find any differences manually configure them to be the same and try the sync again. Regards Jim ... View more

Depending on how your class-maps and sticky groups are configured enabling persistence-rebalance could have an effect on the app. for instance let’s say you have two class-maps using two different sticky groups for both. A new user hits the vip and the first get request matches class-map 1. Since there is no sticky entry the ACE makes a LB decisions and picks server 1. A sticky entry will be created for this user. Get number 2 on the same tcp stream now matches class-map 2. If this class uses a different sticky group you would not have a sticky entry for this user and a new LB decision will be made. Even if you have the same physical servers in the farm if the sticky group is not the same it would create a new sticky entry but this time you could get sent to server 2. Did this work before you enabled persistence-rebalance? Can you provide the config you are using that is giving problems to see if this may be the case? Thank you Jim ... View more

Ryan, Are you using sticky for this traffic? If so that would explain why the newly added server is getting less connections than the ones that are already inservice. Regards Jim ... View more

Tony, Since the servers are local and pointing their default gateway at the ACE there should be no problem with this communication. I see you have an ACL applied to both interfaces named ALL-IN. If this is allowing all IP traffic then the config and topology are correct. If traffic is not working correctly between these hosts I would first confirm the default gateway of the servers is correctly pointing at the alias of the ACE interface. I would then confirm if the traffic leaving the server is using the same MAC address as the ACE shows in the "show arp" output. If the servers are using active active NIC teaming or some sort of clustering the MAC address that is being sent at the ACE may not be the same as what the ACE has learned for this device. If the MAC does not match the show arp mapping then this is the issue. The ACE needs to know the MAC address of each device that is forwarding traffic to it. If this is the case you could try configuring a static arp entry matching the MAC that the server is using. Regard Jim ... View more

Tony, Can you share your config showing interface vlan and IP routes? Also let me know what IP each of the servers in the two subnets are pointing to as the default gateway. I want to confirm I understand your topology correctly. Regards Jim ... View more

Tony, Are all of the servers Layer 2 adjacent to the ACE and if so do the servers use the ACE as a default gateway? If this is the case you really should not have to do anything other than creating an ACL to allow the traffic and apply the access-group to the interfaces. The ACE will see that the destination server is local and will route the traffic to the correct device. If the servers are not using the ACE as the default gateway and you have another L3 interface on these vlans it may be a bit trickier to get communication to work though the ACE depending on the traffic flow. Regards Jim ... View more