Route Servers

Server Infrastructure

The Philadelphia Internet Exchange operates two BIRD route servers, both running on Ubuntu Linux, inside a VMware virtual environment. By utilizing virtual machines, we have the ability to migrate between VM hosts and minimize downtime due to hardware failures or maintenances. Each VM host has 40G connectivity directly to the peering switch, and a 1G management interface to our OOB switch.

The route servers do not forward any traffic and operate strictly on the control-plane.

We recommend participants establish a BGP session to each route server. The route servers do NOT peer with one another.

Description IPv4 Address IPv6 Address ASN
PhillyIX Route Server # 1 2001:504:90::1 54033
PhillyIX Route Server # 2 2001:504:90::2 54033

Default Route Propagation

The default route is not permitted in the route servers and will be filtered.

RFC1918 Address Space

RFC1918 addresses, and other non-internet-routable address space, are NOT permitted in the route servers and will be filtered.

Route Filtration

In an effort to be compliant with MANRS (Mutually Agreed Norms for Routing Security) standards, PhillyIX’s route servers apply incoming route filters based on every member’s IRR records. This means that prefixes which are not specifically associated with your ASN, or with an ASN that is downstream from you, will not be accepted by the route servers, and will therefore not be propagated to other members. Members are encouraged to list their downstream ASNs in an AS-SET on RADB or some other IRR, and also associate all their prefixes with their ASN object. For more information on how to properly configure your routing information in an online database, please visit the MANRS ISP Guide. Our Admin Team is always available by email if you need help getting started or navigating the process.

We utilize bgpq3 to build our prefix lists. These lists are re-generated automatically on a daily basis, and are loaded into the route servers around mid-day.

RPKI Validation

While it is not active yet, we will soon be implementing RPKI validation for all members on a tertiary route server. This route server will filter any RPKI-invalid prefixes from being propagated. If you would like to participate, please configure ROAs for all your prefixes with your region’s registry. An example of how to do this may be found at ARIN’s website. If you require assistance with this, we are happy to help. Please email the Admin Team.

Community Strings

The route servers support the following community Strings. If no community is specified all accepted routes are forwarded to all peers.

Community Action
0:$PEERAS Don’t announce route to RS peers with the ASN $PEERAS
54033:$PEERAS Announce route ONLY to peers with the ASN $PEERAS
0:54033 Do not redistribute route to any peers.
54033:54033 Announce route to all peers (This is the default)