Open vSwitch (OVS) has long been a critical component of the Neutron's reference implementation, offering reliable and flexible virtual switching for cloud environments.
Being an early adopter of the OVS technology, Neutron's reference implementation made some compromises to stay within the early, stable featureset OVS exposed. In particular, Security Groups (SG) have been so far implemented by leveraging hybrid Linux Bridging and IPTables, which come at a significant performance overhead. However, thanks to recent developments and ongoing improvements within the OVS community, we are now able to implement feature-complete security groups directly within OVS.
In this talk we will summarize the existing Security Groups implementation in Neutron and compare its performance with the Open vSwitch-only approach. We hope this analysis will form the foundation of future improvements to the Neutron Open vSwitch reference design.
A healthy diet for your Java application Devoxx France.pdf
Taking Security Groups to Ludicrous Speed with OVS (OpenStack Summit 2015)
1. Taking Security Groups
to Ludicrous Speed
with Open vSwitch
OpenStack Summit
Vancouver, 2015
Miguel Angel Ajo
@mangel_ajo
Ivar Lazzaro
@ivarlazzaro
Thomas Graf
@tgraf__
Justin Pettit
@Justin_D_Pettit
2. Agenda
Problem Statement
– Status Quo – a.k.a “The Bridge Mess”
Possible Solution
– OVS + Stateful services (+ OVN)
Results
– Performance Numbers
Q&A
11. Can we have a pure OVS Model?
br-int
(Open vSwitch)
VM
br-eth1
(Open vSwitch)
VM lxc
Tap, veth, or
internal port
OpenFlow table
with security groups
OVS
bridge
1 network device per guest in host!
Makes VMs and containers equally happy.
14. ● Virtual Networking for OVS
– Developed by same team that made OVS
– Works on same platorms (Linux, Containers, Hyper-V)
● Provides L2/L3 virtual networking
– Logical switches and routers
– Conntrack-based security groups
– L2/L3/L4 ACLs
– Physical and DPDK-based logical-physical gateways
● Integrated with OpenStack and other CMSs
OVN
15. Implementing a Firewall with OVS
● OVS has traditionally only supported stateless matches
● As an example, currently, two ways to implement a firewall in OVS
– Match on TCP flags (Enforce policy on SYN, allow ACK|RST)
● Pro: Fast
● Con: Allows non-established flow through with ACK or RST
set, only TCP
– Use “learn” action to setup new flow in reverse direction
● Pro: More “correct”
● Con: Forces every new flow to OVS userspace, reducing flow
setup by orders of magnitude
– Neither approach supports “related” flows or TCP window
enforcement
16. Connection Tracking
● We are adding the ability to use the conntrack module from Linux
– Stateful tracking of flows
– Supports ALGs to punch holes for related “data” channels
● FTP, TFTP, SIP
● Implement a distributed firewall with enforcement at the edge
– Better performance
– Better visibility
● Introduce new OpenFlow extensions:
– Action to send to conntrack
– Match fields on state of connection
● Have prototype working. Expect to ship as part of OVS in next
release.
20. OVSFirewallDriver
● Original proposal from Amir Sadoughi
– https://review.openstack.org/#/c/89712
● Stable/kilo (just a POC)
– https://review.openstack.org/#/c/183725/
21. Example HTTP Request
VM 1 VM 2
HTTP req
response
GLOSARY of OF actions
NORMAL = “do like a normal switch”
ct(commit) = “push this packet to CT”
ct(recirc) = “grab any ct info we have, set
+trk, and send to T0”
22. SG OpenFlow Table structure
+trk(+est/+rel)
→ NORMAL
ARP (with filters)
→ NORMAL
(…)
SG rules in OF:
ip
Egress T1Input T0 ct(commit,
recirc)
(…)
SG rules:
tp_dst=80
Ingress T2
From VM(n)
(MAC+in_port -trk)
-trk → ct(recirc)
ToVM(n)(MAC)
match
ct(commit),NORMAL
VM1
VM2
23. SG OpenFlow Table structure
+trk(+est/+rel)
→ NORMAL
ARP (with filters)
→ NORMAL
(…)
SG rules in OF:
ip
Egress T1Input T0 ct(commit,
recirc)
(…)
SG rules:
tp_dst=80
Ingress T2
From VM(n)
(MAC+in_port -trk-trk)
-trk → ct(recirc)
ToVM(n)(MAC)
match
ct(commit),NORMAL
VM1
24. SG OpenFlow Table structure
+trk(+est/+rel)
→ NORMAL
ARP (with filters)
→ NORMAL
(…)
SG rules in OF:
ip
Egress T1Input T0 ct(commit,
recirc)
(…)
SG rules:
tp_dst=80
Ingress T2
From VM(n)
(MAC+in_port -trk)
-trk → ct(recirc)
ToVM(n)(MAC)
match
ct(commit),NORMAL
25. SG OpenFlow Table structure
+trk(+est or +rel)
→ NORMAL
ARP (with filters)
→ NORMAL
(…)
SG rules in OF:
ip
Egress T1Input T0 ct(commit,
recirc)
(…)
SG rules:
tp_dst=80
Ingress T2
From VM(n)
(MAC+in_port -trk)
-trk → ct(recirc)
ToVM(n)(MAC)
match
ct(commit),NORMAL
26. SG OpenFlow Table structure
+trk(+est/+rel)
→ NORMAL
ARP (with filters)
→ NORMAL
(…)
SG rules in OF:
ip
Egress T1Input T0 ct(commit,
recirc)
(…)
SG rules:
tp_dst=80
Ingress T2
From VM(n)
(MAC+in_port -trk)
-trk → ct(recirc)
ToVM(n)(MAC)
match
ct(commit),NORMAL
VM2
27. SG OpenFlow Table structure
+trk(+est/+rel)
→ NORMAL
ARP (with filters)
→ NORMAL
(…)
SG rules in OF:
ip
Egress T1Input T0 ct(commit,
recirc)
(…)
SG rules:
tp_dst=80
Ingress T2
From VM(n)
(MAC+in_port -trk)
-trk → ct(recirc)
ToVM(n)(MAC)
match
ct(commit),NORMAL
VM2
28. SG OpenFlow Table structure
+trk(+est/+rel)
→ NORMAL
ARP (with filters)
→ NORMAL
(…)
SG rules in OF:
ip
Egress T1Input T0 ct(commit,
recirc)
(…)
SG rules:
tp_dst=80
Ingress T2
From VM(n)
(MAC+in_port -trk)
-trk → ct(recirc)
ToVM(n)(MAC)
match
ct(commit),NORMAL
29. SG OpenFlow Table structure
+trk(+est/+rel)
→ NORMAL
ARP (with filters)
→ NORMAL
(…)
SG rules in OF:
ip
Egress T1Input T0 ct(commit,
recirc)
(…)
SG rules:
tp_dst=80
Ingress T2
From VM(n)
(MAC+in_port -trk)
-trk → ct(recirc)
ToVM(n)(MAC)
match
ct(commit),NORMAL
VM1
30. SG OpenFlow Table structure
+trk(+est/+rel)
→ NORMAL
ARP (with filters)
→ NORMAL
(…)
SG rules in OF:
ip
Egress T1Input T0 ct(commit,
recirc)
(…)
SG rules:
tp_dst=80
Ingress T2
From VM(n)
(MAC+in_port -trk)
-trk → ct(recirc)
ToVM(n)(MAC)
match
ct(commit),NORMAL
41. Conclusion
● Both throughput and latency are considerably improve (Up to 6x in
some situations).
● If limited by wire speed, pure OVS approach generally consumes
less CPU cycles for the same result, leaving more resources for
actual workload.
● Issue for specific packet sizes to be investigated and resolved before
merge.
42. Next Steps
● Convert ML2 PoC to a patch that can be merged
– Write functional tests
– Optimize OF rules/manipulation
● Complete upstream merge of connection tracking
support in Open vSwitch in the Linux kernel
● Consider and realize OVN integration of this work
● Hopefully ready for Liberty