Multi-Lateral Peering Exchange (MLPE)
Route Servers

The MASS IX route server architecture consists of two separate VM hypervisors located in different data centers for redundancy. From time to time, MASS IX staff will conduct maintenance on the boxes that will cause BGP sessions to go down momentarily. That is why two route servers are provided—service will be maintained if you are peered with both route servers, as you will continue to receive routes from the second route server.

  1. Note: Peering with route servers is optional and is not required of participants.

  1. Note: As of H2 CY 2023, MASS IX route servers will now enforce validity of each route using the Internet Routing Registry (IRR) and Resource Public Key Infrastructure (RPKI). Please ensure that your routes are properly registered in IRR and any published ROAs are matching constraints exactly with the actual legitimate advertisements.

MASS IX Route Server Information

AS Number
Route Server #1
Route Server #2

Route Server Configuration

For Cisco, you need to configure "no bgp enforce-first-as" in order to use the route servers. RS will feed you routes without appending its own AS number, in order to ensure transparent propagation of routes without modifying attributes. A sample route server peering configuration will look like:

router bgp $your_as_number
  no bgp enforce-first-as
  neighbor remote-as 26563
  neighbor description
  neighbor send-community both
  neighbor remote-as 26563
  neighbor description
  neighbor send-community both
  neighbor 2001:504:47::CE35:8FFC:1 remote-as 26563
  neighbor 2001:504:47::CE35:8FFC:1 description
  neighbor 2001:504:47::CE35:8FFC:1 send-community both
  neighbor 2001:504:47::CE35:8FFD:1 remote-as 26563
  neighbor 2001:504:47::CE35:8FFD:1 description
  neighbor 2001:504:47::CE35:8FFD:1 send-community both
  address-family ipv4
    neighbor activate
    neighbor prefix-list $your_outbound_prefix_list out
    neighbor activate
    neighbor prefix-list $your_outbound_prefix_list out
  address-family ipv6
   neighbor 2001:504:47::CE35:8FFC:1 activate
   neighbor 2001:504:47::CE35:8FFC:1 prefix-list $your_ipv6_outbound_prefix_list out
   neighbor 2001:504:47::CE35:8FFD:1 activate
   neighbor 2001:504:47::CE35:8FFD:1 prefix-list $your_ipv6_outbound_prefix_list out

Route Server Control

Filtering of incoming routes can be done by yourself by applying an inbound route policy (such as route-map) against MASS IX route server sessions.

For controlling outbound routing information, you can do this by sending us BGP communities as follows:

block announcement of a route to certain peer
0:<Peer AS>
announce a route to a certain peer
26563:<Peer AS>
block announcement of a route to ALL peers
announce a route to ALL peers (default behavior)

Communities not starting with 26563: or 0: will not be processed by the RS. Routes with no community at all will be construed as "26563:26563" and be sent to all peers by default. Please don't forget to set "send-community" against MASS-IX route server neighbors if you want to influence route propagation.

IX Participants with 32-bit ASN

MASS IX implements N:M filtering based on standard community strings. As standard BGP communities support only 4 bytes, this only works for 2-byte ASNs and peers with 2-byte ASNs. For BGP peers with 32-bit ASN, substitute the "<Peer AS>" section in accordance with the following list:

Enfopoint (AS393965)
EndLayer (AS393965)
Tilson Broadband (AS399100)

Route Server Transparency

MASS IX route servers will propagate BGP routes while transparently passing the following attributes unchanged: MED, AS Path (RS will not append its own ASN to the path) and next-hop. The transparency of attributes is important for many reasons, including ease of traffic engineering and to facilitate redundancy. For example, some networks may have a mix of both bilateral and multilateral sessions to a same peer.

Getting Started

To peer with MASS IX route servers, please email your request to