Understanding OpenDaylight VTN and the Redirection Function Shreyansh Jain NEC Technologies India Pvt. Ltd. shreyansh.jain@{nectechnologies.in, gmail.com}
Next 45 Minutes … • A brief introduction to OpenDaylight VTN • OpenDaylight Platform: VTN Project Overview • Understanding VTN: Definition, Virtual Nodes and Network Creation • Physical Virtual Mapping of VTN • Creating Network Topology and Packet Handling • Using VTN Manager REST APIs • Using VTN Flow-Filters and Redirection • Using Redirection for creating arbitrary flows • Flow Matching in a VTN • Various Use Cases • Appendix 2
Understanding OpenDaylight VTN Project 3
OpenDaylight Platform: VTN Project Overview • VTN Project constitutes of VTN Coordinator and VTN Manager plugins VTN Coordinator is responsible for interfacing between multiple controller environment, and providing RESTful APIs for Northbound Applications VTN Manager is available as AD- SAL bundle for OpenDaylight Controller. Responsible for: - OpenFlow PACKET_IN and PACKET_OUT handling - Providing RESTful API for basic VTN Semantics - Setting Flow Entries on OpenFlow Switches (FLOW_MOD) 4 Image from: http://www.opendaylight.org/project/technical-overview
OpenDaylight Platform: VTN Project Overview • Deploying VTN across multiple Controller (DC) environment Northbound Applications RESTful APIs Coordination Coordination RESTful APIs <<Java API>> <<Java API>> 5 Image from: http://www.opendaylight.org/project/technical-overview
Understanding VTN: Definition • VTN or Virtual Tenant Network • Abstracting the physical network to create multiple Logical Networks layered over same physical plane • User would define a L2/L3 network without worrying about the physical topology • VTN Manager Plugin detects the topology, maps the logical representations and installs necessary flows on network elements (OpenFlow Switches – OFS) V vRouter V Virtual Network V V vBridge V Virtual Interface V OpenFlow Switch Physical Network VLAN300 VLAN100 VLAN100 VLAN200 VLAN100 VLAN200 6
Understanding VTN Topology: Virtual Nodes • Various nodes used for defining a network • vBridge • Works like a Layer 2 Switching element, with support for MAC learning • Unknown MAC destination are flooded to all interfaces (except incoming interface) • Pair of source MAC and incoming interfaces are learned and aged out • Also used for specifying a mapping with the physical layer (VLAN Mapping) • vRouter (Implemented by VTN Coordinator APIs) • Works like a Layer 3 Routing element (Without advanced features like OSPF, BGP) • Table of discovered hosts is maintained based on ARP requests and responses • Forwarded packet modification is performed based on dynamic or static routes • Virtual Interfaces • Represents a port on a vBridge or vRouter (L2 or L3) virtual device • Also used for specifying a mapping with the physical layer (Port Mapping) • This mapping is used by VTN to define flow actions to be performed for an incoming frame • vLink • A logical representation of connections between various network elements • A VTN is like a single large switch encompassing all OpenFlow enabled ports on the underlying physical network Some other semantics also exist; vTerminal, vTep, vTunnel, vBypass – designed for defining networks linking multiple controlled domains (network stretching across multiple DCs) 7
Understanding VTN Topology: Network Creation • Creating a network by connecting together the virtual nodes: • A VTN can have many L2 devices (vBridge) and one L3 device (vRouter) • Multiple vBridge can exists in a VTN, with or without inter-connections • Two vBridge cannot connect to each other directly. For interlinking, a vRouter is used • Virtual Interfaces are used for: • Connecting vBridge and vRouter • Until vLink between two nodes is created, they remain disconnected on physical plane • Mapping with Physical network • Flow-filters (traffic segregation) and functions like Redirection are applied on these Creating a Physical Defining VTN Linking together the Topology; One in which one Semantics for one Virtual and Physical or more edge-to-edge path or more Virtual network using exist Networks mapping functions Physical network having Mapping, represented by flow multiple paths would allow Define multiple VTNs for all entries, provides entry/exit VTN to reroute traffic in case of unrelated logical networks point for traffic on virtual link failures network 8
Physical Virtual Mapping for a VTN • Eventually, a VTN needs to be linked to the physical network • This work is done by specifying a map with physical layer • Each incoming packet is mapped to one of the defined VTNs, or dropped in case of no match • Mapping defines relation between Virtual and Physical network elements • Port Mapping • Linking a physical port (or vif of an OVS) of a particular OpenFlow Switch (OFS) to a vBridge • Can map a tagged (of a specified VLAN) or an untagged packet arriving on that port • Configured on a virtual interface associated with a vBridge • VLAN Mapping • Mapping the particular VLAN slice over all OFS on the physical plane • OR, reducing the scope by specifying a VLAN over a particular OFS • MAC Mapping • Supported from Helium onwards [1] ; Creating a White-list of allowed MAC address for untagged frames, for a particular vBridge • <Not much information available in Wiki, though source code seems to have this implemented “ manager/../MacMap.java and MacMapConfig.java” > 9 [1] From: https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_%28VTN%29:Helium_Release_Notes
Dynamic Network Topology creation • VTN Manager forms a physical view of all connected OFSs using LLDP • LLDP Packets are pushed out of OFSs port and their reception is noted for forming a physical plane graph • Once created, the graph is actively updated for learning new or failed paths • Flows are created based on this acquired topology Image from Slide 23 of ODL-MiniSummit-Virt-Final_20150224.pdf from 10 https://wiki.opendaylight.org/images/3/30/ODL-MiniSummit-Virt-Final.pdf extracted on 24/Feb/2015
Handling a new Packet • Incoming packets are mapped to appropriate VTN based on mapping • Once mapped to a VTN, L2 functions of flooding across virtual interfaces is performed if ARP hasn’t yet been learned • Once ARP is learned, flow entries are pushed on the edge ports; Core flows are created or updated based on the topology detected • ARP table is passively updated based on flow entry timeout or new ARP broadcasts Image from Slide 24 of ODL-MiniSummit-Virt-Final_20150224.pdf from 11 https://wiki.opendaylight.org/images/3/30/ODL-MiniSummit-Virt-Final.pdf extracted on 24/Feb/2015
Using VTN Manager REST APIs • Creating a VTN named BLUE • RESTful and Java APIs have been exposed by the bundles [2][3] • For both, VTN Manager and VTN Coordinator, JSON and XML are supported data format • Creating VTN Configuration(s) using VTN Manager RESTful APIs Name of the new VTN POST /controller/nb/v2/vtn/default/vtns/ BLUE • JSON: {"description": “BLUE Colored Virtual Network", "idleTimeout": "0","hardTimeout": "0"} Creating a VTN Virtual Network [2] VTN Manager REST APIs: https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):VTN_Manager:RestApi 12 [3] VTN Manager Java APIs: https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):VTN_Manager:JavaApi
Using VTN Manager REST APIs • Creating another VTN named GREEN • Multiple VTNs can be created, each being functionally isolated from the other Name of the new VTN POST /controller/nb/v2/vtn/default/vtns/ GREEN • JSON: {"description": “GREEN Colored Virtual Network”, "idleTimeout ": "0","hardTimeout": "0"} Creating another VTN Virtual Networks 13
Using VTN Manager REST APIs • Adding a vBridge Br100 to the VTN BLUE • Multiple vBridge per VTN can be created, each representing a single broadcast domain POST /controller/nb/v2/vtn/default/vtns/ BLUE /vbridges/ Br100 • JSON : {"description": “vBridge for VLAN 100", " ageInterval": "600"} A vBridge on a VTN Name of the new vBridge for VLAN 100 Virtual Networks V Br100 14
Using VTN Manager REST APIs • Adding Interfaces to the vBridge Br100 on BLUE • Multiple virtual interfaces per vBridge can be created; Each is equivalent to a port on a L2 switch POST /controller/nb/v2/vtn/default/vtns/BLUE/vbridges/Br100/interfaces/ IF1 • JSON: {"description": “A Yellow Dot on Br100"," enabled": true } An Interface on vBridge Br100 Virtual Networks V IF1 Br100 15
Using VTN Manager REST APIs • Adding another Interfaces to the vBridge Br100 on BLUE • Multiple virtual interfaces per vBridge can be created; Each is equivalent to a port on a L2 switch POST /controller/nb/v2/vtn/default/vtns/BLUE/vbridges/Br100/interfaces/ IF2 • JSON: {"description": “Another Yellow Dot on Br100"," enabled": true} Another Interface on vBridge Br100 Virtual Networks V IF1 IF2 Br100 16
Recommend
More recommend
