Aruba & ProVision-based
1748028 Members
5114 Online
108757 Solutions
New Discussion юеВ

Re: Smart-Link with LACP Group

 
Mirthrock311
Occasional Contributor

Smart-Link with LACP Group

I have a question about the capabilities of Smart-Link with Trunk Groups.  Before I ask, let me outline my scenario:

I have two HP Aruba 2920-48G switches; one is located in the MDF and the other is in the IDF about 300 feet away.  I have an SFP+ module and fiber transceiver in each switch with LC/LC fiber so that the two switches can communicate over a 10G pipe.  I also have four copper runs between the MDF and IDF.  I've configured the four copper runs in a trunk called Trk1 on each switch.  The copper trunk and fiber line both work fine individually, but I'd like to configure failover from the fiber line to the copper trunk.

Now, the question: Can I use a trunk in a smart-link group?  When configuring the smart-link group, I used the command "smart-link group 1 master" but I don't see an option to add the trunk as a master (or slave for that matter).  It seems that I can only add individual ports.  If smart-link does not work, is there another way to achieve this?

Thanks in advance!

7 REPLIES 7
parnassus
Honored Contributor

Re: Smart-Link with LACP Group

Hi, it seems you're looking for an answer for the same final uncommented question I raised on your other 2920 LACP Redundacy Question thread.

The scenario you're describing here is somewhat very similar to the one you initially outlined there (Here no 2920 Stacking on both ends, there you had two Stacks of 2920...but that doesn't matter...same interconnections links, same desired type of redundancy between your two ends) so the relationships between this thread and the other one are clears: said so, please don't forget to update that thread too if you receive a satisfying answer here...or viceversa.

My final take: Smart Link works with link (port), not with a group of ports (trunk) <-- from the other Thread "...the point is to understand if it can also work between two Stacks and if it [the Smart Link] admits Bridge Aggregation groups as links."


I'm not an HPE Employee
Kudos and Accepted Solution banner
Mirthrock311
Occasional Contributor

Re: Smart-Link with LACP Group

Thank you.  My apologies for starting a new thread.  I was attempting to keep the issue of Smart-Link separate from the first LACP group question.  But, I appreciate your answer in both threads :-)  I will update the other thread momentarily.

I believe that you are correct - I found no way to add a trunk group to the smart-link group.  However, after testing, I believe that Smart-Link is the correct solution for me.  It appears that the failover for Smart-Link is significantly faster than STP.  In our environment, that immediate failover is more important than having a larger pipe for failover.

Last night, I attempted to configure the Smart-Link group to pass traffic from our two VLANs - 1 and 58.  The commands I ran and my understanding of each command are below.  The issue I'm experiencing is that the slave link will not pass any traffic, but I'm unsure why.  I can see that the slave link is marked as active and if I reconnect the master link, it takes over immediately.  So, the functionality appears to work, but traffic will not flow.

smart-link group 1 master 1/A1   *sets fiber as primary link
smart-link group 1 slave 4/48   *sets copper as failover linksmart-link group 1 preemption-mode role   *allows link to fail back to fiber once available
smart-link group 1 protected-vlans 1-58   *allows failover link to pass vlan range 1-58 since individual VLANs can't be specified
smart-link group 1 trap enable   *enables SNMP traps
smart-link group 1 send-control-vlan 1 *allows VLAN 1 to send flush packets

My confusion: I'm not sure what the last command actually does.  I'm not familiar with flush packets and I wasn't able to find any helpful documentation on how they work.  I'm not sure if that last command has anything to do with my issues and I'm not knowledgeable enough about Smart-Link to troubleshoot.

Any help would be much appreciated.

 

parnassus
Honored Contributor

Re: Smart-Link with LACP Group

Great! The idea of using the Thick Pipe as the Smart Link Master port and the Thin Pipe as the Smart Link Slave port is very reasonable...and it's simple (using the Thin Pipe is, indeed, only for exceptional cases and limited in time).

Have you tried to execute also the smart-link recv-control-vlan vid-list command (which is an interface level command) that must be executed for both the Master and the Slave port?

If the option send-control-vlan vid defines the single VLAN to send flush packets I think the other option recv-control-vlan vid-list defines the VLANs to receive flush packets...but what are those flush packets I don't know!

What the debug smart-link group 1, show smart-link group 1 and show smart-link recv-control-vlans commands report?

The more I read about Smart Link feature the more I like it...the 2nd point to clarify is that if it was engineered to work against two different Switches - instead of just one as per you scenario - as the diagram below seems to suggest (it's not clear and no restrictions were cited but...):

Smart_Link.png

 

 

A side note about the option preemption-mode: as I undersood it (correct me if I'm wrong!) when setting the option preemption-mode to Off (which is the default value) that means you use the Role mode (check it with the show smart link group 1 command) and if you use the Role mode once the Master port comes back up from a failure it goes in stand-by mode and it does not forwarding traffic at all leaving the forwarding role to the Slave port (which, as I understood, is not what you really want)...so if you want that your Master port, once it comes back up, becomes Active again (after a specified preemption delay time) IMHO you need to set the preemption-mode option to forced with the preemption-delay option set to its minium possible value (which is 1 second as per default).


I'm not an HPE Employee
Kudos and Accepted Solution banner
parnassus
Honored Contributor

Re: Smart-Link with LACP Group

In a old H3C document (So very Comware biased) I found that:

  1. A "legal" flush message (packets) refers to the message whose control VLAN ID is consistent with the receiving control VLAN ID configured on the receiving port. A little bit crypticc but better than nothing.
  2. Smart Link and STP cannot be enabled together on the same involved port at the same time, STP must be disabled on that port before assigning the port to a Smart Link Group. Another point to check.
  3. Besides assigning single ports to a Smart Link Group, a LAG can be assigned too BUT it should be Static or Manual (not LACP). So maybe it could work.

Here we go with some more informations about Smart Link (from Huawei).


I'm not an HPE Employee
Kudos and Accepted Solution banner
Mirthrock311
Occasional Contributor

Re: Smart-Link with LACP Group

This is all great information.  Since the switches are in production, I won't get a chance to test this today.  Most likely it will be Monday or Tuesday of next week.  I will update the thread once I get some new info.

A few thoughts/questions:

Would I need to configure the send-control-vlan and recv-control-vlan command for each VLAN that I use?
I'm curious if the send-control-vlan and recv-control-vlan commands need to be issues on separate switches.  For example, would Switch A (where I'm configuring Smart-Link) be the sender and Switch B be the receiver?  I noticed that you can run the smart-link commands directly on an interface as well.
I'll research smart-link with LAGs a bit later and worry about adding that level of complexity after I get it up and running with  single Master and Slave interfaces.

 

Thanks again for all the help!

 

parnassus
Honored Contributor

Re: Smart-Link with LACP Group


@Mirthrock311 wrote:

Would I need to configure the send-control-vlan and recv-control-vlan command for each VLAN that I use?

I think it's not the purpose for that options, to create a Smart Link the main steps should be:

  1. Create a Smart Link Group with smart link group group-id command, once you create it without any options you enter into the smart link group context where you then will be able to define the other various options: master port, slave port, protected-vlans vid-list, send-control-vlan vid, preemption-mode off | forced | bandwidth, preemption-delay 10-max, trap enable | disable. So this means that the send-control-vlan vid option is related to the Smart Link Group context and not to a specific interface.
  2. Configure (Receving Control) VLANs with the interface level command, that must be executed for both Master and Slave ports, smart link recv-control-vlan vid-list.
  3. Eventually enable Smart Link debugging with the command debug smart link group group-id | all flush-packets (this is not mandatory).

So there isn't anything related to uplinked Switch(es): AFAIK, the Smart Link seems a feature that born and die within the only one Switch from which the Primary/Backup connections depart (exactly from the Access Switch on the diagram above) and so doesn't involve other configurations in other (distribution) Switch(es).

It's like Smart Link feature permits its Switch to act blinded disregarding what "receiving" Switch(es) does/do (so Smart Link can't be compared to Port Trunking where both ends should be configured to basically agree about their interconnections).


I'm curious if the send-control-vlan and recv-control-vlan commands need to be issues on separate switches.  For example, would Switch A (where I'm configuring Smart-Link) be the sender and Switch B be the receiver?  I noticed that you can run the smart-link commands directly on an interface as well.

Mmmm...I think those commands don't need to be executed on "receiver" Switch(es), see above.


 


I'm not an HPE Employee
Kudos and Accepted Solution banner
parnassus
Honored Contributor

Re: Smart-Link with LACP Group

Not to create confusion...but, despite my initial toughts, I discovered that Smart Link configuration, at least when performed on Comware 7.10 based Switches (so not on Aruba 2920 which is ProVision based), is a little bit more complex than expected (the Smart Link documentation for ProVision based Switches, from this point of view, seems to lack a little bit) and involves some basic configurations also on uplink destination ports of the associated Switches, especially regarding the enablement for receiving Flush Messages on defined control VLAN (or VLANs, if many systems are involved).

Basically it seems that is only necessary to enable Smart Link Flush Messages on uplink destination ports (Primary and Secondary) of the associated Switches following these general guidelines:

  • If no Control VLAN is specified for processing Flush Messages, the device forwards the received Flush Messages without any processing.
  • Make sure the Receive Control VLAN is the same as the Transmit Control VLAN configured on the Smart Link device. If they are not the same, the associated device will forward the received Flush Messages directly without any processing.
  • Do not remove the Control VLANs, oherwise, Flush Messages cannot be sent correctly.
  • Make sure the Control VLANs are existing VLANs, and assign the ports capable of receiving Flush Messages to the Control VLANs.

Translated in commands (supposing the originating Smart Link device sends Flush Messages using, as example, the Control VLAN 10 - flush enable control-vlan 10 - enabled for each of one of its Smart Link Groups):

[Device_B] interface ten-gigabitethernet 1/0/1
[Device_B-Ten-GigabitEthernet1/0/1] port link-type trunk
[Device_B-Ten-GigabitEthernet1/0/1] port trunk permit vlan 1 to 30
[Device_B-Ten-GigabitEthernet1/0/1] smart-link flush enable control-vlan 10
[Device_B-Ten-GigabitEthernet1/0/1] quit
[Device_B] interface ten-gigabitethernet 1/0/3
[Device_B-Ten-GigabitEthernet1/0/3] port link-type trunk
[Device_B-Ten-GigabitEthernet1/0/3] port trunk permit vlan 1 to 30
[Device_B-Ten-GigabitEthernet1/0/3] undo stp enable
[Device_B-Ten-GigabitEthernet1/0/3] smart-link flush enable control-vlan 20
[Device_B-Ten-GigabitEthernet1/0/3] quit

Note that there are two ports involved (1/0/1 and 1/0/3) because the Device_B receives trunks concurrently from two different Smart Links devices (which use two different Control VLANs, respectively 10 and 20, to send theirs Control Messages to the associated Device_B).

So again, apart from configuration differences, it's unclear if Smart Link will admit a 1:1 relationship with just one associated Switch per each Smart Link Switch instead of 1:2 (or many) with at least 2 differents associated Switches per each Smart Link Switch.

Reference: HPE 5920 & 5900 Switch Series High Availability Configuration Guide.

 

 


I'm not an HPE Employee
Kudos and Accepted Solution banner