future of clustering & mct

[inphobia]

tl:dr: does mct have a future or is it getting phased out.

heya,

we recently got 4 7850's to replace some aging cisco nexus's, they won our public tender easily & specs are impressive. we are a heavy user of vpc on the nexus side, but replacing this with mct has proven to be a challenge. our tender specified as minimal feature l3 redundancy for ipv6, so we're bound to 10.0.10 or higher.

we also required link bundeling over 2 devices running independant operating systems while presenting themselves as a single device to the other end: which mct (multi chassis trunking) provides.

finally, pvrst needed to be supported on all links.

which is when the fun started as any vlan that becomes an mct vlan disables stp. both our partner & their ruckus liasons always came with examples from the 8.0.95 docs ( https://docs.commscope.com/bundle/fastiron-08095-l2guide/page/GUID-F20E9DED-FCDA-4C3C-BBC7-19127E9E1... ), in specific the last 2 mct chapters. those are notably abcent (with good reason i guess) from 10.0 docs.

in the end i got a config working with mct + pvrst when using stp in "single" mode. while not what we intended it can be argued that this meets the minimum reqs detailed in our tender.

my current view of mct is not really possive after all this. documentation for the 10.0.x train as it stands is quite inconsistent, troubleshooting pretty barebones, created quite a few inconsistent (different stp protocols, differing vlans, etc) mct's which still got accepted, snmp support for mct also seems to have gotten lost somewhere along the way, issu for clusters seems to talk about stacks instead. our partner also let slip they only had 1 client which used mct & tried to push us to going for a stack instead.

however, i'm running out of time & need to get these in production. since our partner has been excellent in other projects they won i don't want to return these switches due to being non complaint (since i already sent back the 8200's due to no redundant&hot swap fans & psu's - at least the model they proposed) and as noted above mct in 10.0 seems like it can use some love: i'll be going for stacking instead of clusters.

long intro , now to the question: what's the plan for mct? from what the rumormill told me 10.0.x was a major rework of the code make it less complex going forward. is mct low in the todo queue (for whatever reason), is a replacement in the works, is it being phased out? i started this project on 10.0.10a, used each release including cd versions up until the 10.0.20 i'm on now, but the release notes are silent on mct items.

all that said: kudos to the ruckus support staff. this might be the second time in 20 years that support was lightning fast to respond, actually knew the products they support, had frequent & to the point feedback. and actually got the bugs resolved.

(this was fun: "ping vrf tstix 10.40.69.252 source 10.40.69.2532" - and 2532 is not a typo - case 01631172)

[inphobia]

side note: should i get some kind of autoreply from #ruckus-docs@commscope.com ?sent a partial draft by accident 3 hours and the complete one 1 hour ago, but nothing yet.

failed to follow up on the support email not working a few months ago, have been having health issues. will poke them as per your suggestion.

[Chandini]

Hi Inphobia

With regard to MCT support for SNMP let me check internally . For your existing code if Traps are supported or not you can check using command "show snmp server" command.

I did check MIB reference guide for 10.0.10 version but was unable to find MCT related OID's which can be used for polling so I suppose it might not be supported for now but let me validate it internally.

• https://support.ruckuswireless.com/documents/4468-fastiron-10-0-10-ga-mib-reference

Thanks