Wired Intelligent Edge

Hi! Looking at latest Aruba Airwave 8.2.11.0 Supported Infrastructure Devices (April, 28th 2020) a new Aruba CX Switch series is listed: it's one named "Aruba CX 6200" (with a reference to ArubaOS-CX 10.5 software line ML.10.05.1000). Pretty much interesting.

 

 

A personal thought: are we ready to slowly start saying adieu at ArubaOS-Switch?

I've heard 6200F is going to be in the middle between 2930F and 9300F price wise (currently 6300F is 2x the price of 2930F). There's no 6200M at least for now so no dual psus.

 

We bought couple hundred 6300F but just got my hands on first few for labbing. Still don't know sure though what are the advantages over 2930F Mixing 6300M and 6300F of course and maybe we'll get something useful from the NAE but we'll see.

 

 

\OT

So, in the end, you opted for Aruba CX 6300F instead of Aruba 2930F...probably Aruba CX 6200 will support Dynamic Segmentation too.

 

Just to speak what I dislike in seeing VSF re-engineered on ArubaOS-CX is a VSF implementation not developed to provide an orchestrated software update method (so it's all or nothing: want to update? do reboot the whole stack [*])...like VSF FSU (Aruba 5400R zl2 only)...the given reason to this point was it wasn't necessary considering the switch placement (Access)...still a missing thing to me...especially considering how advanced (and different) ArubaOS-CX is.

 

[*] You should know about that already having a lot of stacks to maintain, with that regard the ArubaOS-CX VSF is apparently implemented not to differently from well known ArubaOS-Switch VSF or Backplane Stacking implementations.

OT\

I realize this isn't the right place to say this
<rant>
But I agree 100% with voicing disappointment with how there isn't a way to do a seamless upgrade. We can upgrade our wireless controllers without any impact; we can upgrade our core/dist layers (VSX) without any disruption to the network. Yet, when we go to upgrade our edge layer, our wireless access goes down. 

 

Having a way to connect our 2 port uplink APs (335 as an example), both ports could be uplinked to different members of the stack, and then the members reboot one at a time. (Assuming the stack has 2 uplinks to distribution) you have a way to keep wireless online pretty much through all firmware updates. I'd even be okay with 2 separate stacks if they could do MCLag. 

I realize there probably isn't a lot of use cases, but having a way to keep the wireless online throughout any firmware upgrade at any level of the network would be great.

</rant>

Boy, I really miss my dual-sup 4500.

Always on availability on my access layer. Some with 3y+ uptime (only went down due to power shortage) with multiple upgrades and downgrades in-between. Mine's from 2011.

 

Yet, it's 2020 and a "modern" NOS software still can't get a hitless upgrade with 3 different equipment in a stack...

 

 

---

@cwickline14 wrote: ...But I agree 100% with voicing disappointment with how there isn't a way to do a seamless upgrade. We can upgrade our wireless controllers without any impact; we can upgrade our core/dist layers (VSX) without any disruption to the network. Yet, when we go to upgrade our edge layer, our wireless access goes down. 

Yeah, it's what I meant (I wrote about this lack on ArubaOS-CX VSF implementation initially here, by commenting about new Aruba CX 6300F/M and their VSF feature, and also here explicitly asking about a possible ArubaOS-CX VSF FSU implementation).

 

---

@cwickline14 wrote: Having a way to connect our 2 port uplink APs (335 as an example), both ports could be uplinked to different members of the stack, and then the members reboot one at a time. (Assuming the stack has 2 uplinks to distribution) you have a way to keep wireless online pretty much through all firmware updates. I'd even be okay with 2 separate stacks if they could do MCLag. 

I realize there probably isn't a lot of use cases, but having a way to keep the wireless online throughout any firmware upgrade at any level of the network would be great.

---

Good point(s).

Hi,

 

As a workaround, and if you are ok with two separate stacks, then you possibly can get around this issue by terminating your APs in a planned manner across different stacks..

As such even if the stack goes down/reboots, other APs located in the same location will not be impacted..

 

Needless to say, the seamless wireless upgrade assumes that there is RF redundancy .. so you just need to take an extra step and ensure your "redundant" APs are terminated on different switches..

 

 

Back on track.

 

It looks like the new Aruba CX 6200 Switch Series will be formed by these SKUs:

 

• JL724A Aruba 6200F 24G 4SFP+ Switch
• JL725A Aruba 6200F 24G Class4 PoE 4SFP+ 370W Switch
• JL726A Aruba 6200F 48G 4SFP+ Switch
• JL727A Aruba 6200F 48G Class4 PoE 4SFP+ 370W Switch
• JL728A Aruba 6200F 48G Class4 PoE 4SFP+ 740W Switch

List taken from the ArubaOS-CX 10.04.2000 Release Notes for Aruba CX 6200 (available on ASP).

They are posted them on the Aruba site here

Datasheet can be found here
https://www.arubanetworks.com/assets/ds/DS_6200Series.pdf

Hmm so now modular switches, 10G uplinks and less routing capacity it seems.

 

Same CPU and memory though so it's limited in the software.

One difference I found out from "Introduction to the Web UI" document is:

"NOTE: The 6200 switches support two VRFs. One management VRF and one default VRF."

 

Though it's not possible at least with 6300F to attach VLAN interfaces to mgmt VRF. So only OOBM but who runs separate OOBM network for access switches

VSF manual says

The VSF stack supports 6200F devicesdevices in the 6300 family (6300M and 6300F).

---

So I guess you could do a stack with 6200F and 6300M?

Hi, each and every VSF Stack can be made of switches belonging to the same Switch series [*], mixes are not admitted (so Aruba CX 6200 with Aruba CX 6200, Aruba CX 6300 with Aruba CX 6300). [*] Not to speak of VSF deployed on ArubaOS-Switch based Switch Series like Aruba 2930F and Aruba 5400R zl2 (for the latter series the requirement is even more strict: 5406 with 5406 and 5412 with 5412, in any case two members only).

Hmm wonder what that quote meant then. From newest VSF guide, page 13

Well the Feature description: https://techhub.hpe.com/eginfolib/Aruba/OS-CX_10.04/5200-6790/index.html#GUID-80EC00A2-C169-4425-B828-231BEF25245F.html is quite clear about that.

Yep I would think that it's limited to only 6200 or 6300 only. Though it would've been interesting to be able to add 6300M to a 6200F stack if some places require dual PSUs

Though so far our 6200F quote was more expensive than what we pay for 6300F, we have quite a good deal on those 6300Fs

---

@pubjohndoe wrote: Yep I would think that it's limited to only 6200 or 6300 only. Though it would've been interesting to be able to add 6300M to a 6200F stack if some places require dual PSUs

---

Yep, it would...but actually it's not possible (to mix 6200 and 6300F/M to form a VSF stack).

 

With regards to the sentence you were referring to (Page 13 of latest

I think it's just a matter of bad wording (probably an error, note the "devicesdevices" string), a sentence born in a bad way.

 

Some one should contact the HPE Aruba documentation team (docsfeedback@hpe.com) and alert them about that sentence (Part Number: 5200-6790c Published: May 2020 Edition: 4 Page: 13 --> a clearer sentence would be: "A VSF stack can be deployed by using either Aruba 6200F devices or Aruba 6300F/M devices, not a mix of devices from different switch series.", that's all).

Greetings!

 

I'm working with the docs team to get that wording fixed on our end. (I think that note was just clarifying that there are no modular switches in the 6200F family, only fixed switches.)

 

To clarify: You cannot mix 6200s and 6300s in a VSF stack — a stack can be either all 6300s (any combination of fixed and modular switches) or all 6200Fs. 

---

@pubjohndoe wrote: Same CPU and memory though so it's limited in the software.

---

Quite clear that some features were simply not implemented: so we are facing some Software (ArubaOS-CX) based restrictions; some other relevant limits (lower than those available on 6300/6400) have been also set by Software - as it often happens - since, as you wrote, CPU, RAM and ASIC generation are identical to Aruba 6300 Switch series.