BGP Filtering

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.

Route Filtering



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 you 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 command access−list 1 permit 160.0.0.0 0.255.255.255 permits 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 101 160.0.0.0 0.255.255.255 255.0.0.0 0.0.0.0. This list permits 160.0.0.0/8 only.

Another type of filtering is path filtering, which is described in the next section.

Path Filtering



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 stops 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, this update matches the access list and will be denied.

The .* is another regular expression with the period 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 use the show ip bgp regexp regular expression> command. This shows all the paths that have matched the configured regular expression.

0 Comments: