1

I am trying to setup a VM using Linux KVM for a F5 BIG-IP VE deployment (used in a lab) https://support.f5.com/content/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ve-kvm-setup-11-3-0/_jcr_content/pdfAttach/download/file.res/BIG-IP®_Virtual_Edition_Setup_Guide_for_Linux_KVM.pdf.

This VM requires 3 different network interfaces (management, external connection, and internal connection)

I have been trying to setup these connections in /etc/network/interfaces with the following configuration:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
# This is an autoconfigured IPv6 interface
iface eth0 inet6 auto

auto br0
iface br0 inet dhcp
   pre-up ip tuntap add dev tap0 mode tap user root
   pre-up ip tuntap add dev tap1 mode tap user root
   pre-up ip tuntap add dev tap2 mode tap user root
   pre-up ip link set tap0 up
   pre-up ip link set tap1 up
   pre-up ip link set tap2 up
   bridge_ports all tap0 tap1 tap2
   bridge_stp off
   bridge_maxwait 0
   bridge_fd      0
   post-down ip link set tap0 down
   post-down ip link set tap1 down
   post-down ip link set tap2 down
   post-down ip tuntap del dev tap0 mode tap
   post-down ip tuntap del dev tap1 mode tap
   post-down ip tuntap del dev tap2 mode tap

Although whenever I go to configure the VM, only one of the tap interfaces will show up as being associated with the bridge. I spent 4-5 hours just trying to get those interfaces working and did not have any luck. What am I doing wrong here?

enter image description here

1
  • I really don't understand. Let's put big manuals aside. Do you need 3 TAP interfaces connected to your host machine or you need 3 interfaces on your VM and one interface outside (connected to host)? Apr 7, 2015 at 19:18

2 Answers 2

1

All you need to set up on the host is the bridge. When you configure virtual NICs, and attach them to the VM, the taps will get created automatically, when the VM is started.

Now, without reading the actual guide, it looks like you need three interfaces on three DIFFERENT networks. If you plug all your virtual NICs into the same bridge (effectively, a virtual switch), they all end up on the same L2 network. You can get by on simple subnetting of course, but if you wantto use VLANs, you need to create a separate bridge on every VLAN tagged interface, and plug the virtual NICs accordingly

0

Dyasny's answer is correct, but leaves out information that may be useful depending on how you wish to design the networking stack on your hypervisor. Bridges themselves support VLAN tagging with subinterfaces (such as br0.10 for VLAN 10 on bridge 0). This way, you can spawn subinterfaces from the bridge, rather than bridges being bound to individual ethernet device subinterfaces. This can greatly simplify your network stack if you operate with many VLANs on your host out of a common fabric.

These VLAN tagged subinterfaces can be used either directly by using them as host devices in a given VM NIC configuration (such as br0.10). When used this way, the VM will communicate on that given VLAN with its virtual ethernet device as if it were native. No tagging will function within the guest. If you need more VLANs, you'll have to emulate more NICs, and those NICs can still be subinterfaces from the same bridge. They CANNOT be the bridge root (br0) if you have already used subinterfaces.

Alternatively, by using the bridge "root" interface (such as br0) for connecting a VM TAP interface, the VM itself can access both the native VLAN on the bridge as well as also create tagged interfaces that function from within the guest just as one would do with the host machine. This can allow several VLANs to be accessed within the guest with only one virtual NIC, simplifying deployments of machines that access several VLANs. VMs will only be able to tag VLANs that have also been tagged on the host bridge. In this way, the host bridge acts as a VLAN database and ACL pretty much like a typical switch would.

And even alternatively to this, Open vSwitch can do this very same activity with a better interface.

EXAMPLE CONFIGURATION:

I'm leaving out everything below the bridge as well as most bridge options, because they're not terribly useful in this layer 2 discussion. Here is an example of using tagged subinterfaces on the host bridge to provide a VLAN ACL set while using the host bridge itself to attach your tap interfaces to.

$> cat /etc/sysconfig/network-scripts/ifcfg-br0

DEVICE=br0
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=none
NM_CONTROLLED=no
DELAY=0

-

$> cat /etc/sysconfig/network-scripts/ifcfg-br0.10

DEVICE=br0.10
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=none
VLAN=yes

Once you've done all of that (or something similar) use br0 as your interface to connect your VM TAP interface, and behold that you may now create a tagged interface within the VM itself for VLAN 10. Bridges can process VLANs and also act as VLAN trunks.

6
  • When you connect a VM to a bridge you do not pass the bridge to a VM, you create a tap interface that plugs into the bridge and the VM, acting as a virtual port between the VM and the bridge. This is why you do not tag bridges and "pass the interface to a VM" but tag an interface, build a bridge on top of the tagged interface, and plug a VM's interface into the tagged bridge. If you have a different experience, please share your configuration, I'd love to test it
    – dyasny
    Mar 11, 2017 at 20:25
  • Perhaps I'm being overly simplistic when I say "pass", so I'll probably edit this to avoid confusion. I'm fully aware that a tap interface is automatically created and bound to the bridge on the host. It's why your answer is correct. It's an easy configuration to test, so I'll attach it.
    – Spooler
    Mar 11, 2017 at 21:21
  • Interesting. However, if you tag inside the VM without br0.x in place, and the underlying interface or bond is connected to a network trunk, it will work nonetheless. So I don't see the point in creating a tag on the bridge, besides, maybe, giving the host an IP on that specific vlan
    – dyasny
    Mar 12, 2017 at 1:43
  • and yes, when you say "pass" in the virtualization context, you can either mean passthrough, or a way to let the VM take over an interface (i.e. macvtap, vm-fex etc)
    – dyasny
    Mar 12, 2017 at 1:44
  • I've never been able to get it to work like that. I've always had to put a VLAN subinterface on the host in order for the tagged traffic on a VM to actually leave the physically connected interface(s). What distribution are you using? In my case, I've only used this on Debian.
    – Spooler
    Mar 12, 2017 at 1:46

You must log in to answer this question.

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