External BGP Configuration

Before you start the hands-on part of this module, you should load the appropriate configuration and verify that the testbed is up and running by executing the corresponding robot file:

The RBFS implementation of BGP uses two daemons for handling BGP-related processing:

Before configuring a BGP peer, we will configure a few general parameters that define the local BGP speaker:

All of these options are configured using the set instance <instance> protocol bgp hierarchy.

The correct setting can be verified using the command

Now that we have configured some local parameters, we want to setup external BGP peerings to neighboring routers. We use the following setup:

The BGP peers must manually be defined as there is no auto-detection of neighbors.

BGP has many different attributes that can be associated with a BGP peer, e.g.

Depending on your peering rules, a lot of these settings are shared by multiple BGP peers. Thus, BGP defines the concept of BGP Peer Groups, which is a template of BGP settings that is defined once and then applied to one or more BGP peers. The BGP peer groups are defined in the set instance <instance> protocol bgp peer-group <pgname>.

Let’s have another look at the information that RBFS provides on the BGP peer. For sake of clarity, we will split the output in several chunks:

In the above output, the second line shows the current status of the BGP Finite State Machine (Established). Additionally, information about the latest transition is provided. In our example, a BGP NOTIFICATION message was sent or received. NOTIFICATION messages contain an error code and a sub-error code to provide additional information. In this particular example, a NOTIFICATION with error code CEASE was generated, which is sent when a BGP peer closes its BGP connection without a fatal error. The error subcodes usually contain more details. In this example, the peer has been administratively shut down, e.g., through a restart, configuration change, etc.

In the solution to the last exercise, we already pointed out that two BGP peers must agree on common keepalive and holddown timer values. If both peers have different timers configured, then the smaller values are used.

The same is true for address families. In order to exchange routing information, both BGP peers need to agree on the intersection of supported address families.

BGP is a protocol that has continually expanded its functionality since its original specification. On the one hand, it is of course useful to be able to easily add new features without having to adapt essential protocol mechanisms. On the other hand, there is the problem that two different BGP implementations may not support the same extensions. Therefore, BGP has introduced the capability negotiation. During session establishment, a BGP peer lists all the capabilities it supports in the OPEN message. If the remote side finds any capability that it does not support, it sends back a NOTIFICATION with corresponding information. This process is repeated until a both BGP peers agree on a common subset.

In this example we can see there is no mismatch of features, i.e., both BGP peers agreed to support BGP route refresh messages as well as 4-byte AS numbers on top of the original BGP specification.

It is possible to administratively disable a BGP peer without deleting the whole configuration, e.g., that way a new BGP peer can be pre-configured before it is actually connected.

Now that we have established some BGP peerings, we need to understand how BGP peers exchange route update messages and how they are processed.

BGP UPDATE messages received from a BGP neighbor are stored in a table called the RIB-IN. In BDS, the RIB-IN table name has the format <instance_name>.bgp.rib-in.afi.safi.<peer_ip>.<local_ip>, e.g., the IPv4 route updates received from R2 are stored in default.bgp.rib-in.ipv4.unicast.172.16.0.2.172.16.0.1. These tables are populated by the bgp.iod. The command show bgp rib-in can be used to view the content of the table:

The routes will then be passed from bgp.iod to the bgp.appd which does a BGP best path selection based on standard BGP rules. The results are stored in the BGP FIB. The corresponding BDS table is named <instance_name>.bgp.1.fib-local.afi.safi, e.g., the IPv4 BGP FIB is stored in default.bgp.1.fib-local.ipv4.unicast. In this table, all BGP route information from all peers is consolidated. The content of the BGP FIB can be retrieved by show bgp fib command:

As BGP is not the only routing protocol running on the system, the routing information base daemon (ribd) is responsible for evaluating all the route sources (e.g., BGP, static routes, direct routes, …​) and choosing the best path which will then be installed into the RIB and used to forward traffic. The show route command is used to retrieve the information stored in the RIB.

On the other hand, bgp.appd provides the BGP FIB for route update advertisements to BGP peers. These route updates are stored in the BGP RIB-OUT. Apart from the nexthop information, all BGP peers which belong to the same peer-group will get identical BGP updates. Therefore, the BGP RIB-OUT is stored in BDS on a per peer-group basis namely <instance_name>.bgp.1.peer-group.<pgname>.afi.safi, e.g., default.bgp.1.peer-group.ISP2.ipv4.unicast. The `show bgp rib-out`is used to view the RIB-OUT table:

If you want to use load sharing, you must enable the multipath option. The BGP multipath option is configured under the set instance <instance> protocol bgp <afi> <safi> hierarchy, i.e., it can be set on a per address-family basis.

Unlike IGP protocols, BGP is not enabled on any interfaces. If we look at the output of the show bgp rib-out command, we notice that R1 is only advertising routes to its peers which were learned from these peers before. As a consequence, no destination within AS64501 is reachable from the outside so far.

The process of injecting non-BGP routes into the BGP tables is called redistribution just like in IGPs. In order to make routes reachable from outside our AS, we need to redistribute direct routes, static routes or routes from other dynamic protocols into BGP using the set instance <instance_name> protocol bgp address-family <afi> <safi> redistribute …​ syntax.

In the last section we saw that a BGP route can have many path attributes. Some of these path attributes (e.g., local preference, AS_PATH, or MED) have a direct impact on selecting the best path, while other path attributes (e.g., community values) have no direct impact in the route selection process.

In the BGP Introduction module we created an ordered list of criteria that are evaluated when selecting the best path. To make a particular route better or worse, individual path attributes can be changed. The most flexible way to do this is with the Policy Framework, which we will introduce in detail in X.

If you have completed the exercise, you can check the results by executing