 |
 |
On Sep 20, 2016, at 8:29 AM, Doug McIntyre <[log in to unmask]> wrote: > > There are ways to tell which is the "active" path through the rings, as I > stated before, I think one path is mainly "active" and one is mainly passive. > I don't know if just disabling one VCP port will work. Let’s figure out of a common VCP port first. Like I said before, this ‘path’ is based on src/dst interfaces in the VC, and the selection algorithm is SPF based (but factors in actual PFE hops on each switch - internal to each switch is a PFE chip controlling a set of ports with a fabric between that is also used for VC - it’s not as simple as FPC0 -> FPC1 -> FPC2) What say: ‘show virtual-chassis vc-path source-interface ge-1/0/15 destination-interface xe-0/0/14’ (original issue of AITech to USInternet - loss evident) ‘show virtual-chassis vc-path source-interface ge-1/0/11 destination-interface xe-0/0/8’ (MNVoip to Charter - loss evident) ‘show virtual-chassis vc-path source-interface ge-1/0/15 destination-interface xe-2/0/11’ (AITech to UW Madison - no loss evident) If there is a common VCP port on the two paths where loss was evident, it’d probably be easier and less intrusive to disable that port during a maintenance window, test, then re-enable. IIRC that active path failover command is for *. 'request virtual-chassis vc-port member 1 set interface vcp-X disable' -- Andrew Hoyos [log in to unmask]