ACE30-MOD-k9 in bridge mode. Individual server in the same vlan of Real Servers not reacheable.

[FrancescoDellaTorre]

I configured ACE30-MOD-K9 in bridge mode and I configured a server farm with his real servers. The traffic passes and is balanced correctly between all RSERVER. But I can not contact a server that is on the same vlan of the serverpharm but doesn't belong at this serverfarm.

I Thought that the traffic directed to this "spare" server shouldn't  be balanced but the bridge should permit traffic to pass. (trasperent mode) Is it correct ?

What does ACE in bridge mode with traffic directed to servers that do not belong to any server farm but are present on the same VLAN (same bridge group)?

In rispect at the following configuration 10.10.10.168 isn't reacheable

------------------------------------------------------------------------------------------

access-list INBOUND line 8 extended permit ip any any
access-list INBOUND line 16 extended permit icmp any any

probe http HTTP_PROBE1
  expect status 200 200

rserver host RS_WEB1
  ip address 10.10.10.163
  inservice
rserver host RS_WEB2
  ip address 10.10.10.164
  inservice
rserver host RS_WEB3
  ip address 10.10.10.165
  inservice
rserver host RS_WEB4
  ip address 10.10.10.167
  inservice

serverfarm host SF_FIREGROUP
  rserver RS_WEB1
    inservice
  rserver RS_WEB2
    inservice
  rserver RS_WEB3
    inservice
  rserver RS_WEB4
    inservice

sticky ip-netmask 255.255.255.255 address source sticky-ip
  replicate sticky
  serverfarm SF_FIREGROUP

sticky http-cookie myCookie sticky-cookie
  cookie insert browser-expire
  serverfarm SF_FIREGROUP

class-map match-any VS_FIREGROUP
  2 match virtual-address 10.10.10.169 tcp eq www
  4 match virtual-address 10.10.10.169 tcp eq 8081
  5 match virtual-address 10.10.10.169 tcp eq 8082
  6 match virtual-address 10.10.10.169 tcp eq 8083
  7 match virtual-address 10.10.10.169 tcp eq 8084
  8 match virtual-address 10.10.10.169 tcp eq 8085
  9 match virtual-address 10.10.10.169 tcp eq 8097

class-map match-any VS_FIREGROUP_HTTPS
  2 match virtual-address 10.10.10.169 tcp eq https

policy-map type loadbalance first-match HTTP
  class class-default
    sticky-serverfarm sticky-cookie
policy-map type loadbalance first-match HTTPS
  class class-default
    sticky-serverfarm sticky-ip

policy-map multi-match HTTP_HTTPS_MULTI_MATCH
  class VS_FIREGROUP
    loadbalance vip inservice
    loadbalance policy HTTP
    loadbalance vip advertise active
  class VS_FIREGROUP_HTTPS
    loadbalance vip inservice
    loadbalance policy HTTPS
    loadbalance vip advertise active

interface vlan 4
  bridge-group 1
  access-group input INBOUND
  service-policy input HTTP_HTTPS_MULTI_MATCH
  no shutdown
interface vlan 700
  bridge-group 1
  access-group input INBOUND
  no shutdown

interface bvi 1
  ip address 10.10.10.150 255.255.255.0
  no shutdown

ip route 0.0.0.0 0.0.0.0 10.10.10.1

Thanks a lot

Francesco

[Kanwaljeet Singh]

Hi Francesco,

Yes, you are right. ACE in bridge mode should just pass the traffic. Doesn't look like a ACE problem. Does it work if you take ace out of picture?

Regards,

Kanwal

[FrancescoDellaTorre]

Thanks Kanwal as you said probably i Should investigate on other configuration.

Thanks

[Kanwaljeet Singh]

Hi Francesco,

Just to add more a bit, A bridge group is very similar to routed mode except ACE cannot NAT pass through traffic, vlan's cannot be shared and couple of other things but client's should be able to access the server as in before.

But also whether in bridge or routed mode, ACE does create flows and applies other security parameters if configured to the traffic. This is for security. Also, ACE should know the MAC of the device to forward the traffic to. Can you check if ACE has the MAC of the destination? You can also put a route for testing purpose and see if that resolves the issue. That should probably be the quickest way to check if ACE is creating any issue here.

Regards,

Kanwal