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 ...). 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:
config router prefix-list
edit 'blockrule'
config rule
edit 10
set action deny
set prefix 10.10.1.0 255.255.255.0
unset ge
unset le
set prefix 10.10.1.0 255.255.255.0
unset ge
unset le
next
edit 20
edit 20
set prefix any
unset ge
unset le
unset ge
unset le
next
end
next
end
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:
config router bgp
set as 100
set network-import-check disable
config neighbor
set network-import-check disable
config neighbor
edit '10.5.20.160'
set prefix-list-out 'blockrule'
set remote-as 101
set remote-as 101
next
end
end
In this case, prefix-list-out was used to filter outgoing advertisements from FortiGate-A towards FortiGate-B. To control prefixes being received and accepted into the BGP RIB, apply the prefix-list in the inbound direction using the prefix-list-in option instead.
Results:
Before configuring/applying the prefix-list:
Before configuring/applying the prefix-list:
FortiGate-A # get router info bgp neighbors 10.5.20.160 advertised-routes
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
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
After configuring/applying the prefix-list (10.10.1.0/24 no longer being advertised). Note that there may be a several-second delay before the list is updated, as BGP must wait for the advertisement-interval to elapse before it can advertise the new list of prefixes:
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 ip router bgp all en
diagnose ip router bgp level info
diagnose debug en
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
Related articles:
