BGP announcements: network v. prefix-list v. route-maps with 'match prefix-list'

[noemi.berry]

I have some questions about how BGP prefix announcements are made, with 'network' statements, 'neighbor prefix-list' statements, and 'nieghbor route-map out' statements in which the route-map contains 'match ip prefix-list' statements .

Sample config.  This router has null static routes to its own prefixes, so, the prefixes are always present in the routing table.

    router bgp 66666

     network 2.2.2.2            <---- my prefixes

     network 3.3.3.3

     neighbor 1.1.1.1 remote-as 8888    <---- my peer

    ip route 2.2.2.2 255.255.255.0 Null0

    ip route 3.3.3.3 255.255.255.0 Null0

This router is carrying full Internet routes, so it's important that it only announces its organization's own prefixes and not its whole table (some of which is learned from another ISP), and this works, only the two prefixes in the 'network' statements are announced.

Now for other reasons we might want to use a prefix-list and/or route-maps.

What gets announced in each of these scenarios?

1) Route-map that references a prefix-list with an explicit deny at the end

    router bgp 66666

     network 2.2.2.2

     network 3.3.3.3

     neighbor 1.1.1.1 route-map To-ISP out

    route-map To-ISP permit 10

     match ip address prefix-list Outbound

     ip prefix-list Outbound seq 10 permit 2.2.2.2 /24

     ip prefix-list Outbound seq 20 permit 3.3.3.3 /24

     ip prefix-list Outbound seq 30 deny 0.0.0.0/0 le 32

2) Route-map that references a prefix-list, without an explicit deny at the end

    router bgp 66666

     network 2.2.2.2

     network 3.3.3.3

     neighbor 1.1.1.1 route-map To-ISP out

    route-map To-ISP permit 10

     match ip address prefix-list Outbound

     ip prefix-list Outbound seq 10 permit 2.2.2.2 /24

     ip prefix-list Outbound seq 20 permit 3.3.3.3 /24

      (Would this scenario announce the router's full routing table to peer 1.1.1.1?)

3) Prefix-list directly in the neighbor config, with an explicit deny at the end

    router bgp 66666

     network 2.2.2.2

     network 3.3.3.3

     neighbor 1.1.1.1 prefix-list Outbound out

     ip prefix-list Outbound seq 10 permit 2.2.2.2 /24

     ip prefix-list Outbound seq 20 permit 3.3.3.3 /24

     ip prefix-list Outbound seq 30 deny 0.0.0.0/0 le 32

4) Prefix-list directly in the neighbor config, without an explicit deny at the end

    router bgp 66666

     network 2.2.2.2

     network 3.3.3.3

     neighbor 1.1.1.1 prefix-list Outbound out

     ip prefix-list Outbound seq 10 permit 2.2.2.2 /24

     ip prefix-list Outbound seq 20 permit 3.3.3.3 /24

And then each scenario without the network 2.2.2.2 and network 3.3.3.3 statements:

1a) Route-map that references a prefix-list with an explicit deny at the end, without network statments

    router bgp 66666

     neighbor 1.1.1.1 route-map To-ISP out

    route-map To-ISP permit 10

     match ip address prefix-list Outbound

     ip prefix-list Outbound seq 10 permit 2.2.2.2 /24

     ip prefix-list Outbound seq 20 permit 3.3.3.3 /24

     ip prefix-list Outbound seq 30 deny 0.0.0.0/0 le 32

2a) Route-map that references a prefix-list, without an explicit deny at the end, without network statements

    router bgp 66666

     neighbor 1.1.1.1 route-map To-ISP out

    route-map To-ISP permit 10

     match ip address prefix-list Outbound

     ip prefix-list Outbound seq 10 permit 2.2.2.2 /24

     ip prefix-list Outbound seq 20 permit 3.3.3.3 /24

3a) Prefix-list directly in the neighbor config, with an explicit deny at the end, without network statements

    router bgp 66666

     neighbor 1.1.1.1 prefix-list Outbound out

     ip prefix-list Outbound seq 10 permit 2.2.2.2 /24

     ip prefix-list Outbound seq 20 permit 3.3.3.3 /24

     ip prefix-list Outbound seq 30 deny 0.0.0.0/0 le 32

4a) Prefix-list directly in the neighbor config, without an explicit deny at the end, without network statements

    router bgp 66666

     neighbor 1.1.1.1 prefix-list Outbound out

     ip prefix-list Outbound seq 10 permit 2.2.2.2 /24

     ip prefix-list Outbound seq 20 permit 3.3.3.3 /24

So, the summary of questions:

 - Is a prefix-list is just an ACL to filter what's sent?

 - Can a prefix-list make announcements itself?

 - Or does it depend on how the prefix-list is used?  (e.g. in a match ip address prefix-list statement in a route-map it acts as a passive filter; and in a neighbor prefix-list statement it acts as an active announcement?).

 - Is there a conflict between having both 'network' and 'neighbor prefix-list' statements?

 - Is there a conflict between having both 'network' and 'neighbor route-map out' with statements?

I've Googled and read documents, but haven't seen this all put together yet. 

We had an incident in which our ISP shut down our peer for a prefix-limit violation when we experienced scenario #3 (route-map matching on a prefix-list missing the explicit 'deny' at the end) for about 10 minutes.  But I'm not sure what mechanism would have announced our entire routing table!

Specific information greatly appreciated!

[Peter Paluch]

Hi Noemi,

A great question indeed!

One comment before starting analyzing the options: Your networks are inconsistent with their netmasks. I assume you wanted to talk about 2.2.2.2/32 and 3.3.3.3/32 throughout your entire post.

In Scenarios 1 through 4, only 2.2.2.2/32 and 3.3.3.3/32 will be advertised. No other networks will be advertised. The explicit deny statement at the end of the Outbound prefix-list is not necessary because every prefix-list contains an implicit "deny any" as its last invisible entry, but at the same time, having it there does no harm and makes it explicitly visible that this prefix-list is consciously meant to act as "deny what has not been permitted earlier".

In Scenarios 1a through 4a, nothing would be advertised. The outbound prefix-list or route-map that references this prefix-list match only 2.2.2.2/32 and 3.3.3.3/32. However, they are not injected into BGP as the corresponding network commands are missing. If these networks are not learned via BGP themselves (which they shouldn't be as they should not be advertised by anyone else) then with this configuration, the router will advertise nothing to its peer 1.1.1.1

 - Is a prefix-list is just an ACL to filter what's sent?

Yes, it is a sort of "ACL" that allows or denies individual network entries from routing protocol updates. As opposed to ACLs, prefix-lists are more suited for manipulating routing updates because they are specifically constructed to match network prefixes and their lengths (that is, network addresses and netmasks). ACLs can be used for these purposes, too (using either match ip address acl-name in a route-map or using neighbor distribute-list acl-name) but they are very cumbersome and impractical, as their primary purpose is to filter traffic flows, not traffic contents, and using them in BGP is just forcing them to do something they have not been originally constructed for.

 - Can a prefix-list make announcements itself?

No, never. In scenarios like the ones you have posted, never.

 - Or does it depend on how the prefix-list is used?

There is one application of prefix-lists I know of that causes additional artificial prefixes to be injected into BGP. This feature is called Conditional Route Injection and it allows to de-aggregate a prefix: If you learn a certain prefix, say, 2.2.2.0/24, you can tell your router to artificially inject subnets of this prefix into BGP (say, 2.2.2.0/26, 2.2.2.64/26, 2.2.2.128/26, 2.2.2.192/26) so that you can then advertise these subnets and perform more fine-grained traffic balancing. You can read more about this feature here:

http://www.cisco.com/c/en/us/td/docs/ios/12_2s/feature/guide/fsbgpri.html

However, keep in mind that even here, the prefix-list is not injecting the routes per-se, it just tells BGP what routes to inject in this particular scenario.

If prefix-lists are used to filter routing updates, they only cause networks to be filtered out. They cannot cause a non-existent network to be added to the routing updates.

- Is there a conflict between having both 'network' and 'neighbor prefix-list' statements?

I am not sure what you mean by a conflict but as far as I can tell, there is absolutely no ill interaction between a network command and the use of a neighbor prefix-list.

 - Is there a conflict between having both 'network' and 'neighbor route-map out' with statements?

The same as before.

We had an incident in which our ISP shut down our peer for a prefix-limit violation when we experienced scenario #3 (route-map matching on a prefix-list missing the explicit 'deny' at the end) for about 10 minutes.  But I'm not sure what mechanism would have announced our entire routing table!

A simple typo in referencing either the route-map name or the prefix-list name would cause the BGP to use a non-existent filtering object, and as a result, there would be no filters at all. This is, in my opinion, the most straightforward explanation.

Best regards,
Peter

[noemi.berry]

Thank you so much Peter, I'm so anxious to understand this.

A few clarifications:

>Your networks are inconsistent with their netmasks. I assume you wanted to talk about 2.2.2.2/32 and 3.3.3.3/32 throughout your entire post.

Oops.  Yes, you're correct, I meant network 2.2.2.0 255.255.255.0 for illustration purposes.  Editing failure!

 (In fact, my example was worse than that -- without an explicit mask, classful masking applies, and the statement 'network 2.2.2.2' would imply announcing 2/8!)

In Scenarios 1a through 4a, nothing would be advertised. The outbound prefix-list or route-map that references this prefix-list match only 2.2.2.2/32 and 3.3.3.3/32. However, they are not injected into BGP as the corresponding network commands are missing. If these networks are not learned via BGP themselves (which they shouldn't be as they should not be advertised by anyone else) then with this configuration, the router will advertise nothing to its peer 1.1.1.1.

What about networks that ARE learned via BGP?

This sample router is one in a dual-home situation: 2 routers, 2 ISPs, with iBGP peering between them.  So, this sample router learns prefixes from the other router / ISP.  In that case, is it possible that Scenario #4 above (route-map references prefix-list that lacks the explicit 'deny' at the end) would announce our entire table upstream?  (Would IGP synchronization disabled be a clue?)

If prefix-lists are used to filter routing updates, they only cause networks to be filtered out. They cannot cause a non-existent network to be added to the routing updates.

Got it.

Can they cause an existent network that's in our routing table, learned via BGP/iBGP, to be announced?  Especially lacking an explicit 'deny' at the end?

>A simple typo in referencing either the route-map name or the prefix-list name would cause the BGP to use a non-existent filtering object, and as a result, there would be no filters at all. This is, in my opinion, the most straightforward explanation.

What mechanism would actually send / announce the prefixes?  That is, even if a typo or other mistake negated the filtering, some mechanism would still initiate the announcements?  (of our entire routing table -- or enough to trigger a prefix-limit violation for 850+ prefixes?)

There are other mechanisms that announce prefixes dynamically, such as redistributing from another routing protocol, or  neighbor distribute-list , but we don't have anything like that....

Or do we?  Are there default setups that say "announce all routes in the routing table"?  

We had Scenario #3 in place and working perfectly, and I am positive the only change we made was a cut-and-paste removal of the last 'deny' line in the prefix-list (Scenario #4).   Maybe while updating the prefix-list, it was removed for long enough that outbound routes were unfiltered, but still, what mechanism would initiate the (now-unfiltered) announcement?

Thanks for the other answers.  (Apologies for ambiguities -- by "conflict" between a 'network' and 'neighbor prefix-list' statement, I meant to ask if the two statements would compete to perform an announcement, and the answer is no.)

Still a few lines shy of getting it -- thanks so much!

[Peter Paluch]

Hi Noemi,

You are welcome.

What about networks that ARE learned via BGP?

This sample router is one in a dual-home situation: 2 routers, 2 ISPs, with iBGP peering between them.  So, this sample router learns prefixes from the other router / ISP.  In that case, is it possible that Scenario #4 above (route-map references prefix-list that lacks the explicit 'deny' at the end) would announce our entire table upstream?  (Would IGP synchronization disabled be a clue?)

This isn't Scenario #4 - looks more like Scenario #2. Nevertheless, a missing deny block in the route-map would make no difference. Even a route-map has an invisible deny block at its end. If a prefix wasn't permitted by the referenced prefix-list in the first block of the route-map, it would proceed to the second block which is, in this case, the implicit deny block, and be denied. Having an explicit deny block at the very end of a route-map is equivalent to having none, the same as with prefix-lists I've explained in my previous post.

The IGP synchronization is an entirely different concept, and has no relation to this at all.

Can they cause an existent network that's in our routing table, learned via BGP/iBGP, to be announced?  Especially lacking an explicit 'deny' at the end?

Your prefix-lists are constructed as "permit these specific networks". Whether there is an explicit deny at the end of such list is not relevant anymore, as the prefix-list still has an implicit deny at its very end, and all its entries permit specific networks only. Such a prefix-list would still advertise only those networks that specifically match the explicit networks in the prefix-list's entries. If no network matches them, regardless of where they came from (learned via BGP or injected locally into BGP), nothing would be advertised.

What mechanism would actually send / announce the prefixes?  That is, even if a typo or other mistake negated the filtering, some mechanism would still initiate the announcements?  (of our entire routing table -- or enough to trigger a prefix-limit violation for 850+ prefixes?)

Recall that BGP will advertise all known destinations to an external peer unless there is a filter applied to that neighbor that tightens down the list of advertised prefixes. BGP cannot advertise networks it does not know, and filters in BGP applied either using neighbor route-map or neighbor prefix-list only cause the full list of networks to be shortened but never to be extended by some new network.

Assuming that your router learned those 850+ routes from another BGP peer, it would be automatically willing to advertise them to your upstream ISP. If you mistype the name of the filter that is supposed to filter these routes as they are advertised to your ISP, there is no filtering mechanism in place, and the routes will be advertised all without any filtering.

You may be suggesting the old well-known truth that after changing outbound BGP policies, it is necessary to use the clear ip bgp command to force BGP to re-send the routes again. This may have been true in the past. I've noticed, however, that on newer IOSes, the router keeps tracks whether the policies (route-maps, prefix-lists, etc.) have changed, and if so, it will automatically schedule this update in approx. 30 seconds since the policy was last updated.

Is there any possibility of the prefix-list or the route-map being modified in any way that would open a window of 30 seconds during which this prefix-list or route-map allowed all prefixes to be advertised? Perhaps an inadvertent "permit 0.0.0.0/0 le 32" being added to the prefix-list, or removing the prefix-list altogether and reapplying it back?

There are other mechanisms that announce prefixes dynamically, such as redistributing from another routing protocol, or  neighbor distribute-list

Please note that the neighbor distribute-list is the same as neighbor prefix-list - it is related to filtering updates, only the distribute-list refers to an ACL instead of a prefix-list. It cannot add prefixes to those being already advertised - it can only filter out updates from advertisements.

Are there default setups that say "announce all routes in the routing table"?  

None that I am aware of. BGP in its basic configuration automatically advertises all learned routes further, observing two rules: Do not advertise routes back to the peer you are using as the next hop to reach those networks, and do not advertise an iBGP-learned route to another iBGP peer. But BGP does not automatically snatch all routes from a routing table.

We had Scenario #3 in place and working perfectly, and I am positive the only change we made was a cut-and-paste removal of the last 'deny' line in the prefix-list (Scenario #4).   Maybe while updating the prefix-list, it was removed for long enough that outbound routes were unfiltered, but still, what mechanism would initiate the (now-unfiltered) announcement?

Removing the trailing deny line would not make a difference. However, inadvertently replacing it with a permit 0.0.0.0/0 le 32 line for more than 30 seconds would correspond to the behavior you've experienced. Also, removing the entire prefix-list for more than 30 seconds would be also responsible for what happened - assuming you're running a recent IOS that initiates these updates 30 seconds after the last change to the outbound policy.

Best regards,
Peter

[noemi.berry]

>Recall that BGP will advertise all known destinations to an external peer....

So how is it that our original super-uber-duber bare-bones BGP config doesn't announce this router's entire routing table?

router bgp 66666

 network 2.2.2.0

 network 3.3.3.0

 neighbor 10.255.255.2 remote-as 66666  # iBGP peer

 neighbor 1.1.1.2 remote-as 55555       # eBGP peer

 neighbor 1.1.1.2 filter-list 1 out

!

ip as-path access-list 1 permit ^$

ip as-path access-list 1 deny .*

OHH -- Because I'm a dummy, and missed the obvious and ubiquitous statement:   ip as-path access-list, referenced as a filter-list in a neighbor statement.  It says to only announce routes that originate from our AS, which are only our prefixes in the network statements.  Duh!

Believe it or not, this is one of those things that everyone assumes is known, but quasi-newbies like me might miss.  I somehow thought that announcements were made only via explicit statements in the neighbor config (including static network statements), but as you describe, all destinations are announced.

So, now I'm certain that our prefix-limit violation with our ISP was because of a clumsy transition between our "bare-bones" config and our "route-map / prefix-list" config -- not because the prefix-list itself was wrong, as you describe in such eloquent detail. 

With that little clue, one more question: If we only want to announce our 2 prefixes, then if we put a prefix-list and an ip as-path access-list in a route-map, they'd performing the same function, in two different ways.  Harmless extra insurance, or redundant?  What's the best practice here?

router bgp 66666

 network 2.2.2.0

 network 3.3.3.0

 neighbor 1.1.1.2 route-map TO-ISP out

route-map TO-ISP permit 10

 match ip address prefix-list Outbound  !--- filters based on prefix

 match as-path 1                        !--- filters based on AS path

ip prefix-list Outbound seq 10 permit 2.2.2.0 /24

ip prefix-list Outbound seq 20 permit 3.3.3.0 /24

ip prefix-list Outbound seq 30 deny 0.0.0.0/0 le 32

ip as-path access-list 1 permit ^$

ip as-path access-list 1 deny .*

Thank you so much again for your help, I have a much much better understanding now.  You are an ongoing source of 'light bulb' moments.  I'm sure there will be more!

[Peter Paluch]

Hi Noemi,

With that little clue, one more question: If we only want to announce our 2 prefixes, then if we put a prefix-list and an ip as-path access-list in a route-map, they'd performing the same function, in two different ways.  Harmless extra insurance, or redundant?  What's the best practice here?

I would say that is it kind of redundant. It is much easier to use the as-path access lists rather than prefix-list. In the prefix-lists, you have to identify each network to be advertised by its address or at least by its common prefix. With as-path ACLs, it's so much easier and more compact: You simply say that what you're advertising is everything that has an empty AS_PATH attribute, meaning it's your home network.

A combination of AS_PATH ACLs and prefix-lists would be useful if, for example, you wanted to make sure that you advertise only your home networks, but in addition, you would want to filter out some home prefixes you do not want the external world to see. So you would have your as-path ACL allowing all home routes while a prefix-list filtering out the unneeded (few) networks and leaving all others in place. Makes sense?

Best regards,
Peter