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:
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.
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.
Example:
The following example configures an ASN for a router:
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 can be configured either at the network-instance level or at the BGP level. If a router ID is configured at the BGP level, BGP uses it instead of the router ID configured at the network-instance level.
Example:
The following example configures a router ID at the network-instance level. BGP uses this router ID unless a different router ID is configured at the BGP level.
The following example configures a router ID at the BGP level. If this is configured, BGP uses it instead of the router ID configured at the network-instance level.
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.
Example:
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.
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.
Example:
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.
You can set the following options for handling the AS_PATH in received BGP routes:
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.
Example:
The following example configures the router to process received routes where its own ASN appears in the AS_PATH a maximum of 1 time:
Normally, two sites having the same ASN would not be able to reach each other directly since 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 towards the peer.
Example:
The following example configures the router to replace the ASN of the peer with its own ASN:
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 towards 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.
Examples:
The following example configures the router to delete private AS numbers (2-byte and 4-byte) from the advertised AS path towards all peers. This shortens the AS path.
The following example configures the router to replace private AS numbers with the local AS number used towards the peer. This keeps the AS path the same length.
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.
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.
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.
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.
Example:
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.
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.
Example:
All established BGP sessions are taken down when the BGP instance is disabled.
The following command deletes a BGP neighbor from the configuration.
Example:
The following command deletes the settings for a BGP peer group from the configuration.
Example:
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.
Examples:
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.
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.
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.
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.
Example:
The following example configures a keychain consisting of two keys.
The following example configures BGP to use the keys in the keychain above for protocol authentication: