Logical Interface VLANXXX does not go down

[philg]

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.

[bsivasub]

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.

You may need some dynamic routing

[lrian]

At one time even if all of the L2 ports were down the vlan interface would not go down if that vlan was also on the sc0 interface.

Dunno if that bug was ever fixed or not...

[j.chenevey]

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.

[philg]

Thanks very much for your consideration. Check out the following bug CSCdp62432. I believe this is what I am experiencing, you might be also.

[j.chenevey]

Just found this too: CSCdp62432 MSFC autostate needs enhancement in dual MSFC configuration.

Bug Release notes: Autostate is a mechanism whereby the MSFC''s vlan interface will be down,down

if there is no physical port associated with that vlan.

With the current release of software if you have two MSFCs in a dual-supervisor

configuration, the vlan interface on the MSFC will not go down when there is

no FE/GE ports tied to the vlan, since the other MSFC port is considered as

a physical port. The breaks ''MSFC autstate'' in dual MSFC configuration.

The next release (5.4.2) of software will have a fix by checking to see if

the last port in a vlan is that of a router port and if yes, it will bring

the vlan interface down.

[bairdj3]

Hello,

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.

Hope this helps!