EXOS or VOSS

[EF]

Hi team!!!

I have a new deployment with universal hardware switches, now we have to take a decision about the architecture:

- tradicional stacks with EXOS?
- flexibility SPB cloud with standalon devices?

Im confused about why SPB devices can´t work on stack, and maybe this is a problem for a customers that works with Nortel/Avaya ERS legacy stacks because the number of mgmt IPs grow, but in the other hand with SPB they will have more flexibility and more fault tolereance.

Is there any document with pros and cons? Comparative whitepaper?

what is your opinon?

Regards

EF

[Ludovico_Steven]

It is no longer true that VOSS is only for the core, in the past year and a half, since release VOSS8.3 and 8.4, VOSS has taken on all the necessary edge/access features, in particular around NAC and auto-sense.
There was a decision to fully automate not only the fabric forming, but also the access port configuration, and this is achieved via the new auto-sense capability which, if in particular if deployed with NAC, now allows complete zero touch of the fabric edge.

Stacking is an old concept, and delivers a clear benefit when weighing the need to configure the wiring closet switches. It is clearly easier to configure a stack of 8 units, than it would be to configure those 8 units individually.
But if you have a solution where you don't need to configure the wiring closet switches anymore, then where's the value of stacking ?

Besides, stacking is not simple, there is a lot of software complexity under the bonnet to make stacks work, and that inevitably translates in some downsides: setting up the stack to start with is a pain; stack failures are rare but can happen and are a pain to troubleshoot/correct; upgrading a stack usually takes out all the units at once; and a stack usually requires uplinks into an MLAG distribution layer, which obviously needs provisioning upfront.

Fabric edge is a new way of designing networks, and goes hand in hand with the auto-sense functionality, and does away with stacking.
It also does away with requiring an MLAG distribution. And there are no more constraints on how to wire up the wiring closet. If you want to wire it up as in the stacking days, you can, but if you want to have more diverse wiring topology, you can have one wiring closet connect to the next one, in a ring like topology; or you could have a triangular distribution with wiring closets dual homed into each side of the triangle. The flexibility is the key.

[jeronimo]

Very interesting read.

I do not totally agree. I am not a fan of auto-sense. Auto-sense makes things just work, which is contrary to security, where you only want things to work that you explicitly configure.

I think it is ok for NNIs and during onboarding stage. I would even revert NNIs to static using "no auto-sense enable convert-to-config" after that. For example: In case IS-IS adjacency fails for whatever reason (configuration error or software failure), both ends of the connection might be going into NNI-ONBOARDING state and create a nice broadcast storm.

In any case, you should take care to separate your onboarding VLAN/service from any user/management traffic as anyone would potentially be able to connect to that service.

Furthermore, I'm not sure about feature parity. You can't run macros/policy, like enabling LLDP when a phone has been authorized (by NAC). (Not the other way round, which would be enabling Voice TLVs when someone _claims_ to be a phone.) Not being able to do this for example prevents you from having multiple voice networks, very common in a multi-tenant scenario, which is what fabric architecture is made for I guess. (Hint: Being able to set LLDP voice vlan using "Extreme-Dynamic-Config" Radius attrs would be spot-on <-- Feature request.)

Also, session QoS cannot be configured nicely from within XIQ(-SE at least). It just says it's not supported and you have to go manually fiddle with ACEs and set them through Radius.

I agree about the advantages concerning topology, even though every single switch having its own IP address is somewhat hard to digest...