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.
Part I: Layer 3 Configuration
The tenant, VRF, and bridge domain are created.
|
Configure common pervasive gateway. In the following example REST API XML, the bolded text is relevant to configuring a common pervasive gateway. Example: |
This section explains how to enable and disable the IP aging policy using the REST API.
| Step 1 |
To enable the IP aging policy: Example: |
| Step 2 |
To disable the IP aging policy: Example: |
To specify the interval used for tracking IP addresses on endpoints, create an Endpoint Retention policy by sending a post with XML such as the following example:
<fvEpRetPol bounceAgeIntvl="630" bounceTrig="protocol"
holdIntvl="350" lcOwn="local" localEpAgeIntvl="900" moveFreq="256"
name="EndpointPol1" remoteEpAgeIntvl="350"/>When creating the subnet for the static route, it is configured under the EPG (fvSubnet object under fvAEPg), associated with the pervasive BD (fvBD), not the BD itself.
The subnet mask must be /32 (/128 for IPv6) pointing to one IP address or one endpoint. It is contained in the EPG associated with the pervasive BD.
The tenant, VRF, BD, and EPG have been created.
|
To configure a static route for the BD used in a pervasive gateway, enter a post such as the following example: Example: |
|
Create a tenant, VRF, bridge domain with a neighbor discovery interface policy and a neighbor discovery prefix policy. Example:
|
|
Configure an IPv6 neighbor discovery interface policy and associate it with a Layer 3 interface: The following example displays the configuration in a non-VPC set up. Example:
|
| Step 1 |
Disable the Neighbor Discovery Duplicate Address Detection process for a subnet by changing the value of the ipv6Dad entry for that subnet to disabled. The following example shows how to set the Neighbor Discovery Duplicate Address Detection entry for the 2001:DB8:A::11/64 subnet to disabled:
Example: |
||
| Step 2 |
Enter the show ipv6 int command on the leaf switch to verify that the configuration was pushed out correctly to the leaf switch. For example: |
|
To configure Microsoft NLB in unicast mode, send a post with XML such as the following example: Example: |
|
To configure Microsoft NLB in multicast mode, send a post with XML such as the following example: Example: |
|
To configure Microsoft NLB in IGMP mode, send a post with XML such as the following example: Example: |
|
To configure an IGMP Snooping policy and assign it to a bridge domain, send a post with XML such as the following example: Example:This example creates and configures the IGMP Snooping policy, igmp_snp_bd_12 with the following properties, and binds the IGMP policy, igmp_snp_bd_21, to bridge domain, bd_21:
|
You can enable IGMP snooping and multicast processing on ports that have been statically assigned to an EPG. You can create and assign access groups of users that are permitted or denied access to the IGMP snoop and multicast traffic enabled on those ports.
|
To configure application EPGs with static ports, enable those ports to receive and process IGMP snooping and multicast traffic, and assign groups to access or be denied access to that traffic, send a post with XML such as the following example. In the following example, IGMP snooping is enabled on Example: |
After you have enabled IGMP snooping and multicast on ports that have been statically assigned to an EPG, you can then create and assign access groups of users that are permitted or denied access to the IGMP snooping and multicast traffic enabled on those ports.
|
To define the access group, The example configures access group Example: |
|
To configure an MLD Snooping policy and assign it to a bridge domain, send a post with XML such as the following example: Example:This example creates and configures the MLD Snooping policy mldsn with the following properties, and binds the MLD policy mldsn-it-fabric-querier-policy to bridge domain mldsn-bd3:
|
| Step 1 |
Configure a tenant and VRF and enable multicast on a VRF. Example: |
||
| Step 2 |
Configure L3 Out and enable multicast (PIM, IGMP) on the L3 Out. Example: |
||
| Step 3 |
Configure a BD under the tenant and enable multicast and IGMP on the BD. Example: |
||
| Step 4 |
Configure an IGMP policy and assign it to the BD. Example: |
||
| Step 5 |
Configure a route map, PIM, and RP policy on the VRF.
Example:Configuring a fabric RP: |
||
| Step 6 |
Configure a PIM interface policy and apply it on the L3 Out. Example: |
||
| Step 7 |
Configure inter-VRF multicast. Example: |
The desired VRF, bridge domains, Layer 3 Out interfaces with IPv6 addresses must be configured to enable PIM6. For Layer 3 Out, for IPv6 multicast to work, an IPv6 loopback address is configured for the node in the logical node profile.
Basic unicast network must be configured.
| Step 1 |
Enable PIM6 on the VRF. Example: |
| Step 2 |
Enable PIM6 on the Layer 3 Out. Example: |
| Step 3 |
Enable PIM6 on the BD. Example: |
| Step 4 |
Configure Static Rendezvous Point. Example: |
| Step 5 |
Configure a PIM6 interface policy and apply it on the Layer 3 Out. Example: |
You will be configuring multicast filtering at the bridge domain level. Use the procedures in this topic to configure either source filtering or receiver filtering, or both, at the bridge domain level.
The bridge domain where you will be configuring multicast filtering is already created.
The bridge domain is a PIM-enabled bridge domain.
Layer 3 multicast is enabled at the VRF level.
| Step 1 |
If you want to enable multicast source filtering on the bridge domain, send a post with XML such as the following example: Example: |
||
| Step 2 |
If you want to enable multicast receiver filtering on the bridge domain, send a post with XML such as the following example: Example:
|
| Step 1 |
Login to Cisco APIC: Example: |
| Step 2 |
Configure the TEP pool: Example: |
| Step 3 |
Configure the node ID policy: Example: |
| Step 4 |
Configure infra L3Out and external connectivity profile: Example: |
To enable Cisco APIC to discover and connect the IPN router and remote leaf switches, perform the steps in this topic.
This example assumes that the remote leaf switches are connected to a pod in a multipod topology. It includes two L3Outs configured in the infra tenant, with VRF overlay-1:
One is configured on VLAN-4, that is required for both the remote leaf switches and the spine switch that is connected to the WAN router.
One is the multipod-internal L3Out configured on VLAN-5, that is required for the multipod and Remote Leaf features, when they are deployed together.
| Step 1 |
To define the TEP pool for two remote leaf switches to be connected to a pod, send a post with XML such as the following example: Example: |
||
| Step 2 |
To define the node identity policy, send a post with XML, such as the following example: Example: |
||
| Step 3 |
To configure the Fabric External Connection Profile, send a post with XML such as the following example: Example: |
||
| Step 4 |
To configure an L3Out on VLAN-4, that is required for both the remote leaf switches and the spine switch connected to the WAN router, enter XML such as the following example. Example: |
||
| Step 5 |
For releases prior to Release 4.1(2), to configure the multipod L3Out on VLAN-5, that is required for both multipod and the remote leaf topology, send a post such as the following example.
Example: |
The SR-MPLS infra L3Out is configured on the border leaf switch, which is used to set up the underlay BGP-LU and overlay MP-BGP EVPN sessions that are needed for the SR-MPLS handoff.
An SR-MPLS infra L3Out will be scoped to a pod or a remote leaf switch site.
Border leaf switches or remote leaf switches in one SR-MPLS infra L3Out can connect to one or more provider edge (PE) routers in one or more routing domains.
A pod or remote leaf switch site can have one or more SR-MPLS infra L3Outs.
Each SR-MPLS infra L3Out should have a unique provider label and one provider label only. Each SR-MPLS infra L3Out is identified by the provider label.
You will configure the following pieces when configuring the SR-MPLS infra L3Out:
Nodes
Only leaf switches are allowed to be configured as nodes in the SR-MPLS infra L3Out (border leaf switches and remote leaf switches).
Each SR-MPLS infra L3Out can have border leaf switches from one pod or remote leaf switch from the same site.
Each border leaf switch or remote leaf switch can be configured in multiple SR-MPLS infra L3Outs if it connects to multiple SR-MPLS domains.
You will also configure the loopback interface underneath the node, and a node SID policy underneath the loopback interface.
Interfaces
Supported types of interfaces are:
Routed interface or sub-interface
Routed port channel or port channel sub-interface
For sub-interfaces, any VLAN tag is supported.
You will also configure the underlay BGP peer policy underneath the interfaces area in the SR-MPLS infra L3Out.
QoS rules
You can configure the MPLS ingress rule and MPLS egress rule through the MPLS QoS policy in the SR-MPLS infra L3Out.
If you do not create an MPLS QoS policy, any ingressing MPLS traffic is assigned the default QoS level.
You will also configure the underlay and overlay through the SR-MPLS infra L3Out:
Underlay: BGP peer IP (BGP LU peer) configuration as part of the interface configuration.
Overlay: MP-BGP EVPN remote IPv4 address (MP-BGP EVPN peer) configuration as part of the logical node profile configuration.
Review the SR-MPLS guidelines and limitations provided in Guidelines and Limitations, especially the guidelines and limitations provided in Guidelines and Limitations for the SR-MPLS Infra L3Out.
(Optional) If necessary, configure an MPLS custom QoS policy using the procedures provided in Creating SR-MPLS Custom QoS Policy Using REST API.
|
Post with information similar to the following: |
Using the procedures in this section, you will configure a SR-MPLS VRF L3Out, which will be used to forward traffic from the SR-MPLS infra L3Out that you configured in the previous set of procedures.
User tenant VRFs are mapped to the SR-MPLS infra L3Outs to advertise tenant bridge domain subnets to the DC-PE routers and import the MPLS VPN routes received from the DC-PE.
You must specify routing and security policies in the SR-MPLS VRF L3Out for each VRF. These policies point to one or more SR-MPLS infra L3Outs.
One SR-MPLS VRF L3Out is supported for each VRF.
You can configure multiple consumer labels in one SR-MPLS VRF L3Out, with each consumer label identifying one SR-MPLS infra L3Out. A consumer label identifies the entry and exit point for traffic to and from one SR-MPLS VRF L3Out, which is a particular MPLS domain for a particular pod or remote leaf switch.
Review the SR-MPLS guidelines and limitations provided in Guidelines and Limitations, especially the guidelines and limitations provided in Guidelines and Limitations for the SR-MPLS VRF L3Out.
Configure an SR-MPLS infra L3Out using the procedures provided in Configuring an SR-MPLS Infra L3Out Using the REST API.
|
Post with information similar to the following: |
SR-MPLS Custom QoS policy defines the priority of the packets coming from an SR-MPLS network while they are inside the ACI fabric based on the incoming MPLS EXP values defined in the MPLS QoS ingress policy. It also marks the CoS and MPLS EXP values of the packets leaving the ACI fabric through an MPLS interface based on IPv4 DSCP values defined in MPLS QoS egress policy.
If no custom ingress policy is defined, the default QoS Level (Level3) is assigned to packets inside the fabric. If no custom egress policy is defined, the default EXP value of 0 will be marked on packets leaving the fabric.
| Step 1 |
Create SR-MPLS QoS policy. In the following POST:
|
| Step 2 |
Applying SR-MPLS QoS policy. In the following POST, replace customqos1 with the name of the SR-MPLS QoS policy you created in the previous step. |
Part II: External Routing (L3Out) Configuration
Routed Connectivity to External Networks
| Step 1 |
Mark the spine switches as route reflectors. Example: |
| Step 2 |
Set up the pod selector using the following post. Example:For the FuncP setup— Example:For the PodP setup— |
Node and Interface for L3Out
The ACI fabric is installed, APIC controllers are online, and the APIC cluster is formed and healthy.
An APIC fabric administrator account is available that will enable creating the necessary fabric infrastructure configurations.
The target leaf switches are registered in the ACI fabric and available.
Port channels are configured when port channels are used for L3Out interfaces.
 Note |
In the following REST API example, long single lines of text are broken up with the \ character to improve readability. |
|
To configure a Layer 3 route to the port channels that you created previously using the REST API, send a post with XML such as the following: Example: |
The ACI fabric is installed, APIC controllers are online, and the APIC cluster is formed and healthy.
An APIC fabric administrator account is available that will enable creating the necessary fabric infrastructure configurations.
The target leaf switches are registered in the ACI fabric and available.
Port channels are configured using the procedures in "Configuring Port Channels Using the REST API".
Note |
In the following REST API example, long single lines of text are broken up with the \ character to improve readability. |
|
To configure a Layer 3 sub-interface route to the port channels that you created previously using the REST API, send a post with XML such as the following: Example: |
|
Configure the SVI interface encapsulation scope. Example: |
The tenant and VRF configured.
A Layer 3 Out is configured and a logical node profile and a logical interface profile under the Layer 3 Out is configured.
|
Enable the SVI auto state value. Example:To disable the autostate, you must change the value to disabled in the above example. For example, |
The tenant where you configure the BGP external routed network is already created.
The following shows how to configure the BGP external routed network using the REST API:
For Example:
Example: |
Refer to the Verified Scalability Guide for Cisco APIC on the Cisco APIC documentation page for the acceptable values for the following fields.
The two properties that enable you to configure more paths are
maxEcmp and maxEcmpIbgp in the
bgpCtxAfPol object. After you configure these two properties,
they are propagated to the rest of your implementation. The ECMP policy is applied
at the VRF level.
The following example provides information on how to configure the BGP Max Path feature using the REST API:
<fvTenant descr="" dn="uni/tn-t1" name="t1">
<fvCtx name="v1">
<fvRsCtxToBgpCtxAfPol af="ipv4-ucast" tnBgpCtxAfPolName="bgpCtxPol1"/>
</fvCtx>
<bgpCtxAfPol name="bgpCtxPol1" maxEcmp="64" maxEcmpIbgp="64"/>
</fvTenant>
This following example provides information on how to configure the AS Path Prepend feature using the REST API:
<?xml version="1.0" encoding="UTF-8"?>
<fvTenant name="coke">
<rtctrlAttrP name="attrp1">
<rtctrlSetASPath criteria="prepend">
<rtctrlSetASPathASN asn="100" order="1"/>
<rtctrlSetASPathASN asn="200" order="10"/>
<rtctrlSetASPathASN asn="300" order="5"/>
<rtctrlSetASPath/>
<rtctrlSetASPath criteria="prepend-last-as" lastnum=”9" />
</rtctrlAttrP>
<l3extOut name="out1">
<rtctrlProfile name="rp1">
<rtctrlCtxP name="ctxp1" order="1">
<rtctrlScope>
<rtctrlRsScopeToAttrP tnRtctrlAttrPName="attrp1"/>
</rtctrlScope>
</rtctrlCtxP>
</rtctrlProfile>
</l3extOut>
</fvTenant>
|
Configure the BGP External Routed Network with Autonomous override enabled.
Example: |
The following procedure describes how to use the BGP neighbor shutdown feature using the REST API.
| Step 1 |
Configure the node and interface. This example configures VRF Example: |
| Step 2 |
Configure the BGP routing protocol and configure the BGP neighbor shutdown feature. This example configures BGP as the primary routing protocol, with a BGP peer with the IP address, The adminSt variable can be set to one of the following:
In the following example, the BGP neighbor shutdown feature is enabled. Example: |
The following procedure describes how to use the BGP neighbor soft reset feature using the REST API.
| Step 1 |
Configure the node and interface. This example configures VRF Example: |
| Step 2 |
Configure the BGP routing protocol and configure the BGP neighbor soft reset feature. This example configures BGP as the primary routing protocol, with a BGP peer with the IP address, The dir variable can be set to one of the following:
In the following example, the soft dynamic inbound reset is enabled. Example: |
bgpProtP under l3extLNodeP configuration. Under bgpProtP, configure a relation (bgpRsBgpNodeCtxPol) to the desired BGP Context Policy (bgpCtxPol).
|
Configure a node specific BGP timer policy on Example:In this example, |
|
Delete the node specific BGP timer policy on Example:The code phrase |
|
The following REST API shows the global configuration for bidirectional forwarding detection (BFD): Example: |
|
The following REST API shows the interface override configuration for bidirectional forwarding detection (BFD): Example: |
| Step 1 |
The following example shows the interface configuration for bidirectional forwarding detection (BFD): Example: |
| Step 2 |
The following example shows the interface configuration for enabling BFD on OSPF and EIGRP: Example:Example: |
| Step 3 |
The following example shows the interface configuration for enabling BFD on BGP: Example: |
| Step 4 |
The following example shows the interface configuration for enabling BFD on Static Routes: Example:Example: |
| Step 5 |
The following example shows the interface configuration for enabling BFD on IS-IS: Example: |
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 Cisco APIC and Transit Routing.
|
Create an OSPF external routed network for management tenant. Example: |
| Step 1 |
Configure an EIGRP context policy. Example: |
| Step 2 |
Configure an EIGRP interface policy. Example: |
| Step 3 |
Configure an EIGRP VRF. Example:IPv4: IPv6: |
| Step 4 |
Configure an EIGRP Layer3 Outside. Example:IPv4 IPv6 IPv4 and IPv6 |
| Step 5 |
(Optional) Configure the interface policy knobs. Example:The
|
| Step 1 |
Configure BGP route summarization using the REST API as follows: Example: |
||
| Step 2 |
Configure OSPF inter-area and external summarization using the following REST API: Example: |
||
| Step 3 |
Configure EIGRP summarization using the following REST API: Example:
|
Configuring Route Control with Route Maps and Route Profile Using REST API
The following procedure describes how to configure the route control per BGP peer feature using the REST API.
|
Configure the route control per BGP peer feature. Where:
Example: |
Tenant and VRF must be configured.
|
Configure the route map/profile using explicit prefix list.
Example: |
This example assumes that you have configured the Layer 3 outside network connections using BGP. It is also possible to perform these tasks for a network using OSPF.
The tenant, private network, and bridge domain are created.
The Layer 3 outside tenant network is configured.
|
Configure the route control protocol using import and export controls. Example: |
The following procedure describes how to configure the interleak redistribution using the REST API.
Create the tenant, VRF, and L3Out.
| Step 1 |
Configure the route-map for interleak redistribution. Example:The following example configures a route map |
| Step 2 |
Apply the configured route map to an L3Out. The following example applies the route map from Step 1 to L3Out
Example: |
These steps describe how to configure transit routing for a tenant. This example deploys two L3Outs, in one VRF, on two border leaf switches, that are each connected to a separate router.
Configure the node, port, functional profile, AEP, and Layer 3 domain.
Create the external routed domain and associate it to the interface for the L3Out.
Configure a BGP route reflector policy to propagate the routes within the fabric.
| Step 1 |
Configure the tenant and VRF. This example configures tenant Example: |
| Step 2 |
Configure the nodes and interfaces. This example configures two L3Outs for the tenant t1 and VRF v1, on two border leaf switches. The VRF has a Layer 3 domain,
Example: |
| Step 3 |
Configure the routing protocol for both border leaf switches. This example configures BGP as the primary routing protocol for both the border leaf switches, both with ASN 100. It also
configures Node 101 with BGP peer Example: |
| Step 4 |
Configure a connectivity routing protocol. This example configures OSPF as the communication protocol, for both L3Outs, with regular area ID Example: |
| Step 5 |
Configure the external EPGs. This example configures the network Example: |
| Step 6 |
Optional. Configure a route map. This example configures a route map for each BGP peer in the inbound and outbound directions. For Example: |
| Step 7 |
Create the filter and contract to enable the EPGs to communicate. This example configures the filter Example: |
| Step 8 |
Associate the external EPGs with the contract. This example associates the external EPG |
The following example configures two L3Outs on two border leaf switches, using the REST API.
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/policymgr/mo/.xml -->
<polUni>
<fvTenant name="t1">
<fvCtx name="v1"/>
<l3extOut name="l3out1">
<l3extRsEctx tnFvCtxName="v1"/>
<l3extLNodeP name="nodep1">
<bgpPeerP addr="15.15.15.2/24">
<bgpAsP asn="100"/>
</bgpPeerP>
<l3extRsNodeL3OutAtt rtrId="11.11.11.103" tDn="topology/pod-1/node-101"/>
<l3extLIfP name="ifp1">
<l3extRsPathL3OutAtt addr="12.12.12.3/24" ifInstT="l3-port" tDn="topology/pod-1/paths-101/pathep-[eth1/3]" />
<ospfIfP/>
</l3extLIfP>
</l3extLNodeP>
<l3extInstP name="extnw1">
<l3extSubnet ip="192.168.1.0/24" scope="import-security"/>
<l3extRsInstPToProfile direction="import" tnRtctrlProfileName="rp1"/>
<l3extRsInstPToProfile direction="export" tnRtctrlProfileName="rp2"/>
<fvRsProv tnVzBrCPName="httpCtrct"/>
</l3extInstP>
<bgpExtP/>
<ospfExtP areaId="0.0.0.0" areaType="regular"/>
<l3extRsL3DomAtt tDn="uni/l3dom-dom1"/>
<rtctrlProfile name="rp1">
<rtctrlCtxP name="ctxp1" action="permit" order="0">
<rtctrlRsCtxPToSubjP tnRtctrlSubjPName="match-rule1"/>
</rtctrlCtxP>
</rtctrlProfile>
<rtctrlProfile name="rp2">
<rtctrlCtxP name="ctxp1" action="permit" order="0">
<rtctrlRsCtxPToSubjP tnRtctrlSubjPName="match-rule2"/>
</rtctrlCtxP>
</rtctrlProfile>
</l3extOut>
<l3extOut name="l3out2">
<l3extRsEctx tnFvCtxName="v1"/>
<l3extLNodeP name="nodep2">
<bgpPeerP addr="25.25.25.2/24">
<bgpAsP asn="100"/>
</bgpPeerP>
<l3extRsNodeL3OutAtt rtrId="22.22.22.203" tDn="topology/pod-1/node-102" />
<l3extLIfP name="ifp2">
<l3extRsPathL3OutAtt addr="23.23.23.3/24" ifInstT="l3-port" tDn="topology/pod-1/paths-102/pathep-[eth1/3]" />
<ospfIfP/>
</l3extLIfP>
</l3extLNodeP>
<l3extInstP name="extnw2">
<l3extSubnet ip="192.168.2.0/24" scope="import-security"/>
<l3extRsInstPToProfile direction="import" tnRtctrlProfileName="rp2"/>
<l3extRsInstPToProfile direction="export" tnRtctrlProfileName="rp1"/>
<fvRsCons tnVzBrCPName="httpCtrct"/>
</l3extInstP>
<bgpExtP/>
<ospfExtP areaId="0.0.0.0" areaType="regular"/>
<l3extRsL3DomAtt tDn="uni/l3dom-dom1"/>
<rtctrlProfile name="rp1">
<rtctrlCtxP name="ctxp1" action="permit" order="0">
<rtctrlRsCtxPToSubjP tnRtctrlSubjPName="match-rule1"/>
</rtctrlCtxP>
</rtctrlProfile>
<rtctrlProfile name="rp2">
<rtctrlCtxP name="ctxp1" action="permit" order="0">
<rtctrlRsCtxPToSubjP tnRtctrlSubjPName="match-rule2"/>
</rtctrlCtxP>
</rtctrlProfile>
</l3extOut>
<rtctrlSubjP name="match-rule1">
<rtctrlMatchRtDest ip="192.168.1.0/24"/>
</rtctrlSubjP>
<rtctrlSubjP name="match-rule2">
<rtctrlMatchRtDest ip="192.168.2.0/24"/>
</rtctrlSubjP>
<vzFilter name="http-filter">
<vzEntry name="http-e" etherT="ip" prot="tcp"/>
</vzFilter>
<vzBrCP name="httpCtrct" scope="context">
<vzSubj name="subj1">
<vzRsSubjFiltAtt tnVzFilterName="http-filter"/>
</vzSubj>
</vzBrCP>
</fvTenant>
</polUni>
Shared L3Out
The following REST API configuration example that displays how two shared Layer 3 Outs in two VRFs communicate.
| Step 1 |
Configure the provider Layer 3 Out. Example: |
| Step 2 |
Configure the consumer Layer 3 Out. Example: |
This section describes how to configure QoS directly on an L3Out. This is the preferred way of configuring L3Out QoS starting with Cisco APIC Release 4.0(1).
You can configure QoS for L3Out on one of the following objects:
Switch Virtual Interface (SVI)
Sub Interface
Routed Outside
| Step 1 |
Configure QoS priorities for a L3Out SVI. Example: |
| Step 2 |
Configure QoS priorities for a sub-interface. Example: |
| Step 3 |
Configure QoS priorities for a routed outside. Example: |
This section describes how to configure QoS for L3Outs using Contracts.
Note |
Starting with Release 4.0(1), we recommend using custom QoS policies for L3Out QoS as described in Configuring QoS Directly on L3Out Using REST API instead. |
| Step 1 |
When configuring the tenant, VRF, and bridge domain, configure the VRF for egress mode ( Example: |
||||
| Step 2 |
When creating the filters and contracts to enable the EPGs participating in the L3Out to communicate, configure the QoS priority. The contract in this example includes the QoS priority, The filter also has the
Example: |
SR-MPLS Custom QoS policy defines the priority of the packets coming from an SR-MPLS network while they are inside the ACI fabric based on the incoming MPLS EXP values defined in the MPLS QoS ingress policy. It also marks the CoS and MPLS EXP values of the packets leaving the ACI fabric through an MPLS interface based on IPv4 DSCP values defined in MPLS QoS egress policy.
If no custom ingress policy is defined, the default QoS Level (Level3) is assigned to packets inside the fabric. If no custom egress policy is defined, the default EXP value of 0 will be marked on packets leaving the fabric.
| Step 1 |
Create SR-MPLS QoS policy. In the following POST:
|
| Step 2 |
Applying SR-MPLS QoS policy. In the following POST, replace customqos1 with the name of the SR-MPLS QoS policy you created in the previous step. |
To enable Cisco APIC to send monitoring probes for a specific SLA type using REST API, perform the following steps:
|
Configure an IP SLA monitoring policy. Example: |
To configure an IP SLA track member using REST API, perform the following steps:
|
Configure an IP SLA track member. Example: |
To configure an IP SLA track list using REST API, perform the following steps:
|
Configure an IP SLA track list. Example: |
To associate an IP SLA track list with a static route using REST API, perform the following steps:
|
Associate an IP SLA track list with a static route. Example: |
To associate an IP SLA track list with a next hop profile using REST API, perform the following steps:
|
Associate an IP SLA track list with a next hop profile. Example: |
HSRP is enabled when the leaf switch is configured.
The tenant and VRF must be configured.
VLAN pools must be configured with the appropriate VLAN range defined and the appropriate Layer 3 domain created and attached to the VLAN pool.
The Attach Entity Profile must also be associated with the Layer 3 domain.
The interface profile for the leaf switches must be configured as required.
| Step 1 |
Create port selectors. Example: |
| Step 2 |
Create a tenant policy. Example: |
| Step 3 |
Create an HSRP interface policy. Example: |
| Step 4 |
Create an HSRP group policy. Example: |
| Step 5 |
Create an HSRP interface profile and an HSRP group profile. Example: |
| Step 1 |
The following example shows how to deploy nodes and spine switch interfaces for GOLF, using the REST API: Example: |
| Step 2 |
The XML below configures the spine switch interfaces and infra tenant provider of the GOLF service. Include this XML structure in the body of the POST message. Example: |
| Step 3 |
The XML below configures the tenant consumer of the infra part of the GOLF service. Include this XML structure in the body of the POST message. Example: |
Enable distributing BGP EVPN type-2 host routes using the REST API, as follows:
EVPN services must be configured.
| Step 1 |
Configure the Host Route Leak policy, with a POST containing XML such as in the following example: Example: |
| Step 2 |
Apply the policy to the VRF BGP Address Family Context Policy for one or both of the address families using a POST containing XML such as in the following example: Example: |
Feedback