Wired Intelligent Edge

last person joined: 3 hours ago 

Bring performance and reliability to your network with the Aruba Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of the ArubaOS-Switch and ArubaOS-CX devices, and find ways to improve security across your network to bring together a mobile first solution.
Expand all | Collapse all

Aruba 8360: SFP Cages and VSX LAG' ports

This thread has been viewed 32 times
  • 1.  Aruba 8360: SFP Cages and VSX LAG' ports

    Posted Jul 13, 2021 05:02 AM
    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

  • 2.  RE: Aruba 8360: SFP Cages and VSX LAG' ports

    Posted Jul 13, 2021 08:24 AM
    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

  • 3.  RE: Aruba 8360: SFP Cages and VSX LAG' ports

    Posted Jul 13, 2021 10:00 AM
    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