Aci 3456

BRKACI-3456
Mastering ACI and

OpenStack
Domenico Dastoli
Technical Marketing Engineer INSBU
ddastoli@cisco.com
Cisco Spark
Questions?
Use Cisco Spark to communicate
with the speaker after the session
How
1. Find this session in the Cisco Live Mobile App
2. Click “Join the Discussion”
3. Install Spark or go directly to the space
4. Enter messages/questions in the space
cs.co/ciscolivebot#BRKACI-3456
© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public
ACI connects Virtual and Physical World
BRKACI-3456 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 4
Agenda
• ACI, Virtualisation and VMM Domains
• ACI and OpenStack
• Options to Install OpenStack and ACI plugin
• Operate OpenStack: ML2 mode and GBP mode
• External Network connectivity
• Demo
• Q&A
Virtualisation and VMM Domains
ACI Anywhere - Vision
Any Workload, Any Location, Any Cloud
ACI Anywhere
Remote PoD Multi-Pod / Multi-Site Hybrid Cloud Extension
IP IP
WAN WAN
Remote Location On Premise Public Cloud
Security Everywhere Analytics Everywhere Policy Everywhere
Cisco ACI – The basics
Logical Network Provisioning of Stateless Hardware
Web App DB
QoS QoS QoS

WWW Filter Service Filter
APIC
ACI Fabric
Scale-Out Penalty Free Overlay
Hypervisor Interaction with ACI
Two modes of Operation
Non-Integrated Mode Integrated Mode
APIC APIC
WEB DB
VLAN 10 VLAN 10 VLAN 100 APP DB
• ACI Fabric as an IP-Ethernet • ACI Fabric as a Policy Authority

Transport
• Encapsulations Normalized and
• Encapsulations manually allocated dynamically provisioned
• Separate Policy domains for Physical • Integrated Policy domains across
and Virtual Physical and Virtual
Hypervisor Integration with ACI
 Relationship (VMM Domain) is
formed between APIC and Virtual
APIC Machine Manager (VMM)
 Multiple VMMs likely on a single

ACI Fabric
 There is 1:1 relationship between

a Distributed Virtual Switch and
VMM Domain
vCenter Kubernetes SCVMM OpenStack RHEV

DVS/AVE
VMM Domains & VLAN Encapsulation
16M Virtual Networks  VLAN ID only gives 4K EPGs (12 bits)
APIC
 Scale by creating pockets of 4K EPGs
 Map EPGs to VMM Domain based on

scope of live migration
 Place VM anywhere
 Live migrate within VMM domain
EP EP EP
EP
EP
EP EP
EP EP EP EP
EP EP
EP
VMM Domain 1 VMM Domain 2

4K EPGs 4K EPGs
VMM Domains & VLAN Encapsulation
16M Virtual Networks  VLAN ID only gives 4K EPGs (12 bits)
APIC
 Scale by creating pockets of 4K EPGs
 Map EPGs to VMM Domain based on

scope of live migration
VNID 6032  Place VM anywhere
 Live migrate within VMM domain
EP
EP VLAN 16
EP EP
VLAN 5
VMM Domain 1 VMM Domain 2

4K EPGs 4K EPGs
ACI and OpenStack
ACI + OpenStack – With OpFlex Support
Full Policy Based Network Automation Extended to the Hypervisor
OpenStack Controller
OpFlex for OVS
APIC Unified Plugin
• Open Source OpFlex agent extends ACI into the host
APIC • OpFlex Proxy exposes new open API in ACI fabric
OpFlex Proxy
OS nodes OVS OpFlex Agent
Solutions with Major OpenStack Distributions
Why Cisco ACI and OpenStack?
Distributed, Scalable Hardware-Accelerated
Virtual Networking Performance
• Full Neutron Node datapath replace • Automatic VXLAN tunnels at top of

• Fully distributed Layer 2, anycast rack (ToR)
gateway, DHCP, and metadata • No wasted CPU cycles for tunneling
• Distributed NAT and floating • Optional use of SRIOV
IP address
Integrated Overlay Operations and

and Underlay Telemetry
• Fully managed underlay network • Troubleshooting across physical and

through Cisco® APIC virtual environments
• Capability to connect physical servers • Health scores and capacity planning
and multiple hypervisors to overlay per tenant network
networks
What is the ACI Unified Plugin for OpenStack?
Neutron ML2
The Modular Layer 2 (ml2) plugin is a framework allowing OpenStack Networking to simultaneously utilize
the variety of layer 2 networking technologies.
Drivers within ml2 implement separately extensible sets of network types and of mechanisms for
accessing networks of those types.
• Type Drivers Neutron Server

Each available network type is managed by an ml2 TypeDriver.
TypeDrivers maintain any needed type-specific network state, and
perform provider network validation and tenant network allocation.
The ml2 plugin currently includes drivers for the local, flat, vlan, gre,
ML2 Plug-in API Extensions
opflex and vxlan network types.
• Mechanism Drivers Type Manager Mechanism Manager

Each networking mechanism is managed by an ml2
MechanismDriver. The MechanismDriver is responsible for taking the
TypeDriver
TypeDriver
TypeDriver
TypeDriver
Population
Microsoft
SR-IOV
Hyper-V
vSwitch
Layer 2
Nexus
VXLAN
information established by the TypeDriver and ensuring that it is
OpFlex
Bridge
Cisco
Cisco
VLAN
APIC
Open
Linux
GRE
properly applied given the specific networking mechanisms that have
been enabled.
ACI ML2 Mechanism Driver
When running the ACI integration, The following
Type and Mechanism Drivers will be used:
• Type Drivers Neutron Server

opflex
• Mechanism Drivers
apic_aim
ML2 Plug-in
API Extensions
Type Manager Mechanism Manager
Linux Bridge
TypeDriver
TypeDriver
TypeDriver
TypeDriver
Population
apic_aim
Microsoft
Hyper-V
SR-IOV
vSwitch
Layer 2
OpFlex
VXLAN
Nexus
VLAN
Cisco
Cisco
Open
GRE
APIC ML2 options
• Opflex mode allows creation of neutron networks based on

• VLAN
• VXLAN
• APIC AIM Mechanism driver enables the user to deploy OpenStack projects in:
• Neutron standard ML2 mode
• Group Based Policy (GBP) mode
ML2 vs GBP mode
ML2 – APIC Mapping
• With the ML2 Neutron Object APIC Object
Standard Neutron
Project Tenant
model, the
following mapping Network EPG + BD
happens.
Subnet Subnet
• All the operations
are done on Router Contract
OpenStack through
Horizon, CLI or Security Group + Rule N/A
Iptables rules maintained per host
Heat
ACI Tenant Creation with ML2 model
GBP – APIC Mapping
• With the GBP Model GBP Object APIC Object
the following mapping
Project Tenant
happens.
L3 Policy VRF
• GBP offers much more
granularity and L2 Policy Bridge Domain + Subnet
flexibility compare to
standard neutron. Policy Group Endpoint Group
• GBP comes with CLI, Policy Ruleset Contract

Heat and Horizon
plugins
ACI Tenant Creation with GBP model
GBP Policy Mapping
VRF
EPG Bridge Domain

DHCP
subnet
dhcp EPG EPG

server
WEB DB
EPG
APP
GBP Policy Mapping
GBP L3 Policy
VRF
EPG Bridge Domain

DHCP
subnet
dhcp EPG EPG

server
WEB DB
EPG
APP
GBP Policy Mapping
VRF
GBP L2
Policy
EPG Bridge Domain
DHCP
subnet
dhcp EPG EPG

server
WEB DB
EPG
APP
GBP Policy Mapping
VRF
EPG Bridge Domain

DHCP
subnet
GBP
dhcp EPG EPG Policy Groups
server
WEB DB
EPG
APP
GBP Policy Mapping
VRF
EPG Bridge Domain

DHCP
subnet
dhcp EPG EPG

server
WEB DB
EPG
APP
ML2 vs GBP model – what is best?
• GBP:
• Application Centric
• Security groups are created as ACI contracts AND OVS rules. So they are
visible on ACI and will be enforced both in HW (ACI leaf) and SW (OVS).
• Introduces new REST APIs: if any existing templates, you will need to adapt
• ML2:
• Network Centric
• Standard way of creating neutron networks
• REST API will not change: any heat or CLI template will keep working
• Security Groups not visible in ACI: they are implemented by OS as OVS rules
What are the components and how do they work?
[heat-admin@overcloud-controller-0 ~]$ sudo yum list | grep @aci-repo
aci-integration-module.noarch 0.6.0-162.el7 @aci-repo
agent-ovs.x86_64 1:1.5.0-63.el7.centos @aci-repo
apicapi.noarch 1.1.0-170.el7 @aci-repo
neutron-opflex-agent.noarch 2:6.1.0-26.el7 @aci-repo
openstack-dashboard-gbp.noarch 6.0.0-53.el7 @aci-repo
What’s installed on openstack-heat-gbp.noarch 6.0.0-53.el7
openstack-neutron-gbp.noarch 6.2.0-53.el7
@aci-repo
@aci-repo
[heat-admin@overcloud-controller-0 ~]$
the controller and
compute node? controller
[heat-admin@overcloud-compute-0 ~]$ sudo yum list | grep @aci-repo

agent-ovs.x86_64 1:1.5.0-63.el7.centos @aci-repo
neutron-opflex-agent.noarch 2:6.1.0-26.el7 @aci-repo
openstack-neutron-gbp.noarch 6.2.0-53.el7 @aci-repo
[heat-admin@overcloud-compute-0 ~]$
compute
A new component:
A key ACI Integration Module
component: The AIM daemon is running on the
Controller nodes and is responsible to
configure ACI through REST API call
based on the OpenStack policy model
AIM Daemon defined.
Architecture: APIC Integration Manager
Description
• APIC Integration Database and APIC Integration

Netwo
Router
Security Policy Rule Policy Manager (AIM) introduced as central point of
rk Group Group Set Group
storing plugin configuration.
• AIM uses the OpenStack database.
Group-Based OpenStack
• AIM continuously synchronizes with APIC using
Policy Controller APIC Integration Daemon (AID).
AID
processes Neutron API
• Group-Based Policies are mapped into Neutron API
APIC Unified Plugin
and then AIM. Neutron APIs are mapped to AIM
APIC Integration Database (AIM) directly.
The AIM Daemon at work: the workflow
Application Network Profile
EPG EPG
3 EPG DB
C1 WEB C2 APP
APIC Create Application Policy
ACI
5
Fabric
2 Push Policy
Automatically Push
Network Profiles to
APIC and keep it
sync
Create Network, Subnet,

Security Groups, Policy NETWORK ROUTING SECURITY
AIM
1
OPEN VIRTUAL SWITCH OPEN VIRTUAL SWITCH OPEN VIRTUAL SWITCH
NEUTRON NOVA
4 Web App Web App DB Web Web DB
OpenStack Tenant
Instantiate VMs
HYPERVISOR HYPERVISOR HYPERVISOR
Neutron Opflex Agent
The Neutron Opflex Agent runs on both
the compute and the controller. It is
Neutron Opflex responsible to communicate with the
neutron server.
Agent
Agent OVS
The Agent OVS runs on the compute
and controller nodes. It is responsible to
communicate with the OVS and the leaf
node to register to ACI fabric.
Agent OVS
OpFlex Architecture
Neutron Server(s) • Neutron-opFlex-agent:

Receives updates from Neutron
Endpoint
Information: about new endpoints and
RabbitMQ OpFlex policy
(ACI infra VLAN) updates EP and Service files
OpenStack
Node
• Agent-OVS: Runs OpFlex

Neutron- OpenFlow Open protocol with ACI leaf proxy.
Agent-
Opflex- vSwitch
OVS
Agent
• Agent-OVS Programs open

Endpoint
Files vswitch via OpenFlow
What is the Endpoint file?
For each VM, the Neutron

Opflex Agent creates a .ep file
local to the node with all the
information of the VM.
Routing settings
VM IP address
Network Policy including

floating IP if any assigned
VM name
Closer look to the enhancement with the ACI plugin
Distributed, Scalable Hardware-Accelerated
Virtual Networking Performance
• Full Neutron Node datapath replace • Automatic VXLAN tunnels at top of

• Fully distributed Layer 2, anycast rack (ToR)
gateway, DHCP, and metadata • No wasted CPU cycles for tunneling
• Distributed NAT and floating • Optional use of SRIOV
IP address
Integrated Overlay Operations and

and Underlay Telemetry
• Fully managed underlay network • Troubleshooting across physical and

through Cisco® APIC virtual environments
• Capability to connect physical servers • Health scores and capacity planning
and multiple hypervisors to overlay per tenant network
networks
Routing and Policy Enforcement is done on the host
Tenant Networks DESCRIPTION
• Traditionally in OpenStack the

routing is done on the servers
Compute
hosting neutron services only.
Host
Neutron Server(s)
• With ACI integration the opflex-
agent is taking care of the
Neutron Endpoint routing of the VMs. Since each
L3 File
Agent
compute node has a opflex-
Agent- OpenFlow OVS
agent, the routing is done in a
OVS
distributed manner.
• Also, the opflex-agent performs

local policy enforcement through
Management/API Network OVS rules locally on the same
hypervisor where the instance
lives.
DHCP Function
Tenant Networks
DESCRIPTION
• Traditionally VMs are

getting IP from Neutron
Compute
Host DHCP Server
Neutron Server(s)
DHCP • Agent-OVS learns info of

Endpoint DORA the VM from Endpoint
File
Neutron Files
DHCP
DNSmasq neutron- Agent-
Agent
opflex-agent OVS • Agent-OVS responds to
the VMs with DHCP
DHCP Allocation and Options responses
Management/API Network • DHCP allocation and

options passed back to
Neutron server.
Metadata Function
Tenant Networks
DESCRIPTION
• Traditionally in OS VMs
Nova get the meatadata
Compute
OpenStack Controller Host
information from the
VM
service running on
Service
Meta-data Neutron Server
File
Nova-API neutron- neutron- • Neutron metadata agent is

Metadata opflex- Agent metadata
Service agent -OVS -agent reading the Service File
• Metadata agent locally

VM Metadata
performs proxy
Management/API Network
• Metadata agent updates
the neutron server with
VM Metadata
NAT Function performed in the OVS locally
ACI Fabric External Router DESCRIPTION
Link Subnet IP: With IP routes to:
L3-Out VRF SNAT: 10.1.2.0/24
10.1.1.2/30
Floating: 10.1.3.0/24
Tenant VRFs RID: 7.7.7.7 • Floating IP configured by
OpenStack Neutron using
standard mechanism
• OVS performs NAT
Link Subnet IP:
10.1.1.1/30 function using OpenFlow
rules from OpFlex agent
Non-NAT NAT/ for Floating IP
Tenant External
Traffic Traffic
SNAT Subnet IP:
Open vSwitch 10.1.2.1/24
w/Local NAT Floating Subnet IP:
10.1.3.1/24
Compute Node
About the OpenStack Infrastructure network
Required connectivity for hosts
• Typically there will be a number of
networks required for OpenStack:
• Internal API Network (VLAN)
• Storage Network (VLAN)
• Storage Management Network (VLAN)
• Provisioning Network (Native VLAN)
• External Network (VLAN)
Note:
Controller node requires connectivity to the
APIC controller. External Network can be used
for this purpose.
Physical connectivity with ACI
OpenStack node will need:
• At least two NICs per server configured as bond interface (for
redundancy)
• One NIC for provisioning network
ACI Configuration for OpenStack Node connectivity
To provide connectivity between hosts, it is required to pre provision a tenant

on ACI with the appropriate configuration.
This tenant could be either dedicated to the OpenStack infrastructure, or it
could be shared with other infrastructure hosts.
Note that this infrastructure tenant will provide the underlay connectivity for
the host, therefore it will be updated only if necessary to modify the
OpenStack node connectivity (i.e. adding a node).
ACI OpenStack Infrastructure tenant
Tenant: OpenStack_Infra
VRF: Main_VRF
BD_MGMT BD_OpenStack_Infra
L3 unicast enabled L3 Unicast Enabled
Default GW IP defined Limit IP Learning to Subnet: Disabled
EPG-ExternalNet EPG-InternalApi EPG-StorageNet EPG-StorageMgmt EPG-Provisioning

VLAN104 VLAN105 VLAN106 VLAN107 Native-VLAN
- Two BDs:
- BD_MGMT provides OOB connectivity (in this design this provides connectivity both
Internet and APIC)
- BD_OSP is only switching but we keep L3 enabled to learn IP from the hosts
- EPGs have static bindings to the interfaces of the host
EPG Static binding
bond0
EPG- EPG- EPG- EPG- EPG-

Provisioning InternalApi StorageNet StorMgmt External
Native VLAN105 VLAN106 VLAN107 VLAN104
OpenStack nodes will have NIC interfaces statically bound to ACI End Point Group.
On ACI side an individual interface will be configured for Provisioning network. The bond interfaces of
the host will be connected to a VPC pair on ACI leaf switches.
OpenStack Infrastructure Tenant
• Define the EPG and the specific static binding for
each network required:
• ExternalNet
• InternalAPI
• StorageMgmt
• StorageNet
OpenStack Tenant Network (VM datapath)
OpenStack Tenant Network
• Neutron provides each tenant with their own networks using either VLAN
segregation (where each tenant network is a network VLAN), or tunneling
(through VXLAN). Network traffic is isolated within each tenant network. Each
tenant network has an IP subnet associated with it, and network namespaces
means that multiple tenant networks can use the same address range without
causing conflicts.
• ACI Plugin allows to use as encapsulation

mode:
• VLAN
• VXLAN
OpenStack Tenant Network with ACI with VLAN
• In VLAN encapsulation mode:
• The user will define a pool of VLAN (VMM Domain Pool)
• Each OpenStack project network will automatically pick one VLAN from the pool
• The ACI Access policy of the Leaf ports will allow all the VLANs defined in the VLAN
pool
bond0 The bond0 could be the same

interface used for the OpenStack
VLAN infra traffic.
trunk
VMM Domain Pool: 200-300 However this could be also a

dedicated bond for tenant traffic.
Tenant1 Tenant1 Tenant2 Tenant3
net1 net2 net1 Net1
VLAN 200 VLAN 201 VLAN 220 VLAN 230
OpenStack Tenant Network with ACI with VLAN: Scalability
• If you need to scale more than 4k VLANs:
1. You can use VXLAN
2. You can create multiple VMM domain and assign nodes to those:
Allows you to use multiple VMM Domains with potentially overlapping VLAN pool ranges in a
single OpenStack deployment
Compute-1 Compute-2
bond0 bond0
VLAN trunk VLAN trunk
VMM Domain1 Pool: 200-300
VMM Domain2 Pool: 200-300
OpenStack Tenant Network with ACI with VXLAN
• In VXLAN encapsulation mode:
• The ACI Access policy of the Leaf ports will allow the ACI Infra VLAN.
• Each OpenStack project network will automatically pick one VXLAN
• The VXLAN will be encapsulated into a tunnel using the ACI infra VLAN
bond0
The bond0 could be the same interface

VXLAN are encapsulated into tunnel used for the OpenStack infra traffic or could
using ACI Infra VLAN be a dedicated bond for tenant traffic.
For better performance, server NICs should

be capable of VXLAN offload
VMM Domain: VXLAN
Blade systems are not supported with
Tenant1 Tenant1 Tenant2 Tenant3
net1 net2 net1 Net1 VXLAN encapsulation
VXLAN 200 VXLAN 201 VXLAN 220 VXLAN 230
What if you want to provision VLAN to 3rd party?
Hierarchical port binding (HPB)
ACI Leaf
Switch Hierarchical Port Binding allows to
create different network types:
non-opflex opflex main segment • Opflex networks would be

using local vlan segment (VLAN or VXLAN) created onto ACI
• vlan or other network types can
3rd party opflex
be created to bind special 3rd
party agent or mech driver asks
for vlan port binding
Compute Host
SR-IOV support with ACI
OpenStack Controller
Group-Based Policy ML2
Another use case for HPB is SR-
IOV enabled hosts:
• GBP or ML2 options
• GBP – Reintroduces security
policies via groups / rulesets in
the fabric
• Can mix opflex and SR-IOV on
VLANs
the same physnet
NIC NIC
SRIOV SRIOV
VNF VNF VNF VNF VNF
IPv6 Dual Stack
• Many OpenStack customers are interested
connecting VMs to both IPv4 and IPv6
networks
• This feature adds support in the ACI

OpenStack plugins for dual stack operation
• OpenStack neutron address scopes are

automatically mapped to ACI VRFs
• Each IPv4 address scope maps to a unique

VRF in ACI. A IPv6 address scope may
include multiple IPv4 address scopes will be
provisioned on these VRFs
Installation of OpenStack
OpenStack Support
• Cisco is committed to provide support to the main OpenStack distributions:
• Other distributions is supported with specific agreements with the 3rd party
vendor, i.e.
Installation of OpenStack and ACI Plugin
• On Cisco.com:
• https://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-
infrastructure-controller-apic/tsd-products-support-series-
home.html#OpenStack_Installation_Guides
• Manual installation:
• Prone to errors and discouraged. Moving forward we will limit the support for production
environments while documentation will be always provided.
• RHEL OSP Director – full support for automated installation and upgrade
• Canonical Juju Charms – full support for automated installation and upgrade
Operate OpenStack
ML2 model
ML2 – APIC Mapping
• With the ML2 Neutron Object APIC Object
Standard Neutron
Project Tenant
model, the
following mapping Network EPG + BD
happens.
Subnet Subnet
• All the operations
are done on Router Contract
OpenStack through
Horizon, CLI or Security Group + Rule N/A
Heat Iptables rules maintained per host
Create a new OpenStack project:
[stack@dom-undercloud ~]$ openstack project create --description "tenant Cisco Live Europe
Barcelona" CiscoLive
+-------------+------------------------------------+
| Field | Value |
+-------------+------------------------------------+
| description | tenant Cisco Live Europe Barcelona |
| enabled | True |
| id | 97390b780c7545d393d9314d34e69cfa |
| name | CiscoLive |
+-------------+------------------------------------+
[stack@dom-undercloud ~]$ openstack role add --project CiscoLive --user admin admin
+-----------+----------------------------------+
| Field | Value |
+-----------+----------------------------------+
| domain_id | None |
| id | cd3c4088da8d40778e93efc2d8d8ce6c |
| name | admin |
+-----------+----------------------------------+
[stack@dom-undercloud ~]$
Create a new OpenStack network:
[stack@dom-undercloud ~]$ openstack network create net101
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | UP |
| dns_domain | None |
| id | 96c4644f-a63a-4b15-b36f-b00dfe71bc38 |
| is_default | None |
| name | net101 |
| port_security_enabled | True |
| project_id | 97390b780c7545d393d9314d34e69cfa |
| provider:network_type | opflex |
| provider:physical_network | physnet1 |
| provider:segmentation_id | None |
| qos_policy_id | None |
| revision_number | 3 |
| router:external | Internal |
| segments | None |
| shared | False |
| status | ACTIVE |
| subnets | |
+---------------------------+--------------------------------------+
Attach a subnet to the network
[stack@dom-undercloud ~]$ openstack subnet create --network net101 --gateway 192.168.200.254 --subnet-range
192.168.200.0/24 subnet101
+-------------------+--------------------------------------+
| Field | Value |
+-------------------+--------------------------------------+
| allocation_pools | 192.168.200.1-192.168.200.253 |
| cidr | 192.168.200.0/24 |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.200.254 |
| host_routes | |
| id | 96c4644f-a63a-4b15-b36f-b00dfe71bc38 |
| ip_version | 4 |
| name | subnet101 |
| network_id | f816ceaa-af05-47ce-83b9-f06dc5ed9f5b |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
+-------------------+--------------------------------------+
What happens on ACI
• A new Tenant is created and a new EPG
and unicast disabled BD is created
• Unicast routing will stay disabled until a
router is created in OS
• The BD is attached to a generic unrouted
VRF created in common tenant
Add a router and attach the subnet to it
[stack@dom-undercloud ~]$ openstack router create CLrouter
+-------------------------+--------------------------------------+
| Field | Value |
+-------------------------+--------------------------------------+
| admin_state_up | UP |
| availability_zone_hints | None |
| availability_zones | None |
| description | |
| distributed | False |
| external_gateway_info | None |
| flavor_id | None |
| ha | False |
| id | 0cbf9e21-f6f9-40c2-9c98-6f04a0ff6268 |
| name | CLrouter |
| revision_number | None |
| routes | |
| status | ACTIVE |
+-------------------------+--------------------------------------+
[stack@dom-undercloud ~]$ openstack router add subnet CLrouter subnet101
Security Groups with ML2 model
• In ML2 policy mode the router created corresponds to a permit any contract
in ACI.
• Security groups are defined in OpenStack and controlled there.
• They will be reflected in policy defined in OVS rules.
GBP model
GBP – APIC Mapping
• With the GBP Model GBP Object APIC Object
the following mapping
Project Tenant
happens.
L3 Policy VRF
• GBP offers much more
granularity and L2 Policy Bridge Domain
flexibility compare to Policy Group Endpoint Group
standard neutron.
Policy Ruleset Contract
• GBP comes with CLI,
Heat and Horizon
plugins
Create a new GBP VRF:
This pool is where I’ll be taking my tenant
subnets from during network creation.
[stack@dom-undercloud ~]$ gbp l3p-create Main_VRF --ip-pool

192.168.0.0/16 --subnet-prefix-length 24
Created a new l3_policy:
+----------------------------+--------------------------------------+
| Field | Value |
+----------------------------+--------------------------------------+
| address_scope_v4_id | 059fed59-1f07-4907-bece-8f260cb0bb86 |
| address_scope_v6_id | |
| id | b7b638f7-7fbd-4594-9ef8-4a560961a26c |
| ip_pool | 192.168.0.0/16 |
| ip_version | 4 |
| l2_policies | |
| name | Main_VRF |
| proxy_ip_pool | 192.168.0.0/16 |
| proxy_subnet_prefix_length | 28 |
| routers | ac49f46d-f08e-4fe2-9016-35b81dc56942 |
| shared | False |
| status | BUILD |
| status_details | |
| subnet_prefix_length | 24 |
| subnetpools_v4 | d68b01f2-992b-4743-8dbf-a7f3a8c00313 |
| subnetpools_v6 | |
| tenant_id | 5b8945dba07a43e0b32efea4f1bc3fdf |
+----------------------------+--------------------------------------+
Create a new GBP L2 Policy (Bridge Domain):
[stack@dom-undercloud ~]$ gbp l2policy-create --l3-policy Main_VRF l2pnet101

Created a new l2_policy:
+----------------------+--------------------------------------+
| Field | Value |
+----------------------+--------------------------------------+
| description | |
| id | 6c905c23-a4b7-4960-8959-6b8d16088ce3 |
| inject_default_route | True |
| l3_policy_id | b7b638f7-7fbd-4594-9ef8-4a560961a26c |
| name | l2pnet101 |
| network_id | eb2269dc-4e43-44f8-a96a-7b060d942d98 |
| policy_target_groups | autof6c8bb08ac721e02feae6f27a57a1444 |
| project_id | 5b8945dba07a43e0b32efea4f1bc3fdf |
| shared | False | This EPG contains
| status | ACTIVE | DHCP instance for
| tenant_id | 5b8945dba07a43e0b32efea4f1bc3fdf | the L2 policy.
+----------------------+--------------------------------------+
The subnet is
carved out from the
VRF /16 defined
before
Create GBP groups (ACI EPGs):
[stack@dom-undercloud ~]$ gbp group-create epg101 --l2-policy l2pnet101
I can add more EPG, both in the same Bridge Domain, or

in others:
[stack@dom-undercloud ~]$ gbp l2policy-create --l3-policy Main_VRF l2pnet102

In order to allow communication, I need to create policy
actions, classifiers, rules and rulesets within GBP.
GBP ACI
Policy Classifier Filter Entry
Policy Rule Filter
Policy Ruleset Contract
First, create a Policy Action to define the behaviour:
[stack@dom-undercloud ~]$ gbp policy-action-create allow --action-type allow

Created a new policy_action:
+--------------+--------------------------------------+
| Field | Value |
+--------------+--------------------------------------+
| action_type | allow |
| action_value | |
| description | |
| id | c9333baf-aa23-4a32-806c-11d1e16eabeb |
| name | allow |
| shared | False |
+--------------+--------------------------------------+
Then define a Policy Classifier:
[stack@dom-undercloud ~]$ gbp policy-classifier-create icmp-traffic --protocol icmp --direction bi

Created a new policy_classifier:
+-------------+--------------------------------------+
| Field | Value |
+-------------+--------------------------------------+
| description | |
| direction | bi |
| id | 5947db25-6c2e-4091-b012-ea1b86a0fb53 |
| name | icmp-traffic |
| port_range | |
| protocol | icmp |
| shared | False |
+-------------+--------------------------------------+
Next, define a Policy Rule, referencing the classifier
created in the last step:
[stack@dom-undercloud ~]$ gbp policy-rule-create ping-policy-rule --classifier icmp-traffic --actions allow
Created a new policy_rule:
+--------------------------+------------------------------------------------------------------------------------------+
| Field | Value |
+--------------------------+------------------------------------------------------------------------------------------+
| apic:distinguished_names | {"Forward-FilterEntries": ["uni/tn-common/flt-pr_3ecd614d-717b-483c-8e5c-c5f335d40a88/e |
| | -os-entry-0"], "Reverse-FilterEntries": ["uni/tn-common/flt-reverse-pr_3ecd614d-717b- |
| | 483c-8e5c-c5f335d40a88/e-os-entry-1", "uni/tn-common/flt-reverse-pr_3ecd614d-717b-483c- |
| | 8e5c-c5f335d40a88/e-os-entry-2", "uni/tn-common/flt-reverse-pr_3ecd614d-717b-483c-8e5c- |
| | c5f335d40a88/e-os-entry-3", "uni/tn-common/flt-reverse-pr_3ecd614d-717b-483c-8e5c- |
| | c5f335d40a88/e-os-entry-4"]} |
| description | |
| enabled | True |
| id | 3ecd614d-717b-483c-8e5c-c5f335d40a88 |
| name | ping-policy-rule |
| policy_actions | 2070e9ff-4de9-46ea-a81e-772906982adf |
| policy_classifier_id | 88c8e3c0-d9c5-4e6b-9992-a56b539e0b98 |
| project_id | 5b8945dba07a43e0b32efea4f1bc3fdf |
| shared | False |
| status | BUILD |
+--------------------------+------------------------------------------------------------------------------------------+
© 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 102
Now define a Policy Ruleset to tie everything together:
[stack@dom-undercloud ~]$ gbp policy-rule-set-create icmp-policy-rule-set --policy-rules ping-policy-rule
Created a new policy_rule_set:
+------------------------+--------------------------------------+
| Field | Value |
+------------------------+--------------------------------------+
| child_policy_rule_sets | |
| description | |
| id | 29c3654d-6c9f-446b-8461-62eea3f6c050 |
| name | icmp-policy-rule-set |
| parent_id | |
| policy_rules | 9be64bdb-1d86-4577-bd3f-0bad2e9c0758 |
| shared | False |
| tenant_id | 5ab060d7c812478b904203d7901c1356 |
+------------------------+--------------------------------------+
Let’s now apply these rules to our EPGs:
[stack@dom-undercloud ~]$ gbp group-update epg101 --provided-policy-rule-sets "icmp-policy-rule-set=true"
Updated policy_target_group: epg101
[stack@dom-undercloud ~]$ gbp group-update epg102 --consumed-policy-rule-sets "icmp-policy-rule-set=true"

Updated policy_target_group: epg102
We can now ping between the two networks!
ACI Fabric
Contract
epg101 EPG Epg102 EPG
Inter host enforcement is

done on ACI leaf switches.
epg101 Compute epg102

Compute epg102
Node1 Node2
OVS rules do the routing and

enforcement on the host
External Network
External Connectivity
• Connectivity for a tenant can be either shared or dedicated.
• A shared external network is visible by all OpenStack projects.
• A dedicated connectivity for the OpenStack project.
• It would be possible to have a mixed environment both with shared and

dedicated external connectivity.
Tenant Pasta&Co Tenant Pizza&Co Tenant Pasta&Co Tenant Pizza&Co
net1 net2 net3 net4 net1 net2 net3 net4
Dediacated Dediacated
Shared L3 out
L3 out L3 out
WWW WWW WWW
Physical Layout
APIC
• L3out is defined L3Out

on ACI.
OSPF/
BGP/
• The external static
router is defined
Controller Compute1 Compute2
with a dynamic
or static protocol
How to create the L3out on ACI
• Although the OpenStack plugin could create automatically an L3out on ACI, the
best practice is to create it manually
• Defining manually an L3out supports all the L3out features:
• VPC
• Dynamic routing protocols
• Route engineering
• Etc.
• The L3out can be created with XML templates or in any ways you are familiar
with.
• Once the L3out is available, ACI AIM plugin on OpenStack can import it and
start controlling the L3out.
Dedicated Tenant External Network
Creation of the L3out Dedicated
• A dedicated L3out must be created in the
OpenStack created tenant.
• In the L3out creation, it must be specified:
• Interfaces and their IP information
• Dynamic routing if any
• External EPG
• You should NOT add any contract as they

will be added later automatically by the
plugin.
• If you require SNAT or FIP, the L3 out
must be defined in a different VRF from the
one created by OpenStack!
Query ACI for external networks
[heat-admin@overcloud-controller-0 ~]$ aimctl manager external-network-find

+--------------------------------------+-------------------+--------+
| tenant_name | l3out_name | name |
|--------------------------------------+-------------------+--------|
| common | l3out1 | extEpg |
| prj_4ec99ec19a0f4f00808f18d82d7032af | l3out1-DefaultVRF | extEpg |
| prj_5d0431309d5d45a1836dfa0a8beb6ef0 | l3out1-DefaultVRF | extEpg |
| prj_97390b780c7545d393d9314d34e69cfa | externalNet | extEpg |
+--------------------------------------+-------------------+--------+
• Through the ACI Integration Module (AIM) controller, it is possible to query ACI
for the existing and available external networks.
Import External Networks from ACI to OpenStack
[heat-admin@overcloud-controller-0 ~]$ aimctl manager external-network-get
prj_97390b780c7545d393d9314d34e69cfa externalNet extEpg
+-------------------------+--------------------------------------------------------------------------+
| Property | Value |
|-------------------------+--------------------------------------------------------------------------|
| tenant_name | prj_97390b780c7545d393d9314d34e69cfa |
| l3out_name | externalNet |
| name | extEpg |
| monitored | True |
| consumed_contract_names | [] |
| provided_contract_names | [] |
| dn | uni/tn-prj_97390b780c7545d393d9314d34e69cfa/out-externalNet/instP-extEpg |
+-------------------------+--------------------------------------------------------------------------+
+---------------+-----------------------------------------+
|---------------+-----------------------------------------|
| resource_type | ExternalNetwork |
| resource_root | tn-prj_97390b780c7545d393d9314d34e69cfa |
| sync_status | synced |
| health_score | 100 |
| id | 3e368bc8-e83d-4c8a-b269-6c7873464def |
+---------------+-----------------------------------------+
• AIM controller manager will import the external network
Create OpenStack External Network
[stack@dom-undercloud ~]$ neutron net-create external-net-CL --router:external --apic:distinguished_names type=dict
ExternalNetwork=uni/tn-prj_97390b780c7545d393d9314d34e69cfa/out-externalNet/instP-extEpg
+----------------------------+----------------------------------------------------------------------------------------+
| Field | Value |
+----------------------------+----------------------------------------------------------------------------------------+
| admin_state_up | True |
| apic:distinguished_names | {"ExternalNetwork": "uni/tn-prj_97390b780c7545d393d9314d34e69cfa/out-externalNet |
| | /instP-extEpg", "BridgeDomain": "uni/tn-prj_97390b780c7545d393d9314d34e69cfa/BD-EXT- |
| | externalNet", "VRF": "uni/tn-prj_97390b780c7545d393d9314d34e69cfa/ctx-DefaultVRF", |
| | "EndpointGroup": "uni/tn-prj_97390b780c7545d393d9314d34e69cfa/ap-OpenStack/epg-EXT- |
| | externalNet"} |
| apic:nat_type | distributed |
| apic:synchronization_state | synced |
| id | f085fe67-42e1-4b3c-8951-e5d9932222ca |
| is_default | False |
| name | external-net-CL |
| port_security_enabled | True
Creating neutron external network |
| provider:network_type | opflex bound to the L3out imported with |
| provider:physical_network | physnet1 the aimctl manager. |
| provider:segmentation_id | |
| router:external | True |
| shared | False |
| status | ACTIVE |
| subnets | |
+----------------------------+----------------------------------------------------------------------------------------+
External SNAT or Floating IP Pool Definition
[stack@dom-undercloud ~]$ neutron subnet-create external-net-CL 10.104.21.0/24 --name ext-subnet --disable-dhcp
--gateway 10.104.21.1 --apic:snat_host_pool True
Created a new subnet:
+----------------------------+--------------------------------------------------+
| Field | Value |
+----------------------------+--------------------------------------------------+
| allocation_pools | {"start": "10.104.21.2", "end": "10.104.21.254"} |
| apic:distinguished_names | {} |
| apic:snat_host_pool | True |
| apic:synchronization_state | N/A |
| cidr | 10.104.21.0/24 |
| dns_nameservers | | Creating neutron external
| enable_dhcp | False | network SNAT pool and
| gateway_ip | 10.104.21.1 |
| host_routes | |
attaching the router to the
| id | 5344832d-dd03-40d7-a4d2-3f04c86fbb9d | external net.
| ip_version | 4 |
| ipv6_address_mode | |
| ipv6_ra_mode | |
| name | ext-subnet |
| network_id | f085fe67-42e1-4b3c-8951-e5d9932222ca |
| service_types | |
| subnetpool_id | |
| tenant_id | 97390b780c7545d393d9314d34e69cfa |
+----------------------------+--------------------------------------------------+
[stack@dom-undercloud ~]$ openstack router set --external-gateway external-net-CL CLrouter
SNAT Pool
Each Hypervisor will be assigned with one IP from the pool and the VMs will be NATted with the IP of the
hypervisor.
The External network in ACI
3. The NATted IP
in ACI is
represented by
the external EPG 2. OVS applies
NAT rules
4. Traffic is sent
to external router 1. VM traffic
through ACI reaches OVS
The External Network EPG will be created in the tenant itself.

A contract to allow connectivity between the EPG and the L3out will
be created automatically.
Shared Tenant External Network
Create L3 out on ACI – Shared
• The shared external network must be
defined in the Common tenant in ACI
Same as before, you use the aimctl manager to import the external network
[heat-admin@overcloud-controller-0 ~]$ aimctl manager external-network-find

+--------------------------------------+--------------+--------+
| tenant_name | l3out_name | name |
|--------------------------------------+--------------+--------|
| common | l3out1 | extEpg |
| prj_11fa0c41388f4d3fbf3f2f6d6184f687 | externalNet | extEpg |
+--------------------------------------+--------------+--------+
[heat-admin@overcloud-controller-0 ~]$ aimctl manager external-network-get common l3out1 extEpg
+-------------------------+---------------------------------------+
|-------------------------+---------------------------------------|
| tenant_name | common |
| l3out_name | l3out1 |
| name | extEpg |
| nat_epg_dn | |
| display_name | |
| monitored | True |
| consumed_contract_names | [] |
| provided_contract_names | [] |
| dn | uni/tn-common/out-l3out1/instP-extEpg |
+-------------------------+---------------------------------------+
[heat-admin@overcloud-controller-0 ~]$
External Network
[stack@dom-undercloud ~]$ neutron net-create external-net-CL --router:external --shared --apic:distinguished_names
type=dict ExternalNetwork=uni/tn-common/out-l3out1/instP-extEpg
+----------------------------+----------------------------------------------------------------------------------------+
| Field | Value |
+----------------------------+----------------------------------------------------------------------------------------+
| admin_state_up | True |
| apic:distinguished_names | {"ExternalNetwork": "uni/tn-common/out-l3out1/instP-extEpg", "BridgeDomain": "uni/tn- |
| | common/BD-osp11_s2_EXT-l3out1", "VRF": "uni/tn-common/ctx-external_vrf", |
| | "EndpointGroup": "uni/tn-common/ap-osp11_s2_OpenStack/epg-EXT-l3out1"} |
| apic:external_cidrs | 0.0.0.0/0 |
| apic:nat_type | distributed |
| apic:synchronization_state | synced |
| availability_zone_hints | |
| availability_zones | |
| id | b90bfad9-4ed3-477f-996a-4222ae0768dd |
| is_default | False |
| name | external-net-CL Creating neutron external network |
| port_security_enabled | True |
| project_id | 11fa0c41388f4d3fbf3f2f6d6184f687
bound to the L3out imported with |
| provider:network_type | opflex the aimctl manager. |
| provider:physical_network | physnet1 |
| provider:segmentation_id | |
| router:external | True |
| shared | True |
| status | ACTIVE |
| subnets | |
+----------------------------+----------------------------------------------------------------------------------------+
External SNAT or Floating pool definition
[stack@dom-undercloud ~]$ neutron subnet-create external-net-CL 10.104.21.0/24 --name ext-subnet --disable-dhcp
--gateway 10.104.21.1 --apic:snat_host_pool True
Created a new subnet:
+----------------------------+--------------------------------------------------+
| Field | Value |
+----------------------------+--------------------------------------------------+
| apic:distinguished_names | {} |
| apic:snat_host_pool | True | Creating neutron external
| apic:synchronization_state | N/A | network SNAT pool and
| cidr | 10.104.21.0/24 |
| dns_nameservers | |
attaching the router to the
| enable_dhcp | False | exterlan net. Same way as
| gateway_ip | 10.104.21.1 | before with dedicated
| host_routes | |
| id | 5344832d-dd03-40d7-a4d2-3f04c86fbb9d | network.
| ip_version | 4 |
| ipv6_address_mode | |
| ipv6_ra_mode | |
| name | ext-subnet |
| network_id | f085fe67-42e1-4b3c-8951-e5d9932222ca |
| service_types | |
| subnetpool_id | |
| tenant_id | 97390b780c7545d393d9314d34e69cfa |
+----------------------------+--------------------------------------------------+
[stack@dom-undercloud ~]$ openstack router set --external-gateway external-net-CL CLrouter
SNAT Pool
Same as before, each Hypervisor will be assigned with one IP from the pool and the VMs will be NATted
with the IP of the hypervisor. This time the SNAT IP will appear in the Common Tenant in ACI.
Using Floating IP
[stack@dom-undercloud ~]$ neutron subnet-create external-net-CL 10.104.31.0/24 --name ext-subnet-FIP --allocation-pool

start=10.104.31.10,end=10.104.31.100 --disable-dhcp --gateway 10.104.31.1
+----------------------------+---------------------------------------------------+
| Field | Value |
+----------------------------+---------------------------------------------------+
| apic:distinguished_names | {} | Creating floating IP is as simple
| apic:snat_host_pool | False |
| cidr | 10.104.31.0/24 |
as adding another subnet to the
| enable_dhcp | False | external network.
| gateway_ip | 10.104.31.1 |
| host_routes | |
| id | d9bb7111-b668-4823-932d-68fa211aa69b |
| ip_version | 4 |
| name | ext-subnet-FIP |
| network_id | b90bfad9-4ed3-477f-996a-4222ae0768dd |
| project_id | 11fa0c41388f4d3fbf3f2f6d6184f687 |
| service_types | |
| tenant_id | 11fa0c41388f4d3fbf3f2f6d6184f687 |
+----------------------------+---------------------------------------------------+
Floating IP in ACI
Floating Subnet will be visible in

ACI and when you assign a FIP
to a VM this will appear in the
operational tab of the external
EPG.
Demo
Demo Time!
Creation of opflex networks.
Binding of OpenStack VMs to those networks.
Adding connectivity to a bare metal server and a vSphere

virtual machine.
controller compute1
compute2 ESXi Bare Metal
APIC
APIC
APIC
Bridge Domain Orange 192.168.100.254/24
EPG Orange-OS
Bridge Domain Green 192.168.200.254/24
EPG green-OS
controller compute1
APIC
APIC
APIC
EPG Orange-OS
EPG green-OS EPG green-mixed
controller compute1
APIC
APIC
APIC
EPG Orange-OS
controller compute1
APIC
Contract allow-ICMP APIC
Allow ICMP APIC
EPG Orange-OS
Contract allow-SSH
Allow TCP:22
controller compute1
Are we there yet?
ACI connects Virtual and Physical World
Q&A
For Your
Reference
Documentation
• APIC OpenStack Plugin Installation Guides:
• http://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-
x/openstack/b_ACI_with_OpenStack_OpFlex_Architectural_Overview.html
x/openstack/b_ACI_with_OpenStack_OpFlex_Deployment_Guide_for_Red_Hat.html
x/openstack/b_ACI_with_OpenStack_OpFlex_Deployment_Guide_for_Ubuntu.html
For Your
Reference
Documentation (Cont.)
• APIC GBP Plugin Datasheet:
• http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/openstack-at-
cisco/datasheet-c78-734181.html
• APIC OpenStack Plugin Datasheet:
• http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/openstack-at-
cisco/datasheet-c78-732353.html
• GBP WhitePaper:
• http://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-
centric-infrastructure/white-paper-c11-733126.html
• GBP wiki:
• https://wiki.openstack.org/wiki/GroupBasedPolicy
Cisco Spark
Questions?
Use Cisco Spark to communicate
with the speaker after the session
How
1. Find this session in the Cisco Live Mobile App
2. Click “Join the Discussion”
3. Install Spark or go directly to the space
4. Enter messages/questions in the space
cs.co/ciscolivebot#BRKACI-3456
• Please complete your Online Complete Your Online
Session Evaluations after each
session
Session Evaluation
• Complete 4 Session Evaluations
& the Overall Conference
Evaluation (available from
Thursday) to receive your Cisco
Live T-shirt
• All surveys can be completed via
the Cisco Live Mobile App or the
Communication Stations
Don’t forget: Cisco Live sessions will be available
for viewing on-demand after the event at
www.ciscolive.com/global/on-demand-library/.
Continue Your Education
• Demos in the Cisco campus
• Walk-in Self-Paced Labs
• Tech Circle
• Meet the Engineer 1:1 meetings
• Related sessions
Thank you

Aci 3456

Uploaded by

Copyright:

Available Formats

You might also like

Aci 3456

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Aci 3456

Uploaded by

Copyright:

Available Formats

BRKACI-3456

Mastering ACI and

Remote PoD Multi-Pod / Multi-Site Hybrid Cloud Extension

Remote Location On Premise Public Cloud

Security Everywhere Analytics Everywhere Policy Everywhere

QoS QoS QoS

Scale-Out Penalty Free Overlay

Non-Integrated Mode Integrated Mode

• ACI Fabric as an IP-Ethernet • ACI Fabric as a Policy Authority

 Multiple VMMs likely on a single

 There is 1:1 relationship between

vCenter Kubernetes SCVMM OpenStack RHEV

 Map EPGs to VMM Domain based on

 Live migrate within VMM domain

VMM Domain 1 VMM Domain 2

 Map EPGs to VMM Domain based on

VNID 6032  Place VM anywhere

 Live migrate within VMM domain

VMM Domain 1 VMM Domain 2

OS nodes OVS OpFlex Agent

Solutions with Major OpenStack Distributions

• Full Neutron Node datapath replace • Automatic VXLAN tunnels at top of

Integrated Overlay Operations and

• Fully managed underlay network • Troubleshooting across physical and

• Type Drivers Neutron Server

• Mechanism Drivers Type Manager Mechanism Manager

• Type Drivers Neutron Server

Type Manager Mechanism Manager

• Opflex mode allows creation of neutron networks based on

• GBP comes with CLI, Policy Ruleset Contract

EPG Bridge Domain

dhcp EPG EPG

EPG Bridge Domain

dhcp EPG EPG

dhcp EPG EPG

EPG Bridge Domain

EPG Bridge Domain

dhcp EPG EPG

[heat-admin@overcloud-compute-0 ~]$ sudo yum list | grep @aci-repo

• APIC Integration Database and APIC Integration

• AIM uses the OpenStack database.

APIC Create Application Policy

Create Network, Subnet,

Neutron Server(s) • Neutron-opFlex-agent:

• Agent-OVS: Runs OpFlex

• Agent-OVS Programs open

For each VM, the Neutron

Network Policy including

• Full Neutron Node datapath replace • Automatic VXLAN tunnels at top of

Integrated Overlay Operations and

• Fully managed underlay network • Troubleshooting across physical and

• Traditionally in OpenStack the

• Also, the opflex-agent performs

• Traditionally VMs are

DHCP • Agent-OVS learns info of

Management/API Network • DHCP allocation and

Nova-API neutron- neutron- • Neutron metadata agent is

• Metadata agent locally