Sending and receiving BGP updates can be controlled by using a number of different filtering methods. BGP updates can be filtered based on route information, on path information or on communities. All methods will achieve the same results, choosing one over the other depends on the specific network configuration.
In order to restrict the routing information that the router learns or advertises, you can filter BGP based on routing updates to or from a particular neighbor. In order to achieve this, an access-list is defined and applied to the updates to or from a neighbor. Use the following command in the router configuration mode:
Neighbor {ip-address|peer-group-name} distribute-list access-list-number {in | out}
In the following example, RTB is originating network 160.10.0.0 and sending it to RTC. If RTC wanted to stop those updates from propagating to AS100, we would have to apply an access-list to filter those updates and apply it when talking to RTA:
RTC#
router bgp 300
network 170.10.0.0
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 distribute-list 1 out
access-list 1 deny 160.10.0.0 0.0.255.255
access-list 1 permit 0.0.0.0 255.255.255.255
(filter out all routing updates about 160.10.x.x)
Using access-lists is a bit tricky when we are dealing with supernets that might cause some conflicts.
Assume in the above example that RTB has different subnets of 160.10.X.X and our goal is to filter updates and advertise only 160.0.0.0/8 (this notation means that we are using 8 bits of subnet mask starting from the far left of the IP address; this is equivalent to 160.0.0.0 255.0.0.0)
The following access list:
access-list 1 permit 160.0.0.0 0.255.255.255
will permit 160.0.0.0/8,160.0.0.0/9 and so on. In order to restrict the update to only 160.0.0.0/8 we have to use an extended access list of the following format:
access-list
ex: access-list 101 160.0.0.0 0.255.255.255 255.0.0.0 0.0.0.0
This list will permit 160.0.0.0/8 only.
Another type of filtering, is path filtering which is described in the next section.
You can specify an access list on both incoming and outgoing updates based on the BGP autonomous system paths information. In the above figure we can block updates about 160.10.0.0 from going to AS100 by defining an access list on RTC that prevents any updates that have originated from AS200 from being sent to AS100. To do this use the following statements.
ip as-path access-list access-list-number {permit|deny} as-regular-expression
neighbor {ip-address|peer-group-name} filter-list access-list-number {in|out}
The following example will stop RTC from sending RTA updates about 160.10.0.0
RTC#
router bgp 300
neighbor 3.3.3.3 remote-as 200
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 filter-list 1 out (the 1 is the access list number below)
ip as-path access-list 1 deny ^200$
ip as-path access-list 1 permit .*
In the above example, access-list 1 states: deny any updates with path information that start with 200 (^) and end with 200 ($). The ^200$ is called a regular expression, with ^ meaning starts with and $ meaning ends with. Since RTB sends updates about 160.10.0.0 with path information starting with 200 and ending with 200, then this update will match the access list and will be denied.
The .* is another regular expression with the dot meaning any character and the * meaning the repetition of that character. So .* is actually any path information, which is needed to permit all other updates to be sent.
What would happen if instead of using ^200$ we have used ^200
If you have an AS400 (see figure above), updates originated by AS400 will
have path information of the form (200, 400) with 200 being first and 400
being last. Those updates will match the access list ^200 because they
start with 200 and will be prevented from being sent to RTA which is not
the required behavior.
A good way to check whether we have implemented the correct regular expression is to do:
sh ip bgp regexp <regular expression>.
This will show us all the path that has matched the configured regular expression.
Regular expressions sound a bit complicated but actually they are not. The next section will explain what is involved in creating a regular expression.
A regular expression is a pattern to match against an input string. By building a regular expression we specify a string that input must match. In case of BGP we are specifying a string consisting of path information that an input should match.
In the previous example we specified the string ^200$ and wanted path information coming inside updates to match it in order to perform a decision.
The regular expression is composed of the following:
A- Ranges:
A range is a sequence of characters contained within left and right square
brackets. ex: [abcd]
B- Atoms
An atom is a single character
. (Matches any single character)
^ (Matches the beginning of the input string)
$ (Matches the end of the input string)
\character (Matches the character)
- (Matches a comma (,), left brace ({), right brace (}), the beginning
of the input string, the end of the input string, or a space.
C-Pieces
A piece is an atom followed by one of the symbols:
* (Matches 0 or more sequences of the atom)
+ (Matches 1 or more sequences of the atom)
? (Matches the atom or the null string)
D- Branch
A branch is a 0 or more concatenated pieces.
Examples of regular expressions follow:
a* any occurrence of the letter a, including none
a+ at least one occurrence of a should be present
ab?a this will match aa or aba
ex:
_100_(via AS100)
^100$ (origin AS100)
^100 .* (coming from AS100)
^$ (originated from this AS)
We have already seen route filtering and as-path filtering. Another method is community filtering. Community has been discussed previously and here are few examples of how we can use it.
We would like RTB above to set the community attribute to the BGP routes it is advertising such that RTC would not propagate these routes to its external peers. The no-export community attribute is used:
RTB#
router bgp 200
network 160.10.0.0
neighbor 3.3.3.1 remote-as 300
neighbor 3.3.3.1 send-community
neighbor 3.3.3.1 route-map setcommunity out
route-map setcommunity
match ip address 1
set community no-export
access-list 1 permit 0.0.0.0 255.255.255.255
Note that we have used the route-map setcommunity in order to set the community to no-export. Note also that we had to use the "neighbor send-community" command in order to send this attribute to RTC.
When RTC gets the updates with the attribute no-export, it will not propagate them to its external peer RTA.
Example 2:
RTB#
router bgp 200
network 160.10.0.0
neighbor 3.3.3.1 remote-as 300
neighbor 3.3.3.1 send-community
neighbor 3.3.3.1 route-map setcommunity out
route-map setcommunity
match ip address 2
set community 100 200 additive
access-list 2 permit 0.0.0.0 255.255.255.255
In the above example, RTB has set the community attribute to 100 200 additive. The value 100 200 will be added to any existing community value before being sent to RTC.
A community list is a group of communities that we use in a match clause of a route map which allows us to do filtering or setting attributes based on different lists of community numbers.
ip community-list community-list-number {permit|deny} community-number
For example we can define the following route map, match-on-community:
route-map match-on-community
match community 10 (10 is the community-list number)
set weight 20
ip community-list 10 permit 200 300 (200 300 is the community number)
We can use the above in order to filter or set certain parameters like weight and metric based on the community value in certain updates. In example two above, RTB was sending updates to RTC with a community of 100 200. If RTC wants to set the weight based on those values we could do the following:
RTC#
router bgp 300
neighbor 3.3.3.3 remote-as 200
neighbor 3.3.3.3 route-map check-community in
route-map check-community permit 10
match community 1
set weight 20
route-map check-community permit 20
match community 2 exact
set weight 10
route-map check-community permit 30
match community 3
ip community-list 1 permit 100
ip community-list 2 permit 200
ip community-list 3 permit internet
In the above example, any route that has 100 in its community attribute will match list 1 and will have the weight set to 20. Any route that has only 200 as community will match list 2 and will have weight 20. The keyword exact states that community should consist of 200 only and nothing else. The last community list is here to make sure that other updates are not dropped. Remember that anything that does not match, will be dropped by default. The keyword internet means all routes because all routes are members of the internet community.
The neighbor command can be used in conjunction with route maps to perform either filtering or parameter setting on incoming and outgoing updates.
Route maps associated with the neighbor statement have no affect on incoming updates when matching based on the IP address:
neighbor ip-address route-map route-map-name
Assume in the above diagram we want RTC to learn from AS200 about networks that are local to AS200 and nothing else. Also, we want to set the weight on the accepted routes to 20. We can achieve this with a combination of neighbor and as-path access lists.
Example 1:
RTC#
router bgp 300
network 170.10.0.0
neighbor 3.3.3.3 remote-as 200
neighbor 3.3.3.3 route-map stamp in
route-map stamp
match as-path 1
set weight 20
ip as-path access-list 1 permit ^200$
Any updates that originate from AS200 have a path information that starts with 200 and ends with 200 and will be permitted. Any other updates will be dropped.
Example 2:
Assume that we want the following:
1- Updates originating from AS200 to be accepted with weight 20.
2- Updates originating from AS400 to be dropped.
3- Other updates to have a weight of 10.
RTC#
router bgp 300
network 170.10.0.0
neighbor 3.3.3.3 remote-as 200
neighbor 3.3.3.3 route-map stamp in
route-map stamp permit 10
match as-path 1
set weight 20
route-map stamp permit 20
match as-path 2
set weight 10
ip as-path access-list 1 permit ^200$
ip as-path access-list 2 permit ^200 600 .*
The above statement will set a weight of 20 for updates that are local to AS200, and will set a weight of 10 for updates that are behind AS400 and will drop updates coming from AS400.
In some situations we are forced to manipulate the PATH information in order to manipulate the BGP decision process. The command that is used with a route map is:
set as-path prepend
Suppose in the above diagram that RTC is advertising its own network 170.10.0.0 to two different ASs: AS100 and AS200. When the information is propagated to AS600, the routers in AS600 will have network reachability information about 150.10.0.0 via two different routes, the first route is via AS100 with PATH (100, 300) and the second one is via AS400 with PATH (400, 200,300). Assuming that all other attributes are the same AS600 will pick the shortest path and will choose the route via AS100.
AS300 will be getting all its traffic via AS100. If we want to influence this decision from the AS300 end we can make the PATH through AS100 look like it is longer than the PATH going through AS400. We can do this by prepending autonomous system numbers to the existing path info advertised to AS100. A common practice is to repeat our own AS number using the following:
RTC#
router bgp 300
network 170.10.0.0
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 route-map SETPATH out
route-map SETPATH
set as-path prepend 300 300
Because of the above configuration, AS600 will receive updates about 170.10.0.0 via AS100 with a PATH information of: (100, 300, 300, 300) which is longer than (400, 200, 300) received from AS100.
A BGP peer group, is a group of BGP neighbors with the same update policies. Update policies are usually set by route maps, distribute-lists and filter-lists, etc. Instead of defining the same policies for each separate neighbor, we define a peer group name and we assign these policies to the peer group.
Members of the peer group inherit all of the configuration options of the peer group. Members can also be configured to override these options if these options do not affect outbound updates; you can only override options set on the inbound.
To define a peer group use the following:
neighbor peer-group-name peer-group
In the following example we will see how peer groups are applied to internal and external BGP neighbors.
Example 1:
RTC#
router bgp 300
neighbor internalmap peer-group
neighbor internalmap remote-as 300
neighbor internalmap route-map SETMETRIC out
neighbor internalmap filter-list 1 out
neighbor internalmap filter-list 2 in
neighbor 5.5.5.2 peer-group internalmap
neighbor 6.6.6.2 peer-group internalmap
neighbor 3.3.3.2 peer-group internalmap
neighbor 3.3.3.2 filter-list 3 in
In the above configuration, we have defined a peer group named internalmap and we have defined some policies for that group, such as a route map SETMETRIC to set the metric to 5 and two different filter lists 1 and 2. We have applied the peer group to all internal neighbors RTE, RTF and RTG. We have defined a separate filter-list 3 for neighbor RTE, and this will override filter-list 2 inside the peer group. Note that we could only override options that affect inbound updates.
Now, let us look at how we can use peer groups with external neighbors. In the same diagram we will configure RTC with a peer-group externalmap and we will apply it to external neighbors.
Example 2:
RTC#
router bgp 300
neighbor externalmap peer-group
neighbor externalmap route-map SETMETRIC
neighbor externalmap filter-list 1 out
neighbor externalmap filter-list 2 in
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 peer-group externalmap
neighbor 4.4.4.2 remote-as 600
neighbor 4.4.4.2 peer-group externalmap
neighbor 1.1.1.2 remote-as 200
neighbor 1.1.1.2 peer-group externalmap
neighbor 1.1.1.2 filter-list 3 in
Note that in the above configs we have defined the remote-as statements outside of the peer group because we have to define different external ASs. Also we did an override for the inbound updates of neighbor 1.1.1.2 by assigning filter-list 3.
(End of section 3)