BGP - 2 - BGP Routing Policies

Route Filtering and Route Summarization

Four popular tools used to filter BGP routes:

1. Distribution lists
2. Prefix lists
3. AS_PATH filter lists
4. Route maps

Additionally, the aggregate-address.

The four main tools have the following features in common:

• All can filter incoming and outgoing Updates, per neighbor or per peer group.
• Peer group configurations require Cisco IOS Software to process the routing policy against the Update only once, rather than once per neighbor.
• The filters cannot be applied to a single neighbor that is configured as part of a peer group.
• Each tool’s matching logic examines the contents of the BGP Update message, which includes the BGP PAs and network layer reachability information (NLRI).
• If a filter’s configuration is changed, a clear command is required for the changed filter to take effect.
• The clear command can use the soft reconfiguration option.

Filtering BGP Updates Based on NLRI

One difference between BGP distribute lists and IGP distribute lists is that a BGP distribute list can use an extended ACL to match against both the prefix and the prefix length. When used with IGP filtering tools, ACLs called from distribute lists cannot match against the prefix length.

The prefix list matches the exact prefixes and prefix lengths; the omission of any ge or le parameter means each line matches only that exact prefix.

Both the route map and any referenced ACL or prefix list have deny and permit actions configured. The route-map command’s action—either deny or permit —defines whether an NLRI is filtered ( deny ) or allowed to pass ( permit ). The permit or deny action in an ACL or prefix list implies

whether an NLRI matches the route map clause ( permit by the ACL/prefix list) or does not match ( deny in the ACL/prefix list).

To support soft reconfiguration, BGP must remember the actual sent and received BGP Update information for each neighbor. The neighbor neighbor-id soft-reconfiguration inbound command causes the router to keep a copy of the received Updates from the specified neighbor. (IOS keeps a copy of sent Updates automatically.) 

For configuration changes that impact the local injection of routes into the BGP table, soft reconfiguration does not help. The reason is that soft

reconfiguration simply reprocesses Updates, and features that inject routes into BGP through the redistribute or network commands are not injected based on Update messages.

Comparing BGP Prefix Lists, Distribute Lists, and Route Maps

If the desired policy is only to filter routes based on matching prefixes/lengths, a route map does not provide any additional function over using a distribute list or prefix list directly. Similarly, if the goal of the policy is to filter routes just based on matching with an AS_PATH filter, the route map does not provide any additional function as compared to calling an AS_PATH filter directly using the neighbor filter-list command. However, only route maps can provide the following two functions for BGP routing policy configurations:

• Matching logic that combines multiples of the following: prefix/length, AS_PATH, or other BGP PAs.
• The setting of BGP PAs for the purpose of manipulating BGP’s choice of which route to use

Filtering Subnets of a Summary Using the aggregate-address Command

The filtering options on the aggregate-address command are as follows:

• Filtering all component subnets of the summary from being advertised, by using the summary-only keyword
• Advertising all the component subnets of the summary, by omitting the summaryonly keyword
• Advertising some and filtering other component subnets of the summary, by omitting the summary-only keyword and referring to a route map using the suppressmap keyword.

Filtering BGP Updates by Matching the AS_PATH PA

To filter routes by matching the AS_PATH PA, Cisco IOS uses AS_PATH filters.

The main two steps are as follows:

1. Configure the AS_PATH filter using the ip as-path access-list number { permit | deny } regex command.
2. Enable the AS_PATH filter using the neighbor neighbor-id filter-list as-path-filter-number { in | out } command.

Because the most recently added ASN is the first ASN in the AS_SEQUENCE segment, the process of adding the ASN before advertising routes to external BGP (eBGP) peers is called AS_PATH prepending. 

Including the as-set keyword, R4 creates an AS_SET segment in the AS_PATH of the aggregate route. Note that the AS_SET segment is shown in brackets, and it is listed in no particular order. These facts are all important to the process of AS_PATH filtering.

Confederation ASNs are used to prevent loops inside the confederation. Because these ASNs will be removed before advertising the route outside the full AS, the confederation ASNs are kept inside a different segment—the AS_CONFED_SEQ segment. Finally, if a route is aggregated inside a confederation, the AS_CONFED_SET segment holds the confederation ASNs with the same logic as used by the AS_SET segment type, but keeps them separate for easy removal before advertising the routes outside the confederation.

The show ip as-path-access-list command shows the contents of the list.

The show ip bgp neighbor neighbor-id advertised-routes command displays the routes actually sent—in other words, this command reflects the effects of the filtering by omitting the filtered routes from the output.

The show ip bgp neighbor neighbor-id received-routes command displays the routes actually received from a neighbor, never omitting routes from the output, even if the router locally filters the routes on input.

Output filter lists are applied before the router adds its own ASN to the AS_PATH.

A couple of ways to test regex without changing the routing policy.

show ip bgp neighbor 10.1.34.4 received-routes | include 4_1_.*_.*_.*_44

This command parses the entire command output using the regex after the include keyword.

The other method to test a regex is to use the show ip bgp regexp expression command. This command parses the AS_PATH variables in a router’s BGP table, including all special characters. However, the regexp option of the show ip bgp command is not allowed with the received-routes or advertised- routes option.

Note that the "(" must be matched by enclosing it in square brackets, as ! the "(" itself and the ")" are metacharacters, and would otherwise be interpreted as a metacharacter. Without the "[(]" to begin the regex, the ! AS_PATH filter would not match. Because the "{" and "}" are not metacharacters, they can simply be typed directly into the regex.

BGP Path Attributes and the BGP Decision Process

Each BGP PA can be described as either a well-known or optional PA. 

Well-known PAs are either one of the following:

• Mandatory: The PA must be in every BGP Update.
•  Discretionary: The PA is not required in every BGP Update.

The BGP Decision Process

1. Is the NEXT_HOP reachable?
2. Highest administrative weight
3. Highest LOCAL_PREF PA
4. Locally injected routes
5. Shortest AS_PATH length: The length calculation ignores both AS_CONFED_SET and AS_CONFED_SEQ, and treats an AS_SET as one ASN, regardless of the number of ASNs in the AS_SET. It counts each ASN in the AS_SEQUENCE as one. (This step is ignored if the bgp bestpath as-path ignore command is configured.)
6. ORIGIN PA
7. Smallest Multi-Exit Discriminator (MED) PA: The smaller the value, the better the route.
8. Neighbor Type: Prefer external BGP (eBGP) routes over internal BGP (iBGP).
9. IGP metric for reaching the NEXT_HOP.

If a step determines the best route for an NLRI, BGP does not bother with the remaining steps.

When overlapping NLRIs exist—for example, 130.1.0.0/16, 130.2.0.0/16, and 130.0.0.0/12—BGP attempts to find the best route for each specific prefix/prefix length.
First and last of the nine items relate to NEXT_HOP.

Configuring BGP Policies

The show ip bgp <network> command lists the advertising router’s RID and neighbor ID.

The "from z.z.z.z" phrases identify the neighbor ID that advertised the route. The "(y.y.y.y)" output that follows lists the RID of that same router.

Step 1: NEXT_HOP Reachable

Step 2: Administrative Weight

Default 0 for learned routes, 32,768 for locally injected routes

The neighbor route-map command creates an implied filtering decision. Any route matched by a permit clause in the route map is implied to be allowed through, and routes matched by a deny clause will be filtered. Route maps use an implied deny all at the end of the route map for any unmatched routes. By including a final clause with just a permit keyword, the route map changes to use permit all logic, thereby passing all routes.

Step 3: Highest Local Preference (LOCAL_PREF)

Changing the default Using the bgp default local-preference <0-4294967295> BGP subcommand

Step 4: Choose Between Locally Injected Routes Based on ORIGIN PA

When the same NLRI is locally injected into BGP from multiple methods, pick the route with the better ORIGIN PA.

Step 5: Shortest AS_PATH

bgp bestpath as-path ignore command - Removes the AS_PATH length step from the decision tree for the local router.

Removing Private ASNs - 

 Private ASNs can be removed only at the point of sending an eBGP Update.

 If the current AS_SEQ contains both private and public ASNs, the private ASNs will not be removed.

 If the ASN of the eBGP peer is in the current AS_PATH, the private ASNs will not be removed, either.

The aggregate-address command with the as-set option can lengthen the AS_PATH length calculation as well.

The BGP AS_PATH length calculation counts the entire AS_SET as 1, regardless of the actual length.

Step 6: Best ORIGIN PA

The well-known mandatory BGP ORIGIN PA characterizes a route based on how it was injected into BGP. 

If the set of routes to reach a single NLRI includes only one route of ORIGIN code IGP (i), and all the others as incomplete (?), the route with ORIGIN i is the best route. BGP routing policies can set the ORIGIN code explicitly by using the set origin route

map subcommand, although the earlier steps in the BGP decision process are typically better choices.

Step 7: Smallest Multi-Exit Discriminator

Scope - Advertised by one AS into another, propagated inside the AS but not sent to any other ASs. Smaller is better.

The purpose of the MED (or MULTI_EXIT_DISC) is to allow routers in one AS to tell routers in a neighboring AS how good a particular route is. A default setting is 0. MED. A better default for MED can be set by using the bgp bestpath med missing-as-worst BGP subcommand, which resets a router’s default MED to the largest possible MED value, instead of the lowest.

Configuring MED: Multiple Adjacent Autonomous Systems

By default, a Cisco router ignores MED when the multiple routes to a single NLRI list different neighboring ASNs. This default action makes sense—normally you would not expect two different neighboring ISPs to have chosen to work together to set MEDs. To override this default and consider the MED in all cases, a router needs to configure the bgp always-compare-med BGP subcommand. If used on one router, all routers inside the

same AS should also use the bgp always-compare-med command, or routing loops can result.

After reaching the other AS, the MED is advertised inside the AS, but not outside the AS.

MED can also be set through inbound route maps, although that is not the intended design with which to use MED.

Step 8: Prefer Neighbor Type eBGP over iBGP

BGP uses this decision point frequently when two or more enterprise routers connect to the same ISP.

Each enterprise border router knows of one eBGP route to reach each prefix, and one or more iBGP routes to the same prefix learned from that enterprise’s other border routers. With no routing policies configured, the routes tie on all decision points up to this one, including AS_PATH length, because all the prefixes were learned from the same neighboring ISP. The decision process reaches this step, at which point the one eBGP route is picked as the best route.

Step 9: Smallest IGP Metric to the NEXT_HOP

Step 10: Lowest BGP Router ID of Advertising Router

Step 11: Lowest Neighbor ID

The BGP maximum-paths Command

BGP defaults the maximum-paths command to a setting of 1. However, BGP will consider adding multiple entries to the IP routing table, for the same NLRI, under certain conditions—conditions that differ based on whether the best route is an eBGP route or an iBGP route.

The following rules determine if and when a router will add multiple eBGP routes to the IP routing table for a single NLRI:

1. BGP must have had to use a tiebreaker (Step 10 or 11) to determine the best route.
2. The maximum-paths number command must be configured to something larger than the default of 1.
3. Only eBGP routes whose adjacent ASNs are the same ASN as the best route are considered as candidates.
4. If more candidates exist than that called for with the maximum-paths command, the tiebreakers of Steps 10 and 11 determine the ones to use.

The rules for iBGP have some similarities with eBGP, and a few differences, as follows:

1. Same rule as eBGP rule 1.
2. The maximum-paths ibgp number command defines the number of possible IP routes, instead of the maximum-paths number command used for eBGP.
3. Only iBGP routes with differing NEXT_HOP settings are considered as candidates.
4. Same rule as eBGP rule 4.

BGP Communities

The BGP COMMUNITY PA provides a mechanism by which to group routes so that routing policies can be applied to all the routes with the same community. 

BGP communities are powerful in that they allow routers in one AS to communicate policy information to routers that are one or more autonomous systems distant. In fact, because the COMMUNITY PA is an optional transitive PA, it can pass through autonomous systems that do not even understand the COMMUNITY PA and then still be useful at another downstream AS.

The only way to match the COMMUNITY is to refer to an ip community-list , which then has the matching parameters.

The set community 10 20 30 additive command would add the values to the existing COMMUNITY string.

The show ip bgp community-list list-number command is then used to show whether a match would be made. This command lists the entries of the BGP table that match the associated COMMUNITY PA, much like the show ip bgp regex command examines the AS_PATH PA.

The set community none command in a route-map clause, and all routes matched by that clause will have their COMMUNITY PA removed. A route map can also remove individual COMMUNITY strings by using the set commlist community-list-number delete command.

Filtering NLRIs Using Special COMMUNITY Values

A route with COMMUNITY NO_EXPORT is not advertised outside an AS. This value can be used to prevent an AS from being a transit AS for a set of prefixes. 

Finally, routes with these settings can be seen with commands like show ip bgp community noexport, with similar options NO_ADVERT and LOCAL_AS.

Fast Convergence Enhancements

BGP only provides updates to its neighbors periodically using an interval based on the peering type: iBGP peers receive updates every 5 seconds, whereas eBGP peers are updated only every 30 seconds. BGP will only verify next-hop reachability every 60 seconds.

Fast External Neighbor Loss Detection

The eBGP session between directly connected eBGP neighbors will be torn down the moment that the connected subnet between the peers is lost. This will result in the immediate flushing of BGP routes, and BGP will immediately begin looking at alternate routes. 

Internal Neighbor Loss Detection

With the neighbor fall-over command, the moment that the IP address of the BGP peer is removed from the routing table, the BGP session with the peer will be torn down, thus resulting in immediate convergence. 

EBGP Fast Session Deactivation

Use it to quickly detect failures of eBGP sessions established between loopback interfaces of eBGP peers or to detect eBGP neighbor loss when you disable fast external fall-over.

Summary

network ip-address backdoor 

- BGP mode; identifies a network as a backdoor route, considering it to have the same administrative distance as iBGP routes