This document summarizes a presentation about route servers at an Internet exchange point (IXP) in Rome, Italy. It describes the purpose and technical aspects of route servers, including how they allow members to establish peering through a single BGP session rather than a full mesh. Specific details are provided about the route servers at NaMeX, including their hardware, configuration, filtering policies, and current members. Future plans are outlined, such as implementing 32-bit community tags for export policies and improving redundancy.

1. Peering Workshop 2010 – Roma, July 9th 2010
Route servers @ NaMeX
noc@namex.it

2. Peering Workshop 2010 – Roma, July 9th 2010
Outline
• Route Servers in an IXP environment
• Technical aspects
• Pros and cons
• NaMeX route servers
• Configuration and filtering
• TODO

3. Peering Workshop 2010 – Roma, July 9th 2010
Route Servers in an IXP environment
What ?
Route Servers (RS) provide support for the
establishment of peering arrangements between
IXP peers: theoretically, a single peering session
replaces a complex full mesh BGP interconnection
How ?
 Each peer establishes a single BGP peering
session with the RS, advertising its own
prefixes
 RS performs per-peer RIB calculation,
applying input/output filter to overall received
prefixes
 RS announces each peer a set of prefixes
resulting from the previous RIB calculation
 RS is not involved in packet forwarding !

4. Peering Workshop 2010 – Roma, July 9th 2010
Technical aspects
RS operates in a fully transparent way:
 BGP attributes are not modified by RS, and passed on to peers
 RS never shows up as a next-hop
 Routes are exchanged with RS, packets are directly exchanged between peers
 Routing table on each client should be exactly the same as in the case of full
mesh BGP peerings
In general, RS are implemented by means of UNIX machines running some sort of BGP
routing daemon:
 Most of the work is BGP session management and RIB calculations (CPU and
Memory)‫‏‬
 No need for an expensive forwarding backplane (although some exceptions exist)‫‏‬

5. Peering Workshop 2010 – Roma, July 9th 2010
Technical aspects (2)‫‏‬
Generic RS model:
 Prefixes received from Peer A are filtered
according to a set of input filters
 For each Peer, prefixes resulting from
filtering operations undergo a best-path
selection process, based on a per-client local-
RIB
 Prefixes from A are considered for
announcement to other peers according to its
output filtering policy
Key aspects:
 Peer may retain a certain degree of control
over where its announcements go
 Best Path Selection is fully delegated to RS

6. Peering Workshop 2010 – Roma, July 9th 2010
Pros and cons
PROs
 Speeding up “start of peering” for new members: most routes available through a single
BGP session (in the ideal case)
 Preventing / mitigating misconfiguratons, leaks, hijacks by enforcing the application of input
filters
 Providing backup for direct peering sessions
 Outsourcing RIB path calculations to fast, dedicated machines
 Simplify the configuration required to be performed by IXP members on their own BGP
peering routers
 Added value service for an IXP
CONs
 Outsourcing RIB path calculations !
 Limited/incomplete control over announcements export

7. Peering Workshop 2010 – Roma, July 9th 2010
NaMeX route servers
Hardware:
• two OpenBSD 4.6 boxes
• OpenBGPd 4.6
Configuration:
• AS196959 (3.351)
• Primary LAN: 193.201.28.60 – 2001:7f8:10::19:6959
• Secondary LAN: 193.201.29.60 – 2001:7f8:10:b::19:6959
• Passive mode, transparent (`no bgp enforce-first-as` on IOS >= 12.0(S) )
• MD5 support (optional)
• dedicated peer-RIB

8. Peering Workshop 2010 – Roma, July 9th 2010
NaMeX route servers (2)
In order to setup sessions with the route server, each interested member must:
• Specify its Autonomous System number (trivial)
• Specify (optional) additional AS-SET containing all customer ASes being announced overt the
IXP
• Specify (optional) MD5 session password
• Technical info: https://www.namex.it/it/techinfo/routeserver
Members currently peering with the route servers:
• Caspur/Inroma
• E4A
• F-root
• Panservice
• Seeweb
• Unidata
Overall announced (filtered) prefixes: 72

9. Peering Workshop 2010 – Roma, July 9th 2010
Configuration and filtering
Route server configuration is generated
automatically from master database,
once per day:
• Import filters are generated according to peer
ASN and AS-SET: IRRtoolset (Peval) on
whois.ripe.net
• Only routes originating from peer AS and AS-
SET are accepted
• Martians, bogons and default routes are filtered
out
• Hijacks and leaks prevention !

10. Peering Workshop 2010 – Roma, July 9th 2010
Import filtering
Generated filters example:
Peer filters can be seen here: https://www.namex.it/en/tools/rsinfo

11. Peering Workshop 2010 – Roma, July 9th 2010
Output filtering
In general, RS clients provide simple ways to control to whom their prefixes are
announced
Community tag based export policy specification:
• Announce to all: <rs-asn>:<rs-asn>
• Announce only to a certain peer: <rs-asn>:<peer-asn>
• Do not announce to a certain peer: 0:<peer-asn>
• Announce to none: tag with 0:0
This is not currently supported at NaMeX:
• Schema is based on 32bit communities (16 bits for rs-asn or peer-asn)
• Does not scale to environments with 32bit ASN peers
• Upcoming NaMeX members are most likely to use 32bit ASNs
• 32bit Communities are being implemented into OpenBGPD, status of implementation for
other vendors (Cisco, Juniper) is not known

12. Peering Workshop 2010 – Roma, July 9th 2010
TODO
- - Alternate support for export policy specification:
- Build output filters from IRR (policies in aut-num objects) ?
- Local database for policy specification, with a simple web interface ?
- Web based Looking Glass (work in progress)
- Improved RS redundancy and reliability (2 physical boxes on each LAN)

13. Peering Workshop 2010 – Roma, July 9th 2010
Thanks!