[ovs-discuss] kvm guests and vlans

[Ben Pfaff]

On Fri, Oct 05, 2018 at 10:24:23PM +0000, Srinivas wrote:
> > ovs-vsctl \
>           -- add-br br0 \
>           -- add-port br0 bond0 tag=0 \
>           -- add-port br0 bond0.11 tag=11 \
>           -- add-port br0 bond0.12 tag=12 \
>           -- add-port br0 vm1 tag=0 \
>           -- add-port br0 vm2 tag=11 \
>           -- add-port br0 vm3 tag=12
> 
> Thanks Ben. The reason i need to break out the child interfaces from bond0 is that i have some applications on the host that would be receiving traffic from vlans 11 and 12. My requirement is that guests on vlan11 and vlan12 will need to talk to these applications running on bond0.11 and bond0.12 respectively and also go out onto the lan to reach other machines on vlan11 and 12.

It sounds like you're planning to configure IP addresses on the bond0.11
and bond0.12 interfaces.  This is not a good idea.  The FAQ addresses
some of this:

Q: I created a bridge and added my Ethernet port to it, using commands like
these::

    $ ovs-vsctl add-br br0
    $ ovs-vsctl add-port br0 eth0

and as soon as I ran the "add-port" command I lost all connectivity through
eth0.  Help!

    A: A physical Ethernet device that is part of an Open vSwitch bridge should
    not have an IP address.  If one does, then that IP address will not be
    fully functional.

    You can restore functionality by moving the IP address to an Open vSwitch
    "internal" device, such as the network device named after the bridge
    itself.  For example, assuming that eth0's IP address is 192.168.128.5, you
    could run the commands below to fix up the situation::

        $ ip addr flush dev eth0
        $ ip addr add 192.168.128.5/24 dev br0
        $ ip link set br0 up

    (If your only connection to the machine running OVS is through the IP
    address in question, then you would want to run all of these commands on a
    single command line, or put them into a script.)  If there were any
    additional routes assigned to eth0, then you would also want to use
    commands to adjust these routes to go through br0.

    If you use DHCP to obtain an IP address, then you should kill the DHCP
    client that was listening on the physical Ethernet interface (e.g. eth0)
    and start one listening on the internal interface (e.g. br0).  You might
    still need to manually clear the IP address from the physical interface
    (e.g. with "ip addr flush dev eth0").

    There is no compelling reason why Open vSwitch must work this way.
    However, this is the way that the Linux kernel bridge module has always
    worked, so it's a model that those accustomed to Linux bridging are already
    used to.  Also, the model that most people expect is not implementable
    without kernel changes on all the versions of Linux that Open vSwitch
    supports.

    By the way, this issue is not specific to physical Ethernet devices.  It
    applies to all network devices except Open vSwitch "internal" devices.

Q: Can I configure an IP address on a VLAN?

    A: Yes.  Use an "internal port" configured as an access port.  For example,
    the following configures IP address 192.168.0.7 on VLAN 9.  That is, OVS
    will forward packets from eth0 to 192.168.0.7 only if they have an 802.1Q
    header with VLAN 9.  Conversely, traffic forwarded from 192.168.0.7 to eth0
    will be tagged with an 802.1Q header with VLAN 9::

        $ ovs-vsctl add-br br0
        $ ovs-vsctl add-port br0 eth0
        $ ovs-vsctl add-port br0 vlan9 tag=9 \
            -- set interface vlan9 type=internal
        $ ip addr add 192.168.0.7/24 dev vlan9
        $ ip link set vlan0 up

    See also the following question.

Q: I configured one IP address on VLAN 0 and another on VLAN 9, like this::

    $ ovs-vsctl add-br br0
    $ ovs-vsctl add-port br0 eth0
    $ ip addr add 192.168.0.5/24 dev br0
    $ ip link set br0 up
    $ ovs-vsctl add-port br0 vlan9 tag=9 -- set interface vlan9 type=internal
    $ ip addr add 192.168.0.9/24 dev vlan9
    $ ip link set vlan0 up

but other hosts that are only on VLAN 0 can reach the IP address configured on
VLAN 9.  What's going on?

    A: `RFC 1122 section 3.3.4.2 "Multihoming Requirements"
    <https://tools.ietf.org/html/rfc1122>`__ describes two approaches to IP
    address handling in Internet hosts:

    - In the "Strong ES Model", where an ES is a host ("End System"), an IP
      address is primarily associated with a particular interface.  The host
      discards packets that arrive on interface A if they are destined for an
      IP address that is configured on interface B.  The host never sends
      packets from interface A using a source address configured on interface
      B.

    - In the "Weak ES Model", an IP address is primarily associated with a
      host.  The host accepts packets that arrive on any interface if they are
      destined for any of the host's IP addresses, even if the address is
      configured on some interface other than the one on which it arrived.  The
      host does not restrict itself to sending packets from an IP address
      associated with the originating interface.

    Linux uses the weak ES model.  That means that when packets destined to the
    VLAN 9 IP address arrive on eth0 and are bridged to br0, the kernel IP
    stack accepts them there for the VLAN 9 IP address, even though they were
    not received on vlan9, the network device for vlan9.

    To simulate the strong ES model on Linux, one may add iptables rule to
    filter packets based on source and destination address and adjust ARP
    configuration with sysctls.

    BSD uses the strong ES model.

> I also see another approach by reading  notes on the web of creating separate bridges for each of the subinterfaces ex bridge.11 by adding bond0.11. 
> Any reason  why creating seperate bridges is preferred over creating a single bridge ?any security concerns if we use a single bridge as you called out?

There's no difference for security.  The "fake" bridge model is only
supported at all because it was initially necessary to support
XenServer.  That need has long since passed but people use the feature
(even though I called it "fake bridges" to discourage them), so we can't
remove it.