Route Server service @ NaMeX


Published on

Route Server service @ NaMeX

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Route Server service @ NaMeX

  1. 1. Peering Workshop 2010 – Roma, July 9th 2010 Route servers @ NaMeX
  2. 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. 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. 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. 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. 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. 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: – 2001:7f8:10::19:6959 •  Secondary LAN: – 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. 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: Members currently peering with the route servers: •  Caspur/Inroma •  E4A •  F-root •  Panservice •  Seeweb •  Unidata Overall announced (filtered) prefixes: 72
  9. 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 •  Only routes originating from peer AS and AS- SET are accepted •  Martians, bogons and default routes are filtered out •  Hijacks and leaks prevention !
  10. 10. Peering Workshop 2010 – Roma, July 9th 2010 Import filtering Generated filters example: Peer filters can be seen here:
  11. 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. 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. 13. Peering Workshop 2010 – Roma, July 9th 2010 Thanks!