Routing Protocol Support

This chapter contains the following sections:

About Routing Protocol Support

Routing within the Cisco ACI fabric is implemented using BGP (with BFD support) and the OSPF or EIGRP routing protocols.

IP source routing is not supported in the ACI fabric.

BGP External Routed Networks with BFD Support

The following sections provide more information on BGP external routed networks with BFD support.

Guidelines for Configuring a BGP Layer 3 Outside Network Connection

When configuring a BGP external routed network, follow these guidelines:

The BGP direct route export behavior changed after release 3.2(1), where ACI does not evaluate the originating route type (such as static, direct, and so on) when matching export route map clauses. As a result, the "match direct" deny clause that is always included in the outbound neighbor route map no longer matches direct routes, and direct routes are now advertised based on whether or not a user-defined route map clause matches.

Therefore, the direct route must be advertised explicitly through the route map. Failure to do so will implicitly deny the direct route being advertised.
The AS override option in the BGP Controls field in the BGP Peer Connectivity Profile for an L3Out was introduced in release 3.1(2). It allows Cisco Application Centric Infrastructure (ACI) to overwrite a remote AS in the AS_PATH with ACI BGP AS. In Cisco ACI, it is typically used when performing transit routing from an eBGP L3Out to another eBGP L3Out with the same AS number.

However, an issue arises if you enable the AS override option when the eBGP neighbor has a different AS number. In this situation, strip the peer-as from the AS_PATH when reflecting it to a peer.
The Local-AS Number option in the BGP Peer Connectivity Profile is supported only for eBGP peering. This enables Cisco ACI border leaf switches to appear to be a member of another AS in addition to its real AS assigned to the fabric MP-BGP Route Reflector Policy. This means that the local AS number must be different from the real AS number of the Cisco ACI fabric. When this feature is configured, Cisco ACI border leaf switches prepend the local AS number to the AS_PATH of the incoming updates and append the same to the AS_PATH of the outgoing updates. Prepending of the local AS number to the incoming updates can be disabled by the no-prepend setting in the Local-AS Number Config. The no-prepend + replace-as setting can be used to prevents the local AS number from being appended to the outgoing updates in addition to not prepending the same to the incoming updates.
A router ID for an L3Out for any routing protocols cannot be the same IP address or the same subnet as the L3Out interfaces such as routed interface, sub-interface or SVI. However, if needed, a router ID can be the same as one of the L3Out loopback IP addresses.
If you have multiple L3Outs of the same routing protocol on the same leaf switch in the same VRF instance, the router ID for those must be the same. If you need a loopback with the same IP address as the router ID, you can configure the loopback in only one of those L3Outs.
There are two ways to define the BGP peer for an L3Out:
- Through the BGP peer connectivity profile (bgpPeerP) at the logical node profile level (l3extLNodeP), which associates the BGP peer to the loopback IP address. When the BGP peer is configured at this level, a loopback address is expected for BGP connectivity, so a fault is raised if the loopback address configuration is missing.
- Through the BGP peer connectivity profile (bgpPeerP) at the logical interface profile level (l3extRsPathL3OutAtt), which associates the BGP peer to the respective interface or sub-interface.
It is recommended to use BGP default timers and leverage bidirectional forwarding detection (BFD) to get sub-second failure detection. Aggressive timers can cause BGP sessions to flap unexpectedly during CPU intense operations.
You must configure an IPv6 address to enable peering over loopback using IPv6.

Tenant networking protocol policies for BGP l3extOut connections can be configured with a maximum prefix limit that enables monitoring and restricting the number of route prefixes received from a peer. After the maximum prefix limit is exceeded, a log entry can be recorded, further prefixes can be rejected, the connection can be restarted if the count drops below the threshold in a fixed interval, or the connection is shut down. You can use only one option at a time. The default setting is a limit of 20,000 prefixes, after which new prefixes are rejected. When the reject option is deployed, BGP accepts one more prefix beyond the configured limit and the Cisco Application Policy Infrastructure Controller (APIC) raises a fault.

Note

Cisco ACI does not support IP fragmentation. Therefore, when you configure Layer 3 Outside (L3Out) connections to external routers, or Multi-Pod connections through an Inter-Pod Network (IPN), it is recommended that the interface MTU is set appropriately on both ends of a link. On some platforms, such as Cisco ACI, Cisco NX-OS, and Cisco IOS, the configurable MTU value does not take into account the Ethernet headers (matching IP MTU, and excluding the 14-18 Ethernet header size), while other platforms, such as IOS-XR, include the Ethernet header in the configured MTU value. A configured value of 9000 results in a max IP packet size of 9000 bytes in Cisco ACI, Cisco NX-OS, and Cisco IOS, but results in a max IP packet size of 8986 bytes for an IOS-XR untagged interface.

For the appropriate MTU values for each platform, see the relevant configuration guides.

We highly recommend that you test the MTU using CLI-based commands. For example, on the Cisco NX-OS CLI, use a command such as ping 1.1.1.1 df-bit packet-size 9000 source-interface ethernet 1/1.

BGP Connection Types and Loopback Guidelines

The ACI supports the following BGP connection types and summarizes the loopback guidelines for them:


BGP Connection Type	Loopback required	Loopback same as Router ID	Static/OSPF route required
iBGP direct	No	Not applicable	No
iBGP loopback peering	Yes, a separate loopback per L3Out	No, if multiple Layer 3 out are on the same node	Yes
eBGP direct	No	Not applicable	No
eBGP loopback peering (multi-hop)	Yes, a separate loopback per L3Out	No, if multiple Layer 3 out are on the same node	Yes

Configuring BGP External Routed Networks

Use the procedures in the following sections to configure BGP external routed networks.

Configuring BGP External Routed Network Using the GUI

Before you begin

The tenant, VRF, and bridge domain where you configure the BGP external routed network is already created.

Procedure

Step 1

In the Navigation pane, expand Tenant_name > Networking > External Routed Networks.

Step 2

Right-click, and click Create Routed Outside.

Step 3

In the Create Routed Outside dialog box, perform the following actions:

In the Name field, enter a name for the external routed network policy.

Click the BGP checkbox.

Note

BGP peer reachability must be available in one of two ways. You must either configure static routes or enable OSPF.

(Optional) In the Route Control Enforcement field, check the Import check box.

Note

Check this check box if you wish to enforce import control with BGP.

From the VRF field drop-down list, choose the desired VRF.
Expand the Route Control for Dampening field, and choose the desired address family type and route dampening policy. Click Update.

In this step, the policy can be created either with step 4 or there is also an option to Create route profile in the drop-down list where the policy name is selected.
Expand Nodes and Interfaces Protocol Policies.
In the Create Node Profile dialog box, enter a name for the node profile.
Expand Nodes.
From the Select Node dialog box, from the Node ID field drop-down list, choose a node.
In the Router ID field, enter the router ID.

Expand Loopback Address, and in the IP field, enter the IP address. Click Update.

Note

Enter an IPv6 address. If you did not add the router ID in the earlier step, you can add an IPv4 address in the IP field.

Click OK.

Step 4

In the Navigation pane, expand Tenant_name > Networking > Route Profiles. Right-click Route Profiles, and click Create Route Profile. In the Create Route Profile dialog box, perform the following actions:

In the Name field, enter a name for the route control VRF.
Expand the Create Route Control Context dialog box.
In the Name field, enter a name for the route control VRF.
From the Set Attribute drop-down list, choose Create Action Rule Profile.

When creating an action rule, set the route dampening attributes as desired.

Step 5

In the Create Interface Profiles dialog box, perform the following actions:

In the Name field, enter an interface profile name.
In the Interfaces area, choose the desired interface tab, and then expand the interface.

Step 6

In the Select Routed Interface dialog box, perform the following actions:

From the Path field drop-down list, choose the node and the interface.

In the IP Address field, enter the IP address.

Note

Depending upon your requirements, you can add an IPv6 address or an IPv4 address.

(Optional) If you entered an IPv6 address in the earlier step, in the Link-local Address field, enter an IPv6 address.
Expand BGP Peer Connectivity Profile field.

Step 7

In the Create Peer Connectivity Profile dialog box, perform the following actions:

In the Peer Address field, the dynamic neighbor feature is available. If desired by the user, any peer within a specified subnet can communicate or exchange routes with BGP.

Enter an IPv4 of an IPv6 address to correspond with IPv4 or IPv6 addresses entered in the earlier in the steps.
In the BGP Controls field, check the desired controls.
In the Autonomous System Number field, choose the desired value.
(Optional) In the Weight for routes from this neighbor field, choose the desired value.
(Optional) In the Private AS Control field, check the check box for Remove AS.
(Optional) In the Local Autonomous System Number Config field, choose the desired value.

Optionally required for the local autonomous system feature for eBGP peers.

(Optional) In the Local Autonomous System Number field, choose the desired value.

Optionally required for the local autonomous system feature for eBGP peers.

Note

The value in this field must not be the same as the value in the Autonomous System Number field.

Click OK.

Step 8

Perform the following actions:

In the Select Routed Interface dialog box, click OK.
In the Create Interface Profile dialog box, click OK.
In the Create Node Profile dialog box, click OK.

The External EPG Networks area is displayed.
In Create Routed Outside dialog box, choose the node profile you created earlier, and click Next.

Step 9

Expand External EPG Networks, and in the Create External Network dialog box, perform the following actions:

In the Name field, enter a name for the external network.
Expand Subnet.

In the Create Subnet dialog box, in the IP address field, enter the subnet addresses as required.

Note

Enter an IPv4 or IPv6 address depending upon what you have entered in earlier steps.

When creating the external subnet, you must configure either both the BGP loopbacks in the prefix EPG or neither of them. If you configure only one BGP loopback, then BGP neighborship is not established.

In the Scope field, check the check boxes for Export Route Control Subnet, Import Route Control Subnet, and Security Import Subnet. Click OK.

Note

Check the Import Route Control Subnet check box if you wish to enforce import control with BGP.

Step 10

In the Create External Network dialog box, click OK.

Step 11

In the Create Routed Outside dialog box, click Finish.

The eBGP is configured for external connectivity.

Configuring BGP External Routed Network Using the NX-OS Style CLI

Procedure

The following shows how to configure the BGP external routed network using the NX-OS CLI:

Example:


apic1(config-leaf)# template route-profile damp_rp tenant t1
This template will be available on all leaves where tenant t1 has a VRF deployment
apic1(config-leaf-template-route-profile)# set dampening 15 750 2000 60
apic1(config-leaf-template-route-profile)# exit
apic1(config-leaf)#
apic1(config-leaf)# router bgp 100
apic1(config-bgp)# vrf member tenant t1 vrf ctx3
apic1(config-leaf-bgp-vrf)# neighbor 32.0.1.0/24 l3out l3out-bgp
apic1(config-leaf-bgp-vrf-neighbor)# update-source ethernet 1/16.401
apic1(config-leaf-bgp-vrf-neighbor)# address-family ipv4 unicast
apic1(config-leaf-bgp-vrf-neighbor-af)# weight 400
apic1(config-leaf-bgp-vrf-neighbor-af)# exit
apic1(config-leaf-bgp-vrf-neighbor)# remote-as 65001
apic1(config-leaf-bgp-vrf-neighbor)# private-as-control remove-exclusive
apic1(config-leaf-bgp-vrf-neighbor)# private-as-control remove-exclusive-all
apic1(config-leaf-bgp-vrf-neighbor)# private-as-control remove-exclusive-all-replace-as
apic1(config-leaf-bgp-vrf-neighbor)# exit
apic1(config-leaf-bgp-vrf)# address-family ipv4 unicast
apic1(config-leaf-bgp-vrf-af)# inherit bgp dampening damp_rp
This template will be inherited on all leaves where VRF ctx3 has been deployed
apic1(config-leaf-bgp-vrf-af)# exit
apic1(config-leaf-bgp-vrf)# address-family ipv6 unicast
apic1(config-leaf-bgp-vrf-af)# inherit bgp dampening damp_rp
This template will be inherited on all leaves where VRF ctx3 has been deployed
apic1(config-leaf-bgp-vrf-af)# exit

Configuring BGP External Routed Network Using the REST API

Before you begin

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:

Procedure

Example:


<l3extOut descr="" dn="uni/tn-t1/out-l3out-bgp" enforceRtctrl="export" name="l3out-bgp" ownerKey="" ownerTag="" targetDscp="unspecified">
	<l3extRsEctx tnFvCtxName="ctx3"/>
	<l3extLNodeP configIssues="" descr="" name="l3extLNodeP_1" ownerKey="" ownerTag="" tag="yellow-green" targetDscp="unspecified">
		<l3extRsNodeL3OutAtt rtrId="1.1.1.1" rtrIdLoopBack="no" tDn="topology/pod-1/node-101"/>
		<l3extLIfP descr="" name="l3extLIfP_2" ownerKey="" ownerTag="" tag="yellow-green">
			<l3extRsNdIfPol tnNdIfPolName=""/>
			<l3extRsIngressQosDppPol tnQosDppPolName=""/>
			<l3extRsEgressQosDppPol tnQosDppPolName=""/>
			<l3extRsPathL3OutAtt addr="3001::31:0:1:2/120" descr="" encap="vlan-3001" encapScope="local" ifInstT="sub-interface" llAddr="::" mac="00:22:BD:F8:19:FF" mode="regular" mtu="inherit" tDn="topology/pod-1/paths-101/pathep-[eth1/8]" targetDscp="unspecified">
				<bgpPeerP addr="3001::31:0:1:0/120" allowedSelfAsCnt="3" ctrl="send-com,send-ext-com" descr="" name="" peerCtrl="bfd" privateASctrl="remove-all,remove-exclusive,replace-as" ttl="1" weight="1000">
					<bgpRsPeerPfxPol tnBgpPeerPfxPolName=""/>
					<bgpAsP asn="3001" descr="" name=""/>
				</bgpPeerP>
			</l3extRsPathL3OutAtt>
		</l3extLIfP>
		<l3extLIfP descr="" name="l3extLIfP_1" ownerKey="" ownerTag="" tag="yellow-green">
			<l3extRsNdIfPol tnNdIfPolName=""/>
			<l3extRsIngressQosDppPol tnQosDppPolName=""/>
			<l3extRsEgressQosDppPol tnQosDppPolName=""/>
			<l3extRsPathL3OutAtt addr="31.0.1.2/24" descr="" encap="vlan-3001" encapScope="local" ifInstT="sub-interface" llAddr="::" mac="00:22:BD:F8:19:FF" mode="regular" mtu="inherit" tDn="topology/pod-1/paths-101/pathep-[eth1/8]" targetDscp="unspecified">
				<bgpPeerP addr=“31.0.1.0/24" allowedSelfAsCnt="3" ctrl="send-com,send-ext-com" descr="" name="" peerCtrl="" privateASctrl="remove-all,remove-exclusive,replace-as" ttl="1" weight="100">
					<bgpRsPeerPfxPol tnBgpPeerPfxPolName=""/>
					<bgpLocalAsnP asnPropagate="none" descr="" localAsn="200" name=""/>
					<bgpAsP asn="3001" descr="" name=""/>
				</bgpPeerP>
			</l3extRsPathL3OutAtt>
		</l3extLIfP>
	</l3extLNodeP>
	<l3extRsL3DomAtt tDn="uni/l3dom-l3-dom"/>
	<l3extRsDampeningPol af="ipv6-ucast" tnRtctrlProfileName="damp_rp"/>
	<l3extRsDampeningPol af="ipv4-ucast" tnRtctrlProfileName="damp_rp"/>
	<l3extInstP descr="" matchT="AtleastOne" name="l3extInstP_1" prio="unspecified" targetDscp="unspecified">
		<l3extSubnet aggregate="" descr="" ip="130.130.130.0/24" name="" scope="import-rtctrl"></l3extSubnet>
		<l3extSubnet aggregate="" descr="" ip="130.130.131.0/24" name="" scope="import-rtctrl"/>
		<l3extSubnet aggregate="" descr="" ip="120.120.120.120/32" name="" scope="export-rtctrl,import-security"/>
		<l3extSubnet aggregate="" descr="" ip="3001::130:130:130:100/120" name="" scope="import-rtctrl"/>
	</l3extInstP>
	<bgpExtP descr=""/>
</l3extOut>
<rtctrlProfile descr="" dn="uni/tn-t1/prof-damp_rp" name="damp_rp" ownerKey="" ownerTag="" type="combinable">
	<rtctrlCtxP descr="" name="ipv4_rpc" order="0">
		<rtctrlScope descr="" name="">
			<rtctrlRsScopeToAttrP tnRtctrlAttrPName="act_rule"/>
		</rtctrlScope>
	</rtctrlCtxP>
</rtctrlProfile>
<rtctrlAttrP descr="" dn="uni/tn-t1/attr-act_rule" name="act_rule">
	<rtctrlSetDamp descr="" halfLife="15" maxSuppressTime="60" name="" reuse="750" suppress="2000" type="dampening-pol"/>
</rtctrlAttrP>

Configuring BGP Max Path

The following feature enables you to add the maximum number of paths to the route table to enable equal cost, multipath load balancing.

Configuring BGP Max Path Using the GUI

Before you begin

The appropriate tenant and the BGP external routed network are created and available.

Procedure

Step 1	Log in to the APIC GUI, and on the menu bar, click Tenants > `tenant_name` > Networking > Protocol Policies > BGP > BGP Address Family Contextand right click Create BGP Address Family Context Policy.
Step 2	In the Create BGP Address Family Context Policy dialog box, perform the following tasks. Refer to the Verified Scalability Guide for Cisco APIC on the Cisco APIC documentation page for the acceptable values for the following fields. In the Name field, enter a name for the policy. In the eBGP Distance field, enter a value for the administrative distance of eBGP routes. In the iBGP Distance field, enter a value for the administrative distance of iBGP routes. In the Local Distance field, enter a value for the local distance. In the eBGP Max ECMP field, enter a value for the maximum number of equal-cost paths for eBGP load sharing. In the iBGP Max ECMP field, enter a value for the maximum number of equal-cost paths for iBGP load sharing. In the Enable Host Route Leak field, click the box to enable distributing EVPN type-2 (MAC/IP) host routes to the DCIG. Click Submit after you have updated your entries.
Step 3	Click Tenants > `tenant_name` > Networking > VRFs > `VRF_name`
Step 4	Review the configuration details of the subject VRF.
Step 5	Access the BGP Context Per Address Family field and select IPv6 in the Address Family drop-down list.
Step 6	Access the BGP Address Family Context you created in the BGP Address Family Context drop-down list and associate it with the subject VRF.
Step 7	Click Submit.

Configuring BGP Max Path Using the NX-OS Style CLI

Before you begin:

The appropriate tenant and the BGP external routed network are created and available.

The two properties which 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.

Use the following commands when logged in to BGP:

maximum-paths [ibgp]

no maximum-paths [ibgp]

Example:

apic1(config)# leaf 101
apic1(config-leaf)# template bgp address-family newAf tenant t1
This template will be available on all nodes where tenant t1 has a VRF deployment
apic1(config-bgp-af)# maximum-paths ?
<1-16> 	Maximum number of equal-cost paths for load sharing. The default is 16.
ibgp 	Configure multipath for IBGP paths
apic1(config-bgp-af)# maximum-paths 10
apic1(config-bgp-af)# maximum-paths ibpg 8
apic1(config-bgp-af)# end
apic1#
no maximum-paths [ibgp]

Configuring BGP Max Path Using the REST API

This 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="8" maxEcmpIbgp="4"/>
    </fvTenant>

Configuring AS Path Prepend

Use the procedures in the following sections to configure AS Path Prepend.

Configuring AS Path Prepend

A BGP peer can influence the best-path selection by a remote peer by increasing the length of the AS-Path attribute. AS-Path Prepend provides a mechanism that can be used to increase the length of the AS-Path attribute by prepending a specified number of AS numbers to it.

AS-Path prepending can only be applied in the outbound direction using route-maps. AS Path prepending does not work in iBGP sessions.

The AS Path Prepend feature enables modification as follows:

Prepend

Appends the specified AS number to the AS path of the route matched by the route map.

Note

You can configure more than one AS number.
4 byte AS numbers are supported.
You can prepend a total 32 AS numbers. You must specify the order in which the AS Number is inserted into the AS Path attribute.

Prepend-last-as

Prepends the last AS numbers to the AS path with a range between 1 and 10.

The following table describes the selection criteria for implementation of AS Path Prepend:


Prepend	1	Prepend the specified AS number.
Prepend-last-as	2	Prepend the last AS numbers to the AS path.
DEFAULT	Prepend(1)	Prepend the specified AS number.

Configuring AS Path Prepend Using the GUI

Before you begin

A configured tenant.

Procedure

Step 1	Log in to the APIC GUI, and on the menu bar, click Tenants > `tenant_name` > Networking > External Routed Networks > Set Rules for Route Maps and right click Create Set Rules For A Route Map.
Step 2	In the Create Set Rules For A Route Map dialog box, perform the following tasks: In the Name field, enter a name. Click the Set AS Path icon to open the Create Set AS Path dialog box.
Step 3	Select the criterion Prepend AS to prepend AS numbers.
Step 4	Enter the AS number and its order and then click Update. Repeat if multiple AS numbers must be prepended.
Step 5	Select the criterion Prepend Last-AS to prepend the last AS number a specified number of times.
Step 6	Enter Count (1-10).
Step 7	On the Create Set Rules For A Route Map display, confirm the listed criteria for the set rule based on AS Path and click Finish.
Step 8	On the APIC GUI menu bar, click Tenants > `tenant_name` > Networking > External Routed Networks > Set Rules for Route Maps and right click your profile.
Step 9	Confirm the Set AS Path values the bottom of the screen.

Configuring AS Path Prepend Using the NX-OS Style CLI

This section provides information on how to configure the AS Path Prepend feature using the NX-OS style command line interface (CLI).

Before you begin

A configured tenant.

Procedure

To modify the autonomous system path (AS Path) for Border Gateway Protocol (BGP) routes, you can use the set as-path command. The set as-path command takes the form of apic1(config-leaf-vrf-template-route-profile)# set as-path {'prepend as-num [ ,... as-num ] | prepend-last-as num}

Example:

apic1(config)# leaf 103

apic1(config-leaf)# vrf context tenant t1 vrf v1

apic1(config-leaf-vrf)# template route-profile rp1

apic1(config-leaf-vrf-template-route-profile)# set as-path ?

prepend Prepend to the AS-Path

prepend-last-as Prepend last AS to the as-path

apic1(config-leaf-vrf-template-route-profile)# set as-path prepend 100, 101, 102, 103

apic1(config-leaf-vrf-template-route-profile)# set as-path prepend-last-as 8

apic1(config-leaf-vrf-template-route-profile)# exit

apic1(config-leaf-vrf)# exit

apic1(config-leaf)# exit

What to do next

To disable AS Path prepend, use the no form of the shown command:

apic1(config-leaf-vrf-template-route-profile)# [no] set as-path { prepend as-num [ ,... as-num ] | prepend-last-as num}

Configuring AS Path Prepend Using the REST API

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>

BGP External Routed Networks with AS Override

Use the procedures in the following sections to configure BGB external routed networks with AS override.

About BGP Autonomous System Override

Loop prevention in BGP is done by verifying the Autonomous System number in the Autonomous System Path. If the receiving router sees its own Autonomous System number in the Autonomous System path of the received BGP packet, the packet is dropped. The receiving router assumes that the packet originated from its own Autonomous System and has reached the same place from where it originated initially. This setting is the default to prevent route loops from occurring.

The default setting to prevent route loops from occurring could create an issue if you use the same Autonomous System number along various sites and disallow user sites with identical Autonomous System numbers to link by another Autonomous System number. In such a scenario, routing updates from one site is dropped when the other site receives them.

To prevent such a situation from occurring, beginning with the Cisco APIC Release 3.1(2m), you can now enable the BGP Autonomous System override feature to override the default setting. You must also enable the Disable Peer AS Check at the same time.

The Autonomous System override function replaces the Autonomous System number from the originating router with the Autonomous System number of the sending BGP router in the AS Path of the outbound routes. This feature can be enabled per feature per address family (IPv4 or IPv6).

The Autonomous System Override feature is supported with GOLF Layer 3 configurations and Non-GOLF Layer 3 configurations.

Figure 1. Example Topology Illustrating the Autonomous System Override Process

Router 1 and Router 2 are the two customers with multiple sites (Site-A and Site-B). Customer Router 1 operates under AS 100 and customer Router 2 operates under AS 200.

The above diagram illustrates the Autonomous System (AS) override process as follows:

Router 1-Site-A advertises route 10.3.3.3 with AS100.
Router PE-1 propagates this as an internal route to PE2 as AS100.
Router PE-2 prepends 10.3.3.3 with AS121 (replaces 100 in the AS path with 121), and propagates the prefix.
Router 2-Site-B accepts the 10.3.3.3 update.

Configuring BGP External Routed Network with Autonomous System Override Enabled Using the GUI

Before you begin

The Tenant, VRF, Bridge Domain are created.
The External Routed Network that is in a non-GOLF setting, a logical node profile, and the BGP peer connectivity profile are created.

Procedure

Step 1

On the menu bar, choose Tenants > Tenant_name > Networking > External Routed Network > Non-GOLF Layer 3 Out_name > Logical Node Profiles.

Step 2

In the Navigation pane, choose the appropriate BGP Peer Connectivity Profile.

Step 3

In the Work pane, under Properties for the BGP Peer Connectivity Profile, in the BGP Controls field, perform the following actions:

Check the check box for the AS override field to enable the Autonomous System override function.

Check the check box for the Disable Peer AS Check field.

Note

You must check the check boxes for AS override and Disable Peer AS Check for the AS override feature to take effect.

Choose additional fields as required.

Step 4

Click Submit.

Configuring BGP External Routed Network with Autonomous System Override Enabled Using the REST API

Procedure

Configure the BGP External Routed Network with Autonomous override enabled.

Note

The line of code that is in bold displays the BGP AS override portion of the configuration. This feature was introduced in the Cisco APIC Release 3.1(2m).

Example:



<fvTenant name="coke">

   <fvCtx name="coke" status="">
       <bgpRtTargetP af="ipv4-ucast">
           <bgpRtTarget type="import" rt="route-target:as4-nn2:1234:1300" />
           <bgpRtTarget type="export" rt="route-target:as4-nn2:1234:1300" />
       </bgpRtTargetP>
       <bgpRtTargetP af="ipv6-ucast">
           <bgpRtTarget type="import" rt="route-target:as4-nn2:1234:1300" />
           <bgpRtTarget type="export" rt="route-target:as4-nn2:1234:1300" />
       </bgpRtTargetP>
   </fvCtx>
   
   <fvBD name="cokeBD">
       <!-- Association from Bridge Doamin to Private Network -->
       <fvRsCtx tnFvCtxName="coke" />
       <fvRsBDToOut tnL3extOutName="routAccounting" />
       <!-- Subnet behind the bridge domain-->
       <fvSubnet ip="20.1.1.1/16" scope="public"/>
       <fvSubnet ip="2000:1::1/64" scope="public"/>
   </fvBD>   
   <fvBD name="cokeBD2">
       <!-- Association from Bridge Doamin to Private Network -->
       <fvRsCtx tnFvCtxName="coke" />
       <fvRsBDToOut tnL3extOutName="routAccounting" />
       <!-- Subnet behind the bridge domain-->
       <fvSubnet ip="30.1.1.1/16" scope="public"/>
       
   </fvBD> 
   <vzBrCP name="webCtrct" scope="global">
       <vzSubj name="http">                                
           <vzRsSubjFiltAtt tnVzFilterName="default"/>
       </vzSubj>
   </vzBrCP>
        
   <!-- GOLF L3Out -->
   <l3extOut name="routAccounting">
      <l3extConsLbl name="golf_transit" owner="infra" status=""/>
      <bgpExtP/>
      <l3extInstP name="accountingInst">
          <!--
          <l3extSubnet ip="192.2.2.0/24" scope="import-security,import-rtctrl" />
          <l3extSubnet ip="192.3.2.0/24" scope="export-rtctrl"/>
          <l3extSubnet ip="192.5.2.0/24" scope="export-rtctrl"/>
          <l3extSubnet ip="64:ff9b::c007:200/120" scope="export-rtctrl" />
          -->
          <l3extSubnet ip="0.0.0.0/0"
                                scope="export-rtctrl,import-security"
                                aggregate="export-rtctrl"
    
          />
          <fvRsProv tnVzBrCPName="webCtrct"/> 
      </l3extInstP>
      
      <l3extRsEctx tnFvCtxName="coke"/>
   </l3extOut>
   
    <fvAp name="cokeAp">
      <fvAEPg name="cokeEPg" >
          <fvRsBd tnFvBDName="cokeBD" />
            <fvRsPathAtt tDn="topology/pod-1/paths-103/pathep-[eth1/20]" encap="vlan-100" instrImedcy="immediate" mode="regular"/>
            <fvRsCons tnVzBrCPName="webCtrct"/> 
      </fvAEPg>
      <fvAEPg name="cokeEPg2" >
          <fvRsBd tnFvBDName="cokeBD2" />
            <fvRsPathAtt tDn="topology/pod-1/paths-103/pathep-[eth1/20]" encap="vlan-110" instrImedcy="immediate" mode="regular"/>
            <fvRsCons tnVzBrCPName="webCtrct"/> 
      </fvAEPg>
    </fvAp>
    
    <!-- Non GOLF L3Out-->
    <l3extOut name="NonGolfOut">
       <bgpExtP/>
       <l3extLNodeP name="bLeaf">
           <!--
           <l3extRsNodeL3OutAtt tDn="topology/pod-1/node-101" rtrId="20.1.13.1"/>
           -->
           <l3extRsNodeL3OutAtt tDn="topology/pod-1/node-101" rtrId="20.1.13.1">
           <l3extLoopBackIfP addr="1.1.1.1"/>
           
           <ipRouteP ip="2.2.2.2/32"  >
             <ipNexthopP nhAddr="20.1.12.3"/>
      </ipRouteP>
         
          
        </l3extRsNodeL3OutAtt>
           <l3extLIfP name='portIfV4'>
               <l3extRsPathL3OutAtt tDn="topology/pod-1/paths-101/pathep-[eth1/17]" encap='vlan-1010' ifInstT='sub-interface' addr="20.1.12.2/24">
                 
               </l3extRsPathL3OutAtt>
           </l3extLIfP>
           <l3extLIfP name='portIfV6'>
               <l3extRsPathL3OutAtt tDn="topology/pod-1/paths-101/pathep-[eth1/17]" encap='vlan-1010' ifInstT='sub-interface' addr="64:ff9b::1401:302/120">
                   <bgpPeerP addr="64:ff9b::1401:d03" ctrl="send-com,send-ext-com" />
               </l3extRsPathL3OutAtt>
           </l3extLIfP>
           <bgpPeerP addr="2.2.2.2" ctrl="as-override,disable-peer-as-check, send-com,send-ext-com" status=""/>
       </l3extLNodeP>
       <!--
        <bgpPeerP addr="2.2.2.2" ctrl="send-com,send-ext-com" status=""/>
        -->
       <l3extInstP name="accountingInst">
           <l3extSubnet ip="192.10.0.0/16" scope="import-security,import-rtctrl" />
           <l3extSubnet ip="192.3.3.0/24" scope="import-security,import-rtctrl" />
           <l3extSubnet ip="192.4.2.0/24" scope="import-security,import-rtctrl" />
           <l3extSubnet ip="64:ff9b::c007:200/120" scope="import-security,import-rtctrl" />
           <l3extSubnet ip="192.2.2.0/24" scope="export-rtctrl" />
           <l3extSubnet ip="0.0.0.0/0"
                                scope="export-rtctrl,import-rtctrl,import-security"
                                aggregate="export-rtctrl,import-rtctrl"
    
          />
       </l3extInstP>
      <l3extRsEctx tnFvCtxName="coke"/>
   </l3extOut>
   
</fvTenant>

Configuring Per VRF Per Node BGP Timer Values

Use the procedures in the following sections to configure per VRF per node BGP timer values.

Per VRF Per Node BGP Timer Values

Prior to the introduction of this feature, for a given VRF, all nodes used the same BGP timer values.

With the introduction of the per VRF per node BGP timer values feature, BGP timers can be defined and associated on a per VRF per node basis. A node can have multiple VRFs, each corresponding to a fvCtx. A node configuration (l3extLNodeP) can now contain configuration for BGP Protocol Profile (bgpProtP) which in turn refers to the desired BGP Context Policy (bgpCtxPol). This makes it possible to have a different node within the same VRF contain different BGP timer values.

For each VRF, a node has a bgpDom concrete MO. Its name (primary key) is the VRF, <fvTenant>:<fvCtx>. It contains the BGP timer values as attributes (for example, holdIntvl, kaIntvl, maxAsLimit).

All the steps necessary to create a valid Layer 3 Out configuration are required to successfully apply a per VRF per node BGP timer. For example, MOs such as the following are required: fvTenant, fvCtx, l3extOut, l3extInstP, LNodeP, bgpRR.

On a node, the BGP timer policy is chosen based on the following algorithm:

If bgpProtP is specified, then use bgpCtxPol referred to under bgpProtP.
Else, if specified, use bgpCtxPol referred to under corresponding fvCtx.
Else, if specified, use the default policy under the tenant, for example, uni/tn-<tenant>/bgpCtxP-default.
Else, use the default policy under tenant common, for example, uni/tn-common/bgpCtxP-default. This one is pre-programmed.

Configuring a Per VRF Per Node BGP Timer Using the Advanced GUI

When a BGP timer is configured on a specific node, then the BGP timer policy on the node is used and the BGP policy timer associated with the VRF is ignored.

Before you begin

A tenant and a VRF are already configured.

Procedure

Step 1

On the menu bar, choose Tenant > Tenant_name > Networking > Protocol Policies. In the Navigation pane, expand Networking > Protocol Policies > BGP > BGP Timers.

Step 2

In the create BGP Timers Policy dialog box, perform the following actions:

In the Name field, enter the BGP Timers policy name.
In the available fields, choose the appropriate values as desired. Click Submit.

A BGP timer policy is created.

Step 3

Navigate to the External Routed Network, and create a Layer 3 Out with BGP enabled by performing the following actions:

Right-click Create Routed Outside.
In the Create Routed Outside dialog box, specify the name of the Layer 3 Out.
Check the check box to enable BGP.
Expand Nodes and Interfaces Protocol Policies.

Step 4

To create a new node, in the Create Node Profile dialog box, perform the following actions:

In the Name field, enter a name for the node profile.
In the BGP Timers field, from the drop-down list, choose the BGP timer policy that you want to associate with this specific node. Click Finish.

A specific BGP timer policy is now applied to the node.

Note

To associate an existing node profile with a BGP timer policy, right-click the node profile, and associate the timer policy.

If a timer policy is not chosen specifically in the BGP Timers field for the node, then the BGP timer policy that is associated with the VRF under which the node profile resides automatically gets applied to this node.

Step 5

To verify the configuration, in the Navigation pane, perform the following steps:

Expand Layer 3 Out > External Routed Network_name > Logical Node Profiles > Logical Node Profiles_name > BGP Protocol Profile.
In the Work pane, the BGP protocol profile that is associated with the node profile is displayed.

Configuring a Per VRF Per Node BGP Timer Using the REST API

The following example shows how to configure Per VRF Per node BGP timer in a node. Configure bgpProtP under l3extLNodeP configuration. Under bgpProtP, configure a relation (bgpRsBgpNodeCtxPol) to the desired BGP Context Policy (bgpCtxPol).

Procedure

Configure a node specific BGP timer policy on node1, and configure node2 with a BGP timer policy that is not node specific.

Example:

POST https://apic-ip-address/mo.xml

<fvTenant name="tn1" >
    <bgpCtxPol name="pol1" staleIntvl="25" />
    <bgpCtxPol name="pol2" staleIntvl="35" />
    <fvCtx name="ctx1" >
      <fvRsBgpCtxPol tnBgpCtxPolName="pol1"/>
    </fvCtx>
     <l3extout name="out1" >
      <l3extRsEctx toFvCtxName="ctx1" />
      <l3extLNodeP name="node1" >
        <bgpProtP name="protp1" >
            <bgpRsBgpNodeCtxPol tnBgpCtxPolName="pol2" />
        </bgpProtP>
      </l3extLNodeP>
      <l3extLNodeP name="node2" >
      </l3extLNodeP>

In this example, node1 gets BGP timer values from policy pol2, and node2 gets BGP timer values from pol1. The timer values are applied to the bgpDom corresponding to VRF tn1:ctx1. This is based upon the BGP timer policy that is chosen following the algorithm described in the Per VRF Per Node BPG Timer Values section.

Deleting a Per VRF Per Node BGP Timer Using the REST API

The following example shows how to delete an existing Per VRF Per node BGP timer in a node.

Procedure

Delete the node specific BGP timer policy on node1.

Example:

POST https://apic-ip-address/mo.xml
 
<fvTenant name="tn1" >
    <bgpCtxPol name="pol1" staleIntvl="25" />
    <bgpCtxPol name="pol2" staleIntvl="35" />
    <fvCtx name="ctx1" >
      <fvRsBgpCtxPol tnBgpCtxPolName="pol1"/>
    </fvCtx>
     <l3extout name="out1" >
      <l3extRsEctx toFvCtxName="ctx1" />
      <l3extLNodeP name="node1" >
        <bgpProtP name="protp1" status="deleted" >
            <bgpRsBgpNodeCtxPol tnBgpCtxPolName="pol2" />
        </bgpProtP>
      </l3extLNodeP>
      <l3extLNodeP name="node2" >
      </l3extLNodeP>

The code phrase <bgpProtP name="protp1" status="deleted" > in the example above, deletes the BGP timer policy. After the deletion, node1 defaults to the BGP timer policy for the VRF with which node1 is associated, which is pol1 in the above example.

Configuring a Per VRF Per Node BGP Timer Policy Using the NX-OS Style CLI

Procedure

	Command or Action	Purpose
Step 1	Configure BGP ASN and the route reflector before creating a timer policy. Example: `apic1(config)# apic1(config)# bgp-fabric apic1(config-bgp-fabric)# route-reflector spine 102 apic1(config-bgp-fabric)# asn 42 apic1(config-bgp-fabric)# exit apic1(config)# exit apic1#`
Step 2	Create a timer policy. Example: `apic1# config apic1(config)# leaf 101 apic1(config-leaf)# template bgp timers pol7 tenant tn1 This template will be available on all nodes where tenant tn1 has a VRF deployment apic1(config-bgp-timers)# timers bgp 120 240 apic1(config-bgp-timers)# graceful-restart stalepath-time 500 apic1(config-bgp-timers)# maxas-limit 300 apic1(config-bgp-timers)# exit apic1(config-leaf)# exit apic1(config)# exit apic1#`	The specific values are provided as examples only.
Step 3	Display the configured BGP policy. Example: `apic1# show run leaf 101 template bgp timers pol7 # Command: show running-config leaf 101 template bgp timers pol7 leaf 101 template bgp timers pol7 tenant tn1 timers bgp 120 240 graceful-restart stalepath-time 500 maxas-limit 300 exit exit`
Step 4	Refer to a specific policy at a node. Example: `apic1# config apic1(config)# leaf 101 apic1(config-leaf)# router bgp 42 apic1(config-leaf-bgp)# vrf member tenant tn1 vrf ctx1 apic1(config-leaf-bgp-vrf)# inherit node-only bgp timer pol7 apic1(config-leaf-bgp-vrf)# exit apic1(config-leaf-bgp)# exit apic1(config-leaf)# exit apic1(config)# exit apic1#`
Step 5	Display the node specific BGP timer policy. Example: `apic1# show run leaf 101 router bgp 42 vrf member tenant tn1 vrf ctx1 # Command: show running-config leaf 101 router bgp 42 vrf member tenant tn1 vrf ctx1 leaf 101 router bgp 42 vrf member tenant tn1 vrf ctx1 inherit node-only bgp timer pol7 exit exit exit apic1#`

Troubleshooting Inconsistency and Faults

The following inconsistencies or faults could occur under certain conditions:

If different Layer 3 Outs (l3Out) are associated with the same VRF (fvCtx), and on the same node, the bgpProtP is associated with different policies (bgpCtxPol), a fault will be raised. In the case of the example below, both Layer 3 Outs (out1 and out2) are associated with the same VRF (ctx1). Under out1, node1 is associated with the BGP timer protocol pol1 and under out2, node1 is associated with a different BGP timer protocol pol2. This will raise a fault.


tn1
  ctx1
  out1
    ctx1
    node1
      protp pol1
  
  out2
    ctx1
    node1
      protp pol2

If such a fault is raised, change the configuration to remove the conflict between the BGP timer policies.

eBGP Multipath Relax

The 3.2(7) release adds VRF-scoped node level support for modifying the Border Gateway Protocol (BGP) best path policy. You can modify the policy by using the External Border Gateway Protocol (eBGP) multipath relax option.

By default, BGP does not allow load balancing between multiple paths received from different autonomous system (AS) numbers. The multipath relax option changes this default behavior by relaxing the AS-PATH check and triggering multipathing across multiple eBGP peers. As a result, BGP will download multiple equal-cost multipath (ECMP) routing paths to the routing database.

Configuring eBGP Multipath Relax Using the GUI

The following procedure configures eBGP multipath relax using the GUI.

Before you begin

This procedure assumes that you previously created a BGP best path policy and a logical node profile under a tenant.

Procedure

Step 1	On the menu bar, choose Tenants > All Tenants.
Step 2	In the Work pane, double-click the tenant's name.
Step 3	Enable the eBGP multipath relax feature in a BGP best path policy. In the Navigation pane, choose Tenant `tenant_name` > Policies > Protocol > BGP > BGP Best Path Policy > Create BGP Best Path Control Policy. Put a check in the AS-Path Control check box. Click Submit. The eBGP multipath relax feature is now enabled for the chosen BGP best path policy.
Step 4	Choose the AS-path policy for a Layer 3 outside (L3Out). In the Navigation pane, choose Tenant `tenant_name` > Networking > External Routed Networks > `L3Out_name` > Logical Node Profiles > Create BGP Protocol Profile. In the Work pane, in the AS-Path Policy drop-down list, choose the same BGP best path policy that you used in the previous step. Click Submit.

Configuring eBGP Multipath Relax Using the NX-OS-Style CLI

The following procedure configures eBGP multipath relax using the NX-OS-style CLI.

Before you begin

This procedure assumes that you previously created a BGP best path policy and a logical node profile under a tenant.

Procedure

Step 1

Enter the configure mode.

Example:

apic1# configure

Step 2

Enable the eBGP multipath relax feature in a BGP best path template (policy).

Example:

apic1(config)# leaf 200
apic1(config-leaf)# template bgp bestpath policy1 tenant tenant1
apic1(config-bgp-bestpath)# as-path multipath-relax
apic1(config-bgp-bestpath)# exit

The template policy1 will be available on all nodes where tenant tenant1 has a VRF deployment.

Step 3

Inherit the template into a VRF instance.

The following example commands inherit template policy1 into VRF instance vrf1 in tenant tenant1 on node 42.

Example:

apic1(config-leaf)# router bgp 42
apic1(config-leaf-bgp)# vrf member tenant tenant1 vrf vrf1
apic1(config-leaf-bgp-vrf)# inherit bgp bestpath policy1

Configuring eBGP Multipath Relax Using the REST API

The following procedure configures eBGP multipath relax using the REST API.

Before you begin

This procedure assumes that you previously created a BGP best path policy and a logical node profile under a tenant.

Procedure

Send a post with XML similar to the following example to configure eBGP multipath relax:

Example:

<polUni>
    <fvTenant name="tenant1" status="">
        <bgpBestPathCtrlPol name="policy1" ctrl="multipath-relax" />
        <l3extOut name="out1" >
            <l3extRsEctx tnFvCtxName="vrf1"/>
            <l3extLNodeP name="np1">
                <bgpProtP>
                    <bgpRsBestPathCtrlPol tnBgpBestPathCtrlPolName="policy1" />
                </bgpProtP>
                <l3extRsNodeL3OutAtt rtrId="11.11.11.102" tDn="topology/pod-1/node-200"/>
                <l3extLIfP name="ifp1">
                    <l3extRsPathL3OutAtt addr="12.12.12.3/24" ifInstT="l3-port"
                      tDn="topology/pod-1/paths-200/pathep-[eth1/4]"/>
                </l3extLIfP>
            </l3extLNodeP>
        </l3extOut>
    </fvTenant>
</polUni>

This example enables eBGP multipath relax in the policy policy1, and inherits policy policy1 into VRF instance vrf1 in tenant tenant1.

Configuring BFD Support

Use the procedures in the following sections to configure BFD support.

Bidirectional Forwarding Detection

Use Bidirectional Forwarding Detection (BFD) to provide sub-second failure detection times in the forwarding path between ACI fabric border leaf switches configured to support peering router connections.

BFD is particularly useful in the following scenarios:

When the peering routers are connected through a Layer 2 device or a Layer 2 cloud where the routers are not directly connected to each other. Failures in the forwarding path may not be visible to the peer routers. The only mechanism available to control protocols is the hello timeout, which can take tens of seconds or even minutes to time out. BFD provides sub-second failure detection times.
When the peering routers are connected through a physical media that does not support reliable failure detection, such as shared Ethernet. In this case too, routing protocols have only their large hello timers to fall back on.
When many protocols are running between a pair of routers, each protocol has its own hello mechanism for detecting link failures, with its own timeouts. BFD provides a uniform timeout for all the protocols, which makes convergence time consistent and predictable.

Observe the following BFD guidelines and limitations:

Prior to APIC release 5.0, BFD echo packets received on a leaf switch from neighbor routers are classified with the default QoS class (best effort). Due to that classification, BFD drops might result when there is congestion on the interfaces.
Starting from APIC release 3.1(1), BFD between leaf and spine switches is supported on fabric-interfaces for IS-IS. In addition, BFD feature on spine switch is supported for OSPF and static routes.
BFD is supported on modular spine switches that have -EX and -FX line cards (or newer versions), and BFD is also supported on the Nexus 9364C non-modular spine switch (or newer versions).
BFD between VPC peers is not supported.
Multihop BFD is not supported.
BFD over iBGP is not supported for loopback address peers.
BFD sub interface optimization can be enabled in an interface policy. One sub-interface having this flag will enable optimization for all the sub-interfaces on that physical interface.
BFD for BGP prefix peer not supported.

Note

For the appropriate MTU values for each platform, see the relevant configuration guides.

We highly recommend that you test the MTU using CLI-based commands. For example, on the Cisco NX-OS CLI, use a command such as ping 1.1.1.1 df-bit packet-size 9000 source-interface ethernet 1/1.

Configuring BFD on an Individual Layer 3 Out Using the GUI

Before you begin

The tenant and VRF are configured.
A Layer 3 Out is configured and a logical node profile under the Layer 3 Out is configured.

Procedure

Step 1	On the menu bar, click Tenants > `tenant_name`.
Step 2	In the Navigation pane, click Networking > External Routed Networks > `L3Out` > Logical Node Profiles > `logical-node-profile` > Logical Interface Profiles > `logical-interface-profile`.
Step 3	In the Navigation pane, right-click on your Logical Interface Profile, and select Create BFD Interface Profile. The Create BFD Interface Profile page appears.
Step 4	Enter the necessary information in this page to create the BFD interface profile. In the Authentication Type area, select the authentication type. The authentication types are: No authentication: No authentication is used. Keyed SHA1 The default is No authentication. In the BFD Interface Policy area, enter the target BFD interface policy name. This name can be between 1 and 64 alphanumeric characters. Note that you cannot change this name after the object has been saved.
Step 5	Click Submit.

Configuring BFD Globally on Leaf Switch Using the GUI

Procedure

Step 1

On the menu bar, choose Fabric > Access Policies.

Step 2

In the Navigation pane, expand the Switch Policies > Policies > BFD.

There are two types of bidirectional forwarding detection (BFD) configurations available:

BFD IPV4
BFD IPV6

For each of these BFD configurations, you can choose to use the default policy or create a new one for a specific switch (or set of switches).

Note

By default, the APIC controller creates default policies when the system comes up. These default policies are global, bi-directional forwarding detection (BFD) configuration polices. You can set attributes within that default global policy in the Work pane, or you can modify these default policy values. However, once you modify a default global policy, note that your changes affect the entire system (all switches). If you want to use a specific configuration for a particular switch (or set of switches) that is not the default, create a switch profile as described in the next step.

Step 3

To create a switch profile for a specific global BFD policy (which is not the default), in the Navigation pane, expand the Switch Policies > Profiles > Leaf Profiles.

The Profiles - Leaf Profiles screen appears in the Work pane.

Step 4

On the right side of the Work pane, under ACTIONS, select Create Leaf Profile.

The Create Leaf Profile dialog box appears.

Step 5

In the Create Leaf Profile dialog box, perform the following actions:

In the Name field, enter a name for the leaf switch profile.
In the Description field, enter a description of the profile. (This step is optional.)
In the Switch Selectors field, enter the appropriate values for Name (name the switch), Blocks (select the switch), and Policy Group (select Create Access Switch Policy Group).

The Create Access Switch Policy Group dialog box appears where you can specify the Policy Group identity properties.

Step 6

In the Create Access Switch Policy Group dialog box, perform the following actions:

In the Name field, enter a name for the policy group.
In the Description field, enter a description of the policy group. (This step is optional.)
Choose a BFD policy type (BFD IPV4 Policy or BFD IPV6 Policy), then select a value (default or Create BFD Global Ipv4 Policy for a specific switch or set of switches).

Step 7

Click SUBMIT.

Another way to create a BFD global policy is to right-click on either BFD IPV4 or BFD IPV6 in the Navigation pane.

Step 8

To view the BFD global configuration you created, in the Navigation pane, expand the Switch Policies > Policies > BFD.

Configuring BFD Globally on Spine Switch Using the GUI

Procedure

Step 1

On the menu bar, choose Fabric > Access Policies.

Step 2

In the Navigation pane, expand the Switch Policies > Policies > BFD.

There are two types of bidirectional forwarding detection (BFD) configurations available:

BFD IPV4
BFD IPV6

For each of these BFD configurations, you can choose to use the default policy or create a new one for a specific switch (or set of switches).

Note

Step 3

To create a spine switch profile for a specific global BFD policy (which is not the default), in the Navigation pane, expand the Switch Policies > Profiles > Spine Profiles.

The Profiles- Spine Profiles screen appears in the Work pane.

Step 4

On the right side of the Work pane, under ACTIONS, select Create Spine Profile.

The Create Spine Profile dialog box appears.

Step 5

In the Create Spine Profile dialog box, perform the following actions:

In the Name field, enter a name for the switch profile.
In the Description field, enter a description of the profile. (This step is optional.)
In the Spine Selectors field, enter the appropriate values for Name (name the switch), Blocks (select the switch), and Policy Group (select Create Spine Switch Policy Group).

The Create Spine Switch Policy Group dialog box appears where you can specify the Policy Group identity properties.

Step 6

In the Create Spine Switch Policy Group dialog box, perform the following actions:

In the Name field, enter a name for the policy group.
In the Description field, enter a description of the policy group. (This step is optional.)
Choose a BFD policy type (BFD IPV4 Policy or BFD IPV6 Policy), then select a value (default or Create BFD Global Ipv4 Policy for a specific switch or set of switches).

Step 7

Click SUBMIT.

Another way to create a BFD global policy is to right-click on either BFD IPV4 or BFD IPV6 in the Navigation pane.

Step 8

To view the BFD global configuration you created, in the Navigation pane, expand the Switch Policies > Policies > BFD.

Configuring BFD Globally on Leaf Switch Using the NX-OS Style CLI

Procedure

Step 1	To configure the BFD IPV4 global configuration (bfdIpv4InstPol) using the NX-OS CLI: Example: `apic1# configure apic1(config)# template bfd ip bfd_ipv4_global_policy apic1(config-bfd)# [no] echo-address 1.2.3.4 apic1(config-bfd)# [no] slow-timer 2500 apic1(config-bfd)# [no] min-tx 100 apic1(config-bfd)# [no] min-rx 70 apic1(config-bfd)# [no] multiplier 3 apic1(config-bfd)# [no] echo-rx-interval 500 apic1(config-bfd)# exit`
Step 2	To configure the BFD IPV6 global configuration (bfdIpv6InstPol) using the NX-OS CLI: Example: `apic1# configure apic1(config)# template bfd ipv6 bfd_ipv6_global_policy apic1(config-bfd)# [no] echo-address 34::1/64 apic1(config-bfd)# [no] slow-timer 2500 apic1(config-bfd)# [no] min-tx 100 apic1(config-bfd)# [no] min-rx 70 apic1(config-bfd)# [no] multiplier 3 apic1(config-bfd)# [no] echo-rx-interval 500 apic1(config-bfd)# exit`
Step 3	To configure access leaf policy group (infraAccNodePGrp) and inherit the previously created BFD global policies using the NX-OS CLI: Example: `apic1# configure apic1(config)# template leaf-policy-group test_leaf_policy_group apic1(config-leaf-policy-group)# [no] inherit bfd ip bfd_ipv4_global_policy apic1(config-leaf-policy-group)# [no] inherit bfd ipv6 bfd_ipv6_global_policy apic1(config-leaf-policy-group)# exit`
Step 4	To associate the previously created leaf policy group onto a leaf using the NX-OS CLI: Example: `apic1(config)# leaf-profile test_leaf_profile apic1(config-leaf-profile)# leaf-group test_leaf_group apic1(config-leaf-group)# leaf-policy-group test_leaf_policy_group apic1(config-leaf-group)# leaf 101-102 apic1(config-leaf-group)# exit`

Configuring BFD Globally on Spine Switch Using the NX-OS Style CLI

Use this procedure to configure BFD globally on spine switch using the NX-OS style CLI.

Procedure

Step 1	To configure the BFD IPV4 global configuration (bfdIpv4InstPol) using the NX-OS CLI: Example: `apic1# configure apic1(config)# template bfd ip bfd_ipv4_global_policy apic1(config-bfd)# [no] echo-address 1.2.3.4 apic1(config-bfd)# [no] slow-timer 2500 apic1(config-bfd)# [no] min-tx 100 apic1(config-bfd)# [no] min-rx 70 apic1(config-bfd)# [no] multiplier 3 apic1(config-bfd)# [no] echo-rx-interval 500 apic1(config-bfd)# exit`
Step 2	To configure the BFD IPV6 global configuration (bfdIpv6InstPol) using the NX-OS CLI: Example: `apic1# configure apic1(config)# template bfd ipv6 bfd_ipv6_global_policy apic1(config-bfd)# [no] echo-address 34::1/64 apic1(config-bfd)# [no] slow-timer 2500 apic1(config-bfd)# [no] min-tx 100 apic1(config-bfd)# [no] min-rx 70 apic1(config-bfd)# [no] multiplier 3 apic1(config-bfd)# [no] echo-rx-interval 500 apic1(config-bfd)# exit`
Step 3	To configure spine policy group and inherit the previously created BFD global policies using the NX-OS CLI: Example: `apic1# configure apic1(config)# template spine-policy-group test_spine_policy_group apic1(config-spine-policy-group)# [no] inherit bfd ip bfd_ipv4_global_policy apic1(config-spine-policy-group)# [no] inherit bfd ipv6 bfd_ipv6_global_policy apic1(config-spine-policy-group)# exit`
Step 4	To associate the previously created spine policy group onto a spine switch using the NX-OS CLI: Example: `apic1# configure apic1(config)# spine-profile test_spine_profile apic1(config-spine-profile)# spine-group test_spine_group apic1(config-spine-group)# spine-policy-group test_spine_policy_group apic1(config-spine-group)# spine 103-104 apic1(config-leaf-group)# exit`

Configuring BFD Globally Using the REST API

Procedure

The following REST API shows the global configuration for bidirectional forwarding detection (BFD):

Example:


<polUni>
 <infraInfra>
    <bfdIpv4InstPol name="default" echoSrcAddr="1.2.3.4" slowIntvl="1000" minTxIntvl="150" minRxIntvl="250" detectMult="5" echoRxIntvl="200"/>
    <bfdIpv6InstPol name="default" echoSrcAddr="34::1/64" slowIntvl="1000" minTxIntvl="150" minRxIntvl="250" detectMult="5" echoRxIntvl="200"/>
 </infraInfra>
</polUni>

Configuring BFD Interface Override Using the GUI

There are three supported interfaces (routed Layer 3 interfaces, the external SVI interface, and the routed sub-interfaces) on which you can configure an explicit bi-directional forwarding detection (BFD) configuration. If you don't want to use the global configuration, yet you want to have an explicit configuration on a given interface, you can create your own global configuration, which gets applied to all the interfaces on a specific switch or set of switches. This interface override configuration should be used if you want more granularity on a specific switch on a specific interface.

Note

When a BFD interface policy is configured over a parent routed interface, by default all of its routed sub-interfaces with the same address family as that of the parent interface will inherit this policy. If any of the inherited configuration needs to be overridden, configure an explicit BFD interface policy on the sub-interfaces. However, if Admin State or Echo Admin State is disabled on the parent interface, the property cannot be overridden on the sub-interfaces.

Before you begin

A tenant has already been created.

Procedure

Step 1	On the menu bar, choose Tenant.
Step 2	In the Navigation pane (under Quick Start), expand the Tenant you created `Tenant_name` > Networking > External Routed Networks.
Step 3	Right-click on External Routed Networks and select Create Routed Outside. The Create Routed Outside dialog box appears.
Step 4	In the Create Routed Outside dialog box, under Define the Routed Outside, there should be an existing configuration already set up. If not, enter the values to define the identity of the Routed Outside configuration.
Step 5	Under Nodes And Interfaces Protocol Profiles, at the bottom of the Create Routed Outside dialog box, click the "+" (expand) button. The Create Node Profile dialog box appears.
Step 6	Under Specify the Node Profile, enter the name of the node profile in the Name field.
Step 7	Click the "+" (expand) button located to the right of the Nodes field. The Select Node dialog box appears.
Step 8	Under Select node and Configure Static Routes, select a node in the Node ID field.
Step 9	Enter the router ID in the Router ID field.
Step 10	Click OK. The Create Node Profile dialog box appears.
Step 11	Click the "+" (expand) button located to the right of the Interface Profiles field. The Create Interface Profile dialog box appears.
Step 12	Enter the name of the interface profile in the Name field.
Step 13	Select the desired user interface for the node you previously created, by clicking one of the Interfaces tabs: Routed Interfaces SVI Routed Sub-Interfaces
Step 14	In the BFD Interface Profile field, enter BFD details. In the Authentication Type field, choose No authentication or Keyed SHA1. If you choose to authenticate (by selecting Keyed SHA1), enter the Authentication Key ID, enter the Authentication Key (password), then confirm the password by re-entering it next to Confirm Key.
Step 15	For the BFD Interface Policy field, select either the common/default configuration (the default BFD policy), or create your own BFD policy by selecting Create BFD Interface Policy. If you select Create BFD Interface Policy, the Create BFD Interface Policy dialog box appears where you can define the BFD interface policy values.
Step 16	Click SUBMIT.
Step 17	To see the configured interface level BFD policy, navigate to Networking > Protocol Polices > BFD.

Configuring BFD Interface Override Using the NX-OS Style CLI

Procedure

Step 1	To configure BFD Interface Policy (bfdIfPol) using the NX-OS CLI: Example: apic1# configure apic1(config)# tenant t0 apic1(config-tenant)# vrf context v0 apic1(config-tenant-vrf)# exit apic1(config-tenant)# exit apic1(config)# leaf 101 apic1(config-leaf)# vrf context tenant t0 vrf v0 apic1(config-leaf-vrf)# exit apic1(config-leaf)# interface Ethernet 1/18 apic1(config-leaf-if)# vrf member tenant t0 vrf v0 apic1(config-leaf-if)# exit apic1(config-leaf)# template bfd bfdIfPol1 tenant t0 apic1(config-template-bfd-pol)# [no] echo-mode enable apic1(config-template-bfd-pol)# [no] echo-rx-interval 500 apic1(config-template-bfd-pol)# [no] min-rx 70 apic1(config-template-bfd-pol)# [no] min-tx 100 apic1(config-template-bfd-pol)# [no] multiplier 5 apic1(config-template-bfd-pol)# [no] optimize subinterface apic1(config-template-bfd-pol)# exit
Step 2	To inherit the previously created BFD interface policy onto a L3 interface with IPv4 address using the NX-OS CLI: Example: `apic1# configure apic1(config)# leaf 101 apic1(config-leaf)# interface Ethernet 1/15 apic1(config-leaf-if)# bfd ip tenant mode apic1(config-leaf-if)# bfd ip inherit interface-policy bfdPol1 apic1(config-leaf-if)# bfd ip authentication keyed-sha1 key 10 key password`
Step 3	To inherit the previously created BFD interface policy onto an L3 interface with IPv6 address using the NX-OS CLI: Example: `apic1# configure apic1(config)# leaf 101 apic1(config-leaf)# interface Ethernet 1/15 apic1(config-leaf-if)# ipv6 address 2001::10:1/64 preferred apic1(config-leaf-if)# bfd ipv6 tenant mode apic1(config-leaf-if)# bfd ipv6 inherit interface-policy bfdPol1 apic1(config-leaf-if)# bfd ipv6 authentication keyed-sha1 key 10 key password`
Step 4	To configure BFD on a VLAN interface with IPv4 address using the NX-OS CLI: Example: `apic1# configure apic1(config)# leaf 101 apic1(config-leaf)# interface vlan 15 apic1(config-leaf-if)# vrf member tenant t0 vrf v0 apic1(config-leaf-if)# bfd ip tenant mode apic1(config-leaf-if)# bfd ip inherit interface-policy bfdPol1 apic1(config-leaf-if)# bfd ip authentication keyed-sha1 key 10 key password`
Step 5	To configure BFD on a VLAN interface with IPv6 address using the NX-OS CLI: Example: `apic1# configure apic1(config)# leaf 101 apic1(config-leaf)# interface vlan 15 apic1(config-leaf-if)# ipv6 address 2001::10:1/64 preferred apic1(config-leaf-if)# vrf member tenant t0 vrf v0 apic1(config-leaf-if)# bfd ipv6 tenant mode apic1(config-leaf-if)# bfd ipv6 inherit interface-policy bfdPol1 apic1(config-leaf-if)# bfd ipv6 authentication keyed-sha1 key 10 key password`

Configuring BFD Interface Override Using the REST API

Procedure

The following REST API shows the interface override configuration for bidirectional forwarding detection (BFD):

Example:


<fvTenant name="ExampleCorp">    
  <bfdIfPol name=“bfdIfPol" minTxIntvl="400" minRxIntvl="400" detectMult="5" echoRxIntvl="400" echoAdminSt="disabled"/>  
    <l3extOut name="l3-out">   
        <l3extLNodeP name="leaf1">
            <l3extRsNodeL3OutAtt tDn="topology/pod-1/node-101" rtrId="2.2.2.2"/>            
            <l3extLIfP name='portIpv4'>
                <l3extRsPathL3OutAtt tDn="topology/pod-1/paths-101/pathep-[eth1/11]" ifInstT='l3-port' addr="10.0.0.1/24" mtu="1500"/>
                <bfdIfP type=“sha1” key=“password"> 
                    <bfdRsIfPol tnBfdIfPolName=‘bfdIfPol'/>
                </bfdIfP>
            </l3extLIfP>                                                                                                                                                                  
        </l3extLNodeP>
    </l3extOut>
</fvTenant>

Configuring BFD Consumer Protocols Using the GUI

This procedure provides the steps to enable bi-directional forwarding detection (BFD) in the consumer protocols (OSPF, BGP, EIGRP, Static Routes, and IS-IS), which are consumers of the BFD feature. To consume the BFD on these protocols, you must enable a flag in them.

Note

These four consumer protocols are located in the left navigation pane under Tenant > Networking > Protocol Policies.

Before you begin

A tenant has already been created.

Procedure

Step 1

On the menu bar, choose Tenant.

Step 2

To configure BFD in the BGP protocol, in the Navigation pane (under Quick Start), expand the Tenant you created Tenant_name > Networking > Protocol Policies > BGP > BGP Peer Prefix.

Step 3

On the right side of the Work pane, under ACTIONS, select Create BGP Peer Prefix Policy.

The Create BGP Peer Prefix Policy dialog box appears.

Note

You can also right-click on BGP Peer Prefix from the left navigation pane to select Create BGP Peer Prefix to create the policy.

Step 4

Enter a name in the Name field and provide values in the remaining fields to define the BGP peer prefix policy.

Step 5

Click SUBMIT.

The BGP peer prefix policy you created now appears under BGP Peer Prefix in the left navigation pane.

Step 6

In the Navigation pane, go back to Networking > External Routed Networks.

Step 7

Right-click on External Routed Networks and select Create Routed Outside.

The Create Routed Outside dialog box appears.

Step 8

In the Create Routed Outside dialog box, enter the name in the Name field. Then, to the right side of the Name field, select the BGP protocol.

Step 9

In the Nodes and Interfaces Protocol Profiles section , click the "+" (expand) button.

The Create Node Profile dialog box appears.

Step 10

In the BGP Peer Connectivity section, click the "+" (expand) button.

The Create BGP Peer Connectivity Profile dialog box appears.

Step 11

In the Create BGP Peer Connectivity Profile dialog box, next to Peer Controls, select Bidirectional Forwarding Detection to enable BFD on the BGP consumer protocol, shown as follows (or uncheck the box to disable BFD).

Step 12

To configure BFD in the OSPF protocol, in the Navigation pane, go to Networking > Protocol Policies > OSPF > OSPF Interface.

Step 13

On the right side of the Work pane, under ACTIONS, select Create OSPF Interface Policy.

The Create OSPF Interface Policy dialog box appears.

Note

You can also right-click on OSPF Interface from the left navigation pane and select Create OSPF Interface Policy to create the policy.

Step 14

Enter a name in the Name field and provide values in the remaining fields to define the OSPF interface policy.

Step 15

In the Interface Controls section of this dialog box, you can enable or disable BFD. To enable it, check the box next to BFD, which adds a flag to the OSPF consumer protocol, shown as follows (or uncheck the box to disable BFD).

Step 16

Click SUBMIT.

Step 17

To configure BFD in the EIGRP protocol, in the Navigation pane, go back to Networking > Protocol Policies > EIGRP > EIGRP Interface.

Step 18

On the right side of the Work pane, under ACTIONS, select Create EIGRP Interface Policy.

The Create EIGRP Interface Policy dialog box appears.

Note

You can also right-click on EIRGP Interface from the left navigation pane and select Create EIGRP Interface Policy to create the policy.

Step 19

Enter a name in the Name field and provide values in the remaining fields to define the OSPF interface policy.

Step 20

In the Control State section of this dialog box, you can enable or disable BFD. To enable it, check the box next to BFD, which adds a flag to the EIGRP consumer protocol (or uncheck the box to disable BFD).

Step 21

Click SUBMIT.

Step 22

To configure BFD in the Static Routes protocol, in the Navigation pane, go back to Networking > External Routed Networks.

Step 23

Right-click on External Routed Networks and select Create Routed Outside.

The Create Routed Outside dialog box appears.

Step 24

In the Define the Routed Outside section, enter values for all the required fields.

Step 25

In the Nodes and Interfaces Protocol Profiles section, click the "+" (expand) button.

The Create Node Profile dialog box appears.

Step 26

In the section Nodes, click the "+" (expand) button.

The Select Node dialog box appears.

Step 27

In the Static Routes section, click the "+" (expand) button.

The Create Static Route dialog box appears. Enter values for the required fields in this section.

Step 28

Next to Route Control, check the box next to BFD to enable (or uncheck the box to disable) BFD on the specified Static Route.

Step 29

Click OK.

Step 30

To configure BFD in the IS-IS protocol, in the Navigation pane go to Fabric > Fabric Policies > Interface Policies > Policies > L3 Interface.

Step 31

On the right side of the Work pane, under ACTIONS, select Create L3 Interface Policy.

The Create L3 Interface Policy dialog box appears.

Note

You can also right-click on L3 Interface from the left navigation pane and select Create L3 Interface Policy to create the policy.

Step 32

Enter a name in the Name field and provide values in the remaining fields to define the L3 interface policy.

Step 33

To enable BFD ISIS Policy, click Enable.

Step 34

Click SUBMIT.

Configuring BFD Consumer Protocols Using the NX-OS Style CLI

Procedure

Step 1	To enable BFD on the BGP consumer protocol using the NX-OS CLI: Example: `apic1# configure apic1(config)# bgp-fabric apic1(config-bgp-fabric)# asn 200 apic1(config-bgp-fabric)# exit apic1(config)# leaf 101 apic1(config-leaf)# router bgp 200 apic1(config-bgp)# vrf member tenant t0 vrf v0 apic1(config-leaf-bgp-vrf)# neighbor 1.2.3.4 apic1(config-leaf-bgp-vrf-neighbor)# [no] bfd enable`
Step 2	To enable BFD on the EIGRP consumer protocol using the NX-OS CLI: Example: `apic1(config-leaf-if)# [no] ip bfd eigrp enable`
Step 3	To enable BFD on the OSPF consumer protocol using the NX-OS CLI: Example: `apic1(config-leaf-if)# [no] ip ospf bfd enable` `apic1# configure apic1(config)# spine 103 apic1(config-spine)# interface ethernet 5/3.4 apic1(config-spine-if)# [no] ip ospf bfd enable`
Step 4	To enable BFD on the Static Route consumer protocol using the NX-OS CLI: Example: `apic1(config-leaf-vrf)# [no] ip route 10.0.0.1/16 10.0.0.5 bfd` `apic1(config)# spine 103 apic1(config-spine)# vrf context tenant infra vrf overlay-1 apic1(config-spine-vrf)# [no] ip route 21.1.1.1/32 32.1.1.1 bfd`
Step 5	To enable BFD on IS-IS consumer protocol using the NX-OS CLI: Example: `apic1(config)# leaf 101 apic1(config-spine)# interface ethernet 1/49 apic1(config-spine-if)# isis bfd enabled apic1(config-spine-if)# exit apic1(config-spine)# exit` `apic1(config)# spine 103 apic1(config-spine)# interface ethernet 5/2 apic1(config-spine-if)# isis bfd enabled apic1(config-spine-if)# exit apic1(config-spine)# exit`

Configuring BFD Consumer Protocols Using the REST API

Procedure

Step 1	The following example shows the interface configuration for bidirectional forwarding detection (BFD): Example: <fvTenant name="ExampleCorp"> <bfdIfPol name=“bfdIfPol" minTxIntvl="400" minRxIntvl="400" detectMult="5" echoRxIntvl="400" echoAdminSt="disabled"/> <l3extOut name="l3-out"> <l3extLNodeP name="leaf1"> <l3extRsNodeL3OutAtt tDn="topology/pod-1/node-101" rtrId="2.2.2.2"/> <l3extLIfP name='portIpv4'> <l3extRsPathL3OutAtt tDn="topology/pod-1/paths-101/pathep-[eth1/11]" ifInstT='l3-port' addr="10.0.0.1/24" mtu="1500"/> <bfdIfP type=“sha1” key=“password"> <bfdRsIfPol tnBfdIfPolName=‘bfdIfPol'/> </bfdIfP> </l3extLIfP> </l3extLNodeP> </l3extOut> </fvTenant>
Step 2	The following example shows the interface configuration for enabling BFD on OSPF and EIGRP: Example: BFD on leaf switch `<fvTenant name=“ExampleCorp"> <ospfIfPol name="ospf_intf_pol" cost="10" ctrl="bfd”/> <eigrpIfPol ctrl="nh-self,split-horizon,bfd" dn="uni/tn-Coke/eigrpIfPol-eigrp_if_default" </fvTenant>` Example: BFD on spine switch <l3extLNodeP name="bSpine"> <l3extRsNodeL3OutAtt tDn="topology/pod-1/node-103" rtrId="192.3.1.8"> <l3extLoopBackIfP addr="10.10.3.1" /> <l3extInfraNodeP fabricExtCtrlPeering="false" /> </l3extRsNodeL3OutAtt> <l3extLIfP name='portIf'> <l3extRsPathL3OutAtt tDn="topology/pod-1/paths-103/pathep-[eth5/10]" encap='vlan-4' ifInstT='sub-interface' addr="20.3.10.1/24"/> <ospfIfP> <ospfRsIfPol tnOspfIfPolName='ospf_intf_pol'/> </ospfIfP> <bfdIfP name="test" type="sha1" key="hello" status="created,modified"> <bfdRsIfPol tnBfdIfPolName='default' status="created,modified"/> </bfdIfP> </l3extLIfP> </l3extLNodeP>
Step 3	The following example shows the interface configuration for enabling BFD on BGP: Example: <fvTenant name="ExampleCorp"> <l3extOut name="l3-out"> <l3extLNodeP name="leaf1"> <l3extRsNodeL3OutAtt tDn="topology/pod-1/node-101" rtrId="2.2.2.2"/> <l3extLIfP name='portIpv4'> <l3extRsPathL3OutAtt tDn="topology/pod-1/paths-101/pathep-[eth1/11]" ifInstT='l3-port' addr="10.0.0.1/24" mtu="1500"> <bgpPeerP addr="4.4.4.4/24" allowedSelfAsCnt="3" ctrl="bfd" descr="" name="" peerCtrl="" ttl="1"> <bgpRsPeerPfxPol tnBgpPeerPfxPolName=""/> <bgpAsP asn="3" descr="" name=""/> </bgpPeerP> </l3extRsPathL3OutAtt> </l3extLIfP> </l3extLNodeP> </l3extOut> </fvTenant>
Step 4	The following example shows the interface configuration for enabling BFD on Static Routes: Example: BFD on leaf switch <fvTenant name="ExampleCorp"> <l3extOut name="l3-out"> <l3extLNodeP name="leaf1"> <l3extRsNodeL3OutAtt tDn="topology/pod-1/node-101" rtrId="2.2.2.2"> <ipRouteP ip=“192.168.3.4" rtCtrl="bfd"> <ipNexthopP nhAddr="192.168.62.2"/> </ipRouteP> </l3extRsNodeL3OutAtt> <l3extLIfP name='portIpv4'> <l3extRsPathL3OutAtt tDn="topology/pod-1/paths-101/pathep-[eth1/3]" ifInstT='l3-port' addr="10.10.10.2/24" mtu="1500" status="created,modified" /> </l3extLIfP> </l3extLNodeP> </l3extOut> </fvTenant> Example: BFD on spine switch <l3extLNodeP name="bSpine"> <l3extRsNodeL3OutAtt tDn="topology/pod-1/node-103" rtrId="192.3.1.8"> <ipRouteP ip="0.0.0.0" rtCtrl="bfd"> <ipNexthopP nhAddr="192.168.62.2"/> </ipRouteP> </l3extRsNodeL3OutAtt> <l3extLIfP name='portIf'> <l3extRsPathL3OutAtt tDn="topology/pod-1/paths-103/pathep-[eth5/10]" encap='vlan-4' ifInstT='sub-interface' addr="20.3.10.1/24"/> <bfdIfP name="test" type="sha1" key="hello" status="created,modified"> <bfdRsIfPol tnBfdIfPolName='default' status="created,modified"/> </bfdIfP> </l3extLIfP> </l3extLNodeP>
Step 5	The following example shows the interface configuration for enabling BFD on IS-IS: Example: <fabricInst> <l3IfPol name="testL3IfPol" bfdIsis="enabled"/> <fabricLeafP name="LeNode" > <fabricRsLePortP tDn="uni/fabric/leportp-leaf_profile" /> <fabricLeafS name="spsw" type="range"> <fabricNodeBlk name="node101" to_="102" from_="101" /> </fabricLeafS> </fabricLeafP> <fabricSpineP name="SpNode" > <fabricRsSpPortP tDn="uni/fabric/spportp-spine_profile" /> <fabricSpineS name="spsw" type="range"> <fabricNodeBlk name="node103" to_="103" from_="103" /> </fabricSpineS> </fabricSpineP> <fabricLePortP name="leaf_profile"> <fabricLFPortS name="leafIf" type="range"> <fabricPortBlk name="spBlk" fromCard="1" fromPort="49" toCard="1" toPort="49" /> <fabricRsLePortPGrp tDn="uni/fabric/funcprof/leportgrp-LeTestPGrp" /> </fabricLFPortS> </fabricLePortP> <fabricSpPortP name="spine_profile"> <fabricSFPortS name="spineIf" type="range"> <fabricPortBlk name="spBlk" fromCard="5" fromPort="1" toCard="5" toPort="2" /> <fabricRsSpPortPGrp tDn="uni/fabric/funcprof/spportgrp-SpTestPGrp" /> </fabricSFPortS> </fabricSpPortP> <fabricFuncP> <fabricLePortPGrp name = "LeTestPGrp"> <fabricRsL3IfPol tnL3IfPolName="testL3IfPol"/> </fabricLePortPGrp> <fabricSpPortPGrp name = "SpTestPGrp"> <fabricRsL3IfPol tnL3IfPolName="testL3IfPol"/> </fabricSpPortPGrp> </fabricFuncP> </fabricInst>

OSPF External Routed Networks

Use the procedures in the following sections to configure OSPF external routed networks.

OSPF Layer 3 Outside Connections

OSPF Layer 3 Outside connections can be normal or NSSA areas. The backbone (area 0) area is also supported as an OSPF Layer 3 Outside connection area. ACI supports both OSPFv2 for IPv4 and OSPFv3 for IPv6. When creating an OSPF Layer 3 Outside, it is not necessary to configure the OSPF version. The correct OSPF process is created automatically based on the interface profile configuration (IPv4 or IPv6 addressing). Both IPv4 and IPv6 protocols are supported on the same interface (dual stack) but it is necessary to create two separate interface profiles.

Layer 3 Outside connections are supported for the routed interfaces, routed sub-interfaces, and SVIs. The SVIs are used when there is a need to share the physical connect for both Layer 2 and Layer 3 traffic. The SVIs are supported on ports, port channels, and virtual port channels (vPCs).

When an SVI is used for an Layer 3 Outside connection, an external bridge domain is created on the border leaf switches. The external bridge domain allows connectivity between the two VPC switches across the ACI fabric. This allows both the VPC switches to establish the OSPF adjacencies with each other and the external OSPF device.

When running OSPF over a broadcast network, the time to detect a failed neighbor is the dead time interval (default 40 seconds). Reestablishing the neighbor adjacencies after a failure may also take longer due to designated router (DR) election.

Note

A link or port channel failure to one vPC Node does not cause an OSPF adjacency to go down. The OSPF adjacency can stay up using the external bridge domain accessible through the other vPC node.
When an OSPF time policy or a BGP, OSPF, or EIGRP address family policy is applied to an L3Out, you can observe the following behaviors:
- If the L3Out and the policy are defined in the same tenant, then there is no change in behavior.
- If the L3Out is configured in a user tenant other than the common tenant, the L3Out VRF instance is resolved to the common tenant, and the policy is defined in the common tenant, then only the default values are applied. Any change in the policy will not take effect.
If a border leaf switch forms OSPF adjacency with two external switches and one of the two switches experiences a route loss while the adjacent switches does not, the Cisco ACI border leaf switch reconverges the route for both neighbors.
OSPF supports aggressive timers. However, these timers quickly bring down the adjancency and cause CPU churn. Therefore, we recommend that you use the default timers and use bidirectional forwarding detection (BFD) to get sub-second failure detection.

Creating an OSPF External Routed Network for Management Tenant Using the GUI

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.

Procedure

Step 1

On the menu bar, choose TENANTS > mgmt.

Step 2

In the Navigation pane, expand Networking > External Routed Networks.

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:

In the Name field, enter a name (RtdOut).
Check the OSPF check box.
In the OSPF Area ID field, enter an area ID.
In the OSPF Area Control field, check the appropriate check box.
In the OSPF Area Type field, choose the appropriate area type.
In the OSPF Area Cost field, choose the appropriate value.

In the VRF field, from the drop-down list, choose the VRF (inb).

Note

This step associates the routed outside with the in-band VRF.

From the External Routed Domain drop-down list, choose the appropriate domain.
Click the + icon for Nodes and Interfaces Protocol Profiles area.

Step 5

In the Create Node Profile dialog box, perform the following actions:

In the Name field, enter a name for the node profile. (borderLeaf).
In the Nodes field, click the + icon to display the Select Node dialog box.
In the Node ID field, from the drop-down list, choose the first node. (leaf1).
In the Router ID field, enter a unique router ID.

Uncheck the Use Router ID as Loopback Address field.

Note

By default, the router ID is used as a loopback address. If you want them to be different, uncheck the Use Router ID as Loopback Address check box.

Expand Loopback Addresses, and enter the IP address in the IP field. Click Update, and click OK.

Enter the desired IPv4 or IPv6 IP address.

In the Nodes field, expand the + icon to display the Select Node dialog box.

Note

You are adding a second node ID.

In the Node ID field, from the drop-down list, choose the next node. (leaf2).
In the Router ID field, enter a unique router ID.

Uncheck the Use Router ID as Loopback Address field.

Note

By default, the router ID is used as a loopback address. If you want them to be different, uncheck the Use Router ID as Loopback Address check box.

Expand Loopback Addresses, and enter the IP address in the IP field. Click Update, and click OK. Click OK.

Enter the desired IPv4 or IPv6 IP address.

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:

In the Name field, enter the name of the profile (portProf).
In the Interfaces area, click the Routed Interfaces tab, and click the + icon.
In the Select Routed Interfaces dialog box, in the Path field, from the drop-down list, choose the first port (leaf1, port 1/40).
In the IP Address field, enter an IP address and mask. Click OK.
In the Interfaces area, click the Routed Interfaces tab, and click the + icon.
In the Select Routed Interfaces dialog box, in the Path field, from the drop-down list, choose the second port (leaf2, port 1/40).

In the IP Address field, enter an IP address and mask. Click OK.

Note

This IP address should be different from the IP address you entered for leaf1 earlier.

In the Create Interface Profile dialog box, click OK.

The interfaces are configured along with the OSPF interface.

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:

In the Name field, enter a name for the external network (extMgmt).
Expand Subnet and in the Create Subnet dialog box, in the IP address field, enter an IP address and mask for the subnet.
In the Scope field, check the desired check boxes. Click OK.
In the Create External Network dialog box, click OK.

In the Create Routed Outside dialog box, click Finish.

Note

In the Work pane, in the External Routed Networks area, the external routed network icon (RtdOut) is now displayed.

Creating an OSPF External Routed Network for a Tenant Using the NX-OS CLI

Configuring external routed network connectivity involves the following steps:

Create a VRF under Tenant.
Configure L3 networking configuration for the VRF on the border leaf switches, which are connected to the external routed network. This configuration includes interfaces, routing protocols (BGP, OSPF, EIGRP), protocol parameters, route-maps.
Configure policies by creating external-L3 EPGs under tenant and deploy these EPGs on the border leaf switches. External routed subnets on a VRF which share the same policy within the ACI fabric form one "External L3 EPG" or one "prefix EPG".

Configuration is realized in two modes:

Tenant mode: VRF creation and external-L3 EPG configuration
Leaf mode: L3 networking configuration and external-L3 EPG deployment

The following steps are for creating an OSPF external routed network for a tenant. To create an OSPF external routed network for a tenant, you must choose a tenant and then create a VRF for the tenant.

Note

The examples in this section show how to provide external routed connectivity to the "web" epg in the "OnlineStore" application for tenant "exampleCorp".

Procedure

Step 1

Configure the VLAN domain.

Example:


apic1(config)# vlan-domain dom_exampleCorp   
apic1(config-vlan)# vlan 5-1000
apic1(config-vlan)# exit

Step 2

Configure the tenant VRF and enable policy enforcement on the VRF.

Example:

apic1(config)# tenant exampleCorp                   
apic1(config-tenant)# vrf context  
 exampleCorp_v1
apic1(config-tenant-vrf)# contract enforce
apic1(config-tenant-vrf)# exit

Step 3

Configure the tenant BD and mark the gateway IP as “public”. The entry "scope public" makes this gateway address available for advertisement through the routing protocol for external-L3 network.

Example:


apic1(config-tenant)# bridge-domain exampleCorp_b1
apic1(config-tenant-bd)# vrf member exampleCorp_v1
apic1(config-tenant-bd)# exit
apic1(config-tenant)# interface bridge-domain exampleCorp_b1
apic1(config-tenant-interface)# ip address 172.1.1.1/24 scope public 
apic1(config-tenant-interface)# exit

Step 4

Configure the VRF on a leaf.

Example:


apic1(config)# leaf 101   
apic1(config-leaf)# vrf context tenant exampleCorp vrf exampleCorp_v1

Step 5

Configure the OSPF area and add the route map.

Example:


apic1(config-leaf)# router ospf default   
apic1(config-leaf-ospf)# vrf member tenant exampleCorp vrf exampleCorp_v1
apic1(config-leaf-ospf-vrf)# area 0.0.0.1 route-map map100 out 
apic1(config-leaf-ospf-vrf)# exit
apic1(config-leaf-ospf)# exit

Step 6

Assign the VRF to the interface (sub-interface in this example) and enable the OSPF area.

Example:

Note

For the sub-interface configuration, the main interface (ethernet 1/11 in this example) must be converted to an L3 port through “no switchport” and assigned a vlan-domain (dom_exampleCorp in this example) that contains the encapsulation VLAN used by the sub-interface. In the sub-interface ethernet1/11.500, 500 is the encapsulation VLAN.


apic1(config-leaf)# interface ethernet 1/11
apic1(config-leaf-if)# no switchport
apic1(config-leaf-if)# vlan-domain member dom_exampleCorp
apic1(config-leaf-if)# exit
apic1(config-leaf)# interface ethernet 1/11.500
apic1(config-leaf-if)# vrf member tenant exampleCorp vrf exampleCorp_v1
apic1(config-leaf-if)# ip address 157.10.1.1/24
apic1(config-leaf-if)# ip router ospf default area 0.0.0.1

Step 7

Configure the external-L3 EPG policy. This includes the subnet to match for identifying the external subnet and consuming the contract to connect with the epg "web".

Example:


apic1(config)# tenant t100                     	
apic1(config-tenant)# external-l3 epg  l3epg100
apic1(config-tenant-l3ext-epg)# vrf member v100
apic1(config-tenant-l3ext-epg)# match ip 145.10.1.0/24
apic1(config-tenant-l3ext-epg)# contract consumer web
apic1(config-tenant-l3ext-epg)# exit
apic1(config-tenant)#exit

Step 8

Deploy the external-L3 EPG on the leaf switch.

Example:


apic1(config)# leaf 101
apic1(config-leaf)# vrf context tenant t100 vrf v100
apic1(config-leaf-vrf)# external-l3 epg l3epg100

Creating OSPF External Routed Network for Management Tenant Using REST API

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.

Procedure

Create an OSPF external routed network for management tenant.

Example:

POST: https://apic-ip-address/api/mo/uni/tn-mgmt.xml

<fvTenant name="mgmt">
   <fvBD name="bd1">
      <fvRsBDToOut tnL3extOutName="RtdOut" />
      <fvSubnet ip="1.1.1.1/16" />
      <fvSubnet ip="1.2.1.1/16" />
      <fvSubnet ip="40.1.1.1/24" scope="public" />
      <fvRsCtx tnFvCtxName="inb" />
   </fvBD>
   <fvCtx name="inb" />
   
   <l3extOut name="RtdOut">
      <l3extRsL3DomAtt tDn="uni/l3dom-extdom"/>
      <l3extInstP name="extMgmt">
      </l3extInstP>    
      <l3extLNodeP name="borderLeaf">    
         <l3extRsNodeL3OutAtt tDn="topology/pod-1/node-101" rtrId="10.10.10.10"/>         
         <l3extRsNodeL3OutAtt tDn="topology/pod-1/node-102" rtrId="10.10.10.11"/>         
         <l3extLIfP name='portProfile'>
           <l3extRsPathL3OutAtt tDn="topology/pod-1/paths-101/pathep-[eth1/40]" ifInstT='l3-port' addr="192.168.62.1/24"/>
           <l3extRsPathL3OutAtt tDn="topology/pod-1/paths-102/pathep-[eth1/40]" ifInstT='l3-port' addr="192.168.62.5/24"/>
            <ospfIfP/>
                                </l3extLIfP>
      </l3extLNodeP>
      <l3extRsEctx tnFvCtxName="inb"/>
      <ospfExtP areaId="57" />
   </l3extOut>   
</fvTenant>

EIGRP External Routed Networks

Use the procedures in the following sections to configure EIGRP external routed networks.

About EIGRP Layer 3 Outside Connections

This example shows how to configure Enhanced Interior Gateway Routing Protocol (EIGRP) when using the Cisco APIC. The following information applies when configuring EIGRP:

The tenant, VRF, and bridge domain must already be created.
The Layer 3 outside tenant network must already be configured.
The route control profile under routed outside must already be configured.
The EIGRP VRF policy is the same as the EIGRP family context policy.
EIGRP supports only export route control profile. The configuration related to route controls is common across all the protocols.

You can configure EIGRP to perform automatic summarization of subnet routes (route summarization) into network-level routes. For example, you can configure subnet 131.108.1.0 to be advertised as 131.108.0.0 over interfaces that have subnets of 192.31.7.0 configured. Automatic summarization is performed when there are two or more network router configuration commands configured for the EIGRP process. By default, this feature is enabled. For more information, see Route Summarization.

EIGRP Protocol Support

EIGRP protocol is modeled similar to other routing protocols in the Cisco Application Centric Infrastructure (ACI) fabric.

Supported Features

The following features are supported:

IPv4 and IPv6 routing
Virtual routing and forwarding (VRF) and interface controls for each address family
Redistribution with OSPF across nodes
Default route leak policy per VRF
Passive interface and split horizon support
Route map control for setting tag for exported routes
Bandwidth and delay configuration options in an EIGRP interface policy
Authentication support (supported for release 3.2(4) and later)

Unsupported Features

The following features are not supported:

Stub routing
EIGRP used for BGP connectivity
Multiple EIGRP L3extOuts on the same node
Per-interface summarization (an EIGRP summary policy will apply to all interfaces configured under an L3Out)
Per interface distribute lists for import and export

Categories of EIGRP Functions

EIGRP functions can be broadly categorized as follows:

Protocol policies
L3extOut configurations
Interface configurations
Route map support
Default route support
Transit support

Primary Managed Objects That Support EIGRP

The following primary managed objects provide EIGRP support:

EIGRP Address Family Context Policy eigrpCtxAfPol: Address Family Context policy configured under fvTenant (Tenant/Protocols).
fvRsCtxToEigrpCtxAfPol: Relation from a VRF to a eigrpCtxAfPol for a given address family (IPv4 or IPv6). There can be only one relation for each address family.
eigrpIfPol: EIGRP Interface policy configured in fvTenant.
eigrpExtP: Enable flag for EIGRP in an L3extOut.
eigrpIfP: EIGRP interface profile attached to an l3extLIfP.
eigrpRsIfPol: Relation from EIGRP interface profile to an eigrpIfPol.
Defrtleak: Default route leak policy under an l3extOut.

EIGRP Protocol Policies Supported Under a Tenant

The following EIGRP protocol policies are supported under a tenant:

EIGRP Interface policy (eigrpIfPol)—contains the configuration that is applied for a given address family on an interface. The following configurations are allowed in the interface policy:
- Hello interval in seconds
- Hold interval in seconds
- One or more of the following interface control flags:
  - split horizon
  - passive
  - next hop self
EIGRP Address Family Context Policy (eigrpCtxAfPol)—contains the configuration for a given address family in a given VRF. An eigrpCtxAfPol is configured under tenant protocol policies and can be applied to one or more VRFs under the tenant. An eigrpCtxAfPol can be enabled on a VRF through a relation in the VRF-per-address family. If there is no relation to a given address family, or the specified eigrpCtxAfPol in the relation does not exist, then the default VRF policy created under the common tenant is used for that address family.

The following configurations are allowed in the eigrpCtxAfPol:
- Administrative distance for internal route
- Administrative distance for external route
- Maximum ECMP paths allowed
- Active timer interval
- Metric version (32-bit / 64-bit metrics)

Guidelines and Limitations When Configuring EIGRP

When configuring EIGRP, follow these guidelines:

Configuring EIGRP and BGP for the same Layer 3 outside is not supported.
Configuring EIGRP and OSPF for the same Layer 3 outside is not supported.
There can be one EIGRP Layer 3 Out per node per VRF. If multiple VRFs are deployed on a node, each VRF can have its own Layer 3 Out.
Multiple EIGRP peers from a single Layer 3 Out is supported. This enables you to connect to multiple EIGRP devices from the same node with a single Layer 3 Out.

The following configurations will cause the EIGRP neighbors to flap:

Changing administrative distances or metric style (wide/narrow) through an EIGRP address family context in the VRF
Setting configurations of multiple EIGRP summary routes to external EPG all at once. In contrast, configuring only a single EIGRP summary route will not cause the EIGRP neighbors to flap.
Setting the following configurations that will cause a table-map used internally to be updated:
- Changing the route tag for the VRF
- Setting configurations of import direction route control for an OSPF L3Out in the same VRF on the same border leaf switch as an EIGRP L3Out (for example, enabling or disabling the Route Control Enforcement “Import” option or changing routes that are allowed or denied for the import direction). Note that such configurations are not allowed in an EIGRP L3Out itself as the feature is not supported for EIGRP. However, the configurations in an OSPF L3Out still impacts EIGRP L3Outs in the same VRF and leaf switch. This is because the import route control for OSPF utilizes a table-map that is shared, for other purposes, with EIGRP in the same VRF on the same border leaf switch.

Configuring EIGRP Using the GUI

Procedure

Step 1

On the menu bar, choose Tenants > All Tenants.

Step 2

In the Work pane, double click a tenant.

Step 3

In the Navigation pane, expand the Tenant_name > Networking > Protocol Policies > EIGRP.

Step 4

Right-click EIGRP Address Family Context and choose Create EIGRP Address Family Context Policy.

Step 5

In the Create EIGRP Address Family Context Policy dialog box, perform the following actions:

In the Name field, enter a name for the context policy.
In the Active Interval (min) field, choose an interval timer.
In the External Distance and the Internal Distance fields, choose the appropriate values.
In the Maximum Path Limit field, choose the appropriate load balancing value between interfaces (per node/per leaf switch).
In the Metric Style field, choose the appropriate metric style. Click Submit.

In the Work pane, the context policy details are displayed.

Step 6

To apply the context policy on a VRF, in the Navigation pane, expand Networking > VRFs.

Step 7

Choose the appropriate VRF, and in the Work pane under Properties, expand EIGRP Context Per Address Family.

Step 8

In the EIGRP Address Family Type drop-down list, choose an IP version.

Step 9

In the EIGRP Address Family Context drop-down list, choose the context policy. Click Update, and Click Submit.

Step 10

To enable EIGRP within the Layer 3 Out, in the Navigation pane, click Networking > External Routed Networks, and click the desired Layer 3 outside network.

Step 11

In the Work pane under Properties, check the checkbox for EIGRP, and enter the EIGRP Autonomous System number. Click Submit.

Step 12

To create an EIGRP interface policy, in the Navigation pane, click Networking > Protocol Policies > EIGRP Interface and perform the following actions:

Right-click EIGRP Interface, and click Create EIGRP Interface Policy.
In the Create EIGRP Interface Policy dialog box, in the Name field, enter a name for the policy.
In the Control State field, check the desired checkboxes to enable one or multiple controls.
In the Hello Interval (sec) field, choose the desired interval.
In the Hold Interval (sec) field, choose the desired interval. Click Submit.
In the Bandwidth field, choose the desired bandwidth.
In the Delay field, choose the desired delay in tens of microseconds or pico seconds.

In the Work pane, the details for the EIGRP interface policy are displayed.

Step 13

In the Navigation pane, click the appropriate external routed network where EIGRP was enabled, expand Logical Node Profiles and perform the following actions:

Expand an appropriate node and an interface under that node.
Right-click the interface and click Create EIGRP Interface Profile.
In the Create EIGRP Interface Profile dialog box, in the EIGRP Policy field, choose the desired EIGRP interface policy. Click Submit.

Note

The EIGRP VRF policy and EIGRP interface policies define the properties used when EIGRP is enabled. EIGRP VRF policy and EIGRP interface policies are also available as default policies if the user does not want to create new policies. So, if a user does not explicitly choose either one of the policies, the default policy is automatically utilized when EIGRP is enabled.

This completes the EIGRP configuration.

Configuring EIGRP Using the NX-OS-Style CLI

Procedure

Step 1	SSH to an Application Policy Infrastructure Controller (APIC) in the fabric: Example: `# ssh admin@node_name`
Step 2	Enter the configure mode: Example: `apic1# configure`
Step 3	Enter the configure mode for a tenant: Example: `apic1(config)# tenant tenant1`
Step 4	Configure the Layer 3 Outside on the tenant: Example: apic1(config-tenant)# show run # Command: show running-config tenant tenant1 # Time: Tue Feb 16 09:44:09 2016 tenant tenant1 vrf context l3out exit l3out l3out-L1 vrf member l3out exit l3out l3out-L3 vrf member l3out exit external-l3 epg tenant1 l3out l3out-L3 vrf member l3out match ip 0.0.0.0/0 match ip 3.100.0.0/16 match ipv6 43:101::/48 contract consumer default exit external-l3 epg tenant1 l3out l3out-L1 vrf member l3out match ipv6 23:101::/48 match ipv6 13:101::/48 contract provider default exit exit
Step 5	Configure a VRF for EIGRP on a leaf: Example: apic1(config)# leaf 101 apic1(config-leaf)# vrf context tenant tenant1 vrf l3out l3out l3out-L1 apic1(config-leaf-vrf)# show run # Command: show running-config leaf 101 vrf context tenant tenant1 vrf l3out l3out l3out-L1 # Time: Tue Feb 16 09:44:45 2016 leaf 101 vrf context tenant tenant1 vrf l3out l3out l3out-L1 router-id 3.1.1.1 route-map l3out-L1_in scope global ip prefix-list tenant1 permit 1:102::/48 match prefix-list tenant1 exit exit route-map l3out-L1_out scope global ip prefix-list tenant1 permit 3.102.10.0/23 ip prefix-list tenant1 permit 3.102.100.0/31 ip prefix-list tenant1 permit 3.102.20.0/24 ip prefix-list tenant1 permit 3.102.30.0/25 ip prefix-list tenant1 permit 3.102.40.0/26 ip prefix-list tenant1 permit 3.102.50.0/27 ip prefix-list tenant1 permit 3.102.60.0/28 ip prefix-list tenant1 permit 3.102.70.0/29 ip prefix-list tenant1 permit 3.102.80.0/30 ip prefix-list tenant1 permit 3.102.90.0/32 <OUTPUT TRUNCATED> ip prefix-list tenant1 permit ::/0 match prefix-list tenant1 exit exit route-map l3out-L1_shared scope global exit exit exit
Step 6	Configure the EIGRP interface policy: Example: apic1(config-leaf)# template eigrp interface-policy tenant1 tenant tenant1 This template will be available on all leaves where tenant tenant1 has a VRF deployment apic1(config-template-eigrp-if-pol)# show run # Command: show running-config leaf 101 template eigrp interface-policy tenant1 tenant tenant1 # Time: Tue Feb 16 09:45:50 2016 leaf 101 template eigrp interface-policy tenant1 tenant tenant1 ip hello-interval eigrp default 10 ip hold-interval eigrp default 30 ip throughput-delay eigrp default 20 tens-of-micro ip bandwidth eigrp default 20 exit exit
Step 7	Configure the EIGRP VRF policy: Example: `apic1(config-leaf)# template eigrp vrf-policy tenant1 tenant tenant1 This template will be available on all leaves where tenant tenant1 has a VRF deployment apic1(config-template-eigrp-vrf-pol)# show run # Command: show running-config leaf 101 template eigrp vrf-policy tenant1 tenant tenant1 # Time: Tue Feb 16 09:46:31 2016 leaf 101 template eigrp vrf-policy tenant1 tenant tenant1 metric version 64bit exit exit`
Step 8	Configure the EIGRP VLAN interface and enable EIGRP in the interface: Example: apic1(config-leaf)# interface vlan 1013 apic1(config-leaf-if)# show run # Command: show running-config leaf 101 interface vlan 1013 # Time: Tue Feb 16 09:46:59 2016 leaf 101 interface vlan 1013 vrf member tenant tenant1 vrf l3out ip address 101.13.1.2/24 ip router eigrp default ipv6 address 101:13::1:2/112 preferred ipv6 router eigrp default ipv6 link-local fe80::101:13:1:2 inherit eigrp ip interface-policy tenant1 inherit eigrp ipv6 interface-policy tenant1 exit exit apic1(config-leaf-if)# ip summary-address ? eigrp Configure route summarization for EIGRP apic1(config-leaf-if)# ip summary-address eigrp default 11.11.0.0/16 ? <CR> apic1(config-leaf-if)# ip summary-address eigrp default 11.11.0.0/16 apic1(config-leaf-if)# ip summary-address eigrp default 11:11:1::/48 apic1(config-leaf-if)# show run # Command: show running-config leaf 101 interface vlan 1013 # Time: Tue Feb 16 09:47:34 2016 leaf 101 interface vlan 1013 vrf member tenant tenant1 vrf l3out ip address 101.13.1.2/24 ip router eigrp default ip summary-address eigrp default 11.11.0.0/16 ip summary-address eigrp default 11:11:1::/48 ipv6 address 101:13::1:2/112 preferred ipv6 router eigrp default ipv6 link-local fe80::101:13:1:2 inherit eigrp ip interface-policy tenant1 inherit eigrp ipv6 interface-policy tenant1 exit exit
Step 9	Apply the VLAN on the physical interface: Example: apic1(config-leaf)# interface ethernet 1/5 apic1(config-leaf-if)# show run # Command: show running-config leaf 101 interface ethernet 1 / 5 # Time: Tue Feb 16 09:48:05 2016 leaf 101 interface ethernet 1/5 vlan-domain member cli switchport trunk allowed vlan 1213 tenant tenant13 external-svi l3out l3out-L1 switchport trunk allowed vlan 1613 tenant tenant17 external-svi l3out l3out-L1 switchport trunk allowed vlan 1013 tenant tenant1 external-svi l3out l3out-L1 switchport trunk allowed vlan 666 tenant ten_v6_cli external-svi l3out l3out_cli_L1 switchport trunk allowed vlan 1513 tenant tenant16 external-svi l3out l3out-L1 switchport trunk allowed vlan 1313 tenant tenant14 external-svi l3out l3out-L1 switchport trunk allowed vlan 1413 tenant tenant15 external-svi l3out l3out-L1 switchport trunk allowed vlan 1113 tenant tenant12 external-svi l3out l3out-L1 switchport trunk allowed vlan 712 tenant mgmt external-svi l3out inband_l1 switchport trunk allowed vlan 1913 tenant tenant10 external-svi l3out l3out-L1 switchport trunk allowed vlan 300 tenant tenant1 external-svi l3out l3out-L1 exit exit
Step 10	Enable router EIGRP: Example: `apic1(config-eigrp-vrf)# show run # Command: show running-config leaf 101 router eigrp default vrf member tenant tenant1 vrf l3out # Time: Tue Feb 16 09:49:05 2016 leaf 101 router eigrp default exit router eigrp default exit router eigrp default exit router eigrp default vrf member tenant tenant1 vrf l3out autonomous-system 1001 l3out l3out-L1 address-family ipv6 unicast inherit eigrp vrf-policy tenant1 exit address-family ipv4 unicast inherit eigrp vrf-policy tenant1 exit exit exit`

Configuring EIGRP Using the REST API

Procedure

Step 1	Configure an EIGRP context policy. Example: `<polUni> <fvTenant name="cisco_6"> <eigrpCtxAfPol actIntvl="3" descr="" dn="uni/tn-cisco_6/eigrpCtxAfP-eigrp_default_pol" extDist="170" intDist="90" maxPaths="8" metricStyle="narrow" name="eigrp_default_pol" ownerKey="" ownerTag=""/> </fvTenant> </polUni>`
Step 2	Configure an EIGRP interface policy. Example: `<polUni> <fvTenant name="cisco_6"> <eigrpIfPol bw="10" ctrl="nh-self,split-horizon" delay="10" delayUnit="tens-of-micro" descr="" dn="uni/tn-cisco_6/eigrpIfPol-eigrp_if_default" helloIntvl="5" holdIntvl="15" name="eigrp_if_default" ownerKey="" ownerTag=""/> </fvTenant> </polUni>`
Step 3	Configure an EIGRP VRF. Example: IPv4: `<polUni> <fvTenant name="cisco_6"> <fvCtx name="dev"> <fvRsCtxToEigrpCtxAfPol tnEigrpCtxAfPolName="eigrp_ctx_pol_v4" af="1"/> </fvCtx> </fvTenant> </polUni>` IPv6: `<polUni> <fvTenant name="cisco_6"> <fvCtx name="dev"> <fvRsCtxToEigrpCtxAfPol tnEigrpCtxAfPolName="eigrp_ctx_pol_v6" af="ipv6-ucast"/> </fvCtx> </fvTenant> </polUni>`
Step 4	Configure an EIGRP Layer3 Outside. Example: IPv4 `<polUni> <fvTenant name="cisco_6"> <l3extOut name="ext"> <eigrpExtP asn="4001"/> <l3extLNodeP name="node1"> <l3extLIfP name="intf_v4"> <l3extRsPathL3OutAtt addr="201.1.1.1/24" ifInstT="l3-port" tDn="topology/pod-1/paths-101/pathep-[eth1/4]"/> <eigrpIfP name="eigrp_ifp_v4"> <eigrpRsIfPol tnEigrpIfPolName="eigrp_if_pol_v4"/> </eigrpIfP> </l3extLIfP> </l3extLNodeP> </l3extOut> </fvTenant> </polUni>` IPv6 `<polUni> <fvTenant name="cisco_6"> <l3extOut name="ext"> <eigrpExtP asn="4001"/> <l3extLNodeP name="node1"> <l3extLIfP name="intf_v6"> <l3extRsPathL3OutAtt addr="2001::1/64" ifInstT="l3-port" tDn="topology/pod-1/paths-101/pathep-[eth1/4]"/> <eigrpIfP name="eigrp_ifp_v6"> <eigrpRsIfPol tnEigrpIfPolName="eigrp_if_pol_v6"/> </eigrpIfP> </l3extLIfP> </l3extLNodeP> </l3extOut> </fvTenant> </polUni>` IPv4 and IPv6 <polUni> <fvTenant name="cisco_6"> <l3extOut name="ext"> <eigrpExtP asn="4001"/> <l3extLNodeP name="node1"> <l3extLIfP name="intf_v4"> <l3extRsPathL3OutAtt addr="201.1.1.1/24" ifInstT="l3-port" tDn="topology/pod-1/paths-101/pathep-[eth1/4]"/> <eigrpIfP name="eigrp_ifp_v4"> <eigrpRsIfPol tnEigrpIfPolName="eigrp_if_pol_v4"/> </eigrpIfP> </l3extLIfP> <l3extLIfP name="intf_v6"> <l3extRsPathL3OutAtt addr="2001::1/64" ifInstT="l3-port" tDn="topology/pod-1/paths-101/pathep-[eth1/4]"/> <eigrpIfP name="eigrp_ifp_v6"> <eigrpRsIfPol tnEigrpIfPolName="eigrp_if_pol_v6"/> </eigrpIfP> </l3extLIfP> </l3extLNodeP> </l3extOut> </fvTenant> </polUni>
Step 5	(Optional) Configure the interface policy knobs. Example: `<polUni> <fvTenant name="cisco_6"> <eigrpIfPol bw="1000000" ctrl="nh-self,split-horizon" delay="10" delayUnit="tens-of-micro" helloIntvl="5" holdIntvl="15" name="default"/> </fvTenant> </polUni>` The `bandwidth` (bw) attribute is defined in Kbps. The `delayUnit` attribute can be "tens of micro" or "pico".

Cisco APIC Layer 3 Networking Configuration Guide, Release 3.x and Earlier

Bias-Free Language

Results

Chapter: Routing Protocol Support

Routing Protocol Support

About Routing Protocol Support

BGP External Routed Networks with BFD Support

Guidelines for Configuring a BGP Layer 3 Outside Network Connection

BGP Connection Types and Loopback Guidelines

Configuring BGP External Routed Networks

Configuring BGP External Routed Network Using the GUI

Before you begin

Procedure

Configuring BGP External Routed Network Using the NX-OS Style CLI

Procedure

Example:

Configuring BGP External Routed Network Using the REST API

Before you begin

Procedure

Example:

Configuring BGP Max Path

Configuring BGP Max Path Using the GUI

Before you begin

Procedure

Configuring BGP Max Path Using the NX-OS Style CLI

Configuring BGP Max Path Using the REST API

Configuring AS Path Prepend

Configuring AS Path Prepend

Configuring AS Path Prepend Using the GUI

Before you begin

Procedure

Configuring AS Path Prepend Using the NX-OS Style CLI

Before you begin

Procedure

Example:

What to do next

Configuring AS Path Prepend Using the REST API

BGP External Routed Networks with AS Override

About BGP Autonomous System Override

Configuring BGP External Routed Network with Autonomous System Override Enabled Using the GUI

Before you begin

Procedure

Configuring BGP External Routed Network with Autonomous System Override Enabled Using the REST API

Procedure

Example:

Configuring Per VRF Per Node BGP Timer Values

Per VRF Per Node BGP Timer Values

Configuring a Per VRF Per Node BGP Timer Using the Advanced GUI

Before you begin

Procedure

Configuring a Per VRF Per Node BGP Timer Using the REST API

Procedure

Example:

Deleting a Per VRF Per Node BGP Timer Using the REST API

Procedure

Example:

Configuring a Per VRF Per Node BGP Timer Policy Using the NX-OS Style CLI

Procedure

Example:

Example:

Example:

Example:

Example:

Troubleshooting Inconsistency and Faults

eBGP Multipath Relax

Configuring eBGP Multipath Relax Using the GUI

Before you begin

Procedure

Configuring eBGP Multipath Relax Using the NX-OS-Style CLI

Before you begin

Procedure

Example:

Example:

Example:

Configuring eBGP Multipath Relax Using the REST API

Before you begin

Procedure

Example:

Configuring BFD Support

Bidirectional Forwarding Detection