08-06-2011 05:26 PM
Hello,
I have two 6509 switches with ACE modules installed and configured as active/standby. There is no FWSM installed, so MSFC shares a common subnet with the external interface of ACE. On both MSFCs, I can see the static route injected (RHI) by ACE. However, those routes are different. On the MSFC hosting the active ACE, the next hop of the static route installed is the alias IP address of the external ACE interface. On the MSFC hosting the standby ACE has the next hop as the IP address of the external interface of the standby ACE not the alias.
This causes a problem when traffic is routed through the second MSFC where it will send traffic destined to my VIP to the standby ACE causing traffic to be dropped.
Why this behaviour happens? I started to see this behaviour after a sudden reboot on the standby ACE. Before that, I am not sure what was the route injected into the second MSFC but I had no problem with my VIP.
Can anyone help me how I can tell the second MSFC to route traffic towards the alias instead of the interface IP?
Thanks.
Solved! Go to Solution.
08-11-2011 12:46 AM
The TAC case is resolved. Posting back to the community so the solution can be shared with a wider audience.
Thanks to Mohammed for keeping outputs of troubleshooting at the time of problem, it was found that after the standby ACE rebooted, BOTH the active ACE and standby ACE were injecting the host route to the VIP, this is not expected behaviour. The expected behaviour is for the active ACE to inject the host route with the ACE alias IP as the next hop, and the standby to not inject the route.
This problem is due to a software defect CSCsx67908 "When you configure ACEs for redundancy and Route Health Injection (RHI) and the standby ACE reboots, duplicate RHI entries can exist on the supervisor."
Software fix integrated is available. There is also workaround by a "FT switchover" on the ACE.
Another workaround by routing is to disable RHI for the VIP, and instead advertise the VIP subnet by routing protocol on the switch supervisor (eg, advertising the connected Vlan via EIGRP, OSPF, etc...).
RHI of the VIP is not enable by default, and can be disabled with the following from ACE:
policy-map multi-match XYZ class ABC no loadbalance vip advertise active
More info on RHI can be found here:
Regards,
Simon
08-07-2011 11:05 PM
Hi Mohammed, I am already working with you on a TAC case on this issue, and noticed you've started this thread. I'll post out the resolution when our TAC case is resolved.
Regards,
Simon
08-11-2011 12:46 AM
The TAC case is resolved. Posting back to the community so the solution can be shared with a wider audience.
Thanks to Mohammed for keeping outputs of troubleshooting at the time of problem, it was found that after the standby ACE rebooted, BOTH the active ACE and standby ACE were injecting the host route to the VIP, this is not expected behaviour. The expected behaviour is for the active ACE to inject the host route with the ACE alias IP as the next hop, and the standby to not inject the route.
This problem is due to a software defect CSCsx67908 "When you configure ACEs for redundancy and Route Health Injection (RHI) and the standby ACE reboots, duplicate RHI entries can exist on the supervisor."
Software fix integrated is available. There is also workaround by a "FT switchover" on the ACE.
Another workaround by routing is to disable RHI for the VIP, and instead advertise the VIP subnet by routing protocol on the switch supervisor (eg, advertising the connected Vlan via EIGRP, OSPF, etc...).
RHI of the VIP is not enable by default, and can be disabled with the following from ACE:
policy-map multi-match XYZ class ABC no loadbalance vip advertise active
More info on RHI can be found here:
Regards,
Simon
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide