[ovs-discuss] VLANs and DHCP

Scott Lowe scott.lowe at scottlowe.org
Tue Nov 24 21:12:35 UTC 2015


Hi Jeff, sorry for the delay in responding to you. Please see my responses inline, prefixed by [SL].


> On Oct 21, 2015, at 10:47 AM, Jeff Forbes <jeff.forbes at mail.nacon.com> wrote:
> 
> Scott,
> 
> Thanks for you detailed response. I will try to explain in more detail
> what we are trying to accomplish with openvswitch and VLANs. The
> networking environment we are trying to setup is somewhat out of the
> ordinary, as we have many small subnets (only 1-3 VMs each) that are
> isolated using ebtables rules. The small subnets are typically in the
> larger 10.0.x.y (netmask 255.255.0.0) subnet. For example, one subnet
> with two VMs would have IPs of 10.0.1.2 and 10.0.1.10. Another subnet
> with two VMs may have 10.0.28.1 and 10.0.28.5. Each of these subnets
> would then use the server at 10.0.0.1 to get its IP addresses and for
> internet access when configured for that. As I said above, we use
> ebtables rules to isolate the networks based on the MAC address.


[SL] So if I understand correctly, these VMs *think* (based on IP address and subnet mask) that they are all part of the same subnet, but are being segregated at layer 2 using ebtables rules based on MAC address. This allows you to use a single router/DHCP server (at 10.0.0.1) but still keep the systems isolated within the same subnet/broadcast domain. Does that sound correct?


> The environment is highly dynamic with sets of VMs and their associated
> subnets typically running for only tens of minutes to several hours.


[SL] Do you have some sort of orchestration system in place to assist with the dynamic nature of this environment? I'll touch on this more later, but it sounds to me like the biggest challenge is orchestration of the environment (installing/updating/removing rules for VM-to-VM connectivity as VMs are spawned/killed).


> We think that the networking options provided by openvswitch will be
> more efficient, scale better and easier to make complex networking
> scenarios than using sets of ebtables rules.


[SL] I'll defer to the OVS experts, but you could certainly do the same thing you're doing now (with ebtables rules) using OVS (using OpenFlow flows). I don't know that the complexity of the system will be reduced, and I still see the biggest challenge as orchestration (you need something to assist with installing/removing flow rules as VMs are spawned/killed). In this case, you could potentially use an OpenFlow controller to assist with that process. You might still need something else (a custom application, a cloud management system, etc.) to talk to the OpenFlow controller.


> I hope that I have provided sufficient detail to allow for you and other
> group members to provide some insight into how to accomplish the type of
> networking scenario we need with openvswitch.
> 
> Best,
> 
> Jeff
> 
> 
> On Fri, 2015-10-02 at 08:51 -0600, Scott Lowe wrote:
>> Hi Jeff, please see my responses inline, prefixed by [SL].
>> 
>> 
>> Jeff Forbes <jeff.forbes at mail.nacon.com> wrote:
>> 
>>> I have set up the openvswitch demo for isolating VM traffic using VLANs.
>>> The setup works as expected. The difficulty I am having is with using
>>> DHCP to assign the IPs. The two VLANs have IP ranges of 10.0.0.x and
>>> 10.0.1.x and the netmasks are 255.255.0.0. I have been able to get
>>> dnsmasq to assigned IPs for one of the VLANs by  assigning an internal
>>> openvswitch port on the DHCP server the ip of 10.0.0.1 and the tag of
>>> one of the VLANs.
>> 
>> 
>> [SL] Based on the network addresses and subnet mask provided, you have a
>> situation where you have two VLANs (which are Layer 2 broadcast domains)
>> inside a single IP network (which is a Layer 3 broadcast domain). This can
>> produce some unexpected (and typically undesired) results. Generally, you'll
>> align your VLANs with your IP subnets, since systems can't communicate
>> across VLANs without passing through a Layer 3 device anyway.
>> 
>> 
>>> The goal is to be able to have multiple vlans with IPs in the 10.0.x.y
>>> range and have them assigned IPs based on the VMs MAC address.
>>> What is the best way to have the DHCP daemon recognize the different
>>> VLANs?
>> 
>> 
>> [SL] DHCP itself is not VLAN-aware and operates within a Layer 2 broadcast
>> domain (a VLAN). Without assistance, a single DHCP server in one VLAN won't
>> be able to provide IP address leases to systems outside its own VLAN. That
>> assistance comes in the form of a DHCP relay, which takes DHCP requests on
>> one VLAN and forwards them across a router to the DHCP server in the other
>> VLAN.
>> 
>> 
>>> I tried to use the trunk directive, but dnamasq did not respond to the
>>> broadcast DHCP request. 
>>> 
>>> The reason for using the 10.0.x.y address space is that we would like to
>>> be able to have some of the VLANs be able to communicate between each
>>> other without changing the VLAN tag. Is there a way of doing this?
>> 
>> 
>> [SL] Systems in different VLANs can't communicate with systems in other
>> VLANs without passing through a Layer 3 device (a router).
>> 
>> Can you share a bit more on exactly *what* you're trying to achieve with
>> this particular environment, so that we can try to provide some guidance as
>> to how to achieve it?


-- 
Scott




More information about the discuss mailing list