OECG – Chapter 13


This next chapter gets into the details of the BGP “best” decision process, and how you can influence that process. A great deal of time is spent working through the BGP decision process, and different elements of the decision process that you can take advantage of. This is a long chapter, over 50 pages.

So let’s start by talking about 4 useful ways of filtering BGP routes, some of which were discussed previously.

Distribution lists, prefix lists (which I like for simple needs), AS_PATH filter lists and route maps have a number of common features:

  • They all have the ability to filter both incoming and outgoing BGP updates, either per neighbor or per peer group (remember that you can group neighbors into peer groups, and then configure the peer group as a whole).
  • If you use these filters to tweak a peer group, your routing policy only has to hit the BGP update process once for everyone in the peer group, a nice thing to do for IOS.
  • Conversely, if the neighbor is a member of a peer group, then your filter can’t be applied to that neighbor individually.
  • Each filtering method looks at BGP Update messages (not routes) to determine what course of action to take, examining the BGP PAs and NLRIs.
  • If you write the filter, put it into production and then later change it, you’ll have to clear the session between BGP neighbors for your changes to be effective.
  • The “clear” command has an option called “soft reconfiguration” that allows you implement those filtering changes without completely blowing away your established BGP neighbor relationship.
    • Understand that the soft reconfiguration feature allows BGP to reapply filters to BGP Updates. NLRIs that have hit the BGP table from a process other than BGP updates are not impacted by soft reconfiguration.
    • “clear ip bgp xx.xx.xx.xx soft” would apply the new filter to both inbound and outbound BGP Updates.
    • “clear ip bgp xx.xx.xx.xx soft in” would apply the new filter to inbound updates, assuming that you’ve also done a “neighbor xx.xx.xx.xx soft-reconfiguration inbound”, which instructs BGP to maintain a copy of the BGP update table from that neighbor so that your inbound filters can be reapplied.
    • “clear ip bgp xx.xx.xx.xx soft out” would apply the new filter to outbound updates.

The different filter methods have different matching capabilities:

  • “neighbor distribute-list” using a standard ACL can match IP prefixes via a wildcard mask.
  • “neighbor distribute-list” using an extended ACL can match IP prefixes and prefix lengths via a wildcard mask. (But not a RANGE of prefix lengths, as supported by prefix-lists.)
    • To use an extended ACL to match prefix length, you could use an entry as follows “permit ip host host”.
    • This would match prefixes with lengths of /24.
  • “neighbor prefix-list” allows you to use IP prefix lists, where you can match a prefix or range of prefixes in one line.
  • “neighbor filter-list” allows you to filter an NLRI based on AS_PATH, using an “ip as-path access-list”.
  • “neighbor route-map” allows you to filter a number of attributes definable within a route-map, including prefix, prefix-length, AS_PATH and other PAs. If all you want to match is a prefix or AS_PATH alone, one of the other methods is just as effective. But route-maps are handy when you need to match multiple NLRI PAs as well as prefix.

Another method for filtering BGP updates involves the use ot the “aggregate-address” command. This may not be immediatly intuitive, as this command is use for summarization, but in effect you are filtering NLRIs from the Update process.

  • If you use the “summary-only” keyword, then you’ll filter all the subnets that fall under the summary.
  • If you do NOT use “summary-only”, then you’ll be sending all the subnets as well as the summary.
  • If you want to supress certain routes, then you can use the “suppress-map” command and refer to a route-map that will define what you wish to filter. Prefix-list “permits” are matches and therefore suppressed.

Finally for this section, you can filter routes based on their AS_PATH PA. You can do this using regex if you like. I won’t go into what regex is all about; I’ll assume you know a thing or two about it already if you’re working on your CCIE. The book goes into pages of regex examples that I will not go into here, but understand that you can leverage this filtering feature with the “ip as-path access-list <number> {permit|deny} regex” command, where “regex” is your regular expression. Then you apply this as-path filter to a neighbor with a “neighbor <id> filter-list as-path-filter-number {in|out}. (P.S. If you feel you’re getting cheated on this section, you are. I’m behind my study schedule thanks to power failures, 2 3am mornings, and a snowstorm, in April no less. Happy spring. So you’ll have to study up on this section a bit more yourself.)

Miscellaneous points to ponder as we close this section out:

  • “show ip bgp neighbor <id> advertised-routes” will show you the routes you’re actually sending your neighbor, post-filter.
  • “show ip bgp neighbor <id> received-routes” will show you the routes you’re actually receiving from your neighbor, pre-filter, even if you’re filtering the routes as they come in.
  • The router will apply an output filter list BEFORE it adds it’s own ASN to the AS_PATH PA.

About the author

Ethan Banks

Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.


Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.

Subscribe via Email

Receive complete, ad-free posts in your inbox as I publish them here.