Open Stack

(adding the list)

* Dan Wendlandt (dan at nicira.com) wrote:
> On Tue, Aug 14, 2012 at 3:00 PM, Robert Kukura <rkukura at redhat.com> wrote:
> > >     Just as a sanity check, my plan is for the OVS agent to use a
> > separate
> > >     integration bridge for each physical network interface on which it
> > >     realizes flat networks and/or VLANs. Is this what you would expect?
> > >
> > >     I'm planning to stick with the current approach of leaving it to the
> > >     administrator to create these integration bridges and attach the
> > >     physical interfaces to them. Therefore, instead of linuxbridge's
> > >     physical_interface_mappings configuration variable, the openvswitch
> > >     agent will use a physical_bridge_mappings variable that maps physical
> > >     network names to pre-configured integration bridge names. Are you OK
> > >     with this approach?
> > >
> > >
> > > hrmm... I would have expected a single integration bridge, with patch
> > > ports (or veths, since path ports are not supported with the OVS kernel
> > > model) connecting a particular local vlan on the integration bridge with
> > > an external bridge (and possible external vlan) there.
> > >
> > > Otherwise you need to change the vifplugging logic for
> > > OVS fundamentally, and in ways that won't work with some other plugins
> > > (e.g., NVP).  It would also prevent a VM NIC being moved from one
> > > provider network to another unless the agent grew the ability to move
> > > ports from one bridge to another dynamically.
> >
> > I'm really glad I asked before implementing the agent!
> 
> me too :)
> 
> 
> > If I understand your suggested approach, it would make VLANs and flat
> > networks work similarly to the way tunnels currently work. All virtual
> > networks would be assigned local VLAN tags unique within the integration
> > bridge. I expect this approach to significantly reduce the amount of
> > code in the agent, since we'd no longer have separate OVSQuantumAgent
> > and OVSTunnelQuantumAgent classes.
> 
> yeah, that has been the high-level goal for a while, so would be great to
> move closer to that.
> 
> > Then the question is how to patch the local VLAN in the integration
> > bridge to the actual physical interface or the VLAN on the actual
> > physical interface.
> 
> Dan, can you provide a quick overview of how both
> > patch ports and veths would accomplish this?
> >
> 
> You can see an example of using patch ports in the OVS plugin here:
> https://github.com/openstack/quantum/blob/master/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py#L547
> 
> basically, we're creating a patch port between br-int and br-tun in this
> example.  In your case, you'd want to create a brX for each ethX, and then
> attach ethX to brX.  The easiest thing to do would probably be that for a
> mapping of a local vlan A to a global vlan M on ethX, create a patch port
> from br-int to brX, and put the br-int port of the patch as an access port
> on VLAN A, and put the brX side port as an access port on VLAN M (note,
> putting a port as an access port in OVS just means setting the 'tag'
> property on the Port, see:
> https://github.com/openstack/quantum/blob/master/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py#L126
> )
> 
> veths would be very similar, just using a different library call to create
> the pair of devices.  quantum.agent.linux.ip_lib has an add_veth() method
> that let's you do this.

Should be functionally equivalent to something like:

ip link add name int-to-tun type veth peer name tun-to-int
ovs-vsctl add-port br-int int-to-tun
ovs-vsctl add-port br-tun tun-to-int

to connect the two.

> > Chris, can you confirm that patch ports are not available in RHEL, so
> > we'd need to use veths for this? I'm OK with doing patch ports first if
> > both are needed and patch ports are more straightforward, then add the
> > veth option as bug fix.

There is no patch port support in the upstream kernel module, so same
for Fedora, and other distros not using an out-of-tree module.

> > Would patch ports avoid the need to create sub-interfaces for each VLAN
> > on each physical interface?
> >
> 
> I don't think you need sub-interfaces in either case, using the method I
> described above.  Remember that OVS, unlike LB, is a vlan aware switch.
> 
> I think the veth model is actually more general, as it should work
> regardless.  OVS patch ports were introduced by the OVS developers I
> believe because they wanted something more lightweight than veths, but for
> this use case, I'm not sure it matters.
> 
> Thanks,
> 
> Dan
> >
> > -Bob
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~