The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter contains the following sections:
Tenants can be isolated from one another or can share resources. The primary elements that the tenant contains are filters, contracts, outside networks, bridge domains, contexts, and application profiles that contain endpoint groups (EPGs). Entities in the tenant inherit its policies. A tenant can contain one or more virtual routing and forwarding (VRF) instances or contexts; each context can be associated with multiple bridge domains.
Note | In the APIC GUI under the tenant navigation path, a context (VRF) is called a private network. |
Tenants are logical containers for application policies. The fabric can contain multiple tenants. You must configure a tenant before you can deploy any Layer 4 to Layer 7 services. The ACI fabric supports IPv4, IPv6, and dual-stack configurations for tenant networking.
The Application Centric Infrastructure (ACI) fabric provide tenant default gateway functionality and route between the fabric virtual extensible local area (VXLAN) networks. For each tenant, the fabric provides a virtual default gateway or Switched Virtual Interface (SVI) whenever a subnet is created on the APIC. This spans any switch that has a connected endpoint for that tenant subnet. Each ingress interface supports the default gateway interface and all of the ingress interfaces across the fabric share the same router IP address and MAC address for a given tenant subnet.
The Layer 3 VNID is allocated by the APIC. The traffic that goes across the fabric is transported using the VNID of the Layer 3 segment. In the egress leaf switch, the packet is routed from the Layer 3 segment VNID to the VNID of the egress subnet.
The ACI model provides very efficient forwarding in the fabric for the traffic that is routed within the tenant. For example, the traffic between two virtual machines (VM) that belongs to the same tenant on the same physical host, but on different subnets travels only to the ingress switch before it is routed (using the minimal path cost) to the correct destination. In the current VM environments, the traffic travels to an edge VM (possibly on a different physical server) before it is routed to the correct destination.
The routes that are learned through peering are sent to the spine switches. The spine switches act as route reflectors and distribute the external routes to all of the leaf switches that have interfaces that belong to the same tenant. These routes are longest prefix match (LPM) summarized addresses and are placed in the leaf switch's forwarding table with the VTEP IP address of the remote leaf switch where the external router is connected. WAN routes have no forwarding proxy. If the WAN routes do not fit in the leaf switch's forwarding table, the traffic is dropped. Because the external router is not the default gateway, packets from the tenant endpoints (EPs) are sent to the default gateway in the ACI fabric.
The ACI fabric is unaware of the presence of the external router and the APIC statically assigns the leaf switch interface to its EPG.
The ACI fabric route reflectors use multiprotocol BGP (MP-BGP) to distribute external routes within the fabric. To enable route reflectors in the ACI fabric, the fabric administrator must select the spine switches that will be the route reflectors, and provide the autonomous system (AS) number. Once route reflectors are enabled in the ACI fabric, administrators can configure connectivity to external networks as described in the following sections.
To connect external routers to the ACI fabric, the fabric infrastructure administrator configures spine nodes as Border Gateway Protocol (BGP) route reflectors. For redundancy purposes, more than one spine is configured as a router reflector node (one primary and one secondary reflector).
When a tenant needs to attach a WAN router to the ACI fabric, the infrastructure administrator configures the leaf node (as described below) to which the WAN router is being connected as WAN top of rack (ToR) and pairs this WAN ToR with one of the route reflector nodes as a BGP peer. When route reflectors are configured on the WAN ToR, they are able to advertise the tenant routes into the fabric.
Each leaf node can store up to 4000 routes. If a WAN router has to advertise more than 4000 routes, it should peer with multiple leaf nodes. The infrastructure administrator configures each of the paired leaf nodes with the routes (or route prefixes) that it can advertise.
The infrastructure administrator must configure an external WAN router connected to the fabric as follows:
Configure up to two spine nodes as route reflectors. For redundancy, configure primary and secondary route reflectors.
On WAN ToRs, configure the primary and secondary route reflector nodes.
On WAN ToRs, configure the routes that the ToR is responsible for advertising. This is optional and needs to be done only when the tenant router is known to advertise more than 4000 routes.
Before you can distribute the static route to the other leaf switches on the Application Centric Infrastructure (ACI) fabric, a multiprotocol BGP (MP-BGP) process must first be operating, and the spine switches must be configured as BGP route reflectors.
To integrate the ACI fabric into an external routed network, you can configure Open Shortest Path First (OSPF) for management tenant Layer 3 connectivity.
Note | To watch an example video of this task, see Videos Webpage. |
You must verify that the router ID and the logical interface profile IP address are different and do not overlap.
The following steps are for creating an OSPF external routed network for a management tenant. To create an OSPF external routed network for a tenant, you must choose a tenant and create a VRF for the tenant.
For more details, see also the KB article about Transit Routing.
Note | To watch an example video of this task, see Videos Webpage. |
Step 1 | On the menu bar, choose . |
Step 2 | In the Navigation pane, expand . |
Step 3 | Right-click External Routed Networks, and click Create Routed Outside. |
Step 4 | In the
Create
Routed Outside dialog box, perform the following actions:
|
Step 5 | In the
Create
Node Profile dialog box, perform the following actions:
|
Step 6 | In the Create Node Profile dialog box, in the OSPF Interface Profiles area, click the + icon. |
Step 7 | In the
Create
Interface Profile dialog box, perform the following tasks:
|
Step 8 | In the Create Node Profile dialog box, click OK. |
Step 9 | In the Create Routed Outside dialog box, click Next. The Step 2 External EPG Networks area is displayed. |
Step 10 | In the External EPG Networks area, click the + icon. |
Step 11 | In the
Create
External Network dialog box, perform the following actions:
|
Step 1 | Mark the spine
switches as route reflectors.
Example: POST URL: https://apic-ip/api/policymgr/mo/uni/fabric.xml <bgpInstPol name="default"> <bgpAsP asn="1" /> <bgpRRP> <bgpRRNodePEp id=“<spine_id1>”/> <bgpRRNodePEp id=“<spine_id2>”/> </bgpRRP> </bgpInstPol> |
Step 2 | Set up the pod
selector using the following post.
Example: For the FuncP setup— POST URL: https://APIC-IP/api/policymgr/mo/uni.xml <fabricFuncP> <fabricPodPGrp name="bgpRRPodGrp”> <fabricRsPodPGrpBGPRRP tnBgpInstPolName="default" /> </fabricPodPGrp> </fabricFuncP> Example: For the PodP setup— POST URL: https://APIC-IP/api/policymgr/mo/uni.xml <fabricPodP name="default"> <fabricPodS name="default" type="ALL"> <fabricRsPodPGrp tDn="uni/fabric/funcprof/podpgrp-bgpRRPodGrp"/> </fabricPodS> </fabricPodP> |
Step 1 | Verify the
configuration by performing the following actions:
|
Step 2 | Verify that the
autonomous system number is configured in the spine switches by performing the
following actions:
|
Creating Tenants, VRF, and Bridge Domains
A tenant contains policies that enable qualified users domain-based access control. Qualified users can access privileges such as tenant administration and networking administration.
A user requires read/write privileges for accessing and configuring policies in a domain. A tenant user can have specific privileges into one or more domains.
In a multitenancy environment, a tenant provides group user access privileges so that resources are isolated from one another (such as for endpoint groups and networking). These privileges also enable different users to manage different tenants.
A tenant contains primary elements such as filters, contracts, bridge domains, and application profiles that you can create after you first create a tenant.
You can create and specify a VRF and a bridge domain for the tenant. The defined bridge domain element subnets reference a corresponding Layer 3 context.
For details about enabling IPv6 Neighbor Discovery see the related KB article, KB: Creating a Tenant, VRF, and Bridge Domain with IPv6 Neighbor Discovery .
To watch an example video of this task, see Videos Webpage.
If you have a public subnet when you configure the routed outside, you must associate the bridge domain with the outside configuration.
Step 1 | On the menu bar, click . |
Step 2 | In the Create Tenant dialog box, perform the following tasks: |
Step 3 | In the Navigation pane, expand , and in the Work pane, drag the VRF icon to the canvas to open the Create VRF dialog box, and perform the following tasks: |
Step 4 | In the Networking pane, drag the BD icon to the canvas while connecting it to the VRF icon. In the Create Bridge Domain dialog box that displays, perform the following tasks: |
Step 5 | In the
Networks pane, drag the
L3 icon down to the canvas while connecting it to
the
VRF icon. In the
Create
Routed Outside dialog box that displays, perform the following
tasks:
|
Deploying an Application Policy
As traffic enters the leaf switch from the front panel interfaces, the packets are marked with the EPG of the source EPG. The leaf switch then performs a forwarding lookup on the packet destination IP address within the tenant space. A hit can result in any of the following scenarios:
A unicast (/32) hit provides the EPG of the destination endpoint and either the local interface or the remote leaf switch VTEP IP address where the destination endpoint is present.
A unicast hit of a subnet prefix (not /32) provides the EPG of the destination subnet prefix and either the local interface or the remote leaf switch VTEP IP address where the destination subnet prefix is present.
A multicast hit provides the local interfaces of local receivers and the outer destination IP address to use in the VXLAN encapsulation across the fabric and the EPG of the multicast group.
Note | Multicast and external router subnets always result in a hit on the ingress leaf switch. Security policy enforcement occurs as soon as the destination EPG is known by the ingress leaf switch. |
A miss result in the forwarding table causes the packet to be sent to the forwarding proxy in the spine switch. The forwarding proxy then performs a forwarding table lookup. If it is a miss, the packet is dropped. If it is a hit, the packet is sent to the egress leaf switch that contains the destination endpoint. Because the egress leaf switch knows the EPG of the destination, it performs the security policy enforcement. The egress leaf switch must also know the EPG of the packet source. The fabric header enables this process because it carries the EPG from the ingress leaf switch to the egress leaf switch. The spine switch preserves the original EPG in the packet when it performs the forwarding proxy function.
On the egress leaf switch, the source IP address, source VTEP, and source EPG information are stored in the local forwarding table through learning. Because most flows are bidirectional, a return packet populates the forwarding table on both sides of the flow, which enables the traffic to be ingress filtered in both directions.
In the ACI security model, contracts contain the policies that govern the communication between EPGs. The contract specifies what can be communicated and the EPGs specify the source and destination of the communications. Contracts link EPGs, as shown below.
EPG 1 --------------- CONTRACT --------------- EPG 2
Endpoints in EPG 1 can communicate with endpoints in EPG 2 and vice versa if the contract allows it. This policy construct is very flexible. There can be many contracts between EPG 1 and EPG 2, there can be more than two EPGs that use a contract, and contracts can be reused across multiple sets of EPGs, and more.
There is also directionality in the relationship between EPGs and contracts. EPGs can either provide or consume a contract. An EPG that provides a contract is typically a set of endpoints that provide a service to a set of client devices. The protocols used by that service are defined in the contract. An EPG that consumes a contract is typically a set of endpoints that are clients of that service. When the client endpoint (consumer) tries to connect to a server endpoint (provider), the contract checks to see if that connection is allowed. Unless otherwise specified, that contract would not allow a server to initiate a connection to a client. However, another contract between the EPGs could easily allow a connection in that direction.
This providing/consuming relationship is typically shown graphically with arrows between the EPGs and the contract. Note the direction of the arrows shown below.
EPG 1 <-------consumes-------- CONTRACT <-------provides-------- EPG 2
These same constructs also apply for policies that govern virtual machine hypervisors. When an EPG is placed in a virtual machine manager (VMM) domain, the APIC downloads all of the policies that are associated with the EPG to the leaf switches with interfaces connecting to the VMM domain. For a full explanation of VMM domains, see the Virtual Machine Manager Domains chapter of the ACI Fundamentals manual. When this policy is created, the APIC pushes it (pre-populates it) to a VMM domain that specifies which switches allow connectivity for the endpoints in the EPGs. The VMM domain defines the set of switches and ports that allow endpoints in an EPG to connect to. When an endpoint comes on-line, it is associated with the appropriate EPGs. When it sends a packet, the source EPG and destination EPG are derived from the packet and the policy defined by the corresponding contract is checked to see if the packet is allowed. If yes, the packet is forwarded. If no, the packet is dropped.
The contract also allows more complex actions than just allow or deny. The contract can specify that traffic that matches a given subject can be re-directed to a service, can be copied, or can have its QoS level modified. With pre-population of the access policy in the concrete model, endpoints can move, new ones can come on-line, and communication can occur even if the APIC is off-line or otherwise inaccessible. The APIC is removed from being a single point of failure for the network. Upon packet ingress to the ACI fabric, security policies are enforced by the concrete model running in the switch.
A filter specifies the data protocols to be allowed or denied by a contract that contains the filter. A contract can contain multiple subjects. A subject can be used to realize uni- or bidirectional filters. A unidirectional filter is a filter that is used in one direction, either from consumer-to-provider (IN) or from provider-to-consumer (OUT) filter. A bidirectional filter is the same filter that is used in both directions. It is not reflexive.
Contracts are policies that enable inter-End Point Group (inter-EPG) communication. These policies are the rules that specify communication between application tiers. If no contract is attached to the EPG, inter-EPG communication is disabled by default. No contract is required for intra-EPG communication because intra-EPG communication is always allowed.
Application profiles enable you to model application requirements that the APIC then automatically renders in the network and data center infrastructure. The application profiles enable administrators to approach the resource pool in terms of applications rather than infrastructure building blocks. The application profile is a container that holds EPGs that are logically related to one another. EPGs can communicate with other EPGs in the same application profile and with EPGs in other application profiles.
To deploy an application policy, you must create the required application profiles, filters, and contracts. Typically, the APIC fabric hosts a three-tier application within a tenant network. In this example, the application is implemented by using three servers (a web server, an application server, and a database server). See the following figure for an example of a three-tier application.
The web server has the HTTP filter, the application server has the Remote Method Invocation (RMI) filter, and the database server has the Structured Query Language (SQL) filter. The application server consumes the SQL contract to communicate with the database server. The web server consumes the RMI contract to communicate with the application server. The traffic enters from the web server and communicates with the application server. The application server then communicates with the database server, and the traffic can also communicate externally.
The parameters to create a filter for http in this example is as follows:
Parameter Name | Filter for http |
---|---|
Name |
http |
Number of Entries |
2 |
Entry Name |
Dport-80 Dport-443 |
Ethertype |
IP |
Protocol |
tcp tcp |
Destination Port |
http https |
The parameters to create filters for rmi and sql in this example are as follows:
Parameter Name | Filter for rmi | Filter for sql |
---|---|---|
Name |
rmi |
sql |
Number of Entries |
1 |
1 |
Entry Name |
Dport-1099 |
Dport-1521 |
Ethertype |
IP |
IP |
Protocol |
tcp |
tcp |
Destination Port |
1099 |
1521 |
The application profile database in this example is as follows:
EPG | Provided Contracts | Consumed Contracts |
---|---|---|
web |
web |
rmi |
app |
rmi |
sql |
db |
sql |
-- |
Deploying an Application Policy Using the GUI
Create three separate filters. In this example they are HTTP, RMI, SQL. This task shows how to create the HTTP filter. The task is identical for creating the other filters.
Verify that the tenant, network, and bridge domain have been created.
Step 1 | On the menu
bar, choose
TENANTS. In the
Navigation pane, expand the
, right-click
Filters, and click
Create
Filter.
| ||
Step 2 | In the
Create
Filter dialog box, perform the following actions:
| ||
Step 3 | Expand Entries in the Name field. Follow the same process to add another entry with HTTPS as the Destination port, and click Update. This new filter rule is added. | ||
Step 4 | Follow the same process in the earlier steps to create two more filters (rmi and sql) and use the parameters provided in Parameters to Create Filters for rmi and sql. |
Step 1 | On the menu bar, choose TENANTS and the tenant name on which you want to operate. In the Navigation pane, expand the . | ||
Step 2 | Right-click . | ||
Step 3 | In the
Create
Contract dialog box, perform the following tasks:
| ||
Step 4 | In the Create Contract Subject dialog box, click OK. | ||
Step 5 | Create two more contracts for rmi and for sql following the same steps in this procedure. For the rmi contract, choose the rmi subject and for sql, choose the sql subject. |
The port the EPG uses must belong to one of the VM Managers (VMM) or physical domains associated with the EPG.
Step 1 | Expand
EPGs. In the
Create
Application EPG dialog box, perform the following actions:
|
Step 2 | In the Create Application Profile dialog box, create two more EPGs. The three EPGs should be db, app, and web in the same bridge domain and data center. |
You can associate contracts that were created earlier to create policy relationships between the EPGs.
When you name the provided and consumed contracts, verify that you give the same name for both provided and consumed contracts.
Step 1 |
| ||
Step 2 | In the Name field, from the drop-down list, choose sql contract. Click OK. This step enables the db EPG to provide the sql contract and the app EPG to consume the sql contract. | ||
Step 3 | Click and drag across the APIC GUI screen from the app ePG to the web EPG. The Add Consumed Contract dialog box is displayed. | ||
Step 4 | In the Name field, from the drop-down list, choose rmi contract. Click OK. This step enables the app EPG to provide the rmi contract and the web EPG to consume the rmi contract. | ||
Step 5 | Click the web EPG icon, and click the + sign in the Provided Contracts area. The Add Provided Contract dialog box is displayed. | ||
Step 6 | In the Name field, from the drop-down list, choose web contract. Click OK. Click Submit. You have created a three-tier application profile called OnlineStore. | ||
Step 7 | To verify, in the Navigation pane, navigate to and click OnlineStore under Application Profiles. In the Work pane, you can see the three EPGs app, db, and web are displayed. | ||
Step 8 | In the Work pane, choose . You can see the EPGs and contracts displayed in the order that they are consumed and provided. |
This topic provides a typical example of how to statically deploy an EPG on a specific port when using Cisco APIC.
The tenant where you deploy the EPG is already created.
Step 1 | On the menubar, click TENANTS. |
Step 2 | In the Navigation pane, expand the appropriate . |
Step 3 | Right-click Application Profiles and click Create Application Profile. |
Step 4 | In the
Create Application Profile dialog box, perform
the following actions:
|
Step 5 | In the Navigation pane, expand Application Profiles to view the new application profile. |
Step 6 | Expand Application EPGs, to view the new EPG. |
Step 7 | Expand the EPG and click Static Bindings (Paths), and in the Work pane, view the details of the static binding paths that are established. |
Step 1 | Configure a
VLAN domain:
Example: apic1(config)# vlan-domain dom1 apic1(config-vlan)# vlan 10-100
| ||
Step 2 | Create a
tenant:
Example: apic1# configure apic1(config)# tenant t1
| ||
Step 3 | Create a
private network/VRF:
Example: apic1(config-tenant)# vrf context ctx1 apic1(config-tenant-vrf)# exit
| ||
Step 4 | Create a
bridge domain:
Example: apic1(config-tenant)# bridge-domain bd1 apic1(config-tenant-bd)# vrf member ctx1 apic1(config-tenant-bd)# exit
| ||
Step 5 | Create an
application profile and an application EPG:
Example: apic1(config-tenant)# application AP1 apic1(config-tenant-app)# epg EPG1 apic1(config-tenant-app-epg)# bridge-domain member bd1 apic1(config-tenant-app-epg)# exit apic1(config-tenant-app)# exit apic1(config-tenant)# exit
| ||
Step 6 | Associate the
EPG with a specific port:
Example: apic1(config)# leaf 1017 apic1(config-leaf)# interface ethernet 1/13 apic1(config-leaf-if)# vlan-domain member dom1 apic1(config-leaf-if)# switchport trunk allowed vlan 20 tenant t1 application AP1 epg EPG1
|
The tenant where you deploy the EPG is created.
Example: <fvTenant name="<tenant_name>" dn="uni/tn-test1" > <fvCtx name="<network_name>" pcEnfPref="enforced" knwMcastAct="permit"/> <fvBD name="<bridge_domain_name>" unkMcastAct="flood" > <fvRsCtx tnFvCtxName="<network_name>"/> </fvBD> <fvAp name="<application_profile>" > <fvAEPg name="<epg_name>" > <fvRsPathAtt tDn="topology/pod-1/paths-1017/pathep-[eth1/13]" mode="regular" instrImedcy="immediate" encap="vlan-20"/> </fvAEPg> </fvAp> </fvTenant> |
This topic provides a typical example of how to create physical domains, Attach Entity Profiles (AEP), and VLANs that are mandatory to deploy an EPG on a specific port.
Note | All endpoint groups (EPGs) require a domain. Interface policy groups must also be associated with Attach Entity Profile (AEP), and the AEP must be associated with a domain, if the AEP and EPG have to be in same domain. Based on the association of EPGs to domains and of interface policy groups to domains, the ports and VLANs that the EPG uses are validated. The following domain types associate with EPGs:
The APIC checks if an EPG is associated with one or more of these types of domains. If the EPG is not associated, the system accepts the configuration but raises a fault. The deployed configuration may not function properly if the domain association is not valid. For example, if the VLAN encapsulation is not valid for use with the EPG, the deployed configuration may not function properly. |
Step 1 | On the menu bar, click . |
Step 2 | In the Navigation pane, click Quick Start. |
Step 3 | In the Work pane, click Configure an interface, PC, and vPC. |
Step 4 | In the
Configure Interface, PC, and vPC dialog box, click
the
+ icon to select switches and perform the following
actions:
|
Step 5 | On the menu
bar, click
TENANTS. In the
Navigation pane, expand the appropriate
and perform the
following actions:
The switch profile and the interface profile are created. The policy group is created in the port block under the interface profile. The AEP is automatically created, and it is associated with the port block and with the domain. The domain is associated with the VLAN pool and the Tenant is associated with the domain. |
Step 1 | Create a VLAN
domain and assign VLAN ranges:
Example: apic1(config)# vlan-domain domP apic1(config-vlan)# vlan 10 apic1(config-vlan)# vlan 25 apic1(config-vlan)# vlan 50-60 apic1(config-vlan)# exit |
Step 2 | Create an
interface policy group and assign a VLAN domain to the policy group:
Example: apic1(config)# template policy-group PortGroup apic1(config-pol-grp-if)# vlan-domain member domP |
Step 3 | Create a
leaf interface profile, assign an interface policy group to the profile, and
assign the interface IDs on which the profile will be applied:
Example: apic1(config)# leaf-interface-profile InterfaceProfile1 apic1(config-leaf-if-profile)# leaf-interface-group range apic1(config-leaf-if-group)# policy-group PortGroup apic1(config-leaf-if-group)# interface ethernet 1/11-13 apic1(config-leaf-if-profile)# exit |
Step 4 | Create a
leaf profile, assign the leaf interface profile to the leaf profile, and
assign the leaf IDs on which the profile will be applied:
Example: apic1(config)# leaf-profile SwitchProfile-1019 apic1(config-leaf-profile)# leaf-interface-profile InterfaceProfile1 apic1(config-leaf-profile)# leaf-group range apic1(config-leaf-group)# leaf 1019 apic1(config-leaf-group)# |
Step 1 | Create the
interface profile, switch profile and the Attach Entity Profile (AEP).
Example: <infraInfra> <infraNodeP name="<switch_profile_name>" dn="uni/infra/nprof-<switch_profile_name>" > <infraLeafS name="SwitchSeletor" descr="" type="range"> <infraNodeBlk name="nodeBlk1" descr="" to_="1019" from_="1019"/> </infraLeafS> <infraRsAccPortP tDn="uni/infra/accportprof-<interface_profile_name>"/> </infraNodeP> <infraAccPortP name="<interface_profile_name>" dn="uni/infra/accportprof-<interface_profile_name>" > <infraHPortS name="portSelector" type="range"> <infraRsAccBaseGrp tDn="uni/infra/funcprof/accportgrp-<port_group_name>" fexId="101"/> <infraPortBlk name="block2" toPort="13" toCard="1" fromPort="11" fromCard="1"/> </infraHPortS> </infraAccPortP> <infraAccPortGrp name="<port_group_name>" dn="uni/infra/funcprof/accportgrp-<port_group_name>" > <infraRsAttEntP tDn="uni/infra/attentp-<attach_entity_profile_name>"/> <infraRsHIfPol tnFabricHIfPolName="1GHifPol"/> </infraAccPortGrp> <infraAttEntityP name="<attach_entity_profile_name>" dn="uni/infra/attentp-<attach_entity_profile_name>" > <infraRsDomP tDn="uni/phys-<physical_domain_name>"/> </infraAttEntityP> <infraInfra> |
Step 2 | Create a domain.
Example: <physDomP name="<physical_domain_name>" dn="uni/phys-<physical_domain_name>"> <infraRsVlanNs tDn="uni/infra/vlanns-[<vlan_pool_name>]-static"/> </physDomP> |
Step 3 | Create a VLAN
range.
Example: <fvnsVlanInstP name="<vlan_pool_name>" dn="uni/infra/vlanns-[<vlan_pool_name>]-static" allocMode="static"> <fvnsEncapBlk name="" descr="" to="vlan-25" from="vlan-10"/> </fvnsVlanInstP> |
Step 4 | Associate the
EPG with the domain.
Example: <fvTenant name="<tenant_name>" dn="uni/tn-" > <fvAEPg prio="unspecified" name="<epg_name>" matchT="AtleastOne" dn="uni/tn-test1/ap-AP1/epg-<epg_name>" descr=""> <fvRsDomAtt tDn="uni/phys-<physical_domain_name>" instrImedcy="immediate" resImedcy="immediate"/> </fvAEPg> </fvTenant> |