ACE 4710 service in one context breaks service in second context.

micajc · ‎12-17-2008

Before I pull out all my hair and run screaming out into the snow can I get a reality check on that's going on.

I've got a single ACE 4710 (a ft peer to be added later once his services are migrated to the new config (aka out of the admin context)

My design plan was to have critical services use DNS round robin to two virtual ip's. One to be managed by context OVIP and the other to be managed by context EVIP (odd and even respectively) Once the FT peer was added it would split the traffic roughly between the two ace 4710's so only half the traffic would see any effect from a peer failover. This is a one armed connection as the real servers are all over the place pending a network cleanup.

From my attached config you will see that I've configured an ldap service running on EVIP at 198.161.62.202. This tests and works fine including ping responses. I then add the services matching pair to the OVIP context which uses the same vlan 24 and subnet at 198.161.62.201. As soon as the ovip service is added I can no longer use the service on 202 although it still responds to vip pings. On reboot the working session moves back to EVIP and OVIP responds to the vip pings but doesn't respond to the tcp session. This looks like some kind of ACL clobbering going on between contexts which to my understanding should each have their own virtual interface to vlan24 and so should be isolated.

Any help would be appreciated.

ttyl... Mica

raulgomez101 · ‎12-17-2008

Check the Access List on the EVIP context. It doesn't exist.

When the new Context comes inservice, the ACE will block the traffic going to EVIP.

RG

micajc · ‎12-17-2008

Did that and found the acl from EVIP disapeared. Recreated the acl. Both services worked..

write mem on both contects (console only) and a reboot now EVIP works and OVIP has disapeared. (responds to management ip only)

Checked the acl's again, it's still there but doesn't seem to be working. removed and recreated the acl and access-group entries on OVIP. Still not working.

The disapearing acl I can blame on the web interface but I still seem to have some underlying problem.

Gilles Dufour · ‎12-19-2008

do a 'show np 1 access-l trace ...' with src your client and destination the vip that fails.

You will see in the output something like vserver: 0x...

Then do a 'show cfgm internal table l3-rule' and identify the vserver with id found previously.

You should get a class-map id and policy id.

You can then use 'show cfgm inter table class-map' to see if it corresponds to what you have setup.

Virtualization is a concept that exists in the config but not in the forwarding engine (IXP). So, there could be a mixup of data between config and forwarding engine.

The test above should give you the config as seen by the forwarding engine.

Are you running A3(2.x) ? or something below ?

G.

micajc · ‎12-19-2008

Cisco support found the answer for me.... The way the network is implemented vserver's do a gratuitous arp as soon as they are alive. If they come up before the ports in channel are in forward mode this arp stays in virtual land in the ace and no one can see the new ip until another arp occurs. One context vip consistently arp'd before the link was ready and the second after. The fix is to do one of two things...

a) enable port fast on the switch

b) set the carrier-delay on the physical interfaces.

In my case we set the carrier-delay to 60 and my issues went away.