Peering Workshop 2010 – Roma, July 9th 2010

Route servers @ NaMeX noc@namex.it

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

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 !

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)‏

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

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

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

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

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 !

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

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

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)

Peering Workshop 2010 – Roma, July 9th 2010

Thanks!