Wired Intelligent Edge

 View Only
last person joined: 18 hours ago 

Bring performance and reliability to your network with the HPE Aruba Networking Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of your switching devices, and find ways to improve security across your network to bring together a mobile-first solution
Expand all | Collapse all

LACP Configuration Assistance

This thread has been viewed 9 times
  • 1.  LACP Configuration Assistance

    Posted Jun 02, 2023 03:06 PM
    Hello all.  I am attempting to create a LACP link between two (CORE)5412R switches, (which are connected to one another via a VSF connection) with one (EDGE)2930M switch.  
    So far, I have applied the following configuration on the 5412's:
    trunk ethernet 1/b2,2/b2 trk2 lacp
    On the 2930M, i have applied the following configuration:
    trunk ethernet b21,b22 trk2 lacp
    Upon applying the configuration, I lose SSH access to the 2930 switch from the 5412R, as it removes all VLANS, (including the management VLAN) from the port.  On the 5412R, when I run the command 'show lacp peer', it does show the the correct System ID (MAC address?) of the 2930, which tells me that the configuration is correct.
    Is there a way to circumvent the removal of the VLANS when creating the LACP link, or would I need to go to every edge switch and console in to retag the required VLANS?   Note: The second link has not been plugged in yet, as I am testing connectivity.  Any assistance or suggestions would be appreciated. 

  • 2.  RE: LACP Configuration Assistance

    Posted Jun 02, 2023 03:43 PM
    Hi! as far as I know a newly created logical interface for port trunking (trk<id>) is automatically made untagged member of Default VLAN 1...so you need to apply required VLAN membership tagging (changing its native VLAN Id and/or adding various tagged VLAN Id) after its creation manually.

  • 3.  RE: LACP Configuration Assistance

    Posted Jun 02, 2023 03:51 PM

    Thanks for confirming.  Also while on subject on VLAN tagging, should the NATIVE VLAN (1) be tagged or untagged on the LACP link, and tagged or untagged on the regular access ports? 

    I know this question is often asked, but I am confused as to whether if it should be.  

  • 4.  RE: LACP Configuration Assistance

    Posted Jun 03, 2023 02:31 AM

    As has been said, you loose connectivity because the newly formed logical interface has no config. But if you before hand make that logical interface by using the trunk command with an unused interface, you can configure the vlans in advance. Then remove the additional physical interface. 

    There are no rules about what should be untagged on a physical or logical interface except that only one vlan can be untagged and on most switch OSs, there must be one set (default is 1). Note that if different at the two end you end up with log entires in some switches. In comware you can have no untagged vlan but for your switch you will always have one even if not configured. 

    I like the best practice of tagging all used vlans. It makes them clear in the config and leaves the untagged for special use cases. Vlan1 is never used anywhere so this unconfigured vlan is passed without effect. 

  • 5.  RE: LACP Configuration Assistance

    Posted Jun 03, 2023 03:47 AM
    Personally I tend to remove Default VLAN id 1 from any port (VLAN 1 context shows you no untagged on each removed port leaving the VLAN 1 existent but without any port as its member). The thumb rule is that a port used for "Access" should be made untagged member of a particular VLAN used for access (!=1) - that is like saying that you will (re)configure the Native VLAN id moving it from 1 to whatever you need on that port (Native VLAN id = the VLAN id the port is untagged with) - and a port used for "Trunk" should be made tagged member of all required VLAN ids you need to allow passing on that port (in this case you are free to remove the Native VLAN id - so its "untagged membership" - since that very port - physical or logical it would be - was already made tagged member of other VLAN ids).