[ovs-discuss] Separate DHCP services for two OVS fake bridges?

Will Dennis (Live.com) willarddennis at live.com
Tue Apr 16 15:40:29 UTC 2013


Ah, maybe this is the problem?

 

http://openvswitch.org/pipermail/discuss/2013-March/009386.html

 

I did terminate the Floodlight controller process, and now the VM on the “20-net” (= vl20-ovsbr0 fake bridge) does not get any DHCP address. So looks like I will have to learn how to “put[…] ‘normal’ into the lists of actions on  ovs-ofctl or by outputting to OFPP_NORMAL from an OpenFlow controller” – any pointers on how to do this, and make it persistent?

 

Thanks,

Will

 

From: discuss-bounces at openvswitch.org [mailto:discuss-bounces at openvswitch.org] On Behalf Of Willard Dennis
Sent: Friday, April 12, 2013 12:46 PM
To: discuss at openvswitch.org
Subject: [ovs-discuss] Separate DHCP services for two OVS fake bridges?

 

Hi all,

 

I’m setting up a testbed virtualization server for a research group here. The architecture is that I’m using Open vSwitch (1.10.90) and have a bridge (named ovsbr0) that is attached to an OpenFlow controller (in our case, Floodlight v0.90.) I then have instantiated two OVS “fake bridges” to provide automatic VLAN tagging (vl10-ovsbr0 -> tag “10”, vl20-ovsbr0 -> tag “20”) to libvirt networks that are defined around the two fake bridges. The upshot of all of this so far is that I can instantiate a VM thru “virt-manager”, set the NIC of the VM to use either “10-net” or “20-net”, and the VMs get a port on the correct fake bridge, and their “vnet#” port gets tagged with the correct VLAN tag. 

 

So now I would like to provide DHCP (and DNS) to these VMs, but have different DHCP IP address pools for each fake bridge (= libvirt network.) I have read that libvirt can not assign IPs to the networks itself if the forward mode is “bridge”. So I attempted to do this with dnsmasq running on the host system, and configured it to only listen to the vl10-ovsbr0 interface (which I thought would restrict the DHCP service to only that one fake bridge.) Sure enough, VMs I instantiated and attached to the “10-net” did get a DHCP-assigned address (192.168.10.x). Then I spun up another VM and attached it to the “20-net” and was expecting it to not get assigned an IP address (since there was ostensibly no DHCP service for that network) but to my surprise, the VM *did* get a DHCP address assigned, from the pool I established for the “10-net”! This obviously is not what I want. Now I’m wondering how this worked, and if I can fix it.

 

Here’s my OVS setup at present:

 

# ovs-vsctl show
3e0d861b-efb7-46b1-af1b-4a76cd833558
    Bridge "ovsbr0"
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        Port "ovsbr0"
            Interface "ovsbr0"
                type: internal
        Port "vnet0"
            tag: 10
            Interface "vnet0"
        Port "vnet1"
            tag: 10
            Interface "vnet1"
        Port "vl10-ovsbr0"
            tag: 10
            Interface "vl10-ovsbr0"
                type: internal
        Port "vl20-ovsbr0"
            tag: 20
            Interface "vl20-ovsbr0"
                type: internal
        Port "vnet2"
            tag: 20
            Interface "vnet2"
# ovs-vsctl list-br
ovsbr0
vl10-ovsbr0
vl20-ovsbr0
# ovs-vsctl --real list-br
ovsbr0
# ovs-vsctl --fake list-br
vl10-ovsbr0
vl20-ovsbr0
# ovs-vsctl list-ports vl10-ovsbr0
vnet0
vnet1
# ovs-vsctl list-ports vl20-ovsbr0
vnet2

Here’s the config stanzas in my dnsmasq.conf file:

 

interface=vl10-ovsbr0
bind-interfaces
dhcp-range=192.168.10.50,192.168.10.150,4h

(also, tried changing the “interface=vl10-ovsbr0” stanza to “listen-address=192.168.10.254” which is the IP addr I assigned the vl10-ovsbr0 int in Linux, but that didn’t work to fix the problem either...)

 

Anyone have any ideas on how to get the two fake bridges to have separate DHCP service?

 

Thanks,

Will

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20130416/ab61881e/attachment.html>


More information about the discuss mailing list