LACP Fallback Mode blocks ports on VLAN - making feature not functional

Karl_Witthuhn — Fri, 11 Jan 2019 02:44:55 GMT

Greetings EXOS community -

I am trying to see if the "LACP Fallback" feature can be of use to me to overcome the problem that PXE boot/DHCP has when a server reboots to re-image.

I have a pair of stacked Extreme X460-48t switches running the latest firmware 16.2.4.5-patch1-6.

A server (running Linux SLES12SP3) is connected to ports 1:1 + 2:1 running in LACP mode.

Here's the relevant configuration:

enable sharing 1:1 grouping 1:1,2:1 algorithm address-based L3_L4 lacp
configure sharing 1:1 lacp timeout short
configure sharing 1:1 lacp fallback enable
configure sharing 1:1 lacp fallback timeout 10

Spanning-tree is disabled.

When the node is up and running - the Linux bonding module running mode=802.3ad is good and everything is happy on the switch.

Load Sharing Monitor
Config Current Agg Min Ld Share Flags Ld Share Agg Link Link Up
Master Master Control Active Algorithm Group Mbr State Transitions
================================================================================
1:1 1:1 LACP 1 L2 A 1:1 Y A 37
L2 2:1 Y A 37

However, as soon as the server reboots - the sharing group master (port 1:1) becomes blocked on the untagged VLAN (vlan = default)

VLAN Interface with name Default created by user
Admin State: Enabled Tagging: 802.1Q Tag 1
Description:
Virtual router: VR-Default
IPv4 Forwarding: Enabled
IPv4 MC Forwarding: Disabled
Primary IP: 172.23.100.3/16
IPv6 Forwarding: Disabled
IPv6 MC Forwarding: Disabled
IPv6: None
STPD: s0(Disabled,Auto-bind)
Protocol: Match all unfiltered protocols
Loopback: Enabled
NetLogin: Disabled
OpenFlow: Disabled
TRILL: Disabled
QosProfile: None configured
Egress Rate Limit Designated Port: None configured
Flood Rate Limit QosProfile: None configured
Ports: 114. (Number of active ports=3)
Untag: *1:2, 1:3, 1:4, 1:5, 1:6, 1:7, 1:8,
1:9, 1:10, 1:11, 1:12, 1:13, 1:14, 1:15,
1:16, 1:17, 1:18, 1:19, 1:20, 1:21, 1:22,
1:23, 1:24, 1:25, 1:26, 1:27, 1:28, 1:29,
1:30, 1:31, 1:32, 1:33, 1:34, 1:35, 1:36,
1:37, 1:38, 1:39, 1:40, 1:41, 1:42, 1:43,
1:44, 1:45, 1:46, 1:47, 1:49, 1:50, 1:51,
1:52, 1:53, 1:54, 1:55, 1:56, 1:57, 1:58,
2:2, 2:3, 2:4, 2:5, 2:6, 2:7, 2:8,
2:9, 2:10, 2:11, 2:12, 2:13, 2:14, 2:15,
2:16, 2:17, 2:18, 2:19, 2:20, 2:21, 2:22,
2:23, 2:24, 2:25, 2:26, 2:27, 2:28, 2:29,
2:30, 2:31, 2:32, 2:33, 2:34, 2:35, 2:36,
2:37, 2:38, 2:39, 2:40, 2:41, 2:42, 2:43,
2:44, 2:45, 2:46, 2:47, 2:49, 2:50, 2:51,
2:52, 2:53, 2:54, 2:55, 2:56, 2:57, 2:58,
*1:48g, *1:1bg

This causes the DHCP/PXE server to lose connection to this server completely during the reboot process and no DHCP/ARP/PXE packets are sent out.

Any ideas on how to prevent an inactive LACP port from being blocked on a VLAN when the LACP link goes down? Kind of defeats the purpose of LACP fallback if the VLAN doesn't forward traffic to the ports that are supposed to fallback to.

Thank you.

topic LACP Fallback Mode blocks ports on VLAN - making feature not functional in ExtremeSwitching (EXOS/Switch Engine)

LACP Fallback Mode blocks ports on VLAN - making feature not functional