V3.0 July 2015©OneCloud Inc.– SanJose, CA
OpenStack: Advanced Networking
OneCloud Consulting• Close Alliance with Cisco • Former Cisco Engineering, Services, & Technical Marketing Engineers
• CVG, DCG & INSBU Residency & Relationship• Custom Development: UCS/UCSD, ACI & OpenStack services and development• Training: Education, TOI, Custom engagements• Deployment/Integration/Support: Customer enablement of Cisco Technologies
• Global Presence• Demonstrated ability to deliver globally and to a diverse audience• Resident Software Development capability in US (6) and India (10)
2
Course Expectations• Instructor • Student• Course
• Intent• Approach• Outcomes
• Resources• onecloudclass.com
• Web-based Lab Guide• Presentation PDF
3
AgendaModule 1SDN In
OpenStack
Module 2OpenStack Networking
Module 3Neutron L2
Module 4OpenStack
Services
Module 5Cisco &
OpenStack•A Short History of SDN
•Dynamic ‘overlay’ networks
•SDN Controllers•SDN in OpenStack
•Generic Neutron Function
•Integration with Controllers
•OpenStack Network History
•Nova Network and Functions
•Neutron Creation and Integration
•L2 Past and ML2 Present
•Using ML2 Model and basic L3 and Services
•XaaS- beyond L2•L3 Agent, HA, DVR
•LBaaS•VPNaaS•FWaaS (in incubation)
•L3aaS•L3 service plugin
•Nexus•ACI ‘approximation’ model
•ACI overview•Group Policy in OpenStack
Cloud Defined
Platform as a Service (PaaS)
Infrastructure as a Service (IaaS)
Software as a Service(SaaS)
Rapid Elasticity
Resource Pooling
Public Hybrid Community Private
Measured Service
US NIST Cloud Model
ServiceModels
DeploymentModels
Broad Network Access
Essential Characteristics
On-DemandSelf Service
5
Application HistoryMonolithic (1940-1980)
• Mega scale “single” compute needed to deal with app scale• Development as waterfall process, major projects for development, upgrades, etc.• Security and scale through dedicated external appliances (firewall, SAN storage)
Distributed (1980-2010)• Application broken into scalable units• Development still waterfall, with complex management and staging required for component upgrades• Security and scale rely more heavily on network, QoS, embedded services• Internet bubble web sites, load balancing via appliances to monolithic web, app, db servers
WebScale (2010-Present)• Applications broken into smaller easy to replace units with managed APIs for interaction• “Agile” development with Continuous Integration and Deployment• Distributed security, either in the app, or at the network edge• Current super-scale web services and rapidly developed super-custom apps
Teams Manage Infrastructure
6
Developer Manages Infrastructure
Teams Still Manage Infrastructure
What is OpenStack?• OpenStack is an open source infrastructure
and application middleware for building private and public clouds.
• OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources throughout a datacenter.
• OpenStack is backed up by a global community of technologists, developers, researchers, corporations and cloud computing experts.
ComputeNetworking
Storage
7
History
• NASA Nebula project (scalable compute “cloud”)
• RackSpace CloudFiles project (scalable object storage “cloud”)
• Developer Led “Summits”• 6-month development to release
cycle• Community involved• Foundation formed to manage
“open” process
8
Cisco and OpenStack
9
Why is Cisco involved in OpenStack ?
“We’re projecting our vision of the network’s role in the cloud and working to ensure that that vision is a reality in the many clouds of the future.”
10
Cisco + OpenStack
• Cisco Validated Designs for production deployments
• Work closely and jointly with customers to design and build their OpenStack environment
• OpenStack based Global Intercloud hosted across Cisco and partners data centers
• Cisco Webex Service running on OpenStack
• Neutron/Nova Plug-ins for Cisco product lines – Nexus, DFA, APIC, UCS• UCS/UCSM SDK/integration tools
• Code contributions across several services – Network, Compute, Dashboard, Storage
• Former Foundation Board member Communit
yParticipationEngineering
Partners/Customers
Cloud Services
11
OpenStack ArchitectureHorizon
Swift Cinder Neutron Ceilometer Trove Sahara
Keystone
GlanceNova-----
Ironic
Heat
• OpenStack is made up of individual projects• Largely written in Python and is heavily dependent on Linux
Compute ImageStorage
ObjectStorage
BlockStorage
Network Metering Database as a Service
Analytics as a Service
Authorizationand
Authentication
Orchestration
Dashboard
12
Lab 1 - Deploy an OpenStack environment
We'll build a simple PackStack environment, which we'll then use for the rest of the class effort.1) Register your class user account at http://bit.ly/advnet1Log into lab.onecloudinc.com (user information is as per Pod5)3) run packstack setup script (already on initial VM): https://github.com/onecloud/cloud-tools/blob/master/get_packstack.sh
Lab Default Reference Model• Single Controller (AIO)
• Network on Controller• OVS + L3_agent• Cinder on LVM
• Separate Compute• Nova• Cinder• OVS + VLAN
Control Node
KeystoneNova
Neutron (L2/L3)CinderHorizon
Compute Node
NovaCinder(OVS)
Management: 10.1.64.0/24
Public/Float: 172.24.4.224/28
VLAN / VxLAN / GRE…
14
AgendaModule 1SDN In
OpenStack
Module 2OpenStack Networking
Module 3Neutron L2
Module 4OpenStack
Services
Module 5Cisco &
OpenStack•A Short History of SDN
•Dynamic ‘overlay’ networks
•SDN Controllers•SDN in OpenStack
•Generic Neutron Function
•Integration with Controllers
•OpenStack Network History
•Nova Network and Functions
•Neutron Creation and Integration
•L2 Past and ML2 Present
•Using ML2 Model and basic L3 and Services
•XaaS- beyond L2•L3 Agent, HA, DVR
•LBaaS•VPNaaS•FWaaS (in incubation)
•L3aaS•L3 service plugin
•Nexus•ACI ‘approximation’ model
•ACI overview•Group Policy in OpenStack
Module 1SDN in OpenStack
16
SDN in OpenStack● SDN Control● OpenStack Control model (delta from SDN)● Virtual Switching (in OpenStack)
17
Origins of SDN
Merger of multiple domains● Security compliance● End-user-enabled change● Reduction in change control opportunity window
How do you model this kind of rapid change?● Network centric focus● Distributed networks from the beginning● BGP routing is the model - how to apply beyond L3 (both
below and above)
PreSDN Network Management
I19
Tenant AVM1
Tenant AVM2
Tenant CVM1
Tenant CVM2
Tenant CVM3
Tenant CVM4
Policy
Standard Approach to Distributed Networking
20
Forwarding Hardware
Software Control
Forwarding Hardware
Software Control
Forwarding Hardware
Software Control
Forwarding Hardware
Software Control
Forwarding Hardware
Software Control
BGP managed forwardingWhat about ACLsWhat about port configurationVPN endpoints…
BGP Routing Control
Before SDN - Poor forwarding abstraction
21
VRF
Controller
Router/Switch
L3 TableL2 Table + VLAN ACL + QoS Port Groups
I
A
B
C
Distributed Configuration of Forwarding State
Manual Configuration of Forwarding State
Packet in
Packet out● Fixed Function (L2, L3)● Implementation often exposed through API● Unclear state consistency semantics
With SDN - Generalized dataplane
22
OpenFlow Controller
Router/Switch
I
A
B
CFlow Table Flow Table Flow Table
● Programmatic management of function ● Minimal API● Consistency data semantics
Programmatic Configuration of Forwarding State
SDN Approach to Distributed Networking
23
Forwarding Hardware
OpenFlow
Forwarding Hardware
OpenFlow
Forwarding Hardware
OpenFlow
Forwarding Hardware
OpenFlow
Forwarding Hardware
OpenFlow
Software Control
Generalized Hardware
HAL
ControlApplication
Decouple Control Logic
OpenFlow
Network OS
The SDN Model
SDN
OpenFlow to manage:ForwardingAccess ControlEncapsulation
OpenStack “SDN” Controller
Controller
vSwitch vSwitch
VM_1 VM_2
Connect Connect
Communicate
confignotify notify5
74
632
1
24
OpenStack “SDN” Controller
communicate
Nova
Neutron
ML2pSwitch
vSwitch vSwitch
VM_1 VM_2
1
4
2
33
4
boot
boot6
6
7
nova/neutron interact6
5
25
OVS – Virtual Switching• OpenFlow based virtual
switch• Central controller• Kernel forwarding (after
local flow validation/setup)• VLAN/Vxlan/GRE
forwarding
• Default OS config uses Neutron as central control, and local agents rather than OVS control path
Kernel forwarding
OVS local control
OpenStack Agent
kernel
user
Configure Flow
First Packet
Flow
26
Diving Deeper - OVS mapping
27
VM01
Linux Bridge
vnet 0
eth 0
br-int
int-br-eth 1
phy-br-eth 1
br-eth 1
IP
Configured by Nova Compute
eth 1
qvbWWWveth pair
Linux Bridge
TAP device
Open vSwitch
VLAN101
VLAN10228
VM01
Linux Bridge
vnet 0
eth 0
qvbWWW
br-int
int-br-eth 1
phy-br-eth 1
br-eth 1
IP
Configured by Neutron Agent
Open vSwitch
veth pair
Linux Bridge
TAP device
VLAN101
eth1
VLAN10229
Configured by Nova Compute
qvbWWW
Port VLAN tag:1
VM01 VM02 VM03
Linux Bridge Linux Bridge Linux Bridge Linux Bridge
vnet 0 vnet 1 vnet 2 vnet 3
eth 0 eth 0 eth 1 eth 0
qvbWWW qvbXXX qvbYYY qvbZZZ
br-int
int-br-eth 1
phy-br-eth 1
br-eth 1
IP IP IP IP
Open vSwitch
veth pair
Linux Bridge
TAP device
VLAN101
VLAN102
eth1
Configured by Neutron Agent
30
Configured by Nova Compute
qvbZZZqvbYYYqvbXXXqvbWWW
Port VLAN tag:1 Port VLAN tag:2
VM01 VM02 VM03
Linux Bridge Linux Bridge Linux Bridge Linux Bridge
vnet 0 vnet 1 vnet 2 vnet 3
eth 0 eth 0 eth 1 eth 0
qvbXXX qvbYYY qvbZZZ qvbWWW
qvbXXX qvbYYY qvbZZZ
br-int
qvbWWW
int-br-eth 1
phy-br-eth 1
Port VLAN tag:1 Port VLAN tag:2
br-eth 1
IP IP IP IP
Tenant flows are separated by internally assigned VLAN ID
Tenant flows are separated by user defined VLAN ID
VLAN ID is converted with flow tabledl_vlan=101 mod_vlan_vid:1dl_vlan=102 mod_vlan_vid:2
VLAN ID is converted with flow tabledl_vlan=1 mod_vlan_vid:101dl_vlan=2 mod_vlan_vid:102
VLAN101
VLAN102Physical L2 Switch for
Private Network
eth 1
VM02 VM03
veth pair
Open vSwitch
31
VM01
Lab2 - OVS flow review
Lab 2 looks at the current state of OVS+GRE
Spin up two VMs, and force them to the different compute nodes (--availablity-zone nova:aioXXX)Trace flows between two VMs (bridge-ovs-?)
AgendaModule 1SDN In
OpenStack
Module 2OpenStack Networking
Module 3Neutron L2
Module 4OpenStack
Services
Module 5Cisco &
OpenStack•A Short History of SDN
•Dynamic ‘overlay’ networks
•SDN Controllers•SDN in OpenStack
•Generic Neutron Function
•Integration with Controllers
•OpenStack Network History
•Nova Network and Functions
•Neutron Creation and Integration
•L2 Past and ML2 Present
•Using ML2 Model and basic L3 and Services
•XaaS- beyond L2•L3 Agent, HA, DVR
•LBaaS•VPNaaS•FWaaS (in incubation)
•L3aaS•L3 service plugin
•Nexus•ACI ‘approximation’ model
•ACI overview•Group Policy in OpenStack
Module 2OpenStack Networking - Neutron
34
OpenStack Networking (Neutron)Horizon
Swift Cinder Neutron Ceilometer Trove Sahara
Keystone
GlanceNova
Heat
What is it?• Network Services manager• Supports L2, L3, and L4 services• Interacts with Nova to support
network functions for VMs
What can it do?• CRUD L2, L3 (subnet), IPAM/DHCP• Basic L3 with inbound NAT/FloatingIP• Extensions provide:
• L3 service (ha router, fw, slb)• Access to Physical/Virtual services (e.
g. VLAN/VXLAN on a switch)35
First there was Nova-Network• Basic Network models including a VPN service
•FLAT or VLAN Based networks (with VPN access)•Outbound "PAT" and inbound "NAT"
• IPv4 DHCP and Cloud Metadata service• IPTables based software routing
• Embedded in Nova, not really a separate service• Provided for basic network service
•still in use in many production environments•Parity is still a "goal" for Neutron
• Missing some key pieces•Service extension like LBaaS•Alternate L2 software based networks
36
Then there was Neutron• Breaks out Network function into it’s own project
• Provides a plugin mechanism to enable different technologies
• Provides consistent high level API• Tenant L2/L3/XaaS• Overlapping IP ranges• Simple compute-network interaction model
• API extensions enable additional control• Security and Compliance policies• Quality of Service• Monitoring and Troubleshooting
37
Neutron - Key Services• Port, Network, and Subnet
• DHCP services via DNSmasq (default)
• L3 Forwarding via IPTables software (default)
• Floating IPv4 address management/NAT via IPTables (default)
• Cloud-Init Metadata service for VM bootstrap data
• XaaS enablement (VPN, FW, SLB)
• Performance Monitoring38
Tenant Segment (L2)
Outbound Traffic “PAT”Overloads Tenant Gateway addressAllows access to “external” services
Floating IP allocation[1.2.9.75] ➔ [172.16.0.23]Tenant Gateway “NAT” to VM
Neutron ModelOpenStack Generic Network
VM VM Interface[172.16.0.23]DHCP AssignedPre-allocated Address
Security Group Applied[Allow HTTP & SSH]
[172.16.0.0/24]
[1.2.9.0/20]
RFC 1918IPv4
Addresses
Tenant Router/“NAT” GatewayGateway Port
Provider NetworkProvider AllocatePublic IPv4Address Space
39
• Network / Ports / Subnets• L2 / Broadcast is the base API• No concept of dependency mapping or intent
VMVMDHCP and MetaData Service connect directly (or rather via ip namespace) to tenant net
L3 outside
Virtual or
physical L2
Outside L3
+1 +2
“physical” view
L2 neutron
Neutron Architecture
Core Plugins
ML2
Service Plugins
Message Queue
Load
Bal
ance
r
Fire
wal
l
VP
N
HA
Pro
xy
IPTa
bles
Ope
nSw
an
L3 S
ervi
ces
Futu
re S
Ps
VLA
N
GR
E
VX
LAN
Cis
co N
exus
OV
S
Ope
nDay
Ligh
t
AP
IC
Mor
e ve
ndor
dr
iver
s
OV
S
Ci (
Nex
us,
N1K
v)M
ore
vend
or
plug
ins
L3 Agent
L2 Agent
DHCP AgentREST API
Neutron Server
Network Node
Control Node
Compute NodeType Drivers Mechanism Drivers
Nova
Keystone
Glance
DatabaseOVS
Driver
IP Tables
41
AgendaModule 1SDN In
OpenStack
Module 2OpenStack Networking
Module 3Neutron L2
Module 4OpenStack
Services
Module 5Cisco &
OpenStack•A Short History of SDN
•Dynamic ‘overlay’ networks
•SDN Controllers•SDN in OpenStack
•Generic Neutron Function
•Integration with Controllers
•OpenStack Network History
•Nova Network and Functions
•Neutron Creation and Integration
•L2 Past and ML2 Present
•Using ML2 Model and basic L3 and Services
•XaaS- beyond L2•L3 Agent, HA, DVR
•LBaaS•VPNaaS•FWaaS (in incubation)
•L3aaS•L3 service plugin
•Nexus•ACI ‘approximation’ model
•ACI overview•Group Policy in OpenStack
Module 3OpenStack Services - ML2 & L3
43
• Modular Layer 2: replaces multiple different "Core" technologies
•Layer 2 networking technologies•Virtual Switching: Open Virtual Switch,
Linux Bridge, Hyper-V DVS, VMware NSX•L2 Population (efficient tunnel creation,
efficient broadcast forwarding)•Or replace OpenStack's Control with an SDN controller
• OpenDaylight• OpenContrail• Nuage Networks• Midukora• Plumgrid
Layer 2 Management - ML2
VLA
N
GR
E
VX
LAN
Cis
co N
exus
OV
S
AP
IC
Type Drivers
44
Neutron Server
Mechanism Drivers
Core Plugin
ML2
Ope
nDay
Ligh
t
Mor
e ve
ndor
dr
iver
s
L2 Population - Building trees for Overlays
Tunnel protocols build full mesh networks by defaultL2_population attempts to build trees for forwarding based on VM availability (e.g. create high level flow mapping)
- ARP Proxy- Broadcast encap- OVS or linuxbridge support
NS
VMa/b VMa
VMb
NS
VMa/b VMa
VMb
Lab 3 - Demo - Use ML2 Nexus Plugin
Enable ML2 Nexus Plugin against VLAN based ML2 OVS environment.
PackStack Kilo based installAdd ML2 mechanism driver and configuration- add additional python components- enable configuration for ML2 Cisco Nexus driver
Tenant Segment (L2)
Outbound Traffic “PAT”Overloads Tenant Gateway addressAllows access to “external” services
Floating IP allocation[1.2.9.75] ➔ [172.16.0.23]Tenant Gateway “NAT” to VM
Neutron ModelOpenStack Generic Network
VM VM Interface[172.16.0.23]DHCP AssignedPre-allocated Address
Security Group Applied[Allow HTTP & SSH]
[172.16.0.0/24]
[1.2.9.0/20]
RFC 1918IPv4
Addresses
Tenant Router/“NAT” GatewayGateway Port
Provider NetworkProvider AllocatePublic IPv4Address Space
47
• Network / Ports / Subnets• L2 / Broadcast is the base API• No concept of dependency mapping or intent
VMVMDHCP and MetaData Service connect directly (or rather via ip namespace) to tenant net
L3 Agent• An API extension to allow administrators and
tenants to create “routers” that connect to L2 networks.
• It uses the Linux IP stack and iptables to perform L3 forwarding and NAT (Masquerade).
• Defaults to using Linux Network namespaces to provide isolated forwarding contexts (VRF).
• Each router will have its own namespace with a name based on its UUID.
VM
L3-agent
Network Node
48
IPTables• L3 agent uses IPTables to perform NAT.• User space application program that allows a system
administrator to configure the tables provided by the Linux kernel firewall.
• IP Tables is also used for security groups at the VM port (nova-compute deployed/managed Linux Bridge + IPtables rules).
• Used for different protocols• IPtables applies to IPv4• IP6tables to IPv6• arptables to ARP {no user control}• ebtables to Ethernet terms {used for spoofing control, no user
control}
VM
L3-agent
Network Node
49
br-int
Public NetPhysical networkVLAN ID 101
Multiple Networks & Routingovs-neutron-agentovs-neutron-agent
L3-agent
dhcp-agent
br-tun
VXLAN
VM03
br-int
br-eth1
VM01
Compute Node
network Blocal OVS ID 5
network Alocal OVS ID 2
DHCP ports
Router interface ports
Network Node
network A local OVS ID 11
network B local OVS ID 8
Router gateway and floating ip ports
br-ex
eth1 eth1VXLAN
br-tun br-eth1
eth1
br-int
external network Dbinding: local
50
DHCP & MetaDataDHCP Service supported principally via DNSMasq
- New in Kilo is better 3rd party IPAM support (and therefore alternative DHCP service support)
- Cisco PNR is being integrated (for the CIS project, but should work for others as well)
MetaData is enabled by default as a proxy via DNSMasq- Provided by the Cloud-Init metadata service (well know WS @
169.254.169.254)- Used for VM initialization (ssh key injection)- Can be used 'post boot' as well- proxy function enables mapping of VMs with overlapping IP ranges
External network Internal network
Floating IP Networks
Router is used for VM to access outside andallow VMs on different subnets or networks access each otherFloating IP is used for outside to access VM
gw_port7.0.1.2/24Floating ip:7.0.1.4/24
Router interface10.0.1.1/24
VM10.0.1.5/24gw: 10.0.1.1/24
I
52
l3_agent
Floating IP portFloating IP fixed port on fixed IP network
In general, the port acting as router interface should have gateway address of
subnet
external networkvswitch br-ex
eth0
Lab 4 - Use L2 and L3 Services
Delete and create a network, router, and floating IP poolmap a floating IP to a VMconnect to the VM via floating IP
AgendaModule 1SDN In
OpenStack
Module 2OpenStack Networking
Module 3Neutron L2
Module 4OpenStack
Services
Module 5Cisco &
OpenStack•A Short History of SDN
•Dynamic ‘overlay’ networks
•SDN Controllers•SDN in OpenStack
•Generic Neutron Function
•Integration with Controllers
•OpenStack Network History
•Nova Network and Functions
•Neutron Creation and Integration
•L2 Past and ML2 Present
•Using ML2 Model and basic L3 and Services
•XaaS- beyond L2•L3 Agent, HA, DVR
•LBaaS•VPNaaS•FWaaS (in incubation)
•L3aaS•L3 service plugin
•Nexus•ACI ‘approximation’ model
•ACI overview•Group Policy in OpenStack
Module 4OpenStack Services - L3 and Beyond
55
Services in Neutron
• L3 Routing and PAT/NAT service• L3 XaaS
•L3aaS•SLBaaS•FWaaS•VNPaaS
56
Neutron XaaS Architecture• Similar in concept to ML2
plugin• Common plugin/API
provides ability to talk to “any” device or set of devices
• Central database table per XaaS extension keeps environment in sync
NeutronServer
XaaSNeutronAdvSvcPlugin
Neutron + XaaS API Extensions
Automation for XaaS
XaaS Scheduler
XaaSAgent
REST APIDrivers
AMQP (Async)
Database
Device - A
Device - B
57
L3 Service Plugin
• Supports CSR1000v in Juno (plus others)• No HA model in the plugin, but can be implemented by device
drivers
• ASR-1000 support with L3 HA (HSRP {RG future}), NAT, and v6 in development for CIS and others, code is available for IceHouse, Juno, and Kilo releases.
• Can still support L3_agent based model via new device driver
58
HW_1
Service PluginController
Neutron-Server
Config-agent
L3 device driverASR
L3 CSR driver
L3 service plugin
ASR Pairnetconf
CSR
vm
REST
Neutron XaaS
60
LBaaS - Load Balancing as a Service
[10.0.0.0/24]
Tenant Router10.0.0.130.0.0.2
Tenant AVM1
10.0.0.2
Tenant AVM2
10.0.0.3
Tenant AVM3
10.0.0.4
Load Balancer10.0.0.530.0.0.5
External Net
[30.0.0.0/24]
Tenant Net
• Distributes clients requests across multiple servers
• Load balancing client traffic coming from one network to application services (e.g. VMs) on the same or a different network.
• Default model: HAproxy VM• Supports classic algorithms • Basic health monitoring
(ping, etc.)• Can also collect forwarding
statistics 61
VPNaaS - VPN as a Service
[10.0.2.0/24]
Tenant AVM1
10.0.1.2
Tenant AVM2
10.0.2.2
Tenant NetTenant Net
[10.0.1.0/24]
I II
IPSEC
• Extends L3_agent now a Service Plugin much like the L3 Service Plugin model
• Adds ability to create point to point and point to multipoint IPSEC tunnels
• Plan to add MPLS class VPN capabilities/ configuration
• Default model leverages OpenSwan to control p2p links
• Cisco Service Plugin for VPN allows for use of CSR1000v
62
FWaaS - Firewall as a Service
[10.0.0.0/24]
Tenant Router10.0.0.130.0.0.2
Tenant AVM1
10.0.1.2
Tenant AVM2
10.0.1.3
Tenant BVM1
10.0.0.4
External Net
[30.0.0.0/24]
Tenant Net
Tenant BVM2
10.0.0.4
[10.0.1.0/24]Tenant Net
• Provides OpenStack users with the ability to deploy firewalls to protect their networks.
• Features of OpenStack• Apply firewall rules on traffic
entering and leaving tenant networks.
• Support for applying tcp, udp, icmp, or protocol agnostic rules.
• Creation and sharing of firewall policies which hold an ordered collection of the firewall rules.
• Ability to audit firewall rules and policies.
63
L3aaS
User adds an Internal Network to a Router
1) client.add_interface_router()
2) REST API call, add_router_interface()3) core_plugin.create_port(), writes new data to DB
4) “routers_updated” AMQP message
5) Read new state from DBget_sync_data()
router’s port lists updated_process_router()
6) driver.internal_network_added()
7) config push via NetConf
Horizon Dashboard neutronclient
CiscoCfgAgent/RoutingSvcHelper
process_services() loop
Listens for update notifications, fetches state from DB, and calls driver
when updates occur
neutron-server(L3-NAT-db-mixin functions)
Implemented by:PhysicalL3RouterApplianceDBMixin
PhysicalCiscoRouterPlugin
ASR1k HSRP pair
MySQL DB
ASR1k Driver
l3_rpc_joint_agent_apinotifier module
Lab 5 - Use CSR in a Tenant Context
It many not always be possible to deploy a network service _in_ OpenStack, so we'll work through using the CSR as a tenant appliance.Install the CSR image (with the appropriate tweaks)Deploy the CSR as a router (in parallel with L3_agent routing)
- Access the CSR routed VMs directly via CSR on the "public" network
- Access the CSR via the FloatingIP model
Lab 6 - Use the CSR via Neutron
Enable L3 Service via Neutron
Establish a CSR based router
Create a VM with a Floating IP address associated
AgendaModule 1SDN In
OpenStack
Module 2OpenStack Networking
Module 3Neutron L2
Module 4OpenStack
Services
Module 5Cisco &
OpenStack•A Short History of SDN
•Dynamic ‘overlay’ networks
•SDN Controllers•SDN in OpenStack
•Generic Neutron Function
•Integration with Controllers
•OpenStack Network History
•Nova Network and Functions
•Neutron Creation and Integration
•L2 Past and ML2 Present
•Using ML2 Model and basic L3 and Services
•XaaS- beyond L2•L3 Agent, HA, DVR
•LBaaS•VPNaaS•FWaaS (in incubation)
•L3aaS•L3 service plugin
•Nexus•ACI ‘approximation’ model
•ACI overview•Group Policy in OpenStack
Module 5
68
Cisco OpenStack Embedded Devices• Nexus switches (ML2)
• VLAN and VLAN trunk• Future VXLAN/VLAN mapping• L3 via local SVI (no HA)
• CSR1000v (Juno) (Service)• L3 Router + NAT (Floating IP and
“outbound” overload)• VPNaaS Endpoint (p2p or multi-point)
(since Icehouse)• FWaaS
• ASAv (future) (Service)• VPNaaS• FWaaS (possible)
• Nexus 1000v (now) (ML2)• Extension based port-profile driven
networks• DFA (now) (ML2)
• Extension based port-profile driven networks
• APIC (ML2)• Simplified model for Policy – Uses
current Neutron interfaces (now)• Neutron policy interface (?-Kilo)
• ASR router (Future) (Service)• HA aware L3 Router + NAT
69
70
OpenStack Networking with Cisco Devices
Tenant VM
Upstream Internet/Intranet
hypervisorhypervisornetctrl
Tenant VM Tenant VM Tenant VM
CSR SLB
OSOS bareOS bare OS
KVM n1000VEM
nova agent
KVM
nova agent
OVS
neutron
Mgmt
M
KVM
VSM
Nexus 5/6/7/9
nova-serverneutron-server
L3 - service driverML2 - driver DHCP
VSM - VEM Management
One Machine
| N1000v| N5/6/7/9K| OVS
Cisco Nexus Plugin
• Works with Nexus 3k/5k/6k/7k/9k
• Support for Neutron Provider Networks
• Dynamic VLAN and SVI provisioning/de-provisioning on ToR
Compute NodesVM on a Compute
Neutron Server
Neutron Core plugin (Cisco/ML2)
ncclient
Nova
Compute Nodes
create/update port request sent to Neutron
VM VM
Nexus ToR
Cisco Nexus Driver
Neutron Server
Neutron Core plugin (Cisco/ML2)
ncclient
Nexus ToRNexus ToR
Compute Nodes
VM VM
Nova
71
ml2_conf_cisco.ini[ml2_cisco]# Example:# [ml2_mech_cisco_nexus:1.1.1.1]# compute1=1/1# compute2=ethernet:1/2# compute3=port-channel:1# ssh_port=22# username=admin# password=mySecretPassword
72
Lab 7 (Demo) - Enable Cisco Nexus ML2
Move from GRE to VLAN tunnels for tenantsEnable Nexus ML2 driverCreate Network with tenant VLAN and verify creation
neutron port-create NETWORK_NAME -- n1kv:profile_id PROFILE_ID
Policy
Cisco Nexus1000v Plugin (KVM)neutron network-profile-create PROFILE_NAME
vlan --segment_range 400-499
neutron net-create NETWORK_NAME -- n1kv:profile_id PROFILE_ID
neutron policy-profile-list
▪ Network Profiles – VLAN, VXLAN (multicast/unicast), Trunk
▪ Policy Profiles – ACLs, QoS
▪ VXLAN Gateway Service VM
Network Profile (admin)
Policy Profile defined in VSM(periodic polling)
ProfileCompute Nodes
VM on a Compute
Nova
Compute Nodes
VM VM
Cisco N1Kv Plugin
Neutron Server
Neutron Core plugin (Cisco/ML2)
N1Kv VSM
Compute Nodes
VM VM
Nova
N1Kv VEM
Network Profile:Network Segment Pool Policy Profile:Port Profile,
74
▪ Service Pluginso Management of logical resources
▪ Schedulero Select Hosting device
▪ Device Managero Lifecycle management of devices
(Spinning up of NFV devices)o Book-keeping of processing capacity in
devices (Avoid over allocation)
▪ Config Agento Apply configuration to deviceso Monitor health devices
Compute NodesCompute Nodes
VM VM
Neutron Server
NFV Device Driver
DeviceManagerScheduler
Config Agent
Nova
Neutron Server
Neutron Service Plugin
Scheduler Device Manager Nova
NFV Device Driver
config agent
75
NFV (Cisco Driven Architecture)
Cisco CSR1000v for Neutron L3 Service
Compute NodesCompute Nodes
VM VM
Neutron Server
NFV Device Driver
DeviceManagerScheduler
Config Agent
Nova
Neutron Server
Neutron Service Plugin (L3)
Scheduler Device Manager Nova
Routing Device Driver(CSR1Kv)
config agent
CSR1Kv VM
Rest API / netconf
Mapping of Neutron reference L3 implementation:
● Linux namespaces - CSR1Kv VRF
● Router ports (qr) on bridge – CSR1Kv VLAN sub interfaces
● Gateway ports (qg) on bridge - CSR1Kv VLAN sub interfaces
● Linux IPTables – CSR1Kv NAT
Benefits:● Available as NFV services● Scalable solution● Integrates with N1Kv
76
Example CSR1Kv config
External Gateway port:173.38.209.1
Floating IP port:173.38.209.2
10.0.100.2
Internal Gateway port10.0.100.1
encapsulation dot1Q 500
ip address 10.0.100.1 255.255.255.0ip nat inside
interface GigabitEthernet2.600 encapsulation dot1Q 600ip vrf forwarding nrouter-462986b8ip address 173.38.209.1 255.255.255.0ip nat outside
ip nat inside source static 10.0.100.2 173.38.209.2vrf nrouter-462986b8 match-in-vrf
External Network -173.38.209.0/24
VLAN 600
Neutron Router (CSR)
Neutron Network and Subnet - 10.0.100.0/24 VLAN 500
VM1
77
CSR1000v VPN Service Driver (KVM)
Cisco VPN ServiceDriver
Cisco VPN Device Driver
Performs validation and sends to agent
Benefits▪ CSR1Kv secure VPN qualified solution▪ Unlock rich CSR1Kv features into OpenStack
neutron vpn-ikepolicy-create ikepolicy1
neutron vpn-ipsecpolicy-create ipsecpolicy1
neutron vpn-service-create --name myvpn --description "My vpn service” router1 mysubnet
neutron ipsec-site-connection-create --name vpnconnection1 \ -- vpnservice-id myvpn \--ikepolicy-id ikepolicy1 \--ipsecpolicy-id ipsecpolicy1 \--peer-address 172.24.4.23 --peer-id 172.24.4.23 --peer-cidr \ 10.2.0.0/24 --psk secret
Neutron Service plugin (VPN)
RPC calls Compute NodesCompute Nodes
VM VM
REST API
Neutron Server
Cisco VPN Device Driver
CSR1KvVM
78
VPN Agent
Dynamic Fabric Automation(DFA)
Neutron Server
Neutron Core plugin(ML2)
Cisco DFA Driver
VM’s
vswitch
LLDP Agent
Compute Nodes
REST API
communicates (VDP) with the Leaf passing the VM’s information along with the Segment ID when instance is created/deleted.
neutron net-create NETWORK_NAME--dfa:cfg_profile_id PROFILE_IDneutron config-profile-list
vSwitch Driver
DFA config profile for OpenStack Networks
Benefit▪ Fabric based overlays with
OpenStack
▪ Network Fabric Advantages exposed to OpenStack networks
Neutron Server
Neutron Core plugin (ML2)
vSwitch Driver
Cisco DFA Driver
Data Center Network Manager (DCNM)
DFA Spine/Leaf
Compute NodesCompute Nodes
VM VM
vSwitch LLDP Agent
Network attributes communicated to switches
79
APIC Driver – ML2
neutron router
security group
Web
HYPERVISOR HYPERVISOR HYPERVISOR
neutron network
• ML2 (modular level 2) driver supporting existing Neutron APIs: network, router, security group, LBaaS, etc.
• Automation of neutron ports for virtual machines
• Relies on OVS in hypervisor
• Available on Openstack IceHouse, Juno.
App DB Web Web App
APIC Driver (ML2)
OVS Plugin
Neutron
APIC Plugin
OpenStack APIC ML2 Plugin
Host 4
OVS
IPTables
APIC Plugin converts networks to End Point Groups
REST API
Host 1
OVS
IPTables
Host 2
OVS
IPTables
Host 3
OVS
IPTables
OVS Plugin
Controller Node
Neutron
APIC Plugin
Neutron
APIC Plugin Workflow
Hypervisor Hypervisor Hypervisor Hypervisor Hypervisor Hypervisor
ACI Fabric Offers:• VXLAN tunnels• Distributed L2• Distributed default
gateway
1. User creates a network / router / etc. through Neutron CLI / Horizon / Heat2. OVS Driver selects VLAN from VLAN pool. VLAN is configured in Open vSwitch3. APIC Driver maps neutron object to APIC policy model4. IP Tables in Linux Hypervisor provides host-based security group enforcement5. Open vSwitch tags each Neutron network with VLAN6. ACI ToR translates VLAN into VXLAN, providing distributed L2 and distributed default gateway support.
Hypervisor:• Enforces
security groups
ACI Fabric Offers:• VXLAN tunnels• Distributed L2• Distributed default
gatewayOVS Plugin
Controller Node
APIC Plugin
Neutron
Neutron ACI Mapping
OpenStack ACI
Tenant Tenant
No equivalent Application Profile
Network EPG
Subnet Subnet
Security Group Handled by Host or ACI Contract
Security Group Rule Handled by Host or ACI Filter
Router Context
Network:external Outside EPG
83
GBP Architecture
Neutron Driver maps GBP to existing Neutron API and offers compatibility with any existing Neutron Plugin
Native Drivers exist for OpenDaylight as well as multiple vendors (Cisco, Nuage Networks, One Convergence, ...)
https://wiki.openstack.org/wiki/GroupBasedPolicy
Group Policy
CLI Horizon Heat
Neutron Driver
Neutron
Any Existing Plugins and ML2 Drivers
Native Driver
Neutron Port
Neutron Port
Existing Neutron APITenant
Group Policy Neutron API
Tenant
End Point Group (EPG)
End Point Group (EPG)
API to provide clear separation between Application developer and Infrastructure manager▪ Application developer doesn’t need to care about network centric resources such as Networks/Routers
etc (existing Neutron API)▪ Infrastructure Manager doesn’t need to care about application requirements such as what ports
requires to be opened for the applications
Evolving the Neutron API - GPB
85
Neutron Network Neutron Router
Neutron Network
End Point End Point End Point End Point
Contract - Set of Policy RulesSecurity Groups
Outside
Group Policy API Usage ExampleProvides “Web” Policy
“App” End Point
Group (EPG)
VM End Points
Provides “App” Policy
Consumes “App” Policy
“DB”End Point
Group (EPG)
VM End Points
Provides “DB” Policy
Consumes “DB” Policy
Consumes “Web” Policy
neutron policy-rule-create web-rule --direction ingress --protocol tcp --port 80 neutron policy-rule-create all-rule --direction ingress --protocol tcp --port all neutron policy-rule-create db-rule --direction ingress --protocol tcp --port 3306
neutron contract-create web --policy-rule web-rule neutron contract-create app --policy-rule all-rule neutron contract-create db --policy-rule db-rule
neutron endpoint-group-create DB --provide dbneutron endpoint-group-create APP --provide app --consume db neutron endpoint-group-create WEB --provide web --consume app neutron endpoint-group-create OUTSIDE --consume web
“Web” End Point
Group (EPG)
VM End Points
86
VMVM
Compute Nodes
VMVM
Compute Nodes
APIC Plugin
Cisco APIC Driver
APIC
vSwitch Driver
REST APINetwork:EPG, Router:Contract
Provides distributed L2,L3 functionality
Developing Integration with APIC Using OpenStack Neutron Group Policy API
ACI Spine/LeafSwitch
APIC
VM VM
vSwitch
Neutron Server
Neutron Core plugin (ML2)
87
Lab 7 - ACI via Group Policy
Enable Group Policy on an OpenStack system (Different than the one we've been using so far)Verify the creation of a contract and association with an endpoint on creation of a VM
Top Related