Bug 1115118 - [RFE] Support for initially configuring LACP (Mode 4 Bond) manually in order to connect with RHEV-M. [NEEDINFO]
Summary: [RFE] Support for initially configuring LACP (Mode 4 Bond) manually in order ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs
Version: 3.4.0
Hardware: All
OS: Linux
high
high
Target Milestone: ovirt-3.6.1
: 3.6.0
Assignee: Scott Herold
QA Contact: wanghui
URL:
Whiteboard:
Depends On: 994451 1231379
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-01 15:13 UTC by Allie DeVolder
Modified: 2019-10-10 09:20 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-09 20:48:28 UTC
oVirt Team: Node
cwu: needinfo? (avoss)
sherold: Triaged+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:0376 normal SHIPPED_LIVE Red Hat Enterprise Virtualization Manager 3.6.0 2016-03-10 01:20:52 UTC
Red Hat Knowledge Base (Solution) 1145313 None None None Never

Description Allie DeVolder 2014-07-01 15:13:23 UTC
- What is the nature and description of the request?
Support for initially configuring LACP (Mode 4 Bond) manually in order to connect with RHEV-M.

- Why does the customer need this? (List the business requirements here)
In order to actually communicate with RHEV-M over Brocade brand networking equipment, the LACP bond must be enabled in order for traffic to reach the RHEV-M. If that bond is created, vdsm-reg treats it as a bridge instead of a bond, and breaks.

- How would the customer like to achieve this? (List the functional
requirements here)
TUI support for initially configuring and connecting to RHEV-M over LACP

Comment 2 Dan Kenigsberg 2014-07-06 13:54:28 UTC
I believe that in the network page of ovirt-node's TUI, an admin can set up arbitrary bonding options.

However, the sad thing is that as you can see in bug 1097713, vdsm-reg does not work over bond, and it has never worked. You can still trigger installation via Engine, but the real answer is in bug 994451: vdsm-reg must go.

Comment 9 Gerwin Krist 2015-05-29 13:50:36 UTC
Any update on this one? Our switches (Extreme Networks) do have the same problem as the Brocade switches. Registering new hosts is currently very hard for us without jumping thru hoops.

Comment 13 Fabian Deutsch 2015-06-08 08:45:45 UTC
As mentioned in comment 2 users can already created bonds with arbitrary options in the RHEV-H, this should also cover the creation of LACP capable bonds.

But note that in case that bonds are used, the user must add the host from the RHEV-M side.

Comment 14 Yaniv Kaul 2015-11-17 14:36:33 UTC
Fabian - anything else left to do here?

Comment 15 Fabian Deutsch 2015-11-17 14:48:09 UTC
It should get test coverage, otherwise we should be fine.

Ying, should this (LACP mode) be covered explicitly in test case RHEVM3-13108 ?

Comment 16 Yaniv Kaul 2015-11-18 15:00:53 UTC
(In reply to Fabian Deutsch from comment #15)
> It should get test coverage, otherwise we should be fine.

So it should be moved to ON_QA.

> 
> Ying, should this (LACP mode) be covered explicitly in test case
> RHEVM3-13108 ?

Comment 17 Fabian Deutsch 2015-11-18 15:04:56 UTC
Indeed.

Comment 18 Red Hat Bugzilla Rules Engine 2015-11-18 15:04:59 UTC
Fixed bug tickets must have target milestone set prior to fixing them. Please set the correct milestone and move the bugs back to the previous status after this is corrected.

Comment 19 Chaofeng Wu 2015-11-19 09:27:40 UTC
We try the following steps on rhev-hypervisor7-7.2-20151112.1.iso. Confirmed that 
RHEV-M can add RHEV-H by mode 4 bond network, with RHEV-H connect to the network 
switch which configured LACP mode.

Physical ENV:
Test machine           Switch
    eno3 <-----------> port 21
    eno4 <-----------> port 22

Version:
RHEV-M3.6.0.3-0.1.el6
rhev-hypervisor7-7.2-20151112.1.iso
ovirt-node-3.6.0-0.20.20151103git3d3779a.el7ev.noarch

Steps:
1. Configure the port 21 and 22 with LACP mode configured on the switch.
2. Install RHEV-H7.2-20151112, create bond0 with mode4 on eno3 and eno4, configure
bond0 with vlan tag 20 and DHCP mode.
3. Add RHEV-H from RHEV-M3.6.0.3-0.1.el6.
4. Unplug one port from the test machine.

Result:
After step3, RHEV-H can be up successful on RHEV-M.
After step4, RHEV-H still up on RHEV-M.

Additional info:
Switch configuration:
------------------------------------------------------
Switch#show run
... ...
!
interface Port-channel5
 switchport trunk encapsulation dot1q
 switchport mode trunk
!
... ...
!
interface GigabitEthernet0/21
 switchport trunk encapsulation dot1q
 switchport mode trunk
 duplex full
 channel-protocol lacp
 channel-group 5 mode active
!
interface GigabitEthernet0/22
 switchport trunk encapsulation dot1q
 switchport mode trunk
 duplex full
 channel-protocol lacp
 channel-group 5 mode active
!
... ...

Switch# show interfaces Port-channel5 etherchannel 
Port-channel5   (Primary aggregator)

Age of the Port-channel   = 00d:00h:44m:52s
Logical slot/port   = 2/5          Number of ports = 2
HotStandBy port = null 
Port state          = Port-channel Ag-Inuse 
Protocol            =   LACP

Ports in the Port-channel: 

Index   Load   Port     EC state        No of bits
------+------+------+------------------+-----------
  0     00     Gi0/21   Active             0
  0     00     Gi0/22   Active             0

Time since last port bundled:    00d:00h:33m:50s    Gi0/22
Time since last port Un-bundled: 00d:00h:35m:33s    Gi0/22

Switch#show int Gi0/21 trunk

Port        Mode         Encapsulation  Status        Native vlan
Gi0/21      on           802.1q         trunk-inbndl  1
                                      (Po5)

Port        Vlans allowed on trunk
Gi0/21      1-4094

Port        Vlans allowed and active in management domain
Gi0/21      1,3,10-13,15-16,20,30,40,99,152-153

Port        Vlans in spanning tree forwarding state and not pruned
Gi0/21      1,3,10-13,15-16,20,30,40,99,152-153


Switch#show int Gi0/22 trunk

Port        Mode         Encapsulation  Status        Native vlan
Gi0/22      on           802.1q         trunk-inbndl  1
                                      (Po5)

Port        Vlans allowed on trunk
Gi0/22      1-4094

Port        Vlans allowed and active in management domain
Gi0/22      1,3,10-13,15-16,20,30,40,99,152-153

Port        Vlans in spanning tree forwarding state and not pruned
Gi0/22      1,3,10-13,15-16,20,30,40,99,152-153


RHEV-H configuration:
---------------------------------------------------------
[root@localhost ~]# tcpdump -nn -v -i eno3 -s 1500 -c 1 'ether[20:2] == 0x2000'
tcpdump: WARNING: eno3: no IPv4 address assigned
tcpdump: listening on eno3, link-type EN10MB (Ethernet), capture size 1500 bytes
03:49:43.055084 CDPv2, ttl: 180s, checksum: 0x7e82 (unverified), length 419
	Device-ID (0x01), length: 6 bytes: 'Switch'
	Version String (0x05), length: 189 bytes: 
	  Cisco IOS Software, C3560 Software (C3560-ADVIPSERVICESK9-M), Version 12.2(25)SEE4, RELEASE SOFTWARE (fc1)
	  Copyright (c) 1986-2007 by Cisco Systems, Inc.
	  Compiled Mon 16-Jul-07 03:11 by myl
	Platform (0x06), length: 20 bytes: 'cisco WS-C3560G-24TS'
	Address (0x02), length: 69 bytes: IPv4 (3) 192.168.20.1 IPv6 (2) fe80::21e:49ff:fe88:f4c2 IPv6 (1) 3ffe:501:ffff:101::1
	Port-ID (0x03), length: 19 bytes: 'GigabitEthernet0/21'
	Capability (0x04), length: 4 bytes: (0x00000029): Router, L2 Switch, IGMP snooping
	Protocol-Hello option (0x08), length: 32 bytes: 
	VTP Management Domain (0x09), length: 0 bytes: ''
	Native VLAN ID (0x0a), length: 2 bytes: 1
	Duplex (0x0b), length: 1 byte: full
	Management Addresses (0x16), length: 13 bytes: IPv4 (1) 192.168.20.1
	unknown field type (0x1a), length: 12 bytes: 
	  0x0000:  0000 0001 0000 0000 ffff ffff
1 packet captured
1 packet received by filter
0 packets dropped by kernel

[root@localhost ~]# tcpdump -nn -v -i eno4 -s 1500 -c 1 'ether[20:2] == 0x2000'
tcpdump: WARNING: eno4: no IPv4 address assigned
tcpdump: listening on eno4, link-type EN10MB (Ethernet), capture size 1500 bytes
03:50:43.059479 CDPv2, ttl: 180s, checksum: 0x7d82 (unverified), length 419
	Device-ID (0x01), length: 6 bytes: 'Switch'
	Version String (0x05), length: 189 bytes: 
	  Cisco IOS Software, C3560 Software (C3560-ADVIPSERVICESK9-M), Version 12.2(25)SEE4, RELEASE SOFTWARE (fc1)
	  Copyright (c) 1986-2007 by Cisco Systems, Inc.
	  Compiled Mon 16-Jul-07 03:11 by myl
	Platform (0x06), length: 20 bytes: 'cisco WS-C3560G-24TS'
	Address (0x02), length: 69 bytes: IPv4 (3) 192.168.20.1 IPv6 (2) fe80::21e:49ff:fe88:f4c2 IPv6 (1) 3ffe:501:ffff:101::1
	Port-ID (0x03), length: 19 bytes: 'GigabitEthernet0/22'
	Capability (0x04), length: 4 bytes: (0x00000029): Router, L2 Switch, IGMP snooping
	Protocol-Hello option (0x08), length: 32 bytes: 
	VTP Management Domain (0x09), length: 0 bytes: ''
	Native VLAN ID (0x0a), length: 2 bytes: 1
	Duplex (0x0b), length: 1 byte: full
	Management Addresses (0x16), length: 13 bytes: IPv4 (1) 192.168.20.1
	unknown field type (0x1a), length: 12 bytes: 
	  0x0000:  0000 0001 0000 0000 ffff ffff
1 packet captured
1 packet received by filter
0 packets dropped by kernel

[root@localhost ~]# brctl show
bridge name	bridge id		STP enabled	interfaces
;vdsmdummy;		8000.000000000000	no		
ovirtmgmt		8000.e41f13ebcd63	no		bond0.20

[root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-bond0
# Generated by VDSM version 4.17.10.1-0.el7ev
DEVICE=bond0
BONDING_OPTS='mode=4 miimon=100'
ONBOOT=yes
MTU=1500
NM_CONTROLLED=no
IPV6INIT=no
HOTPLUG=no

[root@localhost ~]# cat  /sys/class/net/bond0/bonding/slaves
eno3 eno4

[root@localhost ~]# cat /proc/net/vlan/config 
VLAN Dev name	 | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
bond0.20       | 20  | bond0

Comment 20 Ying Cui 2015-11-19 10:03:16 UTC
Fabian, could you check comment 19, is that enough for this bug on node side? Thanks

Comment 21 Fabian Deutsch 2015-11-19 14:44:24 UTC
4. Unplug one port from the test machine.
Suggestion: Try to remove both cables, just one at a time.

I don't know if the correct working of LACp can be verified from the console.
In general this looks fine to me.

We should also cover the auto-installation with the bond_setup= argument to see where we stand here.

Comment 22 Chaofeng Wu 2015-11-24 07:34:15 UTC
(In reply to Fabian Deutsch from comment #21)
> 4. Unplug one port from the test machine.
> Suggestion: Try to remove both cables, just one at a time.

Test your suggestion steps:
1, Unplug one cable, wait 5 mins, ping and check RHEV-H status.
2. Plug the cable back, wait 5 mins, ping and check RHEV-H status.
3. Unplug the other one, wait 5 mins, ping and check RHEV-H status.
4. Plug the cable back, wait 5 mins, ping and check RHEV-H status.

Result:
For all the steps, RHEV-H can ping successful, there is no ping packages lost,
and RHEV-H status always was up.

> 
> I don't know if the correct working of LACp can be verified from the console.
> In general this looks fine to me.
> 
> We should also cover the auto-installation with the bond_setup= argument to
> see where we stand here.
Test the bood_setup patameter:
bond=bond0:eno3,eno4:mode=4 vlan=20:bond0

Test steps were some with TUI Installation, the result was PASS.

Comment 23 Chaofeng Wu 2015-11-24 08:48:28 UTC
Hi Allan,

We test the request on Bond+Vlan environment, details please see the comment 19 and comment 22. 
Do you think whether those scenarios can meet the customers request ?

Comment 24 wanghui 2016-02-03 08:03:42 UTC
According to comment#19 and #22, verified this issue on rhev-hypervisor7-7.2-20151112.1.iso.

Comment 26 errata-xmlrpc 2016-03-09 20:48:28 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-0376.html


Note You need to log in before you can comment on or make changes to this bug.