BGP Configuration Guide

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 shortest Autonomous system (AS) path and various other route attributes.

The RBFS supports the following BGP functions:

The statements and commands required to configure and verify the functioning of BGP features are described in this guide.

The address family configured at the instance level determines the types of address families that the virtual routing and forwarding (VRF) instance supports. At this level, you also configure the route target (RT), and the import and export policies for the instance. The forwarding daemon (FWDD) uses these configuration statements to create the VRF tables for each address family. Note that the route distinguisher (RD) is configured under the instance hierarchy level.

At the BGP protocol level, the address family configuration is used to determine which address families BGP supports. Multiple commands exist under this hierarchy level.

At the BGP peer group level, the address family configuration is used to determine which address families are needed to negotiate usage with the other BGP peers in the group.

There is no configuration under the peer hierarchy level. This statement establishes the peer, and all peers must be associated with a peer group. All of the parameters that apply to a peer are determined at the peer-group hierarchy level.

For example, this sequence configures IPv4 unicast support for the vrf1 instance:

BGP determines support for route redistribution based on address family. The selected address family can redistribute local interface routes, static routes, routes learned by IS-IS, and so on. Complete redistribute statement information and examples are included in other sections.

The example below shows route redistribution possibilities:

Some configuration statements start with edit and other start with set. These are called modes and commands in the RBFS.

The RBFS uses both modes (using “edit”) and commands (using “set”) to configure statements and determine parameters. All edits and sets are done through the configuration daemon CONFD. Their end result is similar, but the terms apply to slightly different configuration methods:

In a typical configuration session, you will use both methods:

You leave the edit mode with the exit command.

In many cases, you can configure the same feature from different levels of the configuration hierarchy. For example, you can set a BGP redistribution for direct addresses at the global, protocol, or address family level of the hierarchy.

The following three statements set redistribution of direct addresses for BGP. At the global level:

At the BGP protocol level:

At the address family level:

When committed without errors, all three result in the same configuration, displayed with show running-configuration:

Configure and log into the RBFS instance

edit instance <instance-name>

Configure the route distinguisher (RD) to define unique routes within an IPv4 network. Provider Edge (PE) routers use route distinguishers to identify which virtual private network (VPN) a packet belongs to in a PE network.

set instance <instance-name> rd <as-number | ipv4-address>:<rd-value>

Configure the route target (RT) to use to transfer routes between VRFs and VPNs. The RT identifies a subset of routes within the BGP VPNv3 unicast table that should be used in a VRF for a particular customer. You configure an RT for importing or exporting routes, or both.

set rt ( import | export } both ) target:<rt-value>

You must enable BGP inside an instance before you configure the BGP-specific instance options. When this enable command is successfully executed, the mode is changed from edit to set.

edit protocol bgp

You must configure the BGP address families if you are using route redistribution, load balancing, or other advanced features. By default, BGP neighbor sessions support IP4v unicast and multicast address families.

set protocol bgp address-family <address-family-afi> <address-family-safi>

In addition to the basic family support, you can also configure a number of options. These are mostly self-explanatory and only basic information is provided.

Supported options, detailed in sections below, are:

This statement is for temporary use until full routing policy support is configured. Use this statement to configure the number of prefixes that the BGP unicast session can download to the forwarding daemon (FWDD). BGP downloads the attribute information (community, extended community, and as-path) for prefixes to the Routing Information Base (RIB) and Forwarding Information Base (FIB) for advertising.

You can assign counters based on BGP prefixes and attributes on a per-input interface basis.

set protocol bgp address-family <address-family-afi> <address-family-safi> unicast download-count <count-number>

Apply the BGP routing policy for downloaded routes. The policy is defined elsewhere.

set protocol bgp address-family <address-family-afi> <address-family-safi> download-policy <policy-name>

Allow load sharing among the configured number of multiple Exterior BGP (EBGP) and Internal BGP (IBGP) paths.

set protocol bgp address-family <address-family-afi> <address-family-safi> multipath <number-of-paths>

Enable the redistribution feature to dynamically inject routes from a certain protocol into the IP routing table.

set protocol bgp address-family <address-family-afi> <address-family-safi> redistribute <protocol>

By default, the forwarding table retains the VPN routes for all route targets when the roputing protocol process shuts down. If you disable this retention of route targets, the VPN routes are removed from the forwarding table when the routing protocol shuts down.

set protocol bgp address-family <address-family-afi> <address-family-safi> retain-route-target disable

The Segment Routing Global Block (SRGB) is the range of label values reserved for segment routing (SR). These values are assigned as segment identifiers (SIDs) to SR-enabled network nodes and have global significance throughout the routing domain.

You must specify the base starting value for the labels (a number greater than 15), a range for the labels, and an index within the label range.

set protocol bgp address-family <address-family-afi> labeled-unicast srgb base <base-value> range <range-value> index <index-value>

BGP route selection involves more than just adding routes to the BGP routing table and forwarding table. By default, BGP implementations provide their own criteria for selecting the “best route” based on the values of BGP attributes associated with the route. If the route selection process is not producing optimal routes within a routing domain, you can steer the BGP route selection process in a number of ways with the best route selection option.

set protocol bgp bestroute-selection <best-route-option>

Configure cluster ID to associate routers in a group within a BGP routing instance. Routers belong to the same cluster if they have the same cluster ID. The cluster ID is formatted as an IPv4 address.

set protocol bgp cluster-id <cluster-identifier>

Configure the domain name for this BGP routing instance.

set protocol bgp domain-name <domain-name>

By default, the BGP routing process enforces the First AS feature. This feature discards updates received from an eBGP peer if the peer does not list its own AS number as the first segment in the AS_PATH BGP attribute.

To disable the First AS feature and accept updates without the peer’s source AS matching the first AS in the AS_PATH attribute, configure the feature to disable the enforce First AS feature.

set protocol bgp enforce-first-as disable

Configure a host name for BGP to use.

set protocol bgp host-name <host-name>

Configure the local AS number in four-byte format for BGP to use.

set protocol bgp local-as <as4-number>

Configure the value to use as BGP local preference. You can use the local AS preference number to choose the exit path for an AS.

set protocol bgp local-preference <preference-number>

Configure the value to use as BGP Multi-Exit Discriminator (MED) value. When an AS has multiple links to another AS, the MED value is used to determine the exit to use to reach the other AS.

set protocol bgp out-metric <med-value>

Assign a protocol preference distance value to routes learned by eBGP, iBGP, or both.

set protocol bgp protocol-preference ( internal | external) <preference-value>

Configure the value used as the router ID.

set protocol bgp router-id <router-id>

Configure the timer value used to keep the router active.

set protocol bgp timer hold-time <seconds> keep-alive <seconds>

Configure the value for the type-of-service (DSCP) bits.

set protocol bgp type-of-service <tos-value>

Configure a name for a peer group of BGP routers. Neighbor peers with the same update policies can be grouped as peers (equals) to simplify the initial configuration and updates. Peers share the same policies such as route maps, distribution lists, filter lists, update source, and so on, so peer groups only need one configuration statement for these values.

set protocol bgp peer-group <peer-group-name> ( address-family <address-family-afi> | any-as | ebgp-multihop <hop-count> | link-local-nexthop-only | local-as <as-number> | remote-as <as-number>)

You must configure the BGP address families for a peer-group if you are using route redistribution, load balancing, or other advanced features. Note: The advanced features are NOT configured here, but under the BGP instance. By default, BGP neighbor sessions support IP4v unicast and multicast address families.

set protocol bgp peer-group <peer-group-name> address-family <address-family-afi> <address-family-safi> [ options ]

Configure parameters for a, IPv4 or IPv6 BGP peer. A BGP peer is a BGP router that has an active TCP connection to another BGP router. To establish point-to-point connections between peer autonomous systems (ASs) for eBGP or within the AS for iBGP, you configure a BGP session on an interface. When you configure a BGP peer, the configuration adds the IP address of the peer in the specified autonomous system to the multiprotocol BGP (mBPG) neighbor table maintained in the local router.

set instance protocol bgp peer ( ipv4 | ipv6) peer-address <ip-address> ( update-source >ip-address> | peer-group <peer-group-name> | interface <interface-name> )

There are three main peer types to configure:

Each type has a general peer configuration format associated with it: * (IPv4 peer) set instance protocol bgp peer ipv4 peer-address <ipv4-address> update-source <ipv4-address> peer-group <group-name> * (IPv6 peer) set instance protocol bgp peer ipv6 peer-address <ipv6-address> update-source <ipv6-address> peer-group <group-name> * (IPv6 link-local dynamic peer) set instance protocol bgp peer interface <interface-name> peer-group <group-name> Note that IP6v link-local peers configure the interface. The following examples configure a peer of each type.

Display information about the BGP routing information base local (rib-local) table for an address family. The rib-local table is used to determine entries for the forwarding table.

show bgp rib <afi> <safi>

Display information summary about the BGP routes downloaded to the Forwarding Information Base (FIB) table.

show bgp rib <afi> <safi>

Display information summary about the BGP routes in the peer group table that will be sent to peers from the Routing Information Base output (RIB-out) table.

show bgp rib <peer-group-name> <afi> <safi>

Display information summary about the BGP peers.

show bgp peer ( instance <instance-name> )

Display detailed information about the BGP peers.

show bgp peer <peer-ip> detail ( instance <instance-name> )

Display information summary about the RIB-in table and a peer.

show bgp peer <peer-ip> rib-in <afi> <safi>

The main job of network nodes like routers is to maintain information about “what networks are where?” and also about the links between the routers. The network nodes route traffic from one to another so packets are always making progress toward a destination (that is, there are no loops or black holes). Routers use routing protocols to share their knowledge of the network topology and interfaces so that all parts of the networks are reachable, even if some links and routers are not working properly.

However, it is also the job of the network nodes to filter or modify routing information as it is advertised from router to router in the network. This filtering is needed so that a simple edge router with a local and remote interface does not have to carry a core routing table with hundreds of thousands of entries. The modification of the free flow of routing information around the network is known as establishing a routing policy for the router. A routing policy determines which routing updates are accepted by the router, which properties should be changed, and which routes should be advertised to other routers.

Routing policies can be applied to any routing protocol, internal to an AS (an IGP) or not (an EGP). Nevertheless, the most critical routing protocol for applied routing policy is BGP. Because BGP comes in IGP (iBGP) and EGP (eBGP) forms, BGP information potentially goes everywhere in the network. To control this flow, which might overwhelm smaller devices, BGP routes are carefully filtered before and during acceptance, modification, and advertisement.

There is no standard for routing policy implementation. Therefore, each hardware or software vendor is free to create their own implementation of features and goals. RtBrick supports extensive options for policies. This document contains basic examples that can easily be extended to cover other situations.

RtBrick supports attaching a BGP routing policy at two levels:

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.

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 filters, but for the instance as a whole.

An import policy, when applied to an address family at the instance level, examines all incoming routes before accepting the information for the global VPN or other instance level, but only for that address family.

An export policy, when applied to an address family at the instance level, examines all outgoing routes before sending the information from the global VPN or other instance level, but only for that address family.

There are three types of routing policy in this implementation:

Do not be confused by the use of the terms “filter” and “policy” as specific types of routing policy. Instead of these terms referring to generic route filtering and application of a routing policy, RtBrick uses these terms as specific forms of an overall approach to BGP policy and routing.

Here are some examples of useful routing policies for BGP. In some cases, only two steps are required, for a route filter and import or export policy application: configure the filter policy and apply where needed. On others, three or even four steps are needed: configure the filter policy, then the route policy, then the route map, and finally, apply the routing policy where needed. This section gives examples of each

These examples show only the basics of the complete application of routing policy. Almost all BGP attributes can be used, along with many possible keywords. The current list is as follows:

©Copyright 2020 RtBrick, Inc. All rights reserved. The information contained herein is subject to change without notice. The trademarks, logos and service marks ("Marks") displayed in this documentation are the property of RtBrick in the United States and other countries. Use of the Marks are subject to RtBrick’s Term of Use Policy, available at https://www.rtbrick.com/privacy. Use of marks belonging to other parties is for informational purposes only.