Route servers help reduce the number of BGP sessions that members need to configure. Instead of configuring two sessions for each member router (one IPv4 and of course another one in IPv6), members can simplify and configure only four sessions in total: one IPv4 and one IPv6 to each of our two route servers.
To be able to control the distribution of routing information via the route servers, Internet Exchanges allow the use of BGP communities. The exact communities to use are almost an industry standard, and LU-CIX follows that de facto standard.
Recently, we have reworked our handling of communities leading to the following two changes.
Large communities for 32-bit AS numbers
Traditional BGP communities are 32-bit values, most of the time written as <16bits:16bits>.
The industry standard designates the first 16-bit to be either 0 or the IX AS number, and the remaining 16-bit to be the AS number of the IX member that a routing policy is being applied to. As an example, setting the community 49624:2602 indicates that you want to announce the prefix carrying this tag, to Restena (AS2602).
Obviously, this system doesn’t work anymore for 32-bit AS numbers, which have been introduced back in 2009. Although extended communities introduced in 2006 (RFC 4360) were an improvement over standard communities, they still only offered the possibility to record one 32-bit and one 16-bit AS number. Relief came only in 2017 (RFC 8092) when large communities were introduced.
Therefore, LU-CIX has introduced large communities for members to signal routing policy concerning 32-bit AS numbers. Large communities consist of three 32-bit fields, i.e. 12 bytes in total, allowing them to easily accommodate 32-bit AS numbers.
If you already take advantage of standard communities to implement your routing-policy on LU-CIX, you will now be in a position to correctly implement your policy towards members with 32-bit AS numbers, by using the following communities:
| Action* | Community | Large Community |
| 1. block of announcement of a route to a certain peer | 0:<peer-as> | 49624:0:<peer-as> |
| 2. announcement of a route to a certain peer | 49624:<peer-as> | 49624:1:<peer-as> |
| 3. block of announcement of a route to all peers | 0: 49624 | 49624:0:0 |
| 4. announcement of a route to all peers | 49624: 49624 | 49624:1:0 |
Standard communities remain supported since they are sufficient when working with 16-bit AS numbers.
The use of communities is documented on LU-CIX’ website here https://www.lu-cix.lu/solutions/route-servers/.
Handling of well-known communities
RFC1997, which initially introduced communities in BGP, defines a few well-known community values for specific use cases. Previously, these communities (and their intended action) were handled by our route servers, i.e. applying NO_EXPORT to a route meant that our route servers did not announce that route to any member. However, since route servers are merely an optimisation in the routing between members, there is no reason why they should honour and act upon well-known communities. Rather, route-servers should pass routes tagged with those communities on to members.
This improved behaviour has now been implemented on our route servers. The following communities are now transparently forwarded by our route servers:
NO_EXPORT (0xFFFFFF01 - 65535:65281)
NO_ADVERTISE (0xFFFFFF02 - 65535:65282)
NO_EXPORT_SUBCONFED (0xFFFFFF03 - 65535:65283)
LU-CIX members thus have the possibility to control distribution of their routes within other member networks, while still using the route-servers. We expect that all member routers treat these communities according to the BGP standards.
