last person joined: an hour 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

5406 VSF and Distributed Trunking

  • 1.  5406 VSF and Distributed Trunking

    Posted Nov 24, 2017 03:40 AM


    actually we use two 5406 with distributed trunking. On these switches are our servers/storage connected with LACP Trunks. These 5406 have an DT-LACP Trunk to single 5412. Now I want to replace the 5412 with two 5406R using VSF. Is it supported to connect the two "old 5406" using distributed trunking and the two 5406R using VSF ? From my understanding it should be possible (Using DT-LACP Trunk on old 5406 and using normal LACP Trunk on new 5406R with VSF).

    Is there any official information about that or has anybody tested this solution ?

  • 2.  RE: 5406 VSF and Distributed Trunking

    Posted Nov 24, 2017 04:55 PM

    Just to be clear...in your actual network topology is there a ISC Link between your two HP 5406 zl Switches? that's to check that your DT-LACP link to the downstream HP 5412 zl Switch is really a DT-LACP link as you described above.


    If I understood you correctly (correct me if I'm wrong), by replacing the downstream HP 5412 zl Switch with a VSF (made of two Aruba 5406R zl2 Switches as a single logical virtual swith), you are asking if the actual DT will be still supported once the downstream switch will become a VSF.


    The answer would be probably "no" because of a specific DT related restriction:


    1. All DT linked switches (and I tend to imagine that HP, with "All DT linked switches" phrasing, meant also the downstream switch) must be running the same software version: AFAIK, the HP 5400 zl doesn't run the same software that run on Aruba 5400R zl2 (branch K versus KB)...since VSF can be deployed only on Aruba 5400R zl2 this imply that a DT terminating on a VSF should not be compatible if upstreaming ISC linked Switches aren't of Aruba 5400R zl2 series too (so one can thus consequently state: two Aruba 5400R zl2 ISC linked for DT would support a VSF as a downstream switch). VSF, on the other hand, was declared not compatible with DT...so it looks like a no-no, no matter the side you look from.

    Clearly would be nice to read about other opinions with regard to this subject.


    PS from another perspective...wouldn't be better to change the actual pair of HP 5406 zl Switch (that rely on ISC for DT-LACP) with a VSF of two modern (and more powerful) Aruba 5406R zl2 Switches?...in this case DT-LACP and ISC link will not be necessary at all (since you will still have a physical switch - the actual 5412 zl - simply LACP trunked with a single logical virtual switch made of two physical switches)...clearly I don't know all the valid reasons (enhance capacity for edge devices served by the HP 5412 zl? probably!) you have to replace the HP 5412 zl with a new VSF instead of implementing the scenario I just supposed....mine is just a collateral consideration.

  • 3.  RE: 5406 VSF and Distributed Trunking

    Posted Nov 27, 2017 01:37 AM

    Thanks for your reply.

    There is a ISC link between the two 5406zl Switches. On the site of the two 5406 there are two ports configured as dt-lacp. On the site of the 5412 there are two ports configured as lacp.

    Regarding "must be the same" firmware version, from my understanding this is only necessary for the switches which are interconnected with the ISC Links.

    When I read the actual manual "HPE ArubaOS-Switch Management and Configuration Guide K_KA_KB.16.02" on page 197:

    .. The grouped links appear to the downstream device as if they are from a single device. This allows third party devices such as switches, servers, or any other networking device that supports trunking to interoperate
    with the distributed trunking switches (DTSs) seamlessly....


    I found the information on VSF & DT not supported too, but my understanding here is, that it is not supported on the same switch.

    I found no information that it is not supported when I connect two pairs with each technology configured.


    Yes, it makes sense to kick the old 5406 switches out and replace this with 5406R and VSF, but we need to replace the 5412 for removing the single point of failure.

  • 4.  RE: 5406 VSF and Distributed Trunking

    Posted Dec 01, 2017 04:52 AM

    Now I have got an official reply from HPe Support:


    Distributed trunking

    The Ethernet link aggregation feature can be used to aggregate physical links between the VSF and its upstream or downstream devices across the VSF members. This eliminates the need for spanning tree and also provides load balancing across all ports of the link aggregate.



    The scenario was tested in HPe Labs and confirmed as "working"


  • 5.  RE: 5406 VSF and Distributed Trunking

    Posted Dec 01, 2017 04:13 PM

    Thanks for starting this thread and I'm not trying to hijack it, but it's the closest thread to my situation I've found.


    We have a 'core' 5406zl with a 2 port LACP trunk (trk5)

    This trunk is connected to a pair of 2930Fs configured in a VSF. 

    One port is connected to the commander of the 2930 VSF, the other port of the trunk is connected to the Standby. 


    If I plug in a dumb device into the Master I can get a DHCP address no problem

    If I plug in a dumb device into the Standy I don't seem to get a DHCP address.  


    I've re-checked my trunk tagging on the trunk port on both ends and can't figure out what I'm missing.  

    From my reading, this is a supported configuration.

  • 6.  RE: 5406 VSF and Distributed Trunking

    Posted Dec 05, 2017 08:33 AM

    I had a remote session with support yesterday.  We managed to determine that this issue looks to be a bug in the firmware.

    When I was first setting up the switches, I had used one of the physical UTP ports as an uplink, and placed it in a trunk.Upon removing that port from the trunk and changing the vlan it appears to no longer function as expected until the system is rebooted.  


    We tested this again, by creating an LACP trunk with two ports, everything worked as expected at this point. We then removed the ports from the trunk, again everything worked as expected. We then changed the untagged vlan assigned to that port and traffic was not passed. If we reset the untagged vlan on the port to the one in use while the port was trunked it did work.  Rebooting cleared the issue.


    The technician I was working with is going to look into it further on their end.