3

I am learning networking by building a small virtual network within a CentOS host. I need some guidance at the highest level to start planning:

The Scenario:

A CentOS 7 HOST needs to have a CentOS 7 GUEST, and both the HOST and the GUEST must each have different static public IP addresses. I understand that this is accomplished by creating a bridge on the HOST.

The HOST physical box is connected via Ethernet to a router/modem that has a GATEWAY IP address of 12.34.567.8aa. There are 5 public static IP addresses available, including 12.34.567.111, 12.34.567.222, 12.34.567.333, 12.34.567.444, and 12.34.567.555

How should the static public IP addresses be defined for the HOST, the BRIDGE, and the GUEST? Should they have three separate IP addresses? Or should the HOST and the BRIDGE have the same IP?

The current ip addresses as defined on the HOST are as follows. The HOST's connection to the router/modem is eno1, and the BRIDGE is defined as br1. 

[root@remote-host ~]# ip addr
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether making:this:anonymous brd making:this:anonymous
    inet 12.34.567.111/29 brd 12.34.567.8xx scope global eno1
       valid_lft forever preferred_lft forever
    inet6 making:this:anonymous scope global dynamic
       valid_lft 414553sec preferred_lft 414553sec
    inet6 making:this:anonymous scope global noprefixroute dynamic
       valid_lft 2419198sec preferred_lft 345598sec
    inet6 making:this:anonymous scope link
       valid_lft forever preferred_lft forever
3: wlp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether making:this:anonymous brd making:this:anonymous
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
    link/ether making:this:anonymous brd making:this:anonymous
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 1000
    link/ether making:this:anonymous brd making:this:anonymous
50: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether making:this:anonymous brd making:this:anonymous
    inet 12.34.567.111/29 brd 12.34.567.8xx scope global br1
       valid_lft forever preferred_lft forever
    inet6 making:this:anonymous scope link
       valid_lft forever preferred_lft forever
63: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN qlen 1000
    link/ether making:this:anonymous brd making:this:anonymous
    inet6 making:this:anonymous scope link
       valid_lft forever preferred_lft forever
[root@remote-host ~]#
Improve this question

1 Answer 1

Reset to default
1

According to libvirt documentation:

Bridge to LAN

This is the recommended config for general guest connectivity on hosts with static wired networking configs.

Provides a bridge from the VM directly to the LAN. This assumes there is a bridge device on the host which has one or more of the hosts physical NICs enslaved. The guest VM will have an associated tun device created with a name of vnetN, which can also be overridden with the element (see overriding the target element). The tun device will be enslaved to the bridge. The IP range / network configuration is whatever is used on the LAN. This provides the guest VM full incoming & outgoing net access just like a physical machine.

Using virsh to Create Bridge

According to RHEL Documentation, you can use virsh to create a bridge, e.g. br0 bridge based on the eth0 interface:

# virsh iface-bridge eth0 br0

Should you want/need to remove the bridge, do

# virsh iface-unbridge br0

Creating network initscripts

If that doesn't work the way you need it to be, create/edit the init-scripts in /etc/sysconfig/network-scripts/ manually. This section is directly from the libvirt documentation page:

In the /etc/sysconfig/network-scripts directory it is neccessary to create 2 config files. The first (ifcfg-eth0) defines your physical network interface, and says that it will be part of a bridge:

# cat > ifcfg-eth0 <<EOF
DEVICE=eth0
HWADDR=00:16:76:D6:C9:45
ONBOOT=yes
BRIDGE=br0
NM_CONTROLLED=no
EOF

Obviously change the HWADDR to match your actual NIC's address. You may also wish to configure the device's MTU here using e.g. MTU=9000.

The second config file (ifcfg-br0) defines the bridge device:

# cat > ifcfg-br0 <<EOF
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0
NM_CONTROLLED=no
EOF

WARNING: The line TYPE=Bridge is case-sensitive - it must have uppercase 'B' and lower case 'ridge'

After changing this restart networking (or simply reboot)

 # service network restart

The final step is to disable netfilter on the bridge:

 # cat >> /etc/sysctl.conf <<EOF
 net.bridge.bridge-nf-call-ip6tables = 0
 net.bridge.bridge-nf-call-iptables = 0
 net.bridge.bridge-nf-call-arptables = 0
 EOF
 # sysctl -p /etc/sysctl.conf

It is recommended to do this for performance and security reasons. See Fedora bug #512206. Alternatively you can configure iptables to allow all traffic to be forwarded across the bridge:

# echo "-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT" > /etc/sysconfig/iptables-forward-bridged
# lokkit --custom-rules=ipv4:filter:/etc/sysconfig/iptables-forward-bridged
# service libvirtd reload

NetworManager and Bridging

Though I'm not sure if this is still true, as there's active development, NetworkManager does not support bridging. Therefore, it may be necessary to disable it and use the network service instead:

# chkconfig NetworkManager off
# chkconfig network on
# service NetworkManager stop
# service network start

So, once you create the "bridge" interface, enslave the physical NIC to it as outlined within the documentation, then you need to edit the Virtual Guest's configuration to enslave its NIC to the bridge on the host as well.

...
<devices>
  ...
  <interface type='bridge'>
    <source bridge='br0'/>
  </interface>
  <interface type='bridge'>
    <source bridge='br1'/>
    <target dev='vnet7'/>
    <mac address="00:11:22:33:44:55"/>
  </interface>
  ...
</devices>

Once that's done, the router, to which your host's physical NIC is connected, will assign addresses via DHCP to the bridged interfaces--both for the host and/or the guest.

There's a Q&A on Serverfault that might be helpful in getting the guest configuration set up. Essentially, using virsh (assuming you're working with libvirt), do

virsh net-list
virsh net-edit $NETWORKNAME

Look for the dhcp section and edit to something like this

<dhcp>
  <range start='192.168.122.100' end='192.168.122.254'/>
  <host mac='52:54:00:6c:3c:01' name='vm1' ip='192.168.122.11'/>
  <host mac='52:54:00:6c:3c:02' name='vm2' ip='192.168.122.12'/>
  <host mac='52:54:00:6c:3c:03' name='vm3' ip='192.168.122.12'/>
</dhcp>

Note: There might be a "hosts" file in /var/lib/libvirt/dnsmasq/ with existing mappings.

nl /var/lib/libvirt/dnsmasq/myvirtnet.lan.hostsfile 
     1  52:54:00:39:ae:1c,192.168.122.242,minirhel.myvirtnet
     2  52:54:00:9b:0a:42,192.168.122.133,rhel7.myvirtnet
     3  52:54:00:f9:1e:45,192.168.122.134,rhel7.myvirtnet
     4  52:54:00:b0:d5:38,192.168.122.205,redqcow.myvirtnet
     5  52:54:00:af:c4:9c,192.168.122.206,redqcow.myvirtnet

Improve this answer
4
  • Thank you. Does the physical router that the physical host is attached to via Ethernet cable need to have dhcp activated? And also, starting with a clean installation of CentOS on the host, how should the host's Ethernet connection to the external physical network be configured in CentOS?
    – CodeMed
    Mar 25, 2017 at 4:05
  • I think the route would have to have DHCP enabled. You may be able to set a static IP on the router side, though I'm not certain. You should try using DHCP and check the router for the give IPs and the respective MAC addresses. That way you could always try to assign Static IPs using those MAC addresses.
    – ILMostro_7
    Mar 25, 2017 at 17:21
  • I am carefully decomposing all that you were kind enough to write. Thank you. But I notice that you are propagating confusion about NetworkManager and bridging. Such confusion is what makes the many google results on this topic confusing and error-prone. While I cannot confirm or deny how NetworkManager and virsh interact with bridges, this link seems to indicate that NetworkManager can create and manage bridges.
    – CodeMed
    Mar 26, 2017 at 16:37
  • @CodeMed the reason I mentioned the issue with bridging and NetworkManager is because that's in the RHEL docs. However, I recall seeing somewhere that NetworkManager had, indeed, received the necessary updates for bridging to work properly; hence my additional quip about ongoing development in NetworkManager.
    – ILMostro_7
    Mar 27, 2017 at 7:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .