[ovs-discuss] LACP fallback support

O'Reilly, Darragh darragh.oreilly at hpe.com
Mon Jun 12 10:57:47 UTC 2017


I don't really know what you are trying to do, but here are some comments. The lacp_status is "negotiated", so the other side is healthy and sending LACP PDUs, so the bond is not in active-backup, but it seems you are trying to use individual links of the bundle. Another useful command is "ovs-appctl lacp/show". Also PXE is probably not going to work with VLAN tagged packets.

Darragh.

From: Nguyen, Minh-Nghia [mailto:minh-nghia.nguyen at sap.com]
Sent: 09 June 2017 16:25
To: ovs-discuss at openvswitch.org
Cc: O'Reilly, Darragh <darragh.oreilly at hpe.com>
Subject: RE: LACP fallback support

Hi,

We are aware of this config and have tried to use it, but are running into a problem.

Here is the bond port config:

_uuid               : 22808a9c-0ab3-4aff-881d-92573fc17912
bond_active_slave   : "52:54:00:e6:c4:99"
bond_downdelay      : 31000
bond_fake_iface     : false
bond_mode           : balance-tcp
bond_updelay        : 31000
external_ids        : {}
fake_bridge         : false
interfaces          : [0fc925f7-0166-4455-873b-3f3355b672b2, 2859937c-25ed-472e-81ff-bb1913196640, 600d7d5f-f25f-405f-b190-f1f5c0db6a5c, 7a71a3b1-7e0e-4239-b933-03433e665587]
lacp                : active
mac                 : []
name                : "bond17"
other_config        : {bond-detect-mode=miimon, bond-miimon-interval="100", host_id=none, lacp-fallback-ab="true", lacp-time=fast}
qos                 : []
rstp_statistics     : {}
rstp_status         : {}
statistics          : {}
status              : {}
tag                 : 400
trunks              : []
vlan_mode           : []

    Bridge "br0"
        Port "bond17"
            tag: 400
            Interface "eth2"
            Interface "eth3"
            Interface "eth5"
            Interface "eth4"
        Port "eth1"
            Interface "eth1"
        Port "br0"
            Interface "br0"
                type: internal

The current bond/show returns:

---- bond17 ----
bond_mode: balance-tcp
bond may use recirculation: yes, Recirc-ID : 44
bond-hash-basis: 0
updelay: 31000 ms
downdelay: 31000 ms
next rebalance: 9816 ms
lacp_status: negotiated
active slave mac: 52:54:00:e6:c4:99(eth4)

slave eth2: enabled
                may_enable: true

slave eth3: enabled
                may_enable: true

slave eth4: enabled
                active slave
                may_enable: true

slave eth5: enabled
                may_enable: true

All the eth interfaces are connected to VMs, on eth1 we have a vlan 400 interface that has IP 199.166.40.3. On the other hand, eth4 it is 199.166.40.11. Here is the tcpdump at eth1 after a ping attempt.

16:18:40.755586 52:54:00:6e:a9:48 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 400, p 0, ethertype ARP, Request who-has 199.166.40.3 tell 199.166.40.11, length 46
16:18:40.756877 52:54:00:8d:b0:eb > 52:54:00:6e:a9:48, ethertype 802.1Q (0x8100), length 64: vlan 400, p 0, ethertype ARP, Reply 199.166.40.3 is-at 52:54:00:8d:b0:eb, length 46
16:18:41.754281 52:54:00:6e:a9:48 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 400, p 0, ethertype ARP, Request who-has 199.166.40.3 tell 199.166.40.11, length 46
16:18:41.755169 52:54:00:8d:b0:eb > 52:54:00:6e:a9:48, ethertype 802.1Q (0x8100), length 64: vlan 400, p 0, ethertype ARP, Reply 199.166.40.3 is-at 52:54:00:8d:b0:eb, length 46

Tcpdump at eth4, however has no reply messages, and ping failed. Basically traffic cannot go back into the bond at this point.

16:18:30.388649 52:54:00:6e:a9:48 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 199.166.40.3 tell 199.166.40.11, length 46
16:18:31.387577 52:54:00:6e:a9:48 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 199.166.40.3 tell 199.166.40.11, length 46
16:18:32.385825 52:54:00:6e:a9:48 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 199.166.40.3 tell 199.166.40.11, length 46
16:18:33.403071 52:54:00:6e:a9:48 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 199.166.40.3 tell 199.166.40.11, length 46

Could you have a look and any help would be appreciated.

Thanks in advance,

Nghia

From: O'Reilly, Darragh [mailto:darragh.oreilly at hpe.com]
Sent: 09 June 2017 13:44
To: Nguyen, Minh-Nghia <minh-nghia.nguyen at sap.com<mailto:minh-nghia.nguyen at sap.com>>; ovs-discuss at openvswitch.org<mailto:ovs-discuss at openvswitch.org>
Subject: RE: LACP fallback support

There is fallback to active-backup:

ovs-vsctl set port bond0 other_config:lacp-fallback-ab=true

See http://openvswitch.org/support/dist-docs/ovs-vswitchd.conf.db.5.html

Darragh.

From: ovs-discuss-bounces at openvswitch.org<mailto:ovs-discuss-bounces at openvswitch.org> [mailto:ovs-discuss-bounces at openvswitch.org] On Behalf Of Nguyen, Minh-Nghia
Sent: 09 June 2017 13:28
To: ovs-discuss at openvswitch.org<mailto:ovs-discuss at openvswitch.org>
Subject: [ovs-discuss] LACP fallback support

Hi,

We are trying to build a testbed for node provisioning. In the real setup, our baremetal nodes are connected to a physical Arista switch with LAGs and LACP fallback individual mode is set to support PXE booting.

We want to emulate those behaviours with openvswitch built inside a VM and a provisioning VM that has network interfaces connected to the OVS VM via veth pairs, and use ovs bonding for LACP. However, as far as we are aware, there are not any form of LACP fallback mechanism in ovs. We would love to know if there is any way to work around this or if this has ever been considered.

Many thanks.

Minh Nghia Nguyen

HANA Cloud Computing, Systems Engineering
SAP (UK) Limited   I   The Concourse   I   Queen's Road   I   Queen's Island   I   Belfast BT3 9DT
E: minh-nghia.nguyen at sap.com<mailto:minh-nghia.nguyen at sap.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20170612/5edbe5fa/attachment-0001.html>


More information about the discuss mailing list