Strategies and BGP Policies
Different tools can be used to define the prefix ranges and to enforce policies by applying a filter or a complex route map. Prefixes can be selected “directly” (using access lists or better using prefix lists), per group of AS numbers (using AS-PATH and regular expressions) or using tagging based of a specific type of communities (well defined or customized, matched through an community list). Once the prefix is selected by the matching conditions, the routes can be either filtered (using filter-lists or distribute lists) or modified using set statements for in route-maps.
(1) Selecting the prefixes using an AS-PATH list and Regular Expressions (for filtering or route map policies)
AS-Path is a mandatory attribute. It is very important for eBGP path selection, being the default first metric used for path selection, preferred to MED or others in eBGP. It is also the most commonly used parameters for “political” agreements between ISP for transit. Some ISPs may transit, some not, therefore accepting or rejecting routes based on AS paths (together with advertising of prefix towards an eBGP ISP neighbor instead of another). The AS-PATH is automatically modified by egress eBGP peers when they advertise routes to eBGP neighbors, prepending the local AS to the AS-PATH vector.
When a route in injected by BGP (“network” or “redistribute” statements) the AS-PATH is created as an empty list on the peer originator, to be increased prepending each AS number when routes are advertised to eBGP neighbors (not to iBGP neighbors). AS-PATHs are in BGP binary attributes, but are transparently converted into strings, with each character or character sequence match-able via a regular expression used in an “ip as-path access-list” permit or deny statement.
=> Using AS-PATH access-list are the most efficient tool when policies need to be configured based on AS topology and not on specific prefix. AS-PATH access-list should be used whenever possible, specially in cases such:
– Willing the local AS to NOT being a Transit AS;
– Chosing a primary AS and a backup AS or mixtures in more complex AS topologies;
– Setting the inbound direction for part of the AS topology;
Regular Expression Operators:
. Matches ANY, SINGLE character
[ ] Matches the characters or a range of characters.
^ Matches the character or null string at the beginning of an input string.
? Matches zero or one occurrence of the preceding [pattern] or charachter (note: Precede question mark with Ctrl-V)
Matches zero or more sequences of the preceding [pattern] or charachter. Wildcard for any number of characters.
+ Matches one or more sequences of the preceding [pattern] or charachter.
$ Matches the character or null string at the end of an input string.
() Exact nest characters for matching. Separate endpoints of a range with a dash (-).
[] Single or multiple occurrence of a set op possible characters. Dash (-) can be used.
| Single occurrence of a set op possible characters. Dash (-) can be used.
_ Matches a separateor such: , { } or /space/
\ Remember a () group (\1 = the first group, \2 = the second etc.)
Atomic Examples:
[05-9] matches 0, 5, 6, 7, 8, 9 but not 1, 2, 3 or 4
^123 matches 1234, but not 01234
12?3 matches 13 and 123
123$ matches 123, 0123, 564656123 but not 1234
1235 matches any occurrence of the number 5 including none (123, 1235, 12355, etc.)
(18 )+ matches 18, “18 18”, etc. (at least one number 18 must be present)
(17) matches any number of occurrencies of the two-character string 17 (“”, 17, 171717, etc.)
[17] matches any number of occurrencies of the character 1 or 7 (“”, 1, 7, 11, 77 etc.)
1(1|7)7 matches 117 and 177, but not 17, 1177, 1117, or 1777
_1300_ matches any of the following: ^1300$ ^1300/space/ /space/1300 {1300, ,1300, {1300} ,1300,
Little more complex:
32|43 32OR 43
(32)|(43) 32 OR 43
[32] 3 or 2
[1-3] 1, 2 or up to 3
[13].[2-4] 12, 192, 1 2, 32 but not 125
(_21_|_22_)._3_ 21 3 OR 22 3
[13][2-4] 1, 2, 3, 12, 193, 1993, 188883, 1555554 but not 15
[13]?[2-4] 1, 2, 3, 12, 193 but not 1993, 188883, 1555554, 15
[13]+[2-4] 12, 193, 1993, 188883, 1555554 but not 1, 2, 3 15
^([0-9]+)(_\1) “1” “1 1” “1 1 1 1” “2” “3 3” “4 4 4 4”
^((54)+)(_\1) “54” “54 54” “
54 54 54 54“
Typical:
ip as-path access-list 1 permit .
=> the list matches ANY occurency
ip as-path access-list 1 permit ^$
=> the list matches routes injected by the local AS
ip as-path access-list 1 permit ^100$
=> the list matches routes directly injected by direct neighbor AS 100
ip as-path access-list 1 permit ^100_
=> the list matches routes coming from direct neighbor AS 100
ip as-path access-list 1 permit _100$
=> the list matches routes originated by AS 100
ip as-path access-list 1 permit _100_
=> the list matches routes passing through or originated by AS 100
ip as-path access-list 1 permit ^([0-9]+)(_\1)$
=> the list matches routes coming from whatever neighbor, with only that AS number eventually repeated several times (due to prepending). Note that ^ and $ can be, if required, removed (in case of transit). If the neighbor is a customer (non transit) than both ^ and $ should be used. Further the \1 means reuse the 1st group (that is [0-9]+) and the is needed because the prepended value can be zero, one or more times.
Practical uses:
AS-PATH are the easiest way to perform route-filtering to eBGP neighbor due to the different AS. For example if you want to accept in inbound only routes coming by the external AS and you want to send only the local AS generated routes:
router bgp 100
neighbor 162.108.21.4 remote-as 200
neighbor 162.108.21.4 filter-list 1 in
neighbor 162.108.21.4 filter-list 2 out
!
ip as-path access-list 1 permit ^100_ <<<<< Only AS path coming from AS 100
!
ip as-path access-list 2 permit ^$ <<<<< Only locally generated AS path
!
end
Useful:
“show ip bgp regexp <expression>” which return all routes in bgp table that match an expression.
Avoid being transit = announce only prefixes generated at your AS, without reporting any other AS brhind:
router bgp 3
no synchronization
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 filter-list 1 out
ip as-path access-list 1 permit ^$
Get only route from an AS and is customers only, not AS furhter away from them:
1 = generated by AS1
1 6 or 1 3 = AS6 and AS3 customer of AS1
1 3 2 = NOT this, that is transit for 2.
^1 ?[0-9]$ = anything coming from AS1 plus eventually at max another AS behind (the “?” means zero or 1 time, not more), whatever that customer of AS1 would be (that is “[0-9]” with “$” to say no more than that).
router bgp 3
no synchronization
neighbor 172.16.20.1 remote-as 1
neighbor 172.16.20.1 filter-list 1 in
ip as-path access-list 1 permit ^1 ?[0-9]$
Don’t get paths originated from a specific AS (note that a space is needed to say 123 but not 123XXXX)
ip as-path access-list 1 deny ^123 .
Don’t get paths transiting from a specific AS (note that a space is needed to say 123 but not 123XXXX)
ip as-path access-list 1 deny _123 .
ip as-path access-list 1 deny _123_
(2) Selecting the prefixes using Prefix lists:
Prefix lists are the main tool when policies need to be implemented on a per prefix basis (better alternative than Access Lists). To identify prefixes in filters or match statements in route-mpas use prefix lists.
router bgp 200
neighbor 162.108.21.8 remote-as 300
neighbor 162.108.21.8 prefix-list BLUE out
!
ip prefix-list BLUE seq 10 deny 0.0.0.0/0 le 7
ip prefix-list BLUE seq 20 permit 0.0.0.0/0 ge 8 le 24
ip prefix-list BLUE seq 30 deny 10.0.0.0/8 ge 8
ip prefix-list BLUE seq 40 deny 172.16.0.0/14 ge 14
ip prefix-list BLUE seq 50 deny 192.168.0.0/16 ge 16
ip prefix-list BLUE seq 60 permit 0.0.0.0/0 ge 8 le 24
Using distribute lists (ACLs) for filtering is quite similar (method not recommended):
router bgp 200
neighbor 162.108.21.8 remote-as 300
neighbor 162.108.21.8 distribute-list 1 in
!
access-list 1 permit 192.168.0.0 0.0.255.255
access-list 1 deny 0.0.0.0 255.255.255.255
(3) Selecting the prefixes using Community Tags (for route map policies)
Communities are BGP attributes (Optional, Transitional) used for tagging BGP routes. The purpouse of Communities is to group a number of routes together and, based on the attached community, apply decisions to further policy BGP behaviour. Typically communities are set to specify a group of routes based on the BGP speaker in order to apply other BGP attributes and decisions. Tagging BGP routes with different community attributes across autonomous system or physical boundaries can prevent the need to configure long lists of individual permit or deny statements.
=> use communities to signal a neighbor that the announcement are made through the local BGP speaker. When policies need to be applied based on a specific neighbor or location of provenience, communities provide the most efficient tool.
Communities are 32 bit values, always managed using Route-Maps. Originally they where displayed as single decimal32 bit value (0%65356). Newer IOS can express it, more usefully, as two 16 bitvalues, being the first the AS, separated by a “:”, as example 100:1. The command “ip bgp-community new-format” changes from old to new format. Communities are by default stripped outgoing advertisements to all (iBGP and eBGP)neighbors, unless the command “neighbor x.x.x.x send-community” is used.
Community list are used for creating list to be used in route-map match conditions. Community lists are in the form:
ip community-list 10 permit 100:1
ip community-list 20 permit 100:2 100:20
ip community-list 30 permit 100:2 100:30
Each numbered statement is in sequential OR. In each statement more communities are in AND conditions. Community lists 1-99 have this format. Community lists 101-199 are based on regular expressions. The match condition is expressed as:
“match community-list 10 {exact}”. The “exact” option specified that the match must be mutually exact.
NOTE: Four predefined communities are also available (supposed “neighbor x.x.x.x send-community” has already been stated):
internet -> routes tagged with this community are sent to both eBGP and iBGP neighs;
no-export -> routes tagged with this community are sent only to iBGP (and e-confederates);
local-as -> routes tagged with this community are sent only to iBGP neighs;
no-advertise -> routes tagged with this community are not sent;
Examples:
hostname RouterY
!
router bgp 100
neighbor 1.1.1.1 remote-as 200
neighbor 1.1.1.1 route-map SET_Community_to_Neighbor_X out
neighbor 1.1.1.1 send-community
!
route-map SET_Community_to_Neighbor_X permit 10
match as-path 1
set community 100:1
!
route-map SET_Community_to_Neighbor_X permit 20
set community 100:2 additive
hostname RouterX
!
router bgp 200
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 route-map Policy_on_Community_from_Neighbor_Y in
!
ip community-list 10 permit 100:1
ip community-list 20 permit 100:2
!
route-map Policy_on_Community_from_Neighbor_Y permit 10
match community-list 10
set local-preference 200
!
route-map Policy_on_Community_from_Neighbor_Y permit 20
match community-list 20
set local-preference 100
!
route-map Policy_on_Community_from_Neighbor_Y permit 30
set local-preference 50
Communities are not shown by the “show ip bgp” command, but using the more specific: “show ip bgp <prefix>”.
Useful, applying a show-filter to the available BGP table, are the commands:
“show ip bgp community <community>”
“show ip bgp community-list <community-list>”
Communities can be deleted as well: the “set comm-list delete” command allows communities to be removed.
Router(config)ip community-list 1 permit 231:10
Router(config)ip community-list 1 permit 231:20
Router(config)router bgp 45
Router(config-router)neighbor 10.6.2.5 remote-as 5
Router(config-router)neighbor 10.6.2.5 route-map inbound_delete in
Router(config-router)route-map inbound_delete permit 10
Router(config-route-map)set comm-list 1 delete
(4) Applying inbound/outbound filters from/to specific neighbors as policies.
Once it is defined which prefixes, group of prefixes or AS paths need to be policed, the policed need to be applied. Basically this means either completing filtering updates (normally in outbound, seldomly in inbound, better in this case using ORF) or modifying specific attributes in order to influence decisions (take care of BOTH inbound and outbound direction, though).
For filtering the available tools are:
– distribution-lists {in|out}, using ACLs (not recommended in BGP);
– prefix-list {in|out}, using prefix lists;
– filter-lists {in|out}, using AS-path ACLs;
(see examples further)
For explicit attribute based policing, the main tool is the route-map (with some neighbor command to set a default value of a attribute per neighbor if this is needed).
(5) Applying detailed policies using Route-Maps (outbound or inbound):
Route-Maps offer all match and set capabilities for matching prefixes and setting their attributes. They can be set in inbound direction from a neighbor or in outbound direction to a neighbor:
Usage: “neighbor x.x.x.x route-map <route-map-Name> <in|out>”
Notes:
– A “Permit ALL” is equivalent of a route-map permit statement with NO match condition specified.
– if a route-map is applied in IN/OUT and no match condition (or an explicit deny) is found, the route is discarded.
– in a route-map sequence numbers allow for a hierarchical OR conditions
– in a route-map more “match” statements can be made per sequence number. In this case there is an AND of conditions.
– A possible “continue” command can be used to subdivide actions in hierarchies of actions;
AND Condition: IF {Cond_A AND Cond_B) then set X
!
route-map RM permit 10
match Cond_A
match Cond_B
set X
OR Condition: IF {Cond_A OR Cond_B) then set X
!
route-map RM permit 10
match Cond_A
set X
!
route-map RM permit 20
match Cond_B
set X
Intersting example: using “other” match conditions to select prefixes:
RT(config-route-map) match ip address <ACL>
RT(config-route-map) match ip address prefix-list <name>
RT(config-route-map) match as-path path-list-number
RT(config-route-map) match community {<Community_List> | <Community-list-name> [exact]}
RT(config-route-map) match ip next-hop <ACL>
RT(config-route-map) match interface
RT(config-route-map) set community {community-number [additive]} | none
RT(config-route-map) set local-preference number-value
RT(config-route-map) set weight weight
RT(config-route-map) set origin {igp | egp as-number | incomplete}
RT(config-route-map) set as-path {tag | prepend as-path-string}
RT(config-route-map) set next-hop next-hop
RT(config-route-map) set metric <med-value>
RT(config-route-map) set dampening halflife reuse suppress max-suppress-time
RT(config-router) redistribute protocol [process-id] [route-map <map>]]
RT(config-router) network <ip-range> mask <net-mask> [route-map <map>]]
RT(config-router) aggregate <ip-range> <net-mask> [attribute-map <map>]] | [advertise-map <map>]
RT(config-router) aggregate <ip-range> <net-mask> [suppress-map <map>]] | summary-only
RT(config-router) neighbor <ip-add> [route-map <map>]] {in|out}
RT(config-router) neighbor <ip-add> [route-map <map>]] {in|out}
RT(config-router) neighbor <ip-add> advertise-map <Adv-pref_map> exist-map <IF_pref_exist_map>
RT(config-router) bgp inject-map <More_spec_To_Inject_map> exist-map <IF_Less_spec_prefix_exist_map>
router bgp 100
no synchronization
bgp router-id 150.1.4.4
redistribute connected route-map CONNECTED-to-OSPF
neighbor 161.1.34.3 remote-as 200
no auto-summary
!
route-map CONNECTED-to-OSPF permit 10
match interface Loopback0 FastEthernet0
!
end
(6) Using Policy-Lists within route maps for more compact configuration :
As a later development in IOS, BGP route map policy lists allow a network operator to group route map match clauses into named lists called policy lists. A policy list functions like a macro. When a policy list is referenced in a route map, all of the match clauses are evaluated and processed as if they had been configured directly in the route map.
Policy lists support only match clauses and do not support set clauses. Policy lists can be configured for all applications of route maps, including redistribution, and can also coexist, within the same route map entry, with match and set clauses that are configured separately from the policy lists. Policy lists are supported only by BGP and are not supported by other IP routing protocols.
=> Policy lists (like peer groups or templates) are just a tool for making BGP configuration more scalable.
(7) Route Map Operation with Continue Clauses, also for configuration easyness :
Another enhancement on route-map configuration is the introduction of the continue statement. When a continue clause is configured, the route map will continue to evaluate and execute match clauses in the specified route map entry after a successful match occurs. The continue clause can be configured to “go to” a specific route map entry by specifying the sequence number, or if a sequence number is not specified, the continue clause will go to the next sequence number. If a match clause exists, the continue clause is executed only if a match occurs. If no successful matches occur, the continue clause is ignored.
When a successful match occurs and a continue clause exists, the route map executes the set clauses and then goes to the specified route map entry. If a continue clause does not exist in the next route map entry, the route map will be evaluated normally. If a continue clause exists in the next route map entry but a match does not occur, the route map will not continue and will “fall through” to the next sequence number if one exists.
The main benefit of the “continue” command is in the possibility of not repeating a (group of) set command(s) on multiple statements. Suppose a general policy is to set the metric as 0 and add a basis community to all announce prefixes. A continue command can be used so that specific prefixes get their specific attributes and then all get the basic attributes:
route-map Outbound_Policy permit 10
match ip address prefix-list Specific_29
set community 100:12345
set as-path prepend 40000 40000
continue 100
!
route-map Outbound_Policy permit 20
match ip address prefix-list Specific_16
set as-path prepend 40000
continue 100
!
route-map Outbound_Policy deny 30
match ip address prefix-list Specific_30
!
route-map Outbound_Policy permit 100
set metric 0
set community 100:9999 additive
!
end
What policy, then? And where/when?
All BGP tools to select, inject routes and modify their attributes sent (or received), should follow an appropriate use. BGP is rather free in allowing administrator’s implementation: modifying the standard behaviour almost everything is possible, with only a few constraints (most of them customizable):
[eBGP and iBGP]
– The next hop must be known in RIB (that’s nothing you can do about it, but the next hop can at lieast be modified with a “set ip next-hop” statement in an inbound route-map);
– The order of comparison of BGP attribute is pre-defined (some attribute, though can be ignored if required: “bgp bestpath as-path ignore”, “no bgp bestpath compare-routerid”, “bgp bestpath cost-community ignore”);
– By default there is no limiting to the number of prefixes that the routing process will accept (it can be set, though, per neighbor basis)
– By default flapping routes are acceptable once the BGP peers insert them in the BGP table. Configuring BGP prefix dampening can help such fluctuations;
[eBGP]
– There cannot be a loop in the AS-PATH (but can be worked around, via policy on AS-PATH or using “bgp bestpath as-path ignore”);
– eBGP expects to have neighborship built on directly connected networks (can be overridden in case of multi-hop and single-hop, using other interfaces as peering points via “update-source”);
– eBGP does not propagate the Local_Pref attribute, while iBGP does not propagate the MED attribute;
– MED is optional, sometimes even missing. Policy should not use MED unless agreed, but MEd by default is part of the selection algorythm (“bgp always-compare-med”, “bgp bestpath med confed” and “bgp bestpath med missing-as-worst” can alter MED usage influence);
[iBGP]
– iBGP “no synchronization” will suppose full-mesh, or either Route Reflector(s) or Confederation in order to be safe and not create a blackhole;
– iBGP does not modify the next hop, like eBGP does (both behaviours can be overridden using the “neighbor next-hop-self” for iBGP or, at the opposite, “neighbor next-hop-unchanged” for eBGP);
– iBGP routes should not be injected in the IGP table (can be worked around with the “bgp redistribute-internal”);
– iBGP route are subject to synchronization to the IGP table (but this is normally disabled);
Guidelines:
See: Connecting to a Service Provider Using eBGP
– using MED;
– using AS-path via outbound route-maps;
– using Weight in inbound;
– setting the Local_Pref for iBGP peers;
– using prefix-list filters in inbound (eventually with ORF);
– using AS-Path filter-list in inbound;
– using Communities (sending, adding, removing, evaluating) in outbound and inbound route-maps;
– using Route-maps for setting outbound attributes;
– using Route-maps for modifying inbound selection attributes (eventually with policy-list and continues statements);
See: Configuring iBGP Features (reducing full-mesch iBGP requirements):
– using Confederations
– using Route Reflectors
– setting the next-hop as the local iBGP router;