We have a situation where a 6509 with dual MSFC's is acting as LAN core connected to an 8510 that acts as a WAN distribution router. We have two physical connections, two logical interfaces(int vlan991 and int vlan992) and two static default routes pointing to the 8510. (load balancing per packet). Our problem is that even when one of the physical connections to the 8510 is broken, the logical interface on the 6509 does not go "down". We end up losing half of our traffic. Thanks in advance for considering our problem.
vlan interface would go down if the last of the L2 port in that vlan goes down. Are you sure there is no ports which are in connected state in those two vlans. Remember trunk ports are ports in that vlan.
I think we are experiencing this scenario as well and are busy researching it. We have not had a chance to test any of our scenarios but this is what I'd propose:
Essentially, the static route is not being removed from the route table when the physical interface goes down. Since the logical interface is UP/UP, once the static route is in the route table and the 6500MSFC has the MAC address of the 8510 in its router arp cache, the msfc will continue to use forward traffic to that destination until the entry for the 8510 gets removed from the arp cache (default arp aging is 4 hrs).
I still don't know why interface remains UP/UP but if there is another port on your 6509 that is forwarding on that VLAN, the logical interface will remain UP/UP. However, if you the the VLAN is point-to-point between 6509 and 8510 only, then I don't know yet if this could be a bug.
I have found only one possible solution thus far: on Cat6500 issue command "set msfcautostate enable". Switch command description reads, "This feature is useful for discontinuing the advertisement of routing paths when access to them is severed (either through fault or administrative disabling).
When you enable msfcautostate, VLAN interfaces on the MSFC are active only when there is at least one other active interface within the Catalyst 6000 family switch. This interface could be a physical end-user port, a trunk connection for which the VLAN is active, or even another MSFC with an equivalent VLAN interface." I believe you have to be running at least 6.2 code on the Cat to have the command available. Let me know if this resolves your problem.
The default behaviour is that as long as there is an *active* port on the switch which belongs to the vlan for which the VLAN interface is defined the VLAN interface will NOT go to a 'down/down' status which results in poor or no Layer 3 failover.
The *active* port may be a port which is assigned to a VLAN or a port enabled with Frame Tagging (i.e. dot1q/ISL) which is NOT pruned. By default *trunks* are members of all VLANs.
In terms of Layer 3 failover using a dynamic routing protocol (like OSPF) the forwarding table will NOT be updated until the Neighbor Adj. times out, as opposed to immediate notification to the routing protocol by an interface going *down*. For that timeout period data may be routed into a *black hole*.
When configuring the statics you want to include both the outgoing interface and the next hop address. This may assist in proper failover.
Ideally you should make sure that all *trunk* ports are pruned accordingly so that Layer 3 failover is not comprised.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...