Page History

...

• Enable Security Groups
  • There are several issues with the current implementation of security groups over OVS networks, mainly concerning the inability of OVS to forward packets for processing to netfilter. Apart from that, it would be better from an architectural point of view to implement security groups within the OVS flow table. 
    The most important issue here is that OVS does not allow to specify port ranges in flow table entries (CIDRs can be used for network addresses). This means that rules which apply to port ranges needs to be translated into multiple flow table entries. 
    This has two consequences: i) managing abstract rules and their mapping into OVS flow entries; ii) a potentially very high number of flow table entries which can cause a consistent number of user-mode/kernel-mode context switches due to the limited size of the kernel-level flow table. At the moment we don't have any solution to the management problem, neither we do have an estimate of the performance impact due to the increased number of rules in the flow table. To cut a long story short, we probably need a prototype implementation to state whether an OVS-based approach for security groups is feasible or not.
    It is worth noting that with the latest release of Open vSwitch, which introduces bitmask-like mechanisms for specifying source and destination port attribute, the total number of rules needs is significantly reduced. 

• Anchor
  bypass bypass Bypass the virtual router Bypass the virtual router

  Bypass the virtual router
  • In a nutshell, this enhancement is aimed at allowing inter-subnet routing without going through the virtual router. Once routing rules have been configured through the API, the OVS flow table can be programmed in order to send packet to the appropriate destination host, even if that host is in a different tunnel mesh (virtual subnet). 
    For more information about inter-network routing, a feature which is currently being implemented on the VLAN backend, please have a look at the following specification from Alena: Inter-VLAN Routing functional spec
• Consider alternatives to GRE overlays
  • GRE does not scale particularly well when the traffic directed to the physical tunnel interface increases. Apart from the performance overhead due to the GRE header, which amount to about 3%, the real issue is the fact that with GRE encapsulation it is not possible to leverage TCP segmentation offload. This means that GRE packets are not fragmented in hardware, but in software. This affects the overall throughput, which decreases as the amount of traffic sent over the tunnel increases. Please see the attached documents (GRE-overhead-analysis.docx, GRE-overhead-analysis-no-TSO.docx) for more information.

...