ACE - ICMP Client ---> Server VLAN

Roble Mumin · ‎11-03-2006

I am still trying to get the idea why it is not possible to get some ICMP replys from the ALIAS of the server VLAN when requesting the echo coming from the client side.

The ICMP and also the traceroute works great with the inspection of ICMP for RSERVER -> Server VLAN -> Client VLAN -> OUT.

The problem or issue is only when you try to get echo replys from the Server VLAN Alias and it's according ip and peer ip addresses.

Funny thing is one of the interface addresses answers. In a context A it is the "ip address" and in a context B it is the "peer ip address".

Kind off questions my sanity here. :)

My inspection rules are applied to the client vlan's or transfer network interfaces whatever view you prefer and work so far as intended.

Any idea Gilles?

Roble

Gilles Dufour · ‎11-03-2006

could you share your config and tell me the source ip address of the ping and what destination works and do not work.

Thanks,

Gilles.

Roble Mumin · ‎11-03-2006

Sure, took me a while to sanitize the config though.

Maybe i got something wrong if you see any major f'up's let me know.

Source IP is behind 2nd layer 3 device. Let's call it the admin vlan. The ICMP works inside the context btw. if i am in context Test or QP2 and ping the 3 ip's (alias,ip and peer ip) it works.

RSERVER -> Server Vlan alias,ip and peer ip ICMP works also.

And thanks for reading.

Roble

PS: Context QP2 is currently configured for connectivity only but will become more or less like context Test for productivity enviroment.

Roble Mumin · ‎11-10-2006

Any idea about that issue?

Gilles Dufour · ‎11-12-2006

the ACE module does not allow routing accros context. So, if you try to ping from a device in context Admin the ip address of ACE or any other device in another context, it won't work unless the routing between the context is down by another gateway.

Gilles.

Roble Mumin · ‎11-13-2006

I see, but i also have the same beahvior when routing inside a context.

Have a look at context "Test" config. It has a client side vlan (444) and a server side vlan (555).

The communication path for my ping looks like below.

MyWorkstation <-> L3 Device <-> Context Test (Vlan 444) <-> Context Test (Vlan 555) -> ip, peer ip, alias

As you can see i am staying inside the context test just passing the packet coming from the vlan 444 to an ip address inside vlan 555. So this should work.

I am not talking about following communication path which can't work regarding you're statement above.

Context Admin (Vlan 444) <-> Context Test (Vlan 444) <-> Context Test Vlan (555)-> ip, peer ip, alias

Roble

Gilles Dufour · ‎11-13-2006

is it just the ping that does not work or any other type of connection fails ? Like telnet ?

Did you try to remove the icmp inspect from the service policy ?

Did you capture sniffer trace on vlan 444 and 555 to see if the request is droped or the respone and where.

Thanks,

Gilles.

Roble Mumin · ‎11-13-2006

It's only the ping that fails. The features i configured are working as intended (LB,SSL, inspection etc.). I just try to understand why it behaves like that.

And regarding sniffer traces you are a bit out of luck with the ACE currently. I haven't been able to capture any traffic from the ACE so far either with RSPAN or the ACE "capture" equvivalent. But that seems to be a bug if "CSCsf27442" is right.

You have an idea when to expect a new SW release for the ACE?

Roble

Gilles Dufour · ‎11-14-2006

next software release is in december.

For the span, I was suggesting to sniff vlans - not the ACE Te interface.

Since only ping are failing and you have configured icmp inspection, could you try to disable it and see if that makes a difference.

Gilles.

Roble Mumin · ‎01-09-2007

Managed to upgrade the modules to A4 today.

The beheavior is now more consistent which means that none of the ip,peer ip and alias of the according server side vlan replies to a ping. It leaves me with the feeling that the previous behavior was a bug.

For troubleshooting reasons it would still be nice to figure out if you can change that behavior in the future. Checking the server side gateways from the client side via simple icmp messages (works the other way around).

Roble