Route Servers
The purpose of Route Servers (RS) is to simplify the process of routing so that with only two BGP sessions every member can exchange routing information about the announces of all others.
On the scheme is shown only one of the two Route Servers. RS are two, positioned on different locations with the aim of full reservation. Nevertheless they are basically identical.
The scheme illustrates how the Route Server is functioning and how does member B find the network of a client of member A (20.10.10.0/24) and when receives traffic for it sends it through the shared switching infrastructure.
With the help of BGP Community the member may decide who he wants to “give” the traffic to. The following BGP Community is maintained for every announced prefix:
| BGP Community | TIPS for RS |
| 0:MEMBER-AS | DO NOT ANNOUNCE TO THIS MEMBER |
| 15669:MEMBER-AS | ANNOUNCE TO THIS MEMBER |
| 0:15669 | DO NOT ANNOUNCE TO ANY MEMBER |
| 15669:15669 | ANNOUNCE TO ALL MEMBERS |
BGP communities for 32-bit AS numbers.
To use BGP communities with 32-bit AS numbers, set MEMBER-AS values as listed in the following table:
| Member | AS | BGP Community (MEMBER-AS) |
| InterWorks | 197469 | 64769 |
Default local рreference = 100.
| BGP Community | TIPS for RS |
| 15669:65000 | Local preference = 0 |
| 15669:65050 | Local preference = 50 |
In relation to the incoming traffic (which announces are accepted) the control is in the member – he can filter which ones of the received from RS announces he will accept.
With the idea of full coverage of the functionality of both Public and Private Peering, RS can remove its own AS from the route, which will make them seem directly connected without a necessary BGP session between them.
The received RS announces will be checked in RIPE and announces, if they are not described in detail, they will not be accepted. This is done with the purpose of prevention of errors when announcing prefixes which cannot be maintained by the member in question.
