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)

[Chandini]

Hi Inphobia

Thank you for reaching us

From the details shared I suppose the reason you are choosing to go with 10.0.10 version for 7800 series is the L3 IPV6 redundancy feature correct ?

Are there any other specific features you are looking for on version 10.0.10 ?

I would need some time to check on this and revert back to you. Could you please let me know if you already have a case logged with regard to the concerns you have ?

Thanks 

[inphobia]

well, 10.0.0 was the first version with vrrp-e support for ipv6 iirc. and since 10.0.0 & 10.0.0a were pulled 10.0.10 is the very minimum.

second reason was to have a shared version with the 8200's we also got (but these will be swapped out for 7550's or 7650's) our 8200's had a fixed fan & psu which was not compliant with the tender (partner did not specify the submodel, just said the complied with hot swap psu & fans). we just needed some copper ports, no poe even (to replace some cisco fex extenders). wording was something like "24 copper rj45 ports must also be included with every core switch - this can either be in a fixed version with ports included in the core switch, or via transceivers in the core switch, via extender technology like cisco fabric extenders, or via standalone switches. link bundling to 2 of these devices must be possible by presenting a single identity (read: mct cluster or stacking). if you want more details feel free to contact me via email.

this was ofcourse with with an mct setup in mind so both cluster members could do l3 forwarding at the same time without resorting to the icl. in a stacking setup i need to see how the packet flow goes on icx's.

the upside of a stack is that i don't need to do fancy tricks to get l3 redundancy (atm i'm running 2 cisco nexus clusters, 2 switches each - and 4-way hsrp (active, passive & 2 "listen" instances).

from the docs it also seems that the ssh algo's in 8.0.95 are ancient. on top "configuration archiving" was also a minimum requirement which i think was added somewhere in version 9.

for all the mct stuff i haven't logged a ticket but we turned to our partner (which in turn got in contact with ruckus) if you want i can provide more background, but not on a public forum.

as for other cases, i still have 4 open:

01653096	P4	2024-03-01	Defect - Pending Fix	cfg-archive confused by timezone
01632265	P3	2024-01-29	Defect - Pending Fix	"ip show-subnet-length"vs "management access"
01631172	P2	2024-01-26	Defect - Pending Fix	ping with source option looses last decimal
01595393	P3	2023-11-27	Defect - Pending Fix	very minor: typo in license command

only one that bothers me, but can be worked around, is the ping one. the others are mostly inconsistent behaviour.

i also often come across errors in the documentation. the first page of every guide contains

Document Feedback

RUCKUS is interested in improving its documentation and welcomes your comments and suggestions.

You can email your comments to RUCKUS at #Ruckus-Docs@commscope.com.

and my email got rejected due to not being a "valid sender". that problem should have been resolved, but then i got some personal health issues and failed to follow up.

being a first time ruckus customer i read all the docs for 10.0.10, but imo these could have used more proof reading. you will find quite some references to "layer 2" & "switch" images in the 10.0.x docs while this was phased out.

what kinda annoyed me was that some of the config snippets plain don't work (great example is how often you find "interface ve x" under vlans, which no longer works)

https://docs.commscope.com/bundle/fastiron-10010-l2guide/page/GUID-AFBE4180-6427-4A06-9B45-95DAEB85C...

vlan 5 name session-vlan by port
 tagged lag 15 
 interface ve 5

 in reality on 10.0.20 this isn't possible:

SSH@campus-core1#conf t
SSH@campus-core1(config)#vlan 3000 name Session-VLAN by port
SSH@campus-core1(config-vlan-3000)#interface ve 3000
SSH@campus-core1(config-vif-3000)#

(changed context instead)

SSH@campus-core1#sh run vlan 3000
vlan 3000 name Session-VLAN by port
tagged lag 1
!

that and the examples just plain not making sense, easy example is

https://docs.commscope.com/bundle/fastiron-10020-l2guide/page/GUID-450791B9-1E96-45D4-8DF4-68C017B82...

why does "dist-b (r4)" in the picture define p1/1/5-6 as going to both dist-a & aggr-a? not to mention that the subpages with the configs almost never match that picture.

as a new customer i have to admit this annoyed me. i manage a lot of different operating systems, making a context switch to the ironware approach; with it's own take on cli interaction but mostly how you assign ports to vlans instead of vlans to ports as well a the spanning tree approach; did take a while. and when trying sample configs snippets from the docs which then don't work...

on a personal level i enjoyed the "challenge", on the professional side my project slipped by a few months & i have to write extra documentation because of what i mentioned.

none of this mentions the strengths of ruckus: the code is under very active development with frequent releases, licenses can still be installed locally & are perpetual, transceivers aren't vendor locked.
support team is top notch: couldn't believe i got contacted within 10minutes after reporting a P2 (that should have been P3 according to the tiering guide).
and very specific: 7850-48f was a perfect fit to move from 10gbit to 25; while also offering enough 40gbit ports for our devices that are 10/40 only. bonus points since those ports are 40/100, which should suffice for 3-4 years at least.

[Chandini · Accepted solution]

Hi Inphobia

Thank you for reaching us.

I was able to check about MCT and it is not going to be phased out and would be part of future releases for supported models.

With regard to the problem you were facing about sharing feedback with the Ruckus Documentation team using email ID #Ruckus-Docs@commscope.com has been fixed

I suppose you logged a case with the team with regard to the same. You can always feel free to share your feedback on email ID #Ruckus-Docs@commscope.com with regard to any documentation problem you are coming across.

If you are still seeing issue when you are dropping a email to the Ruckus Documentation team , I would recommend you to revert back on the previous case number or have a new case created . We will work towards resolving the problem.

I also Thank you for taking time sharing your thoughts on the portal and sharing your thoughts about the documentation. We will highly value any feedback you are putting across to us.

Thanks

[inphobia]

cool, i might revisit mct at a later time then. do you by any chance know what happened to the mct support for snmp? there used to be "BROCADE-MCT-CLUSTER-MIB" for from way back. in the 10.0.10 mibs i found 1 reference to:
brcdMct OBJECT IDENTIFIER ::= { switch 12 }

but that mib leaf has not included, not available. nothing else in the mib hints at mct support. lag mib, stacking mib & other possible mibs also yielded nothing/

as for the documentation remarks: i'll give the email a go again. regretfully i found quite a few so not gonna mail for each item, will group them together.