BGP Configuration

Excerpts of Quagga configuration

Filtering
Filters are applied both to incoming routes announced by neighbours, before they enter the routing information base (RIB), as well as before announcing them to neighbours.

For example, announcements of bogon IP addresses are filtered from incoming neighbours, and routing entries of peers and providers are filtered from the routing database when making announcements to peers and providers (you only announce your own IP ranges, and IP ranges of your clients to these neighbours).

There are four different filters: filter-list, prefix-list, distribute-list, filter-list and route-map. They are applied in the following order:

For inbound updates:
 * 1) route-map
 * 2) filter−list
 * 3) prefix−list, distribute−list (mutually exclusive, use only one of these)

For outbound updates the order of preference is:
 * 1) prefix−list, distribute−list (mutually exclusive, use only one of these)
 * 2) filter−list
 * 3) route−map

(source: BGP FAQ)

Debugging Filters
Filters are applied at two stages: incoming filters from the Adj-RIB-in to the Loc-RIB, and outgoing filters from the Loc-RIB to the Adj-RIB-out. (The Adj-RIB-in contains route advertisements received by neighbours, Loc-RIB contains all accepted routes, and the Adj-RIB-out contains routes to be advertised to neighbours.)

Unfortunately, Quagga and most other BGP implementations only allow you to examine the Loc-RIB table, not the Adj-RIB-in tables or the Adj-RIB-out tables. This makes debugging hard. For example, the command show ip bgp neighbour 192.0.2.0 routes does not show you the complete Adj-RIB-in from 192.0.2.0, but merely those routes from 192.0.2.0 that made it into the Loc-RIB after filtering.

Prefix List
A prefix list describes a list of permitted and denied IP ranges. It is more powerful than access lists.

The following example defines prefix list no-private-ip, which deny private IP ranges (including link-local and documentation ranges): ip prefix-list no-private-ip description Filter bogons ip prefix-list no-private-ip deny 0.0.0.0/8 ip prefix-list no-private-ip deny 10.0.0.0/8 ip prefix-list no-private-ip deny 127.0.0.0/8 ip prefix-list no-private-ip deny 169.254.0.0/16 ip prefix-list no-private-ip deny 172.16.0.0/12 ip prefix-list no-private-ip deny 192.0.2.0/24 ip prefix-list no-private-ip deny 192.168.0.0/16 ip prefix-list no-private-ip deny 240.0.0.0/4 ip prefix-list no-private-ip permit any

For an example with IPv6, see the IPv6 bogon filter list.

The following example defines the prefix list prefix-size-filter denies unyieldingly small (smaller than /24) or very large (bigger than /8) address blocks. ip prefix-list prefix-size-filter description Filter too large and too small IP blocks ip prefix-list prefix-size-filter seq 5 deny 0.0.0.0/0 le 7 ip prefix-list prefix-size-filter seq 6 deny 0.0.0.0/0 ge 25 ip prefix-list prefix-size-filter seq 100 permit any

The second example explicitly defines the sequence numbers of the rules. In the first example, the sequence is taken from the order in the list.

The following example applies both example filters to filter incoming route announcements from the neighbour with IP 192.0.20.

neighbor 192.0.2.0 prefix-list no-private-ip in neighbor 192.0.2.0 prefix-list prefix-size-filter in

If you use the neighbor prefix-list command or the neighbor distribute-list more than once specifying the same IP address or peer group, only the last list is applied. Thus, prefix list can not be used in conjunction with distribute list for a specific neighbour.

A prefix list can also be used with route-maps.

ip prefix-list MYPREFIXLIST permit 192.0.2.0/24 route-map MYROUTEMAP permit 10 match ip address prefix-list MYPREFIXLIST

Do not forget the prefix-list keyword in the match line. Leaving it out will make Quagga look for a access-list called MYPREFIXLIST, and if that does not exist, it will simply assume an empty access-list, without giving a warning.

Distribute Lists / Access Lists
An access list describes a list of permitted and denied IP ranges. It is less powerful than prefix lists (prefix lists can also filter based on the network size, and can specify sequence numbers manually).

The following example defines access list no-private-ip, which deny private IP ranges: access-list no-private-ip deny 10.0.0.0/8 access-list no-private-ip deny 172.16.0.0/12 access-list no-private-ip deny 192.168.0.0/16 access-list no-private-ip permit any

The following example applies this access list to filter incoming route announcements from the neighbour with IP 192.0.20.

neighbor 192.0.2.0 distribute-list no-private-ip in

If you use the neighbor distribute-list command or the neighbor prefix-list more than once specifying the same IP address or peer group, only the last list is applied. Thus, distribute list can not be used in conjunction with prefix list for a specific neighbour.

An access list can also be used with route-maps:

access-list MYACCESSLIST permit 192.0.2.0 route-map MYROUTEMAP permit 10 match ip address MYACCESSLIST

Filter Lists / AS Path Access Lists
A filter list describes a list of permitted and denied AS paths.

The following example defines AS path access list avoid-rival, which forbids all AS paths with the AS number of a competitor, 65192.

ip as-path access-list avoid-rival deny _65192_ ip as-path access-list avoid-rival permit any

The AS list is actually a regular expression. All POSIX regular expression can be used. In addition, the _ (underscore) character has the special meaning that it matches an AS value boundary (comma, left brace, right brace, the beginning of an input string, the end of an input string, or a space).

Example regular expressions:

The following example applies AS path filter avoid-rival to all incoming route announcements from the neighbour with IP 192.0.20. (This attempt to avoid that traffic passes through the given AS is of course feeble, since it assumes all ASes are to be trusted, and only applies to outgoing traffic.)

neighbor 192.0.2.0 filter-list avoid-rival in

If you use the neighbor filter-list command more than once specifying the same IP address or peer group, only the last list-name defined is applied.

An access list can also be used with route-maps:

route-map MYROUTEMAP permit 10 match as-path avoid-rival

Route Maps
Route maps are the work horse of route filtering. They not only filter routing entries, but can also modify routing entries. Route maps consist of a list of match and set configuration commands. The match commands specify match criteria and the set commands specify the action taken if the match criteria are met.

Processing Logic
Each route-map, has an order and 'matching policy' (either 'permit' or 'deny'). Furthermore, it can define match entries, set entries, call entries and/or an exit condition.


 * match: Check if match conditions matches.
 * If there is a match, and the 'matching policy' is 'permit', perform the actions below.
 * If there is a match, and the 'matching policy' is 'deny', stop processing and return 'deny'
 * If nothing matching, goto next route-map


 * action: Perform the following actions
 * Apply set statements
 * If a call statement is present, call given route-map. If that returns a 'deny', finish processing and return 'deny'.
 * If 'Exit Policy' is 'next', goto next route-map
 * If 'Exit Policy' is 'goto', goto first entry whose order in the list is >= the given order. It is 'never possible to jump to an earlier route-map.
 * Finish processing the route-map and permit the route.

Examples
The following example defines a route-map INCOMING, which will make two checks. First, if the as-path matched avoid-rival, it set the local preference very low. Second, if the announced IP range matches no-private-ip access list, it will mark the route entry with the special community "no export". The empty third and final check is crucial: it is a permit matching anything. If that one would not be present, the default would be a deny route map for every route that did not match entry 1 or entry 2.

route-map INCOMING permit 1 match as-path match-rival set local-preference 10 route-map INCOMING permit 2 match ip address prefix-list private-ip-prefix-list set community additive no-export route-map INCOMING permit 3 match ip address private-ip-access-list set community additive no-export route-map INCOMING permit 4

Filter entry #2 and #3 are very similar. However, note the "prefix-list" keyword, which is required for prefix lists. (Leaving it out will give you headaches in debugging.)

Note that the matches here are exactly the opposite of the example filters avoid-rival and no-private-ip. There, we denied AS 65192 and private IP ranges. For these matches we must allow (match), not deny. E.g. for match-rival:

ip as-path access-list match-rival permit _64644_ ip as-path access-list match-rival deny any

Again, this is counter-intuitive. In the following example, AS paths with ASN 64642 are denied (due to the deny in route-map RM-PEER-IN deny 10</tt>), not allowed -- the permit in ip as-path access-list avoid-rival permit _64642_</tt> is not a 'permit', but merely a positive match. Also, the deny</tt> in the AS-path avoid-rival does not mean that those routes are denied, but merely that there is no match for that route map entry, and the processing jumps to the next route map entry, which set the local preference to 90. In addition, the set local-preference 91</tt> is never executed, since the actions in a route map with 'Matching Policy' 'deny' (such as here) are never executed.

ip as-path access-list avoid-rival permit _64642_ ip as-path access-list avoid-rival deny any route-map RM-PEER-IN deny 10 match as-path avoid-rival set local-preference 91 route-map RM-PEER-IN permit 20 set local-preference 90

So in short, the logic of the above example is:
 * routes with ASN 64642 in their AS path are denied
 * All other routes get local-preference 90

The following example applies the route-map to the incoming routes of neighbour 192.0.2.0.

neighbor 192.0.2.0 route-map INCOMING in

Routing decision process
A router chooses the most preferable path to a destination based on configured policies and the following rules of path selection (rules 1-3 apply to all protocols, rules 4-9 apply only to routes learned from BGP sessions):


 * 1) What are the most specific entries (the longest prefix match) in the routing table?
 * 2) Is the next hop accessible?
 * 3) Protocol preference (also known as administrative distance (AD) or administrative weight) check (highest wins. Default: 32768 for static, 200 for iBGP, 20 for eBGP)
 * 4) Local preference check (highest wins. Default: 100)
 * 5) Local route check (local routes take precedence)
 * 6) AS path length check (shortest path wins)
 * 7) Origin check (first routes learned from IGP peers, than EGP, than redistributed from other sources)
 * 8) Multi-Exit Discriminator (MED) check (lowest value wins. Default: 0)
 * 9) Lowest BGP router ID (fallback mechanism)

Parameters
A Transitive value may not be changed when it is forwarded by third parties.

Traffic Engineering
Traffic Engineering is the process of modifying one of the parameters in the BGP decision process, so that a certain route is chosen.

Outbound Traffic Engineering (This works by manipulating incoming routes):
 * Changing local preference
 * Extending inbound AS paths
 * Manipulating the metric (MED)
 * Use inbound communities

Inbound Traffic Engineering (This works by manipulating outgoing routes):
 * Manipulating the metric (MED) is the traditional way
 * Extending outbound AS paths is a traditional hack
 * Setting outbound communities is the more modern approach
 * Last resort method: announcing more specific routes

Typically, local preference is used to enforce relation type (customer, peer or provider). MED or communities are used for traffic engineering.

Routing Instability
The use of traffic engineering tricks may lead to instability.

For example, it is possible to create flapping behaviour even by simply preferring longer routes than shorter routes. Since flapping behaviour creates "BGP ripples" throughout the Internet, it should be avoided.

The use of MED or communities (basically any behaviour that depends on attributes send to peers), the network may not restore correctly after a failure.

See the Bad Gadget and BGP Wedgies examples by Timothy Griffin for more information.

Enforce Relations
local preferences is typically used to enforce relations (highest value wins):

In this scenario, traffic is routed to customers if possible (they typically pay for the traffic), peers otherwise, and providers as a last resort (that traffic typically costs money).

For example: ! define 3 types of neighbours: upstream (transit) provider, peer, and customer. neighbor UPSTREAM peer-group neighbor UPSTREAM route-map RM-UPSTREAM-IN in neighbor PEER     peer-group neighbor PEER    route-map RM-PEER-IN      in neighbor CUSTOMER peer-group neighbor CUSTOMER route-map RM-CUSTOMER-IN in neighbor 172.16.0.41 remote-as 64641 neighbor 172.16.0.41 peer-group UPSTREAM neighbor 172.16.0.41 description Transit Provider AS 64641 neighbor 172.16.0.43 remote-as 64643 neighbor 172.16.0.43 peer-group PEER neighbor 172.16.0.43 description Peer AS 64643 neighbor 172.16.0.45 remote-as 64645 neighbor 172.16.0.45 peer-group CUSTOMER neighbor 172.16.0.45 description Client AS 64645 route-map RM-UPSTREAM-IN permit 10 set local-preference 80 route-map RM-PEER-IN permit 10 set local-preference 90 route-map RM-CUSTOMER-IN permit 10 set local-preference 100

Communities
Communities are optional attributes for routes. They are not used in the route selection itself, but can be used to "tag" certain routing entries, which can be used for filtering or setting the local preference.

A prime example is to use communities to tag routes learnt from customers, peers and providers. All of these routes appear in the local routing database, but only routes from customers should be announced to peers and providers. Tagging these routes with a community is the most elegant way to implement this.

A routing entry can be part of none, one or multiple communities.

Communities can be local to an AS, or be announced to other domains.

Community Values
A community is a 4-byte integer. By convention, the first two bytes are the ASN of the AS that applies a policy based on the community. In addition, there are a few well-known communities.


 * AS:VAL :Custom community to define a AS oriented policy. For example, 64644:80 can be used when AS 64644 wants to pass local policy value 80 to neighboring peer or vice versa.
 * no-advertise:Well-known communities value NO_ADVERTISE. Route entries with this attribute must not be advertised to other BGP peers, not even those in the same AS.
 * local-AS:Well-known communities value NO_EXPORT_SUBCONFED. Route entries with this attribute must not be advertised to external BGP peers.
 * no-export:Well-known communities value NO_EXPORT. Route entries with this attribute must not be advertised to outside a BGP confederation boundary.
 * internet:Well known community internet. Route entries with this attribute can be announced to all other routers in the Internet.
 * none:Not an actual community. Apply no community attribute when you want to clear the communities associated with a route.

Setting a Community
The following example defines a route map that sets the community to no-export.

route-map RM-LOCAL-IN permit 10 set community no-export

The following example defines a route map that adds community 65 (of AS 64641) to the route entry.

route-map RM-PEER-IN permit 10 set community 64641:65 additive

Matching a Community
To match a community, you must first define a community list. The following example defines a communities list seventies, and a route map that adds the community to 108 if the community was 71, 72 or 73.

ip community-list seventies description Community Filter seventies ip community-list seventies permit 64641:71 ip community-list seventies permit 64641:72 ip community-list seventies permit 64641:73 ip community-list seventies deny any route-map community108 10 permit match community seventies set community 64641:108 additive route-map community108 20 permit

Quagga adds a few more options to IP community lists. First of all, it has expanded communities, which are communities with regular expressions. The following example matches all communities in the ragne 2000 to 2999 (a dot . matches any character).

ip community-list expanded cme-prefmod-range permit 64512:2...

Quagga assumes that community lists which are a number between 100 and 199 are expanded community lists, and will do regular expression matching. For names which are a number between 0 and 99, it will never match regular expressions, and for other names (e.g. community108</tt> or cme-prefmod-range</tt>) Quagga will check what it should do. If this is confusing (I think it is), specify it explicitly using the "standard" or "expanded" keywords.

ip community-list standard CMLIST2k    permit 64512:2000 ip community-list expanded CMLIST2kplus permit 64512:2...

In addition, Quagga supports extended community lists. While it is possible to add multiple communities to a route entry, only one of these can be set in BGP messages to neighbours. An entry can have multiple extended communities, even when sending the community information to neighbours.

Example Configuration
The following example show a rather basic configuration.

It defines a router, myrouter, which talks bout OSPF and BGP. The routers is part of AS 64601, with allocated IP space 10.1.0.0/16. The router is placed in the subnet of an Internet exchange (172.16.0.0/12), and has four BGP neighbours:
 * An IGP session with 10.1.45.1, a router in the same AS
 * Router 172.16.0.112 for upstream provider AS 64712
 * Router 172.16.2.38 for peer AS 65312
 * Router 172.16.8.1 for customer AS 64801

Local preference are used to prefer traffic via customers over peers and providers. Communities are used to tag traffic and filter outgoing routes. This example does not define MED, and generally ignores the problem of hot versus cold potato routing. A real example will do more strict checking of customer route announcements. A customer announcing a full /8 o is too common, and you don't want that to destabilize your network.

If you build upon this example, it is important to decide on a good systems for community tags. Please look at real practice. For example, Dutch telecom provider has a nice system using tagging for both relation (customer/peer/transit) and origin of announcement (country code). Query whois for AS286 for more information.

! ! Quagga sample configuration file ! hostname myrouter password verysecret enable password yourwishismycommand ! router ospf ! OSPF is only active on links with an IP in this subnet. ! No need to specifically disable it on the external interface network 10.1.0.0/16 area 0 ! External routing information is distributed through the internal network redistribute bgp redistribute connected router bgp 64601 ! The router resides in the LAN of an Internet exchange with subnet 172.16.0.0/12 bgp router-id 172.16.0.1 network 10.1.0.0/16 ! We announce our full /16 range. ! We don't redistribute ODPF information, since that would announce individual /24 ranges. ! define three groups of connections: upstream providers, peers, and customers ! define route maps to filter incoming and outcoming route announcements ! next-hop-self ensures that transit traffic really goes through our router, ! even if the source and destination can reach each other (such as in a LAN) ! use route-map, filter-list, prefix-list or distribute-list to set filters. neighbor UPSTREAM peer-group neighbor UPSTREAM route-map RM-UPSTREAM-IN in     neighbor UPSTREAM route-map RM-PROVIDER-OUT out neighbor UPSTREAM next-hop-self neighbor PEER    peer-group neighbor PEER    route-map RM-PEER-IN  in     neighbor PEER     route-map RM-PROVIDER-OUT out neighbor PEER    next-hop-self neighbor CUSTOMER peer-group neighbor CUSTOMER route-map RM-CUSTOMER-IN in     neighbor CUSTOMER next-hop-self ! Internal neighbours (iBGP) neighbor 10.1.45.1 remote-as 64601 neighbor 10.1.45.1 description router 45 ! upstream provider neighbor 172.16.0.112 remote-as 64712 neighbor 172.16.0.112 peer-group UPSTREAM neighbor 172.16.0.112 description Transit Provider AS 64712 ! peer neighbor 172.16.2.38 remote-as 65312 neighbor 172.16.2.38 peer-group PEER neighbor 172.16.2.38 description Peer AS 65312 ! client neighbor 172.16.8.1 remote-as 64801 neighbor 172.16.8.1 peer-group CUSTOMER neighbor 172.16.8.1 description Client AS 64801 ! Local Preferences: ! We prefer traffic via customers (thay pay for it), otherwise via peers, ! and via providers only as a last resort (since we pay for that) ! 75 custom (lowered) preference, may be configured by customers, peers or providers using community 2075 ! 80 providers (low preference) ! 85 custom (lowered) preference, may be configured by customers or peers using community 2085 ! 90 peers (medium preference) ! 95 custom (lowered) preference, may be configured by customers using community 2095 ! 100 customers (high preferences) ! Communities: ! We allow neighbours to announce routing entries to use with a community value that signifies ! that it is a low-preference route. This can be useful for backup connections which are not ! to be used unless there really is no other option. We never allow neighbours to set a higher ! preference: that is something we decide upon. The reason we graciously allow lower preferences ! is that we rather receive announcements with low preference than no announcement at all. ! 64601:2075 (as sent by others): request to set local preference to 75 ! 64601:2085 (as sent by others): request to set local preference to 85 ! 64601:2095 (as sent by others): request to set local preference to 95 ! ! 64601:3080 (set by ourself): announcement learnt from upstream provider ! 64601:3090 (set by ourself): announcement learnt from peer ! 64601:3100 (set by ourself): announcement learnt from customer ! (note: our own routes have no community set) ! FILTERS (implemented using route maps) ! BUG ALERT: "on-match next" does not work for Zebra 0.94. ! This is fixed in Quagga 0.98.6, and likely earlier. ! This means that the route map entries that modify the local prefence ! based on a request by the neighbour are never executed. ! Route map for upstream providers. ! Block bogon IPs, make entry as coming from upstream using community 3080, and ! set low local-preference ! optionally allow the neighbour to lower to local preference even more (to 75) route-map RM-UPSTREAM-IN deny 10 match ip address prefix-list private-ip route-map RM-UPSTREAM-IN permit 20 set community 64601:3080 additive set local-preference 80 on-match next route-map RM-UPSTREAM-IN permit 30 match community localpref75 set local-preference 75 route-map RM-UPSTREAM-IN permit 40 ! Route map for peers. ! Block bogon IPs, make entry as coming from upstream using community 3090, and ! set medium local-preference ! optionally allow peers to lower to local preference (to 75 or 85) route-map RM-PEER-IN deny 10 match ip address prefix-list private-ip route-map RM-PEER-IN permit 20 set community 64601:3090 additive set local-preference 90 on-match next route-map RM-PEER-IN permit 30 match community localpref75 set local-preference 75 route-map RM-PEER-IN permit 40 match community localpref85 set local-preference 85 route-map RM-PEER-IN permit 50 ! Outgoing filters for peers and transit providers ! Filter routes from other peers (we don't provide transit for them), only announce ! our own routes and customer routes. route-map RM-PROVIDER-OUT deny 10 ! filter out route entries learnt from peers and upstream providers match community providers ! todo: remove the 3XXX communities in outgoing filters. Those are private, and not of anyone else's business. route-map RM-PROVIDER-OUT permit 20 ! empty route map entry, make sure all non-matching entries pass this filter ! Route map for customers. ! Block bogon IPs, make entry as coming from upstream using community 3100, and ! set a high local-preference ! optionally allow peers to lower to local preference (to 75, 85 or 95) route-map RM-CUSTOMER-IN deny 10 match ip address prefix-list private-ip route-map RM-CUSTOMER-IN permit 20 set community 64601:3100 additive set local-preference 100 on-match next route-map RM-CUSTOMER-IN permit 30 match community localpref75 set local-preference 75 route-map RM-CUSTOMER-IN permit 40 match community localpref85 set local-preference 85 route-map RM-CUSTOMER-IN permit 50 match community localpref95 set local-preference 95 route-map RM-CUSTOMER-IN permit 60 ! community list matching route entries learnt from peers and upstream providers ip community-list standard providers permit 64601:3080 ip community-list standard providers permit 64601:3090 ip community-list standard providers deny ! community list matching lower preference requests ip community-list standard localpref75 permit 64644:2075 ip community-list standard localpref85 permit 64644:2085 ip community-list standard localpref95 permit 64644:2095 ! For backup connections to a provider, you may create the following route-maps, ! provided that that provider has a similar community that allows neighbours to ! set the local preference. ! The following example is specific if AS 64715 is the provider of the backup connection. ! Incoming route map: Set local preference to a low 75. route-map RM-BACKUP-PROVIDER-IN permit 10 ! apply regular route map for upstream providers ! Calling other route maps requires Quagga 0.96.5 or higher. call RM-UPSTREAM-IN on-match next route-map RM-BACKUP-PROVIDER-IN permit 20 ! lower local-preference from 80 to 75 for backup connections set local-preference 75 ! Outcoming route map for backup connections ! Ask peer to set their local preference to a low 75. route-map RM-BACKUP-PROVIDER-OUT deny 10 ! apply regular route map for upstream providers call RM-PROVIDER-OUT on-match next route-map RM-BACKUP-PROVIDER-OUT permit 20 ! set community that asks AS 64715 to use a lower preference. ! communities are send, but since we don't add but replace the community here, ! private communities such as 3XXX are never announced to neighbors. set community 64715:2075 ! Prefix list matching private IP ranges, bogons, and other suspicious IP range announcements. ! Any 'permit' here is a match (not really a 'permit') which is BLOCKED in incoming route map. ! Note: The le 32 also filters subnets of these bogon ranges. However, neigbours can still ! announce a large supernet which contains a bogon range (e.g. 169.254.0.0/15). So you likely ! want to do additional per-neighbour filtering, or peer with known bogon black hole servers. ip prefix-list private-ip description Private ranges, large or small IP ranges ip prefix-list private-ip permit 0.0.0.0/8 le 32 ! no filtering on 10.0.0.0 range for demo network !ip prefix-list private-ip permit 10.0.0.0/8 le 32 ip prefix-list private-ip permit 127.0.0.0/8 le 32 ip prefix-list private-ip permit 169.254.0.0/16 le 32 ip prefix-list private-ip permit 172.16.0.0/12 le 32 ip prefix-list private-ip permit 192.0.2.0/24 le 32 ip prefix-list private-ip permit 192.168.0.0/16 le 32 ip prefix-list private-ip permit 240.0.0.0/4 le 32 !ip prefix-list private-ip permit 0.0.0.0/0 le 7 le 32 ! stricter filtering on prefix sizes for demo network ip prefix-list private-ip permit 0.0.0.0/0 le 14 ip prefix-list private-ip permit 0.0.0.0/0 ge 25 ip prefix-list private-ip deny any log stdout