Wired Intelligent Edge

Hi all, I've a strange question about how (and if) to distribute VSX LAG's member ports on a VSX node ports considering the physical SFP cage grouping of those ports (if any) and do that particularly when deploying a VSX LAG made of (at least) four ports, thus when the VSX LAG uses two ports per VSX node on each VSX node (or, eventually, when a simple non-VSX LAG uses more than two ports on the very same Switch in case VSX LAGs are not involved).

Just as an example to clarify my scenario...let me consider an Aruba 8360 32Y4C where two SFP cages can be easily recognized by looking at the switch externally (OK it's just a visual recognition...only knowing how those groups are eventually connected internally will clarify if one has the right to ask what I'm asking here)...one can just ask this for the sake of curiosity:

What if SFP ports 1-16 of the first SFP cage on the front left follow a different internal path to Switch ASIC in comparison to SFP ports 17-23 of the second SFP cage on the front right?

Should we take care of this potential external AND internal "grouping" - and I ask that from the resiliency standpoint against a potential internal failure (say an entire SFP cage goes down because the ASIC fails on the connectivity to that SFP cage ) - when we setup a VSX LAG involving at least four ports, two per VSX node?

Say...instead of creating the VSX LAG on VSX Primary node made of port 1/0/1 and port 1/0/2 (both of SFP Cage 1), use - as example - port 1/0/1 (of SFP Cage 1) and port 1/0/17 (of SFP Cage 2) and do the same on the VSX Secondary node.

Does this sound unreasonable or crazy (or both)?

Is it based on wrong assumptions (very improbable or totally wrong failure scenarios <- if ASIC fails, it fails entirely impacting both SFP cages at the same time) or, in any case, is it useless as a alternative (and creative) approach?

------------------------------
Davide Poletto
------------------------------

It makes sense. I have seen a switch (another brand) have issues on ports that were part of the same ASIC. Its details like this that make for good resiliency and redundancy planning.

------------------------------
Dustin Burns
Senior Mobility and Access Engineer @WEI

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2021
If my post was useful accept solution and/or give kudos
------------------------------

Original Message:
Sent: Jul 13, 2021 05:02 AM
From: Davide Poletto
Subject: Aruba 8360: SFP Cages and VSX LAG' ports

Hi all, I've a strange question about how (and if) to distribute VSX LAG's member ports on a VSX node ports considering the physical SFP cage grouping of those ports (if any) and do that particularly when deploying a VSX LAG made of (at least) four ports, thus when the VSX LAG uses two ports per VSX node on each VSX node (or, eventually, when a simple non-VSX LAG uses more than two ports on the very same Switch in case VSX LAGs are not involved).

Just as an example to clarify my scenario...let me consider an Aruba 8360 32Y4C where two SFP cages can be easily recognized by looking at the switch externally (OK it's just a visual recognition...only knowing how those groups are eventually connected internally will clarify if one has the right to ask what I'm asking here)...one can just ask this for the sake of curiosity:

What if SFP ports 1-16 of the first SFP cage on the front left follow a different internal path to Switch ASIC in comparison to SFP ports 17-23 of the second SFP cage on the front right?

Should we take care of this potential external AND internal "grouping" - and I ask that from the resiliency standpoint against a potential internal failure (say an entire SFP cage goes down because the ASIC fails on the connectivity to that SFP cage ) - when we setup a VSX LAG involving at least four ports, two per VSX node?

Say...instead of creating the VSX LAG on VSX Primary node made of port 1/0/1 and port 1/0/2 (both of SFP Cage 1), use - as example - port 1/0/1 (of SFP Cage 1) and port 1/0/17 (of SFP Cage 2) and do the same on the VSX Secondary node.

Does this sound unreasonable or crazy (or both)?

Is it based on wrong assumptions (very improbable or totally wrong failure scenarios <- if ASIC fails, it fails entirely impacting both SFP cages at the same time) or, in any case, is it useless as a alternative (and creative) approach?

------------------------------
Davide Poletto
------------------------------

Hello Dustin!

Yes, deep down I know the question was sufficiently reasonable and not totally silly (I do that on Aruba 5400R zl2)...what made me to doubt was more related to the fact that on a non-modular switches like on Aruba 8320/8325/8360 (not to speak about lower end models) looking to enhance the overall resiliency also by an intelligent usage of ports (in other terms, trying to circumvent - or keep somewhat in control for what is possible - potential connectivity issues that are related to or can be amplified by the particular switch "internal" Port-to-ASIC/-Merchant Silicon design) could be less reasonable than applying the very same approach (always aimed to researching resiliency at all levels) used on modular switches where is pretty much more evident that using interfaces placed on different modules as LAG members has various notable benefits (if a Module fails within the chassis...) and that is true either considering a standalone deployment (e.g. one Aruba 5400R zl2 chassis) or considering clustered deployments (e.g. VSF made of two Aruba 5400R zl2 chassis).

Edit: to be honest I should also admit that a single ASIC design leaves less space (or no space at all) for an "ASIC separation" approach as discussed above and, just to stress this line of reasoning a little bit further, one can't simply dig deeper and justify the above approach considering instead that a single ASIC could be interfaced with few PHY chips grouping interfaces (and thus move the focus of the entire approach against the PHY chips - which control a particular group of interfaces - than against the ASIC)...why one can't? because - mostly - switch ports I'm speaking about are PHYless so there is a direct connectivity between the ports and the ASIC and this doesn't help at all...so I'm back to the start.

------------------------------
Davide Poletto
------------------------------

Original Message:
Sent: Jul 13, 2021 08:24 AM
From: Dustin Burns
Subject: Aruba 8360: SFP Cages and VSX LAG' ports

It makes sense. I have seen a switch (another brand) have issues on ports that were part of the same ASIC. Its details like this that make for good resiliency and redundancy planning.

------------------------------
Dustin Burns
Senior Mobility and Access Engineer @WEI

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2021
If my post was useful accept solution and/or give kudos

Original Message:
Sent: Jul 13, 2021 05:02 AM
From: Davide Poletto
Subject: Aruba 8360: SFP Cages and VSX LAG' ports

Hi all, I've a strange question about how (and if) to distribute VSX LAG's member ports on a VSX node ports considering the physical SFP cage grouping of those ports (if any) and do that particularly when deploying a VSX LAG made of (at least) four ports, thus when the VSX LAG uses two ports per VSX node on each VSX node (or, eventually, when a simple non-VSX LAG uses more than two ports on the very same Switch in case VSX LAGs are not involved).

Just as an example to clarify my scenario...let me consider an Aruba 8360 32Y4C where two SFP cages can be easily recognized by looking at the switch externally (OK it's just a visual recognition...only knowing how those groups are eventually connected internally will clarify if one has the right to ask what I'm asking here)...one can just ask this for the sake of curiosity:

What if SFP ports 1-16 of the first SFP cage on the front left follow a different internal path to Switch ASIC in comparison to SFP ports 17-23 of the second SFP cage on the front right?

Should we take care of this potential external AND internal "grouping" - and I ask that from the resiliency standpoint against a potential internal failure (say an entire SFP cage goes down because the ASIC fails on the connectivity to that SFP cage ) - when we setup a VSX LAG involving at least four ports, two per VSX node?

Say...instead of creating the VSX LAG on VSX Primary node made of port 1/0/1 and port 1/0/2 (both of SFP Cage 1), use - as example - port 1/0/1 (of SFP Cage 1) and port 1/0/17 (of SFP Cage 2) and do the same on the VSX Secondary node.

Does this sound unreasonable or crazy (or both)?

Is it based on wrong assumptions (very improbable or totally wrong failure scenarios <- if ASIC fails, it fails entirely impacting both SFP cages at the same time) or, in any case, is it useless as a alternative (and creative) approach?

------------------------------
Davide Poletto
------------------------------