topic RE: EXOS or VOSS in Network Architecture & Design

EXOS or VOSS

EF — Thu, 25 Aug 2022 11:51:00 GMT

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

RE: EXOS or VOSS

Stefan_K_ — Thu, 25 Aug 2022 12:28:00 GMT

It depends. You want to use fabric? Use VOSS. Traditional/normal networking? EXOS.
What are the planned core-switches? How big is the networks / how many switches are planned?

RE: EXOS or VOSS

EF — Thu, 25 Aug 2022 12:52:00 GMT

It´s about 50 switches, I Would like to use VOSS because the mgmt interface is the same as legacy ERS that which is the customer network, plus all the benefits of SPB network. But I see problem in the work day because the administration grows (each VSP is standalone).

RE: EXOS or VOSS

TQU — Thu, 25 Aug 2022 18:40:00 GMT

Hello EF,

You should discuss with the customer and his network team.
From my point of view, it depend on what you want to connect on devices which level of redundanc you want.
For user access device (edge) -> Stack of EXOS
For server or all double link device -> VOSS and vIST cluster
For Core device -> VOSS Fabric SPBm (vIST cluster if required)

about pros/cons, i don't see any document about it.
My opinion :
VOSS was created for core device, not for access. They add layer 2 protection and some access mecanisme to VOSS recently but in front of XOS, i found that XOS offert better control and security option. And you can use Fabric Attach to expend the fabric.
I understand that the GUI is not EDM BOSS/VOSS but XOS Chalet do the job.
With VOSS at the Edge, it will be more flexible (under condition that you have more fiber links) but it can be more harder to admin it for IT team. If GUI is important for your customer, it sound like they are not familiar with automation tools. And if they need to repeat each modifications on each node through the GUI, they will regret the stack option.
This is why you should discuss with your customer to understand their methodes, if they are open to change, automation, XIQ, etc..

Regards,
Théo

RE: EXOS or VOSS

Ludovico_Steven — Fri, 26 Aug 2022 15:58:00 GMT

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.

Re: EXOS or VOSS

FredrikB-NN — Sat, 15 Oct 2022 17:29:42 GMT

Generally I'd stay away from stacking with EXOS. We've moved away since we never stopped seeing temporary loops and all sorts of weird behaviour despite cases and "fixes". It seems the backup is very eager to take over from the primary as the primary goes down for a stack reboot so it starts enabling interfaces that the master had brought down just before it reboots itself. ELRP goes BOOM all over the network when this happens. Customers are moving to MLAG in dist and single switches in access because of this (and other weirdness in stacks).

Re: RE: EXOS or VOSS

jeronimo — Tue, 03 Jan 2023 17:21:28 GMT

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...