Route Servers (RSes) are a critical piece of infrastructure used by prominent IXPs worldwide, especially in environments where a huge number (often more than a hundred) of peers exist. This can make filtering challenging.
Why are route servers different?
The main role of RSes is to facilitate interconnection between multiple routers. They are a value-added service offered by IXPs as a way for new members to get fully operational quickly. Essentially, RSes help accelerate peering.
An RS replaces configurations involving multiple bilateral peering sessions with a single BGP session. This has a number of benefits. Notably, most IPv4 / IPv6 prefixes become reachable through the IXP at first connection, providing benefits for peering from day zero. It also acts as a backup solution for established bilateral sessions.
RSes are also important when IXPs don’t meet the minimum traffic necessary to peer with ‘big’ content providers that impose a limit on minimum exchanged traffic to establish an individual peering session.
Over the years, RSes have become more and more popular in IXPs. Many new features have been added, especially in terms of routing security.
An RS performs initial filtering on routes received from its peers, guaranteeing greater reliability of announced routes. An RS provides protection against hijacks as well as announcements of bogons/martians and default routes.
Consequently, the RS takes care of applying proper input filtering to all BGP announcements, enforcing the application of security criteria, and validating received prefixes according to its policies.
Generally speaking, filtering is based on information contained in the Internet Routing Registry (IRR) system as well as RPKI architecture. In simple terms, validation is usually done by checking BGP announcements against IRR data. Then, routes received from each peer in the RS infrastructure can be additionally filtered according to their RPKI ROA status. The goal is to export a clean set of prefixes to peers connected to the RS, all of which have been validated according to their originating source and announcing peer.
Examining some filtering methods
There are several policies and approaches that can be followed. Choosing the filtering method will depend on the desired level of control and the underlying technical architecture.
The following flows represent validation chains on both OpenBGPD and BIRD. When it comes to filtering, the two pieces of software have quite different approaches to configuration. While OpenBGP uses a rule-based evaluation approach typical of filtering tools such as Packet Filter (PF) or Linux Netfilter, BIRD uses a function-based approach, exploiting a configuration language that mimics the workings of common programming languages such as C.
The different approaches may result in minor differences in the validation chain. In both cases the evaluation flow is split into two separate chains: One that determines which prefix from a peer has the right to be inserted into the global Routing Information Base (RIB) and the other determines a separate view of this RIB, based on the peer to which this RIB is exported.
Filtering chain (BIRD) configuration
Note: We apply IRR-based filtering on updates from peers, and strict filtering of ROA invalids during the export phase. As IRR and RPKI information is completely independent, the filtering strategy can be modified.
The filtering chain can be divided into two parts. The first part filters the advertisements received from peers and saves them in the Route Server’s RIB, shown on the left in Figure 1. The second part filters updates before they are exported to peers, shown on the right in Figure 1.
Import chain configuration steps
- Check if the IP prefix updated is a martian/bogon (using Team Cyrmu resources).
- Check if the update has been tagged with the BGP blackhole community.
- Check if the updated prefix origin AS belongs to the set of allowed ASes.
- Check if the updated prefix belongs to the set of allowed prefixes.
The first step checks if the prefix updated by a peer is a martian/bogon prefix. If either, it gets dropped.
Step 2 checks if the update received has been tagged with the BGP blackhole community. If it has, the Route Server changes the next hop of the update with the hop to the dummy server and the prefix is accepted and stored in the RS’s RIB. If it hasn’t been tagged, it gets dropped.
A set of allowed ASes for a given peer is made of its own AS plus any additional AS listed as a customer in a registered AS-SET. In Step 3, if the origin AS of the updated prefix belongs to the allowed set it is permitted, if it isn’t, it gets rejected.
The set of allowed prefixes for a peer is built by expanding any AS included in the corresponding set of allowed ASes for the peer. For ASes in the set, we look for any route objects with that AS as the origin.
If the updated prefix exactly matches one of the prefixes included in the set of allowed prefixes, then the prefix is added to the RIB. Otherwise, it is rejected in Step 4.
Export chain configuration
Before the prefixes stored in Route Server’s RIB are exported to the peers, more filters are applied. This process applies on a per-neighbour basis.
- Check if the update has been tagged with the blackhole BGP community.
- Check if there is ROA in RPKI Validator.
- Check if the update blocks a large BGP community.
- Check if the update blocks a standard BGP community.
- Check if the update is custom filtered.
Firstly, the export chain checks if the update has been tagged with the blackhole BGP community. If that is the case, ‘no-export’ is applied (which tells the peers who receive the update not to propagate it) and the prefix is announced to the neighbour.
Step 2 checks if the update has a corresponding ROA according to the information found in the RPKI validator. If the result is an invalid ROA, it won’t export to the neighbour.
If the update has a large BGP community blocking the prefix for the specific neighbour, checked in Step 3, the prefix isn’t exported to the neighbour.
Step 4 checks if the update has a BGP blocking standard community for the specific neighbour, it doesn’t export the prefix to the neighbour.
In Step 5, if the update is custom filtered for the specific neighbour, it doesn’t export the prefix to the neighbour. If there’s no custom filter, it is announced to the neighbour.
Filtering chain (OpenBGPD) configuration
For the sake of completeness, below is the processing flow diagram for the OpenBGPD instances of the Route Server architecture. As previously stated, the order of evaluation is slightly different due to implementation differences with respect to the BIRD architecture.
As you can see in Figure 2, there are only a few points of difference in the process, particularly around steps related to the origin-AS and blackhole community.
And that’s it! For more information on prefix filtering, APNIC Academy offers a range of free courses.
This post was originally published on the Namex blog.
Flavio Luciani is chief technology officer at Namex (Roma IXP).
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.