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 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
To configure BGP shortcuts, you must configure the BGP protocol in the default network-instance with the allowed tunnel types for next-hop resolution. You must also define the tunnel resolution mode, which 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
The following example shows the BGP next-hop resolution configuration to allow
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
]
}
}
}
}
}
}
}