Wired Intelligent Edge

Hi all, we start to deploy some 8320 to our customers. The were shipped with OS-CX v10.000013. We are waiting for OS-CX v10.1. Has any deployed them yet? How were your experiences? After i quick look, i missed port speed and dupley/autoneg commands... Thanks and BRs André

AFAIK ArubaOS-CX 10.1 is expected to be released this/next week (documents reported "Mid July") so it shouldn't be officially available yet to Aruba 8320/8400 customers.

Would be interesting to enter into the ArubaOS-CX world (coming from usual ArubaOS-Switch)...let we see if we are going to be lucky enough!

Hi Vestra and Panassus,

Yes, 10.01 is coming soon for the 8400 and 8320 platforms. We are in the final testing phase. It is looking good. Watch out especially for the new VSX feature.

Regards, Ruben.-

 

 

Hello Ruben! that's great, thanks to @vincent.giles, he created the opportunity for us to be in touch with HPE Italy through our VAR to discuss about a possible VSX deployment with two Aruba 8320 and we're going to have a Web Conference late this week that will be held by with Jordi Garcia, Pre-Sales executive South Europe (scenario was briefly discussed here).

Thanks for all comments! 

I really hope that 10.1 with VSX arrives soon...

 

Today, i installed 2x 8320 at a customer.

Unfortunately one of the first steps failed: I configured a default gateway on the vrf management and this didn`t work. Same effect on both 8320. Solution: boot system. 

This is strange. For exmaple using such configration, I never saw this problem:

interface mgmt
no shutdown
ip static 10.136.1.235/24
default-gateway 10.136.1.1

Regards,

Vincent Giles

and shut / no shut of the interface was not enough to solve the issue ?

No, only the reboot helped

@vestra: OT question...how long is the entire reboot procedure? ...probably next week hands on a pair of Aruba 8320...first task OoBM configuration then standalone software update to ArubaOS-CX 10.01 if necessary.

Hi

 

The last time it clocked the reboot it took 50 sec to reboot and get back to CLI, after 70 sec Layer3 traffic was back.

 

 

@vestra: ArubaOS-CX 10.01 is out.

 

 

 

Thanks, we did the upgrade -> without any problems / only short reboot

Hi Vestra, if you deployed VSX can you share a sanitized running configuration? I'm going to deploy it too and I'm asking if there is something that can be studied to be prepared to.

Thanks! Davide.

---

@parnassus wrote:

Hi Vestra, if you deployed VSX can you share a sanitized running configuration? I'm going to deploy it too and I'm asking if there is something that can be studied to be prepared to.

Thanks! Davide.

---

Do you always need a running configuration ?

 

It is very easy to use VSX ! (if you are Aruba Partner, you can also try with WorkBench)

Hello Alexis, it's not essential...but it would be useful to use it as a template to study just in case of doubts...I've collected many info about ArubaOS-CX and, in particular, about setting up VSX so I'm pretty confident I shouldn't have any particular issue [*] (Aruba 8320 arrived today and next Monday we're going to start).

 

[*] apart - I'm asking myseld now - if I can reproduce the same SNMPv3 settings I standardized and used on all other ArubaOS-Switch devices we have in order for the new Aruba 8320 pair to be discoverded by our HPE IMC 7.3 E0605P04.

Hi

At the moment VSX only gives you some config advantage. It is not like IRF and VSF!

You can build the whole corenetwork on 8320/8400 without VSX.

Frank, in all honesty I already know that VSX, in terms of features, resembles somewhat a mix of VSF and IRF but, looking carefully, it behaves neither as VSF does nor as IRF does (IMHO it looks, but it isn't, like the old so called Distributed Trunking with ISL of old ProVision based switches...on steroids...and enigneered for a totally different operating system with totally different approach <- think about how synching happens, as example): in our specific scenario we do need VSX because we do need resiliency (call it HA) through both Aruba 8320 we are going to implement...so it's not just a matter of building a core based on ArubaOS-CX but it's a matter of building an isolated network based on ArubaOS-CX correctly implementing VSX.

At this point I think I have all the puzzle's tiles on the right places, my request was aimed to see if there is a configuration to be taked as very best practice (VRF, ISL, Keepalive, etc.) without recapping VSX related slides from different presentations/documents...it there is, OK...if there isn't, doesn't matter.

I've documented myself a lot about VSX (OTOH I've already implemented VSF using two Aruba 5406R zl2 with OoBM MAD and IRF on low end HPE Comware v5/v7 based switches).

Hi Davide,

Did you already build a 8320 setup with version 10.0, not 10.1? So without VSX.
Yes true to the DT on steroids. I believe that MCLAG with active gateway is unique solution in the market. MCLAG with active gateway works already great without VSX. We have build it many times.

HPE provision was years ahead with DT IMHO.

AFAIK at this moment VSX provides ease of configuration.
It will never be a mix of IRF and VSF.
With VSX both switches will be running independently from each other. That’s it’s strong point. So a different design approach. No ISSU needed as they don’t run as a virtual chassis or logical device.
But this is just my $ 0.02. As always opinions will be unique and you don’t have to agree with them. You can have yours.

Hope this helps.

To follow-up on recommendation. Few things that might help:

-1- links member of the ISL LAG must be sized to sustain at least one uplink failure scenario. An other scenario could be if you have high volume of traffic between single attached nodes connected to primary and other single attached connected to secondary.

-2- It is suggested to use a dedicated VRF for keepalive UDP communication. This is not mandatory at all but minimize any risk of issue due to routing change.

-3- It is recommended to use dedicated direct link for keeplive between primary VSX node and secondary. Again not required but this avoids to be dependant on the stability of the upstream L3 domain. 1G transceiver can be used for this dedicated interconnection as there is very small BW need for keepalive traffic. If there is no port available for this usage, or no fiber path, then use a stable IP path between VSX nodes (ex: it could be through upstream network nodes).

-4- To avoid sub-optimal traffic path (traffic going unnecessary through ISL) please understand and use both features:

 a) active-gateway (first hop Virtual IP), instead of VRRP

 b) active-forwarding (in case you have ECMP routes on uptream nodes pointing to each VSX node). Active forwarding is set on the transit VLAN for upstream routing.

-5- If you don't allow all VLANs in ISL, it is higly recommended to use vsx-sync vlans on the ISL LAG on the primary to guaranty equal VLANs trunking.

If you have more points, clarification ned on best practices, don't hesitate to use the forum.

 

Finally, if you are a partner, there is a very technical presentation on VSX that you have access on Arubapedia for partner. (2 hour presentation and associated slide set).

Hi Vincent, 

 

I was just going through your post and I am in a stage of deploying a new pair of VSX switches on the core layer of the network (which is the L3 demarcation point). It is directly conencted to a pair of firewall in a full mesh topology.

I couldn't understand the use of active forwarding and why should I enable in my case? Should I enable it on the upstream SVI used to connect the firewall ?. Appreciate if you could provide me some details of why and where should I use this active-forwarding feature. 

---

@vincent.giles wrote:

To follow-up on recommendation. Few things that might help:

-1- links member of the ISL LAG must be sized to sustain at least one uplink failure scenario. An other scenario could be if you have high volume of traffic between single attached nodes connected to primary and other single attached connected to secondary.

-2- It is suggested to use a dedicated VRF for keepalive UDP communication. This is not mandatory at all but minimize any risk of issue due to routing change.

-3- It is recommended to use dedicated direct link for keeplive between primary VSX node and secondary. Again not required but this avoids to be dependant on the stability of the upstream L3 domain. 1G transceiver can be used for this dedicated interconnection as there is very small BW need for keepalive traffic. If there is no port available for this usage, or no fiber path, then use a stable IP path between VSX nodes (ex: it could be through upstream network nodes).

-4- To avoid sub-optimal traffic path (traffic going unnecessary through ISL) please understand and use both features:

 a) active-gateway (first hop Virtual IP), instead of VRRP

 b) active-forwarding (in case you have ECMP routes on uptream nodes pointing to each VSX node). Active forwarding is set on the transit VLAN for upstream routing.

-5- If you don't allow all VLANs in ISL, it is higly recommended to use vsx-sync vlans on the ISL LAG on the primary to guaranty equal VLANs trunking.

If you have more points, clarification ned on best practices, don't hesitate to use the forum.

 

Finally, if you are a partner, there is a very technical presentation on VSX that you have access on Arubapedia for partner. (2 hour presentation and associated slide set).

---

 

Since you wrote:

---

@raoul7 wrote: It (the VSX) is directly conencted to a pair of firewall in a full mesh topology. I couldn't understand the use of active forwarding and why should I enable in my case?

You're probably going to use a "Transit VLAN" (one for each VRF) to connect your VSX to your Firewall Cluster/Core, isn't?

 

If so the Active-Forwarding feature should be configured on that upstream SVI [*] (one SVI per VRF) which is facing the upstream layer (the SVI is the logical Layer 3 interface configured and associated with that "Transit VLAN" you will use to uplink to your Firewall Cluster/Core)...and that feature, IIRC, is mutually exclusive - considering the very same VLAN Id - with the other Active-Gateway feature that can, instead, be used facing the downstream layer (so facing the Access Switches/Edge devices) instead of a VRRP approach.

 

For sure @vincent.giles will be able to help you better about that (I hope my line of reasoning is correct enough...if not, pardon, and I'm going to learn it too).

 

[*] something like:

interface vlan x  # where x = Transit VLAN id cited above
  vsx active-forwarding

You got it right Davide :-)

 

To Raoul:

Do you have a single VRF or multiple VRFs ?

If you have only one,  then you may use Routed Port on the VSX pair instead of upstream VSX LAGs (MCLAGs) and transit VLANs

(that is the option for multiple VRFs).

If you have multiple VRFs, or you want to use transit VLANs instead of ROP, then vsx active-forwarding is configured on the transit SVI (to upstream firewalls) to avoid potential sub-optimal path of traffic through ISL between VSX nodes. By activating VSX active-forwarding on the L3 VLAN interface of this upstream transit VLAN, you will also get the benefit of High_Availability for dynamic routing protocols if you use any, as, if a VSX node reboots, is power-off, the remaining VSX node is still able to process traffic with destination MAC being the dying VSX peer.

 

 

Active forwarding is limited into 16 VLAN only? And can you share the sample configuration of the active forwarding if i have pair of VSX swtiches. Thanks

---

@kasmlz23 wrote:

Active forwarding is limited into 16 VLAN only? And can you share the sample configuration of the active forwarding if i have pair of VSX swtiches. Thanks

---

No, there is no limit

it is only limited to 16 V(irtual)MAC by (vlan) interface...

Thanks for the clarification.

Any sample design configuration for the active forwarding using the pai VSX. 

 

Thanks in Advance!

active forwarding or active gateway ?

 

About both, you need to read the documentation

---

@alagoutte wrote:

active forwarding or active gateway ?

 

About both, you need to read the documentation

---

 

Need to setup active forwarding feature of Aruba  VSX, using the OSPF peers, as stated on the diagram. 

 

Thanks!

do you have look the doc ? there is some chapiter about this

Yes already read the document, just to clarify  is using multiple vrf for my LAN departments need to create each transit VLAN as the upstream connection going to the WAN network connection.

 

My question is each TRANSIT VLAN will form OSPF neigbhor from both 8320?

Correct.

For upstream, one transit VLAN per VRF per upstream L3 node.

This makes a triangle: upstream node, VSX primary, VSX secondary. Use OSPF broadcast network-type.

Use vsx active-forwarding on both VSX primary and secondary on each transit VLAN SVI.

Set the L3 node as OSPF DR by setting appropriate DR priority on upstream node (this optimizes uptime during VSX update-software).

Today, we found out that you cannot assign ACLs to a VLAN-Interface.

You can only assign one (1) ingress (and no out) to a physical interface or to a lag group.

 

This is really annoying for a L3-Switch in this price class.

Hope 10.1 will bring this function...

Hello Vestra,

Such capability is on our roadmap.

Just one detail: egress ACL can be applied on routed physical interface.

Regards,

Vincent Giles

Thanks, is there already plan and a date for it?

Hi

I think that you should look at ACL at the access ports too. It is best to enforce security as close to the client as possible.

With ArubaOS-SW and downloadable user roles (DUR) all ACLs are managed in ClearPass and ‘pushed’ dynamically to the access port during port authentication.
For special purposes you can even get more security by using dynamic segmentation (tunneled node)

Hope this helps

ArubaOS-CX 10.01.0001 Release Notes can be found here.

With VSX for L2 MCLAG und for L3 Active-Gateway should be used.

 

The point is that only Active-Gateway OR VRRP can be used on the whole switch. So to start, i don`t want to configure LAG on the old access switches from the customer. Does anybody know if Active-Gateway can be used instead of VRRP without LAG?

 

A quick test shows that it seems to work - but with long switchover times (40-60 pings)

Hi

Active-gateway should be used with mclag AFAIK.
How do you create the redundancy without lag? Spanningtree?

That it works doesn’t mean it should work like that

Thanks, no spanning-tree, loop cannot happen, because each 8320 has only one connection with the aggregation network (and no direct connection between 8320)

Hi

AFAIK you need the ISL link for mclag and maybe even active gateway.
I think with the current setup you have vrrp is more a ‘valid’ option.

I believe that mclag is still a better solution with active gateway.

Hi Vestra,

If you are not using Multi-Chassis LAGs the recommendation is to use VRRP. For example, if you are using MSTP/RPVST, you can make the VRRP V-IP master to be the same as the VLAN/Instance root. That way you optimize the usage of the inter-switch link.

Active gateway may work, but is not designed for that use case.

Regards, Ruben.- 

Now i have the following problem:

The customer has a network with old cisco switches see below. This cannot be changed at the moment.

So i have to attach his two core switches to the 8320, with VSX i have to this with 2x MC-LAG.

 

And now big question: Can this create a loop? Or does VSX mitigate this somehow? (spanning tree cannot be enabled with VSX)

 

Hi 

 

I don't think VSX will solve the loop in your design.

 

If you connect it like that there will be a loop. 

Remember that MCLAG works as a LACP on the cisco switch. So the Cisco switch is 'seeing' it as an LACP to a single switch. In fact there are two switches. MCLAG and ISL is designed to work that way.

 

I would advise a re-design or connect only 1 cisco core switch to the 8320. 

When are the old cisco coreswitches going to be removed?

 

What function do you want to create with the 8320's?:

- core switches?

- L3 routering?