ACE30, bridging using default gateway

[csco10387876]

Good afternoon,

I have a strange behaviour with some ACE30 running A5 release :

Setup is in bridge mode, working correctly with a default gateway set in the context.

For some reason, some return traffic is being routed on the ACE instead of being bridged.

On what conditions would the ace decide to route the traffic of simply bridge it from the server vlan to the client vlan.

Regards,

Luc

[chrhiggi]

Hello Luc!

  ACE's default behavior is seperated into 3 delineations:

  1.) Traffic passing through the ACE.

     - For this type, any traffic recieved on a bridged VLAN will be forwarded to the other vlan in the bridged pair.

  2.) Traffic going to a VIP IP.

     - For this type, any traffic recieved that is destine to a VIP IP is routed. Meaning... the SYN,ACK reply we need to send to the client is checked against our route table. We send the packe to the gateway, or L2 client IP.  You can also enable "mac-sticky" under the ingress interface the client SYN was recieved on.  With that enabled, the route lookup for the SYN,ACK is ignored. Instead, the packet is sent back to the MAC address the SYN sourced from.

  3.) Traffic initiated to or from an ACE interface IP.

     - For this type, ACE uses the route table.  This would include any telnet/SSH/XML sessions to ACE's interface IP for management. As well, Probes, DNS lookups, CRL lookups, FTP/SFTP downloads, etc.

Regards,

Chris Higgins

[csco10387876]

What is strange, is that the traffic is not initiated from the servers, and we have mac sticky enable on the interface.

We will isolate routed VIPs in another context to avoid side effects like this but I still would like to know the cause of this.

Regards,

Luc

[chrhiggi]

Can you send the configuration and an example of IP addresses (*bonus if you can attach a trace file)

Chris

[csco10387876]

interface vlan 337

  description Vip Lan

  ip address 10.32.5.4 255.255.255.0

  peer ip address 10.32.5.5 255.255.255.0

  no normalization

  access-group input Any

  nat-pool 1 10.32.5.254 10.32.5.254 netmask 255.255.255.0 pat

  service-policy input L4_LB_VIP_337

  no shutdown

interface vlan 171

  bridge-group 17

  no normalization

  mac-sticky enable

  no icmp-guard

  access-group input Any

  service-policy input Administration

  service-policy input PM_MM_171_VIP

  no shutdown

interface vlan 173

  bridge-group 17

  no normalization

  mac-sticky enable

  no icmp-guard

  access-group input Any

  no shutdown

what we see is the a server in vlan 173 has return traffic getting droppped on the first firewall next to vlan 337

what is even more strange is that the user isn't complaining....

On the context we used to see 100K concurrent connections, nows that we migrated the routed services to another context we are at 1/10 of the connections

sadly no capture as we migrated the services.