[ovs-dev] Questions about a specific use-case of OVS
chris at rurallink.co.nz
Wed Mar 28 16:30:04 PDT 2012
I am a Network Engineer/C Developer for a small Telco in New Zealand. We are
very pro Linux based solutions to problems most telco's would normally throw
lots of cash at big brands for.
The specific problem that started me looking to openvswitch for is this:
We get customers delivered to us over QinQ, with a single stag/ctag combo
representing a single customer. We then want to smartly decide what we do with
these customers. For some we will merge into a single split horizon layer2 for
Internet access, for some we will bridge two(or more customers (stag/ctag
combos)) together for extending LAN's between to locations, for some we might
both provide Internet and join multiple customers. Open vswitch seems like a
very good starting point for doing this under Linux.
Looking at both the kernel data path code, and the user-space switch I can see
a couple of things that would need to be addressed for us to archive this.
First, the kernel module does not support matching on multiple VLAN tags. I
can ignore this issue for the split horizon layer 2 for the Internet and just
match on mac address to push_vlan actions mappings, but for joining LAN's
where I cannot guarantee the uniqueness of MAC addresses I will need to have
the datapath aware of stacked VLAN tags and only match on those. I have heard
that multiple people have attempted to solve this, and submitted patches, but
nothing has been accepted. Is QinQ something that openvswitch plan to support?
If so, is there somebody working on this that I can work with or are there any
patches that are good place to start from and perhaps complete?
Second, openvswitch is currently a Layer 4 aware switch (from what I have seen
from the datapath so far). The kernel will always wonder as deep into the
packet as it can making keys, then hash on all of the keys. This means that if
I have an IP packet, I cannot switch purely on the mac addresses. Now
obviously it is very easy to hack the kernel module to stop at layer 2 for me,
but it seems more useful to configure the datapath to stop at an arbitrary
layer, perhaps for now layers 2 or 3. Chatting to people on your IRC channel
it was suggested that such a patch was too specialized, and perhaps a patch
that made all of the protocols selectable would be more appropriate. This
doesn't seem like a hard patch, but I would love to hear your opinion.
The other harder and slower approach to my problem would be allow partial
matches on keys. I haven't thought this idea through, but the problems that
arise in the couple of minutes I have spent thinking are, how do you know what
keys to do the hash check on, what happens when there is a more specific match,
and how do you do this without doing lots of hash lookups. To do it fast would
require tree rather than a hash.
Ultimately, if we could tell the datapath that we are not interested in higher
layers, we can optimize away many trips to user-space for flows we will never
want to see and also keep the hashes smaller, and the hash count lower. All
making the switching more optimized for this type of use. Has the idea of
stopping at earlier layers or protocols ever come up within the team? If we
were to work towards implementing something like this would it be in line with
the projects goals?
More information about the dev