ACE 4710 service in one context breaks service in second context.
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 22.214.171.124. 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 126.96.36.199. 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.
Re: ACE 4710 service in one context breaks service in second con
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.
Introduction This article will help you understand the steps on how to
download the UCS licenses from the Cisco Systems website and then
installing it on the UCS. The redacted (blue lines) just covers up
certain numbers for privacy please do not take them...
Introduction This article will help you understand and educate the
customer on how to clear their "expired licenses"
(license-graceperiod-expired) from their UCS-M. If a customer just
purchased a license and needs a step by step guide on how to download
==================== VIC FNIC driver does not support Virtual Volumes (
second level LUN ID ) An enhancement request has been created to track
this feature - CSCux64473 UPDATE - 12-14-2016 We made some traction on
the enhancement request - The Fix is in t...