basic L2 bridge troubleshooting ACE

[csco10387876]

Hi,

I have a strange behaviour on new ace module :

I have a Dmz in bridge mode, I have installed a server on it with a simple web server, I first try to simple connect to this web server just being bridge between client and server.

Sometimes it works just fine, sometimes the tcp connection to 80 doesn't work.

When it doesn't work, the ACE does a icmp echo resquest to the source using it's IP.

The ping always works well.

Do you see anything in the config that is wrong or that I shoud add ?

here is the config :

interface bvi 1

ip address a.a.a.a 255.255.255.224

peer ip address a.a.a.b 255.255.255.224

description Bridge address for Dmz

no shutdown

interface vlan 454

bridge-group 1

no normalization

mac-sticky enable

no icmp-guard

access-group input Any

service-policy input PM_MM_454_VIP

service-policy input TCP_Connection_Timeout

no shutdown

interface vlan 554

bridge-group 1

no normalization

no icmp-guard

access-group input Any

service-policy input TCP_Connection_Timeout

no shutdown

Thanks

[Gilles Dufour]

the ace needs to know about a mac-address to allow a connection to be passed through.

If the arp entry for a learned entries timed out, the connection can't be accepted.

Normally, the echo request is there to populate the arp table when the mac-address is missing.

The CSM had the same behavior.

This is why I always recommend to have the clients behind a router/firewall/gateway and configure a static route on the ACE pointing to this gateway/router/firewall.

Like this the src mac is always a known mac-address.

Gilles.

[csco10387876]

Hello Gilles,

If in a context you have many bridge group, how can you configure a route for each ?

on the csm, there was the gateway command, I though here the mac-sticky replaced that.

here is the arp table on the context :

85.91.161.65 00.50.5a.5b.a1.41 vlan454 LEARNED 17 9121 sec up IS the DG

85.91.161.70 00.08.02.94.9d.27 vlan554 LEARNED 24 9121 sec up Is the server

I tried now and even if the mac is in the arp table it doesn't work.

I have upgraded the blade to 3.0.0_A1_6_3b

I will look at the arp table when it works.

And here I am simply trying to connect to the server, there is no service defined on the ACE for LB and ICMP is sent to the server correctly.

Also the mac address table doesn't change even if it works for someone else.

so PC1 - server on port 80 ok

pc2 - server on port 80 nok

and then for no reason it doesn't work anymore for the first too.

Thanks,

Luc

[Gilles Dufour]

Luc,

I just based my comment on your comment that when it doesn't work you see an icmp echo request from ACE to the client.

This is an indication that the mac-address was missing from the arp table.

In your examplem PC1 could work and not PC2 if one has its mac-address already in the table and the other one not.

It does not matter if you hit a vip or just want to go through.

ACE will have to setup a flow and for that the arp table needs to contain the src mac.

You can check with the command

switch/Admin# sho np 1 me-stats "-socm" | i mac

Drop [mac lookup fail]: 92 0

switch/Admin#

if you had any failure due to missing mac.

Regarding the static routes, you can have up to 8 routes to the same destination.

mac-sticky is there to select the best route. But you first need the routes.

Gilles.

[csco10387876]

here is the output

AcePR/DmzSmals# show np 2 me-stats "-socm"

OCM Statistics: (Current)

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

Connection create received: 4909 0

LB dest decision received: 1823 0

OCM Packet count (Hi & Lo): 6732 0

(Context 1 Statistics)

Drop [mac lookup fail]: 35 0

Connection inserted: 2992 0

Packet message transmitted: 214 0

there is some drops, but the counter doesn't increment when we try.

as the clients are not on the same network, the only mac it sees is the mac of the firewall.

it would be nice if we could define a gateway on a per bridge group basis.

[csco10387876]

Gilles,

Just for the sake of it I added the route :

route 0.0.0.0 0.0.0.0 85.91.161.65

I still can't connect most of the time to the server and get the icmp request back (droppped by the fw).