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 nexthop 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 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 behaviour 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 instance or VRF table.

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 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:

  1. 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 learnt 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).

  2. 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 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 the set local-preference value.

  3. Prefer the route with the shortest AS path, if no route was originated. If there is no AS_PATH attribute, then it is assumed to be of length 0. A single AS_SET is considered to be a length of 1.

  4. 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 and Incomplete. The lowest value is IGP and the highest value is Incomplete.

  5. 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. This behavior can be changed using the always-compare-med command. By default, the always-compare-med command is enabled. This command allows the MED values to be compared even if they are learned from different ASs. 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.)

  6. Prefer external BGP learned routes over internal BGP routes at this point after comparing the route type (internal BGP and external BGP).

  7. Prefer the path whose next hop is resolved through the IGP route with the lowest metric.

  8. Prefer the length with a shorter CLUSTER length path. If the CLUSTER attribute is not present, the length is assumed to be 0.

  9. 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.

  10. 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.

  11. 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 the AS-SEQUENCE attribute.

  • The paths which are marked as Received-only.