Open daylight and Openstack

OPENSTACK SUMMIT VANCOUVER | DAVE NEARY1

OpenDaylight and OpenStack:

A match made in heaven

Dave NearySDN/NFV Community StrategyRed Hat

[email protected]@nearyd


What is OpenDaylight?

● An SDN Controller

● Platform for network engineering

● Network virtualization – disaggregation of physical and virtual network topology

http://www.opendaylight.org


What is an SDN controller?

● Manages edge devices (switches, routers)

● Define network policy, topology centrally

● Push rules for implementation to the edge

● Manage multiple interfaces Southbound (OpenFlow, OVSDB, NETCONF, vendor plug-ins)


Sample SDN applications

● WAN optimization

● Traffic engineering for Network QoS

● Network virtualization

● Software based network applications – IDM, DDoS protection, VPN


OpenDaylight projects


OpenDaylight as OpenStack network overlay


Core OpenDaylight use-cases

● OpenDaylight board focus:● OpenStack network virtualization● Service Function Chaining/NFV

● Work ongoing to document and improve OpenStack integration

● Focus on NFV use-cases: SFC, network policy


OpenDaylight and OpenStack


A brief overview of OpenStack networking(with Open vSwitch ML2 plug-in)


ML2 Architecture Diagram

Neutron Server

ML2 Plugin

Type Manager Mechanism Manager

API Extensions

GR

E

TypeDrive r

Arista

VLA

N

TypeDrive r

VX

LAN

TypeD

rive r

Cisco N

ex us

Hyper-V

L2 Popula tion

Linuxbridg e

Open vS

witch

Tail-F N

CS

Credit: Bob Kukurahttp://bit.ly/1L4Am3k


Neutron architecture

neutron-server

Database

Messagequeue

L2 AgentL2 AgentL2 AgentL2 AgentL2 Agent

L3 AgentL3 AgentL3 Agent

DHCP agentDHCP agentDHCP agent

Credit: Mark McLain


How OpenStack traffic flows (with OVS)

Credit: Lars Kellogg-Stedmanhttps://www.rdoproject.org/Networking_in_too_much_detail


Instance to qbr...

● Virtual NIC eth0 mapped to tap device in host (eg. tap7c7ae61e-05)

● tap device attached to Linux Bridge qbr7c7ae61e (1 bridge per instance)

● Security rules applied here


Security rules

$ iptables -S | grep tap7c7ae61e-05-A quantum-openvswi-FORWARD -m physdev \ --physdev-out tap7c7ae61e-05 \ --physdev-is-bridged -j quantum-openvswi-sg-chain -A quantum-openvswi-FORWARD -m physdev \ --physdev-in tap7c7ae61e-05 \ --physdev-is-bridged -j quantum-openvswi-sg-chain -A quantum-openvswi-INPUT -m physdev \ --physdev-in tap7c7ae61e-05 \ --physdev-is-bridged -j quantum-openvswi-o7c7ae61e-0 -A quantum-openvswi-sg-chain -m physdev \ --physdev-out tap7c7ae61e-05 \ --physdev-is-bridged -j quantum-openvswi-i7c7ae61e-0 -A quantum-openvswi-sg-chain -m physdev \ --physdev-in tap7c7ae61e-05 \ --physdev-is-bridged -j quantum-openvswi-o7c7ae61e-0


qbr... to br-int

● Interface qvb... attaches to qbr... at C

● Interface qvo... attaches to br-int at D

● VLAN tagging applied at br-int


OVS config

$ ovs-vsctl showBridge br-int Port "qvo7c7ae61e-05" tag: 1 Interface "qvo7c7ae61e-05" Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port br-int Interface br-int type: internal


br-tun (Compute node)

● patch-tun (E) connects to patch-int (F), connected to br-tun

● Traffic is sent to the physical NIC (G), with encapsulation (VXLAN, GRE)


br-tun (Control node)

● Traffic on host (H) is converted from GRE to VLAN

● Traffic sent with appropriate VLAN tag on to br-int (I)


Send multicast traffic from GRE tunnel 2 to VLAN 1, port 1

# ovs-ofctl dump-flows br-tunNXST_FLOW reply (xid=0x4): cookie=0x0, duration=422.158s, table=0, n_packets=2, \ n_bytes=120, idle_age=55, priority=3,\ tun_id=0x2,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 \ actions=mod_vlan_vid:1,output:1 cookie=0x0, duration=421.948s, table=0, n_packets=64, \ n_bytes=8337, idle_age=31, \ priority=3,tun_id=0x2,dl_dst=fa:16:3e:dd:c1:62 \ actions=mod_vlan_vid:1,NORMAL cookie=0x0, duration=422.357s, table=0, n_packets=82, \ n_bytes=10443, idle_age=31, priority=4,in_port=1,dl_vlan=1 \ actions=set_tunnel:0x2,NORMAL cookie=0x0, duration=1502.657s, table=0, n_packets=8, n_bytes=596, idle_age=423, priority=1 actions=drop


Tag traffic on GRE tunnel 2 for instance with VLAN tag 1



Tag traffic from port 1 with VLAN tag 1 with GRE tunnel 2



Control-node br-int

● GRE to VLAN conversion in br-tun

● br-int bridges to Neutron agents


Control-node br-int

# ovs-vsctl showBridge br-int Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port "tapf14c598d-98" tag: 1 Interface "tapf14c598d-98" Port br-int Interface br-int type: internal Port "tapc2d7dd02-56" tag: 1 Interface "tapc2d7dd02-56"


Network namespaces

● Each network with DHCP has its own network namespace

● Each router has its own namespace too

# ip netnsqdhcp-88b1609c-68e0-49ca-a658-f1edff54a264qrouter-2d214fde-293c-4d64-8062-797f80ae2d8f


Digging into the namespaces

# ip netns exec qdhcp-88b1609c-68e0-49ca-a658-f1edff54a264 ip addr71: ns-f14c598d-98: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether fa:16:3e:10:2f:03 brd ff:ff:ff:ff:ff:ff inet 10.1.0.3/24 brd 10.1.0.255 scope global ns-f14c598d-98 inet6 fe80::f816:3eff:fe10:2f03/64 scope link valid_lft forever preferred_lft forever

● Interface corresponds to port “tapf14c598d-98” and interface tapf14c598d-98 on br-int

● dnsmasq process listens on this interface, with namespace from before


Routing to the internet

● qrouter namespace contains interfaces K, N

● qg... interface corresponds to gateway set on router (neutron-set-gateway)

● Routing tables for router defined with iptables in qrouter namespace

● NAT to host address happens on br-ex


Router connections# ip netns exec qrouter-2d214fde-293c-4d64-8062-797f80ae2d8f ip addr66: qg-d48b49e0-aa: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether fa:16:3e:5c:a2:ac brd ff:ff:ff:ff:ff:ff inet 172.24.4.227/28 brd 172.24.4.239 scope global qg-d48b49e0-aa inet 172.24.4.228/32 brd 172.24.4.228 scope global qg-d48b49e0-aa inet6 fe80::f816:3eff:fe5c:a2ac/64 scope link valid_lft forever preferred_lft forever68: qr-c2d7dd02-56: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether fa:16:3e:ea:64:6e brd ff:ff:ff:ff:ff:ff inet 10.1.0.1/24 brd 10.1.0.255 scope global qr-c2d7dd02-56 inet6 fe80::f816:3eff:feea:646e/64 scope link valid_lft forever preferred_lft forever

# ovs-vsctl showBridge br-int<snip> Port "tapc2d7dd02-56" tag: 1 Interface "tapc2d7dd02-56"


OpenStack with OpenDaylight


OpenDaylight

Neutron Service

OpenStack Neutron

OVSDB Provider

Neutron ML2 MechanismDriver

OpenDaylight APIs (REST)

Neutron and OpenDaylight

● OpenDaylight exposes a single common OpenStack Service Northbound

● API exposed matches Neutron API precisely

● Multiple back-ends in OpenDaylight

● OpenDaylight OpenStack Neutron Plugin simply passes through

● Simplifies OpenStack plugin

● Pushes complexity to OpenDaylight

Compute A

OVSDB-server

ovs-bridge

Compute B

OVSDB-server

ovs-bridge

OpenFlow


Configuring OpenDaylight with OpenStack

https://wiki.opendaylight.org/view/OpenStack_and_OpenDaylight

1. Install OpenStack, clean Neutron config

2. Install OpenDaylight

3. Clean OVSDB configuration on all hosts

4. Set ODL as manager for Open vSwitch for each host

5. Set ODL as ML2 provider for OpenStack


Step 1: Neutron config

● No migration path to ODL, unfortunately

● Delete subnets, networks, routers, ports

● Stop Neutron service


Step 2: Installing OpenDaylight (Helium)

● Required features:● odl-base-all – Basic services● odl-aaa-authn – Authentication and authorization● odl-restconf – Northbound RESTful API framework● odl-nsf-all● odl-adsal-northbound● odl-mdsal-apidocs● odl-ovsdb-openstack● odl-ovsdb-northbound● odl-dlux-core


After step 2: dlux


Step 3, 4: Clean out OVSDB, connect switches

● For each host:● Stop and disable neutron-openvswitch-agent● Stop Open vSwitch service, delete local database● Restart Open vSwitch service● ovs-vsctl set-manager tcp:172.16.21.56:6640

● setenforce 0 may be necessary


After step 4: ovs-vsctl

# ovs-vsctl show39745b5b-2ff9-416b-ab3e-f1b81fd29fd7 Manager "tcp:192.168.50.20:6640" is_connected: true Bridge br-int Controller "tcp:192.168.50.20:6633" is_connected: true fail_mode: secure Port br-int Interface br-int type: internal ovs_version: "2.3.0"


After step 4: ovs-ofctl

# ovs-ofctl -O OpenFlow13 dump-flows br-intOFPST_FLOW reply (OF1.3) (xid=0x2): cookie=0x0, duration=8558.311s, table=0, n_packets=0, n_bytes=0, priority=0 actions=goto_table:20 cookie=0x0, duration=8559.262s, table=0, n_packets=0, n_bytes=0, dl_type=0x88cc actions=CONTROLLER:65535 cookie=0x0, duration=8557.816s, table=20, n_packets=0, n_bytes=0, priority=0 actions=goto_table:30<snip> cookie=0x0, duration=8553.238s, table=110, n_packets=0, n_bytes=0, priority=0 actions=drop


Step 5: Configure Neutron

● In /etc/neutron/plugins/ml2/ml2_conf.ini:● mechanism_drivers = opendaylight● tenant_network_types = vxlan● Add ml2_odl section with url =

http://odl_control:8080/controller/nb/v2/neutron

● Reset Neutron's ML2 database

● Restart Neutron server


How OpenStack traffic flows (with OpenDaylight)

test0 test1

br-int br-int

dhcp-agentl3-agentbr-ex


vSwitch with some instances

# ovs-vsctl showa31569c6-314f-41dd-972d-a75806b4ee3f Manager "tcp:192.168.50.20:6640" is_connected: true Bridge br-int Controller "tcp:192.168.50.20:6633" is_connected: true fail_mode: secure Port "vxlan-192.168.50.20" Interface "vxlan-192.168.50.20" type: vxlan options: {key=flow, local_ip="192.168.50.21", remote_ip="192.168.50.20"} Port "tapb58febde-6f" Interface "tapb58febde-6f" Port br-int Interface br-int Port "tap2a008646-41" Interface "tap2a008646-41" ovs_version: "2.3.0" Credit: Flavio Fernandes


vSwitch with some instances

# ovs-vsctl showa31569c6-314f-41dd-972d-a75806b4ee3f Manager "tcp:192.168.50.20:6640" is_connected: true Bridge br-int Controller "tcp:192.168.50.20:6633" is_connected: true fail_mode: secure Port "vxlan-192.168.50.20" Interface "vxlan-192.168.50.20" type: vxlan options: {key=flow, local_ip="192.168.50.21", remote_ip="192.168.50.20"} Port "tapb58febde-6f" Interface "tapb58febde-6f" Port br-int Interface br-int Port "tap2a008646-41" Interface "tap2a008646-41" ovs_version: "2.3.0" Credit: Flavio Fernandes


Interfaces with some instances

#ovs-vsctl list Interface | \grep -E '^name|^ofport |^mac_in_use|^external_id'external_ids : {attached-mac="fa:16:3e:94:75:95", iface-id="2a008646-4110-4095-ae68-0d3c70c913fb", iface-status=active, vm-id="0b6d8e31-fa26-4315-ac44-7c87efc44aa7"}mac_in_use : "fe:16:3e:94:75:95"name : "tap2a008646-41"ofport : 3

<snip>

Credit: Flavio Fernandes


Flows with some instances


# ovs-ofctl -O OpenFlow13 dump-flows br-int (extract 1)

cookie=0x0, duration=9652.448s, table=0, n_packets=110, n_bytes=12962, in_port=3,dl_src=fa:16:3e:94:75:95 actions=set_field:0x3ea->tun_id,load:0x1->NXM_NX_REG0[], goto_table:20

cookie=0x0, duration=9679.385s, table=70, n_packets=137, n_bytes=13146, priority=1024,ip,tun_id=0x3ea,nw_dst=2.0.0.3 actions=set_field:fa:16:3e:94:75:95->eth_dst,goto_table:80

cookie=0x0, duration=9651.435s, table=110, n_packets=137, n_bytes=13146, tun_id=0x3ea,dl_dst=fa:16:3e:94:75:95 actions=output:3

Port <-> IP address <-> MAC address





cookie=0x0, duration=9673.749s, table=110, n_packets=2, n_bytes=658, priority=16384,reg0=0x1,tun_id=0x3e9, dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=output:2,output:1

cookie=0x0, duration=9674.253s, table=110, n_packets=2, n_bytes=658, priority=16384,reg0=0x2,tun_id=0x3e9, dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=output:2

Broadcast rules





cookie=0x0, duration=9658.033s, table=110, n_packets=2, n_bytes=196, tun_id=0x3ea,dl_dst=fa:16:3e:41:56:ec actions=output:1

cookie=0x0, duration=9718.289s, table=110, n_packets=13, n_bytes=1196, tun_id=0x3ea,dl_dst=fa:16:3e:a8:c2:66 actions=output:1

ARP within VXLAN


Distributed ARP


Coming in Lithium

● Migration of OVSDB south-bound plug-in from AD-SAL to MD-SAL

● Neutron feature parity incl. LBaaS

● Native DVR (North-South and East-West)

● Neutron northbound interface split out from OpenDaylight controller


Thank you!Questions?

Dave [email protected]@nearyd

Technology

Open daylight and Openstack