Wired Intelligent Edge

Hi,

 

did the 8320 support VSF yet ? or in roadmap ?

 

thanks

The 8320 is not shipping yet. For future looking statements, like roadmap information, please contact your local Aruba Sales team or SE.

The 8320 will support VSX which is a technology specifically target at a virtualized Agg/Core of networks.  Today, we utilize MC-LAG for a redundant and resiliant Agg/Core today.

 

What is VSX?

VSX (ArubaOS-CX) is a Virtualized Core and Aggregation solution designed ground up to meet the high availability, virtualization and simplicity needs unique to the core of the network. VSF (ArubaOS-Switch) is a Virtualized switching solution that provides simplicity and high availability and is an optimal design for access platforms. These two great high availability technologies will play important roles in their respective areas of our portfolio. 

 

The VSX design is purpose built for core and aggregation networks delivering the best combination of today’s solutions like MC-LAG and VSF. It is designed for high availability in every aspect and we will enhance the solution to ease deployment, enable flexibility in design and provide tools to make it easy to manage and troubleshoot. VSX enables a distributed and redundant architecture that is highly available during upgrades inherently by architecture design. Operationally, VSX will include features to ensure enhanced and robust configuration and consistency checking and tools to make upgrades easy and minimally disruptive.

As of today though what are the options to stack two 8320s i have a pair im using as the core of a small business network of a colapsed core design. Its appears VSX isnt in the firmware yet?

Hi Rob, 

 

how many units can 8320 stack?

 

Kind Regards, 
Kenji

VSX will be in beta soon and will be available to our customers in the 10.1 release of code coming out later this summer.  Aruba will be adding further innovations to VSX in future releases of code.  You will be able to stack 2 8320's together in a VSX configuration.  

 

Rob,

   Thanks for the information, however i bought a pair of 8320s after being told i could use them HA, im assumming my only real option currently is MCLAG? seems the 8320 was released a bit early. 

That is correct.  ArubaOS-CX 10.0 code provides a high level of resiliancy and redundancy utilizing MC-LAG.  VSX adds all the bells and whistles to simplify deployment, add sync features, active-active features, etc..  Please feel free to reach out to me on e-mail rob.a.haviland@hpe.com and we can help with your initial MC-LAG configurations.

 

i just emailed you Rob. 

8320 / 8400 / ArubaOS-CX High Availability using MCLAG

The ArubaOS-CX operating system supports HA using an advanced implementation of MCLAG TODAY. It is at the same or higher level than similar technologies in the market.

The MCLAG solution is the same for 8400 and 8320 switches.

The MCLAG elements are: 

• Control plane: Inter-Switch-Link and Keepalive
• Data plane L2: MCLAGs
• Data plane L3: Active gateway

What is MCLAG?

MCLAG is the technology that allows for the configuration of link-aggregation-groups (LAG) with member ports distributed across two chassis.

MCLAG is also the name of these distributed LAGs. These MCLAGs are layer 2 LAGs, and are the optimal solution when connecting layer 2 access devices like access switches and mobility controllers.

Why MCLAG?

MCLAG's main advantage is that it provides redundancy by providing dual homing to layer 2 access devices without the need for STP and at the same time keeps the management and control planes of the two aggregation devices independent, maximizing availability.

Control plane

The inter-switch-link is:

• a function that implements the coordination and synchronization of MCLAG information like LACP neighbors, MAC address tables, etc.
• configured on a link between the two chassis implemeting MCLAG - this link is not dedicated to this function, and it can and does carry other traffic

A separate IP-based keepalive mechanism completes the control plane by providing an integrity check in the case of an ISL failure.

Data plane:

MCLAGs are layer 2 LAGs configured on both chassis that connect to a single access device like a switch or mobility controller. From this 3rd device's LACP point of view, all ports in the LAG belong to a single device.

The Active Gateway is a layer 3 function of MCLAG that provides an active-active gateway for the clients connected to the access device(s).

What is VSX?

MCLAG as described above is available today.

VSX is the next generation of MCLAG, that will simplify the deployment, streamline the configuration, ensure configuration consistency across the two chassis, and take advantage of the unique database-centric OS architecture to provide deeper visibility into MCLAG's management, control and forwarding planes. 

 

Would like to know as soon as this is available. We bought a pair to relpace our enterprise core infrastructure with the assumption that there would be stackable for resiliance with L2 and L3 in a single locical switch.

 

Don't know if I'll be able to configure them that way right now even if it does provide L2 redundancy with the comlex setup you described.

---

@Ruben.Iglesias

Hi,

 

I believe that with the current options like MC-LAG and active gateway you are more then able to setup and configure a redudant core providing L2 and L3 redundancy. 

When VSX is available from release 10.1 the configure part will be easier. That said, setting up MC-LAG with active gateway is not hard at all. Even i can do it.....

8320 does support single virtual data-path with MCLAG in 10.0 and with VSX in 10.1 (coming soon). Essentially, VSX LAG is equal to multi-chassis LAG. VSX brings also other functions like some configuration synchronization and troubelshooting to simplify the management plane.

VSX brings also Virtual first hop gateway (active-active), and optimized L3 processing to avoid unnecessary inter-switch traffic within a VSX stack.

However, VSX is positionned for distribution/core where we want HA during upgrade. In that context, we keep separate control plane and both VSX nodes have their own router ID, and appear as two separate L3 nodes in the L3 routing domain. 

Hi Vincent,

 

Thanks for your reply.

 

 

Hello all, I've few general questions about ArubaOS-CX VSX implementation with regard to hitless failover and declared near zero downtime during software updates.

 

Considering that ArubaOS-CX 10.01 is just behind the corner (Will it be available during mid July?) and so VSX can be finally deployed:

 

• Will an VSX deployment be stable enough with ArubaOS-CX 10.01 to be used in a production environment (In our case we are planning to under-use it basically to provide Layer 2 connectivity on a scenario where, potentially, also an HPE FlexFabric 59x0 would fit the bill)?
• Will software updates really near zero downtime?
• Will failover really be hitless (considering that ISL and Keepalive links should be deployed as per VSX implementation best practices)?

Thanks for any insight and suggestion.

Hi

 

From my experience Aruba firmware out in the field is always production ready. True hitless failover will mean a sync in traffic between the two 8320's. I don't believe that will happen. But with MCLAG you already get a fast failover in traffic. With VSX it will get even faster.

 

 

VSX, as part of ArubaOS-CX 10.1, is available by mid-July. This release has been extensively tested, and failover time will depend mostly about the network topology. You may contact me for a demo if you need where I reboot a switch and total interruption time is less than 0.5 second for unicast test flows (including routing). 10.1 is mature to go for production.

@vincent.giles: thanks for the infos you provided, that's reassuring...probably Aruba 8320 is going to be underutilized and/or overrated for the network scenario we want to deploy: we need a very fast switch (with very low latency at 10Gbps line rate), with fast backplane (in range of Tbps), stackable (IRF/VSF like) and we are going to use grand total of about 60 SFP+ ports and just a few SFP (RJ45) ports. The switch itself is not going to perform L3, just L2 in a quite isolated zone (backend, inbetween our IBM Power 7, 8 and 9 servers infrastructure and IBM all-flash SAN)...we are also evaluating a more "common" solution that include an HPE 5940 (so Comware 7 based which means IRF+ISSU) with same number of SFP+ ports and QSFP+ ports.

Hello Parnasus,

 

For these kind of deployments (Layer 2 - 10G Ports) we use the switch HPE 5700, I suggest you to look into it, its price is like half of the 5940 or 6320 and it supports IRF up to 9 members.

 

Best Regards

 

Luis Regis

Eventually I can create another post to discuss this further (don't want to go too Off-Topic since here we discuss about Aruba 8320/8400 and VSX)...but, yes, you're probably right (there are cheaper alternatives which are able to provide good performance for the price)...on the other hand it is also a matter of purchasing something that is (a) recently engineered both in terms of HW (e.g. with respect to Hardware Backplane, CPU, latency and Packet Buffer size, as examples) and SW (Comware 7 on both, so OK...even if we should take care of tiny differences in Software Development lines) and that is (b) future proof in order to be a good investment at least for next 6 or more years (which is mostly related to Software Development and type of interfaces the device provides, the latter is quite static since SFP+ and QSFP+ will remain there...the former may vary during the product lifecycle).

 

P.S.

A full SFP+ (plus some QSFP+) HPE 5700 hasn't exactly the same port density of a full SFP+ (plus some QSFP+) of an HPE 5940 or Aruba 8320...I mean in a like-for-like comparison: 40 SFP+ ports against 48 SFP+ ports and 2 versus 6 QSFP+. Also a 5900AF could be an alternative (not necessarily cheaper than Aruba 8320 in a equivalent configuration).

For your project, the 8320 seems a very good fit. Don't hesitate to contact me: vincent.giles@hpe.com for a specific follow-up or your project. I may also introduce you to our Aruba Italian System Engineer.

Thanks.

Hi

As you are designing a DC network stick to comware as Aruba is mainly campus. With the number of ports and maybe a spine-leaf setup in the future the 5940 seams a good choice.

Hope it helps

Hello Frank,

 

I agree with you about HPE 5940: it was on top of my list of preferred switch series to be considered (I admit I feel pretty comfortable with IRF designs on Comware 7, given how broad is the IRF usage in DC....that's very reasonable)...strangely the HPE 5940 was defined too overrated by our supplier for our specific "Layer 2 only" usage scenario: personally I find that statement pretty questionable since the same could be said watching how features rich the Aruba 8320 is too.

 

Below non technical considerations that are OT and, possibly, deserve another thread:

 

A factor that kicked it in favour of Aruba 8320 choice - totally Off-Topic here if we limit our analysis about differents technology approaches both series use (e.g. IRF versus VSX or Comware 7 versus ArubaOS-CX) - was the solution final's cost...that one was about 10% more expensive for HPE 5940 than the Aruba 8320 in a "like-for-like" BoM comparison.

I really can't judge if the price difference we were faced looks reasonable or if it was, let me use this term, "artificially managed" by pushing one product over the other for marketing reasons...but, interestingly, if we start to look only at "chassis price" this one is much higher for an Aruba 8320 than for an HPE 5940...instead supported Aruba SFP+ Transceivers were way cheapers in comparison of equivalent HPE (Data Center marked) ones supported by the HPE 5940...so, in the end, the final solution cost rebalanced in favour of the Aruba 8320.

 

My take is that Aruba 8000 is the first and fresh attempt - with a totally new approach permitted by ArubaOS-CX operating system (and related SW/HW architectures) - to kick those high end switch series into the "placid" DC zone (ToR? Core?) providing required some - not all - of the typical DC features we're used to see.

Hi

Keep in mind that the 8320 is still missing DC features at the moment.
If L2 is the only thing needed, now and futurewise I would look at the 5700 in IRF.

Still I would not design a DC with Aruba switches at this moment.

Hello Frank,

 

As I wrote we're pretty conscious that Aruba 8000 Switch series is not comparble, DC features speaking, with typical HPE 5xx0 Comware 7 based Switch series (first of all VSX is not IRF)...on the other hand, in our pure Layer 2 implementation, it should fit the bill quite well.

 

One side consideration to add would also be the horizon a product has both in terms of life expentancy and software development/support...even if I'm a fan of all which is Comware based, HPE 5700 included, I think Aruba 8320 has with respect to 5700, necessarily, a brighter future.

Hi

I disagree. The Comware based switches Have a future in DC, the 8320/8400 not primarily. Both have an OS build for its own area. Yes the 8320 will do the L2 work in the DC, but is not the best suited switch for it.

I think we should give a customer the best advise possible for now AND the future. I would go for Comware

That’s my $ 0.02.

I never wrote that entire Comware operating system based switch series is not going to have a future (in a DC environment or out of a DC environment)...about DC I substantially agree with you...in our scenario we are not properly speaking about a DC role for Aruba 8320 but only a placement into a DC...more, I just wrote that Aruba 8320 is going to have a brighter future with respect to older HPE 5700 (the HPE 5700 is somewhat older if compared to, as example, HPE 5940 or to Aruba 8320 and that it's a fact).

 

So, generally speaking about mid/high end Comware operating system based switch series, I actually would consider HPE 5940, not HPE 5700 (neither HPE 5900AF)...but it's always a matter of which role/feature you're going to use more.

 

P.S. I'm the customer...

Hi Davide,

 

Yes if you look only at the here and now, you could take an 8320 switch.

And yes the 5700 is a bit older then 5940 and above.

Looking at future i would not consider a campus switch in any DC deployment.

 

 

Your statement "Looking at future i would not consider a campus switch in any DC deployment." looks really categorical to me...my take is that, at this point, we have all to admit that Data Center definition can sometimes be loose enough to describe a scenario into which also an high end Core-Campus switch series like Aruba 8400/8320 can be deployed...or, at least, I hope so.

Hi,

 

Why does it look categorical?

 

For riding a bike you use a bicycle, for driving a car you use a car.

 

In most use cases an Campus switch will not be the best solution for a DC network. I would always go for a Comware based switch. Period.

But that is only my take on it. You are off course aloud to have your own.

I don't think we will see eye to eye on this one.