Wired Intelligent Edge

 View Only
last person joined: 2 days 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

LAG between two 8320 clusters for multiple VLANs

This thread has been viewed 9 times
  • 1.  LAG between two 8320 clusters for multiple VLANs

    Posted 15 days ago
    I have 2 VSX Clusters. One has 2 Fiber 8320s and the other is 2 Ethernet 8320s. I currently have two LAGs setup and working between the two clusters using the DAC ports. The LAGs are only one VLAN each.

    I was trying to setup another LAG between the clusters that would carry multiple other VLANs. I was using 1/1/51 for it. I have it set up just like the other LAGs that are working except instead of vlan access # I am using vlan trunk allowed #,#,#.​

    I set up 1 ethernet port on the two ethernet switches and added them to the LAG just to test and that worked. I was wondering, is there any reason why 1/1/51 would not work as a LAG with multiple VLANS? I read somewhere a few times that people had some issues doing something with LAGs, I forget what off hand, but I remember one thing said not sue the bottom row of ports on the swithces...


  • 2.  RE: LAG between two 8320 clusters for multiple VLANs

    Posted 15 days ago
    I have 8325 and use multi chassis LAG with the highest numbers ports (40g optics). They are trunk ports with multiple vlans. I can't think of any reason these would be different to ports 1-48.

    If it wasn't permitted because of hardware limitation i would expect a cli message when you configure.


  • 3.  RE: LAG between two 8320 clusters for multiple VLANs

    MVP GURU
    Posted 15 days ago
    Hi, you initially wrote "I currently have two LAGs setup and working between the two clusters using the DAC ports. The LAGs are only one VLAN each.".

    Just to clarify (maybe it's just me!), does the above sentence mean that your setup was made with two non-VSX LAGs (as you wrote, each one carrying one particular untagged VLAN id only) so it was made with normal LAGs (where a normal LAG is made of two or more physical interfaces of the same VSX member - the Primary or the Secondary - aggregated together instead of being made of two or more interfaces of both VSX members of a particular VSX cluster), say coming from the Primary or the Secondary and terminating to the other VSX cluster Primary or Secondary (or vice-versa) OR does the above sentence mean that your setup was made with two different VSX LAGs each one initiating and terminating in a distributed way on both VSX members of each VSX Cluster with its member interfaces?

    In other words...are you LAGging two VSX Clusters back to back (say from Primary to Primary, Secondary to Secondary or Primary to Secondary/Secondary to Primary) OR are you Multi-Chassis LAGging the first entire VSX cluater to you second entire VSX cluster?

    Then, is there reason you were forced to use two separate (supposedly non MC-LAGs = non VSX LAGs) to separately transport each one a VLAN ID when you could setup a VSX LAG back to back carrying multiple VLAN IDs and aggregating on each side (VSX cluster) up to four physical interfaces per VSX member (having a 4+4=8 ports links aggregation connected to the other VSX cluster)? Any relation with a related (M)STP setup?






  • 4.  RE: LAG between two 8320 clusters for multiple VLANs

    MVP GURU
    Posted 15 days ago
    ...and my above questions are not necessarily tied to the fact that, in my opinion, an "interlink among switches" (or among VSX clusters) - no matter if realized with just one single physical link or with multiple physical links aggregated together into a new logical interface (a LAG or a Multi-Chassis LAG) - should carry only tagged VLANs, the idea of working with an untagged VLAN's membership/transport is typically associated with (VLAN unaware) access devices (indeed you work with Native VLAN on ports designated with the Access/Edge role). Point to Point links generally carry multiple tagged VLAN and the Native VLAN could be, counter-intuitively, declared tagged too (in any case you should allow all of them).