GVRP stands for GARP VLAN Registration Protocol and is a GARP application that registers and deregisters VLAN attributes. It uses Generic Attribute Registration Protocol (GARP), to maintain and propagate dynamic VLAN registration information, throughout GVRP enabled devices on the network.

GVRP lets a device to propagate local VLAN registration information to other participant devices, and to dynamically update the VLAN registration information from other devices to its local database, including active VLAN members and through which port they can be reached. All GVRP participants on a bridged LAN maintain the same VLAN registration information. The VLAN registration information includes both manually configured local static entries and dynamic entries from other devices.

There are 3 different registration modes:

1. Normal – allows dynamic VLAN registration and deregistration on the trunk port, and allows the declarations for dynamic and static VLANs to be sent.
2. Fixed – prevents dynamic VLAN registration and deregistration on the trunk port, and allows only the declarations for static VLANs to be sent.
3. Forbidden – prevents dynamic VLAN registration and deregistration on the trunk port, and allows only the declarations for VLAN 1 to be sent.

Let’s look at our topology. What we want to do is to check how GVRP works:

GARP identifies applications through destination MAC addresses. IEEE 802.1Q assigns 01-80-C2-00-00-21 to the VLAN application (GVRP):

Create VLANs 100, 150 and 200 on Access SW1 (configuration of Access SW2 is omitted here):

[Access SW1]vlan batch 100 150 200
Info: This operation may take a few seconds. Please wait for a moment...done.
[Access SW1]

Add Ethernet interfaces to proper VLANs:

[Access SW1]interface Ethernet0/0/1
[Access SW1-Ethernet0/0/1]port link-type access
[Access SW1-Ethernet0/0/1]port default vlan 100

[Access SW1]interface Ethernet0/0/2
[Access SW1-Ethernet0/0/2]port link-type access
[Access SW1-Ethernet0/0/2]port default vlan 150

[Access SW1]interface Ethernet0/0/3
[Access SW1-Ethernet0/0/3]port link-type access
[Access SW1-Ethernet0/0/3]port default vlan 200

Configure trunks between Access switches and Distribute switch and permit all VLANs to pass through (configuration of Distribution SW is omitted here):

[Access SW1]interface GigabitEthernet0/0/2
[Access SW1-GigabitEthernet0/0/2]port link-type trunk
[Access SW1-GigabitEthernet0/0/2]port trunk allow-pass vlan all

Enable GVRP globally on all switches:

[Access SW1]gvrp

Enable GVRP on all trunk interfaces in the network:

[Access SW1-GigabitEthernet0/0/2]gvrp

Verification:

[Access SW1]display vlan summary 
static vlan:
Total 4 static vlan.
  1 100 150 200 

dynamic vlan:
Total 0 dynamic vlan.

reserved vlan:
Total 0 reserved vlan.

[Access SW2]dis vlan sum
static vlan:
Total 3 static vlan.
  1 100 150 

dynamic vlan:
Total 1 dynamic vlan.
  200 

reserved vlan:
Total 0 reserved vlan.

[Distribution SW]display vlan summary 
static vlan:
Total 1 static vlan.
  1 

dynamic vlan:
Total 3 dynamic vlan.
  100 150 200 

reserved vlan:
Total 0 reserved vlan.

PC1>ping 10.0.0.2

Ping 10.0.0.2: 32 data bytes, Press Ctrl_C to break
From 10.0.0.2: bytes=32 seq=1 ttl=128 time=63 ms
From 10.0.0.2: bytes=32 seq=2 ttl=128 time=62 ms
From 10.0.0.2: bytes=32 seq=3 ttl=128 time=62 ms
From 10.0.0.2: bytes=32 seq=4 ttl=128 time=47 ms
From 10.0.0.2: bytes=32 seq=5 ttl=128 time=47 ms

--- 10.0.0.2 ping statistics ---
  5 packet(s) transmitted
  5 packet(s) received
  0.00% packet loss
  round-trip min/avg/max = 47/56/63 ms

PC2>ping 10.0.1.6

Ping 10.0.1.6: 32 data bytes, Press Ctrl_C to break
From 10.0.1.6: bytes=32 seq=1 ttl=128 time=47 ms
From 10.0.1.6: bytes=32 seq=2 ttl=128 time=63 ms
From 10.0.1.6: bytes=32 seq=3 ttl=128 time=109 ms
From 10.0.1.6: bytes=32 seq=4 ttl=128 time=62 ms
From 10.0.1.6: bytes=32 seq=5 ttl=128 time=63 ms

--- 10.0.1.6 ping statistics ---
  5 packet(s) transmitted
  5 packet(s) received
  0.00% packet loss
  round-trip min/avg/max = 47/68/109 ms

Now configure GVRP registration mode as fixed on the trunk between Access SW1 and Distribution SW:

[Access SW1-GigabitEthernet0/0/2]gvrp registration fixed
[Distribution SW-GigabitEthernet0/0/1]gvrp registration fixed
[Distribution SW]display gvrp statistics

  GVRP statistics on port GigabitEthernet0/0/1 
    GVRP status				: Enabled
    GVRP registrations failed		: 291
    GVRP last PDU origin		: 4c1f-cc46-e9ad
    GVRP registration type		: Fixed

  GVRP statistics on port GigabitEthernet0/0/2 
    GVRP status				: Enabled
    GVRP registrations failed		: 0
    GVRP last PDU origin		: 4c1f-ccea-7bb8
    GVRP registration type		: Normal

Display VLANs on Distribution and Access SW2 switches:

[Distribution SW]display vlan sum
static vlan:
Total 1 static vlan.
  1 

dynamic vlan:
Total 2 dynamic vlan.
  100 150 

reserved vlan:
Total 0 reserved vlan.

[Access SW2]display vlan summary 
static vlan:
Total 3 static vlan.
  1 100 150 

dynamic vlan:
Total 0 dynamic vlan.

reserved vlan:
Total 0 reserved vlan.

As you can see VLAN 200 is not passing anymore.

Let’s assume that we have a Frame Relay topology like in the picture below. We want to have full IP connectivity between our ‘labnario’ routers. To demonstrate, how to configure different types of Frame Relay interface, I will use:

• physical serial interface on labnario1 router
• logical point-to-point interface on labnario2 router
• logical point-to-multipoint interface on labnario3 router.

Let’s start with labnario1 configuration.

<labnario1>system-view 
[labnario1]interface Serial0/0/0
[labnario1-Serial0/0/0] link-protocol fr
[labnario1-Serial0/0/0] fr map ip 123.100.1.2 102 broadcast
[labnario1-Serial0/0/0] fr map ip 123.100.1.3 103 broadcast
[labnario1-Serial0/0/0] ip address 123.100.1.1 255.255.255.0

This is a physical interface which acts as a multipoint interface. All IP to DLCI mappings as well as IP address configuration, should be done under a physical serial interface. Broadcast option at the end of DLCI mapping statement should be added, if we want to send multicast or broadcast packets over this interface. This is required especially, when we are planning to use a dynamic routing protocol over this interface.

Now I want to configure labnario2 router. I will use a logical p2p subinterface.

[labnario2]interface Serial0/0/0
[labnario2-Serial0/0/0] link-protocol fr
[labnario2-Serial0/0/0] interface Serial0/0/0.201 p2p
[labnario2-Serial0/0/0.201] fr dlci 201
[labnario2-fr-dlci-Serial0/0/0.201-201] ip address 123.100.1.2 255.255.255.0

As you can see, there is no fr map ip statement under a point-to-point subinterface. We do not need it, because only one PVC can be assigned to this type of subinterface. All packets with a destination IP address from the range of 123.100.1.0/24, will be routed through this PVC.

On the labnario3 router I will use a logical p2mp subinterface.

[labnario3]interface Serial0/0/0
[labnario3-Serial0/0/0] link-protocol fr
[labnario3-Serial0/0/0] interface Serial0/0/0.301
[labnario3-Serial0/0/0.301] fr map ip 123.100.1.1 301 broadcast
[labnario3-Serial0/0/0.301] fr map ip 123.100.1.2 301 broadcast
[labnario3-Serial0/0/0.301] ip address 123.100.1.3 255.255.255.0

Logical point-2-multipoint frame relay interface configuration is similar to physical interface, as both are multipoint. The only difference is that DLCI to IP mappings and IP address should be configured under a logical serial subinterface not under a physical serial interface.

How to verify if our frame relay interface is working correctly?

First I want to check connectivity between routers.

<labnario1>ping 123.100.1.2
  PING 123.100.1.2: 56  data bytes, press CTRL_C to break
    Reply from 123.100.1.2: bytes=56 Sequence=1 ttl=255 time=90 ms
    Reply from 123.100.1.2: bytes=56 Sequence=2 ttl=255 time=80 ms
    Reply from 123.100.1.2: bytes=56 Sequence=3 ttl=255 time=70 ms
    Reply from 123.100.1.2: bytes=56 Sequence=4 ttl=255 time=70 ms
    Reply from 123.100.1.2: bytes=56 Sequence=5 ttl=255 time=70 ms
<output ommited>

<labnario1>ping 123.100.1.3
  PING 123.100.1.3: 56  data bytes, press CTRL_C to break
    Reply from 123.100.1.3: bytes=56 Sequence=1 ttl=255 time=80 ms
    Reply from 123.100.1.3: bytes=56 Sequence=2 ttl=255 time=50 ms
    Reply from 123.100.1.3: bytes=56 Sequence=3 ttl=255 time=90 ms
    Reply from 123.100.1.3: bytes=56 Sequence=4 ttl=255 time=70 ms
    Reply from 123.100.1.3: bytes=56 Sequence=5 ttl=255 time=30 ms
<output ommited>

<labnario1>ping 123.100.1.3
  PING 123.100.1.3: 56  data bytes, press CTRL_C to break
    Reply from 123.100.1.3: bytes=56 Sequence=1 ttl=255 time=85 ms
    Reply from 123.100.1.3: bytes=56 Sequence=2 ttl=255 time=50 ms
    Reply from 123.100.1.3: bytes=56 Sequence=3 ttl=255 time=90 ms
    Reply from 123.100.1.3: bytes=56 Sequence=4 ttl=255 time=70 ms
    Reply from 123.100.1.3: bytes=56 Sequence=5 ttl=255 time=30 ms
<output ommited>

Labnario1 uses a physical frame relay interface. Below are some useful troubleshooting commands:

[labnario1]dis fr int s0/0/0 
Serial0/0/0, DTE, physical up, protocol up

This is a DTE side, frame relay switch acts as a DCE.

To verify frame relay mappings configuration:

[labnario1]display fr map-info 
Map Statistics for interface Serial0/0/0 (DTE)
  DLCI = 102, IP 123.100.1.2, Serial0/0/0
    create time = 2012/12/13 11:41:12, status = ACTIVE
    encapsulation = ietf, vlink = 683, broadcast
  DLCI = 103, IP 123.100.1.3, Serial0/0/0
    create time = 2012/12/13 11:41:12, status = ACTIVE
    encapsulation = ietf, vlink = 684, broadcast

For PVC status verification, use:

[labnario1]display fr pvc-info
PVC statistics for interface Serial0/0/0 (DTE, physical DOWN)
  DLCI = 102, USAGE = LOCAL (00000100), Serial0/0/0
    create time = 2012/12/13 11:41:12, status = ACTIVE
    InARP = Enable
    in BECN = 0, in FECN = 0
    in packets = 424, in bytes = 13474
    out packets = 446, out bytes = 14108
  DLCI = 103, USAGE = LOCAL (00000100), Serial0/0/0
    create time = 2012/12/13 11:41:12, status = ACTIVE
    InARP = Enable
    in BECN = 0, in FECN = 0
    in packets = 303, in bytes = 9438
    out packets = 525, out bytes = 16244

The same commands on labnario2:

[labnario2]dis fr interface s0/0/0.201
Serial0/0/0.201, point-to-point, DTE, physical up, protocol up

[labnario2]dis fr map-info
Map Statistics for interface Serial0/0/0 (DTE)
  DLCI = 201, Point-to-Point DLCI, Serial0/0/0.201
    create time = 2012/12/13 11:41:15, status = ACTIVE

[labnario2]dis fr pvc-info
PVC statistics for interface Serial0/0/0 (DTE, physical UP)
  DLCI = 201, USAGE = LOCAL (00000010), Serial0/0/0.201
    create time = 2012/12/13 11:41:15, status = ACTIVE
    InARP = Enable
    in BECN = 0, in FECN = 0
    in packets = 780, in bytes = 24128
    out packets = 781, out bytes = 24300

Labnario3 verification:

[labnario3]dis fr int s0/0/0.301
Serial0/0/0.301, multi-point, DTE, physical up, protocol up

[labnario3]dis fr map-info
Map Statistics for interface Serial0/0/0 (DTE)
  DLCI = 301, IP 123.100.1.1, Serial0/0/0.301
    create time = 2012/12/13 11:41:15, status = ACTIVE
    encapsulation = ietf, vlink = 7, broadcast
  DLCI = 301, IP 123.100.1.2, Serial0/0/0.301
    create time = 2012/12/13 11:41:15, status = ACTIVE
    encapsulation = ietf, vlink = 8, broadcast

[labnario3]dis fr pvc-info
PVC statistics for interface Serial0/0/0 (DTE, physical UP)
  DLCI = 301, USAGE = LOCAL (00000100), Serial0/0/0.301
    create time = 2012/12/13 11:41:15, status = ACTIVE
    InARP = Enable
    in BECN = 0, in FECN = 0
    in packets = 918, in bytes = 28034
    out packets = 970, out bytes = 29564

Some debugging commands:

<labnario2>debugging fr ?
  all          All debugging functions 
  compression  FR compression
  event        Event debugging functions 
  inarp        INARP debugging functions 
  ipc          IPC/RPC debugging functions
  lmi          LMI debugging functions 
  mfr          Multilink FR debugging
  packet       Packet debugging functions

Network administrators often need to capture packets, on switches or routers, to locate faults. Some devices do not support remote mirroring, that’s why administrators have to go on-site to capture packets, using local mirroring.

We have a useful command (capture-packet …), on some devices, to catch packets remotely. When taking S5700 switch into consideration, we can capture all packets from an interface (port mirroring) or packets matching specified rules (traffic mirroring). These capture packets can be sent to FTP or TFTP servers and displayed on terminal screen. CX600 and NE40E routers with V6R3 software version can send capture packets to local CF card (name.cap file).

Let’s look at this command:

[Huawei]capture-packet ?
  acl        Acl
  cpu        Packet send to cpu
  interface  Ingress Interface

As you can see you can use port or traffic mirroring. You can also catch packets sent to CPU.

[Huawei]capture-packet interface GigabitEthernet 0/0/1 destination ?
  ftp-server   Send to ftp server
  terminal     Output terminal
  tftp-server  Send to tftp server

These options let you to send capture packets to FTP server, TFTP server or terminal.

Let’s assume that we want to catch packets on interface GE0/0/1 and display this information on terminal screen:

[Huawei]capture-packet interface GigabitEthernet 0/0/1 destination terminal 
Info: Captured packets will be shown on terminal. 
[Huawei]
  Packet: 1
  -------------------------------------------------------
  4c 1f cc 66 48 a4 54 89 98 16 84 42 81 00 00 01 
  08 00 45 00 00 54 01 ad 00 00 ff 01 b1 f3 02 02 
  02 02 02 02 02 03 08 00 cb 2f cf ab 01 00 e4 d3 
  42 00 06 0e 05 00 00 01 02 03 04 05 06 07 08 09 
  0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 
  1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 
  2a 2b 2c 2d 2e 2f 
  -------------------------------------------------------

  Packet: 2
  -------------------------------------------------------
  4c 1f cc 66 48 a4 54 89 98 16 84 42 81 00 00 01 
  08 00 45 00 00 54 01 ae 00 00 ff 01 b1 f2 02 02 
  02 02 02 02 02 03 08 00 a4 2d cf ab 02 00 0a d6 
  42 00 06 0e 05 00 00 01 02 03 04 05 06 07 08 09 
  0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 
  1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 
  2a 2b 2c 2d 2e 2f 
  -------------------------------------------------------

  Packet: 3
  -------------------------------------------------------
  4c 1f cc 66 48 a4 54 89 98 16 84 42 81 00 00 01 
  08 00 45 00 00 54 01 af 00 00 ff 01 b1 f1 02 02 
  02 02 02 02 02 03 08 00 91 2b cf ab 03 00 1c d8 
  42 00 06 0e 05 00 00 01 02 03 04 05 06 07 08 09 
  0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 
  1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 
  2a 2b 2c 2d 2e 2f 
  -------------------------------------------------------

  Packet: 4
  -------------------------------------------------------
  4c 1f cc 66 48 a4 54 89 98 16 84 42 81 00 00 01 
  08 00 45 00 00 54 01 b0 00 00 ff 01 b1 f0 02 02 
  02 02 02 02 02 03 08 00 7e 29 cf ab 04 00 2e da 
  42 00 06 0e 05 00 00 01 02 03 04 05 06 07 08 09 
  0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 
  1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 
  2a 2b 2c 2d 2e 2f 
  -------------------------------------------------------

  Packet: 5
  -------------------------------------------------------
  4c 1f cc 66 48 a4 54 89 98 16 84 42 81 00 00 01 
  08 00 45 00 00 54 01 b1 00 00 ff 01 b1 ef 02 02 
  02 02 02 02 02 03 08 00 75 27 cf ab 05 00 36 dc 
  42 00 06 0e 05 00 00 01 02 03 04 05 06 07 08 09 
  0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 
  1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 
  2a 2b 2c 2d 2e 2f 
  -------------------------------------------------------

Few precautions for capture-packet command:

• If connection to FTP or TFTP servers fails, switch saves capture information locally.
• This command can be only used for upstream traffic.
• Capture packet command is not saved in configuration file.
• You have to wait, to use capture-packet command again, till the last command execution is completed.

More details you can find in product documentation.

What we want to do is to configure 802.1q trunk between labnario1 router and labnarioSW1 switch, so that hosts from VLAN 100 will be able to ping the router’s interface.

Let’s look at the simple topology:

First we want to configure labnario1 router. To configure Ge0/0/1 interface to operate as a 802.1q trunk, we need to configure it as follows:

<labnario1>system-view
[labnario1]
[labnario1]interface GigabitEthernet 0/0/1
[labnario1-GigabitEthernet0/0/1]portswitch
[labnario1-GigabitEthernet0/0/1]port link-type trunk

Now we need to configure subinterface in VLAN 100 and define IP address. Of course our subinterface should be in the same VLAN as our hosts.

[labnario1]interface GigabitEthernet0/0/1.100
[labnario1-GigabitEthernet0/0/1.100]vlan-type dot1q 100
[labnario1-GigabitEthernet0/0/1.100]ip address 150.100.0.1 255.255.255.0

Labnario1 router configuration is finished. Now we can start configuring labnarioSW1 switch. Let’s start with 802.1q trunk configuration:

<labnario1>sys
[LabnarioSW1]
[LabnarioSW1]int GigabitEthernet 0/0/1
[LabnarioSW1-GigabitEthernet0/0/1]port link-type trunk
[LabnarioSW1-GigabitEthernet0/0/1]port trunk allow-pass vlan 100

Now we can add our hosts to VLAN 100:

[LabnarioSW1]interface Ethernet0/0/1
[LabnarioSW1-Ethernet0/0/1]port link-type access
[LabnarioSW1-Ethernet0/0/1] port default vlan 100
[LabnarioSW1]interface Ethernet0/0/2
[LabnarioSW1-Ethernet0/0/1]port link-type access
[LabnarioSW1-Ethernet0/0/1] port default vlan 100

As a last part of this configuration we need to add VLANIF interface on labnarioSW1:

[LabnarioSW1-Ethernet0/0/1]int vlanif100
[LabnarioSW1-Vlanif100]ip add 150.100.0.2 255.255.255.0

Both devices are configured. Let’s check if our hosts are able to ping router’s interface:

PC1>ping 150.100.0.2

Ping 150.100.0.2: 32 data bytes, Press Ctrl_C to break
From 150.100.0.2: bytes=32 seq=1 ttl=255 time=16 ms
From 150.100.0.2: bytes=32 seq=2 ttl=255 time=15 ms
From 150.100.0.2: bytes=32 seq=3 ttl=255 time=16 ms
From 150.100.0.2: bytes=32 seq=4 ttl=255 time=16 ms
From 150.100.0.2: bytes=32 seq=5 ttl=255 time=15 ms

--- 150.100.0.2 ping statistics ---
  5 packet(s) transmitted
  5 packet(s) received
  0.00% packet loss
  round-trip min/avg/max = 0/12/16 ms

PC2>ping 150.100.0.1

Ping 150.100.0.1: 32 data bytes, Press Ctrl_C to break
From 150.100.0.1: bytes=32 seq=1 ttl=255 time=16 ms
From 150.100.0.1: bytes=32 seq=2 ttl=255 time=78 ms
From 150.100.0.1: bytes=32 seq=3 ttl=255 time=47 ms
From 150.100.0.1: bytes=32 seq=4 ttl=255 time=16 ms
From 150.100.0.1: bytes=32 seq=5 ttl=255 time=47 ms

--- 150.100.0.1 ping statistics ---
  5 packet(s) transmitted
  5 packet(s) received
  0.00% packet loss
  round-trip min/avg/max = 16/40/78 ms

Link aggregation, in other words trunking, is a technique that helps to increase bandwidth by bundling multiple physical interfaces into a logical one, named Eth-trunk. Besides bandwidth increase, trunking lets us to implement load-balancing and ensure higher reliability.

Few restrictions must be taken into consideration when creating Eth-trunk interface:

• parameters of physical interfaces (number, transmission rate, duplex mode and traffic-control mode) on both ends of the trunk link must be consistent.
• data sequence must be unchanged (frames belonging to the same data flow are transmitted over the same physical link).

Eth-Trunk interfaces configured on S5700 switch support the following features:

• Layer 2 forwarding and Layer 3 forwarding (unicast and multicast).
• Hash algorithm-based load balancing.
• QoS on the trunk interface.

There are 2 methods of link aggregation:

• manual load balancing mode

Usually used if one of the devices, connected by Eth-trunk, does not support LACP. All active members interfaces forward data and perform load balancing. If an active link of the link aggregation group fails, traffic is balanced among the remaining active links. LACP is disabled.

• static LACP mode.

LACP is enabled. When physical interfaces are added to an Eth-Trunk interface, devices at both ends negotiate aggregation parameters and determine active and inactive interfaces by sending LACPDUs to each other. Inactive interfaces are used for redundancy backup. When an active link fails, the backup link with the highest priority replaces the failed link and changes its status to active. The device in the link aggregation group with a higher LACP priority is the Actor, and the device with a lower LACP priority is the Partner. In case when they have the same LACP priority, the device with smaller MAC address becomes the Actor.

The process of setting up an Eth-Trunk link in static LACP mode:

• LACP PDUs are sent between devices at both ends
• Based on LACP system priority the Actor is determined.
• Active interfaces are determined based on Actor’s LACP priority and interface ID (load-balancing is implemented across these active links).

Let’s look at the topology:

As a configuration of manual load balancing mode is simple, we will focus on static LACP mode.

Based on the topology configure all necessary IP addresses:

labnario_1

#
interface Vlanif100
 ip address 10.0.0.1 255.255.255.0
#
interface GigabitEthernet0/0/23
 port link-type access
 port default vlan 100
#
interface GigabitEthernet0/0/24
 port link-type access
 port default vlan 100

labnario_2

#
interface Vlanif100
 ip address 10.0.0.2 255.255.255.0
#
interface LoopBack0
 ip address 4.4.4.4 255.255.255.255

Create Eth-trunk interface on both switches (labnario_1 as an example):

[labnario_1]interface Eth-Trunk 1
[labnario_1-Eth-Trunk1]bpdu enable 
[labnario_1-Eth-Trunk1]mode lacp-static

Add member interfaces to the Eth-trunk on both switches:

[labnario_1-Eth-Trunk1]trunkport GigabitEthernet 0/0/1 to 0/0/3 
Info: This operation may take a few seconds. Please wait for a moment....done.

You can add members to Eth-trunk in interface view as well.

Set the system priority on labnario_1 to 10 so that it becomes the Actor and set maximum of active interfaces to 2:

[labnario_1]lacp priority 10
[labnario_1]interface Eth-Trunk 1
[labnario_1-Eth-Trunk1]max active-linknumber 2

Verify the configuration on both switches:

[labnario_1]dis eth-trunk 1
Eth-Trunk1's state information is:
Local:
LAG ID: 1                   WorkingMode: STATIC                               
Preempt Delay: Disabled     Hash arithmetic: According to SIP-XOR-DIP         
System Priority: 10         System ID: 4c1f-cce4-15b4                         
Least Active-linknumber: 1  Max Active-linknumber: 2                          
Operate status: up          Number Of Up Port In Trunk: 2                     
--------------------------------------------------------------------------------

ActorPortName          Status   PortType PortPri PortNo PortKey PortState Weight

GigabitEthernet0/0/1   Selected 1000TG   32768   2      401     10111100  1     

GigabitEthernet0/0/2   Selected 1000TG   32768   3      401     10111100  1     

GigabitEthernet0/0/3   Unselect 1000TG   32768   4      401     10100000  1     

Partner:
--------------------------------------------------------------------------------

ActorPortName          SysPri   SystemID        PortPri PortNo PortKey PortState

GigabitEthernet0/0/1   32768    4c1f-ccb8-cad1  32768   2      401     10111100

GigabitEthernet0/0/2   32768    4c1f-ccb8-cad1  32768   3      401     10111100

GigabitEthernet0/0/3   32768    4c1f-ccb8-cad1  32768   4      401     10110000

[labnario_1]display trunkmembership eth-trunk 1
Trunk ID: 1 
Used status: VALID 
TYPE: ethernet 
Working Mode : Static 
Number Of Ports in Trunk = 3
Number Of Up Ports in Trunk = 2
Operate status: up 

Interface GigabitEthernet0/0/1, valid, operate up, weight=1
Interface GigabitEthernet0/0/2, valid, operate up, weight=1
Interface GigabitEthernet0/0/3, valid, operate down, weight=1

[labnario_2]dis eth-trunk 1
Eth-Trunk1's state information is:
Local:
LAG ID: 1                   WorkingMode: STATIC                               
Preempt Delay: Disabled     Hash arithmetic: According to SIP-XOR-DIP         
System Priority: 32768      System ID: 4c1f-ccb8-cad1                         
Least Active-linknumber: 1  Max Active-linknumber: 8                          
Operate status: up          Number Of Up Port In Trunk: 2                     
--------------------------------------------------------------------------------

ActorPortName          Status   PortType PortPri PortNo PortKey PortState Weight

GigabitEthernet0/0/1   Selected 1000TG   32768   2      401     10111100  1     

GigabitEthernet0/0/2   Selected 1000TG   32768   3      401     10111100  1     

GigabitEthernet0/0/3   Unselect 1000TG   32768   4      401     10110000  1     

Partner:
--------------------------------------------------------------------------------

ActorPortName          SysPri   SystemID        PortPri PortNo PortKey PortState

GigabitEthernet0/0/1   10       4c1f-cce4-15b4  32768   2      401     10111100

GigabitEthernet0/0/2   10       4c1f-cce4-15b4  32768   3      401     10111100

GigabitEthernet0/0/3   10       4c1f-cce4-15b4  32768   4      401     10100000

As you can see 2 ports are selected, valid and in UP state, LACP priority is 10, default port priority is 32768, default hash arithmetic is SIP-XOR-DIP (source and destination IP, it can be different on different switches).

Try to change GE0/0/1 and GE0/0/3 ports to be selected and make GE0/0/2 unselected, by configuring LACP priority on the interfaces. A smaller priority value indicates a higher LACP priority. Remember to enable LACP preemption function on Eth-trunk. The LACP preemption function ensures that the interface with the highest LACP priority always functions as an active interface, even if it comes back to UP state after a failure.

[labnario_1]int gig 0/0/1
[labnario_1-GigabitEthernet0/0/1]lacp priority 100
[labnario_1-GigabitEthernet0/0/1]int gig 0/0/3
[labnario_1-GigabitEthernet0/0/3]lacp priority 100

[labnario_1]int Eth-Trunk 1
[labnario_1-Eth-Trunk1]lacp preempt enable 
[labnario_1-Eth-Trunk1]lacp preempt delay 10

Let’s check what’s happened:

[labnario_1]dis eth-trunk 1
Eth-Trunk1's state information is:
Local:
LAG ID: 1                   WorkingMode: STATIC                               
Preempt Delay Time: 10      Hash arithmetic: According to SIP-XOR-DIP         
System Priority: 10         System ID: 4c1f-cce4-15b4                         
Least Active-linknumber: 1  Max Active-linknumber: 2                          
Operate status: up          Number Of Up Port In Trunk: 2                     
--------------------------------------------------------------------------------

ActorPortName          Status   PortType PortPri PortNo PortKey PortState Weight

GigabitEthernet0/0/1   Selected 1000TG   100     2      401     10111100  1     

GigabitEthernet0/0/2   Unselect 1000TG   32768   3      401     10100000  1     

GigabitEthernet0/0/3   Selected 1000TG   100     4      401     10111100  1     

Partner:
--------------------------------------------------------------------------------

ActorPortName          SysPri   SystemID        PortPri PortNo PortKey PortState

GigabitEthernet0/0/1   32768    4c1f-ccb8-cad1  32768   2      401     10111100

GigabitEthernet0/0/2   32768    4c1f-ccb8-cad1  32768   3      401     10110000

GigabitEthernet0/0/3   32768    4c1f-ccb8-cad1  32768   4      401     10111100

By default, the LACP preemption delay is 30 seconds.

Now we can check how hashing algorithm works. To do this we have to configure:

• Eth-trunk port link-type as trunk and allow VLAN 100 to be passed through the trunk.
• Static routing on labnario_1 to be able to ping loopback interface of labnario_2 and default routing on labnario_2 as well.

[labnario_1-Eth-Trunk1]port link-type trunk
[labnario_1-Eth-Trunk1]port trunk allow-pass vlan 100

[labnario_1]ip route-static 4.4.4.4 32 10.0.0.2

[labnario_2]ip route-static 0.0.0.0 0 10.0.0.1

[labnario_1]ping 4.4.4.4
  PING 4.4.4.4: 56  data bytes, press CTRL_C to break
    Reply from 4.4.4.4: bytes=56 Sequence=1 ttl=255 time=580 ms
    Reply from 4.4.4.4: bytes=56 Sequence=2 ttl=255 time=60 ms
    Reply from 4.4.4.4: bytes=56 Sequence=3 ttl=255 time=30 ms
    Reply from 4.4.4.4: bytes=56 Sequence=4 ttl=255 time=30 ms
    Reply from 4.4.4.4: bytes=56 Sequence=5 ttl=255 time=40 ms

  --- 4.4.4.4 ping statistics ---
    5 packet(s) transmitted
    5 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 30/148/580 ms

Now we can ping from PC1 to 4.4.4.4 and check statistics of members of Eth-trunk interface:

PC>ping 4.4.4.4 -t

Ping 4.4.4.4: 32 data bytes, Press Ctrl_C to break
From 4.4.4.4: bytes=32 seq=1 ttl=255 time=31 ms
From 4.4.4.4: bytes=32 seq=2 ttl=255 time=47 ms
From 4.4.4.4: bytes=32 seq=3 ttl=255 time=47 ms
From 4.4.4.4: bytes=32 seq=4 ttl=255 time=31 ms
From 4.4.4.4: bytes=32 seq=5 ttl=255 time=31 ms
From 4.4.4.4: bytes=32 seq=6 ttl=255 time=31 ms
From 4.4.4.4: bytes=32 seq=7 ttl=255 time=47 ms
From 4.4.4.4: bytes=32 seq=8 ttl=255 time=31 ms
From 4.4.4.4: bytes=32 seq=9 ttl=255 time=15 ms
From 4.4.4.4: bytes=32 seq=10 ttl=255 time=31 ms
From 4.4.4.4: bytes=32 seq=11 ttl=255 time=31 ms
From 4.4.4.4: bytes=32 seq=12 ttl=255 time=31 ms
From 4.4.4.4: bytes=32 seq=13 ttl=255 time=47 ms
From 4.4.4.4: bytes=32 seq=14 ttl=255 time=47 ms
From 4.4.4.4: bytes=32 seq=15 ttl=255 time=63 ms
From 4.4.4.4: bytes=32 seq=16 ttl=255 time=47 ms
From 4.4.4.4: bytes=32 seq=17 ttl=255 time=46 ms
From 4.4.4.4: bytes=32 seq=18 ttl=255 time=47 ms
From 4.4.4.4: bytes=32 seq=19 ttl=255 time=32 ms
From 4.4.4.4: bytes=32 seq=20 ttl=255 time=31 ms
From 4.4.4.4: bytes=32 seq=21 ttl=255 time=32 ms
From 4.4.4.4: bytes=32 seq=22 ttl=255 time=31 ms
From 4.4.4.4: bytes=32 seq=23 ttl=255 time=31 ms
From 4.4.4.4: bytes=32 seq=24 ttl=255 time=47 ms
From 4.4.4.4: bytes=32 seq=25 ttl=255 time=47 ms

--- 4.4.4.4 ping statistics ---
  26 packet(s) transmitted
  26 packet(s) received
  0% packet loss
  round-trip min/avg/max = 15/38/63 ms

<labnario_1>dis int gig 0/0/1 | inc Unicast
      Unicast: 26 packets, Multicast: 45 packets
      Unicast: 26 packets, Multicast: 3 packets

<labnario_1>dis int gig 0/0/2 | inc Unicast
      Unicast: 0 packets, Multicast: 19 packets
      Unicast: 0 packets, Multicast: 19 packets

<labnario_1>dis int gig 0/0/3 | inc Unicast
      Unicast: 0 packets, Multicast: 18 packets
      Unicast: 0 packets, Multicast: 19 packets

As you can see all traffic is going by interface GE0/0/1. This is per-flow behaviour. It means that frames belonging to the same data flow are transmitted over the same physical link.

And catched packets on GE0/0/1: