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

PDF

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

BGP external routed networks with BFD support

Updated: April 17, 2026

Want to summarize with AI?

Log in

Bidirectional Forwarding Detection improves path-failure detection for external BGP peers.

Use this reference to understand Bidirectional Forwarding Detection (BFD) support for Border Gateway Protocol (BGP) external routed networks.

Guidelines for configuring a BGP Layer 3 outside connection

A Border Gateway Protocol (BGP) Layer 3 Outside (L3Out) connection enables routing communication between the Cisco ACI fabric and external devices.

  • Requires router ID and loopback address management to prevent conflicts with L3Out interface subnets.

  • Supports BGP peers configured under logical node profiles or logical interface profiles.

  • Uses prefix limits and timer settings to maintain network stability and performance.

BGP configuration guidelines and limitations

Follow these guidelines when you configure a BGP external routed network:

  • Direct route export: Cisco ACI does not evaluate the originating route type when matching export route map clauses. Explicitly advertise direct routes through the route map. Otherwise, Cisco ACI implicitly denies the routes.

  • AS override: Use AS override for transit routing between eBGP L3Outs that use the same autonomous system (AS) number. If you enable AS override when the eBGP neighbor uses a different AS number, strip the peer AS from the AS_PATH attribute.

  • Local AS number: Local AS numbers are supported only for eBGP peering. A local AS number enables a border leaf switch to appear as a member of an additional AS. Control AS-path prepending by using the no-prepend or no-prepend + replace-as setting.

  • Router ID restrictions: The router ID cannot use the same IP address or subnet as an L3Out routed interface, subinterface, or switched virtual interface (SVI). Beginning with Cisco APIC Release 6.0(4), this restriction does not apply when the Use Router ID for Loopback Address option is disabled.

  • Multiple L3Outs: If multiple L3Outs that use the same routing protocol are configured on the same leaf switch and in the same VRF, the L3Outs must use the same router ID.

  • BGP peer definition: Configure a BGP peer under a logical node profile to associate the peer with a loopback IP address. Configure the peer under a logical interface profile to associate it with an interface or subinterface.

  • Timers: Use the default BGP timers and Bidirectional Forwarding Detection (BFD) for subsecond failure detection. This configuration helps prevent session flapping during CPU-intensive operations.

  • IPv6 peering: Configure an IPv6 address to enable BGP peering over a loopback interface.

  • Prefix limits: Use tenant networking protocol policies to monitor and limit route prefixes. The default limit is 20,000 prefixes.

  • ECMP support: Equal-cost multipath (ECMP) routing is not supported when an L3Out is stretched across parent and tier-2 leaf switches.

  • Dynamic BGP peering: Overlapping prefixes are not supported. Use the same prefix mask for dynamic peer configurations within the same address range.

Dynamic BGP peering prefix example

When you configure dynamic BGP peering, you cannot use overlapping prefixes that have different masks. For example, 10.10.0.0/16 and 10.10.10.0/24 are not valid because their address ranges overlap and their prefix masks differ.

BGP connection types and loopback guidelines

Use this reference to determine the loopback and routing requirements for each Border Gateway Protocol (BGP) connection type supported by ACI.

BGP connection type

Loopback required

Loopback same as router ID

Static or OSPF route required

Direct iBGP peering

No

Not applicable

No

iBGP loopback peering

Yes, a separate loopback interface for each L3Out

No, when multiple L3Outs are configured on the same node

Yes

Direct eBGP peering

No

Not applicable

No

eBGP loopback peering (multihop)

Yes, a separate loopback interface for each L3Out

No, when multiple L3Outs are configured on the same node

Yes

BGP peering with external BGP speakers

Border Gateway Protocol (BGP) peering enables border leaf switches to exchange routing information with external BGP speakers by using internal BGP (iBGP) or external BGP (eBGP).

  • Supports iBGP and eBGP peering through OSPF, direct connections, or static routes.

  • Uses the BGP Peer Connectivity Profile to configure supported BGP features.

  • Applies route control at the BGP protocol level when OSPF provides reachability to the BGP peer addresses.

BGP peer connectivity profile features

Cisco ACI supports iBGP and eBGP connections to external peers. Configure the supported BGP features in the BGP Peer Connectivity Profile.

Note

When you use OSPF with BGP peering, OSPF learns and advertises only the routes that provide reachability to the BGP peer addresses. Cisco ACI applies route control configured for the Layer 3 Outside network EPG at the BGP protocol level.

The following table describes the BGP Peer Connectivity Profile features:

Note

Cisco ACI supports only the BGP features listed in the following table. Cisco NX-OS BGP features that are not listed are not supported in Cisco ACI.

Table 1. BGP Peer Connectivity Profile features

BGP feature

Description

Cisco NX-OS equivalent command

Allow Self-AS

Works with the Allowed AS Number Count setting.

allowas-in

Disable peer AS check

Disables the peer AS number check when advertising routes.

disable-peer-as-check

Next-hop self

Sets the next-hop attribute to the local peering address.

next-hop-self

Send community

Sends the standard community attribute to the neighbor.

send-community

Send community extended

Sends the extended community attribute to the neighbor.

send-community extended

Password

Configures BGP MD5 authentication.

password

Allowed AS Number Count

Specifies the number of occurrences of the local AS number that are permitted in the AS path. This setting works with Allow Self-AS.

allowas-in

Disable connected check

Disables the connected-route check for directly connected eBGP neighbors, which permits eBGP peering between loopback interfaces.

TTL

Sets the time-to-live (TTL) value for eBGP multihop connections. This setting is valid only for eBGP.

ebgp-multihop <TTL>

Autonomous System Number

Specifies the autonomous system number of the remote peer.

neighbor <x.x.x.x> remote-as

Local Autonomous System Number Configuration

Specifies options for the local AS feature, including no-prepend, replace-as, and dual-as.

Local Autonomous System Number

Advertises a different AS number from the AS number assigned to the fabric MP-BGP Route Reflector Profile. This feature is supported only for eBGP neighbors. The local AS number must differ from the AS number in the route reflector policy.

local-as xxx <no-prepend> <replace-as> <dual-as>

Site of Origin

The site of origin (SoO) is a BGP extended community attribute that identifies the site from which a route was learned and prevents routing loops.

soo <value>

TCP-AO for BGP

TCP Authentication Option (TCP-AO) is a TCP authentication mechanism that provides cryptographic authentication for TCP segments. In Cisco ACI, TCP-AO is supported for BGP sessions.

TCP-AO improves BGP authentication by supporting:

  • stronger cryptographic algorithms

  • multiple active keys in a keychain

  • send and receive key identifiers

  • coordinated key rollover

  • authentication of TCP segments without using TCP-MD5

TCP-AO uses a Message Authentication Code (MAC) to authenticate TCP segments. In Cisco ACI, the default MAC length is 12 bytes, or 96 bits.

TCP-AO uses the following TCP-AO fields during authentication:

Table 2. TCP-AO fields
Field Description
KeyID Identifies the key that the sender uses to authenticate the TCP segment.
RNextKeyID Indicates the next receive key that the sender expects the peer to use. TCP-AO uses this field to coordinate key changes between peers.
Message Authentication Code, or MAC Authenticates the TCP segment. Cisco ACI uses a default MAC length of 12 bytes.

TCP-AO helps support secure and planned key changes by allowing multiple keys to exist in a keychain. When you configure key lifetimes with an overlap, the BGP session can continue to operate while the peers transition from one key to another.

You cannot configure TCP-AO and BGP password authentication on the same BGP peer. If a BGP peer already uses password authentication, remove the password authentication before you associate a TCP-AO keychain with that peer.

TCP-AO and TCP-MD5 comparison

This table compares TCP-MD5 and TCP-AO for BGP authentication.

Table 3. TCP-AO and TCP-MD5 comparison
Attribute TCP-MD5 TCP-AO
Authentication method Uses an MD5 digest. Uses a MAC calculated with a supported cryptographic algorithm.
Algorithm support Supports MD5 only. Supports AES-128-CMAC, HMAC-SHA-1, HMAC-SHA-256, and HMAC-SHA-256-128.
Key rollover Requires a BGP session reset when the password changes. Supports coordinated key rollover when key lifetimes overlap.
Key management Uses a single password. Uses a TCP keychain with one or more keys.
Key identifier support Does not support key identifiers. Supports send and receive key identifiers.

TCP-AO-keychains

TCP-AO uses keychains instead of a single BGP password. A TCP-AO keychain is a tenant-level policy that contains one or more TCP-AO keys. You associate the keychain with a BGP peer to enable TCP-AO authentication for that peer.

Each key defines the authentication parameters that BGP uses to authenticate TCP segments for a specific time period during which the key is valid.

Cisco ACI supports up to 256 keys in a TCP keychain.

A TCP-AO keychain includes one or more keys. Each key includes these parameters.

Table 4. TCP-AO keychain components
Parameter Description
Key ID Identifies the key within the keychain. Use a unique key ID for each key in the keychain.
Key string Defines the shared secret that TCP-AO uses to generate the MAC. Configure the same key string on both BGP peers.
Send ID Identifies the key that the local peer uses when sending authenticated TCP segments. The supported range is 0 to 255.
Receive ID Identifies the key that the local peer expects to receive from the remote peer. The supported range is 0 to 255.
Cryptographic algorithm Specifies the algorithm that TCP-AO uses to generate the MAC.
Include TCP options Determines if TCP option headers (other than the TCP-AO option itself) are factored into the segment's MAC calculation. Enabling this ensures that modifications to the TCP options header will invalidate the MAC.
Start time Specifies the time when the key becomes valid.
End time Specifies the time when the key expires. You can configure a key to remain valid indefinitely.

Supported cryptographic algorithms

Cisco ACI supports the following TCP-AO cryptographic algorithms for BGP:

  • AES-128-CMAC

  • HMAC-SHA-1

  • HMAC-SHA-256

  • HMAC-SHA-256-128

Use a SHA-256-based algorithm for stronger authentication unless your deployment requires another supported algorithm for interoperability with the remote peer.

TCP-AO key rollover

TCP-AO key rollover allows BGP peers to transition from one TCP-AO key to another without resetting the BGP session. Key rollover is useful when you need to rotate keys periodically for operational or security requirements.

TCP-AO uses the KeyID and RNextKeyID fields to coordinate key changes between peers. The sender uses the KeyID field to identify the key used to authenticate the TCP segment. The sender uses the RNextKeyID field to indicate the next receive key that it expects the peer to use.

For a hitless key rollover, the old key and the new key must overlap for at least 15 minutes. During this overlap period, both keys are valid, which allows both peers to transition to the new key without interrupting the BGP session.

If the old key expires before the new key becomes valid, or if the peers do not have matching key information, the BGP session can reset.

Key rollover guidelines

When you configure TCP-AO key rollover, follow these guidelines:

  • Configure the new key before the current key expires.

  • Configure at least 15 minutes of overlap between the old key and the new key.

  • Ensure that both BGP peers have matching key configuration.

  • Ensure that the Send ID on one peer matches the Receive ID expected by the other peer.

  • Ensure that the Receive ID on one peer matches the Send ID used by the other peer.

  • Do not allow all keys in a key chain to expire.

Key rollover example

The following example shows a planned key rollover with a 15-minute overlap.

Table 5. Key rollover example
Key Start time End time Purpose
Key 1 10:00 10:30 Existing active key
Key 2 10:15 Infinite New key

In this example, Key 1 and Key 2 overlap from 10:15 to 10:30. This 15-minute overlap allows the peers to transition from Key 1 to Key 2 without resetting the BGP session.

Supported BGP peer types for TCP-AO

Use this topic to identify which BGP peer types support TCP-AO authentication.

TCP-AO support is consistent with existing BGP password support where applicable. Some BGP peer types do not support TCP-AO in Cisco ACI Release 6.2(3).

Table 6. Supported peer matrix
BGP peer type Configuration support from APIC GUI BGP password support TCP-AO support
User VRF L3Out Yes Yes Yes
Intra-Pod MP-BGP sessions No No No
MPOD overlay sessions Yes, during initial pod setup Yes Not supported in 6.2(3)
BGP underlay, spine to IPN and remote leaf to IPN Yes Yes Yes
MSITE underlay Yes Yes Not supported in 6.2(3)
Multi-Site overlay Yes Yes Not supported in 6.2(3)
ACI BGW underlay and overlay towards NX-OS BGW Yes Yes Yes
ACI BGW towards spines No No No
SR-MPLS underlay BGP-LU Yes Yes Yes
SR-MPLS overlay Yes Yes Yes
ARL No No No
Floating L3Out BGP sessions towards the CN Yes Yes Yes

Guidelines and limitations for TCP-AO

TCP-AO uses a TCP keychain and requires matching configuration on both BGP peers. A mismatch in keychain parameters can prevent the BGP session from coming up or can cause the session to reset.

Configuration guidelines

Follow these guidelines and limitations when you configure TCP-AO in Cisco ACI:

  • Configure the TCP keychain and keys on both BGP peers.

  • Configure the same key string on both BGP peers.

  • Configure the same cryptographic algorithm on both BGP peers.

  • Configure the same include TCP options setting on both BGP peers.

  • Configure matching key lifetimes on both BGP peers where possible.

  • Configure the send ID on one peer to match the receive ID on the other peer.

  • Configure at least 15 minutes of overlap between the old key and the new key for key rollover.

  • Configure TCP-AO keychains in the same tenant as the BGP peer or in the common tenant.

  • Use TCP-AO only with BGP. TCP keychains cannot be used by classic keychain or MACsec keychain clients.

Keychain guidelines

Follow these guidelines when configuring TCP-AO keychains:

  • A TCP keychain supports 256 keys.

    The Send ID and Receive ID range is 0 to 255.

  • The Send ID and Receive ID must be unique for each key in a keychain.

  • The Key string, Send ID, Receive ID, Send lifetime, and Cryptographic algorithm are required for a key to become active.

  • The include TCP options setting is optional.

  • Type-7 keychain encryption is supported.

  • Type-6 keychain encryption is not supported.

  • The same keychain name cannot be used for TCP keychains, classic keychains, and MACsec keychains.

BGP guidelines

Follow these guidelines when configuring TCP-AO on BGP peers:

  • TCP-AO and BGP password authentication cannot be configured on the same BGP peer.

  • Changing the TCP-AO keychain name on an established BGP session causes the session to reset.

  • Modifying the Key string, Send ID, Receive ID, or cryptographic algorithm of the key that is currently used by a TCP-AO session causes the BGP session to reset.

  • If an incoming packet is authenticated with a key that is not active or installed, segment loss can occur and the BGP session can reset.

  • If the key currently used for transmission expires before rollover completes, the BGP session can reset.

  • A TCP-AO keychain configured in the common tenant can be used by BGP sessions in other tenants.

Mixed mode Compatibilty

APIC raises a fault when it attempts to push a TCP-AO policy to a node that does not support TCP-AO. Before you downgrade Cisco APIC to a release earlier than 6.2(3), remove all TCP-AO configurations.

For more information refer to Mixed mode compatibility for TCP-AO from Cisco APIC release 62x or later

Configure a TCP-AO keychain using the GUI

Use this task to create a TCP-AO keychain policy that can be associated with a BGP peer.

A TCP-AO keychain contains one or more keys. Each key has a send lifetime. To support key rollover, configure at least two keys with overlapping send lifetimes.

You can create the TCP-AO keychain under a user tenant, the infra tenant, or the common tenant. A TCP-AO keychain configured under the common tenant can be used by BGP peers in other tenants.

Before you begin

Ensure the following:

  • The tenant is configured.

  • For user VRF L3Out BGP peers, the L3Out and BGP peer are configured.

  • For BGP infra peers, the infra tenant BGP underlay configuration is configured.

  • Determine the key string, cryptographic algorithm, send ID, receive ID, and send lifetime for each key.

  • If you are configuring key rollover, determine the overlap between the current key and the next key. The overlap must be at least 15 minutes.

Follow these steps to configure a TCP-AO keychain using the GUI.

Procedure

  1. On the menu bar, choose Tenants > tenant_name.

    For a keychain that is shared across tenants, choose Tenants > common.

    For BGP infra peers, choose Tenants > infra.

  2. In the Navigation pane, choose Policies> Protocol > TCP Keychains.

  3. Right-click TCP Keychains and choose Create TCP Keychain Policy.

  4. In the Name field, enter a name for the TCP-AO keychain policy.

  5. In the key configuration area, click + to add a key.

    Configure the following key parameters.

    Table 7. Key parameters
    Field Action
    Key ID Enter the key ID

    The supported range is 0 to 65535.

    Maximum number of keys supported per keychain is 256.
    Send ID Enter the send ID

    The supported range is 0 to 255.
    Receive ID Enter the receive ID

    The supported range is 0 to 255.
    Key String Enter the key string.

    Configure the same key string on both BGP peers.
    Cryptographic Algorithm Choose one of these algorithms

    • AES-128-CMAC

    • HMAC-SHA-1

    • HMAC-SHA-256

    • HMAC-SHA-256-128
    Start Time Specify the time when the key becomes active
    End Time Specify the time when the key expires, or choose an infinite lifetime if applicable
    Include TCP Options Enable or disable this setting based on the peer configuration. Configure the same setting on both peers.

    (optional) Enable only if TCP options must be included in the MAC calculation.

  6. Click Update.

  7. Optional: Add another key for key rollover.

    Ensure that the new key start time overlaps with the current key end time by at least 15 minutes.

  8. Click Submit.

The TCP-AO keychain policy is created. You can associate this policy with a supported BGP peer.

Associate a TCP-AO keychain with a BGP peer using the GUI

Use this task to enable TCP-AO authentication for a BGP peer by associating a TCP-AO keychain with the BGP peer.

TCP-AO is configured on the BGP peer. The TCP-AO keychain policy must exist in the same tenant or in the common tenant.

TCP-AO and BGP password authentication are mutually exclusive. Remove the BGP password before associating a TCP-AO keychain with the BGP peer.

Before you begin

Ensure the following:

  • The tenant, VRF, and L3Out are configured.

  • The BGP peer is configured.

  • The TCP-AO keychain policy is configured in the same tenant or in the common tenant.

  • TCP-MD5 password authentication is not configured on the same BGP peer.

  • The peer router has a matching TCP-AO configuration.

Follow these steps to associate a TCP-AO keychain with a BGP peer.

Procedure

  1. On the menu bar, choose Tenants > tenant_name.

  2. In the Navigation pane, choose Networking > L3Outs > L3Out_name.

  3. Expand Logical Node Profiles > logical_node_profile_name.

  4. Navigate to the BGP peer

    Depending on how the BGP peer is configured, use one of these paths:

    • Logical Node Profiles > logical_node_profile_name> BGP Peer.

    • Logical Interface Profiles > logical_interface_profile_name > BGP Peer Connectivity Profile.

  5. Click BGP peer that you want to configure.

  6. Verify that the Password field is not configured.

    TCP-AO and BGP password authentication cannot be configured on the same BGP peer.

  7. In the TCP-AO keychain field, choose the TCP-AO keychain policy.

    This setting must match the peer router configuration.

  8. Configure the Include TCP Options setting if required.

  9. Click Submit.

APIC associates the TCP-AO keychain with the BGP peer. BGP uses the active key in the keychain to authenticate TCP segments for the BGP session.

Associate a TCP-AO keychain with a BGP infra peer using the GUI

Use this task to enable TCP-AO authentication for supported BGP infra peers, such as BGP underlay peers between spines and the IPN or between remote leaf switches and the IPN.

Cisco ACI supports TCP-AO for BGP underlay peer types that support BGP password authentication. The configuration flow for infra peers is described as the same TCP keychain creation process, followed by associating the policy under the BGP infra peer profile.

Before you begin

Ensure the following:

  • The infra tenant BGP underlay configuration is configured.

  • The TCP-AO keychain policy is configured in the infra tenant or in the common tenant.

  • TCP-MD5 password authentication is not configured on the same BGP infra peer.

  • The peer router has a matching TCP-AO configuration.

Follow these steps to associate a TCP-AO keychain with a BGP infra peer.

Procedure

  1. On the menu bar, choose Tenants > infra.

  2. In the Navigation pane, choose Networking > L3Outs > L3Out_name.

  3. Navigate to the BGP infra peer profile.

  4. Click BGP infra peer that you want to configure.

  5. Verify that BGP password authentication is not configured for the peer.

  6. In the TCP-AO keychain field, choose the TCP-AO keychain policy.

  7. Configure the Include TCP Options setting if required.

  8. Click Submit.

APIC associates the TCP-AO keychain with the BGP infra peer.

Verify TCP-AO for BGP

Use this topic to verify whether TCP-AO is enabled for a BGP peer and whether the expected keys are active

Verify the BGP neighbor TCP-AO state

Use the show bgp ipv4 unicast neighbors peer-ip vrf vrf-name command to verify that TCP-AO authentication is configured for a BGP peer.

Example:

show bgp ipv4 unicast neighbors 192.0.2.2 vrf t1:ctx1
Look for output similar to this:
TCP AO authentication is set: t1:kc1
Active TCPAO Keys:
Sndid: 1 Rcvid: 2 InListenFD InPeerFD RNext Curr

Verify internal TCP-AO key information

Use the show bgp internal neighbor peer-ip vrf vrf-name command to verify TCP-AO keys installed for the peer and listening sockets.

show bgp internal neighbor 192.0.2.2 vrf t1:ctx1
Look for fields such as:
•	Total TCPAO keys for Peer
•	Sndid
•	Rcvid
•	alg_name
•	currentKey
•	nextKey
•	excl-tcp-options
•	Total TCPAO keys for Listening Socket

Verify all internal TCP-AO keys

Use the show bgp internal tcpao command from vsh to display internal TCP-AO key information.

vsh -c "show bgp internal tcpao"
Look for fields such as:
•	Peer
•	VRF
•	Sndid
•	Rcvid
•	alg_name
•	incl-tcp-options

Verify the TCP keychain

Use the show key chain command to verify TCP keychain status.

BGP additional paths

BGP additional paths is a routing feature that enables a BGP speaker to advertise or receive multiple paths for the same prefix without replacing the existing path.

  • Enables BGP peers to negotiate whether they can advertise or receive multiple paths for each prefix.

  • Adds a 4-byte path identifier to the Network Layer Reachability Information (NLRI) to distinguish multiple paths for the same prefix.

BGP additional paths capabilities and limitations

The following limitations apply to BGP additional paths:

  • Cisco APIC supports only the receive capability.

  • If the BGP session is already established, changes to the receive configuration take effect only after the session is reset.

The following figure shows the BGP additional paths receive capability:

Figure 1. BGP route advertisement with the additional paths capability

BGP path advertisement behavior

Before support for the additional paths receive capability, BGP advertised only the best path, and a BGP speaker accepted only one path for a prefix from each peer. If the speaker received multiple paths for the same prefix during the same session, the most recent advertisement replaced the previous path.

BGP external routed network configuration

Use the procedures in this reference to configure BGP external routed networks.

Configure a BGP L3Out by using the GUI

Before you begin

Create the tenant, VRF, and bridge domain for the BGP L3Out. When you create the VRF, check the Configure BGP Policies check box.

Procedure

  1. From the menu bar, choose Tenants > All Tenants.

  2. In the work pane, double-click the tenant name.

  3. In the navigation pane, expand Tenant_name > Networking > L3Outs.

  4. Right-click L3Outs and choose Create L3Out.

    The Create L3Out wizard appears.

  5. On the Identity page of the Create L3Out wizard, configure the L3Out identity:

    1. Complete the Name, VRF, and L3 Domain fields.
    2. In the routing protocol area, check the BGP check box.
    3. Click Next.

      The Nodes and Interfaces page appears.

  6. On the Nodes and Interfaces page of the Create L3Out wizard, configure the nodes and interfaces:

    1. In the Layer 3 area, choose Routed.
    2. From the Node ID drop-down list, choose the node for the L3Out.

      For the topology used in these examples, choose node 103.

    3. In the Router ID field, enter the router ID.
    4. Optional: Configure a different loopback address or disable the loopback address, if required.

      The Loopback Address field is automatically populated with the value from the Router ID field. To use a different loopback address, replace the value with another IP address. To configure no loopback address, clear the field.

    5. Complete the remaining fields on the Nodes and Interfaces page.

      The displayed fields depend on the options that you choose in the Layer 3 and Layer 2 areas.

    6. Click Next.

  7. On the Protocols page of the Create L3Out wizard, configure the BGP peer:

    1. In the BGP Loopback Policies and BGP Interface Policies areas, configure the following fields:

      • Peer Address: Enter the peer IP address.

      • EBGP Multihop TTL: Enter the connection time-to-live (TTL) value. The range is from 1 through 255 hops. A value of 0 does not specify a TTL. The default value is 1.

      • Remote ASN: Enter the autonomous system number of the neighboring autonomous system. Enter a 4-byte autonomous system number in asplain format from 1 through 4294967295.

        Note

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

    2. Click Next.

  8. On the External EPG page of the Create L3Out wizard, configure the external EPG:

    1. In the Name field, enter a name for the external network.
    2. In the Provided Contract field, enter the name of a provided contract.
    3. In the Consumed Contract field, enter the name of a consumed contract.
    4. Clear the Default EPG for all external networks check box if you do not want to advertise all transit routes through the L3Out.
    5. Click + next to Subnet to open the Create Subnet dialog box.
    6. In the IP address field, enter the IP address and network mask of the external network.
      Note

      Enter an IPv4 or IPv6 address that corresponds to the address family configured in the preceding steps. In the prefix EPG, configure either both BGP loopbacks or neither BGP loopback. If you configure only one BGP loopback, the BGP neighbor relationship is not established.

    7. In the Name field, enter a name for the subnet.
    8. In the Scope field, check the Export Route Control Subnet, Import Route Control Subnet, and Security Import Subnet check boxes.
      Note

      Check the Import Route Control Subnet check box to enforce BGP import route control.

    9. Click OK after you complete the configuration in the Create Subnet dialog box.
    10. Click Finish to complete the Create L3Out wizard.

  9. To configure additional BGP settings, choose Tenants > tenant_name > Networking > L3Outs > L3Out_name > Logical Node Profiles > log_node_prof_name > BGP Peer <address> .

    1. In the BGP Controls field, check the required controls.

      • Allow Self AS: Permits routes that contain the local AS number in the AS_PATH attribute.

      • AS override: Enables BGP AS override. You must also check the Disable Peer AS Check check box.

      • Disable Peer AS Check: Disables the peer autonomous system number check.

      • Next-hop Self: Sets the BGP next-hop attribute to the local peering address.

      • Send Community: Sends the BGP community attribute to the peer.

      • Send Extended Community: Sends the BGP extended community attribute to the peer.

      • Send Domain Path: Sends the BGP domain path to the peer.

    2. Check the Receive Additional Paths check box to enable the eBGP L3Out peer to receive multiple paths for each prefix from other eBGP peers.
    3. In the Password and Confirm Password fields, enter and confirm the administrative password.
    4. In the Allow Self AS Number Count field, choose the permitted number of occurrences of the local autonomous system number.
    5. In the Peer Controls field, configure the neighbor-check parameters.
    6. In the Address Type Controls field, configure the BGP IPv4 or IPv6 address-family settings, if required.
    7. Record the value in the Routing Domain ID field, if required.
    8. In the EBGP Multihop TTL field, enter the connection TTL.
    9. In the Weight for routes from this neighbor field, choose the weight assigned to routes received from the peer.
    10. In the Private AS Control field, configure private AS handling.
    11. In the BGP Peer Prefix Policy field, choose an existing peer prefix policy or create one.
    12. In the Site of Origin field, enter an extended community value that identifies the peer site.
    13. In the Remote Autonomous System Number field, enter the autonomous system number of the neighboring autonomous system.
    14. In the Local-AS Number Config field, choose the local autonomous system number configuration.
    15. In the Local-AS Number field, enter the local autonomous system number.
    16. In the Admin State field, choose Disabled or Enabled.
    17. In the Route Control Profile field, configure route control policies for the BGP peer.
    18. Click Submit.

  10. Choose Tenants > tenant_name > Networking > L3Outs > L3Out_name .

  11. Click the Policy/Main tab and configure route control:

    1. Optional: In the Route Control Enforcement field, check the Import check box.
    2. Expand Route Control for Dampening, choose the address-family type and route dampening policy, and click Update.

  12. Choose Tenants > tenant_name > Networking > L3Outs > L3Out_name .

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

  14. Complete the required fields, click + in the Context area, and configure the route control context:

    1. In the Name field, enter a name for the route control VRF instance.
    2. From the Set Attribute drop-down list, choose Create Action Rule Profile.

BGP Max Path and BGP Local Max ECMP

eBGP Max Path: Defines the maximum number of equal-cost paths the fabric installs in the routing table for routes learned from external eBGP peers.

iBGP Max Path: Defines the maximum number of equal-cost paths the fabric installs in the routing table for routes learned from external iBGP peers. This setting also controls the maximum number of equal-cost paths the fabric installs in the routing table for routes learned internal to the fabric via MP-BGP from border leaf switches.

BGP Local Max ECMP: Specifies the maximum number of next-hops the fabric propagates when redistributing static or OSPF routes into BPG. This setting is used with next-hop propagation.

BGP Max Path

This is the standard BGP multipath configuration used to control how many paths BGP will install into the Routing Information Base (RIB) and, subsequently, the Forwarding Information Base (FIB).It applies to BGP-learned routes (eBGP and iBGP) that are received from external BGP peers.

iBGP Max ECMP also applies to internal BGP routes redistributed in the fabric via MP-BGP. For example, the maximum number of next-hops that will be installed on a non-border leaf switch for an external prefix.

It allows the fabric to perform load balancing across multiple BGP paths to the same destination prefix. If you have multiple BGP paths to a destination, BGP will select up to the configured number of paths (e.g., 8) and install them as equal-cost paths in the routing table. It is found under the BGP Address Family context as eBGP Max ECMP and iBGP Max ECMP.

BGP Local Max ECMP

The Local Max ECMP is a property of the BGP Address Family Context Policy in Cisco ACI. It controls the maximum number of eligible equal-cost next hops that a leaf switch can select when redistributing locally learned static or OSPF routes into the fabric MP-BGP control plane.

Local Max ECMP is used with the Next Hop Propagation and Multipath route-map actions. By default, when a border leaf redistributes a static or OSPF route into MP-BGP, it replaces the route's next hop with its own tunnel endpoint (TEP) address. When Next Hop Propagation is enabled, the border leaf preserves the route's original next-hop information during redistribution. Enabling Multipath allows it to redistribute multiple eligible equal-cost next hops, up to the value configured for Local Max ECMP.

The default Local Max ECMP value is 0, which disables local multipath redistribution. Releases earlier than Cisco ACI 6.2(3) support a maximum value of 16. Beginning with release 6.2(3), the maximum value is 64. Values greater than 16 should be used only when the APIC cluster and every leaf and spine switch in the fabric run release 6.2(3) or later.

The policy is configured under:

Tenants > tenant > Policies > Protocol > BGP > BGP Address Family Context.

It is then associated with the appropriate IPv4 or IPv6 address family under the VRF's BGP Context Per Address Family configuration.

Preserving and advertising multiple external next hops allows other fabric leaf switches to forward traffic toward those next hops without first sending it through the redistributing border leaf. This can improve path diversity, load distribution, and resiliency while avoiding suboptimal hairpinning. Although commonly associated with Floating L3Out designs, Local Max ECMP can also be used in other designs that require multipath redistribution and next-hop propagation.

Mixed Mode Compatibility

The 64-way ECMP support is version-dependent. Nodes running firmware 6.2.3 or later support the full range (0-64). For the nodes running firmware prior to 6.2.3, the Policy Manager will automatically clamp the value to 16, even if you configure a higher value, regardless of the APIC configuration.

For more information refer to Mixed mode compatibility for ECMP scaling from release 62x and later

Configure BGP Max Path by using the GUI

Before you begin

Create the appropriate tenant and BGP external routed network.

Procedure

  1. From the menu bar, choose Tenants > All Tenants.

  2. In the work pane, double-click the tenant name.

  3. In the navigation pane, expand Tenant_name > Policies > Protocol > BGP > BGP Address Family Context.

  4. Right-click BGP Address Family Context and choose Create BGP Address Family Context Policy.

  5. In the Create BGP Address Family Context Policy dialog box, configure the policy:

    For the supported values for these fields, see the Verified Scalability Guide for Cisco APIC on the Cisco APIC documentation page.

    1. In the Name field, enter a name for the policy.
    2. In the eBGP Distance field, enter the administrative distance for eBGP routes.
    3. In the iBGP Distance field, enter the administrative distance for iBGP routes.
    4. In the Local Distance field, enter the administrative distance for local routes.
    5. In the eBGP Max ECMP field, enter the maximum number of equal-cost eBGP paths to use for load sharing.
    6. In the iBGP Max ECMP field, enter the maximum number of equal-cost iBGP paths to use for load sharing.

      It is recommended that you keep the iBGP Max ECMP and Max Local ECMP values synchronized. If these values are mismatched, the system will raise an "Info" level fault.

    7. In the Local Max ECMP field, enter the maximum number of local paths that BGP can redistribute as best paths for a route.

      This setting applies only to routes learned through another protocol, such as OSPF or static routing. It does not apply to routes learned through BGP.

      The configurable range is 0 to 64, with a default value of 0. If the value is set to 0, it disables the feature.

    8. Check the Enable Host Route Leak check box to distribute EVPN Type-2 MAC/IP host routes to the DCIG.
    9. Check the BGP Add-Path Capability: Receive check box to enable all eBGP peers in the tenant VRF to receive additional paths for each prefix from other eBGP peers.

      Without BGP Add-Path Capability: Receive, a leaf switch can receive only one next hop for each prefix from an eBGP peer.

    10. Click Submit.

  6. Choose Tenants > tenant_name > Networking > VRFs > vrf_name .

  7. In the work pane, review the configuration of the selected VRF.

  8. Locate the BGP Context Per Address Family field. In the BGP Address Family Type area, choose IPv4 unicast address family or IPv6 unicast address family.

  9. From the BGP Address Family Context drop-down list, choose the policy that you created and associate it with the VRF.

  10. Click Submit.

AS path prepending

Use this reference to configure AS path prepending and influence inbound routing paths.

AS path prepending

AS path prepending is a BGP mechanism that increases the length of the AS-path attribute by adding one or more autonomous system (AS) numbers to the beginning of the path.

  • Applies only to outbound route advertisements through route maps.

  • Supports eBGP sessions but not iBGP sessions.

  • Influences the best-path selection process of a remote BGP peer.

AS path prepending implementation

A BGP peer can influence best-path selection on a remote peer by increasing the length of the AS-path attribute. The remote peer typically prefers a route with a shorter AS path over an otherwise equivalent route.

AS path prepending supports the following methods:

Method

Description
Prepend

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

Note

  • You can configure more than one AS number.

  • Four-byte AS numbers are supported.

  • You can prepend up to 32 AS numbers. Specify the order in which each AS number is inserted into the AS-path attribute.
Prepend-last-as

Prepends the last AS number in the path from 1 through 10 times.

The following table describes the selection criteria for AS path prepending:

Criterion

Value

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

Configure AS path prepending by using the GUI

Before you begin

Create the tenant in which you want to configure the route map set rule.

Procedure

  1. Log in to the APIC GUI and choose Tenants > tenant_name > Policies > Protocol > Set Rules. Right-click Set Rules and choose Create Set Rules for a Route Map.

    The Create Set Rules For A Route Map window appears.

  2. In the Create Set Rules For A Route Map dialog box, configure the set rule:

    1. In the Name field, enter a name for the set rule.
    2. Check the Set AS Path check box and click Next.
    3. In the AS Path window, click + to open the Create Set AS Path dialog box.

  3. Choose the Prepend AS criterion and click + to add an AS number.

  4. Enter the AS number and its order, and then click Update. To prepend additional AS numbers, click + and repeat this step.

  5. After you configure the AS numbers, choose the Prepend Last-AS criterion to prepend the last AS number a specified number of times.

  6. In the Count field, enter a value from 1 through 10.

  7. Click OK.

  8. In the Create Set Rules For A Route Map window, verify the AS path criteria for the set rule and click Finish.

  9. From the APIC GUI menu bar, choose Tenants > tenant_name > Policies > Protocol > Set Rules, and then right-click the profile.

  10. Verify the Set AS Path values at the bottom of the window.

BGP external routed networks with AS override

Use the procedures in this reference to configure AS override for BGP external routed networks.

BGP autonomous system override

BGP autonomous system (AS) override is a routing feature that replaces the AS number of the originating router in the AS path of an outbound route with the AS number of the sending BGP router.

  • Prevents BGP loop-prevention mechanisms from rejecting routes when different sites use the same AS number.

  • Requires the Disable Peer AS Check option to be enabled at the same time.

  • Supports separate configuration for IPv4 and IPv6 address families.

BGP autonomous system override behavior

BGP prevents routing loops by examining the AS path of each received route. If the receiving router finds its own AS number in the AS path, it rejects the route because the route might have passed through the same AS previously.

This loop-prevention behavior can prevent connectivity between sites that use the same AS number and connect through another autonomous system. When one site advertises a route, another site with the same AS number rejects the route because its AS number appears in the AS path.

Beginning with Cisco APIC Release 3.1(2m), you can enable BGP autonomous system override to prevent this route rejection. You must also enable Disable Peer AS Check.

AS override replaces the AS number of the originating router in the AS path of an outbound route with the AS number of the sending BGP router. You can enable the feature separately for the IPv4 and IPv6 address families.

AS override is supported with GOLF and non-GOLF Layer 3 configurations.

Figure 2. Autonomous system override process

Router 1 and Router 2 represent two customers with multiple sites, Site-A and Site-B. Customer Router 1 uses AS 100, and Customer Router 2 uses AS 200.

The figure shows the following AS override process:

  1. Router 1-Site-A advertises route 10.3.3.3 with AS 100.

  2. Router PE-1 propagates the route internally to PE-2 with AS 100 in the AS path.

  3. Router PE-2 replaces AS 100 in the AS path with AS 121 and advertises prefix 10.3.3.3.

  4. Router 2-Site-B accepts the update for prefix 10.3.3.3.

Enable AS override for a BGP external routed network by using the GUI

Before you begin

  • Create the tenant, VRF, and bridge domain.

  • Create the non-GOLF external routed network, logical node profile, and BGP Peer Connectivity Profile.

Procedure

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

  2. In the navigation pane, choose the applicable BGP Peer Connectivity Profile.

  3. In the work pane, under Properties for the BGP Peer Connectivity Profile, configure the BGP Controls:

    1. Check the AS override check box.
    2. Check the Disable Peer AS Check check box.
      Note

      You must enable both AS override and Disable Peer AS Check for AS override to take effect.

    3. Configure any additional fields as required.

  4. Click Submit.

Per-VRF and per-node BGP timer configuration

Use the procedures in this reference to configure BGP timer values for individual VRFs and nodes.

Per-VRF and per-node BGP timer values

The per-VRF and per-node BGP timer feature provides granular control of BGP timer values for a specific VRF on an individual node.

  • Supports different BGP timer configurations for individual nodes in the same VRF.

  • Uses bgpProtP and bgpCtxPol to manage BGP timer policies.

  • Stores timer attributes such as holdIntvl, kaIntvl, and maxAsLimit in the bgpDom managed object (MO).

BGP timer policy selection algorithm

The system selects the BGP timer policy for a node by using the following hierarchy:

  • If bgpProtP references a bgpCtxPol, use that policy.

  • Otherwise, if the corresponding fvCtx references a bgpCtxPol, use that policy.

  • Otherwise, use the default policy under the tenant, such as uni/tn-<tenant>/bgpCtxP-default.

  • If the tenant does not have a default policy, use the preprogrammed default policy under the common tenant, such as uni/tn-common/bgpCtxP-default.

Configuration requirements

A per-VRF and per-node BGP timer configuration requires a valid Layer 3 Outside (L3Out) configuration that includes the following managed objects: fvTenant, fvCtx, l3extOut, l3extInstP, LNodeP, and bgpRR.

Configure a per-VRF and per-node BGP timer by using the Advanced GUI

A node-specific BGP timer policy overrides the BGP timer policy associated with the VRF for that node.

Before you begin

Create the tenant and VRF.

Procedure

  1. On the menu bar, choose Tenant > Tenant_name > Policies > Protocol > BGP > BGP Timers. Right-click BGP Timers and choose Create BGP Timers Policy.

  2. In the Create BGP Timers Policy dialog box, configure the policy:

    1. In the Name field, enter a name for the BGP timer policy.
    2. Configure the required timer values and click Submit.

    The BGP timer policy is created.

  3. Choose Tenant > Tenant_name > Networking > L3Outs. Right-click L3Outs and choose Create L3Out.

    The Create L3Out wizard appears. Use the wizard to create an L3Out with BGP enabled.

  4. On the Identity page of the Create L3Out wizard, configure the L3Out:

    1. In the Name field, enter a name for the L3Out.
    2. From the VRF drop-down list, choose the VRF.
    3. From the L3 Domain drop-down list, choose an external routed domain.
    4. In the routing protocol area, check the BGP check box.
    5. Click Next.

      The Nodes and Interfaces page appears.

    6. Complete the remaining pages in the Create L3Out wizard to create the L3Out.

  5. Choose the logical node profile in the L3Out that you created: Tenant > Tenant_name > Networking > L3Outs > L3Out_name > Logical Node Profiles > LogicalNodeProfile-name .

  6. In the Logical Node Profile window, check the Create BGP Protocol Profile check box.

    The Create Node Specific BGP Protocol Profile window appears.

  7. From the BGP Timers drop-down list, choose the BGP timer policy to associate with the node, and then click Submit.

    The BGP timer policy is 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 you do not choose a node-specific policy in the BGP Timers field, the node uses the BGP timer policy associated with the VRF that contains the node profile.

  8. Verify the node-specific BGP timer configuration:

    1. In the navigation pane, expand Tenant > Tenant_name > Networking > L3Outs > L3Out_name > Logical Node Profiles > LogicalNodeProfile-name > BGP Protocol Profile.
    2. Verify that the work pane displays the BGP protocol profile associated with the node profile.

BGP timer policy conflicts and faults

A BGP timer policy conflict causes a fault when different Layer 3 Outside (L3Out) configurations associated with the same VRF apply different BGP timer policies to the same node.

  • Multiple L3Outs are associated with the same VRF.

  • The same node is configured under the L3Outs.

  • Each L3Out applies a different BGP timer policy to the node.

BGP timer policy conflict resolution

Cisco APIC generates a fault when different L3Outs (l3Out) are associated with the same VRF (fvCtx) on the same node and their bgpProtP objects reference different BGP timer policies (bgpCtxPol).

In the following example, L3Outs out1 and out2 are associated with VRF ctx1. Both L3Outs contain node1. Under out1, the node uses BGP timer policy pol1. Under out2, the same node uses BGP timer policy pol2. Because the policies conflict, Cisco APIC generates a fault.

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

To clear the fault, change the configuration so that the L3Outs apply the same BGP timer policy to the node.

BGP neighbor shutdown and soft reset

Use the procedures in this reference to configure BGP neighbor shutdown and perform a soft reset.

BGP neighbor shutdown and soft reset

BGP neighbor shutdown and soft reset are neighbor-management features that control BGP sessions and routing table updates.

  • BGP neighbor shutdown disables or enables the administrative state of a neighbor without deleting the peer configuration.

  • BGP neighbor soft reset uses route refresh to update inbound or outbound routing information dynamically.

These features are supported beginning with Release 4.2(1).

BGP neighbor shutdown

BGP neighbor shutdown provides behavior similar to the neighbor shutdown command in Cisco NX-OS. Use the policy to disable or enable the administrative state of a BGP neighbor. Disabling the administrative state shuts down the BGP session without deleting the BGP peer configuration.

BGP neighbor soft reset

BGP neighbor soft reset uses the BGP route refresh capability to update inbound and outbound routing information dynamically without relying on stored routing table updates. Use the policy to perform a dynamic inbound or outbound soft reset.

Configure BGP neighbor shutdown by using the GUI

Before you begin

Complete the standard L3Out prerequisites, including the following configurations:

  • Configure the node, port, functional profile, attachable access entity profile (AEP), and Layer 3 domain.

  • Configure a BGP route reflector policy to propagate routes within the fabric.

Use the BGP neighbor administrative state to shut down or enable a BGP session without removing the peer configuration.

Procedure

  1. Create the L3Out and enable BGP:

    1. In the navigation pane, expand Tenant > Networking.
    2. Right-click L3Outs and choose Create L3Out.
    3. Enter the required information to configure BGP for the L3Out.

      On the Identity page of the L3Out creation wizard, choose BGP as the routing protocol.

    4. Complete the Nodes and Interfaces, Protocols, and External EPG pages to finish configuring the L3Out.

  2. Configure the administrative state of the BGP neighbor:

    1. Choose 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 .
    2. Scroll to the Admin State field and choose the required state.

      • Disabled: Disables the administrative state of the BGP neighbor and shuts down the BGP session.

      • Enabled: Enables the administrative state of the BGP neighbor.

Perform a BGP neighbor soft reset by using the GUI

Before you begin

Complete the standard L3Out prerequisites, including the following configurations:

  • Configure the node, port, functional profile, attachable access entity profile (AEP), and Layer 3 domain.

  • Configure a BGP route reflector policy to propagate routes within the fabric.

Procedure

  1. Create the L3Out and enable BGP:

    1. In the navigation pane, expand Tenant > Networking.
    2. Right-click L3Outs and choose Create L3Out.
    3. Enter the required information to configure BGP for the L3Out.

      On the Identity page of the L3Out creation wizard, choose BGP as the routing protocol.

    4. Complete the Nodes and Interfaces, Protocols, and External EPG pages to finish configuring the L3Out.

  2. Perform the BGP neighbor soft reset:

    1. Choose Tenants > tenant > Networking > L3Outs > L3out-name > Logical Node Profiles > logical-node-profile-name > Configured Nodes > node > BGP for VRF- vrf-name > Neighbors.
    2. Right-click the applicable neighbor entry and choose Clear BGP Peer.

      The Clear BGP page appears.

    3. From the Mode drop-down list, choose Soft.

      The Direction field appears.

    4. From the Direction drop-down list, choose the reset direction.

      • Incoming: Performs a dynamic inbound soft reset.

      • Outgoing: Performs an outbound soft reset.

BGP graceful restart helper

Border Gateway Protocol (BGP) graceful restart (GR) helps maintain routing stability while a router restarts its control plane. During the restart, neighboring routers can temporarily retain previously learned routes and continue forwarding traffic while routing protocol updates are suspended.

Cisco Application Centric Infrastructure (ACI) switches operate as GR helpers rather than GR initiators. When a peer performs an operation that triggers graceful restart, such as stateful switchover (SSO), an in-service software upgrade (ISSU), or a BGP process restart, the ACI switch maintains forwarding during the peer's BGP control-plane restart.

Graceful restart roles

During a graceful restart, one router restarts its routing process and initiates the graceful restart operation. A stable peer assists the restarting router by retaining its routes and forwarding state. The stable peer is called a graceful restart receiving device or graceful restart helper.

Graceful restart helper behavior

A graceful restart helper supports nonstop forwarding during a neighboring router's restart. The helper temporarily forwards packets by using stale routing information until the neighbor recovers and the routing adjacency is reestablished. The graceful restart helper capability is enabled by default within a VRF.

Graceful restart uses two primary timers:

  • Restart timer: The restarting router configures and advertises this timer to indicate the maximum time required to restart its routing protocol. If the timer expires before the restart completes, the helper assumes that the restart failed and removes the stale routes. Because an ACI switch operates only as a helper, you do not configure the restart timer on the ACI switch.

  • Stale timer: The graceful restart helper configures and uses this timer to determine how long it retains stale routes. For more information, see Stale interval.

Stale interval

During a graceful restart, the helper continues to use routes previously received from the peer but marks them as stale. After the BGP session is reestablished and the routers synchronize their routing information, the helper removes the stale routes and uses the newly received routes.

The Stale Interval timer determines when the helper removes stale routes if the session is not reestablished. This timer is applied locally. The default value is 300 seconds.

BGP graceful restart helper supported scenarios

Use this reference to identify the peer operations supported by BGP graceful restart helper mode.

In Cisco ACI, BGP graceful restart helper mode supports a peer that performs any of the following operations:

  • Stateful switchover (SSO)

  • In-service software upgrade (ISSU)

  • BGP process restart

During these operations, the Cisco ACI switch acts as the graceful restart helper and maintains forwarding while the peer recovers its BGP state.

BGP graceful restart helper guidelines

BGP peers exchange the graceful restart capability in an OPEN message during initial session establishment. Both the restarting router and its helper, the ACI leaf switch, must exchange this capability to enable graceful restart for the BGP session.

Modify BGP graceful restart helper settings by using the GUI

BGP graceful restart (GR) helper mode is enabled by default on Cisco ACI leaf switches. Use this procedure to change the stale interval for all BGP peers in a virtual routing and forwarding (VRF) instance or for a specific node in a VRF instance.

Before you begin

Ensure that the BGP graceful restart capability is exchanged with the peer and that the restart timer is received from the neighbor.

Procedure

  1. On the menu bar, choose Tenants > All Tenants, and then double-click the tenant name in the work pane.

  2. Complete one of the following sets of substeps to create a BGP timers policy.

    To create a BGP timers policy for all BGP peers in a VRF instance, complete the following substeps:

    1. In the navigation pane, choose tenant_name > Networking > VRFs > vrf_name.
    2. On the Policy tab, choose Create BGP Timers Policy from the BGP Timers drop-down list.

    To create a BGP timers policy for a specific node in a VRF instance, complete the following substeps:

    1. In the navigation pane, choose tenant_name > Networking > L3Outs > L3Out_name > Logical Node Profiles > logical_node_profile_name.
    2. On the Policy tab, check the Create BGP Protocol Profile check box.
    3. Choose Create BGP Timers Policy from the BGP Timers drop-down list.

  3. In the Create BGP Timers Policy dialog box, configure the BGP timers policy:

    1. In the Name field, enter a name for the BGP timers policy.
    2. In the Graceful Restart Controls field, check the Graceful Restart Helper check box.
    3. Optional: In the Stale Interval (sec) field, enter the stale interval.

      The default value is 300 seconds.

    4. Click Submit.
    The BGP timers policy is created.

  4. If you created the BGP timers policy for a specific node in a VRF instance, click Submit in the Create Node Specific BGP Protocol Profile dialog box.

  5. Click Submit to save the configuration.

BFD configuration

Use the procedures in this reference to configure Bidirectional Forwarding Detection (BFD) parameters.

Bidirectional Forwarding Detection

Bidirectional Forwarding Detection (BFD) is a low-overhead network protocol that rapidly detects forwarding-path failures between two routing devices.

  • Provides subsecond failure detection.

  • Provides a consistent timeout mechanism for multiple routing protocols.

  • Detects failures across different physical media and Layer 2 topologies.

BFD scenarios, guidelines, and limitations

BFD is particularly useful in the following scenarios:

  • Peering routers connect through a Layer 2 device or cloud that does not make forwarding-path failures directly visible.

  • The physical medium, such as shared Ethernet, does not provide reliable failure detection.

  • Multiple routing protocols operate between the routers and require consistent, predictable convergence times.

The following guidelines and limitations apply to BFD:

  • Beginning with Cisco APIC Release 3.1(1), BFD between leaf and spine switches is supported on fabric interfaces for IS-IS and on spine switches for OSPF and static routes.

  • Beginning with Cisco APIC Release 5.2(4), BFD supports static routes that are reachable through secondary IPv4 or IPv6 subnets.

  • BFD is supported on modular spine switches with -EX, -FX, or later-generation line cards and on Cisco Nexus 9364C or later-generation fixed spine switches.

  • BFD between virtual port channel (vPC) peers is not supported.

  • Beginning with Cisco APIC Release 5.0(1), leaf switches support multihop BFD.

  • Beginning with Cisco APIC Release 5.0(1), Cisco ACI supports C-bit-aware BFD.

  • Beginning with Release 6.2(2), BFD supports multihop and single-hop sessions over eBGP and iBGP prefix peers.

  • You can enable BFD subinterface optimization in an interface policy.

Note

To change a secondary address that sources a BFD session, add the new address in the same subnet before you remove the existing address.

BFD optimization on subinterfaces

BFD optimization on subinterfaces consolidates session management by designating the subinterface with the lowest VLAN ID as the master subinterface.

  • The master subinterface inherits the BFD session parameters from the parent interface.

  • The remaining subinterfaces use the slow timer for their session intervals.

  • A failure detected on the optimized subinterface causes all subinterfaces on the physical interface to transition to the down state.

BFD echo function

You can enable the BFD echo function on one or both ends of a link. The echo configuration determines the required minimum receive interval associated with the slow timer.

  • When the echo function is disabled, the RequiredMinEchoRx parameter is set to zero.

  • When the echo function is enabled, the slow timer determines the required minimum receive interval.

Note

If a subinterface flaps, all subinterfaces on the same physical interface are affected and transition to the down state for approximately one second.

Configure BFD on a secondary IP address by using the GUI

Use this procedure to configure Bidirectional Forwarding Detection (BFD) for a secondary IPv4 address or an additional IPv6 address.

Procedure

  1. On the menu bar, choose Tenants > All Tenants.

  2. In the work pane, double-click the tenant name.

  3. In the navigation pane, choose tenant_name > Networking > L3Outs > l3out_name > Logical Node Profiles > node_profile_name > Logical Interface Profiles > interface_profile_name .

  4. In the work pane, choose Policy > Routed Sub-interfaces, Policy > Routed Interfaces, or Policy > SVI, depending on the interface type.

  5. Double-click the interface that you want to configure.

  6. Configure the secondary or additional address based on the interface type:

    1. For a routed subinterface, routed interface, or switched virtual interface (SVI) with Path Type set to Port or Direct Port Channel, click + in the IPv4 secondary/IPv6 Additional Addresses table. Enter the IP address and subnet, and then click Submit.
    2. For an SVI with Path Type set to Virtual Port Channel, click + in the Side B IPv4 Secondary/IPv6 Additional Addresses table. Enter the IP address and subnet, and then click OK.

  7. In the navigation pane, choose tenant_name > Networking > L3Outs > l3out_name > Logical Node Profiles > node_profile_name > Configured Nodes > node_name .

  8. In the Static Routes table, click + and configure the static route:

    1. In the Prefix field, enter the IP address and mask of the static route for the external network.
    2. Check the BFD check box.
    3. In the Next Hop Addresses table, click +. In the Next Hop Address field, enter an IP address that is reachable through the secondary address configured on the interface.
    4. Complete the remaining fields as required.
    5. Click OK.

  9. Complete the remaining fields as required.

  10. Click Submit.

Configure BFD globally on a leaf switch by using the GUI

Procedure

  1. On the menu bar, choose Fabric > Access Policies.

  2. In the navigation pane, expand Policies > Switch > BFD.

    The following Bidirectional Forwarding Detection (BFD) policy types are available:

    • BFD IPv4

    • BFD IPv6

    For each BFD policy type, you can use the default policy or create a policy for a specific switch or group of switches.

    Note

    Cisco APIC creates default global BFD policies when the system starts. You can modify the attributes of a default policy in the work pane. Changes to a default global policy affect all switches in the fabric. To use different settings for a specific switch or group of switches, create a leaf switch profile as described in the following steps.

  3. To create a leaf switch profile for a nondefault global BFD policy, expand Switches > Leaf Switches > Profiles in the navigation pane.

    The Leaf Switches - Profiles page appears in the work pane.

  4. From the actions menu on the right side of the work pane, choose Create Leaf Profile.

    The Create Leaf Profile dialog box appears.

  5. In the Create Leaf Profile dialog box, configure the leaf switch profile:

    1. In the Name field, enter a name for the leaf switch profile.
    2. Optional: In the Description field, enter a description of the profile.
    3. Optional: On the Leaf Selectors toolbar, click +.
    4. In the Name field, name the switch selector. In the Blocks field, choose the switch. In the Policy Group field, choose Create Access Switch Policy Group.

      The Create Access Switch Policy Group dialog box appears. In this dialog box, you can configure the policy group identity properties.

  6. If you configured a leaf selector, configure the policy group in the Create Access Switch Policy Group dialog box:

    1. In the Name field, enter a name for the policy group.
    2. Optional: In the Description field, enter a description of the policy group.
    3. Choose BFD IPv4 Policy or BFD IPv6 Policy. Choose the default policy or the appropriate option to create a BFD global policy for the selected switch or group of switches.
    4. Click Update.

  7. Click Next to open Associations.

    Optional: In Associations, associate the leaf profile with leaf interface profiles and access module profiles.

  8. Click Finish.

    You can also create a global BFD policy by right-clicking BFD IPv4 or BFD IPv6 in the navigation pane.

  9. To view the global BFD configuration, expand Policies > Switch > BFD in the navigation pane.

Configure BFD globally on a spine switch by using the GUI

Procedure

  1. On the menu bar, choose Fabric > Access Policies.

  2. In the navigation pane, expand Policies > Switch > BFD.

    The following Bidirectional Forwarding Detection (BFD) policy types are available:

    • BFD IPv4

    • BFD IPv6

    For each BFD policy type, you can use the default policy or create a policy for a specific switch or group of switches.

    Note

    Cisco APIC creates default global BFD policies when the system starts. You can modify the attributes of a default policy in the work pane. Changes to a default global policy affect all switches in the fabric. To use different settings for a specific switch or group of switches, create a spine switch profile as described in the following steps.

  3. To create a spine switch profile for a nondefault global BFD policy, expand Switches > Spine Switches > Profiles in the navigation pane.

    The Spine Switches - Profiles page appears in the work pane.

  4. From the actions menu on the right side of the work pane, choose Create Spine Profile.

    The Create Spine Profile dialog box appears.

  5. In the Create Spine Profile dialog box, configure the spine switch profile:

    1. In the Name field, enter a name for the spine switch profile.
    2. Optional: In the Description field, enter a description of the profile.
    3. Optional: On the Spine Selectors toolbar, click +.
    4. In the Name field, name the switch selector. In the Blocks field, choose the switch. In the Policy Group field, choose Create Spine Switch Policy Group.

      The Create Spine Switch Policy Group dialog box appears. In this dialog box, you can configure the policy group identity properties.

  6. If you configured a spine selector, configure the policy group in the Create Spine Switch Policy Group dialog box:

    1. In the Name field, enter a name for the policy group.
    2. Optional: In the Description field, enter a description of the policy group.
    3. Choose BFD IPv4 Policy or BFD IPv6 Policy. Choose the default policy or the appropriate option to create a BFD global policy for the selected switch or group of switches.
    4. Click Update.

  7. Click Next to open Associations.

    Optional: In Associations, associate the spine profile with spine interface profiles.

  8. Click Finish.

    You can also create a global BFD policy by right-clicking BFD IPv4 or BFD IPv6 in the navigation pane.

  9. To view the global BFD configuration, expand Policies > Switch > BFD in the navigation pane.

Configure a BFD interface override by using the GUI

Before you begin

Create the tenant.

You can configure an explicit Bidirectional Forwarding Detection (BFD) policy on routed Layer 3 interfaces, external switched virtual interfaces (SVIs), and routed subinterfaces. Use an interface override when an interface requires settings that differ from the global BFD policy applied to its switch or group of switches.

Note

When you configure a BFD interface policy on a parent routed interface, routed subinterfaces with the same address family inherit the policy by default. To override an inherited setting, configure an explicit BFD interface policy on the subinterface. If Admin State or Echo Admin State is disabled on the parent interface, you cannot override that setting on a subinterface.

Procedure

  1. On the menu bar, choose Tenant.

  2. In the navigation pane under Quick Start, expand Tenant_name > Networking > L3Outs.

  3. Right-click L3Outs and choose Create L3Out.

    The Create L3Out wizard appears.

  4. On the Identity page of the Create L3Out wizard, configure the L3Out identity:

    1. Complete the Name, VRF, and L3 Domain fields.
    2. In the routing protocol area, check the BGP check box.
    3. Click Next.

      The Nodes and Interfaces page appears.

  5. On the Nodes and Interfaces page of the Create L3Out wizard, configure the nodes and interfaces:

    1. In the Layer 3 area, choose Routed.
    2. From the Node ID drop-down list, choose the node for the L3Out.

      For the topology used in these examples, choose node 103.

    3. In the Router ID field, enter the router ID.
    4. Optional: Configure a different loopback address or disable the loopback address, if required.

      The Loopback Address field is automatically populated with the value from the Router ID field. This behavior is equivalent to the Use Router ID for Loopback Address option in earlier releases. To use a different loopback address, replace the value with another IP address. To configure no loopback address, clear the field.

    5. Complete the remaining fields on the Nodes and Interfaces page.

      The displayed fields depend on the options that you choose in the Layer 3 and Layer 2 areas.

    6. Click Next.

      The Protocols page appears.

  6. On the Protocols page of the Create L3Out wizard, configure the routing protocol policies:

    1. In the BGP Loopback Policies and BGP Interface Policies areas, configure the BGP peer:

      • Peer Address: Enter the peer IP address.

      • EBGP Multihop TTL: Enter the connection time-to-live (TTL) value. The range is from 1 through 255 hops. A value of 0 does not specify a TTL. The default value is 0.

      • Remote ASN: Enter the autonomous system number of the neighboring autonomous system. Enter a 4-byte autonomous system number in asplain format from 1 through 4294967295.

        Note

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

    2. In the OSPF area, choose the default OSPF policy, an existing OSPF policy, or Create OSPF Interface Policy.
    3. Click Next.

      The External EPG page appears.

  7. On the External EPG page of the Create L3Out wizard, configure the external EPG:

    1. In the Name field, enter a name for the external network.
    2. In the Provided Contract field, enter the name of a provided contract.
    3. In the Consumed Contract field, enter the name of a consumed contract.
    4. Clear the Default EPG for all external networks check box if you do not want to advertise all transit routes through the L3Out.

      When you clear this check box, the Subnets area appears. Configure the required subnets and route controls.

    5. Click Finish to complete the Create L3Out wizard.

  8. Choose Tenants > tenant_name > Networking > L3Outs > L3Out_name > Logical Node Profiles > logical_node_profile_name > Logical Interface Profiles > logical_interface_profile_name .

  9. In the Logical Interface Profile window, scroll to Create BFD Interface Profile and check the corresponding check box.

  10. In the Create BFD Interface Profile window, configure the BFD settings.

    • From the Authentication Type drop-down list, choose No authentication or Keyed SHA1.

      If you choose Keyed SHA1, enter the Authentication Key ID and Authentication Key, and then reenter the key in the Confirm Key field.

    • From the BFD Interface Policy drop-down list, choose common/default to use the default BFD policy, or choose Create BFD Interface Policy to create a policy.

      If you choose Create BFD Interface Policy, the Create BFD Interface Policy dialog box appears. Configure the BFD interface policy values in this dialog box.

  11. Click Submit.

  12. To view the configured interface-level BFD policy, choose Policies > Protocol > BFD.

Configure BFD for consumer protocols by using the GUI

Bidirectional Forwarding Detection (BFD) consumer protocols require a protocol-specific setting that enables them to use BFD.

Note

The BGP, OSPF, and EIGRP protocol policies are available in the navigation pane under Tenant > Policies > Protocol.

Before you begin

Create the tenant.

Procedure

  1. Create an L3Out by using the Create L3Out wizard.

  2. On the menu bar, choose Tenant.

  3. To configure BFD for BGP, expand Tenant_name > Policies > Protocol > BGP > BGP Peer Prefix in the navigation pane.

  4. From the actions menu on the right side of the work pane, choose Create BGP Peer Prefix Policy.

    The Create BGP Peer Prefix Policy dialog box appears.

    Note

    You can also right-click BGP Peer Prefix in the navigation pane and choose Create BGP Peer Prefix.

  5. In the Name field, enter a name for the BGP peer prefix policy, and then complete the remaining fields.

  6. Click Submit.

    The policy appears under BGP Peer Prefix in the navigation pane.

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

  8. In the BGP Peer Connectivity Profile window, scroll to the BGP Peer Prefix Policy field and choose the policy that you created.

  9. In the Peer Controls field, check Bidirectional Forwarding Detection to enable BFD for the BGP peer. Clear the check box to disable BFD.

  10. To configure BFD for OSPF, choose Policies > Protocol > OSPF > OSPF Interface in the navigation pane.

  11. From the actions menu on the right side of the work pane, choose Create OSPF Interface Policy.

    The Create OSPF Interface Policy dialog box appears.

    Note

    You can also right-click OSPF Interface in the navigation pane and choose Create OSPF Interface Policy.

  12. In the Name field, enter a name for the OSPF interface policy, and then complete the remaining fields.

  13. In the Interface Controls area, check BFD to enable BFD for OSPF. Clear the check box to disable BFD.

  14. Click Submit.

  15. To configure BFD for EIGRP, choose tenant_name > Policies > Protocol > EIGRP > EIGRP Interface in the navigation pane.

  16. From the actions menu on the right side of the work pane, choose Create EIGRP Interface Policy.

    The Create EIGRP Interface Policy dialog box appears.

    Note

    You can also right-click EIGRP Interface in the navigation pane and choose Create EIGRP Interface Policy.

  17. In the Name field, enter a name for the EIGRP interface policy, and then complete the remaining fields.

  18. In the Control State area, check BFD to enable BFD for EIGRP. Clear the check box to disable BFD.

  19. Click Submit.

  20. To configure BFD for a static route, choose Networking > L3Outs > L3Out_name > Configured Nodes in the navigation pane, and then click the configured node.

    The Node Association window appears.

  21. In the Static Routes area, click +.

    The Create Static Route dialog box appears. Complete the required fields.

  22. Under Route Control, check BFD to enable BFD for the static route. Clear the check box to disable BFD.

  23. Click Submit.

  24. In the 6.2(2) release and earlier, to configure BFD for IS-IS, choose Fabric > Fabric Policies > Policies > Interface > L3 Interface in the navigation pane.

    Fabric BFD for IS-IS is not recommended for the following reasons:

    • In a leaf-spine fabric, IS-IS peers use directly connected subinterfaces. If a leaf or spine switch fails, the physical link also goes down and triggers Layer 1 convergence. BFD does not provide an additional convergence benefit in most of these failure scenarios.

    • BFD can experience false session flaps when BFD packets do not receive sufficient CPU processing time, especially during high CPU utilization, such as during a tech-support collection. A false BFD flap directly affects the IS-IS adjacency. Because IS-IS is a critical fabric control-plane protocol, these flaps can cause widespread data center network instability.

    This configuration is not supported in the 6.2(3) release and later.

  25. From the actions menu on the right side of the work pane, choose Create L3 Interface Policy.

    The Create L3 Interface Policy dialog box appears.

    Note

    You can also right-click L3 Interface in the navigation pane and choose Create L3 Interface Policy.

  26. In the Name field, enter a name for the Layer 3 interface policy, and then complete the remaining fields.

  27. In the BFD ISIS Policy Configuration field, choose Enabled.

  28. Click Submit.

BFD multihop

Bidirectional Forwarding Detection (BFD) multihop detects forwarding failures across multiple network hops.

  • Supports IPv4 and IPv6.

  • Establishes sessions between specific source and destination addresses instead of between interfaces.

  • Supports paths of up to 255 hops.

BFD multihop guidelines and limitations

  • The default and minimum transmit and receive intervals are 250 milliseconds.

  • The default and minimum detection multiplier is 3.

  • BFD multihop does not support echo mode.

Configure a BFD multihop policy

You can configure a Bidirectional Forwarding Detection (BFD) multihop policy in several GUI locations, depending on the scope and purpose of the policy.

  • Global policies : By default, the APIC creates global BFD multihop policies when the system starts. You can modify the attributes of these policies in the work pane. Changes to a default global policy affect all switches. To use different settings for a specific switch or group of switches, create a switch profile and modify the BFD multihop settings in that profile.

    You can create or modify global BFD multihop policies for IPv4 or IPv6 in the following GUI locations:

    • Fabric > Access Policies > Policies > Switch > BFD Multihop > BFD Multihop IPv4 : Right-click and choose Create BFD Global IPv4 MH Policy .

    • Fabric > Access Policies > Policies > Switch > BFD Multihop > BFD Multihop IPv6 : Right-click and choose Create BFD Global IPv6 MH Policy .

  • Node policies : A BFD multihop node policy applies to the interfaces under a node profile.

    You can create or modify BFD multihop node policies in the following GUI location:

    • Tenants > tenant > Policies > Protocol > BFD Multihop > Node Policies : Right-click and choose Create BFD Multihop Node Policy .

  • Interface policies : A BFD multihop interface policy applies to the interfaces under an interface profile.

    You can create or modify BFD multihop interface policies in the following GUI location:

    • Tenants > tenant > Policies > Protocol > BFD Multihop > Interface Policies : Right-click and choose Create BFD Multihop Interface Policy .

  • Override policies : To override the default global configuration for specific switches or interfaces, create a BFD multihop node or interface policy and associate it with the appropriate profile.

    You can create or modify BFD multihop override policies for a node profile or interface profile in the following GUI locations:

    • Tenants > tenant > Networking > L3Outs > l3out > Logical Node Profiles > logical_node_profile : Right-click, choose Create BFD Interface Protocol Profile , and specify a BFD multihop node policy.

    • Tenants > tenant > Networking > L3Outs > l3out > Logical Node Profiles > logical_node_profile > Logical Interface Profiles > logical_interface_profile : Right-click, choose Create MH-BFD Interface Protocol Profile , and specify a 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, choose Create MH-BFD Interface Profile , and specify a BFD multihop interface policy.

Procedure

  1. Navigate to the GUI location for the type of BFD multihop policy that you want to configure.

  2. Open an existing policy or profile, or open the dialog box to create one.

  3. From the Authentication Type field, choose the authentication method for the BFD multihop sessions.

    You can choose no authentication or SHA-1 authentication.

  4. If you are creating a policy, configure the following settings:

    1. In the Name field, enter a name for the policy.
    2. Set Admin State to Enabled .
    3. In the Detection Multiplier field, enter the detection multiplier.

      The detection multiplier specifies the minimum number of consecutive packets that can be missed before BFD declares the session down. The range is from 1 to 50 packets. The default value is 3.

    4. In the Minimum Transmit Interval field, enter the minimum transmit interval.

      The minimum transmit interval specifies the minimum interval between transmitted packets. The range is from 250 to 999 milliseconds. The default value is 250 milliseconds.

    5. In the Maximum Receive Interval field, enter the maximum receive interval.

      The maximum receive interval specifies the maximum interval between received packets. The range is from 250 to 999 milliseconds. The default value is 250 milliseconds.

    6. Click Submit .

Micro BFD

Micro BFD enhances BFD by establishing an individual BFD session on each member link of a port channel.

  • Detects failures faster on individual member links.

  • Identifies the specific failed links in a port channel.

  • Automatically removes failed links from port-channel forwarding.

Micro BFD guidelines and limitations

The following guidelines and limitations apply to micro BFD:

  • Micro BFD is supported on both Link Aggregation Control Protocol (LACP) and non-LACP port channels.

  • Micro BFD can run simultaneously with multihop BFD on the same port channel, but it cannot run with single-hop BFD on the same port channel.

  • Micro BFD functions as a single-hop BFD implementation. It does not operate if a Layer 2 switch is located between the main port channel and the peer.

  • Micro BFD can run on a parent port channel while single-hop BFD runs on subinterfaces of the same port channel.

  • Micro BFD is not supported on first-generation leaf switches whose product IDs do not have an -EX or -FX suffix.

  • Micro BFD is supported only on a routed interface over a port channel.

  • Client protocols can run on a subinterface of the same port channel on which micro BFD is enabled.

  • Micro BFD is not supported on fabric extender (FEX) ports or fabric ports.

  • BFD echo mode is not supported for micro BFD sessions.

  • On a dual-stack port channel, configure micro BFD with either an IPv4 address or an IPv6 address, but not both.

  • Creating or deleting a Layer 3 port-channel main interface causes the physical member ports to flap. This behavior can cause traffic loss if subinterfaces are active.

Figure 3. Micro BFD sessions on a port channel

Configure micro BFD on a port channel

Before you begin

  • Configure a direct port channel for the L3Out interface.

This procedure enables Micro BFD on an L3Out port-channel interface. Micro BFD establishes an individual BFD session on each member link of the port channel.

Procedure

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

  2. Choose the Logical Interface Profile that you want to modify.

  3. Click the Routed Interfaces tab.

    Micro BFD is supported only on a routed interface over a port channel.

  4. In the Routed Interfaces section, double-click an existing interface to modify it, or click + to add an interface to the logical interface profile.

    The remaining steps describe how to enable Micro BFD on an existing logical interface. To add an interface to the logical interface profile, see Modifying Interfaces for L3Out Using the GUI .

  5. In the properties for the selected interface, verify that Path Type is set to Direct Port Channel .

    Micro BFD applies only to a port channel.

  6. Check the Enable Micro BFD check box.

  7. In the Micro BFD Destination Address field, enter the destination IP address of the port channel.

  8. In the Micro BFD Start Timer (sec) field, enter a value from 60 to 3600 seconds.

    The start timer delays the activation of BFD monitoring on the member links to allow the BFD sessions to become established. If you do not configure the timer, BFD monitoring is activated without a delay.

  9. Click Submit .

What to do next

Verify the Micro BFD sessions by using the CLI commands 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