Upload
trinath-somanchi
View
462
Download
11
Embed Size (px)
Citation preview
Agenda• Introduction – What is OVN ? Why its different?• Openstack Neutron with OVN• OVN architecture – DB schema and Utilities• OVN – ACL and L3 Design• OVN L2 – Deep dive – Example • OVN Limitations
Introduction“Open vSwitch is the most popular choice of virtual switch in OpenStack deployments. To make OVS more effective in these environments, we believe the logical next step is to augment the low-level switching capabilities with a lightweight control plane that provides native support for common virtual networking abstractions.”
- OVN, uses a protocol called OVSDB (Open vSwitch Database), which is an open protocol defined in RFC 7047 and has been used up until now as a management protocol to configure OVS.
What is OVN?• Opensource Virtual Networking for OVS.• Provides L2/L3 virtual Networking
• Logical Switches and Routers.• Security groups• L2/L3/L4 ACLs• Multiple tunnel overlays (Geneve, STT and VxLAN)• TOR-based and software-based logical-physical gateways
• Work on same platforms as OVS• Linux (KVM and XEN).• Containers• DPDK
• Integration with Openstack and other CMS.
Why OVN is different ?• Will not require any additional agents for functionality for simplified
deployment and debugging.• Security groups using new in-kernel conntrack integration.• More secure and faster than other methods.
• DPDK-based and hardware-accelerated gateways.• Leverages new OVS DPDK port.• Works with switches from Arista, Brocade, Cumulus, Dell, HP, Juniper, and
Lenovo
Openstack Neutron with OVN• ML2 driver for OVN.• Replaces OVS ML2 driver and Neutron’s OVS agent.
• Speaks OVSDB to configure OVN via its Northbound database.• Only run Neutron API server – No other agents.• No RabbitMQ ( except for notifications to ceilometer and other stuff).• OVN DHCP agent (TODO)
Openstack Neutron with OVN - Overview
Neutron DB
Neutron Server ovsdb-server
rabbitmq
ovn-northd
ovn-controller
neutron-*aas
OVN – ArchitectureOpenstack CMS (Neutron-Server)
OVN North bound DB
OVN – Northd(daemon)
OVN South bound DB
ovn-controller
ovsdb-server ovs-vswitchd
ovn-controller
ovsdb-server ovs-vswitchd
openflowOVSDBOVSDBopenflow
OVSDB
OVSDB
OVSDB
OVSDBOVSDB
Hypervisor 1 Hypervisor N
ovn-northdTranslate between the logical network elements configured by the CMS to the Northbound DB and model them to the Southbound DB tables, which holds the physical/infrastructure bindings and the logical flows which enable the logical connectivity.
Service PluginsL3 Service Plugin OVN
ML2 Mechanism DriverOVN Mech. Driver
OVN – Databases – Northbound DB• Two clients
• CMS which translate its own notion of logical networking configuration into the OVN model (Openstack Neutron for example, it translate neutron networks/ports/security groups into logical switches/logical ports/ACL's).
• ovn-northd daemon, which translate this DB into the Southbound DB model.
• Describes the logical network in conventional network concepts with only virtual elements and the connectivity between them.
• Like., logical switches, logical ports that connect to these switches and logical routers which connects between different logical switches.
• Also ACL's which we can attach to logical switches and configure them for specific logical ports.
• Communication between the ovn-northd and the CMS is bidirectional.
• ovn-northd can update the CMS when a port operational status is up, indicating all needed hooks and configuration took place (This is useful in the Neutron case as Neutron needs to indicate to Nova when a port is ready after deploying a VM).
CMS – Cloud Management System (here, Openstack)
OVN North bound DB
OVN – Databases – Southbound DB• Data Classification
• Physical Network: Information about the chassis nodes in the system. This contains all the information necessary to wire the overlay, such as IP addresses, supported tunnel types, and security keys.
• Logical Network: the topology of logical switches and routers, ACLs, firewall rules, and everything needed to describe how packets traverse a logical network, represented as logical datapath flows.
• Bindings: The current placement of logical components (such as VMs and vifs) onto chassis and the bindings between logical ports and MACs.
• The ovn-northd daemon populate the logical datapath flows, while the ovn-controller (OVN agent in the hypervisor) populate the physical elements and the bindings.
• ovn-controller uses the DB information and connects to the local OpenVSwitch as an Openflow controller to actually configure the needed flows for correct connectivity and also as an OVSDB manager to read the local configurations.
OVN South bound DB
OVN – Database schema ovn_nb :: OVN Northbound database schema
name (str)ports (set of logical_ports)acls (set of acls)
logical_switch
name (str)type (str)options (str-str)parent_name (str)tag (int 1-4095)up (bool – port state)enabled (bool – port state)addresses (str)port_security (str)
logical_port
priority (int 1-32767)direction (str to-lport or from-lport)match (str)action (str – allow-rejected, drop, allow, reject)log (bool)
acl
name (str)ports (str set of logical_router_ports)default_gw (str)
logical_router
name (str)network (str)mac (str)enabled (bool)peer (attachment of LRP)
logical_router_port
Each of the tables in this database contains a special column, named external_ids. This column has the same form and purpose each place it appears.
OVN – Database schema ovn-sb :: OVN Southbound database schema
name (str)encaps (set of 1 or more encaps)vtep_logical_switches (set of str)
chassis
Logical_datapath (datapath_binding)pipeline (str, ingress-egress)table_id (int 0-15)priority (int 0-65,535)match (str)actions (str)stage_name (str)
logical_flow
tunnel_key (int 1-16,777,215)logical_switch (nb-relation)logical_router (nb-relation)
datapath_binding
type (str, one of stt, geneve or vxlan)options (str-str)ip (str, ipv4 addr of encap tep)
encap
datapath (datapath_binding)tunnel_key (int, 32768-65535)name (str)ports (set of 1 or more weak reference to Port_Bindings)
multicast_group
Each of the tables in this database contains a special column, named external_ids. This column has the same form and purpose each place it appears.
datapath (datapath_binding)logical_port (str)chassis (str chassis)tunnel_key (int, 1-32768)mac (str)type (str)
port_binding
OVN – Utilities• ovn-nb - OVN_Northbound database schema
• This database is the interface between OVN and the cloud management system (CMS), such as OpenStack, running above it. The CMS produces almost all of the contents of the database. The ovn-northd program
monitors the database contents, transforms it, and stores it into the OVN_Southbound database.• ovn-sb - OVN_Southbound database schema
• This database holds logical and physical configuration and state for the Open Virtual Network (OVN) system to support virtual network abstraction.
• ovn-nbctl - Open Virtual Network northbound db management utility• This utility can be used to manage the OVN northbound database.
• ovn-sbctl - utility for querying and configuring OVN_Southbound database.• ovn-northd - Open Virtual Network central control daemon
• Responsible for translating the high-level OVN configuration into logical configuration consumable by daemons such as ovn-controller. It translates the logical network configuration in terms of conventional network concepts, taken from the OVN Northbound Database, into logical datapath flows in the OVN Southbound Database below it.
• ovn-controller - Open Virtual Network local controller• ovn-controller-vtep - Open Virtual Network local controller for vtep enabled physical switches.
OVN – Security Groups• Existing way• Requires extra linux bridge and
vEth pair per VM.• Uses Iptables.
• Using OVN ACLs• Uses kernel conntrack module
directly from OVS.• Design benefits.
• No complicated pipeline.• Faster* -- Fewer hops and veth ports.VM VM
Linux Bridge
Linux Bridge
OVS (br-int)
eth eth
tap tap
veth
veth veth
veth
VM VM
OVS (br-int)
eth eth
tap tap
OVN – L3 design• Neutron L3 Agent – Current design
• Agent based.• Used the Linux IP stack and iptables.
• Forwarding.• NAT.
• Overlapping IP address support using namespaces
• OVN L3 design• Native support for IPv4 and IPv6.• Distributed.• ARP/ND suppression.• Flow caching improves performance.
• Without OVN: multiple per-packet routing layers.• With OVN: cache sets dest mac, decrements TTL.
• No use of Neutron L3 agent
OVN L2 – Deep dive • Multi node Openstack Setup with OVN plugin.• 3 VM’s
• one in the controller node (VM1) and • two in the other compute node (VM2 and VM3)
• All connected to the “private” network.
Network Topology
OVN recognizes, two nodes on Chassis with Geneve tunnel Between them, it's important to note that the tunnel was created only when VM’s from the same logical network wereactually deployed in the two nodes.
Tunnel port created on br-int.
Router namespace creation remains unaffected.
The OVN Southbound DB Binding table has entries that link between the logical elements configured in the NorthboundDB and their location in the physical infrastructure.
OVN L2 – Deep dive Flow tables at each Node:
Table 0 - Network classification and incoming tunnel traffic dispatching.Table 16 - Ingress Port Security (This table blocks broadcast/multicast src addresses and also logical VLANs as they are not yet supported)Table 17 - Destination lookup, broadcast, multicast and unicast handling (and unknown MACs)Table 18 – ACL (not implemented)Table 19 - Egress Port SecurityTable 64 - Output table (Logical to Physical or Local - last step in the pipeline which now need to send the packet to the correct port (local or over a tunnel to other compute node))
OVN – an example – On HV1
Name PortsLS1 LP1, LP2
Name MACLP1 AA11
LP2 BB22
Chassis Name Encap IP address
HV1 Geneve* 10.0.0.10
HV2 Geneve* 10.0.0.11
Datapath Match Action
LS1 eth.dst = AA11 LP1
LS1 eth.dst = BB22 LP2
LS1 eth.dst = <broadcast> LP1, LP2
Logical switch
Logical port
Chassis (ovn-controller)
Bindings (ovn-controller)
Pipeline (ovn-northd)
Logical Port Name Chassis NameLP1 HV1
*Geneve: Generic Network Virtualization Encapsulation
OVN – an example – LP2 arrives on HV2Name PortsLS1 LP1, LP2
Name MACLP1 AA11
LP2 BB22
Chassis Name Encap IP address
HV1 Geneve 10.0.0.10
HV2 Geneve 10.0.0.11
Datapath Match Action
LS1 eth.dst = AA11 LP1
LS1 eth.dst = BB22 LP2
LS1 eth.dst = <broadcast> LP1, LP2
Logical switch
Logical port
Chassis (ovn-controller)
Bindings (ovn-controller)
Pipeline (ovn-northd)
` Chassis NameLP1 HV1
LP2 HV2
OVN - Limitations• HA/Redundancy
• ovsdb-server is not distributed, which means you cannot have a cluster or redundancy/high availability to your instance which has a critical job in the process.
• Scale• since ovsdb-server is not distributed it also does not support load sharing, this means that all
controllers connect to the same instance and hence can introduce bottlenecks on busy setups, this doesn't scale up well.
• Different environments might have different requirements• Different users might need different solutions for DB distribution in regards to latency / configuration
changes / resource availability to run the control plane software / SLA regarding configuration loses and so on, this approach means that ovsdb-implementation must support all possible use cases.
• Locked-In Solution• User/Cloud admin is locked to a single solution implementation which is not necessary related to
network virtualization
References & more reading• http://docs.openstack.org/developer/networking-ovn/readme.html• http://galsagie.github.io/tags/#OVN• http://benpfaff.org/~blp/dist-docs/ovn-architecture.7.html• https://wiki.opnfv.org/_media/ovn-opnfv-summit2015.pdf• http://openvswitch.org/support/slides/OVN_Tokyo.pdf• http://openvswitch.org/pipermail/discuss/2015-November/019317.ht
ml• http://lists.opnfv.org/pipermail/opnfv-tech-discuss/2015-November/
006641.html