Presentation
There are several ways to configure network bonding in RHEL 7:
- using the nmtui command and a Text User Interface,
- using the nmcli command at the Command Line Interface,
- using the graphical interface,
- through direct changes in the network configuration files.
For the rest of this tutorial, it is the nmcli option that has been chosen because it’s the quickest method and arguably the least prone to errors.
Prerequisites
To put into practice this tutorial, you need two VM and access to their respective console.
Each VM has been installed with a base distribution (minimal distribution should work but was not tested). Each VM’s got two network interfaces called eth0 and eth1.
If a previous network configuration was set up, remove it on both VM:
# nmcli con show NAME UUID TYPE DEVICE Wired connection 1 f32cfcb7-3567-4313-9cf3-bdd87010c7a2 802-3-ethernet eth1 System eth0 257e9416-b420-4218-b1eb-f14302f20941 802-3-ethernet eth0 # nmcli con del f32cfcb7-3567-4313-9cf3-bdd87010c7a2 # nmcli con del 257e9416-b420-4218-b1eb-f14302f20941
Bonding Configuration
Execute the following steps at the console of both VM.
Create the bonding interface:
# nmcli con add type bond con-name mybond0 ifname bond0 mode active-backup [88934.922710] bonding: bond0: Setting MII monitoring interval to 100. [88934.923313] bonding: bond0: setting mode to active-backup (1). [88934.923845] bonding: bond0: Setting ARP monitoring interval to 0. [88934.924382] bonding: bond0: setting arp_validate to none (0). [88934.924891] bonding: bond0: Setting primary slave to None. [88934.925375] bonding: bond0: setting primary_reselect to always (0). [88934.925920] bonding: bond0: Setting fail_over_mac to none (0). [88934.926409] bonding: bond0: Setting use_carrier to 1. [88934.926819] bonding: bond0: Setting ad_select to stable (0). [88934.927286] bonding: bond0: setting xmit hash policy to layer2 (0). [88934.927786] bonding: bond0: Setting resend_igmp to 1. Connection 'mybond0' (304e66f0-c31c-4b57-92e8-734e2b53bdac) successfully added.
Note: If you don’t specify con-name mybond0, the bonding interface will be named bond-bond0.
Add an IPv4 configuration:
In RHEL 7.0:
# nmcli con mod mybond0 ipv4.addresses "192.168.1.10/24 192.168.1.1" # nmcli con mod mybond0 ipv4.method manual
From RHEL 7.1 on:
# nmcli con mod mybond0 ipv4.addresses 192.168.1.10/24 # nmcli con mod mybond0 ipv4.gateway 192.168.1.1 # nmcli con mod mybond0 ipv4.method manual
Note: If you don’t specify any IP configuration, both VM will get their ip address and gateway through DHCP by default.
Add the eth0 interface to the bonding interface:
# nmcli con add type bond-slave con-name bond0-eth0 ifname eth0 master bond0 [89010.860765] bonding: bond0: making interface eth0 the new active one. [89010.861336] bonding: bond0: enslaving eth0 as an active interface with an up link. Connection 'bond0-eth0' (35081742-5962-4edf-8465-6843603d7777) successfully added.
Note: If you don’t specify con-name bond0-eth0, the bonding slave interface will be named bond-slave-eth0.
Add the eth1 interface to the bonding interface:
# nmcli con add type bond-slave con-name bond0-eth1 ifname eth1 master bond0 [89146.655598] bonding: bond0: enslaving eth1 as a backup interface with an up link. Connection 'bond0-eth1' (037019f3-7115-46a4-a6f9-8fba7bf2adcd) successfully added.
Note: If you don’t specify con-name bond0-eth1, the bonding slave interface will be named bond-slave-eth1.
Activate the bonding interface:
# nmcli con up mybond0 [89222.099283] bonding: bond0: releasing backup interface eth1 [89222.102432] bonding: bond0: releasing active interface eth0 [89222.126862] bonding: bond0: Setting MII monitoring interval to 100. [89222.127410] bonding: bond0: setting mode to active-backup (1). [89222.127950] bonding: bond0: Setting ARP monitoring interval to 0. [89222.128494] bonding: bond0: setting arp_validate to none (0). [89222.128991] bonding: bond0: Setting primary slave to None. [89222.129460] bonding: bond0: setting primary_reselect to always (0). [89222.129964] bonding: bond0: Setting fail_over_mac to none (0). [89222.130443] bonding: bond0: Setting use_carrier to 1. [89222.130847] bonding: bond0: Setting ad_select to stable (0). [89222.131307] bonding: bond0: setting xmit hash policy to layer2 (0). [89222.131801] bonding: bond0: Setting resend_igmp to 1. [89222.132219] IPv6: ADDRCONF(NETDEV_UP): bond0: link is not ready [89222.251450] bonding: bond0: making interface eth1 the new active one. [89222.252022] bonding: bond0: first active interface up! [89222.252462] bonding: bond0: enslaving eth1 as an active interface with an up link. [89222.253641] IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready [89222.305553] bonding: bond0: enslaving eth0 as a backup interface with an up link. Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/70)
Check the configuration:
# nmcli con show NAME UUID TYPE DEVICE mybond0 304e66f0-c31c-4b57-92e8-734e2b53bdac bond bond0 bond0-eth1 037019f3-7115-46a4-a6f9-8fba7bf2adcd 802-3-ethernet eth1 bond0-eth0 35081742-5962-4edf-8465-6843603d7777 802-3-ethernet eth0
Source: RHEL 7 Networking Guide.
Additional Resources
The Geek Diary website provides an interesting tutorial about Changing the currently active slave interface online.
The RackSpace developer blog provides a tutorial explaining LACP bonding and Linux configuration on RHEL 7.
Just want to point your attention that if you configure the nics for Bonding you will have issue with iSCSI connectivity, you can override that by enabling the demo mode for the target.
I didn’t know. Where did you get this information?
iSCSI don’t work with multipath connection, you can find it in the VCP materials and CCNP DataCenter.
Very interesting. Thanks.
On RHEL 7 official documentation they say you have to load the bonding module first
modprobe –first-time bonding
In my CentOS 7.1 I had to activate it the first time.
Interesting. Thanks.
This will not survive a reboot.
Just FYI, ipv4.gateway is an invalid property on RHEL 7.0 (but it’s available on RHEL 7.2).
On RHEL 7.0, you would set up a gateway this way:
# nmcli con mod mybond0 ipv4.addresses “192.168.1.10/24 192.168.1.1”
Yes, I was already aware of that (http://www.pmsas.pr.gov.br/wp-content/?id=certdepot-EX200&exam=rhel7-changes-between-versions/) but I didn’t mention it in this tutorial.
I’m going to fix that. Thanks.
Can you make a bond by taking one interface from vm1 and other interface from vm2? The title above seems like that.
I don’t think this is possible. Although there could be some confusion in the title, network bonding always means combining two network interfaces from the same machine to a single link.
Just wanted to now that on RH7.2, setting the interface devices to eth0 and eth1 fails as there are no such devices. The output of nmcli con show shows
$ nmcli con show
NAME UUID TYPE DEVICE
mybond0 48a3e640-5605-430b-872a-f05b6312da05 bond bond0
bond0-eth0 9a1ca8f7-7c3f-4715-8a0b-85287809570d 802-3-ethernet —
bond0-eth1 0628ec00-40af-4524-ad96-66a048bc2f6f 802-3-ethernet —
No devices are attached to the two bonds. The interfaces, at least for my VM, are eno16777984 instead of eth0 and ens192 instead of eth1. Once I used the correct device names, I was able to remotely log in to the VM.
$ nmcli con show
NAME UUID TYPE DEVICE
bond0-eth0 9a1ca8f7-7c3f-4715-8a0b-85287809570d 802-3-ethernet eno16777984
bond0-eth1 0628ec00-40af-4524-ad96-66a048bc2f6f 802-3-ethernet ens192
mybond0 48a3e640-5605-430b-872a-f05b6312da05 bond bond0
The network interface names depend on your hardware. As most of the instructions here are given for a virtualized environment, it is normal to use the eth0 and eth1 because it’s what you can find in this kind of environment.
I agree with CertDepot, it would be impractical to use anything but a ‘traditionally’ named network device of eth0 (eth1 and so on) for reference purposes.
We are all aware that RHEL7 comes with the predictable network interface device names, however, there are endless combinations these can get generated depending on hardware one uses.
Sticking to traditional naming helps to avoid confusion, as otherwise people would start reporting devices that don’t exist on their systems because hardware don’t math.
This is me and my environment of VMWare virtual machines and Dell and HP physical machines, but for my environment at work, none of the Red Hat 7 systems have had eth0 or eth1 interfaces. That’s used with older Red Hat systems. My physical RHEL6 systems use em1_1 and p1p1 for onboard and pci cards. Virtual do use eth0 and eth1 though. With RH7, even my virtual machines are now using the ens192, ens224, and ens256 device names plus the eno one. That was annoying because an OS update to one of my VMs changed the eno interface to ens and I had to reconfigure. But anyway, I would suggest at least calling out that RH7, at least in my experience, aren’t using the ethn device names any more.
That’s exactly what I said Carl. RH7 uses the predictable network interface device names, and different hardware generates different names. For blogging purposes, it’s best to stick to traditional naming of eth0, eth1 etc.
Carl, I can see where you are coming from. I think the question you are asking is why. The answer is progress. Issues like this occur when upgrading any Operating System.
If you have a Server as a firewall, with two interfaces, on reboot, with the naming system, the interfaces could swap, and obvious security implications.
Eth0 set as an Internal Network
Eth1 set as an External Network
Relating each interface to a physical name (see Red Had Documentation Network Guide Ver 7 Chapter 8) removes this problem.