Technical Tip: How to control BGP route advertisement with prefix-list
Description
This article describes how to control inbound and outbound prefix advertisements using prefix-lists with BGP. Prefix-lists can be used standalone (which is the case for this article), or they can be used as a component a route-map rule (see also: Technical Tip: How to Block Advertising and Receiving of Specific Routes to and from BGP Peer using Route-Map and Prefix-List). Access lists can also be used for this purpose, although this article does not discuss this topic.
Scope
FortiGate, BGP.
Solution
A scenario will be used to demonstrate the use of prefix lists. First, the following topology will be used in this example:
In this scenario, the administrator wants to configure FortiGate-A to block prefix 10.10.1.0/24 from being advertised to FortiGate-B while still allowing all other prefixes to be shared. Since there are no additional requirements (such as community tagging or adjusting BGP attributes like AS_PATH), the administrator has opted to use a simple outbound prefix-list to perform this filtering. Assume that the BGP peering is already working and in an Established state.
To accomplish this task, the administrator can perform the following steps on FortiGate-A:
- Create the prefix-list:
set prefix 10.10.1.0 255.255.255.0
unset ge
unset le
edit 20
unset ge
unset le
Note the following key points for the prefix-list configuration:
- Prefix-list rules can have the action set to permit or deny, but it may be easier to think of the actions more as 'select' (permit) or 'ignore' (deny). For example, the above configuration could be described as follows: 'this prefix list ignores route prefixes matching 10.10.1.0/24 and selects/matches all remaining prefixes').
This is more relevant when combining prefix-lists with route-maps, where prefix-lists are used to select a subset of prefixes that should then undergo a route-map rule.
- Prefix-lists, route-maps, and access-lists assess rules in order of increasing numeric ID, NOT from top-to-bottom order (i.e., Rule 10 is always assessed before Rule 20, even if Rule 10 was located below Rule 20 in the configuration).
It is a good idea to put spacing in-between the rule IDs in case new rules need to be added in-between existing rules (for example, with existing Rules 10 and 20, it is simple to add Rule 15 anywhere in the prefix-list config since it is always assessed after rule 10 and before rule 20). - Prefix-lists, route-maps, and access-lists all have implicit-deny rules, and this is why Rule 20 was added to permit the 'any' prefix. If this rule did not exist, then no prefixes would be matched/permitted by this prefix-list (Rule 10 would drop 10.10.1.0/24, and the implicit_deny would drop the remaining prefixes).
Note that permit is the default action for a configured prefix-list rule, and so it will not appear when using the show command (but will appear with show full-configuration).
- Apply the prefix-list in the outbound direction in the BGP neighbor configuration:
set network-import-check disable
config neighbor
set remote-as 101
Before configuring/applying the prefix-list:
VRF 0 BGP table version is 3, local router ID is 172.31.135.228
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight RouteTag Path
*> 10.10.1.0/24 10.5.23.228 100 32768 0 i <-/->
*> 192.168.1.0 10.5.23.228 100 32768 0 i <-/->
*> 192.168.2.0 10.5.23.228 100 32768 0 i <-/->
Total number of prefixes 3
FortiGate-A # get router info bgp neighbors 10.5.20.160 advertised-routes
VRF 0 BGP table version is 2, local router ID is 172.31.135.228
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight RouteTag Path
*> 192.168.1.0 10.5.23.228 100 32768 0 i <-/->
*> 192.168.2.0 10.5.23.228 100 32768 0 i <-/->
Total number of prefixes 2
Troubleshooting:
The BGP debugging will share that the outgoing prefix list is being applied:
diagnose debug reset
diagnose ip router bgp all enable
diagnose ip router bgp level info
diagnose debug enable
BGP: Router_ID-Outgoing [FSM] State: OpenConfirm Event: 26
id=20300 msg="BGP: %BGP-5-ADJCHANGE: VRF 0 neighbor Router_ID Up "
BGP: Router_ID-Outgoing [RIB] Announce Check: 10.10.1.0/24 is filtered
BGP: [RIB] Scanning BGP Network Routes for VRF 0...
BGP: Router_ID-Outgoing [FSM] State: Established Event: 5
To stop the debugging:
diagnose debug disable
diagnose ip router bgp all disable
diagnose ip router bgp level none
Note:
The BGP will advertise routes that are in the routing table of the FortiGate. If the prefix-list does not match the routes in the routing-table, it will not be advertised. An option is to use the 'ge' or 'le' operator to match routes.
Related articles: