White Paper
Autoconfigure Your Cisco Unified
Fabric Workload
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 1 of 46
Contents
Introduction .............................................................................................................................................................. 3
VLAN and Layer 2 Segment ID ............................................................................................................................... 3
Layer 3 Segment ID and VRF .................................................................................................................................. 6
Mobility Domain ....................................................................................................................................................... 7
Lightweight Directory Access Protocol ................................................................................................................. 9
Autoconfiguration Overview ................................................................................................................................. 12
Semi-Automation ................................................................................................................................................... 13
Data-Plane Instantiated Autoconfiguration Based on Data Packets ................................................................... 16
Control-Plane Instantiated Autoconfiguration with VDP ...................................................................................... 17
Semi-Automation Mode with Auto-Pull ................................................................................................................ 22
Full-Automation Mode ........................................................................................................................................... 23
Manual Autoconfiguration Mode .......................................................................................................................... 26
Universal Profiles .................................................................................................................................................. 36
Appendix ................................................................................................................................................................ 43
Cisco Prime DCNM 7.0 Segment ID Range Settings .......................................................................................... 43
Autoconfiguration and vPC+ ............................................................................................................................... 44
Cisco Prime DCNM Network Autoconfiguration Profiles ..................................................................................... 45
Cisco Prime DCNM VRF Autoconfiguration Profiles ........................................................................................... 45
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 2 of 46
Introduction
Network autoconfiguration is part of the Cisco® Unified Fabric framework and enables your organization to
provision end-host network profiles on demand. The main benefits of the Cisco Unified Fabric workload automation
are:
●
Reduced workload deployment time
●
Flexible workload placement
●
Elimination of static provisioning and clean up
●
Higher tenant scalability
●
Reduction in the operator error due to mis-configuration
●
Consistent configuration for a given network across the fabric
The just-in-time end-host network profiles are stored in a database directory service accessible using the
Lightweight Directory Access Protocol (LDAP). LDAP is an open, vendor-neutral, industry-standard application
protocol for accessing and maintaining distributed directory information services over an IP network. For Cisco
Prime™ Data Center Network Manager (DCNM) and its central-point-of-management (CPOM) function, the network
and services workload-automation information is stored in an LDAP database. DCNM uses OpenLDAP to present
the relevant network autoconfiguration parameters (tenants, organizations, partitions, segments, etc.) to the Cisco
Unified Fabric switches and allows download of end-host tenant profiles with the appropriate parameters when a
workload (physical or virtual) server is connected.
Note:
Any LDAP-accessible directory service can be used for Cisco Unified Fabric autoconfiguration; however,
the advantage of using the DCNM LDAP database is that it includes a large collection of profiles already defined
that can serve a variety of purposes. Please see more about LDAP in a later section.
DCNM provides a standardized northbound REpresentational State Transfer (REST) Application Programming
Interface (API) to support information exchange between DCNM and northbound orchestrators.
This document discusses autoconfiguration in conjunction with a northbound orchestration application and a semiautomated operational mode using DCNM along with other provisioning options. Before these autoconfiguration
provisioning options are described, an overview of several fundamental functions and enhancements that are part
of the Cisco Unified Fabric framework is presented.
VLAN and Layer 2 Segment ID
In a traditional Layer 2 network, the VLAN defines a broadcast domain that is unique to the entire Layer 2 domain.
Switches encapsulate the VLAN ID in the IEEE 802.1q header to maintain VLAN separation on trunks, typically
referred as Inter-Switch Links (ISLs). The IEEE 802.1q tag has a 12-bit vlan field and thus can accommodate up to
4096 VLANs, which can be a limiting factor for large-scale data centers.
As a Cisco Unified Fabric innovation, Cisco introduced the Segment ID, which provides an extended name space.
This hardware-based innovation extends the VLAN name space from the 4096 VLANs provided by IEEE 802.1q to
more than 16 million segments to provide real multitenancy. This capability is achieved by doubling the 12-bit size
to 24 bits and is based on the TRILL Fine-Grained Labeling IETF draft standard (Figure 1).
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 3 of 46
Figure 1.
Extended Name Space with Segment ID Encapsulation
The Segment ID is unique to the entire fabric and therefore globally relevant. In the Cisco Unified Fabric, the
Segment IDs can be added and removed by leaf switches. You can associate a Segment ID with a VLAN manually
using the commands shown in Figure 2.
Figure 2.
Layer 2 Segment ID to VLAN Mapping Configuration Example
Example on a Leaf Switch
!
install feature-set fabricpath
feature-set fabricpath
feature vn-segment-vlan-based
!
vlan 123
mode fabricpath
vn-segment 30000
!
Because the Layer 2 Segment ID defines the broadcast domain within the fabric, VLANs are only locally significant
to the leaf switches, and a specific Segment ID can map to different VLANs on different leaf switches (Figure 3).
Future Cisco NX-OS Software releases will support per-port VLAN significance.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 4 of 46
Figure 3.
Layer 2 Segment ID to VLAN Mapping Example
To transport frames received at the leaf switch from end-hosts (physical or virtual) or other edge devices to a
specific Segment ID and as well for autoconfiguration instantiation, IEEE 802.1q tagged frames (trunk ports) are
required. Access ports or untagged frames needs to be modified as shown in the configuration example in Figure 4
with a native VLAN and are sometimes referred as pseudo access ports. This configuration example allows the leaf
switch to receive untagged frames from the end-host on a specific Ethernet interface to be mapped to the Segment
ID.
Figure 4.
IEEE 802.1q Tagged Access Port Configuration Example
Example on a Leaf Switch
!
interface Ethernet X/Y
switchport
switchport mode trunk
switchport trunk allowed vlan 11
switchport trunk native vlan 11
spanning-tree port type edge trunk
spanning-tree bpduguard enable
no shutdown
!
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 5 of 46
Layer 3 Segment ID and VRF
In the Cisco Unified Fabric at the leaf switch, each Layer 2 domain is represented by a Segment ID. When a Layer
2 domain is assigned to an IP subnet and when an IP gateway address is configured on the switch virtual interface
(SVI) on the leaf switches to route traffic, each SVI will be a member of a Virtual Routing and Forwarding (VRF)
instance, to provide multitenancy. As with a Layer 2 Segment ID, which identifies a unique Layer 2 segment, a
dedicated Layer 3 Segment ID uniquely identifies each VRF instance in the Cisco Unified Fabric. The Layer 3
Segment ID is transported in the same way as the Layer 2 Segment ID within the Layer 2 header for each data
packet, as shown earlier in Figure 1.
In a Layer 3 network, VRF allows multiple instances of a routing table to exist in a single physical leaf switch and to
work simultaneously and independently and provide multitenancy. VRF helps ensure traffic isolation at Layer 3
between different tenants. In the Cisco Unified Fabric, the VRF-instance name is a combination of the organization
and the partition. Figure 5 shows an example.
Figure 5.
Layer 3 Segment ID to VRF Mapping Example
For each VRF instance, NX-OS allocates a single core VLAN from a VLAN pool configured on the leaf switch. The
default core VLAN range is 2500 to 2999. The relevant VLAN range configuration is part of the Power On Auto
Provisioning (POAP) leaf configuration template. This core VLAN is required to map the VRF instance to the Layer
3 Segment ID and hence to populate the Segment ID field in the Layer 2 header for each IP data packet that is
routed at a leaf switch and sent toward another leaf switch (aka toward the spine). From the configuration
perspective, this mapping of the VRF to the Segment ID is performed in the profile vrf-tenant-profile. Figure 6
shows an example of POAP predefined vf-tenant-profileprofile in NX-OS 7.0.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 6 of 46
Figure 6.
POAP Predefined Profile vrf-tenant-profile in NX-OS 7.0
configure profile vrf-tenant-profile
vlan $vrfVlanId
vn-segment $vrfSegmentId
mode fabricpath
interface vlan $vrfVlanId
vrf member $vrfName
ip address 192.168.99.11/24
no ip redirects
ipv6 forward
no ipv6 redirects
no shutdown
!
Note:
The vrf-tenant-profile in NX-OS releases, starting from NX-OS 7.1(0)N1(1) is slightly different then the
vrf-tenant-profile in earlier NX-OS releases.
Note:
The relevant command for defining these VLANs is system fabric core-vlans 2500-2999.
Mobility Domain
Cisco Unified Fabric can take advantage of Virtual Station Interface (VSI) Discovery and Configuration Protocol
1
®
(VDP) with the Cisco Nexus 1000V Switch or Open Virtual Switch (Open vSwitch, or OVS) to automatically
resolve the mapping of the Segment ID to a VLAN. However, not all compute nodes support VDP: for example,
nonvirtualized physical appliances, bare-metal servers or other non-VDP capable virtualized hosts. These end-host
nodes can take advantage of autoconfiguration instantiation through data-plane learning instead of VDP.
Autoconfiguration through data-plane learning intercepts Address Resolution Protocol (ARP), Neighbor Discovery
Protocol (ND), Dynamic Host Configuration Protocol (DHCP) or any other packet for that matter tagged with a
standard IEEE 802.1q tag and uses it to map the locally significant VLAN to the fabric-significant Segment ID.
However, the individual leaf switches can't uniquely identify which VLAN needs to be mapped to a particular
Segment ID, because the same VLAN ID can be used in different tenants.
The Mobility Domain (MD) is the missing piece. A Mobility Domain can be represented by a user-defined string that
uniquely identifies a grouping of 4K vlans. So a Mobility Domain can represent a VMware vCenter, or more
granularly a DVS or cluster or an OpenStack controller. By defining additional Mobility Domains, the VLAN
scalability in the fabric can be greatly increased. The VLAN ID coupled with the Mobility Domain allows the leaf
switch to uniquely identify a tenant network and map it to Layer 2 Segment ID.
Within a Mobility Domain (MD), VLAN IDs are shared across multiple leaf switches, but a leaf can belong to only
one Mobility Domain. However, in Cisco Unified Fabric with autoconfiguration, multiple Mobility Domains can be
defined (Figure 7). Future NX-OS releases will support multiple Mobility Domains per physical leaf switch.
Note:
The NX-OS releases, starting from 7.1(0)N1(1) and DCNM 7.1(1), support multiple Mobility Domains per
leaf switch (Nexus 5600/6000 series switches).
1
VDP is described in IEEE 802.1Qbg Clause 41
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 7 of 46
Figure 7.
Multiple Mobility Domains in Cisco Unified Fabric
The Mobility Domain requires IEEE 802.1q tagged frames between end-host (physical or virtual) or other edge
devices and the leaf switch. Access ports or untagged frames need to be configured as pseudo access ports as
discussed earlier.
A Mobility Domain is identified by a unique 128-character string and is configured on the leaf switch as part of the
fabric database commands. Figure 8 shows a configuration example. The Mobility Domain string configuration is
part of the POAP definition and is configured automatically during the POAP day-zero deployment process for all
leaf switches.
Note:
The NX-OS releases, starting from 7.1(0)N1(1) and DCNM 7.1(1) will support multiple Mobility Domains
per leaf switch along with Mobility Domain changes after POAP day-zero.
Figure 8.
Mobility Domain Configuration Example
Example on a Leaf Switch
!
fabric database mobility-domain <<MyMobilityDomain>>
!
Even if Mobility Domains extend the significance of VLANs across multiple leaf switches, Segment IDs are still
used as globally significant name spaces and provide scalability beyond the 4K VLAN limitations for the fabric.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 8 of 46
Lightweight Directory Access Protocol
2
LDAP is an application protocol used to access directory services. A directory is similar to a database; the
advantage of using directories is that they tend to provide a quick response in large-volume lookups. LDAP also
provides a tree-style organization of objects as part of Cisco Unified Fabric autoconfiguration innovation. Four
object classes have been defined as shown in Table 1.
Table 1.
DCNM LDAP Object Classes
Object Classes
Value
Orgs
An organization identified by its name
Partitions
A network partition, with a Layer 3 Segment ID; partitions typically belongs to an organization
Networks
An entry that maps the tuple {segmentId, vlanId, mobilityDomainId} to one profileName
Profiles
A configuration profile
Note:
The NX-OS releases, starting from 7.1(0)N1(1) and DCNM 7.1(1) will support additional object classes to
support additional use-cases such as DCI autoconfiguration.
Figure 9 shows how these object classes are mapped and structured in the DCNM LDAP database.
Figure 9.
2
DCNM LDAP Database Organization
Please see more details about LDAP in the programmer guide here:
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/7_x/dcnm/dfa_api/DFA_API.html.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 9 of 46
From the configuration perspective, there are the two partitions, each associated with the vrf-common profile, and
the networks are associated with a corresponding network configuration profile: for example,
defaultNetworkIpv4EfProfile. The vrf-common profile is referenced from the network profile (for example,
defaultNetworkIpv4EfProfile) through the include profile vrf-common command. The contents of the network
profile associated with a given network are always pulled down from the DCNM LDAP repository if they are not
already locally cached on the leaf switch. However, note that the included vrf-common profile is not pulled down
from the DCNM LDAP repository during the autoconfiguration instantiation process. Instead, this profile must be
already part of the running configuration on the leaf switches, typically configured through the POAP day-zero
deployment process. Starting with NX-OS 7.1(0)N1(1) and DCNM 7.1(1), with the new universal network profiles,
the contents of the associated partition profile are also pulled down from the LDAP repository (on demand). You
should include the include profile any command in the universal network profiles to allow the partition to be
associated with a partition profile without having any dependence on the network configuration profile, to provide
the most flexibility.
In LDAP, an object class defines the collection of attributes that can be used to define an entry. For example, the
object class network contains the mandatory and optional attributes listed in Table 2.
Table 2.
DCNM 7.0 LDAP Objects Class Network Attributes per Tenant
Mandatory Attributes
Description
segmentId
A 24-bit integer representing a Layer 2 segment
vlanId
VLAN ID (0-4095); default value is 0
mobilityDomainId
Name of mobility domain; default value is None
profileName
A string representing the profile name
Optional Attributes
Description
Description
RFC 4519: descriptive information
networkName
A string representing the network name
partitionName
A string representing the name of the partition
orgName
A string representing the name of the organization
configArg
A single argument to be substituted into ASCII configuration file; should be in the format "name = value"
vSwitchControllerId
IP address of the virtual machine controller
staticIpStart
The start of a static IP address range
staticIpEnd
The end of a static IP address range
vSwitchControllerNetworkId
The virtual switch controller network identifier:
VMware: Port-group name
OpenStack: Network universal unique ID (UUID)
DVSId
The Distributed Virtual Switch identifier:
VMware: Distributed virtual switch (DVS) UUID
OpenStack: Not applicable
Figure 10 shows an example of the object class networks for a specific tenant (ORG:RED) stored in the DCNM
LDAP database accessed through a LDAP browser.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 10 of 46
Figure 10.
DCNM 7.0 LDAP Object Class Network Query
The various configuration values will be passed along with the configuration profile referenced by
defaultNetworkIpv4EfProfile, to create the end-host (physical or virtual) facing VLAN, SVI, VRF etc.
Figure 11 shows the object class profile for the profile defaultNetworkIpv4EfProfile with the relevant
configuration commands for the end-host (physical or virtual) facing VLAN and SVI.
Figure 11.
DCNM 7.0 LDAP Object Class Profile Query
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 11 of 46
In Cisco Unified Fabric with autoconfiguration, the leaf switch acts as a LDAP client. This LDAP client queries the
LDAP server (typically hosted in DCNM) for specific objects, which will subsequently be downloaded to the leaf
switch after an autoconfiguration instantiation trigger event. The autoconfiguration instantiation eliminates the need
to provision and clean up static end-host (physical or virtual) and edge-device configurations on the leaf switches.
Two commands are required to make the leaf switch an LDAP client to support autoconfiguration. The first
command is required to query the networks table, and the second command is required to query the profiles table.
The network query returns the network parameters ($values called configArgs or Configuration Arguments) along
with the configuration profile referenced by the network. The profile query returns the contents of the referenced
configuration profile if not already cached on the leaf switch.
The specified IP address in the configuration example in Figure 12 is the out-of-band IP address of DCNM with the
LDAP service running on it. The LDAP database can also be accessed in-band.
Figure 12.
LDAP Client Configuration Example
Example on a Leaf Switch
!
fabric database type network
server protocol ldap ip 192.168.100.250 vrf management
db-table ou=networks,dc=cisco,dc=com key-type 1
fabric database type profile
server protocol ldap ip 192.168.100.250 vrf management
db-table ou=profiles,dc=cisco,dc=com
!
Note:
The LDAP client configuration for the two object classes namely, network and profile, is part of the
POAP definition and is executed during the day-zero deployment process on all leaf switches.
Autoconfiguration Overview
Autoconfiguration is a powerful feature that helps provision tenant profiles just-in-time on the Cisco Unified Fabric.
Cisco Unified Fabric with autoconfiguration helps simplify server deployment by centralizing the network
configuration and allows just-in-time reconfiguration in the event that a server moves to another leaf switch in the
fabric.
Autoconfiguration can be deployed in any of the following three modes, or a combination:
1.
Semi-Automation
2.
Fully-Automation
3.
Manual
Semi-Automation mode, or partial automation, can be used for physical hosts and virtual machines where DCNM is
employed as a pseudo-orchestrator. Semi-automation mode supports instantiation through VDP as well as using
ARP, ND, DHCP or any other packet with a IEEE 802.1q tag.
Full-automation mode uses an orchestrator connected northbound to DCNM. The orchestrator allows the network
operator to access, provision, and automate compute, storage, and network resources and supports physical and
virtual machine network profile instantiation.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 12 of 46
Manual mode simplifies physical server deployment by automating several network configuration tasks instead of
performing line-by-line configuration. This mode functions without the support of the DCNM auto-configuration
profiles.
Semi-Automation
Semi-Automation mode can be used for end-hosts, either VMs or bare-metal servers. Depending on the virtual
switch capabilities, the trigger to instantiate the relevant end-host (physical or virtual) network profiles using LDAP
from DCNM is either data packet or VDP trigger:
●
A data packet trigger is based on a new MAC learn triggered by an incoming IEEE 802.1q tagged packet
(could be ARP, DHCP, ND or any other packet for that matter). The leaf switch pulls down the associated
network configuration profile from DCNM using the VLAN-ID and the Mobility Domain as the query identifier.
●
VDP is used to trigger the autoconfiguration based on the Segment ID. When the VM is coming up, the
hypervisor vSwitch sends out a notification to the leaf switch, saying I have a workload coming up in
Segment X and please allocate whatever resources those are necessary to be ready to accept traffic from
this VM. The leaf switch pulls down the associated network configuration profile from the DCNM using the
Segment ID as query identifier.
Figure 13 shows the two relevant semi-automated autoconfiguration options.
Figure 13.
Semi-Automated Workload Overview with Data Packet and VDP Trigger
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 13 of 46
The end-host (physical or virtual) network profiles for autoconfiguration are created on DCNM and stored in the
LDAP database accessible through LDAP. In the semi-automation mode, DCNM is the authoritative instance for
managing the fabricwide Segment ID with the appropriate tenant network profile parameters without a northbound
orchestration. DCNM comes with multiple on-demand end-host (physical or virtual) network profiles. To provision
the end-hosts, create a network in the DCNM and store it in the LDAP directory by accessing the DCNM AutoConfiguration option from the main menu as shown in Figure 14.
Figure 14.
Accessing the DCNM 7.0 Auto-Configuration Menu Option
The autoconfiguration window is divided into two panes.
The top pane allows the operator to define an organization and partitions within that organization. The first step is
to create the organization. The next step is to create a partition for the organization. The DCNM automatically
assigns a Layer 3 Segment ID (sometimes called a partition ID) from a predefined Layer 3 Segment ID pool (the
default range is 50’000 to 60’000) that identifies the Layer 3 domain within the fabric.
Note:
Please see the appendix for details about changing the default Segment ID pool in DCNM.
The unique combination of partition within an organization represents a Layer 3 domain or a VRF. The VRF name
is created by combining the organization name and the partition name (specifically vrfName =
organizationName:partitionName).
The example in Figure 15 shows an organization named ORG and with two partitions, named RED and BLUE.
Figure 15.
DCNM 7.0 Top Pane for Creating an Organization and Partitions
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 14 of 46
The lower pane allows the operator to define the network parameters for a particular partition. The network profile
examples in the Figures 16 and 17 show different profiles for two independent partitions.
Figure 16.
DCNM 7.0 Lower Pane with the Network Profile for Partition RED
Figure 17.
DCNM 7.0 Lower Pane with the Network Profile for Partition BLUE
The three network profiles used in the examples in this document are nearly identical and have many similar, selfexplanatory parameters: for example, the Layer 2 Segment ID, IP gateway, and IP subnet, and the optional endhost (physical or virtual) workload-automation DHCP ranges. However, the parameters defined in the Network ID
field in Figure 18 are different.
Table 3 provides an overview of the three autoconfiguration profiles configured in DCNM.
Table 3.
Overview of the Three Autoconfiguration Profiles
Parameter
Profile WORKLOAD-VLAN77
Profile WORKLOAD-VLAN88
Profile WORKLOAD-VDP
Network name
WORKLOAD-VLAN77
WORKLOAD-VLAN88
WORKLOAD-VDP
Partition name
RED
BLUE
BLUE
Segment ID
30077
30088
31230
VLAN ID
77
88
0
Mobility domain
MOBILITY-DOMAIN-1
MOBILITY-DOMAIN-1
None
Profile name
defaultNetworkIpv4EfProfile
defaultNetworkIpv4EfProfile
defaultNetworkIpv4EfProfile
Subnet (DHCP
scope)
10.10.77.0/24
10.10.88.0/24
10.10.99.0/24
Gateway
(DHCP scope)
10.10.77.254
10.10.88.254
10.10.99.254
IP range
(DHCP scope)
10.10.77.200-10.10.77.220
10.10.88.200-10.10.88.220
10.10.99.200-10.10.99.220
The next section discusses the two semi-automated workload-automation trigger options:
●
Data-plane instantiated autoconfiguration based on data packets
●
Control-plane instantiated autoconfiguration with VDP
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 15 of 46
Data-Plane Instantiated Autoconfiguration Based on Data Packets
Figure 18 shows the tenant network (marked in blue) instantiated based on data packet sent by the physical or
virtual host. These packets are received on the physical leaf switch on an IEEE 802.1q trunk port, or as previously
described, on an IEEE 802.1q tagged pseudo trunk port. For this data-plane instantiated autoconfiguration profile,
the definition of a Mobility Domain ID is required.
Figure 18.
Note:
DCNM 7.0 Network Profile WORKLOAD-VLAN77 Details
The example in Figure 18 has the end-host (physical or virtual) network profile
defaultNetworkIpv4EfProfile selected. This IPv4 tenant network profile enables the enhanced forwarding mode
for the end-host-facing SVI. DCNM 7.0 contains more than 30 profiles that apply to multiple cases, including IPv6,
dual-stack, and services-leaf profiles. With DCNM 7.1(1) and later Cisco has introduced the new universal profiles,
which support transparent profile updates, and hence the IPv4, IPv6 and dual-stack profiles are combined into a
single universal profile. The description of other DCNM 7.0 profiles is deliberately omitted from this document, but
the appendix highlights the most important profiles available in DCNM 7.0.
For both physical machines and virtual machines, the setting of the VLAN ID (VLAN ID 77 in Figure 18, marked in
green) is relevant to instantiating the autoconfiguration profile. The interface on the physical machines is set to this
specific VLAN ID (77) and requires the same VLAN ID to be defined in the tenant profile. The virtual machine,
typically managed by a controller (for example, VMware vCenter), is attached to a virtual switch and is assigned to
a port-group that is assigned a specific VLAN ID that also matches the VLAN defined in the DCNM tenant network
profile. Figure 19 shows an example with the VLAN ID set to 77.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 16 of 46
Figure 19.
Virtual Machine Mapping to VLAN77 (VMware vCenter)
Control-Plane Instantiated Autoconfiguration with VDP
Figure 20 shows a network (marked in blue) whose autoconfiguration3 trigger is based on VDP. VDP control-plane
frames are exchanged between the virtual switch (Cisco Nexus 1000V or OVS) and the physical leaf switch. This
approach does not require the definition of a Mobility Domain ID on DCNM or on the physical leaf switch because
identification is based on the Layer 2 Segment ID only4. DCNM automatically sets the Mobility Domain ID to None.
Note:
VDP enables network-based overlays that provide a more scalable solution than host-based overlays for
segmentation beyond the 4K VLAN limitation of IEEE 802.1q.
3
A network definition is independent of the trigger that is configured on the Cisco Prime DCNM to instantiate the end-host
(physical or virtual) network profile on the leaf switch. For example, NX-OS allow both physical and VDP workloads to be part of
the same network segment.
4
In NX-OS 7.1(0)N1(1) or later supports VLAN-based VDP in addition to Segment-based VDP as described in this document.
The VLAN-based VDP enhancements require the concept of a Mobility Domain.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 17 of 46
Figure 20.
Note:
DCNM 7.0 Network Profile WORKLOAD-VDP Details
The vlanId field in the profile parameter section should be empty. The VLAN used for the data packets
between the virtual machine and the network will be automatically negotiated between the physical and virtual
switches. This VLAN is selected from the POAP predefined local VLAN pool (with the command system fabric
dynamic-vlans 2500-3500) on the physical leaf switch. The first negotiated and allocated VLAN is VLAN 3000,
because the VLAN range 2500 to 2999 is used for the core VLANs. The VLAN ID in the Network ID section is
automatically set to zero through DCNM because the VLAN ID is not relevant for VDP-instantiated
autoconfiguration profiles; only the Segment ID is used for network instantiation.
Note:
The empty fields in the Service Configuration Parameters section are not relevant for the two DCNM
workload-automation profiles previously shown. These fields need to be populated for networks hosting L4-L7
services such as load-balancers and firewalls.
The trigger to instantiate the tenant network profiles is a match on the Layer 2 Segment ID. Therefore, the network
operator must set the same Layer 2 Segment ID on the VDP-capable virtual switch as on the DCNM workloadautomation profile (the Layer 2 Segment ID 31230 in Figure 20, marked in green).
Figure 21 provides an example of the manual Cisco Nexus 1000V Virtual Supervisor Module (VSM) configuration
with the same Layer 2 Segment ID (31230, defined under the bridge domain).
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 18 of 46
Figure 21.
Cisco Nexus 1000V VSM Configuration with Layer 2 Segment ID 31230
Example on a Cisco Nexus 1000V Virtual Switch (VSM)
!
feature evb
! Enables EVB (Edge Virtual Bridging) for VDP signalization
feature segmentation
! Allow Segment-ID to VLAN mapping and enables Bridge-Domain support
!
segment transport-mode native
! Using native (dot1q; default mode is VXLAN) encapsulation for Bridge-Domain
!
port-profile type ethernet VDP-ETH-UPLINK
vmware port-group
switchport mode trunk
switchport trunk dynamic
! Allowing the transport of dynamic created VLANs between the physical leaf
! switch and the N1KV
switchport trunk native vlan 1
! Native VLAN 1 is used for the VDP signalization
no shutdown
state enabled
!
bridge-domain VDP31230
segment id 31230
group 232.3.123.1
! Multicast group is used for VXLAN encapsulation, however is not used for native
! encapsulation; but still required to be configured - could be any dummy group
segment transport-mode native
!
port-profile type vethernet VDP-VETH-PUBLIC
vmware port-group
switchport access bridge-domain VDP31230
no shutdown
state enabled
!
Note:
The Edge Virtual Bridging (EVB) feature is required for VDP signalization on both the physical switch and
the Cisco Nexus 1000V VSM. The physical leaf switch acts as the EVB bridge, and the Cisco Nexus 1000V VSM is
the EVB station. EVB consists of two components: VDP and Edge Control Protocol (ECP). VDP is used for
signalization between the physical and virtual switches and runs over the reliable ECP Ethernet protocol, which
uses the nearest customer bridge MAC address (01:80:C2:00:00:00 by default). This VDP multicast MAC address
needs to be identical on the EVB bridge and station. Certain deployments, such as deployments that use a Cisco
Unified Computing System™ (Cisco UCS®) fabric interconnect or a blade switch, require a customized VDP
multicast destination MAC address other than the default 01:80:C2:00:00:00.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 19 of 46
Otherwise, the Cisco UCS fabric interconnect intercepts and consumes packets destined to this specific MAC
address thereby preventing the VDP control frames from reaching the physical leaf switch.
As mentioned earlier, the required VLAN for transporting data packets between the virtual switch of the virtual
machine and the physical leaf switch is dynamically assigned from a POAP predefined local VLAN pool (using the
command system fabric dynamic-vlans 2500-3500) on the physical leaf switch. This locally significant VLAN is
chosen by the physical leaf switch and is communicated to the virtual switch through VDP.
Nevertheless, for the control-plane based network instantiated with VDP, the link between the virtual switch and the
physical leaf switch requires an IEEE 802.1q trunk port with a single VLAN to transport user traffic. The 4K VLAN
limitation on the leaf switch remains, however from the fabric wide perspective we can scale up to 16 Million
segments.
Finally, the virtual machine is assigned to the previously created Cisco Nexus 1000V VSM Ethernet (virtual
Ethernet) port profile. Figure 22 provides an example.
Figure 22.
Virtual Machine Mapping to Cisco Nexus 1000V Port Profiles (VMware vCenter)
Figure 23 shows verification of the control-plane instantiated end-host (physical or virtual) network
autoconfiguration based on VDP on the physical leaf switch. This example shows how powerful VDP-instantiated
autoconfiguration is, with the VDP signalization passing additional valuable information (for example, the virtual
machine hostname and the IP address) to the nearest physical leaf switch. This additional information is
transported on Cisco’s proprietary VDP extensions, which DCNM uses for several visibility tasks.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 20 of 46
Figure 23.
VDP Virtual Machine Information
Example on a Leaf Switch
!
LEAF# show evb hosts
EVB Host table
No. of Hosts: 1
No. of VSIs:
1
Flags: + - Multiple addresses
Host Name
VNI
Vlan
BD
Mac-address
IP-Address
Interface
------------------- --------- -------- ------- ---------------------- ---------------- --------------zrh-vm12
31230
3000
3000
0050.56b7.7983 10.10.99.216
Eth101/1/2
!
Table 4 summarizes the three just-in-time tenant end-host (physical or virtual) network profile examples discussed
so far for the semi-automation mode from the perspective of the LDAP database.
Table 4.
LDAP Object Class Network Values
Attribute Type
Value
Value
Value
mobilityDomainId
MOBILITY-DOMAIN-1
MOBILITY-DOMAIN-1
None
profileName
defaultNetworkIpv4EfProfile
defaultNetworkIpv4EfProfile
defaultNetworkIpv4EfProfile
segmentId
30’077
30’088
31’230
vlanId
77
88
0
configArg
$dhcpServerAddr
$dhcpServerAddr
$dhcpServerAddr
=192.168.100.250
=192.168.100.250
=192.168.100.250
configArg
$gatewayIpAddress=10.10.77.254
$gatewayIpAddress=10.10.88.254
$gatewayIpAddress=10.10.99.254
configArg
$include_vrfSegmentId=50000
$include_vrfSegmentId=50001
$include_vrfSegmentId=50001
configArg
$netMaskLength=24
$netMaskLength=24
$netMaskLength=24
configArg
$segmentId=30’000
$segmentId=30’088
$segmentId=31’230
configArg
$vlanId=77
$vlanId=88
$vlanId=None
configArg
$vrfName=ORG:RED
$vrfName=ORG:BLUE
$vrfName=ORG:BLUE
networkName
WORKLOAD-VLAN77
WORKLOAD-VLAN88
WORKLOAD-VDP
objectClass
Network
Network
Network
orgName
ORG
ORG
ORG
partitionName
RED
BLUE
BLUE
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 21 of 46
Semi-Automation Mode with Auto-Pull
The trigger to download the end-host (physical or virtual) network configuration from DCNM to the physical leaf
switch is based on the ARP, ND, DHCP or any other packet with a IEEE 802.1q tag or the exchange of VDP
packets. Additionally, NX-OS provides the auto-pull command to allow the network operator to trigger the
download and instantiation of a given tenant network configuration. The auto-pull option typically is helpful during
the testing phases of a deployment or in deployments in which the network operator wants to distribute the tenant
network configuration in the Cisco Unified Fabric consistently after the POAP process. The auto-pull command
queries the LDAP database in the same way as the previously discussed trigger options.
The example in Figure 24 shows how the network operator can download the workload-automation profile to the
physical leaf switch.
Figure 24.
Workload Automation Using Auto-Pull
Example on a Leaf Switch
!
LEAF# fabric database auto-pull dot1q <<VLAN>> interface e X/Y
!
The auto-pull command supports several interface options. To successfully instantiate a profile, the definition of a
valid interface is required. The auto-pull command also can be used with the option vni instead dot1q. The vni
option chooses the end-host-facing VLAN from the local pool, as discussed previously for VDP.
Note:
If virtual PortChannel plus (vPC+) is configured on a pair of leaf switches, the end-host (physical or virtual)
network profile is automatically synched between the vPC+ peer switches. Please see the detailed
autoconfiguration description for vPC+ in the appendix.
Figure 25 shows verification of the instantiated profile on a leaf switch. You can use the command show fabric
database host independently for any kind of triggered tenant network configuration as well with the auto-pull
command. The command shows the downloaded variables from the DCNM LDAP database along with the object
classes. Note that the contents of the network profile (for example, defaultNetworkIpv4EfProfile) are also
downloaded to the leaf switch.
Figure 25.
Verification of the Instantiated Autoconfiguration Profile
Example on a Leaf Switch
!
LEAF# show fabric database host dot1q 77
Got Local originated vlan type trigger at 20:36:04
Number of associated interfaces: 2
Sent to Database Manager at 20:36:02
Received Parameters from Database Manager at 20:36:02
Displaying parameters for profile defaultNetworkIpv4EfProfile and instance insta
nce_def_77_77
parameter 0: $gatewayIpAddress=10.10.77.254
parameter 1: $netMaskLength=24
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 22 of 46
parameter 2: $vlanId=77
parameter 3: $segmentId=30077
parameter 4: $vrfName=ORG:RED
parameter 5: $gatewayIpAddress=10.10.77.254
parameter 6: $netMaskLength=24
parameter 7: $dhcpServerAddr=192.168.100.250 <<<before was .251
parameter 8: $include_vrfSegmentId=50000
parameter 9: $vlanId=77
parameter 10: $asn=65000
Sent Apply to Configuration Manager at 20:36:02
Completed executing all commands at 20:36:04
Displaying Data Snooping Ports
Interface
Encap
Flags
State
Eth101/1/1
77
L
Profile Active
Eth101/1/16
77
L
Profile Active
LEAF#
The network operator has the option to clear the instantiated profile on each individual leaf switch with the
command shown in Figure 26.
Figure 26.
Clearing the Profile
Example on a Leaf Switch
!
LEAF# clear fabric database host dot1q <<VLAN>>
!
LEAF# clear fabric database host vni <<L2-SEGMENT-ID>>
!
Full-Automation Mode
Full-automation mode is implemented through a Cisco or third-party orchestrator. An orchestrator allows the
network operator to access, provision, and automate computing, storage, and network resources. Cisco Unified
Fabric supports any northbound system using REST API. It currently integrates closely with the following three
orchestration applications:
●
Cisco UCS Director Release 4.1.0.3 or later
●
OpenStack5
●
VMware vCloud Director6
5
Based on open source software Juno release with Cisco Dynamic Fabric Automation (DFA) plug-in developed at Cisco.
OpenStack for Cisco DFA software is currently packaged with Cisco OpenStack Installer. More details:
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/dfa/openstack/install/guide/rel-20/nexus_openstack_enabler_1_0_install_guide.html
6
VMware vCloud Director uses Advanced Message Queuing Protocol (AMQP) instead of the REST API. The adaptor that listens
to the AMQP notifications and calls REST API’s to populate the LDAP database is packaged with Cisco Prime DCNM.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 23 of 46
The orchestrator is connected northbound to DCNM. Most orchestrators commonly interact with DCNM through
REST APIs. Figure 27 provides a simplified example.
Figure 27.
Fully Automated Mode with VDP
The orchestrator configures the Cisco Nexus 1000V Switches or OVS with a port group or port-profile with an
associated Layer 2 Segment ID for each network in addition to providing that information to the DCNM. The Virtual
Machine managers such as VMware vCenter or OpenStack controller get the appropriate port-groups so that
virtual workloads can then be instantiated and attached to these port-groups for bringing them into the network.
This section describes the principles of full-automation mode independent of the orchestration application. Cisco
provides additional documentation at http://www.cisco.com/go/dfa that describes how to integrate specific
orchestration applications.
Figure 28 shows a full-automation provisioning process with an orchestrator. This example shows the Cisco UCS
Director with Nexus 1000V. Other orchestration works accordingly.
Figure 28.
Full-Automation Mode Process Flow
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 24 of 46
The figure shows the following workflow:
1.
Via an orchestrator like Cisco UCS Director, a new tenant is created which maps to an appropriate
organization and partition in the Unified Fabric.
2.
This information is populated to the DCNM via REST APIs.
3.
DCNM automatically allocates a Layer 3 Segment ID for the corresponding VRF instance and updates the
local LDAP database with the Layer 3 Segment ID.
4.
At the orchestrator, a tenant network is created for which it allocates an appropriate Layer 2 Segment ID from
an orchestrator managed Segment ID pool. This information is also sent to DCNM via REST API calls so that
it is populated into the DCNM LDAP network repository to be available for subsequent query from the leaf
switches.
5.
As part of the network creation, the orchestrator also programs the virtual infrastructure. Specifically, the Cisco
UCS Director programs the Cisco Nexus 1000V VSM with a port-profile with a Layer 2 Segment ID that it
allocated for the previously created tenant network.
6.
In VMware environment, the Nexus 1000V VSM in turn creates an appropriate port-group in vCenter via which
it is pushed to all the compute nodes that are part of the DVS (aka Nexus 1000V VEMs).
7.
A virtual machine is attached this port-group and powered on.
8.
VDP packets with the Layer 2 Segment ID information are sent from the Nexus 1000V VEM to the physical
leaf switch.
9.
The physical leaf switch queries DCNM with the Layer 2 Segment ID.
10. As part of the query response, the DCNM returns to the physical leaf switches the required information (VRF
instance, Layer 3 Segment ID, IP address, profile, etc.) to instantiate the end-host (virtual) network profile
configuration.
11. For the Layer 2 Segment ID, the physical leaf switch associates a free VLAN from the predefined local VLAN
pool.
12. The physical leaf switch passes via VDP the VLAN ID to the virtual switch.
13. The virtual machine sends the packet encapsulated in the associated VLAN (step 11 and 12), which typically
is an ARP, ND, DHCP or even a data packet.
14. The ARP, ND, or DHCP packet is intercepted by the supervisor of the physical leaf switch. The new created
host entry (ARP or ND) is synchronized with the host mobility manager (HMM) for this particular virtual
machine and is subsequently redistributed to the Multiprotocol Border Gateway Protocol (MP-BGP) to make
this host entry available and reachable by other hosts in the same VRF instance in the Cisco Unified Fabric.
Note:
The full-automation example in Figure 28 shows only the use case with VDP using Cisco UCS Director
and Nexus 1000V as a virtual switch. A similar flow would be applicable for other orchestrators using either VDP or
non-VDP triggers for auto-configuration.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 25 of 46
Manual Autoconfiguration Mode
The manual mode provides simplified server deployment by automating several network configuration tasks
instead of performing line-by-line configuration. This mode is used primarily to reduce the initial configuration effort.
It also simplifies reconfiguration in server mobility use cases and helps keep configurations error-free and
consistent on all leaf switches.
An exhaustive manual line-by-line configuration through the NX-OS command-line interface (CLI) without the
tenant profile values populated from the parameter list is also a valid and supported option. However, this option is
not discussed in this document.
The manual mode benefits from the predefined network tenant profiles with variables included in the POAP
templates during the day-zero fabric deployment. These variables (starting with the $ sign) in the profiles are
populated through manually configured parameter lists. These network tenant profiles configured by POAP on the
leaf switches may differ depending on the template chosen and the parameters defined during the POAP process.
Figures 29 and 30 show configurations for the two most commonly employed network tenant profiles: vrf-common
and vrf-tenant-profile.
Figure 29.
POAP Predefined Profile vrf-common
Example on a Leaf Switch
!
configure profile vrf-common
vrf context $vrfName
vni $include_vrfSegmentId
rd auto
address-family ipv4 unicast
route-target import 65000:9999
route-target both auto
address-family ipv6 unicast
route-target import 65000:9999
route-target both auto
router bgp $asn
vrf $vrfName
address-family ipv4 unicast
redistribute hmm route-map FABRIC-RMAP-REDIST-HOST
redistribute direct route-map FABRIC-RMAP-REDIST-SUBNET
maximum-paths ibgp 2
address-family ipv6 unicast
redistribute hmm route-map FABRIC-RMAP-REDIST-V6HOST
redistribute direct route-map FABRIC-RMAP-REDIST-SUBNET
maximum-paths ibgp 2
!
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 26 of 46
Figure 30.
POAP Predefined Profile vrf-tenant-profile in NX-OS 7.0
Example on a Leaf Switch
!
configure profile vrf-tenant-profile
vlan $vrfVlanId
vn-segment $vrfSegmentId
mode fabricpath
interface vlan $vrfVlanId
vrf member $vrfName
ip address 192.168.99.11/24
no ip redirects
ipv6 forward
no ipv6 redirects
no shutdown
!
Note:
The vrf-tenant-profile in NX-OS releases, starting from NX-OS 7.1(0)N1(1) is slightly different then the
vrf-tenant-profile in earlier NX-OS releases.
The two network tenant profiles in Figures 29 and 30 consist of regular CLI commands and variables entered in the
profile configuration mode. These commands in the same network tenant profile are shared with all tenants, in
which case the profile is instantiated multiple times (once per tenant vrf). Figure 31 shows the CLI command to
display the network tenant profile.
Figure 31.
Command to Verify the Predefined Profiles
Example on a Leaf Switch
!
show config-profile name <<profile>>
!
In the first step in manual mode, the network operator configures the parameter list. This list and the corresponding
values populate the variables in the network tenant profiles. The parameter list defines the parameters through the
command set and the data type (for example, integer or string). The parameter list is fully customizable by the
network operator, and the associated values can be used by single or multiple network tenant profiles. A unique
instance is created for each tenant.
Figure 32 provides an example of a complete tenant parameter list with the corresponding values for a single
instance.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 27 of 46
Figure 32.
Parameter List and Associated Values
Example on a Leaf Switch
!
param-list MY_PRIVAT_PARAMETERLIST
define include_vrfSegmentId integer
define asn integer
define vlanId integer
define segmentId integer
define vrfName string
define gatewayIpAddress string
define netMaskLength string
instance MY_INSTANCE_ORG:PAR001_V77
set include_vrfSegmentId 60001
set asn 65000
set vlanId 77
set segmentId 10077
set vrfName ORG:PAR001
set gatewayIpAddress 10.10.77.254
set netMaskLength 24
!
Note:
In the example in Figure 32, the VRF context is created using the OrganizationName:PartitionName
naming convention.
The Layer 2 and Layer 3 Segment IDs (variables segmentID and include_vrfSegmentId) chosen by the network
operator must be from different ranges as defined in DCNM. The appendix of this document shows the adjustable
Layer 2 and Layer 3 Segment ID ranges in DCNM. By default, the range is between 30’000 and 60’000.
Note:
The theoretically supported overall Segment ID range in NX-OS is 4’096 to 16’773’119.
In the second step, the network operator applies the parameter instance to the profile vrf-common using the apply
profile command in configuration mode (Figure 33). Then the operator verifies the profile (Figure 34).
Figure 33.
Applying the Parameter Instance to the vrf-common Profile
Example on a Leaf Switch
!
apply profile vrf-common param-instance MY_INSTANCE_ORG:PAR001_V77
!
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 28 of 46
Figure 34.
Verification of the vrf-common Profile with the Applied Parameter Instance
Example on a Leaf Switch
!
LEAF# show config-profile name vrf-common
config-profile vrf-common
vrf context $vrfName
vni $include_vrfSegmentId
rd auto
address-family ipv4 unicast
route-target import 65000:9999
route-target both auto
address-family ipv6 unicast
route-target import 65000:9999
route-target both auto
router bgp $asn
vrf $vrfName
address-family ipv4 unicast
redistribute hmm route-map FABRIC-RMAP-REDIST-HOST
redistribute direct route-map FABRIC-RMAP-REDIST-SUBNET
maximum-paths ibgp 2
address-family ipv6 unicast
redistribute hmm route-map FABRIC-RMAP-REDIST-V6HOST
redistribute direct route-map FABRIC-RMAP-REDIST-SUBNET
maximum-paths ibgp 2
applied: MY_INSTANCE_ORG:PAR001_V77
!
Applying the parameter instance for the vrf-common profile dynamically creates the VRF context with the required
Layer 3 Segment ID, route distinguisher, route targets, VRF configuration as well as the appropriate BGP address
family. Even if multiple tenants are configured, the vrf-common profile exists only once in the running
configuration.
The route-maps referenced by the redistribution commands for the host mobility manager and the direct-attached
prefix (SVI) are part of the predefined POAP leaf switch template and therefore are the same on each leaf switch.
Figure 35 shows the generated running configuration (use show run vrf ORG:PAR001 to get this output).
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 29 of 46
Figure 35.
Dynamically Generated vrf-common Profile Configuration
Example on a Leaf Switch
!
vrf context ORG:PAR001
vni 60001
rd auto
address-family ipv4 unicast
route-target import 65000:9999
route-target both auto
address-family ipv6 unicast
route-target import 65000:9999
route-target both auto
router bgp 65000
!
vrf ORG:PAR001
address-family ipv4 unicast
redistribute hmm route-map FABRIC-RMAP-REDIST-HOST
redistribute direct route-map FABRIC-RMAP-REDIST-SUBNET
maximum-paths ibgp 2
address-family ipv6 unicast
redistribute hmm route-map FABRIC-RMAP-REDIST-V6HOST
redistribute direct route-map FABRIC-RMAP-REDIST-SUBNET
maximum-paths ibgp 2
!
Calling the vrf-common profile automatically triggers an instantiation of the profile vrf-tenant-profile, including a
new generated second parameter instance, and passes the required values to vrf-tenant-profile. The vrf-tenantprofile profile creates a VLAN and SVI as part of the previously defined VRF instance and assigns the Layer 3
Segment ID (Figures 36 and 37). This VLAN and SVI are often referred as the core VLAN and SVI and are
assigned automatically from the local VLAN pool defined by the command system fabric core-vlans 2500-2999.
Figure 36.
Verification of the vrf-tenant-profile Profile with the Applied Parameter Instance
Example on a Leaf Switch
!
LEAF# show config-profile name vrf-tenant-profile
config-profile vrf-tenant-profile
vlan $vrfVlanId
vn-segment $vrfSegmentId
mode fabricpath
interface vlan $vrfVlanId
vrf member $vrfName
ip address 192.168.99.21/24
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 30 of 46
no ip redirects
ipv6 forward
no ipv6 redirects
no shutdown
applied: param_inst_60001
!
Figure 37.
Dynamically Generated vrf-tenant-profile Configuration
Example on a Leaf Switch
!
vlan 2500
mode fabricpath
vn-segment 60001
!
interface Vlan2500
no shutdown
vrf member ORG:PAR001
no ip redirects
ip address 192.168.99.21/24
ipv6 forward
no ipv6 redirects
!
Note:
The vrf-tenant-profile in NX-OS releases, starting from NX-OS 7.1(0)N1(1) is slightly different then the
vrf-tenant-profile in earlier NX-OS releases.
In Cisco Unified Fabric, a VLAN is a switch-significant resource. The VRF identification or separation within the
Cisco Unified Fabric is based on the Layer 3 Segment ID. The dynamic VLAN assignment for the 1:1 mapping
between the local core VLAN and the global Layer 3 Segment ID is chosen from a local VLAN pool. As mentioned
previously, this local VLAN pool, defined on each leaf switch, is applied during the POAP process (Figure 38). It
can be subsequently modified with the caveat that currently used VLANs cannot be removed from the pool.
Figure 38.
Default Local VLAN Pool Configuration
Example on a Leaf Switch
!
system fabric dynamic-vlans 2500-3500
system fabric core-vlans 2500-2999
!
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 31 of 46
Figure 39 shows another option for seeing which local VLAN is assigned to the Layer 3 Segment ID.
Figure 39.
Showing the Assigned VLAN Mapped to the Layer 3 Segment ID
Example on a Leaf Switch
!
LEAF# show vlan id 1-4000 vn-segment
VLAN Segment-id
---- ----------2500 60001
!
Note:
NX-OS chose the first available VLAN from the pool using a first-come, first-served approach. Different
VLAN IDs for the same fabric-significant Layer 3 Segment ID could be used for each leaf switch. However, this
local VLAN ID is not relevant for end-to-end communication within the Cisco Unified Fabric, because the
multitenancy separation is based on the Layer 3 Segment ID and not on the VLAN ID.
The last step requires configuration of the end-host-facing VLAN and SVI, including the Layer 2 Segment ID and
the appropriate fabric forwarding mode (either enhanced or traditional forwarding). The full-automation and semiautomation modes provide the capability to download the end-host-facing VLAN and SVI profile through an LDAP
request upon instantiation. However, the manual mode with the CLI using profiles and parameter lists doesn’t
provide this capability. Hence, this end-host-facing network profile must be configured manually. Figure 40 shows
an example of an end-host-facing VLAN and SVI with the pervasive IP gateway address and the forwarding mode.
Additional optional configurations (for example, DHCP relay) within the profile are supported.
Figure 40.
End-Host-Facing VLAN and SVI Profile Configuration Example
Example on a Leaf Switch
!
configure terminal
configure profile PRIVATE_LOCAL_IPv4-EF_PROFILE
vlan $vlanId
mode fabricpath
vn-segment $segmentId
!
interface vlan $vlanId
vrf member $vrfName
ip address $gatewayIpAddress/$netMaskLength tag 12345
fabric forwarding mode proxy-gateway
no ip redirects
no shutdown
!
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 32 of 46
The command shown in Figure 41 is used to verify the end-host (physical or virtual) network profile configuration.
Figure 41.
Verification of the End-Host-Facing VLAN and SVI Profile Configuration
Example on a Leaf Switch
!
LEAF# show config-profile name PRIVATE_LOCAL_IPv4-EF_PROFILE
config-profile PRIVATE_LOCAL_IPv4-EF_PROFILE
vlan $vlanId
mode fabricpath
vn-segment $segmentId
interface vlan $vlanId
vrf member $vrfName
ip address $gatewayIpAddress/$netMaskLength tag 12345
fabric forwarding mode proxy-gateway
no ip redirects
no shutdown
!
The profile example in Figures 40 and 41 uses enhanced forwarding mode along with tag 12345 for redistribution
to BGP. This method, using tag 12345, is the preferred approach for redistribution, because the same route map
can be used simultaneously for an IPv4- and IPv6-enabled network (SVI).
The last step requires the application of the previously defined and customized end-host-facing network profile with
the same parameter instance (Figures 42 and 43).
Figure 42.
Applying the Parameter Instance to the Customized End-Host-Facing VLAN and SVI Profile
Example on a Leaf Switch
!
apply profile PRIVATE_LOCAL_IPv4-EF_PROFILE param-instance
MY_INSTANCE_ORG:PAR001_V77
!
Figure 43.
Verification of the Profile with the Applied Parameter Instance
Example on a Leaf Switch
!
LEAF# show config-profile name PRIVATE_LOCAL_IPv4-EF_PROFILE
config-profile PRIVATE_LOCAL_IPv4-EF_PROFILE
vlan $vlanId
vn-segment $segmentId
mode fabricpath
!
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 33 of 46
interface vlan $vlanId
vrf member $vrfName
ip address $gatewayIpAddress/$netMaskLength tag 12345
fabric forwarding mode proxy-gateway
no ip redirects
no shutdown
applied: MY_INSTANCE_ORG:PAR001_V77
!
Figure 44 shows the resulting running configuration.
Figure 44.
Example of a Host-Facing VLAN and SVI with Layer 2 Segment ID
Example on a Leaf Switch
!
vlan 77
mode fabricpath
vn-segment 10077
!
interface Vlan77
no shutdown
vrf member ORG:PAR001
no ip redirects
ip address 10.10.77.254/24 tag 12345
fabric forwarding mode proxy-gateway
!
Recall that the leaf switch deployment through the POAP process configures the required access list and route
maps for the redistribution to BGP. This redistribution is essential for the distribution and reachability of host and
network prefixes within the Cisco Unified Fabric. Figure 45 shows this configuration.
Figure 45.
Predefined POAP Access List and Route Maps
Example on a Leaf Switch
!
ip access-list HOSTS
10 permit ip any any
ipv6 access-list V6HOSTS
10 permit ipv6 any any
!
route-map FABRIC-RMAP-REDIST-HOST deny 10
match interface Vlan99
route-map FABRIC-RMAP-REDIST-HOST permit 20
match ip address HOSTS
route-map FABRIC-RMAP-REDIST-SUBNET permit 10
match tag 12345
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 34 of 46
route-map FABRIC-RMAP-REDIST-V6HOST deny 10
match interface Vlan99
route-map FABRIC-RMAP-REDIST-V6HOST permit 20
match ip address V6HOSTS
!
Figures 46, 47, and 48 show basic verification of successful completion of configuration for a single tenant using
the manual mode with the CLI and parameter lists.
Figure 46.
Verification of the Core VLAN and SVI
Example on a Leaf Switch
!
LEAF# show run interface vlan 2500 expand-port-profile
---snip--!
interface Vlan2500
no shutdown
vrf member ORG:PAR001
no ip redirects
ip address 192.168.99.21/24
ipv6 forward
no ipv6 redirects
!
Figure 47.
Verification of the End-Host-Facing VLAN and SVI
Example on a Leaf Switch
!
LEAF# show run interface vlan 77 expand-port-profile
---snip--!
interface Vlan77
no shutdown
vrf member ORG:PAR001
no ip redirects
ip address 10.10.77.254/24 tag 12345
fabric forwarding mode proxy-gateway
!
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 35 of 46
Figure 48.
Verification of Route Redistribution to BGP
Example on a Leaf Switch
!
LEAF# show ip bgp vrf ORG:PAR001
BGP routing table information for VRF ORG:PAR001, address family IPv4 Unicast
BGP table version is 13, local router ID is 192.168.99.21
Status: s-suppressed, x-deleted, S-stale, d-dampened, h-history, *-valid, >best
Path type: i-internal, e-external, c-confed, l-local, a-aggregate, r-redist,
I-injected
Origin codes: i - IGP, e - EGP, ? - incomplete, | - multipath
Network
Next Hop
Metric
LocPrf
Weight Path
*>i0.0.0.0/0
192.168.99.31
100
0 i
*>r10.10.77.0/24
0.0.0.0
0
100
32768 ?
* i
192.168.99.22
0
100
0 ?
*>r10.10.188.0/24
0.0.0.0
0
100
32768 ?
* i
192.168.99.22
0
100
0 ?
!
Universal Profiles
The previous sections described the autoconfiguration of end-host (physical or virtual) network profiles in terms of
the way that they are created on DCNM and later instantiated on the physical leaf switch. These network profiles
require that all the “$” parameters that are part of the profile must be specified for the instantiation of the profile to
succeed on the leaf switch. Figure 49 shows an example of a default end-host-facing individual7 network profile
called defaultNetworkIpv4EfProfile, which is stored in DCNM 7.0 and downloaded to the physical leaf switch
when instantiated. When later the network operator wants to change any of the “$” parameters on DCNM, the latter
triggers a “reapply configuration” event for the leaf switches. The leaf switches on which the corresponding network
has been instantiated receive this trigger, and as a result that network profile instance is deleted and reinstantiated.
This process has a side-effect: it results in end-host traffic disruption because the entire old configuration is being
removed and the updated configuration is being reapplied.
In addition, recall that the partition profile is embedded into the network profile through an include profile vrfcommon reference at the end of the profile, where the partition profile must already be present on the leaf switch.
This stipulation somewhat reduces flexibility because if the contents of the partition profile need to be updated, the
process can be tedious. It would be better if the partition profile contents could also be downloaded on demand
from the LDAP repository as needed, without any dependence on POAP or day-zero configurations.
All these drawbacks of existing configuration profiles are addressed by the introduction of universal configuration
profiles.
7
The earlier Cisco Prime DCNM 7.0 network profiles are often called individual profiles, in contrast to the new universal
profiles.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 36 of 46
Figure 49.
Default End-Host-Facing Individual Network Profile defaultNetworkIpv4EfProfile
!
vlan $vlanId
vn-segment $segmentId
mode fabricpath
interface vlan $vlanId
vrf member $vrfName
ip address $gatewayIpAddress/$netMaskLength tag 12345
ip dhcp relay address $dhcpServerAddr use-vrf management
fabric forwarding mode proxy-gateway
no ip redirects
no shutdown
include profile vrf-common
!
With NX-OS 7.1(0)N1(1) or later, and with the support of DCNM 7.1(1) or later, universal profiles have been
introduced. Figure 50 shows an example of a universal end-host-facing network profile called
defaultNetworkUniversalEfProfile, which is stored in DCNM 7.1(1) or later and downloaded to the physical leaf
when instantiated. Note that for backward compatibility, both universal and individual network profiles are
supported.
Figure 50.
Default End-Host-Facing Universal Network Profile defaultNetworkUniversalEfProfile
!
vlan $vlanId
vn-segment $segmentId
mode fabricpath
interface vlan $vlanId
vrf member $vrfName
ip address $gatewayIpAddress/$netMaskLength tag 12345
ip dhcp relay address $dhcpServerAddr use-vrf $vrfDhcp
ipv6 address $gatewayIpv6Address/$prefixLength tag 12345
fabric forwarding mode proxy-gateway
no ip redirects
no ipv6 redirects
no shutdown
include profile any
!
These universal configuration profiles have been significantly enhanced so that you can now apply partial
configurations based on the specified “$” parameters with configuration profile refresh features. Therefore, at the
time of instantiation, the NX-OS profile manager process (PPM) runs only the commands in the configuration
profile that have the necessary “$” parameters specified. Any configuration commands that don’t have the
necessary “$” parameters will be silently ignored.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 37 of 46
Figure 50 shows a default IPv4 and IPv6 dual-stack end-host-facing universal configuration profile. Here, the “$”
parameter could be populated or ignored, depending on the network deployment requirements. For example, the
IPv6 deployment can be added when required without affecting the user traffic, because the profile will be updated
with no system degradation.
Figure 51 shows an example of an end-host-facing universal network profile with the selected universal profile
defaultNetworkUniversalEfProfile. The appendix highlights the most important network universal profiles
available in DCNM 7.1(1) or later.
Figure 51.
DCNM 7.1 Network Profile WORKLOAD-VLAN77 with the Selected Network Universal Profile
Additionally, NX-OS 7.1(0)N1(1) or later along with DCNM 7.1(1) allows the download of the VRF profile
(previously referred as the vrf-common profile). This additional LDAP query for this vrf-common-universal profile
helps ensure that the VRF configuration profile is downloaded only if it is not already present on the physical leaf
node. In earlier NX-OS releases, vrf-common and other VRF-related profiles were already part of the day-zero
POAP deployment process.
In addition, the same optional “$” parameter concept applies to the VRF profile in that only the lines in the profile in
which the “$” parameters are specified will be instantiated. The appendix highlights the most important VRF
universal profiles available in DCNM 7.1(1) or later.
The example in Figure 52 shows an organization named ORG with two partitions, named RED and BLUE, with the
selected vrf-common-universal profile.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 38 of 46
Figure 52.
DCNM 7.1 Top Pane for Creating an Organization and Partitions with the vrf-common-universal Profile
The network operator has to select the required vrf-common-universal profile when the partition is added or
edited. Figure 53 shows an example with the relevant vrf-common-universal selection marked in blue.
Figure 53.
DCNM 7.1 Partition Configuration with the vrf-common-universal Profile
The parameter include_borderLeafRt: marked in green in Figure 53 is needed for the import of the default route
originating from the border leaf for each leaf node to have a fabric exit path. The populated value 65000:9999 in
DCNM 7.1(1) or later needs to match the border leaf default route origination configuration and results in the
physical leaf node configuration for this particular VRF RED (Figure 54).
Figure 54.
Resulting Dynamic VRF RED Configuration with the VRF Import Statement
Example on a Leaf Switch
!
LEAF# show run vrf ORG:RED
---snip--vrf context ORG:RED
vni 50000
rd auto
address-family ipv4 unicast
route-target import 65000:9999
route-target both auto
address-family ipv6 unicast
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 39 of 46
route-target import 65000:9999
route-target both auto
---snip--!
The second significant universal profile enhancement is the configuration profile refresh function. The refresh
function supports the pushing of parameter updates after profile parameter changes on DCNM. When the physical
leaf switch receives a notification from DCNM about the universal profile parameter changes, the physical leaf
switch automatically pulls the updated parameters and universal profile, and the NX-OS profile manager
subsequently automatically merges the old and new parameters and profiles and reruns the necessary
configuration changes. In other words, the configuration is incrementally updated, thereby producing the desired
nondisruptive behavior, mimicking the way that a network administrator would have updated the configuration
manually.
The new refresh function is applicable for universal VRF and network universal configuration profiles, and the
refresh notification through Secure Shell (SSH) is sent from DCNM to all leaf nodes, independent of whether the
VRF or network profile is instantiated on that leaf node or not.
The new refresh feature required the introduction of the fabric database refresh command. Figures 55 and 56
respectively show the relevant commands for the refresh of the end-host network profile and the VRF universal
configuration profile.
Figure 55.
Refresh Command for the Network Universal Profile
Example on a Leaf Switch
!
LEAF# fabric database refresh vni <<VNI>>
!
Figure 56.
Refresh Command for the VRF Universal Profile
Example on a Leaf Switch
!
LEAF# fabric database refresh include-vrf <<VRF>>
!
Figures 57 and 58 present examples with refreshed parameters, showing how NX-OS merges the old and the new
configurations. Figure 57 shows a parameter list with the relevant end-host-facing network configuration without the
optional DHCP server and DHCP VRF and the resulting configuration for SVI 77. As you can see, a few “$”
arguments are not assigned values. Figure 58 depicts the updated and merged configuration when the DHCPrelated parameters are updated in the network profile, thereby resulting in a refresh that instantiates the DCHP
server and DHCP VRF configuration.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 40 of 46
Figure 57.
Initial Universal Network Profile Parameters with Resulting Configuration
Example on a Leaf Switch
!
LEAF# show fabric database host dot1q 77
instance_index 1
Got Local originated vlan type trigger at 02:18:02
Number of associated interfaces: 1
The profile will be checked for aging in 1760 seconds
Sent to Database Manager at 02:18:02
Received Parameters from Database Manager at 02:18:03
Displaying parameters for profile defaultNetworkUniversalEfProfile and instance
instance_def_77_1
parameter 0: $gatewayIpAddress=10.10.77.254
parameter 1: $netMaskLength=24
parameter 2: $vlanId=77
parameter 3: $segmentId=30077
parameter 4: $vrfName=ORG:RED
parameter 5: $gatewayIpAddress=10.10.77.254
parameter 6: $netMaskLength=24
parameter 7: $dhcpServerAddr=
parameter 8: $vrfDhcp=
parameter 9: $dhcpServerAddrBackup=
parameter 10: $gatewayIpv6Address=
parameter 11: $prefixLength=
parameter 12: $mtuValue=
parameter 13: $include_vrfSegmentId=50000
parameter 14: $vlanId=77
parameter 15: $asn=65000
Sent Apply to Configuration Manager at 02:18:04
Completed executing all commands at 02:18:06
Displaying Data Snooping Ports
Interface
Encap
Flags State
Eth101/1/1
77
L
Profile Active
LEAF#
!
!
LEAF# show run inter vlan 77 expand-port-profile
---snip--interface Vlan77
no shutdown
vrf member ORG:RED
no ip redirects
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 41 of 46
ip address 10.10.77.254/24 tag 12345
no ipv6 redirects
fabric forwarding mode proxy-gateway
!
LEAF#
Figure 58.
Refreshed Universal Network Profile Parameters with Resulting Configuration
Example on a Leaf Switch
!
LEAF# show fabric database host dot1q 77
instance_index 2
Got Local originated vlan type trigger at 02:18:02
Number of associated interfaces: 1
The profile will be checked for aging in 780 seconds
Sent to Database Manager at 02:26:22
Received Parameters from Database Manager at 02:26:22
Displaying parameters for profile defaultNetworkUniversalEfProfile and instance
instance_def_77_2
parameter 0: $gatewayIpAddress=10.10.77.254
parameter 1: $netMaskLength=24
parameter 2: $vlanId=77
parameter 3: $segmentId=30077
parameter 4: $vrfName=ORG:RED
parameter 5: $gatewayIpAddress=10.10.77.254
parameter 6: $netMaskLength=24
parameter 7: $dhcpServerAddr=192.168.100.250
parameter 8: $vrfDhcp=management
parameter 9: $dhcpServerAddrBackup=
parameter 10: $gatewayIpv6Address=
parameter 11: $prefixLength=
parameter 12: $mtuValue=
parameter 13: $include_vrfSegmentId=50000
parameter 14: $segmentId=30077
parameter 15: $vlanId=77
parameter 16: $asn=65000
This instance defaultNetworkUniversalEfProfile(2) was migrated from defaultNetwo
rkUniversalEfProfile(1)
Sent Apply to Configuration Manager at 02:26:22
Completed executing all commands at 02:26:23
Displaying Data Snooping Ports
Interface
Encap
Flags State
Eth101/1/1
77
L
Profile Active
LEAF#
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 42 of 46
!
!
LEAF#
---snip--interface Vlan77
no shutdown
vrf member ORG:RED
no ip redirects
ip address 10.10.77.254/24 tag 12345
no ipv6 redirects
fabric forwarding mode proxy-gateway
ip dhcp relay address 192.168.100.250 use-vrf management
LEAF#
Another positive side-effect of the universal profiles is a reduced number of profiles shipped with DCNM 7.1(1) or
later and updated POAP configuration templates with fewer preconfigured profiles. The overall reduced number of
end-host (physical or virtual) network profiles is a result of the hitless configuration merge and refresh option with
the newly introduced universal configuration profiles; new parameters, for example, an IPv6 gateway, can easily be
added without the need to replace an IPv4 end-host network profile (for example, defaultNetworkIpv4EfProfile)
with a dual-stack network profile (for example, defaultNetworkIPv4v6EfProfile).
Appendix
Cisco Prime DCNM 7.0 Segment ID Range Settings
The range of Segment IDs used by DCNM for assigning Layer 2 and Layer 3 (Partition) Segment IDs can be
modified in the DFA settings in the Admin section. The Layer 2 Segment ID range by default is 30’000 to 49’999
and the Layer 3 (Partition) VRF Segment ID range by default is 50’000 to 60’000 (Figure 59).
Figure 59.
Note:
DCNM Default Segment ID Range Settings
DCNM releases, starting from 7.1(1), the term “DFA” is replaced with the new term “Fabric”.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 43 of 46
Autoconfiguration and vPC+
Autoconfiguration with vPC+ provides enhanced vPC+ synchronization of end-host-triggered configuration to help
prevent inconsistent configuration states between the vPC+ peers. In deployments with the end-host connected
through a PortChannel to a vPC+ pair of leaf switches, and also with a single-homed end-host recognized as a
vPC+ orphan port, the autoconfiguration instantiation should maintain a consistent configuration on both vPC+ peer
switches to prevent vPC+ and VLAN inconsistencies. For example, a VLAN inconsistency would be reported as a
type-1 violation and would cause the suspension of that particular VLAN.
The Cisco Fabric Service over Ethernet (CFSoE) Protocol on the vPC+ peer link is responsible for synchronizing
the automatically allocated VLANs and Segment IDs during autoconfiguration instantiation to prevent vPC+
inconsistencies.
The same is true for the locally allocated end-host-facing VLAN and SVI instantiated through VDP. In this case, the
two leaf switches need to allocate the same first free available VLAN from a local pool as described previously.
Figure 60 shows an example with two single-homed end-hosts. Each end-host is connected to one of the two leaf
switches and the auto-configured profile instances are synchronized to the neighbor leaf switch. The example
shows the relevant flags (L and V) along with the synchronized end-host (physical or virtual) MAC address and
ARP entries.
Note:
When the trigger for an end-host (physical or virtual) or a set of end-hosts appears on each of the two
vPC+ leaf switches, the flag is set to LV.
Figure 60.
Verification of the Instantiated Autoconfiguration Profile with vPC+ on Leaf Switch LEAF11
Example on a Leaf Switch with vPC+
!
LEAF# show fabric database host
Active Host Entries
flags: L - Locally inserted, V - vPC+ inserted, R - Recovered
VLAN
VNI
STATE
FLAGS PROFILE(INSTANCE)
77
30000
Profile Active L
defaultNetworkIpv4EfProfile(instance_def_77_1)
!
!
LEAF# show mac address-table dynamic
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link
VLAN
MAC Address
Type
age
Secure NTFY
Ports/SWID.SSID.LID
---------+-----------------+--------+---------+------+----+-----------------* 77
0050.56b7.545f
dynamic
260
F
F
Eth101/1/1
+ 77
0050.56b7.5c83
dynamic
0
F
F
12.0.0
!
!
LEAF# show ip arp vrf ORG:RED
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 44 of 46
Flags: * - Adjacencies learnt on non-active FHRP router
+ - Adjacencies synced via CFSoE
# - Adjacencies Throttled for Glean
D - Static Adjacencies attached to down interface
IP ARP Table for context ORG:RED
Total number of entries: 2
Address
Age
MAC Address
Interface
10.10.77.215
00:05:32
0050.56b7.545f
Vlan77
10.10.77.217
00:05:43
0050.56b7.5c83
Vlan77
+
LEAF#
!
Note:
Even if the ARP and MAC address table and the configuration are consistent, pinging the end-host from
the leaf node SVI will work only from one vPC+ peer switch. This is the case because the same SVI IP address
(distributed anycast gateway) is configured on both the peers and the load-balancing decision of the PortChannel
hash between the leaf switch and the end-host will always result in the traffic going to a particular peer (note that
the packet will have the same destination MAC, destination IP resulting in the receiving peer consuming that
packet).
Cisco Prime DCNM Network Autoconfiguration Profiles
DCNM comes with many end-host (physical or virtual) autoconfiguration network profiles. Table 5 and Table 6
summarize the most important profiles.
Table 5.
Preconfigured DCNM 7.0 Individual Network Autoconfiguration Profiles
Profile Name
Description
defaultNetworkIPv4EfProfile
Profile for an IPv4 enabled network segment in the non-default partition with DFA enhanced forwarding mode.
defaultNetworkIPv6EfProfile
Profile for an IPv6 enabled network segment in the non-default partition with DFA enhanced forwarding mode.
defaultNetworkIPv4v6EfProfile Profile for an IPv4 and IPv6 enabled network segment in the non-default partition with DFA enhanced
forwarding mode.
defaultNetworkIPv4TfProfile
Profile for an IPv4 enabled network segment in the non-default partition with DFA traditional forwarding mode.
defaultNetworkIPv6TfProfile
Profile for an IPv6 enabled network segment in the non-default partition with DFA traditional forwarding mode.
defaultNetworkIPv4v6TfProfile Profile for an IPv4 and IPv6 enabled network segment in the non-default partition with DFA traditional
forwarding mode.
defaultNetworkL2Profile
Table 6.
Profile Name
Profile for L2 network segment where DFA L3 routing is not enabled. Another node (service node or router)
attached to a leaf node can do the routing as needed.
Preconfigured DCNM 7.1 Universal Network Autoconfiguration Profiles
Description
defaultNetworkUniversalEfProfile Universal profile for a network in DFA enhanced forwarding mode.
defaultNetworkUniversalTfProfile Universal0020profile for a network in DFA traditional forwarding mode.
Cisco Prime DCNM VRF Autoconfiguration Profiles
The VRF autoconfiguration profiles are part of the new DCNM 7.1(1) or later and will be download and instantiate
upon request from the physical leaf switch. In earlier version of the DCNM were these profiles already configured
through the day-zero POAP deployment process.
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
Page 45 of 46
Table 7.
Preconfigured DCNM 7.1 Universal VRF Autoconfiguration Profiles
Profile Name
Description
vrf-common-universal
Universal profile for a DFA partition.
vrf-common-universal-dynamic-LB-ES
Universal profile for a with service network service used for both a Load Balancer and/or an
Edge Service in routed mode with dynamic routing.
vrf-common-universal-static
Universal profile for a partition with a service node which requires static routing.
vrf-common-universal-external-static
Universal profile for an external partition with a service network segment used for Edge Service
node with static routing.
vrf-common-universal-external-dynamic-ES
Universal profile for an external partition with a service network segment used for Edge Service
node with dynamic routing.
Printed in USA
© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information.
C11-733395-01
07/15
Page 46 of 46