6880 in VSS Mode and OSPF maximum paths

Question

Hi Folks,
I have an issue observed in testing.  We have implemented a VSS solution on the 6880-X-LE.  We have two MEC L3 PO's upstream and thus two OSPF path's for our default route.  After creating an event in the lab to put the boxes in Active - Active (pulled VSL links off SW1) and then go through the process of restoring the VSS (put VSL links back in) I noticed my additional path did not restore.
From the restoration perspective, it went as follows:
Sw1 - Active SW2-standby - pull VSL links
VSL PO goes down
SW1 - Active SW2 - Active (sub second traffic impact)
SW1 - enters recovery mode SW2 - Active
VSL links back in  - VSL PO up
SW1 - reboots and comes up standby SW2 - Active
Routing table now only shows entry for PO200 and no routes can go out PO100.
6880#sh ip route
<cut>  
0.0.0.0/0 [110/1000] via 192.168.0.253, 00:38:34, Port-channel200
      1.0.0.0/24 is subnetted, 2 subnets
O        1.1.1.0 [110/151] via 10.86.50.253, 00:31:55, Port-channel200
O        1.1.2.0 [110/151] via 10.86.50.253, 00:31:55, Port-channel200
      192.168.0.0/16 is variably subnetted, 59 subnets, 8 masks
O        192.168.1.0/25 [110/150] via 1192.168.0.253, 00:31:55, Port-channel200
O        192.168.1.128/25 [110/350] via 192.168.0.253, 00:31:55, Port-channel200
O        192.168..3.0/25 [110/350] via 192.168.0.253, 00:31:55, Port-channel200
6880#sh ip ospf ne
Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.0.253     0   FULL/  -        00:00:31    192..168.50.253    Port-channel200
192.168.0.251     0   FULL/  -        00:00:32    192.168.50.251    Port-channel100
Can anyone help? 
Thanks,
Rash

Answer 1

Hi Reza,
I can't post the configuration. However, I can tell you that I have a TAC case open with Cisco and they agree with me that this behavior requires further investigation.  So the "PO" in question disappears seems to match when I get the error related to the a port-member not being compatible:
Jan 26 15:18:17 est: %EC-SW2_STBY-5-CANNOT_BUNDLE2: Te2/3/14 is not compatible with Te1/5/14 and will be suspended (speed of Te2/3/14 is 10G, Te1/5/14 is 1000M)
So what happens is that in PO100 you'll see only one bundled port and the other is suspended.  This causes OSPF to withdraw the PO from the routing table (hypothesis but reproducible).  
In our trial production launch, I performed the same test above redundancy force-switchover and you'll see both entries in the routing-table. Once the other modules come up and I get a suspended port-member that particular PO disappears from the routing table. 
If you shut/no shut that PO, the PO returns as an available path in the routing table.  In production we are not using GLC-T (as in the lab) but are using GLC-SX-MM.  The bug that puts this member into a suspended state falls under the this bug id:
CSCur17071
What I missed initially is the fact, that the routing table removes that PO from being an available path even though it still has an active port-member.
Cheers,
Rash