[ovs-discuss] Confused about the "multilayer" aspect of OVS

Ben Pfaff blp at nicira.com
Tue Nov 20 16:58:12 UTC 2012


That's in line with one of the (my?) overall goals for Open vSwitch: to
be a suitable platform on top of which to layer higher-level services.
Certainly Open vSwitch is useful on its own, but the possibilities are
much more exciting when an intelligent OpenFlow controller or other
suitable software gets added into the mix.

On Tue, Nov 20, 2012 at 10:02:16AM -0600, Brad Hedlund wrote:
> Good dialogue. This approach makes sense as it fosters an ecosystem of
> commercial and open source routing providers layering on top of OVS as a
> platform -- Rather than the OVS project taking up the task of deciding what
> people want and developing a suite of routing protocols from scratch.
> 
> Cheers,
> Brad
> 
> On Tue, Nov 20, 2012 at 8:21 AM, Will Dennis <willard.dennis at gmail.com>wrote:
> 
> > Thanks, Ben, for your response. This clears things up for me. The routing
> > function must be provided by an outside means, whether an OF controller, or
> > a host-based or perhaps external router (trunk connection to external
> > router, what is called "router-on-a-stick" in some circles.) I was just
> > trying to determine if OVS itself had a routing function "built-in" (static
> > or perhaps even dynamic) that I was missing.
> >
> > Best,
> > Will
> >
> >
> > On Nov 19, 2012, at 11:47 PM, Ben Pfaff <blp at nicira.com> wrote:
> >
> > > On Mon, Nov 19, 2012 at 10:21:50PM -0500, Willard Dennis wrote:
> > >> On the OVS homepage, under the heading "What is Open vSwitch?" it
> > states:
> > >> "Open vSwitch is a production quality, multilayer virtual switch [...]"
> > >>
> > >> My understanding of a multilayer switch is one that not only does
> > >> traditional layer two switching, possibly with multiple VLANs (i.e
> > >> maintains separate L2 forwarding tables for each VLAN) but that also
> > can do
> > >> routing between such VLANs (via virtual VLAN interfaces) without
> > requiring
> > >> an outboard router.
> > >>
> > >> In a testbed setup (comprised of a single Ubuntu Linux box) that I
> > recently
> > >> constructed to learn more about Open vSwitch (and OpenFlow, though that
> > is
> > >> ancillary to this discussion) I instantiated a OVS soft-switch that has
> > >> three VLANs on it:
> > >> VLAN 10 - actual physical ports (interfaces = eth0, eth1, etc.), used to
> > >> communicate with physical infrastructure
> > >> VLAN 20 - VM hosts (interfaces = vnet0, vnet1, etc - in this case, I'm
> > >> using KVM with libvirt)
> > >> VLAN 30 - connection to a router virtualization platform
> > >> (Dynamips/Dynagen/GNS3) via a tuntap interface [see http://www.gns3.netfor
> > >> more detail if desired]
> > >>
> > >> In looking into how to then configure routing between the three VLANs
> > >> within OVS, and not finding anything on the OVS site, I finally came
> > upon
> > >> this article:
> > >> http://blog.scottlowe.org/2010/04/23/configuring-inter-vlan-routing/
> > >>
> > >> So, it seems that the (current) OVS switch implementation is not what
> > I'd
> > >> think of as a "multilayer" switch, as it seems that you have to use the
> > >> Linux kernel routing to perform the routing between the "vlanX"
> > interfaces
> > >> (and this would be an "outboard" router to OVS to me.)
> > >
> > > I'm not sure what the exact intent of that claim is.  It may simply mean
> > > that Open vSwitch can match and act based on multiple layers
> > > (specifically, L2, L3, and L4).  But I believe that it is still correct,
> > > even if one takes the narrower meaning that you suggest, because there
> > > are at least two ways that you can implement routing with OVS.  One is
> > > to use OpenFlow, with a controller.  Another is to use the Linux TCP/IP
> > > stack, on the same box running Open vSwitch, possibly with network
> > > namespaces to implement separation.
> > _______________________________________________
> > discuss mailing list
> > discuss at openvswitch.org
> > http://openvswitch.org/mailman/listinfo/discuss
> >



More information about the discuss mailing list