1 / 16

Encapsulation in OVN

Encapsulation in OVN. What we have and what we want. Mark Michelson Senior Software Developer Red Hat mmichels@redhat.com. Questions I get asked. “Hey we don’t need Geneve given our physical network topology. Is there a way we can use OVN without encapsulation?”

jsalvador
Download Presentation

Encapsulation in OVN

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Encapsulation in OVN What we have and what we want Mark Michelson Senior Software Developer Red Hat mmichels@redhat.com

  2. Questions I get asked “Hey we don’t need Geneve given our physical network topology. Is there a way we can use OVN without encapsulation?” “I heard Geneve causes lower throughput. Can we use VXLAN instead?”

  3. What OVN currently offers • Between hypervisors • Geneve (preferred) • STT • When communicating with gateways • VXLAN Encapsulation allows for communication in an overlay network no matter what the topology of the underlay network is.

  4. The Process • Packet arrives on VIF • OVN associates the OF port with a logical ingress port and logical datapath • OVN runs the ingress pipeline for the logical datapath and determines a logical output port • If the logical output port is bound to the local hypervisor, then OVN runs the egress pipeline for the logical datapath and outputs the packet. • If the logical output port is bound to a remote hypervisor, then OVN encapsulates the packet and sends it to the remote hypervisor.

  5. What is encapsulated? • 24-bit logical datapath identifier • 15-bit logical input port • 16-bit logical output port 55 bits total Geneve and STT naturally have the space for this information. VXLAN only encodes datapath identifier in its 24-bit VNI field. It is assumed there is only a single logical input port.

  6. The Process • Packet arrives on a tunnel • For Geneve and STT • OVN unpacks the logical input port, logical datapath, and logical output port from the encapsulation metadata. • OVN runs the egress pipeline of the logical datapath and outputs the packet • For VXLAN • OVN unpacks the logical datapath from the encapsulation metadata. • OVN runs the ingress pipeline of the logical datapath and determines the output port. • OVN runs the egress pipeline of the logical datapath and outputs the packet.

  7. What alternatives does OVN offer? “localnet” ports • Provide a link between the integration bridge and physical network • Can be associated with a particular VLAN tag Some restrictions: • Can only have one localnet port per hypervisor • localnet port is associated with a single logical switch. Can we have “native” encapsulation-free hypervisor-to-hypervisor traffic?

  8. Consequences of removing encapsulation Removing encapsulation fundamentally breaks the model of OVN. That is, we mix the physical network with the virtual network. This has potential security implications, since we are opening up the integration bridge directly to the physical network. With no encapsulation metadata, we have to use dubious means to determine the logical input port and logical datapath. With no encapsulation, the OVN network must be an underlay network. But let’s continue anyway...

  9. No encapsulation Possible solution: Determine input port and datapath based on source addresses. To say this feels insecure is an understatement. Also, there’s NAT. However, in some closed environments, this may be valid.

  10. No encapsulation Possible solution 2: Have a dedicated port on each datapath dedicated to HV-to-HV traffic. This is similar to a localnet port, but you can have more than one per hypervisor. It would require a secondary virtual-to-physical bridge with the smarts to switch traffic from the physical port to the correct patch port.

  11. Conditional lack of encapsulation AKA “smart encapsulation” Perhaps it is possible to forgo encapsulation under certain circumstances. • when transmitting between ports on the same logical switch. • when transmitting within an IP network This could allow for unencapsulated traffic to be used in a wider range of network topologies. OVN would have to be able to deal with the idea that traffic received on a port may or may not be encapsulated

  12. What about VXLAN? AKA “limited use encapsulation” VXLAN is currently only supported for communication between hypervisors and gateways. No input or output port is provided in the encapsulation, only the datapath. VXLAN doesn’t have the negative press that Geneve has received. Could VXLAN be usable for HV-to-HV traffic?

  13. What about VXLAN? Possible solution 1: Scaled down network. VXLAN doesn’t have as many bits for metadata as STT or Geneve. Maybe we could use smaller identifiers for ports and datapath? Unfortunately, this probably would not work. The restricted size would be an immediate issue for many deployments. Knock-on effects include making multicast unusable, since multicast groups get assigned large tunnel keys.

  14. What about VXLAN? Possible Solution 2: Encapsulate the logical output port. Maybe all ingress and egress paths could be run on the hypervisor with the source VIF. Then encapsulate the packet and only encapsulate the logical output port. When the remote hypervisor receives the packet, then all it has to do is output the packet directly to the appropriate port. This would require all hypervisors to have the exact same OF rules installed. Currently, hypervisors work to only install rules that pertain to them.

  15. Conclusion Encapsulation free OVN is not an easy ask. It would require compromises on both the physical topology, and possibly the logical topology. VXLAN may be in a position to mitigate some concerns about Geneve, but its scalability is questionable. The best solution is to get rid of the negative press surrounding Geneve, and prove that it’s just as good to use as VXLAN. ...Or maybe someone more clever than me needs to take a look at this.

  16. THANK YOU plus.google.com/+RedHat facebook.com/redhatinc linkedin.com/company/red-hat twitter.com/RedHatNews youtube.com/user/RedHatVideos

More Related