This post is the 4th in a series of Border Gateway Protocol (BGP) posts. If you missed any of the first three, here are the links:

• Part #1: BGP Overview, Messages Types, and Neighbor States
• Part #2: BGP Path Selection
• Part #3: BGP Peering and Authentication
  

In this post, we're going to take a look at configuring BGP to advertise Network Layer Reachability Information (NLRI), and also the configuration of a BGP routing policy.

Advertising NLRI

Before we even begin advertising NLRI using our various commands in this section, let’s take a moment to discuss an old feature of BGP that Cisco disables by default for you. The feature is called BGP synchronization. For proof that Cisco has disabled this feature on your device, just perform a show running-configuration on one of your lab BGP speakers and under the BGP process you will find the command no synchronization. If enabled, the synchronization feature prevents a BGP speaker from entering prefixes into BGP if there is not a correlated entry for the prefix in the underlying IGP (or static routes). This helps to prevent “black hole” type situations where devices in the path are not running BGP and cannot forward to the BGP prefix because they lack a route to that prefix from their IGP. This feature is off by default now because of the creation of many different scalability mechanisms that exist in BGP that permit you to configure an IBGP topology without the requirement for a full mesh of IBGP peers. Another reason it is turned off is the fact that it was somewhat encouraging the redistribution of BGP prefixes into the underlying IGP, and this is not always a safe or desirable design practice. 

There is a reason that Cisco is moving away from the use of the network command to configure IGPs at the CLI. It is never a good idea in programming to have a command that does very different things when used in different areas. This is the case with the network command. When used with an IGP, you are enabling the protocol on interface using the command (and also impacting which prefixes are advertised), but with BGP, the network command does something different. It is not enabling BGP on specific interfaces, instead it is advertising a prefix that exists (somehow) on the local device and injecting it into BGP.

While the prefix that you might advertise into BGP is most often found in your IGPs contribution to the routing table, you can use other techniques to generate the prefix for advertisement. For example, you could create a loopback interface that possesses the network prefix that you want to advertise. Or you could create a static route, or even a static route pointing to Null0.

The one tricky little bit associated with the network command in BGP is the fact that if your subnet mask for your prefix is not on an IP address classful boundary (for example, 10.0.0.0/8), then you need to remember to use the mask keyword and supply the correct mask when using the command. Example 1 shows the creation of two loopback interfaces and the advertisement of their prefixes into BGP. Notice this example also shows the verification of these prefix advertisements on the ATL router.

Example 1: Using the Network Command in BGP

While the network command is simple and convenient, it would not be efficient if you had many prefixes to advertise. Another option is to redistribute prefixes into BGP from an IGP or static routes. Example 2 demonstrates redistributing prefixes that have been learned via EIGRP into BGP. Note in the verification that the origin code for these prefixes appears as a (?) indicating Unknown.

Example 2: Redistributing Prefixes into BGP

When you start advertising NLRI into BGP, you might come across prefixes in your BGP table (shown with show ip bgp) that have an (r) status code instead of the expected valid status code (*). Therstatus code indicated a RIB failure, meaning that BGP tried to place the prefix in the BGP table, but could not due to some issue.

The most common reason for RIB failure is administrative distance (AD). For example, IBGP learned prefixes carry a pretty terrible AD of 200. This means that if your router has learned the prefix through an IGP (even one as bad as RIP with an AD of 120), it will be preferred over the IBGP prefix. As a result of this AD issue, BGP does not mark the prefix as valid. Note that this tends not to happen with EBGP-learned prefixes as they have a very preferable AD of 20 (by default).

Many often times, if it is desirable to have the prefix in the IGP and BGP, administrators will manipulate the AD values on their routers to improve the AD if IBGP. For example, in the case of RIP and BGP, the admin could set the AD of IBGP learned routes to 119 in order to make them preferred over the IGP in use.

In addition to catching RIB failures in the results of show ip bgp, you can use the more direct command show ip bgp rib-failure in order to see any prefixes in this status. This is especially helpful in the case of massive BGP tables.

Configuring BGP Routing Policy

It is fairly common to encounter topologies where you explicitly do not want to advertise prefixes in your BGP table, or you might not want to receive certain prefixes from a BGP peer. Fortunately, there are many tools at your disposal for doing this. For example, here are just some methods you could employ in order to filter prefixes:

• Distribute lists
• Extended ACLs
• Prefix lists
• AS Path filters
• Route maps

Example 3 demonstrates one of these filtering methods for you. I selected the route map approach, because everyone (rightly so) loves route maps. Notice how we block one of the two prefixes we would be learning from AS 100 using this approach.

Example 3: Using a Route Map as a Prefix Filter in BGP 

Notice the use of the clear ip bgp * soft command before I do my verification. This ensures the device refreshes the BGP information right away for me so that I do not have to wait for timer expirations when it comes to converging BGP on the new policy manipulations we have made.  

Remember, BGP uses many different path attributes instead of just a simple metric in order to provide you with the opportunity to easily tune and tweak the manner in which routing occurs. Just some of the path attributes you might manipulate in order to effect policy would be:

• Weight
• MED
• Local Preference
• AS Path

You might wonder how AS Path could be manipulated in order to effect routing. After all, the AS Path is set by the routers in the path as the prefix traverses the AS topology. AS Path manipulation is often done with AS Path Prepending. You poison a prefix by prepending your own AS number to the path in order to make a longer (less preferable) AS Path. Like most of our path attribute manipulations, this is easily accomplished using a route map.

Let us walk through an example of using Local Preference to manipulate policy. We often use Local Preference to influence how we will route traffic outbound to a BGP prefix. We do this by setting Local Preference values inbound on multiple paths. Before we get started, understand that Local Preference is a value that is examined fairly high up in the BGP best path decision process, a higher value is preferred, and the values are only passed in IBGP updates. That is how the LOCAL got in to the name Local Preference.

To begin, I have advertised the same prefix into AS 200 (ATL and ATL2) from the TPA1 and TPA2 routers of AS 100. Looking at Example 4, you can see that this prefix (192.168.1.0) can be reached using the next hop of 10.10.10.1 and that this is the preferred path. An alternate path that would be used if this path failed would be through next hop 10.21.21.1.

Example 4: Getting Ready to Use Local Preference

It is now time to have some fun and change this behavior with an example path attribute manipulation. My approach will be to identify the prefix we want to manipulate (192.168.1.0) and raise the Local Preference value to be greater than the default of 100 for the path to TPA2 at next hop 10.21.21.1. I do this by manipulating the prefix as it enters via the 10.21.21.1 path. Example 5 shows this configuration.

Example 5: Manipulating Paths with Local Preference

Notice the preferred path is now via the next hop 10.21.21.1 as we desired. The non-default Local Preference value of 110 also displays for that prefix. This higher value is preferred and changes the selection made by the BGP Best Path Selection process.

That's going to wrap up Part 4 of our BGP series. Coming up in Part 5, we'll take a look at BGP scalability mechanisms. Take good care.