BGP Overview
BGP is a standard exterior gateway protocol (EGP) supported by RtBrick. BGP is considered a “Path Vector” routing protocol and maintains a separate routing table based on the shortest Autonomous System (AS) path and various other route attributes.
Supported BGP Standards
RFC Number | Description |
---|---|
RFC 2545 |
Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing |
RFC 2918 |
Route Refresh Capability for BGP-4 |
RFC 4271 |
A Border Gateway Protocol 4 (BGP-4) |
RFC 4364 |
BGP/MPLS IP Virtual Private Networks (VPNs) |
RFC 4456 |
BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) |
RFC 4486 |
Subcodes for BGP Cease Notification Message |
RFC 4760 |
Multiprotocol Extensions for BGP-4 |
RFC 5492 |
Capabilities Advertisement with BGP-4 |
RFC 6793 |
BGP Support for Four-Octet Autonomous System (AS) Number Space |
RFC 6608 |
Subcodes for BGP Finite State Machine Error |
RFC 6774 |
Distribution of Diverse BGP Paths [Partial Support] |
RFC and draft compliance are partial except as specified. |
Supported Platforms
Not all features are necessarily supported on each hardware platform. Refer to the Platform Guide for the features and the sub-features that are or are not supported by each platform.
Supported BGP Features
The RBFS supports the following BGP functions:
-
Basic BGP Protocol
-
Multiprotocol extension for BGP
-
Multipath for iBGP and eBGP
-
Four-byte AS numbers
-
Nexthop Self or next-hop unchanged
-
Fast external-failover
-
Route reflection
-
MD5 Authentication
-
Route Refresh
-
Advanced route refresh
-
Route redistribution
-
Multihop EBGP
-
Route selection flexibility (always compare MED, ignore AS Path, and so on)
-
Add path
-
Hostname/Domain name
-
Dynamic peers
-
Community, Extended Community, and Large Community support
-
6PE Support
The statements and commands required to configure and verify the functioning of BGP features are described in this guide.
MD5 Authentication
BGP supports the authentication mechanism using the Message Digest 5 (MD5) algorithm. When authentication is enabled, any Transmission Control Protocol (TCP) segment belonging to BGP exchanged between the peers is verified and accepted only if authentication is successful. For authentication to be successful, both peers must be configured with the same password. If authentication fails, the BGP neighbor relationship is not established.
IPv6 Provider Edge (6PE)
The Provider Edge (6PE) solution enables IPv6 communication over the MPLS IPv4 core network. IPv6 reachability information is associated with a label and transferred through MP-BGP(AFI: 2 SAFI:4). IPv4 mapped IPv6 address is used to encode the next-hop information. The edge nodes in the MPLS IPv4 core have to support both IPv4 and IPv6. The IPv6 Labeled Unicast routes received from the 6PE peer is considered as IPv6 unicast routes and installed in IPv6 Unicast FIB. The received Label is attached to the IPv6 data traffic at the Ingress node and tunneled through an MPLS tunnel(SR) to the egress node, the label identifies the IPv6 traffic, and the egress node would POP the label and forward the ipv6 traffic towards the destination.
Policies
The Role of a Routing Policy
Routing Policies are the rules that allow you to control and modify the default behavior of the routing protocols such as BGP and IS-IS. To use routing policies, you configure policies and then apply policies to peer groups or instances.
Attachment Points
Policies are useful when they are applied to routes, for which they need to be made known to routing protocols. In BGP, for example, there are several situations where policies can be used, the most common of these is defining import and export policy. The policy attachment point is the point in which an association is formed between a specific protocol entity, in this case, a BGP neighbor, and a specific named policy.
RtBrick supports attaching a BGP routing policy at two levels:
-
Peer group address-family level
-
Instance address-family level
In each case, you can apply the policy as an import or export policy and filter. As expected, import filters determine which routing updates are accepted and export filters determine which routes are advertised to other peers.
Policy Processing
An import policy, when applied to an address family at the peer group level, examines all incoming routes from all BGP peers in the peer group, but only for that address family.
An export policy, when applied to an address family at the peer group level, examines all outgoing routes to all BGP peers in the peer group, but only for that address family.
At the instance level, routing policies that are applied to an address family can work as import or export policies, but for the instances as a whole.
An import policy, when applied to an address family at the instance level, examines all incoming routes before accepting the information only from global or default tables to other instances or VRF tables.
An export policy, when applied to an address family at the instance level, examines all outgoing routes before sending the information from the VRF to global, and then to the VPN table (default).
BGP Communities
BGP communities are a way to tag routes with additional information that can be used for routing decisions and routing policies. A BGP community is a collection of destinations that share a common property. It allows you to apply actions to that group of destinations as a whole, rather than to each member individually. BGP communities are used to provide an additional capability to tag routes and thereby, modify BGP routing policies.
Communities can influence routing decisions such as accept, reject, preference, and redistribution. RBFS allows various operations such as appending, modifying, or deleting communities as the route travels from one router to another. A BGP community is an optional attribute that can be tagged with a route. The AS path attribute contains community information, which is used to identify community members. It allows for route manipulation without requiring multiple route filters.
RBFS supports three types of BGP communities for implementing complex routing policies and effectively controlling traffic across diverse and large-scale networks.
Standard Communities
These are used to control routing policies and are represented by a 32-bit number. They include well-known Communities such as no-export, no-advertise, and so on.
Extended Communities
Extended Communities provide functionalities beyond what standard communities offer. They are represented by 64-bit number and are displayed as two 32-bit numbers. They include additional fields such as type and sub-type, providing more granularity and the ability to carry additional information. Types: These include route targets, route origin, and other specialized community types that extend.
Large Communities
Represented as a 96-bit number, large communities consist of three 32-bit numbers separated by colons (for example, 64512:100:200). They provide space for tagging routes with extensive information and are easier to use in global policies. Large communities are used in large-scale deployments due to the larger addressing space.
Support for Allow As In
The Allow AS In feature enables BGP routers to receive and process routes even if the routes carry the router’s autonomous system number in the 'AS-Path' attribute. Usually, a BGP router discards routes if the ‘AS-Path’ attribute contains its autonomous system number to prevent loops. However, with the "Allow AS In" feature, such routes can be accepted and routed to the destination without being rejected. You can specify the allow-as-in option value in the peer configuration. For example, if you specify the value ‘5’, the router accepts BGP routes that contain its own AS number (in the AS path) up to 5 times.
BGP Best Path Selection Algorithm
BGP routers typically receive multiple paths to the same destination. A BGP router forms a neighbor relationship by connecting to its neighbors and exchanging the routes, once the connection is established. The BGP route selection algorithm decides which is the best path to install in the IP routing table and to use for traffic forwarding.
BGP Best Path Selection Algorithm
The algorithm eliminates all routes whose next hop is not reachable. Circular route resolution is considered for route resolution.
The algorithm for determining all the routes that have the same route prefix is as follows:
-
The first route selection is performed based on the lowest route source. Route from the local route source is always preferred over the received route. For example, when there is the same prefix route that is redistributed and received from a neighbor, the local (redistributed route) is always preferred. The locally learned route is preferred over the locally crossed or remote crossed route (in the case of VPN, a route might be learned locally in the VRF. The same prefix might be received from the remote as VPNv4. After importing into the VRF routing table, a locally learned route is preferred over the remote local crossed route).
-
Prefer the path with the highest local preference if the route source is the same. If a path does not have a local preference attribute (for example, it is received from an eBGP peer), then it is considered to have the local preference assigned in the given BGP instance. The
show bgp summary
command shows the local preference assigned in the system. This can be changed using theset local-preference
value. -
Prefer the route with the shortest AS path, if no route originated. If there is no
AS_PATH
attribute, then it is assumed to be of length 0. A singleAS_SET
is considered to be a length of1
. -
Prefer the path with the lowest origin type, if the AS path length is the same as all the paths. The available three values include
IGP
,EGP
andIncomplete
. The lowest value isIGP
and the highest value isIncomplete
. -
Prefer the path with the lowest Multi Exit Discriminator (MED), if the original codes are the same. (By default, MED values are only compared when routes are learned from the same AS. Routes without MED values are treated as if they have a MED value of
0
, which is the lowest and, therefore, always the most preferred value.)
-
Prefer external BGP learned routes over internal BGP routes at this point after comparing the route type (internal BGP and external BGP).
-
Prefer the path whose next hop is resolved through the IGP route with the lowest metric.
-
Prefer the length with a shorter CLUSTER length path. If the CLUSTER attribute is not present, the length is assumed to be
0
. -
Prefer the path from the peer with the lowest router ID. For any path with an originator ID attribute, substitute the originator ID for the router ID during router ID comparison.
-
Prefer the lowest peer IP address as the tie-breaker, if the router-id is the same for both sessions. This is for BGP to make route selections in case of multiple peerings are used between the same routers.
-
If add path is enabled, then the same peer might advertise multiple paths for the same prefix. The path with a lower send path ID is preferred.
The BGP best path selection algorithm also provides a mechanism to discard paths that are not considered candidates for the best path. The following paths are discarded:
-
The paths for which next-hops are not resolved.
-
The paths originated from an eBGP neighbor if a local AS is shown in the
AS-PATH
attribute. -
If the BGP
enforce-first-as
attribute is enabled and the update does not contain the AS number of the neighbor as the first AS number in theAS-SEQUENCE
attribute. -
The paths which are marked as
Received-only
.