Cisco APIC Layer 3 Networking Configuration Guide, Release 5.1(x)

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 ACI to overwrite a remote AS in the AS_PATH with ACI BGP AS. In 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.
When configuring the BGP external routed network, incoming updates will have the local AS number prepended, but the BGP process prepends the local AS number last when sent to other eBGP peers. If you do not want this to happen, configure the no-prepend setting in the Local-AS Number Config field in the BGP Peer Connectivity Profile for the L3Out.
The local AS feature is used to advertise a different AS number than the AS assigned to the fabric MP-BGP Route Reflector Profile. If you enable the replace-as option in the Local-AS Number Config field in the BGP Peer Connectivity Profile for an L3Out, the neighbor that is configured with the local AS number will only see the different AS number that is being advertised rather than locally-configured AS number from the BGP process.
At this time, BGP L3Out to L3Out communication through the ACI fabric is not blocked but will not be supported in this scenario:
- Both L3Outs are in the same ASN, and/or
- The L3Out is forming an iBGP session with the ACI fabric
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, 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.
The user must configure an IPv6 address to enable peering over loopback using IPv6.
The autonomous system feature can only be used for eBGP peers. It enables a router to appear to be a member of a second autonomous system (AS), in addition to its real AS. Local AS allows two ISPs to merge without modifying peering arrangements. Routers in the merged ISP become members of the new autonomous system but continue to use their old AS numbers for their customers.

Starting with release 1.2(1x), 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. Once the max 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. Only one option can be used 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 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

BGP Protocol Peering to External BGP Speakers

ACI supports peering between the border leaves and the external BGP speakers using iBGP and eBGP. ACI supports the following connections for BGP peering:

iBGP peering over OSPF
eBGP peering over OSPF
iBGP peering over direct connection
eBGP peering over direct connection
iBGP peering over static route

Note

When OSPF is used with BGP peering, OSPF is only used to learn and advertise the routes to the BGP peering addresses. All route control applied to the Layer 3 Outside Network (EPG) are applied at the BGP protocol level.

ACI supports a number of features for iBGP and eBGP connectivity to external peers. The BGP features are configured on the BGP Peer Connectivity Profile.

The BGP peer connectivity profile features are described in the following table.

Note

ACI supports the following BGP features. NX-OS BGP features not listed below are not currently supported in ACI.

Table 1. BGP Peer Connectivity Profile Features
BGP Features	Feature Description	NX-OS Equivalent Commands
Allow Self-AS	Works with Allowed AS Number Count setting.	allowas-in
Disable peer AS check	Disable checking of the peer AS number when advertising.	disable-peer-as-check
Next-hop self	Always set the next hop attribute to the local peering address.	next-hop-self
Send community	Send the community attribute to the neighbor.	send-community
Send community extended	Send the extended community attribute to the neighbor.	send-community extended
Password	The BGP MD5 authentication.	password
Allowed AS Number Count	Works with Allow Self-AS feature.	allowas-in
Disable connected check	Disable connected check for the directly connected EBGP neighbors (allowing EBGP neighbor peering from the loopbacks).
TTL	Set the TTL value for EBGP multihop connections. It is only valid for EBGP.	ebgp-multihop <TTL>
Autonomous System Number	Remote Autonomous System number of the peer.	neighbor <x.x.x.x> remote-as
Local Autonomous System Number Configuration	Options when using the Local AS feature. (No Prepend+replace-AS+dual-AS etc).
Local Autonomous System Number	The local AS feature used to advertise a different AS number than the AS assigned to the fabric MP-BGP Route Reflector Profile. It is only supported for the EBGP neighbors and the local AS number must be different than the route reflector policy AS.	local-as xxx <no-prepend> <replace-as> <dual-as>

Configuring BGP External Routed Networks

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

Configuring BGP L3Out Using the GUI

Before you begin

The tenant, VRF, and bridge domain where you configure the BGP L3Out is already created, and you selected the Configure BGP Policies option when you were creating the VRF.

Procedure

Step 1

In the Navigation pane, expand Tenant_name > Networking > L3Outs.

Step 2

Right-click, and click Create L3Out.

The Create L3Out wizard appears.

Step 3

Enter the necessary information in the Identity window of the Create L3Out wizard.

Enter the necessary information in the Name, VRF and L3 Domain fields.

In the area with the routing protocol check boxes, choose BGP and OSPF.

Note

BGP peer reachability must be available in one of two ways. You must either configure static routes or enable OSPF. For these procedures, we are enabling OSPF through the Create L3Out wizard, but if you wanted to configure static routes instead, you would configure that setting after you have finished configuring the L3Out using the Create L3Out wizard, then go to Tenants > tenant_name > Networking > L3Outs > L3Out_name > Logical Node Profiles > logical_node_profile_name , then double-click on a node listed in the Nodes area to access the Static Routes area in the Node Association window.

Click Next to move to the Nodes and Interfaces window.

Step 4

Enter the necessary information in the Nodes and Interfaces window of the Create L3Out wizard.

In the Layer 3 area, select Routed.
From the Node ID field drop-down menu, choose the node for the L3Out.

For the topology in these examples, use node 103.
In the Router ID field, enter the router ID.
(Optional) You can configure another IP address for a loopback address, if necessary.

The Loopback Address field is automatically populated with the same entry that you provide in the Router ID field. This is the equivalent of the Use Router ID for Loopback Address option in previous builds. Enter a different IP address for a loopback address, if you don't want to use route ID for the loopback address, or leave this field empty if you do not want to use the router ID for the loopback address.
Enter necessary additional information in the Nodes and Interfaces window.

The fields shown in this window varies, depending on the options that you select in the Layer 3 and Layer 2 areas.
When you have entered the remaining additional information in the Nodes and Interfaces window, click Next.

The Protocols window appears.

Step 5

Enter the necessary information in the Protocols window of the Create L3Out wizard.

In the BGP Loopback Policies and BGP Interface Policies areas, enter the following information:

Peer Address: Enter the peer IP address
EBGP Multihop TTL: Enter the connection time to live (TTL). The range is from 1 to 255 hops; if zero, no TTL is specified. The default is zero.

Remote ASN: Enter a number that uniquely identifies the neighbor autonomous system. The Autonomous System Number can be in 4-byte as plain format from 1 to 4294967295.

Note

ACI does not support asdot or asdot+ format AS numbers.

In the OSPF area, choose the default OSPF policy, a previously created OSPF policy, or Create OSPF Interface Policy.
Click Next.

The External EPG window appears.

Step 6

Enter the necessary information in the External EPG window of the Create L3Out wizard.

In the Name field, enter a name for the external network.
In the Provided Contract field, enter the name of a provided contract.
In the Consumed Contract field, enter the name of a consumed contract.
In the Default EPG for all external networks field, uncheck if you don’t want to advertise all the transit routes out of this L3Out connection.

The Subnets area appears if you uncheck this box. Specify the desired subnets and controls as described in the following steps.
Click the + icon to expand Subnet, then perform the following actions in the Create Subnet dialog box.

In the IP address field, enter the IP address and network mask for the external network.

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 Name field, enter the name of the subnet.

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.

Click OK when you have completed the necessary configurations in the Create Subnet window.
Click Finish to complete the necessary configurations in the Create L3Out wizard.

Step 7

(Optional) Navigate to the BGP Peer Connectivity Profile window to make additional configurations for the BGP external routed network, if necessary:

Tenants > tenant_name > Networking > L3Outs > L3Out_name > Logical Node Profiles > log_node_prof_name > BGP Peer <address>

The BGP Peer Connectivity Profile for this L3Out appears.

In the BGP Controls field, check the desired controls.
The peer controls specify which Border Gateway Protocol (BGP) attributes are sent to a peer. The peer control options are:
- Allow Self AS—Enables the autonomous number check on itself. This allows BGP peer to inject updates if the same AS number is being used.
- AS override—Enables the BGP AS override feature to override the default setting. The AS override function will replace the AS number from the originating router with the AS number of the sending BGP router in the AS Path of outbound routes. This feature can be enabled per feature per address family (IPv4 or IPv6).
  Note:
  The Disable Peer AS Check check box must also be checked in order to enable the AS override feature.
- Disable Peer AS Check—Disables the peer autonomous number check. When the check box is checked, if the advertising router finds the AS number of the receiver in the AS path, it will not send the route to the receiver.
  Note:
  The Disable Peer AS Check check box must be checked in order to enable the AS override feature.
- Next-hop Self—Sends the BGP next hop attribute to itself.
- Send Community—Sends the BGP community attribute to a peer.
- Send Extended Community—Sends the BGP extended community attribute to a peer.
- Send Domain Path—Sends the BGP domain path to a peer.
In the Password and Confirm Password field, enter the administrative password.
In the Allow Self AS Number Count field, choose the allowed number of occurrences of a local Autonomous System Number (ASN).

The range is from 1 to 10. The default is 3.
In the Peer Controls field, enter the neighbor check parameters.
The options are:
- Bidirectional Forwarding Detection—Enables BFD on the peer.
- Disable Connected Check—Disables the check for peer connection.
In the Address Type Controls field, configure the BGP IPv4/IPv6 address-family feature, if desired.
- AF Mcast: Check to enable the multicast address-family feature.
- AF Ucast: Check to enable the unicast address-family feature.
Note the entry in the Routing Domain ID, if necessary.

The value in the Routing Domain ID field reflects the global Domain ID Base value that was entered in the BGP Route Reflector Policy page. See About the BGP Domain-Path Feature for Loop Prevention for more information.
In the EBGP Multihop TTL field, enter the connection time to live (TTL).

The range is from 1 to 255 hops; if zero, no TTL is specified. The default is zero.
In the Weight for routes from this neighbor field, choose the allowed weight for routes from the peer.

The weight assigned locally to the router is used to select the best path. The range is from 0 to 65535.
In the Private AS Control field, configure the private AS control.
These options are valid only when ACI BGP AS is a public AS number, or when the Local-AS Number Config with the no-Prepend+replace-as option is configured using a public AS number on the given BGP peer connectivity profile (the BGP neighbor configuration). The replace-as option is used to remove the actual local private AS from the AS_PATH because the Private AS Control feature does not remove its own local private AS.

The options are:
- Remove all private AS—In outgoing eBGP route updates to this neighbor, this option removes all private AS numbers from the AS_PATH, regardless of whether a public AS number is included in the AS_PATH.
  
  If the neighbor remote AS is in the AS_PATH, this option is not applied.
  
  To enable this option, Remove private AS must be enabled.
- Remove private AS—In outgoing eBGP route updates to this neighbor, this option removes all private AS numbers from the AS_PATH when the AS_PATH has only private AS numbers.
  
  If the neighbor remote AS is in the AS_PATH, this option is not applied.
- Replace private AS with local AS—In outgoing eBGP route updates to this neighbor, this option replaces all private AS numbers in the AS_PATH with ACI local AS, regardless of whether a public AS or the neighbor remote AS is included in the AS_PATH.
  
  To enable this option, Remove all private AS must be enabled.
In the BGP Peer Prefix Policy field, select an existing peer prefix policy or create a new one.

The peer prefix policy defines how many prefixes can be received from a neighbor and the action to take when the number of allowed prefixes is exceeded. This feature is commonly used for external BGP peers, but can also be applied to internal BGP peers.

In the Remote Autonomous System Number field, choose a number that uniquely identifies the neighbor autonomous system.

The Autonomous System Number can be in 4-byte asplain format from 1 to 4294967295.

Note

ACI does not support asdot or asdot+ format AS numbers.

In the Local-AS Number Config field, choose the local Autonomous System Number (ASN) configuration.
Using a local AS number rather than the Global AS permits the routing devices in the associated network to appear to belong to the former AS. The configuration can be:
- no-Prepend+replace-as+dual-as—Does not allow prepending on local AS and is replaced with both AS numbers.
  
  Note: You can prepend one or more autonomous system (AS) numbers at the beginning of an AS path. The AS numbers are added at the beginning of the path after the actual AS number from which the route originates has been added to the path. Prepending an AS path makes a shorter AS path look longer and therefore less preferable to BGP.
- no-prepend—Does not allow prepending on local AS.
- no options—Does not allow alteration of local AS.
- no-Prepend+replace-as—Does not allow prepending on local AS and is replaces AS number.

In the Local-AS Number field, choose the desired value.

Optionally required for the local autonomous system feature for eBGP peers. The local Autonomous System Number can be in 4-byte asplain format from 1 to 4294967295.

Note

ACI does not support asdot or asdot+ format AS numbers.

In the Admin State field, select Disabled or Enabled.
The Admin State field allows you to shut down the corresponding BGP neighbor. Using this feature shuts down the BGP sessions without the need to delete the BGP peer configuration.

Options are:
- Disabled: Disables the BGP neighbor's admin state.
- Enabled: Enables the BGP neighbor's admin state.
In the Route Control Profile field, configure route control policies per BGP peer.
Click + to configure the following:
- Name: The route control profile name.
- Direction: Choose one of the following options:
  - Route Import Policy
  - Route Export Policy
Click Submit.

Step 8

Navigate to Tenants > tenant_name > Networking > L3Outs > L3Out_name .

Step 9

Click the Policy/Main tab and perform the following actions:

(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.

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.

Step 10

Navigate to Tenants > tenant_name > Networking > L3Outs > L3Out_name .

Step 11

Right-click Route map for import and export route control and select Create Route map for import and export route control.

Step 12

Enter the necessary information in this window, then click + in the Context area to bring up the Create Route Control Context window.

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.

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` > Policies > Protocol > BGP > BGP Address Family Context and 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	Locate the BGP Context Per Address Family field and, in the BGP Address Family Type area, select either IPv4 unicast address family or IPv6 unicast address family.
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 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` > Policies > Protocol > Set Rules and right click Create Set Rules for a Route Map. The Create Set Rules For A Route Map window appears.
Step 2	In the Create Set Rules For A Route Map dialog box, perform the following tasks: In the Name field, enter a name. Check the Set AS Path checkbox, then click Next. In the AS Path window, click + to open the Create Set AS Path dialog box.
Step 3	Select the criterion Prepend AS, then click + to prepend AS numbers.
Step 4	Enter the AS number and its order and then click Update. Repeat by clicking + again if multiple AS numbers must be prepended.
Step 5	When you have completed the prepend AS number configurations, 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	Click OK.
Step 8	In the Create Set Rules For A Route Map window, confirm the listed criteria for the set rule based on AS Path and click Finish.
Step 9	On the APIC GUI menu bar, click Tenants > `tenant_name` > Policies > Protocol > Set Rules and right click your profile.
Step 10	Confirm the Set AS Path values the bottom of the screen.

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 > L3Outs > 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.

BGP Neighbor Shutdown and Soft Reset

Use the procedures in the following sections to configure BGB neighbor shutdown and soft reset.

About BGP Neighbor Shutdown and Soft Reset

Beginning with Release 4.2(1), support is now available for the following features:

BGP Neighbor Shutdown
BGP Neighbor Soft Reset

BGP Neighbor Shutdown

The BGP neighbor shutdown feature is similar to the neighbor shutdown command in NX-OS, which shuts down the corresponding BGP neighbor. Use this policy to disable and enable the BGP neighbor's admin state. Using this feature shuts down the BGP sessions without the need to delete the BGP peer configuration.

BGP Neighbor Soft Reset

Using the BGP route refresh capability, the BGP neighbor soft reset feature provides automatic support for a dynamic soft reset of inbound and outbound BGP routing table updates that are not dependent upon stored routing table update information. Use this policy to enable the soft dynamic inbound reset and soft outbound reset.

Configuring BGP Neighbor Shutdown Using the GUI

The following procedure describes how to use the BGP neighbor shutdown feature using the GUI.

Before you begin

Complete the standard prerequisites before configuring an L3Out, such as:

Configure the node, port, functional profile, AEP, and Layer 3 domain.
Configure a BGP Route Reflector policy to propagate the routes within the fabric.

Procedure

Step 1

Create the L3Out and configure the BGP for the L3Out:

On the Navigation pane, expand Tenant and Networking.
Right-click L3Outs and choose Create L3Out.
Enter the necessary information to configure BGP for the L3Out.

You will select BGP in the Identity page in the L3Out creation wizard to configure the BGP protocol for this L3Out.
Continue through the remaining pages (Nodes and Interfaces, Protocols, and External EPG) to complete the configuration for the L3Out.

Step 2

After you have completed the L3Out configuration, configure the BGP neighbor shutdown:

Navigate to the BGP Peer Connectivity Profile screen:

Tenants > tenant > Networking > L3Outs > L3out-name > Logical Node Profiles > logical-node-profile-name > Logical Interface Profiles > logical-interface-profile-name > BGP Peer Connectivity Profile IP-address
Scroll down to the Admin State field and make the appropriate selection in this field.
- Disabled: Disables the BGP neighbor's admin state.
- Enabled: Enables the BGP neighbor's admin state.

Configuring BGP Neighbor Soft Reset Using the GUI

The following procedure describes how to use the BGP neighbor soft reset feature using the GUI.

Before you begin

Complete the standard prerequisites before configuring an L3Out, such as:

Configure the node, port, functional profile, AEP, and Layer 3 domain.
Configure a BGP Route Reflector policy to propagate the routes within the fabric.

Procedure

Step 1

Create the L3Out and configure the BGP for the L3Out:

On the Navigation pane, expand Tenant and Networking.
Right-click L3Outs and choose Create L3Out.
Enter the necessary information to configure BGP for the L3Out.

You will select BGP in the Identity page in the L3Out creation wizard to configure the BGP protocol for this L3Out.
Continue through the remaining pages (Nodes and Interfaces, Protocols, and External EPG) to complete the configuration for the L3Out.

Step 2

After you have completed the L3Out configuration, configure the BGP neighbor soft reset:

Navigate to the BGP Peer Entry screen:

Tenants > tenant > Networking > L3Outs > L3out-name > Logical Node Profiles > logical-node-profile-name > Configured Nodes > node > BGP for VRF-vrf-name > Neighbors
Right-click on the appropriate neighbor entry and select Clear BGP Peer.

The Clear BGP page appears.
In the Mode field, select Soft.

The Direction fields appear.
Select the appropriate value in the Direction field:
- Incoming: Enables the soft dynamic inbound reset.
- Outgoing: Enables the soft outbound reset.

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 > Policies > Protocol > BGP > BGP Timers, then right click Create BGP Timers Policy.

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 Tenant > Tenant_name > Networking > L3Outs, and right-click Create L3Out.

The Create L3Out wizard appears. Create an L3Out with BGP enabled by performing the following actions.

Step 4

Enter the necessary information in the Identity window of the Create L3Out wizard.

In the Name field, enter a name for the L3Out.
From the VRF drop-down list, choose the VRF.
From the L3 Domain drop-down list, choose an external routed domain.
In the area with the routing protocol check boxes, check the BGP box.
Click Next to move to the Nodes and Interfaces window.
Continue through the remaining windows in the Create L3Out wizard to complete the L3Out creation process.

Step 5

After you have created the L3Out, navigate to the logical node profile in the L3Out that you just created: Tenant > Tenant_name > Networking > L3Outs > L3Out_name > Logical Node Profiles > LogicalNodeProfile-name .

Step 6

In the Logical Node Profile window, check next to Create BGP Protocol Profile.

The Create Node Specific BGP Protocol Profile window appears.

Step 7

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 Submit.

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 8

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

Expand Tenant > Tenant_name > Networking > L3Outs > L3Out_name > Logical Node Profiles > LogicalNodeProfile-name > BGP Protocol Profile.
In the Work pane, the BGP protocol profile that is associated with the node profile is displayed.

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.

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:

Beginning with 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.
Beginning with APIC Release 5.0(1), BFD multihop is supported on leaf switches. The maximum number of BFD sessions is unchanged, as BFD multihop sessions are now included in the total.
Beginning with APIC Release 5.0(1), ACI supports C-bit-aware BFD. The C-bit on incoming BFD packets determines whether BFD is dependent or independent of the control plane.
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.

Optimizing BFD on Subinterfaces

You can optimize BFD on subinterfaces. BFD creates sessions for all configured subinterfaces. BFD sets the subinterface with the lowest configured VLAN ID as the master subinterface and that subinterface uses the BFD session parameters of the parent interface. The remaining subinterfaces use the slow timer.

If the optimized subinterface session detects an error, BFD marks all subinterfaces on that physical interface as down.

You can configure the BFD echo function on one or both ends of a BFD-monitored link. The echo function slows down the required minimum receive interval, based on the configured slow timer. The RequiredMinEchoRx BFD session parameter is set to zero if the echo function is disabled. The slow timer becomes the required minimum receive interval if the echo function is enabled.

Note

If one of the subinterfaces flap, subinterfaces on that physical interface are impacted and will go down for a second.

Configuring Bidirectional Forwarding Detection on a Secondary IP Address Using the GUI

This procedure configures bidirectional forwarding detection (BFD) on a secondary IP address using the GUI.

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	In the Navigation pane, choose `tenant_name` > Networking > L3Outs > `l3out_name` > Logical Node Profiles > `node_profile_name` > Logical Interface Profiles > `interface_profile_name`.
Step 4	In the Work pane, choose Policy > Routed Sub-interfaces, Policy > Routed Interfaces, or Policy > SVI, as appropriate.
Step 5	Double-click an interface to edit its properties.
Step 6	Perform one of the following substeps depending on the type of interface: If the interface is a routed sub-interface or routed interface, or a Switch Virtual Interface (SVI) with the Path Type set to Port or Direct Port Channel, in the IPv4 secondary/IPv6 Additional Addresses table, click the + , enter the IP address and subnet, and click Submit. If the interface is a Switch Virtual Interface (SVI) with the Path Type set to Virtual Port Channel, in the Side B IPv4 Secondary/IPv6 Additional Addresses table, click the + , enter the IP address and subnet, and click OK.
Step 7	In the Navigation pane, choose `tenant_name` > Networking > L3Outs > `l3out_name` > Logical Node Profiles > `node_profile_name` > Configured Nodes > `node_name`.
Step 8	In the Static Routes table, click the + and perform the following substeps: In the Prefix field, enter the static route IP address and mask that is assigned to the outside network. Put a chick in the BFD check box. In the Next Hop Addresses table, click the + and in the Next Hop Address field, enter an IP address that is reachable by the secondary IP address that you specified for the interface. Fill out the remaining fields as necessary. Click OK.
Step 9	Fill out the remaining fields as necessary.
Step 10	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 Policies > Switch > 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 Switches > Leaf Switches > Profiles.

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

Step 4

On the right side of the Work pane, under the acttions icon, 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.
(Optional) In the Description field, enter a description of the profile.
(Optional) In the Leaf Selectors toolbar, click +
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

(If configuring a leaf selector) In the Create Access Switch Policy Group dialog box, perform the following actions:

In the Name field, enter a name for the policy group.
(Optional) In the Description field, enter a description of the policy group.
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).
Click Update.

Step 7

Click Next to advance to Associations.

(Optional) In the Associations menu, you can associate the leaf profile with leaf interface profiles and access module profiles.

Step 8

Click Finish.

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

Step 9

To view the BFD global configuration you created, in the Navigation pane, expand Policies > Switch > 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 Policies > Switch > 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 Switches > Spine Switches > Profiles.

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

Step 4

On the right side of the Work pane, under the acttions icon, 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.)
(Optional) In the Spine Selectors toolbar, click +
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

(If configuring a spine selector) In the Create Spine Switch Policy Group dialog box, perform the following actions:

In the Name field, enter a name for the policy group.
(Optional) In the Description field, enter a description of the policy group.
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).
Click Update.

Step 7

Click Next to advance to Associations.

(Optional) In the Associations menu, you can associate the spine profile with spine interface profiles.

Step 8

Click Finish.

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

Step 9

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

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 > L3Outs.

Step 3

Right-click on L3Outs and select Create L3Out.

The Create L3Out wizard appears.

Step 4

Enter the necessary information in the Identity window of the Create L3Out wizard.

Enter the necessary information in the Name, VRF and L3 Domain fields.
In the area with the routing protocol check boxes, choose BGP.
Click Next to move to the Nodes and Interfaces window.

Step 5

Enter the necessary information in the Nodes and Interfaces window of the Create L3Out wizard.

In the Layer 3 area, select Routed.
From the Node ID field drop-down menu, choose the node for the L3Out.

For the topology in these examples, use node 103.
In the Router ID field, enter the router ID.
(Optional) You can configure another IP address for a loopback address, if necessary.

The Loopback Address field is automatically populated with the same entry that you provide in the Router ID field. This is the equivalent of the Use Router ID for Loopback Address option in previous builds. Enter a different IP address for a loopback address, if you don't want to use route ID for the loopback address, or leave this field empty if you do not want to use the router ID for the loopback address.
Enter necessary additional information in the Nodes and Interfaces window.

The fields shown in this window varies, depending on the options that you select in the Layer 3 and Layer 2 areas.
When you have entered the remaining additional information in the Nodes and Interfaces window, click Next.

The Protocols window appears.

Step 6

Enter the necessary information in the Protocols window of the Create L3Out wizard.

In the BGP Loopback Policies and BGP Interface Policies areas, enter the following information:

Peer Address: Enter the peer IP address
EBGP Multihop TTL: Enter the connection time to live (TTL). The range is from 1 to 255 hops; if zero, no TTL is specified. The default is zero.

Remote ASN: Enter a number that uniquely identifies the neighbor autonomous system. The Autonomous System Number can be in 4-byte as plain format from 1 to 4294967295.

Note

ACI does not support asdot or asdot+ format AS numbers.

In the OSPF area, choose the default OSPF policy, a previously created OSPF policy, or Create OSPF Interface Policy.
Click Next.

The External EPG window appears.

Step 7

Enter the necessary information in the External EPG window of the Create L3Out wizard.

In the Name field, enter a name for the external network.
In the Provided Contract field, enter the name of a provided contract.
In the Consumed Contract field, enter the name of a consumed contract.
In the Default EPG for all external networks field, uncheck if you don’t want to advertise all the transit routes out of this L3Out connection.

The Subnets area appears if you uncheck this box. Specify the desired subnets and controls as described in the following steps.
Click Finish to complete the necessary configurations in the Create L3Out wizard.

Step 8

Navigate to Tenants > tenant_name > Networking > L3Outs > L3Out_name > Logical Node Profiles > logical_node_profile_name > Logical Interface Profiles > logical_interface_profile_name

Step 9

In the Logical Interface Profile window, scroll down to the Create BFD Interface Profile field, then check the box next to this field.

Step 10

In the Create BFD Interface Profile window, 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.
In 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 11

Click SUBMIT.

Step 12

To see the configured interface level BFD policy, navigate to Policies > Protocol > BFD.

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 > Policies > Protocol.

Before you begin

A tenant has already been created.

Procedure

Step 1

Create an L3Out using the Create L3Out wizard.

Step 2

On the menu bar, choose Tenant.

Step 3

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

Step 4

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 5

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

Step 6

Click Submit.

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

Step 7

Navigate to Tenants > tenant_name > Networking > L3Outs > L3Out_name > Logical Node Profiles > logical_node_profile_name > Logical Interface Profiles > logical_interface_profile_name > BGP Peer Connectivity Profile.

Step 8

In the BGP Peer Connectivity Profile window, scroll down to the BGP Peer Prefix Policy field and select the BGP peer prefix policy that you just created.

Step 9

In the Peer Controls field, select Bidirectional Forwarding Detection to enable BFD on the BGP consumer protocol (or uncheck the box to disable BFD).

Step 10

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

Step 11

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 12

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

Step 13

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 14

Click Submit.

Step 15

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

Step 16

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 17

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

Step 18

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 19

Click Submit.

Step 20

To configure BFD in the Static Routes protocol, in the Navigation pane, go back to Networking > L3Outs > L3Out_name > Configured Nodes, then click on the configured node to bring up the Node Association window.

Step 21

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 22

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 23

Click Submit.

Step 24

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

Step 25

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 26

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

Step 27

To enable BFD ISIS Policy, in the BFD ISIS Policy Configuration field, click enabled.

Step 28

Click Submit.

BFD Multihop

BFD multihop provides subsecond forwarding failure detection for a destination with more than one hop and up to 255 hops. Beginning with Release 5.0(1), APIC supports BFD multihop for IPv4 and BFD multihop for IPv6 in compliance with RFC5883. BFD multihop sessions are set up between a unique source and destination address pair. A BFD multihop session is created between a source and destination rather than with an interface, as with single-hop BFD sessions.

BFD multihop sets the TTL field to the maximum limit supported by BGP, and does not check the value on reception. The ACI leaf has no impact on the number of hops a BFD multihop packet can traverse, but the number of hops is limited to 255.

Guidelines and Limitations for BFD Multihop

The default and minimum transmit and receive interval timers for BFD multihop are 250 ms.
The default and minimum detection multiplier is 3.
Echo mode is not supported for BFD multihop.

Configuring a BFD Multihop Policy

You can configure a BFD multihop policy in several locations in the GUI, depending on the purpose of the policy.

Global Policies: By default, the APIC controller creates default policies when the system comes up. These default policies are global BFD multihop configuration policies. You can set attributes within the default global policy in the Work pane, or you can modify these default policy values. However, once you modify a default global policy, 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 isn't the default, create a switch profile and modify the BFD multihop values in the switch profile.

You can create or modify global BFD multihop configuration policies for IPv4 or IPv6 in these GUI locations:
- Fabric > Access Policies > Policies > Switch > BFD Multihop > BFD Multihop IPv4: right-click and select Create BFD Global IPv4 MH Policy.
- Fabric > Access Policies > Policies > Switch > BFD Multihop > BFD Multihop IPv6: right-click and select Create BFD Global IPv6 MH Policy.
Node Policies: A BFD Multihop node policy applies to interfaces under a node profile.

You can create or modify BFD multihop node policies in this GUI location:
- Tenants > tenant > Policies > Protocol > BFD Multihop > Node Policies: right-click and select Create BFD Multihop Node Policy.
Inteface Policies: A BFD Multihop interface policy applies to interfaces under an interface profile.

You can create or modify BFD multihop interface policies in this GUI location:
- Tenants > tenant > Policies > Protocol > BFD Multihop > Interface Policies: right-click and select Create BFD Multihop Interface Policy.
Overriding Global Policies: If you don't want to use the default global configuration, but you want to have an explicit configuration on a given interface, you can create your own global configuration. This configuration is then applied to all the interfaces on a specific switch or set of switches. You can use this interface override configuration when you want more granularity on a specific switch on a specific interface.

You can create or modify BFD multihop override policies for a node profile or interface profile in these GUI locations:
- Tenants > tenant > Networking > L3Outs > l3out > Logical Node Profiles > logical_node_profile: right-click, select Create BFD Interface Protocol Profile, specify BFD Multihop node policy.
- Tenants > tenant > Networking > L3Outs > l3out > Logical Node Profiles > logical_node_profile > Logical Interface Profiles > logical_interface_profile: right-click, select Create MH-BFD Interface Protocol Profile, specify BFD Multihop interface policy.
- Tenants > infra > Networking > SR-MPLS Infra L3Outs > l3out > Logical Node Profiles > logical_node_profile > Logical Interface Profiles > logical_interface_profile: right-click, select Create MH-BFD Interface Profile, specify BFD Multihop interface policy.

Procedure

Step 1	Navigate to the GUI location where you will create or configure the BFD multihop policy.
Step 2	Edit an existing profile or policy or launch the dialog box to create a new profile.
Step 3	In the profile, choose an Authentication Type for BFD multihop sessions. You can choose to require no authentication or SHA-1 authentication.
Step 4	If you are creating a new policy, configure the settings in the dialog box: Enter a Name for the policy. Set the Admin State to Enabled. Set the Detection Multiplier value. Specifies the minimum number of consecutive packets that can be missed before BFD declares a session to be down. The range is from 1 to 50 packets. The default is 3. Set the Minimum Transmit Interval value. The minimum interval time for packets being transmitted. The range is from 250 to 999 milliseconds. The default is 250. Set the Maximum Receive Interval value. The maximum interval time for packets being received. The range is from 250 to 999 milliseconds. The default is 250. Click Submit.

Micro BFD

Beginning with Cisco APIC Release 5.2(3), APIC supports Micro BFD, as defined in IETF RFC 7130. When Bidirectional Forwarding Detection (BFD) is configured on a port channel, keep-alive packets are sent on any available member link. The failure of a single member link might not be detected, because the keep-alive packets can merely traverse a remaining link. Micro BFD is an enhancement to BFD that establishes individual BFD sessions on each member link of a port channel, as shown in the following figure.

When a per-link BFD session senses a failure on its member link, the failed link is removed from the forwarding table. This mechanism delivers faster failure detection and assists in identifying which link has failed on the port channel.

Guidelines and Limitations for Micro BFD

Micro BFD can run simultaneously with multi-hop BFD on the same port channel, but not with single-hop BFD.
Micro BFD is a single-hop BFD implementation. It does not function if a Layer 2 switch exists between the main port channel on a switch and the switch's peer.
Micro BFD is not supported on first-generation leaf switches. First-generation switches are those that do not contain a suffix, such as -EX or -FX, in the PID (product identifier).
Micro BFD is supported only on the routed interface over a port channel.
Client protocols can run on a sub-interface on the same port-channel where Micro BFD is enabled.
Micro BFD is not supported on FEX ports or fabric ports.
BFD Echo is not supported on Micro BFD sessions.
On a dual IP stack port channel (IPv4 and IPv6) with Micro BFD enabled, you must configure Micro BFD with either an IPv4 address or an IPv6 address but not both. You cannot have both IPv4 and IPv6 Micro BFD sessions.
Beginning with Cisco APIC Release 5.2(3), Cisco APIC allows using L3 port channel main interface along with sub-interfaces on the same L3 port channel. But creating or deleting L3 port channel main interface will flap port channel physical member ports. This will cause traffic loss if the port channel sub-interfaces are already active.

Configuring Micro BFD on a Port Channel

This procedure modifies an L3Out port channel interface to enable Micro BFD. Micro BFD establishes individual BFD sessions on each member link of a port channel.

Before you begin

A direct port channel is configured for an L3Out interface.

Procedure

Step 1	Navigate to Tenants > `tenant_name` > Networking > L3Outs > `L3Out_name` > Logical Node Profiles > `logical_node_profile_name` > Logical Interface Profiles
Step 2	Select the Logical Interface Profile that you want to modify.
Step 3	Select the Routed Interfaces tab. Micro BFD is supported only on the routed interface over a port channel.
Step 4	In the Routed Interfaces section, double click the existing interface to modify it, or click the + icon to add a new interface to the Logical Interface Profile. The remaining steps of this procedure describe only the enabling of Micro BFD on an existing logical interface. If you are adding a new interface to the Logical Interface Profile, refer to Modifying Interfaces for L3Out Using the GUI.
Step 5	In the configured properties of the selected interface, verify that the selected Path Type is Direct Port Channel. Micro BFD is applicable only on a port channel.
Step 6	Check the checkbox for Enable Micro BFD.
Step 7	Type the destination IP address of the port channel in Micro BFD Destination Address.
Step 8	Enter a value between 60 to 3600 seconds in Micro BFD Start Timer (sec). The start timer delays activation of BFD monitoring on member links in order to allow BFD sessions to establish. The timer is optional. If the timer is not configured, activation is not delayed.
Step 9	Click Submit.

What to do next

You can verify the Micro BFD sessions using the CLI, as shown in the following example:


leaf4# show port-channel database interface port-channel 3
port-channel3
Last membership update is successful
4 ports in total, 4 ports up
First operational port is Ethernet1/44
Age of the port-channel is 0d:22h:46m:03s
Time since last bundle is 0d:22h:42m:43s
Last bundled member is Ethernet1/44
Ports: Ethernet1/41 [on] [up]
Ethernet1/42 [on] [up]
Ethernet1/43 [on] [up]
Ethernet1/44 [on] [up] *

leaf4# show bfd neighbors vrf tenant1:vrf1

OurAddr NeighAddr
LD/RD RH/RS Holdown(mult) State Int Vrf Type

2003:190:190:1::1 2003:190:190:1::2
1090519041/0 Up 6000(3) Up Po3 tenant1:vrf1 singlehop

2003:190:190:1::1 2003:190:190:1::2
1090519042/2148074790 Up 180(3) Up Eth1/44 tenant1:vrf1 singlehop

2003:190:190:1::1 2003:190:190:1::2
1090519043/2148074787 Up 180(3) Up Eth1/41 tenant1:vrf1 singlehop

2003:190:190:1::1 2003:190:190:1::2
1090519044/2148074789 Up 180(3) Up Eth1/43 tenant1:vrf1 singlehop

2003:190:190:1::1 2003:190:190:1::2
1090519045/2148074788 Up 180(3) Up Eth1/42 tenant1:vrf1 singlehop

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

BGP Protocol Peering to External BGP Speakers

Configuring BGP External Routed Networks

Configuring BGP L3Out Using the GUI

Before you begin

Procedure

Configuring BGP Max Path

Configuring BGP Max Path Using the GUI

Before you begin

Procedure

Configuring AS Path Prepend

Configuring AS Path Prepend

Configuring AS Path Prepend Using the GUI

Before you begin

Procedure

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

BGP Neighbor Shutdown and Soft Reset

About BGP Neighbor Shutdown and Soft Reset

BGP Neighbor Shutdown

BGP Neighbor Soft Reset

Configuring BGP Neighbor Shutdown Using the GUI

Before you begin

Procedure

Configuring BGP Neighbor Soft Reset Using the GUI

Before you begin

Procedure

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

Troubleshooting Inconsistency and Faults

Configuring BFD Support

Bidirectional Forwarding Detection

Optimizing BFD on Subinterfaces

Configuring Bidirectional Forwarding Detection on a Secondary IP Address Using the GUI

Procedure

Configuring BFD Globally on Leaf Switch Using the GUI

Procedure

Configuring BFD Globally on Spine Switch Using the GUI

Procedure

Configuring BFD Interface Override Using the GUI

Before you begin

Procedure

Configuring BFD Consumer Protocols Using the GUI

Before you begin

Procedure

BFD Multihop

Guidelines and Limitations for BFD Multihop

Configuring a BFD Multihop Policy

Procedure

Micro BFD

Guidelines and Limitations for Micro BFD

Configuring Micro BFD on a Port Channel

Before you begin

Procedure

What to do next

OSPF External Routed Networks

OSPF Layer 3 Outside Connections

Creating an OSPF L3Out for Management Tenant Using the GUI

Procedure

EIGRP External Routed Networks

About EIGRP Layer 3 Outside Connections

EIGRP Protocol Support

Supported Features

Unsupported Features

Categories of EIGRP Functions

Primary Managed Objects That Support EIGRP