Cisco Nexus Hyperfabric - Cisco Nexus Hyperfabric

Border Gateway Protocol (BGP)

BGP is a dynamic routing protocol used to exchange routing information between different autonomous systems (AS) on the internet. You should configure BGP if your network needs to connect to multiple external networks or support complex, scalable routing. BGP enables automatic route updates and adapts quickly to network changes, making it essential for medium to large networks that require high availability, redundancy, and flexibility.

When BGP peering is established between devices, they share full routing tables initially and then exchange updates only for changed routes. BGP policies allow you to control which routes are advertised or accepted, helping you manage network traffic according to your organization’s needs.

Compared to static routing—which is simple but lacks scalability and requires manual updates—BGP is a robust solution that supports dynamic growth and reliability.

To configure and apply your changes, ensure that you are in edit mode and that you commit your changes.

BGP policies

BGP import and export policies consist of rules and configurations that determine which routing information is selected, advertised, and accepted between BGP peers.

BGP import policy applies to routes received from external BGP peers. BGP export policy applies to routes sent to external BGP peers.

Default import and export policies are predefined and cannot be changed. The default policy acts as a template that contains specific rules.
If you use both default import and export policies, these routes are not advertised to the external peer.
- externally learned routes
- default route
- internal endpoint IP addresses

To view the default import or export policies, navigate to the Fabrics page. In the Attachments area, choose BGP > Import policies or BGP > Export policies.

Default import policy

**Default import policy**
Match	Set	Action
All	Community 64511:99	Permit

Default export policy

**Default export policy**
Match	Set	Action
Community 64511:99	-	Deny
Route tag Black	-	Deny
IPv4 Prefix 0.0.0.0/0 (Exact)	-	Deny
IPv6 Prefix ::/0 (Exact)	-	Deny
Community 64510:*	-	Permit
IPv4 Prefix 0.0.0.0/0 (Exact or longer) 32	-	Deny
IPv6 Prefix ::/0 (Exact or longer) 128	-	Deny
All All conditions are matched	-	Permit

When you add a static route, the Discard option in the Add Static Route page, matches Match Route tag Black, Deny rule in the default export policy. See Add a static route.
The rule Community: 64510:* is used to advertise one or more static routes to an external network.
In the default export policy, certain rules prevent advertisement of the default route and internal endpoint IP addresses (host routes) to the external network.
- Match 0.0.0.0/0 (Exact), Deny
- Match ::/0 (Exact), Deny
- Match 0.0.0.0/0 (Exact or longer) 32, Deny
- Match ::/0 (Exact or longer) 128, Deny
Because the route imported from the external BGP peer has the rule Community: 64511:99 set by the default import policy, the route is not exported to a BGP peer because of the Deny rule in the default export policy.

Create a BGP import policy

Follow these steps to create a BGP import policy.

Step 1	Choose Fabrics, then click the fabric you want to configure a BGP import policy for.
Step 2	In the Attachments area, choose BGP > Import policies.
Step 3	Click + New policy. New policy
Step 4	Enter BGP import policy details. For Import policy name, enter a name for the new BGP import policy. For Labels, click + Add, to enter labels to help categorize the policies, and press Enter. For Description, add text that describes this BGP import policy. For Annotations, click + Add and enter key-value pairs to add annotations.
Step 5	Enter BGP import policy rules. From the Import policy rules (up to 10) area, click + Add rule to add up to 10 rules. In the Order column, use the arrow key to assign an order to the rules in the policy. In the Match column, select the rule type. Community: Provide community numbers. Wildcards are supported. IPv4: Provide IPv4 prefixes, match conditions, and route origins. IPv6: Provide IPv6 prefixes, match conditions, and route origins. Route-tag: Provide route tags. In the Set column, select a BGP attribute from the drop-down list. In the Action column, select an action (permit or deny) to be taken for packets that match the rule from the drop-down list. Click to add match values for each rule. Up to 5 comma-separated values are supported for each rule (except route tags). BGP import policy rule
Step 6	Click Add.

Create a BGP export policy

Follow these steps to create a BGP export policy.

Step 1	Choose Fabrics, then click the fabric you want to configure a BGP import policy for.
Step 2	In the Attachments area, choose BGP > Export policies.
Step 3	Click + New policy. New policy
Step 4	Enter BGP export policy details. For Export policy name, enter a name for the new BGP import policy. For Labels, click + Add, to enter labels to help categorize the policies, and press Enter. For Description, add text that describes this BGP import policy. For Annotations, click + Add and enter key-value pairs to add annotations.
Step 5	Enter BGP export policy rules. From the Export policy rules (up to 10) area, click + Add rule to add up to 10 rules. In the Order column, use the arrow key to assign an order to the rules in the policy. In the Match column, select the rule type. Community: Provide community numbers. Wildcards are supported. IPv4: Provide IPv4 prefixes, match conditions, and route origins. IPv6: Provide IPv6 prefixes, match conditions, and route origins. Route-tag: Provide route tags. In the Set column, select a BGP attribute from the drop-down list. AS path pad: Provide AS path list. Community: Provide community numbers. Next-hop IPv4: Provide IPv4 address of the connection between the peers. Next-hop IPv6: Provide IPv6 address of the connection between the peers. In the Action column, select an action (permit or deny) to be taken for packets that match the rule from the drop-down list. Expand the row to add match values for each rule. Up to 5 comma-separated values are supported for each rule (except route tags). BGP import policy rule
Step 6	Click Add.

BGP peering

Within the Cisco Nexus Hyperfabric, BGP peering can be broadly categorized into two types:

BGP peering from routed interfaces (northbound peering): This peering type establishes BGP sessions via routed or routed sub-interfaces. It typically connects the network fabric to the external network behind physical devices.
BGP peering from host interfaces (southbound peering): This peering type establishes BGP sessions between the network fabric and devices within a data center's logical network subnet. This approach commonly uses virtual devices such as virtual routers, virtual firewalls, or containers. It provides greater control and insight into the movement of traffic for individual hosts.

The figure illustrates a network fabric. SP01 and SP02 function as spine switches, providing core connectivity, including to a Wide Area Network (WAN). Leaf switches LF01, LF02, LF03, and LF04 connect to both spines for redundancy and load balancing. Virtual routers (vRouter1, vRouter2, vRouter3), representing Host 1, Host 2, and Host 3, connect to leaf switches LF01, LF02, and LF03.

The figure highlights the two types of BGP peering. "BGP peering from routed interfaces" (dashed blue line) connects the virtual routers to a logical network SVI (172.16.1.254/24) and an external network (10.0.0.0/8). "BGP peering from host interfaces" (dashed light blue line) directly connects the virtual routers to the leaf switches. This configuration demonstrates BGP peering relationships within the fabric and with external networks.

Note

Although the figure shows spines and leaves, either type of BGP peering can occur on devices other than spines or leaves.

Examples of BGP peering from host interfaces

These examples illustrate the concept and resilience of BGP peering from host interfaces.

In this example, multiple virtual routers (vRouter1, vRouter2, vRouter3) on different hosts are within the same logical network. These virtual routers establish BGP peering with the loopback interfaces of the spine switches (SP01 and SP02), which form the core of the network fabric. This demonstrates initial BGP peering from host interfaces that are connected to external devices within a logical network.

Initial topology for BGP peering from host interfaces

This example highlights a key advantage of this design. It shows vRouter3 migrating from Host 3 to Host 4, a change in its physical location within the fabric. The BGP peering remains unchanged, illustrating the stability and mobility benefits of BGP peering from host interfaces. The BGP sessions remain active and unaffected by the virtual device's physical relocation, ensuring continuous routing and connectivity for its services.

Workload migration with stable BGP peering from host interfaces

Configure BGP peering from routed interfaces

BGP peering from routed interfaces, often referred to as northbound peering, involves establishing BGP sessions between switches using their routed interfaces. This type of peering connects the fabric to external networks. It is used for getting traffic in and out of the network.

Step 1	Navigate to the BGP peers area for a specific route table (VRF). Select Fabrics, then click the fabric you want to configure. In the Logical Networks area, click Route tables (VRF). In the All route tables (VRFs) table, click the route table name where you will configure a BGP peer. In the Configurations area, click BGP peers.
Step 2	Enter the VRF's local autonomous system (AS). In the BGP peers area, click the pencil icon and enter the VRF local AS. Click Save. By default, the VRF local AS is used for the BGP peer unless you configure a local AS override when configuring a peer.
Step 3	Choose + Add BGP peer > from routed interface.
Step 4	For Peer name, enter a name for the new BGP peer.
Step 5	Enter BGP peer address and interface details. For Peer address & interface, enter the peer IP address (the destination IP address of the remote BGP neighbor). Alternatively, you can choose to enter a subset for passive listening. Note For BGP peers that support both IPv4 and IPv6, you must create a separate BGP peer configuration for each address family. In the Select an available routed interface table, select the local interface that will be used to establish the BGP session.
Step 6	Enter BGP peering details. For Type, select the BGP type: iBGP (internal BGP): This BGP type is used to exchange routing information inside a single Autonomous System (AS). Peers are within the same AS. eBGP (external BGP): This BGP type is used to exchange routing information between different ASes. Peers are in different ASes. For Configuration, if the BGP type is eBGP, then select single-hop or multi-hop. For Time to live (TTL), if the BGP type is eBGP and multi-hop, enter the number (2 to 255) of hops allowed for a peering session. As a security check, BGP will establish or maintain a session only if the TTL value in the received IP packet header is equal to or greater than the TTL value configured here for the peering session. For Peer AS, enter the autonomous system (AS) number of the peer. Enter the Local AS override number. Entering an override local AS number allows a switch to replace the AS number of the originating switch with the AS number of the sending BGP switch, preventing the receiving switch from dropping packets from an originator with the same AS as the receiver. By default, the VRF Local AS will be used unless a new value is provided.
Step 7	In the Policy area, select an Import policy and an Export policy from the drop-down list or keep the defaults. These policies are defined in Create a BGP import policy and Create a BGP export policy.
Step 8	(Optional) In the Security area, select an authentication method and enter the credentials.
Step 9	Click Save.

Configure BGP peering from host interfaces

BGP peering from host interfaces establishes BGP sessions between the fabric and endpoints. This peering type uses loopbacks to maintain stable sessions. It provides granular control and visibility of host-level routing, helping you manage traffic flows and policies at the network edge.

Ensure these configurations exist prior to configuring a BGP peer from host interfaces:

the VRF where you want to add a BGP peer
a logical network with a Switch Virtual Interface (SVI) on the VRF
a loopback interface on a switch to host the BGP session
ports assigned with the host role, and
port VLAN membership for the logical network.

Step 1	Navigate to the BGP peers area for a specific route table (VRF). Choose Fabrics, then click the fabric you want to configure. In the Logical Networks area, click Route tables (VRF). In the All route tables (VRFs) table, click the route table name where you will configure a BGP peer. In the Configurations area, click BGP peers.
Step 2	Enter the VRF's local AS. In the BGP peers area, click the pencil icon and enter the VRF local AS. Click Save. By default, the VRF Local AS is used for the BGP peer unless you configure a local AS override. See 5.e.
Step 3	Choose + Add BGP peer > from host interface.
Step 4	Enter BGP peering details. For Peer name, enter a name for the new BGP peer. In the Peer address & interface area: Note For BGP peers that support both IPv4 and IPv6, you must create a separate BGP peer configuration for each address family. Enter the peer IP address (destination IP address of the remote BGP neighbor). Alternatively, you can enter a subset for passive listening. Enable Filter by containment if you want only host interfaces whose IP addresses or subnets are contained within the IP address or subnet specified in the Peer address & interface field. In the Select an available logical network area, select the interface that will be used to send and receive BGP messages to and from the remote peer. You can update the network prefix in Edit peer allow-list (optional) to limit the number of bits in the IP address that are used for the network. For example: 192.168.1.0/16. In the Select a loopback interface table, select the loopback interface. Specify the switch instances of the selected loopback interface to be used as the source for the BGP peering session. You may select multiple switch instances for redundancy, either establishing BGP sessions from all switches simultaneously or choosing a primary one.
Step 5	Configure the BGP peering session. For Type, select the BGP type: iBGP (internal BGP): This BGP type is used to exchange routing information inside a single Autonomous System (AS). Peers are within the same AS. eBGP (external BGP): This BGP type is used to exchange routing information between different autonomous systems (ASes). Peers are in different ASes. For Configuration, if the BGP type is eBGP, then select multi-hop. For Time to live (TTL), if the BGP type is eBGP and multi-hop, enter the number (2 to 255) of hops allowed for a peering session. For Peer AS, enter the AS number of the peer. Enter the Local AS override number. When you enter a local AS override number, the switch replaces the originating switch's AS number with the sending BGP switch's AS number. This action prevents the receiving switch from dropping packets sent from an originator that shares the same AS number as the receiver. By default, the VRF local AS is used unless you provide a new value.
Step 6	In the Policy area, select an Import policy and an Export policy from the drop-down list or keep the defaults. These policies are defined in Create a BGP import policy and Create a BGP export policy.
Step 7	In the Security area, select an authentication method and enter the credentials.
Step 8	Click Save.

View all BGP sessions and policies in a fabric

You can quickly find BGP peering sessions and policy information details for an entire fabric:

Peering sessions from routed interfaces (northbound peering): View these details to confirm that routed interfaces are successfully establishing BGP sessions with the fabric, and to verify their associated VLANs and specific switch locations. This view is crucial for ensuring dynamic route learning, confirming route advertisements, and troubleshooting connectivity with external networks.
Import policies: Use these details to understand and verify which routes are being accepted from BGP neighbors into the fabric's routing tables. This ensures that only desired routes are learned, preventing routing table pollution, enforcing security, and correctly directing incoming traffic.
Export policies: Use these details to understand and verify which routes the fabric is advertising to its BGP neighbors. This is crucial for controlling what information is shared externally, preventing accidental route leakage, and influencing how traffic is routed back into the fabric.

Step 1	Choose Fabrics, then click the fabric you want to see BGP peering information for.
Step 2	In the Attachments area, choose BGP.
Step 3	Select the type of information you want to see.

View BGP peer details

When you view BGP peer details, you can actively monitor several key aspects of your fabric’s BGP operations:

Peer details: Check whether each BGP session is established and running smoothly. This allows you to quickly verify connectivity with your BGP peers and troubleshoot any issues with session establishment.
Received routes: Review the routes your device learns from BGP peers. These routes include important attributes such as AS path, next hop, and local preference. By inspecting these details before import policies are applied, you can make sure your device receives and processes routes from neighbors correctly.
Advertised routes: Examine the routes your device advertises to its BGP peers. This helps you detect unusual or unauthorized routes. It enables you to spot potential route leaks or hijacks and control which routes your device shares to optimize traffic flow.

By actively reviewing these details, you can validate BGP connectivity, resolve routing issues, and maintain strong, effective routing policies across your fabric.

This procedure describes how to navigate to BGP peer details from the fabric level. To view BGP peers for a specific VRF, in the Logical Network area, choose Route tables (VRF) > vrf-name > BGP peers > bgp-peer-name.

Step 1	Choose Fabrics, then click the fabric you want to see BGP peering information for.
Step 2	In the Attachments area, click BGP.
Step 3	In the BGP peers table, click the peer name.
Step 4	Select the type of information you want to see: Peer details, Received routes, or Advertised routes.

Manage BGP peers

Follow these steps to edit or delete a BGP peer.

Step 1	Navigate to the route table of the BGP peer you want to edit or delete. Choose Fabrics, then click the fabric you want to configure. In the Logical Networks area, click Route tables (VRF). In the All route tables (VRFs) table, click the route table name that contains the BGP peer.
Step 2	Depending on how the BGP peer is configured, select from routed interface or from host interface.
Step 3	Edit the BGP peer. In the Action column, click for the BGP peer you want to edit. Edit BGP peering details. Click Save.
Step 4	Delete the BGP peer. In the Action column, click for the BGP peer you want to edit. Click Delete to confirm deletion.

Finish and commit your changes

Your changes are not applied to the fabric until you review, commit, and push them.