Hi, 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? Cheers, Chris _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
