opendaylight netvirt for openstack - files.meetup.com northbound openstack service provider db...
TRANSCRIPT
Links● OVSDB NetVirt Project
https://wiki.opendaylight.org/view/OVSDB_Integration:Main
● Demohttps://wiki.opendaylight.org/view/OVSDB_Integration:Main#Getting_Started_with_OpenDaylight_OVSDB_Plugin_Network_Virtualization
3
OpenDaylight (ODL)● Solve challenges with default
OpenStack Neutron OVS Plugin○ Ease of Use○ Scale○ Resiliency
● True SDN “platform”○ Support future Innovation○ Application support○ Multi-vendor networks
Layer 2Gateway
5
ML2 PluginODL mech driver
Neutron
OOpenDaylightNeutron Northbound
openstack service provider
DB
MD-SAL
Openflow OVSDB
Compute node
OVS VM
Openstack and OpenDaylight● OpenStack Neutron
○ Plugin: Modular Layer 2 Plugin
● networking-odl○ ODL L3 plugin○ Drivers for LBaaS,FWaaS,
VPNaaS…
● OpenDaylight○ Neutron northbound○ OpenStack service providers
■ ovsdb/netvirt, groupbasedpolicy, VTN, lispflowmapper, NIC
○ Southbound protocol■ openflow■ ovsdb
ODL L3/LBaaS/…Plugins/Drivers
6
Control node
Neutron
Control node
OpenDaylight
Computenode
VM
OVSComputenode
VM
OVSNetworknode OVS
DB
Data network
router
internet
Public network
dhcpagent
Mgmt network OpenFlowOVSDB
REST
Network View
7
Control node
Neutron
Control node
Neutron
Control node
OpenDaylight
Control node
OpenDaylightControl node
Neutron
Control node
OpenDaylight
Computenode
VM
OVSComputenode
VM
OVSNetworknode OVS
DB
Data network
router
internet
Public network
dhcpagent
Mgmt network OpenFlowOVSDB
REST
Load
Bal
ance
r(H
AP
roxy
)
HA View
8
Red Hat OpenDaylight Focus● Neutron
○ Neutron REST API○ Neutron Service
● OVSDB NetVirt as a Neutron Service Provider
● SFC for Service Function Chaining● Southbound Protocols
○ OVSDB○ OpenFlow
● OVS Switches and HW Gateways 10
OVSDB NetVirt● The OVSDB NetVirt Project Includes
○ OVSDB Southbound Protocol○ NetVirt network virtualization
● Current implementation of NetVirt ○ Focused on supporting
■ OpenStack Neutron API (Northbound)■ Open vSwtich switches (Southbound)
● Future Plans○ Support NetVirt as a separate application○ Make NetVirt more
■ Scalable, ■ Modular and ■ Extensible
12
L2 Forwarding
NetVirt Logical Flow Pipeline
Classifiertenant network ingress/egress
Table: 0
Inbound NATfloating to internal ip rewrite
Table: 30
Egress ACL
Table: 40
Load Balancer
Table: 50
RoutingL3 gw rewritedec ttl
Table: 60
Table: 110
Outbound NAT
internal gw to external gw
Table: 100
L2 Rewrite
Table: 80
L3 Forwardingset internal dst mac
Table: 70
Ingress ACL
Table: 90
Table: 20
ARP Response
respond to ARP requests
High Level Control Flow: Create Network / Subnet / Port (1) OpenStack sends request for
Network/Subnet/Port creation (for VM) to Neutron Northbound(a) NN passes it to NetVirt provider
(2) Spawning VM will create port on compute node and (a) that will trigger notification from ovsdb(b) OVSDB library will notify SB Plugin(c) SB Plugin will update the MD-SAL
operational data store(3) MD-SAL data store will notify NetVirt provider
about new port creation(4) NetVirt will write data into MD-SAL config
data store for tunnel creation(5) SB Plugin gets notification from MD-SAL data
store about new tunnel data and it sends instructions to library for tunnel interface creation
(6) NetVirt also installs the required flows for VM traffic routing
Existing Key Features (as of Be Release)● Simplified architecture
○ Reducing agents, i.e. no l2-agent○ Autoconfiguration, i.e. create bridges
● Distributed L2: VLAN, NVGRE, VXLAN● Distributed L3: IPv4 Routing, Floating IPs, ARP Responder● High Availability (Clustering)● SFC Integration● DHCPv4 using Neutron DHCP agent● Metadata (cloud-init) support through DHCP namespace● Security-groups (dynamic requires OVS v2.5)● LBaaS● OVSDB HWVTEP Southbound
15
Roadmap (Boron)● Make NetVirt a separate project● Re-architecture: modularity, extensibility, scalability● Common NetVirt for OpenStack and VPN Service● More work on clustering, scalability and performance● NAPT (aka SNAT)● IPv6● Continued work on SFC● Complete L2 (VXLAN) Gateway in NetVirt
○ Based on OVSDB hardware_vtep database schema
● More support for other OpenStack services○ LBaaS, FWaaS, ...
16
• Demonstrate network virtualization using vxlan overlay, L3 and floating ip
• Three nodes in a single ova that can be consumed by vm players:• openstack control, compute, OpenDaylight, CentOS 7, devstack• openstack compute, CentOS 7, devstack• router for external access, CentOS 6.5
• Demohttps://wiki.opendaylight.org/view/OVSDB_Integration:Main#Getting_Started_with_OpenDaylight_OVSDB_Plugin_Network_Virtualization
Demo Description
18
odl32-computeodl31-control
Topology
br-int
br-ex
vmvx110.100.5.3
192.168.56.10
dhcp10.100.5.2
vxlan-192.168.254.32
tap883f9022-bd
tapd0d15959-1f
eth1
br-int
br-ex
eth2
vmvx210.100.5.4
192.168.56.11
vxlan-192.168.254.31
tap5d62515a-be
eth1
OpenDaylight
router-node
eth1
eth0
192.168.56.1
External: VB Internal: 192.168.56.0/24
eth3Data: VB Internal: 192.168.254.0/24
eth3
Management: VB Host-only: 192.168.50.0/24
eth2
patch-ext
patch-int
patch-ext
patch-int
192.168.254.31 192.168.254.32
192.168.50.31 192.168.50.32
19
Neutron Commands (1 of 2)source openrc admin admin
os_addnano.sh:nova flavor-create m1.nano auto 64 0 1
os_addadminkey.sh:nova keypair-add --pub-key ~/.ssh/id_rsa.pub admin_key
os_addextnetrtr.sh:neutron net-create ext-net --router:external --provider:physical_network public --provider:network_type flatneutron subnet-create --name ext-subnet --allocation-pool start=192.168.56.9,end=192.168.56.14 --disable-dhcp --gateway 192.168.56.1 ext-net 192.168.56.0/24
neutron net-create vx-net --provider:network_type vxlan --provider:segmentation_id 1500neutron subnet-create vx-net 10.100.5.0/24 --name vx-subnet --dns-nameserver 8.8.8.8
neutron router-create ext-rtrneutron router-gateway-set ext-rtr ext-netneutron router-interface-add ext-rtr vx-subnet
20
Neutron Commands (2 of 2)
os_addvms.sh:nova boot --poll --flavor m1.nano --image $(nova image-list | grep 'uec\s' | awk '{print $2}' | tail -1) --nic net-id=$(neutron net-list | grep -w vx-net | awk '{print $2}') vmvx1 --availability_zone=nova:odl31 --key_name admin_key
nova boot --poll --flavor m1.nano --image $(nova image-list | grep 'uec\s' | awk '{print $2}' | tail -1) --nic net-id=$(neutron net-list | grep -w vx-net | awk '{print $2}') vmvx2 --availability_zone=nova:odl32 --key_name admin_key
os_addfloatingips.sh:for vm in vmvx1 vmvx2; do vm_id=$(nova list | grep $vm | awk '{print $2}') port_id=$(neutron port-list -c id -c fixed_ips -- --device_id $vm_id | grep subnet_id | awk '{print $2}') neutron floatingip-create --port_id $port_id ext-netdone;
21
DevStack local.conf ODL_MODE for networking-odlhttps://github.com/flavio-fernandes/networking-odl/blob/heliumkilo/devstack/settings#L27
ODL_MODE=${ODL_MODE:-allinone}# ODL_MODE is used to configure how devstack works with OpenDaylight. You# can configure this three ways:# ODL_MODE=allinone# Use this mode if you want to run ODL in this devstack instance. Useful# for a single node deployment or on the control node of a multi-node# devstack environment.# ODL_MODE=compute# Use this for the compute nodes of a multi-node devstack install.# ODL_MODE=externalodl# This installs the neutron code for ODL, but does not attempt to# manage ODL in devstack. This is used for development environments# similar to the allinone case except where you are using bleeding edge ODL# which is not yet released, and thus don't want it managed by# devstack.# ODL_MODE=manual# You're on your own here, and are enabling services outside the scope of# the ODL_MODE variable.
22
odl31-control local.conf
disable_all_servicesenable_service g-api g-reg key n-api n-crt n-obj n-cpu n-cond n-sch n-novnc n-xvnc n-cauth horizon neutron q-dhcp q-meta q-svc mysql rabbitenable_service odl-server odl-compute…HOST_IP=192.168.254.31HOST_NAME=odl31…enable_plugin networking-odl https://github.com/flavio-fernandes/networking-odl summit15demoODL_MODE=manualNEUTRON_CREATE_INITIAL_NETWORKS=FalseODL_L3=TruePUBLIC_INTERFACE=eth2
23
odl32-compute local.conf
disable_all_servicesenable_service n-cpu n-novnc neutron rabbitenable_service odl-compute…HOST_IP=192.168.254.32HOST_NAME=odl32SERVICE_HOST_NAME=odl31SERVICE_HOST=192.168.254.31Q_HOST=$SERVICE_HOST…ODL_MODE=manualODL_L3=TruePUBLIC_INTERFACE=eth2
24
Demo Steps: Create Networks, L3 and Floating IPs
Individual steps:1. source openrc admin admin2. ../tools/os_addnano.sh: add a nano flavor of the vms3. ../tools/os_addadminkey.sh: add ssh keys to have password-less logins to
the tenant vms4. ../tools/os_addextnetrtr.sh: add external and vxlan networks and attach to
router5. ../tools/os_addvms.sh: launch two vms, one on each compute node6. ../tools/os_addfloatingips.sh: assign floating ip’s to each vm
Or just use ../tools/os_doitall.sh: But it’s more fun to do each step and see what happens...
25
Topology: After Stacking
odl31-control
br-ex
eth1
odl32-compute
br-ex
eth2
eth1
OpenDaylight
router-node
eth1
eth0
192.168.56.1
External: VB Internal: 192.168.56.0/24
eth3Data: VB Internal: 192.168.254.0/24
eth3
Management: VB Host-only: 192.168.50.0/24
eth2
192.168.254.31 192.168.254.32
192.168.50.31 192.168.50.32
br-int br-int
26
OVSDB: After Stackingsudo ovs-vsctl showd9904cbd-34c7-48e2-b714-fb5d04a4d899 Manager "tcp:192.168.254.31:6640" is_connected: true Bridge br-ex Controller "tcp:192.168.254.31:6653" is_connected: true fail_mode: secure Port br-ex Interface br-ex type: internal Port "eth2" Interface "eth2" Bridge br-int Controller "tcp:192.168.254.31:6653" is_connected: true fail_mode: secure Port br-int Interface br-int type: internal
27
Flows: After Stackingsudo ovs-ofctl --protocol=OpenFlow13 dump-flows br-ex cookie=0x0, duration=49.967s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL cookie=0x0, duration=49.967s, table=0, n_packets=4, n_bytes=452, dl_type=0x88cc actions=CONTROLLER:65535
sudo ovs-ofctl --protocol=OpenFlow13 dump-flows br-int cookie=0x0, duration=49.482s, table=0, n_packets=0, n_bytes=0, priority=0 actions=goto_table:20 cookie=0x0, duration=49.998s, table=0, n_packets=0, n_bytes=0, dl_type=0x88cc actions=CONTROLLER:65535 cookie=0x0, duration=49.472s, table=20, n_packets=0, n_bytes=0, priority=0 actions=goto_table:30 cookie=0x0, duration=49.466s, table=30, n_packets=0, n_bytes=0, priority=0 actions=goto_table:40 cookie=0x0, duration=49.456s, table=40, n_packets=0, n_bytes=0, priority=0 actions=goto_table:50 cookie=0x0, duration=49.446s, table=50, n_packets=0, n_bytes=0, priority=0 actions=goto_table:60 cookie=0x0, duration=49.435s, table=60, n_packets=0, n_bytes=0, priority=0 actions=goto_table:70 cookie=0x0, duration=49.424s, table=70, n_packets=0, n_bytes=0, priority=0 actions=goto_table:80 cookie=0x0, duration=49.407s, table=80, n_packets=0, n_bytes=0, priority=0 actions=goto_table:90 cookie=0x0, duration=49.403s, table=90, n_packets=0, n_bytes=0, priority=0 actions=goto_table:100 cookie=0x0, duration=49.391s, table=100, n_packets=0, n_bytes=0, priority=0 actions=goto_table:110 cookie=0x0, duration=49.366s, table=110, n_packets=0, n_bytes=0, priority=0 actions=drop
28
odl32-computeodl31-control
Topology: After Adding Neutron Networks and Router
br-int
br-ex
vxlan-192.168.254.32
eth1
br-int
br-ex
eth2
vxlan-192.168.254.31
eth1
OpenDaylight
router-node
eth1
eth0
192.168.56.1
External: VB Internal: 192.168.56.0/24
eth3Data: VB Internal: 192.168.254.0/24
eth3
Management: VB Host-only: 192.168.50.0/24
eth2
patch-ext
patch-int
patch-ext
patch-int
192.168.254.31 192.168.254.32
192.168.50.31 192.168.50.32
tapd0d15959-1f dhcp10.100.5.2
29
OVSDB: After Adding Neutron Networks and Routersudo ovs-vsctl showd9904cbd-34c7-48e2-b714-fb5d04a4d899 Manager "tcp:192.168.254.31:6640" is_connected: true Bridge br-ex Controller "tcp:192.168.254.31:6653" is_connected: true fail_mode: secure Port patch-int Interface patch-int type: patch options: {peer=patch-ext} Port br-ex Interface br-ex type: internal Port "eth2" Interface "eth2"Bridge br-int Controller "tcp:192.168.254.31:6653" is_connected: true
fail_mode: secure Port br-int Interface br-int type: internal Port patch-ext Interface patch-ext type: patch options: {peer=patch-int} Port "tapd0d15959-1f" Interface "tapd0d15959-1f" type: internal Port "vxlan-192.168.254.32" Interface "vxlan-192.168.254.32" type: vxlan options: {key=flow, local_ip="192.168.254.31", remote_ip="192.168.254.32"} ovs_version: "2.3.1"
30
Flows: After Adding Neutron Networks and Router (1 of 2)sudo ovs-ofctl --protocol=OpenFlow13 dump-flows br-int cookie=0x0, duration=35.009s, table=0, n_packets=7, n_bytes=558, in_port=1,dl_src=fa:16:3e:9f:82:6c actions=set_field:0x5dc->tun_id,load:0x1->NXM_NX_REG0[],goto_table:20 (DHCP port ingress) cookie=0x0, duration=179.731s, table=0, n_packets=1, n_bytes=90, priority=0 actions=goto_table:20 (pipeline) cookie=0x0, duration=35.011s, table=0, n_packets=0, n_bytes=0, priority=8192,in_port=1 actions=drop (drop everything else) cookie=0x0, duration=34.793s, table=0, n_packets=0, n_bytes=0, tun_id=0x5dc,in_port=3 actions=load:0x2->NXM_NX_REG0[],goto_table:20 (tunnel ingress) cookie=0x0, duration=180.247s, table=0, n_packets=16, n_bytes=1808, dl_type=0x88cc actions=CONTROLLER:65535 (LLDP punt) cookie=0x0, duration=179.721s, table=20, n_packets=8, n_bytes=648, priority=0 actions=goto_table:30 (pipeline) cookie=0x0, duration=29.644s, table=20, n_packets=0, n_bytes=0, priority=1024,arp,tun_id=0x5dc,arp_tpa=10.100.5.1 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:fa:16:3e:30:19:de->eth_src,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xfa163e3019de->NXM_NX_ARP_SHA[],load:0xa640501->NXM_OF_ARP_SPA[],IN_PORT (ARP response for vxnet gw) cookie=0x0, duration=29.574s, table=20, n_packets=0, n_bytes=0, priority=1024,arp,tun_id=0x5dc,arp_tpa=10.100.5.2 actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],set_field:fa:16:3e:9f:82:6c->eth_src,load:0x2->NXM_OF_ARP_OP[],move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],load:0xfa163e9f826c->NXM_NX_ARP_SHA[],load:0xa640502->NXM_OF_ARP_SPA[],IN_PORT (ARP response for vxnet DHCP namespace) cookie=0x0, duration=179.715s, table=30, n_packets=8, n_bytes=648, priority=0 actions=goto_table:40 (pipeline) cookie=0x0, duration=179.705s, table=40, n_packets=8, n_bytes=648, priority=0 actions=goto_table:50 (pipeline) cookie=0x0, duration=35.165s, table=40, n_packets=0, n_bytes=0, priority=61012,udp,tp_src=68,tp_dst=67 actions=goto_table:50 (allow DHCP) cookie=0x0, duration=179.695s, table=50, n_packets=8, n_bytes=648, priority=0 actions=goto_table:60 (pipeline)
31
Flows: After Adding Neutron Networks and Router (2 of 2)cookie=0x0, duration=179.684s, table=60, n_packets=8, n_bytes=648, priority=0 actions=goto_table:70 (pipeline) cookie=0x0, duration=29.657s, table=60, n_packets=0, n_bytes=0, priority=2048,ip,reg3=0x5dc,nw_dst=10.100.5.0/24 actions=set_field:fa:16:3e:30:19:de->eth_src,dec_ttl,set_field:0x5dc->tun_id,goto_table:70 (l3 src mac of tenant router) cookie=0x0, duration=179.673s, table=70, n_packets=8, n_bytes=648, priority=0 actions=goto_table:80 (pipeline) cookie=0x0, duration=29.578s, table=70, n_packets=0, n_bytes=0, priority=1024,ip,tun_id=0x5dc,nw_dst=10.100.5.2 actions=set_field:fa:16:3e:9f:82:6c->eth_dst,goto_table:80 (l3 forward to DHCP) cookie=0x0, duration=179.656s, table=80, n_packets=8, n_bytes=648, priority=0 actions=goto_table:90 (pipeline) cookie=0x0, duration=179.652s, table=90, n_packets=8, n_bytes=648, priority=0 actions=goto_table:100 (pipeline) cookie=0x0, duration=179.640s, table=100, n_packets=8, n_bytes=648, priority=0 actions=goto_table:110 (pipeline) cookie=0x0, duration=29.631s, table=100, n_packets=0, n_bytes=0, priority=1024,ip,tun_id=0x5dc,nw_dst=10.100.5.0/24 actions=goto_table:110 (allow subnet destined traffic) cookie=0x0, duration=34.801s, table=110, n_packets=0, n_bytes=0, priority=8192,tun_id=0x5dc actions=drop (pipeline) cookie=0x0, duration=179.615s, table=110, n_packets=1, n_bytes=90, priority=0 actions=drop (pipeline) cookie=0x0, duration=34.848s, table=110, n_packets=0, n_bytes=0, priority=16384,reg0=0x2,tun_id=0x5dc,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=output:1 ({multi,broad}cast tunnel ingress) cookie=0x0, duration=34.830s, table=110, n_packets=7, n_bytes=558, priority=16383,reg0=0x1,tun_id=0x5dc,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=output:1,output:3 ({multi,broad}cast) cookie=0x0, duration=34.998s, table=110, n_packets=0, n_bytes=0, tun_id=0x5dc,dl_dst=fa:16:3e:9f:82:6c actions=output:1 (l2 forward to DHCP port)
32
odl32-computeodl31-control
Topology: After Adding VMs
br-int
br-ex
vmvx110.100.5.3
192.168.56.10
dhcp10.100.5.2
vxlan-192.168.254.32
tap883f9022-bd
tapd0d15959-1f
eth1
br-int
br-ex
eth2
vmvx210.100.5.4
192.168.56.11
vxlan-192.168.254.31
tap5d62515a-be
eth1
OpenDaylight
router-node
eth1
eth0
192.168.56.1
External: VB Internal: 192.168.56.0/24
eth3Data: VB Internal: 192.168.254.0/24
eth3
Management: VB Host-only: 192.168.50.0/24
eth2
patch-ext
patch-int
patch-ext
patch-int
192.168.254.31 192.168.254.32
192.168.50.31 192.168.50.32
33
NFV● Provider/Telco Focus● OPNFV
○ SFC○ Open vSwitch for NFV○ Apex (RDO-based Installer)
● OpenStack○ Tacker
● OpenDaylight ○ OVSDB NetVirt, SFC
● OVS ○ DPDK, VXLAN-GRE + NSH
Layer 2Gateway
Tacker
38
SFC: The What and The Why● Mechanism for overriding the basic destination based
forwarding (policy based routing).● Cause network packet flows to route through a network
via a path other than the one that would be chosen by routing table.
● Bottom line: it can be used to “stitch” network services to create a service chain.
○ Dynamic (per need)○ Software defined (no human involved)○ No new “cabling” in existing network is required (overlay based)○ Addresses NFV needs
Haim Daniel, SFC Components
39
SFC Network Model
IP Underlay
BR-INT1 BR-INT2(SFF1) BR-INT4
Host(VM)
Server(VM)
SF1(VM)
BR-INT3(SFF2)
SF2(VM)
Neutron Net 1
tap tap tap tap
Neutron Net 2
Cmpt1 Cmpt2 Cmpt3 Cmpt4
• OVS Bridges are connected to an IP underlay & have IP addresses in the IP underlay context.
• VMs (both user and SF) are logically connected to overlay Neutron networks, and have IP addresses in those network contexts.
• The overlay networks are managed by the Neutron provider (e.g., OVSDB-NetVirt).
• The service chains are managed by SFC + handoffs from/to Neutron Provider at the beginning and end of chain.
• User VMs may be on same Neutron network or different networks connected via router.
• SF’s may be on same or different Neutron networks.
SFC Example - Separate SFFs
BR-INT1
BR-INT2(SFF)
BR-INT4
Host(VM)
Server(VM)
SF1(VM)
BR-INT3(SFF)
SF2(VM)
tap tap
vxlan (normal path)
vxlan-gpe
(SFC path)
● SFC redirects traffic from the normal path though a serice path.
● Components○ Service Funciton (SF)○ Classifier○ Service Function
Forwarder (SFF)○ Service Path
(SC/SP/RSP)○ SFC Proxy
vxlan-gpe
vxlan-gpe
vxlan-gpe
Mgmt
Mgmt
vxlan-gpe
ODL SFC and OVSDB NetVirt Projects● OVSDB NetVirt
○ Network virtualization layer responsible for l2 forwarding of tenant traffic
○ A neutron network provider○ OVSDB plugin for communicating with OVSDB
endpoints● SFC
○ Responsible for managing the Service Chain overlay○ Renders SFC REST into service chains
42
Tacker + SFC Overview:Phase 1 (Direct ODL API)
NFVO / VNFM
Tacker
Compute Node 1
Operator / OSS / BSS
CLIHorizon(GUI) API
OVS
ODL Controller
netconf/
yangOVSDB
Heat
Compute Node 2
OVS
...VNFvRouter
VNFDPI
VNFD
Templates
Nova Neutron(ODL plugin)
SFC API
Workflow:1) Onboard VNFD to
Catalog2) Instantiate 2 or more
VNFs from Catalog3) Invoke Tacker SFC API to
chain them
DB
Optional VNF configusing ODL netconf/yang
ODLsfc -driver
Sridhar Ramaswamy and Tim Rozet, Tacker + SFC43
VNFD
Tacker + SFC Overview:Phase 2 (Direct networking-sfc API)
NFVO / VNFM
Tacker
Compute Node 1
Operator / OSS / BSS
CLIHorizon(GUI) API
OVS
Heat
Compute Node 2
OVS
...VNFvRouter
VNFDPI
VNFD
Templates
Nova Neutron(networking-sfc)
SFC APIWorkflow:1) Onboard VNFD to
Catalog2) Instantiate 2 or more
VNFs from Catalog3) Invoke Tacker SFC API
to chain them4) Neutron sfc-driver
invokes networking-sfc API
DB
Optional VNF configusing ODL netconf/yang
networking-sfc driver
OVSSFC Agent
OVSSFC Agent
OVS driver
Sridhar Ramaswamy and Tim Rozet, Tacker + SFC44
Tacker + SFC Overview:Phase 3 (networking-sfc + ODL)
NFVO / VNFM / SFC API
Tacker
Compute Node 1
Operator / OSS / BSS
CLIHorizon(GUI) API
OVS
ODL Controller
netconf/
yangOVSDB
Heat
Compute Node 2
OVS
...VNFvRouter
VNFDPI
VNFD
Templates
Nova Neutron(sfc)
Workflow:1) Onboard VNFD to
Catalog2) Onboard NSD to Catalog
referring to 2 or more VNFs and VNFFGD describing the chain
3) Instantiate NSD4) Neutron sfc-driver invokes
networking-sfc API
DB NSD
Optional VNF configusing ODL netconf/yang
ODL sfc driver
neutronsfc -driver
Sridhar Ramaswamy and Tim Rozet, Tacker + SFC45
SFC Data Plane Components● Service Classifier: Determines which traffic requires
service and forms the logical start of a service path● Service Path: The actual forwarding path used to
realize a service chain● Service Function Forwarder (SFF): Responsible for
delivering traffic received from the network to one or more connected service functions according to information in the network service header as well as handling traffic coming back from the Service Function (SF)
46
Network Service Header (NSH)● NSH is a data-plane protocol that represents a service
path in the network● IETF adopted protocol● Two major components: path information and
metadata○ Path information to direct packets without requiring per flow
configuration○ Metadata is information about the packets and can be used for
policy
● NSH is added to packet via a classifier● NSH is carried along the chain to services
47
Network Service Header (NSH) 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Base Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Context Headers ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
● Base header: provides information about the service header and the payload protocol.● Service Path Header: provides path identification and location within a path.● Context headers: carry opaque metadata and variable length encoded information.
https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ 48
Service Path Header 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Path ID | Service Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
● Service Path Identifier (SPI): identifies a service path. Participating nodes MUST use this identifier for Service Function Path selection.
● Service Index (SI): provides location within the SFP. The first Classifier (i.e. at the boundary of the NSH domain)in the NSH Service Function Path, SHOULD set the SI to 255, however the control plane MAY configure the initial value of SI as appropriate (i.e. taking into account the length of the service function path). A Classifier MUST send the packet to the first SFF in the chain. Service index MUST be decremented by service functions or proxy nodes after performing required services and the new decremented SI value MUST be reflected in the egress NSH packet.
https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ 49
VXLAN + NSHIPv4 Packet
+----------+------------------------+---------------------+--------------+----------------+|L2 header | IP + UDP dst port=4790 |VXLAN-gpe NP=0x4(NSH)|NSH, NP=0x1 |original packet |+----------+------------------------+---------------------+--------------+----------------+
https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ 50
OVS● Currently using a very old patched version referred to as
NSH V8.● Work is underway to commit newer patches that have
been adapted to fit the current OVS architecture and rely on vxlan capabilities in the kernel.○ Jiri Benc, Flavio Leitner and Thomas Herbert are
working on the patches.○ Latest patch also has support for NSH over Ethernet
51
Going Forward● Need the NSH patches upstreamed● Or can we use something other than NSH. ● Resolve neutron-sfc and ODL SFC APIs● ODL SFC isn’t as dynamic as it should be. Changing
any part of the chain rebuilds the whole chain.● Is Tacker the VNf orchestrator to used or should other
options be used?
52