Open daylight and Openstack

OPENSTACK SUMMIT VANCOUVER | DAVE NEARY1
OpenDaylight and OpenStack:
A match made in heaven
Dave Neary
SDN/NFV Community Strategy
Red Hat
dneary@redhat.com
@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
GRE
TypeDriver
Arista
VLAN
TypeDriver
VXLAN
TypeDriver
CiscoNexus
Hyper-V
L2Population
Linuxbridge
OpenvSwitch
Tail-FNCS
Credit: Bob Kukura
http://bit.ly/1L4Am3k

Neutron architecture
neutron-server
Database
Message
queue
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-Stedman
https://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-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-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 show
Bridge 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-tun
NXST_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
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
n_bytes=10443, idle_age=31, priority=4,in_port=1,dl_vlan=1
actions=set_tunnel:0x2,NORMAL
n_bytes=596, idle_age=423, priority=1 actions=drop

Tag traffic on GRE tunnel 2 for instance with
VLAN tag 1
tun_id=0x2,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00

Tag traffic from port 1 with VLAN tag 1 with GRE
tunnel 2
tun_id=0x2,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00

Control-node br-int
● GRE to VLAN conversion in br-tun
● br-int bridges to Neutron agents

Control-node br-int
# ovs-vsctl show
Bridge 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 netns
qdhcp-88b1609c-68e0-49ca-a658-f1edff54a264
qrouter-2d214fde-293c-4d64-8062-797f80ae2d8f

Digging into the namespaces
# ip netns exec qdhcp-88b1609c-68e0-49ca-a658-f1edff54a264 ip addr
71: 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 addr
66: qg-d48b49e0-aa: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
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
68: qr-c2d7dd02-56: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
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
# ovs-vsctl show
Bridge 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 show
39745b5b-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-int
OFPST_FLOW reply (OF1.3) (xid=0x2):
n_bytes=0, priority=0 actions=goto_table:20
n_bytes=0, dl_type=0x88cc actions=CONTROLLER:65535
n_bytes=0, priority=0 actions=goto_table:30
<snip>
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 show
a31569c6-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"
Credit: Flavio Fernandes

vSwitch with some instances
# ovs-vsctl show
a31569c6-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"

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>

Flows with some instances
# ovs-ofctl -O OpenFlow13 dump-flows br-int (extract 1)
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
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
n_bytes=13146, tun_id=0x3ea,dl_dst=fa:16:3e:94:75:95
actions=output:3
Port <-> IP address <-> MAC address

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
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

n_bytes=196, tun_id=0x3ea,dl_dst=fa:16:3e:41:56:ec
actions=output:1
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 Neary
dneary@redhat.com
@nearyd

Open daylight and Openstack

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Open daylight and Openstack (20)

More from Dave Neary (20)

Recently uploaded (20)

Open daylight and Openstack