Route_server_with_community_based_filtering_and_multiple_ribs

Route server with community based filtering and multiple RIBs

The concept of the configuration is following:
Each IXP member has one or more BGP peers. Those BGP sessions are named R<AS#>x<#>. So for example, R25192x2 is the second BGP peer of a member with AS number 25192. All sessions are unfiltered (except max prefix limit) and connected to a routing table named T<AS#>. So it means that all prefixes received from R25192x1 and R25192x2 are stored in routing table T25192. So each AS has its own routing table. All those routing tables are connected to the master table by pipe protocols named P<AS#>. Filtering (both in and out) is applied inside those PIPE protocols. So it means that unwanted routes from AS1111 would be stored in routing table T1111 but would not go to the master routing table. From the master routing table all routes are distributed back into peer routing tables (with filtering - bgp_out() applied). Attached picture illustrates the whole architecture.

So if you want to see prefixes that are sent by the first router of a member with AS# 222 type:
bird> show route table T222 protocol R222x1

If you want to see routes that where accepted from this router to the master routing table then type:
bird> show route table master protocol R222x1

If you want to see all prefixes that will be (or are) propagated to a member with AS# 333 type:
bird> show route table T333

And the last example - if you want to see prefixes announced from AS111 to AS333:
bird> show route table T333 protocol R111

Inbound filters are named bgp_in_AS<AS#>. First of all, strange routes (rfc1918 and similar) are excluded by the function avoid_martians(). Then the filter checks if the first AS number is equal to the peer number. Then the AS number originating that prefix is matched with AS# set taken usually from RIPE db and then prefix is checked against prefix set taken also usually from RIPE DB.

Outbound filtering is done using one simple function called bgp_out() - it does filtering based on BGP communities. So each member can decide with prefixes are not propagated to which other member.

This variant consumes a lot of memory (and other resources) because each prefix is stored in all local routing tables. You might be also interested a Simple route server configuration.

I hope I explained it a little bit. If you have any other question, please do not hesitate to ask.