BGP
Border Gateway Protocol (BGP) is an inter-AS routing protocol. An AS (autonomous system) is a network or a group of routers logically organized and controlled by common network administration. BGP enables routers to exchange network reachability information, including information about other ASs that traffic must traverse to reach other routers in other ASs.
ASs share routing information, such as routes to each destination and information about the route or AS path, with other ASs using BGP. Routing tables contain lists of known routers, reachable addresses, and associated path cost metrics for each router. BGP uses the information and path attributes to compile a network topology.
To set up BGP routing, participating routers must have BGP enabled, and be assigned to an AS, and the neighbor (peer) relationships must be specified. A router typically belongs to only one AS.
This section describes the minimal configuration necessary to set up BGP on SR Linux. This includes the following:
-
Global BGP configuration, including specifying the autonomous system number (ASN) of the router, as well as the router ID.
-
BGP peer group configuration, which specifies settings that are applied to BGP neighbor routers in the peer group.
-
BGP neighbor configuration, which specifies the peer group to which each BGP neighbor belongs, as well as settings specific to the neighbor, including the AS to which the router is peered.
For information about all other BGP settings, see the SR Linux online help, as well as the SR Linux Advanced Solutions Guide and the SR Linux Data Model Reference.
BGP global configuration
Global BGP configuration includes specifying the autonomous system number (ASN) of the router and the router ID.
Configuring an ASN
An autonomous system number (ASN) is a globally unique value that associates a router to a specific AS. Each router participating in BGP must have an ASN specified.
The following example configures an ASN for a router:
--{ * candidate shared default }--[ ]--
# info network-instance default
network-instance default {
protocols {
bgp {
autonomous-system 65002
}
}
}
Configuring the router ID
The router ID, expressed like an IP address, uniquely identifies the router and indicates the origin of a packet for routing information exchanged between autonomous systems. The router ID is configured at the BGP level.
The following example configures a router ID:
--{ * candidate shared default }--[ ]--
# info network-instance default
network-instance default {
protocols {
bgp {
router-id 2.2.2.2
}
}
Configuring a BGP peer group
A BGP peer group is a collection of related BGP neighbors. The group name should be a descriptive name for the group.
All parameters configured for a peer group are inherited by each peer (neighbor) in the peer group, but a group parameter can be overridden for specific neighbors in the configuration of that neighbor.
The following example configures the administrative state and trace options for a BGP peer group. These settings apply to all of the BGP neighbors that are members of this group, unless specifically overridden in the neighbor configuration.
--{ * candidate shared default }--[ ]--
# info network-instance default
network-instance default {
protocols {
bgp {
group headquarters1 {
admin-state enable
traceoptions {
flag events {
}
flag graceful-restart {
}
}
}
}
Configuring BGP neighbors
After you configure a BGP group name and assign options, you can add neighbors within the same autonomous system to create internal BGP (iBGP) connections and/or neighbors in different autonomous systems to create external BGP (eBGP) peers. All parameters configured for the peer group to which the neighbor is assigned are applied to the neighbor, but a group parameter can be overridden on a specific neighbor basis.
The following example configures parameters for two BGP neighbors. The
peer-group parameter configures both nodes to use the
settings specified for the headquarters1 group. The group settings
apply unless they are specifically overridden in the neighbor configuration.
--{ * candidate shared default }--[ ]--
# info network-instance default
network-instance default {
protocols {
bgp {
neighbor 192.168.11.1 {
peer-group headquarters1
description "default network-instance bgp neighbor to Node A"
peer-as 65001
local-as 65002 {
}
multihop {
admin-state enable
maximum-hops 3
}
failure-detection {
enable-bfd true
fast-failover true
}
}
neighbor 192.168.13.2 {
peer-group headquarters1
description "default network-instance bgp neighbor to Node C"
peer-as 65003
local-as 65002 {
}
failure-detection {
enable-bfd true
fast-failover true
}
}
}
}
}
eBGP multihop
External BGP (eBGP) multihop can be used to form adjacencies when eBGP neighbors are not directly connected to each other; for example, when a non-BGP router is between the eBGP neighbors.
BGP TCP/IP packets sent toward an eBGP neighbor by default have a TTL value of 1. If the BGP TCP/IP packets need to pass through more than one router to reach their destination, the TTL decrements to 0, and the packets are dropped.
To prevent this, you can enable multihop for the eBGP neighbor and specify the maximum number of hops for BGP TCP/IP packets sent to the neighbor. This allows the eBGP neighbor to be indirectly connected by up to the specified number of hops.
When multihop is not enabled, the IP TTL for eBGP sessions is set to 1, and the IP TTL for iBGP sessions is set to 64. By enabling multihop and configuring the maximum number of hops to a neighbor, it allows an eBGP session to have multiple hops, and an iBGP session to have a single hop, if required.
If multihop is enabled and the maximum-hops parameter is configured for a BGP peer group, the settings are applied to the members of the group. If the multihop configuration for a neighbor is changed, the session with the neighbor must be disconnected and re-established for the change to take effect.
Configuring eBGP multihop
To configure eBGP multihop, you enable it for the eBGP neighbor, and specify a value for the maximum-hops parameter. Additionally, the next-hop to the neighbor must be configured so that the two systems can establish a BGP session.
The following example enables multihop for an eBGP neighbor. The maximum-hops parameter is set to 2, which increases the TTL for BGP TCP/IP packets sent toward the eBGP neighbor, allowing the neighbor to be indirectly connected by up to 2 hops.
--{ * candidate shared default }--[ ]--
# info network-instance default
network-instance default {
protocols {
bgp {
neighbor 192.168.11.1 {
multihop {
admin-state enable
maximum-hops 2
}
}
}
}
The following example configures a route to the next-hop toward the eBGP neighbor:
--{ * candidate shared default }--[ ]--
# info network-instance default static-routes
network-instance default {
static-routes {
route 192.168.11.0/24 {
next-hop-group static-ipv4-grp
}
}
}
--{ * candidate shared default }--[ ]--
# info network-instance default next-hop-groups group static-ipv4-grp
network-instance default {
next-hop-groups {
group static-ipv4-grp {
nexthop 1 {
ip-address 192.168.22.22
}
}
}
}AS path options
You can set the following options for handling the AS_PATH in received BGP routes:
-
Allow own AS – configures the router to process received routes when its own ASN appears in the AS_PATH.
-
Replace peer AS – configures the router to replace the ASN of the peer router in the AS_PATH with its own ASN.
-
Remove private AS path numbers – configures the router to either delete private AS numbers, shortening the AS path length, or replace private AS numbers with the local AS number used toward the peer, maintaining the AS path length.
Configuring allow-own-as
Normally, when the ASN of a router appears in the AS_PATH of received routes, it is considered a loop, and the routes are discarded. The allow-own-as option configures the router to process the received routes when its own ASN appears in the AS_PATH. Specifically, it configures the maximum number of times the global ASN of the router can appear in any received AS_PATH before it is considered a loop and considered invalid. Default is 0.
The following example configures the router to process received routes where its own ASN appears in the AS_PATH a maximum of 1 time:
--{ * candidate shared default }--[ ]--
# info network-instance default
network-instance default {
protocols {
bgp {
autonomous-system 65001
as-path-options {
allow-own-as 1
}
}
}
}
Configuring replace-peer-as
Normally, two sites having the same ASN would not be able to reach each other
directly because the receiving router would see its own ASN in the AS_PATH and
consider it a loop. To overcome this, you can configure the router to replace the
peer ASN in the AS_PATH with its own ASN. When the
replace-peer-as option is set to true, the
router replaces every occurrence of the peer AS number that is present in the
advertised AS_PATH with the local ASN used toward the peer.
The following example configures the router to replace the ASN of the peer with its own ASN:
--{ * candidate shared default }--[ ]--
# info network-instance default
network-instance default {
protocols {
bgp {
as-path-options {
replace-peer-as true
}
}
}
}
}
Configuring remove-private-as
You can configure how the router handles private AS numbers: either delete them, shortening the AS path length, or replace private AS numbers with the local AS number used toward the peer, which maintains the AS path length.
You can configure the router to delete or replace private AS numbers that appear before the first occurrence of a non-private ASN in the sequence of most recent ASNs in the AS path. You can also configure the router to ignore private AS numbers when they are the same as the peer ASN.
The following example configures the router to delete private AS numbers (2-byte and 4-byte) from the advertised AS path toward all peers. This shortens the AS path.
--{ * candidate shared default }--[ ]--
# info network-instance default
network-instance default {
protocols {
bgp {
as-path-options {
remove-private-as {
mode delete
}
}
}
}
}
}
The following example configures the router to replace private AS numbers with the local AS number used toward the peer. This keeps the AS path the same length.
--{ * candidate shared default }--[ ]--
# info network-instance default
network-instance default {
protocols {
bgp {
as-path-options {
remove-private-as {
mode replace
}
}
}
}
}
The following example configures the router to replace only private AS numbers that appear before the first occurrence of a non-private ASN in the sequence of most recent ASNs in the AS path.
--{ * candidate shared default }--[ ]--
# info network-instance default
network-instance default {
protocols {
bgp {
as-path-options {
remove-private-as {
mode replace
leading-only true
}
}
}
}
}
The following example configures the router to ignore private AS numbers (neither delete nor replace them) when they are the same as the peer AS number.
--{ * candidate shared default }--[ ]--
# info network-instance default
network-instance default {
protocols {
bgp {
as-path-options {
remove-private-as {
mode replace
ignore-peer-as true
}
}
}
}
}
Route reflection
In a standard iBGP configuration, all BGP speakers within an AS must have full BGP mesh to ensure that all externally learned routes are redistributed through the entire AS.
Configuring route reflection provides an alternative to the full BGP mesh requirement: instead of peering with all other iBGP routers in the network, each iBGP router only peers with a router configured as a route reflector.
An AS can be divided into multiple clusters, with each cluster containing at least one route reflector, which redistributes routes to the clients in the cluster. The clients within the cluster do not need to maintain a full peering mesh between each other. They only require a peering to the route reflectors in their cluster. The route reflectors must maintain a full peering mesh between all non-clients within the AS.
Configuring route reflection
To configure a route reflector, you assign it a cluster ID and specify which neighbors are clients and which are non-clients. Clients receive reflected routes, and non-clients are treated as a standard iBGP peer.
The following example configures the router to be a route reflector for two clients SRL-1 and SRL-2. The router is assigned cluster ID 0.0.0.1.
--{ * candidate shared default }--[ ]--
# info network-instance default
network-instance default {
protocols {
bgp {
route-reflector {
cluster-id 0.0.0.1
}
}
neighbor SRL-1 {
route-reflector {
cluster-id 0.0.0.1
client true
}
neighbor SRL-2 {
route-reflector {
cluster-id 0.0.0.1
client true
}
}
}
}
}
Graceful restart
Graceful restart allows a router whose control plane has temporarily stopped functioning because of a system failure or a software upgrade to return to service with minimal disruption to the network.
To do this, the router relies on neighbor routers, which have also been configured for graceful restart, to maintain forwarding state while the router restarts. These neighbor routers are known as helper routers. The helper routers and the restarting router continue forwarding traffic using the previously learned routing information from the restarting router. Other routers in the network are not notified about the restarting router, so network traffic is not disrupted.
When graceful restart is enabled on the SR Linux and its neighbor, the two routers exchange information about graceful restart capability, including the Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI) of the routes supported for graceful restart.
While the router restarts, the helper router marks the routes from the restarting router as stale, but continues to use them for traffic forwarding. When the BGP session is reestablished, the restarting router indicates to the helper router that it has restarted. The helper router then sends the restarting router any BGP RIB updates, followed by an End-of-RIB (EOR) marker indicating that the updates are complete. The restarting router then makes its own updates and sends them to the helper router, followed by an EOR marker.
Graceful restart is used in conjunction with the In-Service Software Upgrade (ISSU) feature, which can be used to upgrade 7220 IXR-D2 and D3 systems while maintaining non-stop forwarding. During the ISSU, a warm reboot brings down the control and management planes while the NOS reboots, and graceful restart maintains the forwarding state in peers. You can use a tools command to validate that the SR Linux and its peers support warm reboot, including graceful restart configuration. See the SR Linux Software Installation Guide for more information.
Configuring graceful restart
The following example enables graceful restart for the BGP instance. The SR Linux operates as a helper router for neighbor routers when they are restarting, assuming graceful restart is also enabled on the neighbors. Enabling graceful restart also indicates to the neighbors that they can serve as helper routers when the SR Linux itself is restarting.
When operating as a helper router, the SR Linux marks the routes from the restarting router as stale, but continues to use them for forwarding for a period of time while the neighbor router restarts. After this period expires, the SR Linux deletes the routes. The stale-routes-time parameter configures the amount of time in seconds the routes remain stale before they are deleted.
--{ * candidate shared default }--[ ]--
# info network-instance default
network-instance default {
protocols {
bgp {
graceful-restart {
admin-state enable
stale-routes-time 300
}
}
}
}
Following a restart, by default the system waits 600 seconds (10 minutes) to receive EOR markers from all helper routers for all address families that were up before the restart. After this time elapses, the system assumes convergence has occurred and sends its own EOR markers to its peers. You can configure the amount of time the system waits to receive EOR markers to be from 0 to 3,600 seconds.
For example, the following configures the amount of time the system waits to receive EOR markers to 270 seconds.
--{ * candidate shared default }--[ ]--
# info system warm-reboot
system {
warm-reboot {
bgp-max-wait 270
}
}
BGP unnumbered peering
In a typical large-scale data center using BGP, leaf and spine switches are interconnected in a Clos topology, and each device establishes a single-hop eBGP session with each of its physically connected peers. The sessions come up as eBGP because of the ASN allocation scheme; it is common practice to assign a unique ASN to every leaf switch (TOR) in a cluster and a different unique ASN to the set of spine switches to which those TORs are connected. The allocated ASNs are typically private ASNs in the range 4200000000 to 4294967294, although this is not always the case.
For this type of configuration, BGP unnumbered peering can be a useful solution. BGP unnumbered peering is the dynamic setup of one or more single-hop BGP sessions over a network segment that has no globally-unique IPv4 or IPv6 addresses. Each router connected to the network segment is assumed to have an IPv6-enabled interface to the network, and these interfaces have IPv6 link-local addresses that are typically auto-generated by each router from the interface MAC addresses.
How sessions are established using BGP unnumbered peering
The set of BGP speakers configured for BGP unnumbered peering on a network segment discover each other by sending and receiving ICMPv6 router advertisement (RA) messages.
Consider an example of Router A and Router B, which are both connected to an unnumbered interface and configured for BGP unnumbered dynamic session setup. The BGP session between the two routers is established in the following sequence:
- Router B sends an ICMPv6 RA message on its interface b1.
Assuming the RA message is unsolicited, the source IP address of this message is the link-local address of interface b1 (fe80::7efe:90ff:fefc:7ad8), and the destination IP address is the all-nodes multicast address.
- Asynchronously, Router A sends an ICMPv6 RA message on its interface a1.
The source IP address is the link-local address of interface a1 (fe80::7efe:90ff:fefc:7bd8), and the destination IP address is the all-nodes multicast address.
- Router A receives the RA message on interface a1, and the software process responsible for ICMPv6 relays the information to BGP, because in the BGP configuration, a1 is a subinterface that is configured as a dynamic neighbor interface; that is, added to the BGP dynamic-neighbors interface list.
- BGP checks if it already has a BGP session with fe80::7efe:90ff:fefc:7ad8.
-
If BGP already has this session and it is up, or BGP is in the process of establishing this session, then the new information is a no-op. Possibly Router B started the same process moments before Router A.
-
If BGP does not have a session with this link-local address, then a new TCP connection is initiated toward fe80::7efe:90ff:fefc:7ad8.
-
- When the TCP connection is established, the BGP OPEN message sent by Router A encodes a local-AS and other capabilities that come from the configuration of the peer-group associated with interface a1.
- Router A receives a BGP OPEN message from Router B and accepts that OPEN
message, proceeding to move toward the BGP established state, if the OPEN
message encodes an acceptable peer AS number (in one of the
allowed-peer-asranges configured for interface a1). The address families supported by the session are based on the usual MP-BGP negotiation.
BGP dynamic-neighbors interface list
To enable dynamic peering, you add subinterfaces to the BGP dynamic-neighbors interface list in the SR Linux configuration.
- BGP automatically accepts incoming BGP connections to the IPv6 link-local
address of that subinterface, subject to the configured
max-sessionslimit for the subinterface.For the connection to be accepted, the source address must be an IPv6 link-local address (that may or may not also be a defined neighbor address), and the reported ASN of the peer must match relevant configuration. If the source address does not match a configured neighbor address, the session is set up according to the peer-group associated with the subinterface, not the peer-group associated with the dynamic-neighbors accept match-prefix entry matching the source IPv6 link-local address if a matching entry exists.
- BGP registers for IPv6 RA messages on the subinterface. Whenever the source
of one of these RA messages matches an IPv6 link-local address for which
there is currently no established BGP session, the system attempts to create
a BGP session to that address, as long as this does not exceed the
configured
max-sessionslimit for the subinterface. The session is set up according to the configuredpeer-groupassociated with the subinterface.
- Changes to the
allowed-peer-asranges associated with the subinterface are a no-op until the next time BGP attempts to establish the sessions. - Non-arrival of expected ICMPv6 RA messages on the subinterface are a no-op, and do not trigger teardown of associated sessions.
- Existing triggers for tearing down a session apply as normal (for example, hold-timer expiration, BFD timeout, clear bgp neighbor commands, and so on).
- If the link-local address of a dynamic peer is configured as a static neighbor address, the dynamic session is immediately torn down and replaced by the static session.
When a subinterface is deleted from the dynamic-neighbors interface list, all dynamic sessions associated with that subinterface (excluding sessions set up by static configuration of the neighbor) are torn down immediately.
A BGP session that was previously established on an unnumbered interface and subsequently torn down can only be re-established if the subinterface is configured in the dynamic-neighbors interface list and a recent ICMPv6 RA message is received.
Configuration overrides for dynamic peers on unnumbered interfaces
When a dynamic BGP session is initiated or accepted on an interface that is tied to a peer-group, most of the parameters relevant to that session come from the configuration of that peer-group, with the following exceptions:
multihop maximum-hopsis always 1 (for both eBGP and iBGP peers).transport local-addressis always the link-local address of the specified interface.next-hop-selfis alwaystrue. The neighbor is not presumed to have reachability to off-link destinations.transport passive-modeis alwaysfalse. BGP always initiates a connection when informed by ICMPv6, unless it already has a connection.ipv4-unicast receive-ipv6-next-hopsis alwaysenabled.ipv4-unicast advertise-ipv6-next-hopsandevpn advertise-ipv6-next-hopsare alwaysenabled.graceful-restart admin-stateis alwaysdisabled, meaning dynamic-peers do not help during a warm reboot, and there is no helper support for dynamic peers that restart.
Peer AS Validation for dynamic peers on unnumbered interfaces
When a BGP OPEN message is received from an unnumbered dynamic neighbor, the reported AS number of the peer is checked to determine if it is acceptable to allow the peering to proceed.
For a dynamic session associated with a subinterface, the peer AS is acceptable only
if it matches one of the allowed-peer-as elements of the
dynamic-neighbors interface list entry for the subinterface, and if the peer AS is
not equal to the local AS (implying an iBGP session; in the current release, iBGP is
not supported for BGP unnumbered peering).
Configuring BGP unnumbered peering
To configure BGP unnumbered peering, you add subinterfaces to the BGP dynamic-neighbors interface list, and specify the peer autonomous system numbers from which incoming TCP connections to the BGP well-known port are accepted.
The following example adds a subinterface to the BGP dynamic-neighbors interface list.
--{ candidate shared default }--[ ]--
# info network-instance default protocols bgp dynamic-neighbors interface ethernet-1/1.1
network-instance default {
protocols {
bgp {
dynamic-neighbors {
interface ethernet-1/1.1 {
peer-group bgp_peer_group_0
allowed-peer-as [
4294967200
]
}
}
}
}
}
In this example, subinterface ethernet-1/1.1 is added to the BGP
dynamic-neighbors interface list. This subinterface must be enabled for IPv6 and
configured to accept and send IPv6 RA messages. It does not require any IPv4
addresses or global-unicast IPv6 addresses.
Incoming TCP connections to port 179 received on this subinterface that are sourced from an IPv6 link-local address and destined for the IPv6 link local address of this subinterface are automatically accepted. IPv6 RA messages received on this subinterface automatically trigger BGP session setup toward the sender of these messages, if there is not already an established BGP session.
Peer group bgp_peer_group_0 is associated with dynamic BGP neighbors
on this subinterface. Parameters configured for this peer-group are used for
establishing the dynamic BGP session, with the exceptions described in Configuration overrides for dynamic peers on unnumbered interfaces.
ASN 4294967200 is configured as an allowed peer AS for dynamic BGP neighbors on this subinterface. If the BGP OPEN message from a peer on this subinterface contains a MyAS number that is not an allowed peer AS, then a NOTIFICATION is sent to the peer with the indication Bad Peer AS.
BGP configuration management
Managing the BGP configuration on SR Linux can include the following tasks:
- Modifying an AS number
- Deleting a BGP neighbor from the configuration
- Deleting a BGP group
- Resetting BGP peer connections
Modifying an ASN
You can modify the ASN on the router, but the new ASN does not take effect until the BGP instance is restarted, either by administratively disabling/enabling the BGP instance, or by rebooting the system with the new configuration.
--{ * candidate shared default }--[ network-instance default ]--
# protocols bgp autonomous-system 95002
# protocols bgp admin-state disable
# protocols bgp admin-state enable
All established BGP sessions are taken down when the BGP instance is disabled.
Deleting a neighbor
Use the delete command to delete a BGP neighbor from the configuration.
--{ * candidate shared default }--[ network-instance default ]--
# delete protocols bgp neighbor 192.168.11.1Deleting a group
Use the delete command to delete the settings for a BGP peer group from the configuration.
--{ * candidate shared default }--[ network-instance default ]--
# delete protocols bgp group headquarters1Resetting BGP peer connections
To refresh the connections between BGP neighbors, you can issue a hard or soft reset. A hard-reset tears down the TCP connections and returns to IDLE state. A soft-reset sends route-refresh messages to each peer. The hard or soft reset can be issued to a specific peer, to peers in a specific peer-group, or to peers with a specific ASN.
The following command hard-resets the connections to the BGP neighbors in a peer group that have a specified ASN. The hard-reset applies both to configured peers and dynamic peers.
# tools network-instance default protocols bgp group headquarters1 reset-peer peer-as 95002
/network-instance[name=default]/protocols/bgp/group[group-name=headquarters1]:
Successfully executed the tools clear command.
The following command soft-resets the connection to BGP neighbors that have a specified ASN. The soft-reset applies both to configured peers and dynamic peers.
# tools network-instance default protocols bgp soft-clear peer-as 95002
/network-instance[name=default]/protocols/bgp:
Successfully executed the tools clear command.
Protocol authentication
On the SR Linux, authentication of routing control messages for BGP, as well as other protocols such as LDP and IS-IS, is done using shared keys.
Message authentication between two routers involves sharing knowledge of a secret key and a cryptographic algorithm, such as MD5. This secret key, together with the message data, are used to generate a message digest. The message digest is added to each message transmitted by the sender and validated by the receiver, with the expectation that only a sender in possession of the secret key and algorithm details could generate the same message digest computed by the receiver of the message.
To limit exposure in the event a key is compromised, the secret key is changed at regular intervals using keys configured in a keychain. A keychain defines a list of one or more keys; each key is associated with a secret string, an algorithm identifier, and a start time.
When a protocol references a keychain for securing its messages with a set of peers, it uses the active key in the keychain with the most recent start time to generate the message digest in its sent messages, and it drops every received message that does not have an acceptable message digest.
Configuring protocol authentication
To configure protocol authentication, you configure an authentication keychain at the system level and configure a protocol to use the keychain. All protocol authentication is done using keychains. If a protocol requires authentication with a single neighbor using a single key, the key is configured within a keychain, and the protocol references the keychain.
The following example configures a keychain consisting of two keys.
--{ candidate shared default }--[ ]--
# info system authentication
system {
authentication {
keychain k1 {
tolerance 10 {
key 1 {
admin-state enable
algorithm md5
authentication-key ZcvSElJzJx/wBZ9biCt
start-time 2020-05-26T10:21:01Z
}
key 2 {
admin-state enable
algorithm md5
authentication-key e7xdKlYO2DOm7v3IJv
start-time 2020-05-10T10:21:01Z
}
}
}
The following example configures BGP to use the keys in the keychain above for protocol authentication:
--{ candidate shared default }--[ ]--
# info network-instance default protocols bgp authentication
network-instance default {
protocols {
bgp {
authentication {
keychain k1
}
}
}
}
}
BGP shortcuts
With BGP shortcuts, SR Linux can include LDP LSPs or segment routing (SR-ISIS) tunnels in the BGP algorithm calculations. In this case, tunnels operate as logical interfaces directly connected to remote nodes in the network. Because the BGP algorithm treats the tunnels in the same way as a physical interface (being a potential output interface), the algorithm can select a destination node together with an output tunnel to resolve the next-hop, using the tunnel as a shortcut through the network to the destination.
BGP next-hop resolution describes the procedures that BGP uses to resolve the next-hop address of each BGP RIB-In that forms part of a BGP route. The following table defines BGP RIB-In and BGP route in the context of BGP next-hop resolution.
| BGP Term | Definition |
|---|---|
| BGP RIB-In | One of the following:
|
| BGP route | A route submitted by BGP to the fib_mgr that resulted from the grouping of one or more BGP RIB-Ins. (Multiple BGP RIB-Ins per route describes a multipath scenario.) |
With BGP shortcuts enabled, next-hop resolution determines whether to use a local interface or a tunnel to resolve the BGP next-hop.
Tunnel resolution mode
As part of the configuration for BGP shortcuts, you must define the tunnel-resolution mode (prefer/required/disabled). This mode determines the order of preference and fallback of using tunnels in the tunnel table to resolve the next-hop instead of using routes in the FIB, as described in the following sections.
Next-Hop Resolution of IPv4-Unicast RIB-Ins with IPv4 next-hop
The following table describes the next-hop resolution steps for IPv4-Unicast RIB-Ins with IPv4 next-hops, depending on the specified tunnel resolution mode.
| Tunnel Resolution Mode | Next-hop resolution steps in BGP |
|---|---|
| prefer |
|
| require | Perform TTM lookup only, as described in 1
above. If there is no matching tunnel, the RIB-IN is unresolved. |
| disabled | Perform FIB lookup only, as described in 2 above. |
Next-Hop Resolution of IPv4-Unicast and IPv6-Unicast RIB-Ins with IPv6 next-hop
If the next-hop address for the IPv4-Unicast RIB-In is an IPv6 address, the next-hop is resolved by the longest prefix match IPv6 route in the FIB. This is the only option because there are no IPv6 tunnels in the TTM. The same logic applies to BGP RIB-Ins with IPv6-unicast NLRI address family as they can only have an IPv6 next-hop address. The next-hop resolution logic is the same as the FIB lookup described in the preceding table.
Configuring BGP shortcuts over segment routing
To configure BGP shortcuts:
-
In the default network-instance, define the tunnel-resolution mode for the BGP
protocol.
This setting determines the order of preference and the fallback when using tunnels in the tunnel table instead of routes in the FIB. Available options are as follows:
- require
requires tunnel table lookup instead of FIB lookup
- prefer
prefers tunnel table lookup over FIB lookup
- disabled (default)
performs FIB lookup only
- require
- Set the allowed tunnel types for next-hop resolution.
Configure IPv4 BGP shortcuts
The following example shows the BGP next-hop resolution configuration to allow
IPv4
SR-ISIS tunnels, with the tunnel mode set to
prefer.
--{ * candidate shared default }--[ ]--
# info network-instance default protocols bgp ipv4-unicast next-hop-resolution ipv4-next-hops tunnel-resolution
network-instance default {
protocols {
bgp {
ipv4-unicast {
next-hop-resolution {
ipv4-next-hops {
tunnel-resolution {
mode prefer
allowed-tunnel-types [
sr-isis
]
}
}
}
}
}
}
}
Configure IPv6 BGP shortcuts
The following example shows the BGP next-hop resolution configuration to allow IPv6
SR-ISIS tunnels, with the tunnel mode set to prefer.
--{ * candidate shared default }--[ ]--
# info network-instance default protocols bgp ipv4-unicast next-hop-resolution ipv4-next-hops tunnel-resolution
network-instance default {
protocols {
bgp {
ipv6-unicast {
next-hop-resolution {
ipv6-next-hops {
tunnel-resolution {
mode prefer
allowed-tunnel-types [
sr-isis
]
}
}
}
}
}
}
}