NaMeX Route Server HOWTO

Size: px

Start display at page:

Download "NaMeX Route Server HOWTO"

Joanna Georgina Jennings
5 years ago
Views:

1 NaMeX Route Server HOWTO June 24, Service overview Route servers (RS) are a value-added service that can be offered by IXPs. Actually, the availability of a RS within an IXP is becoming more and more requested by its members and, as such, it is becoming a critical infrastructure for large and very large IXPs. Basically, a Route Server provides the following facilities to members of an IXP. Provide a quick start of operations to new members joining the IXP. Provide a redundant alternative to multilateral (public) peering establishment. Support and/or enforce fair application of peering policies on behalf of individual members, avoiding leaks and dangerous misconfigurations. Ease the management and configuration of peering routers that have to hold a large number of peering sessions. This turns out to be a great advantage especially in the case of peerings which do not have to carry significant traffic volumes, so as to justify a huge configuration effort. The basic function of an RS is to replicate the behavior of a full mesh of ebgp peerings in a centralized way. Each member at an IXP can establish a BGP session with the RS, on which it can announce its own prefixes, optionally specifying a selective export policy. The route server takes care of applying proper input filtering to all the BGP announcements (bogon/martians filtering, IRR generated filters,...) and of performing the best path selection for each prefix announced, according to the export policy specified by each IXP member. The RS is also responsible for the propagation of best BGP paths to each IXP member who peers with it. An RS is never involved in packet forwarding, but only performs controlplane operations. This implies that the Autonomous System (AS) number of the RS has not to appear in the BGP announcements the RS propagates to the IXP members. Moreover, the next-hop attribute of the BGP announcements propagated by an RS has to be identical to that contained in the BGP announcements received by the RS. 1

2 The desirable features of an RS can be summarized as follows: Multilateral vs unilateral peering, a single BGP session with RS can theoretically replace a full mesh of sessions with all the other IXP members which are connected to the RS. Best path selection computation on behalf of individual IXP members (that is: selection is delegated from IXP members to the RS). Transparency (1): routing tables on peering routers must be identical to those resulting from a complete BGP peering mesh among RS peers Transparency (2): the presence of an RS does not imply an increase in the overall length of AS paths announce. Transparency (3): RS is not involved in packet forwarding, but traffic have to flow between peering routers. This means that no high bandwidth capacity is needed for a RS to operate. Common policy enforcement: RS may take care of proper BGP announcements filtering according to common practices and stored policies (IRR databases). These features make an RS an appealing service that can be offered by an IXP for (at least) the following reasons: Speed up new members operations: by configuring a single BGP session, new members can immediately have access to most of the routes announced within the IXP Back up single multilateral peering sessions Simplify the configuration required to be performed by IXP members on their own BGP peering routers (most big players are annoyed at the idea of configuring many BGP session with "small operators") Provide a centralized, privileged looking glass on IXP operations: a RS is a strategic point to monitor the overall health of the IXP, in terms of BGP session stability, route flappings, service continuity, peering matrix, and so on. Route servers are currently a critical piece of infrastructure in all the most important IXPs worldwide, especially for those environments where a huge number of peers exists (often more than a hundred) and a RS is a quick shortcut to full operational status for new members. 2

3 2 Operational aspects NaMeX has deployed an experimental Route Server for testing purposes. NaMeX RS supports the following features: Full IPv4/IPv6 support Full transparency Per-peer dedicated RIBs (v4/v6) MD5 session authentication Automatic import filters generation (from whois.ripe.net) Export policy specification via extended BGP communities (planned) Test Route Server reside on both peering LANs and are implemented by means of two OpenBSD/amd64 boxes running OpenBGPD 4.6 as a routing daemon. 2.1 Basic Route Server tasks For each client, the RS performs the following operations: Filter peer prefixes according to a set of rules that is automatically generated from IRR information Import filtered prefixes into global RIB Perform best path selection process for the client in order to populate its dedicated RIBs Each client has then its own view of the RIB, and transparently sees prefixes from other clients as if directly peering with them. RS Autonomous System is stripped from AS paths so that RS is not involved in packet forwarding, next-hops for each route are set accordingly. Support for export policy specification via BGP communities is planned, but will follow the development of extended BGP community support in OpenBGPD, in order to avoid an interoperabilty issu with 32-bit AS numbers that are starting to be assigned from RIRs. 3

4 2.2 Import filters generation Support for the automatic generation of import filters is provided: import filtering ensures that prefixes coming from a certain client are put in the RIB only after having being compared with IRR registered policies for that peer. Thus, only routes originated from the client AS or from one of its registered customers are accepted into the RIB. In order to support input filtering, each client has to specify, along with its own AS number, an AS set macro containing all its direct customers that are going to be announced on the exchange. Then, a set of filter rules is generated by looking at registered routes for the aforementioned AS set (client + customers). Each route is filtered by matching the exact netmask and origin AS, as in this example (OpenBGPD syntax): # AS24796 allow from inet prefix /24 { source-as } allow from inet prefix /23 { source-as } allow from 2001:7f8:10::2:4796 inet6 prefix 2001:7F8:10::/48 { source-as } It is of topmost importance that each RS client properly registers its routes into the IRR. For clients that also have a set of customer ASes, it is also important to create a proper AS-set to contain all customers. This enables the RS to generate its filters from fresh, up-to-date IRR data. Filters can be generated a couple of time a day, performing a configuration reload. Additional filtering is performed in order to block default routes and martians. 2.3 Export policy specification In general, RS clients are allowed to specify an export policy for their routes by means of BGP community set according to a similar schema: Announce to all: tag with <rs-asn>:<rs-asn> Announce only to a certain peer: tag with <rs-asn>:<peer-asn> Do not announce to a certain peer: tag with 0:<peer-asn> Announce to none: tag with 0:0 in order to implement such a scheme by taking into consideration the presence of RS clients with a 32bit ASN, it is necessary to use extended BGP communities (that are larger than 32bits in total). As support for extended 4

5 BGP communities in OpenBGPD is not in a stable state yet. We decided not to implement this feature at the moment and we plan to introduce it later, with a more mature support from the daemon. So please remember that all your routes will be announced to all RS clients even if you try to specify an export policy by means of community tags. 2.4 BGP session parameters In order to participate in the RS test phase, each client has to communicate the following information: 1. Autonomous System Number and neighbor IPv4/IPv6 address 2. (optional) AS set macro containing all customer ASes 3. (optional) a MD5 secret for the BGP session The BGP session can be configured with the following RS data: AS Number: AS (3.351) IPv4 address: (primary LAN) and (secondary LAN) IPv6 address: 2001:7f8:10::19:6959 (primary LAN) and 2001:7f8:10:b::19:6959 (secondary LAN) NOTES: Sessions are configured as passive on the RS side, so they should be set to active on the client side. As of Cisco release 12.0(S) Cisco added the bgp feature bgp enforce-first-as. This feature is enabled by default. To use the route-server fully transparently you have to set no bgp enforce-first-as. 5

2015/07/23 23:32 1/8 More ibgp and Basic ebgp

2015/07/23 23:32 1/8 More ibgp and Basic ebgp More ibgp and Basic ebgp Objective: Connect your ISP to a Transit provider and the Internet Exchange Point using a combination of ISIS, internal BGP, and external