| Home | News | Background | Description of the Service | Publications | Credits & Contacts | Links |
| Computed Data | Query Services | Plot Services |
This page provides introductory information about BGP, the IRR, RPSL, Peval, and IRRd.
|
About the Border Gateway Protocol |
The Internet is divided into tens of thousands of administrative domains called Autonomous Systems (AS), each usually adopting a unique routing protocol and consistent routing policies. Each AS is identified by a number.
The Border Gateway Protocol (BGP) [RFC1771, RFC4271] is the de-facto standard routing protocol used to exchange reachability information between ASes. Two ASes that exchange routing information using BGP are said to have a peering between them. The ASes which have a peering with an AS A are termed peerers of A. BGP also allows to define complex routing policies that affect the propagation of BGP announcements.
|
The Internet Routing Registry |
There are many publicly available registries that describe both the allocation of Internet resources and BGP routing policies. The Regional Internet Registries (e.g., RIPE, ARIN) are in charge of maintaining information over wide geographic regions. The Local Internet Registries (e.g., VERIO, LEVEL3) describe the policies of the customers of a specific ISP. Taken together, all these registries form the Internet Routing Registry (IRR). The main purpose of the IRR is to support a consistent global configuration of routing policies. It is also possible to automatically create BGP filters and router configurations from registry information by using tools such as IRRToolSet.
The registration and maintenance of routing policies are performed on a voluntary basis by network operators, who may register such policies at one or more registries. As a consequence, information therein may be incorrect, incomplete, or outdated. Indeed, some large ISPs and Internet Exchange Points rely on the IRR for route filtering and do not allow their customers to participate in BGP routing unless they document their routing policies in a registry.
|
Routing Policy Specification Language |
The routing policies stored in the IRR are described using the Routing Policy Specification Language (RPSL) [RFC2622, RFC2650] or its more recent variant RPSLng [RFC4012], which introduces support to both multicast and IPv6. RPSL is an object-oriented language that defines 13 classes of objects. Routing policies are described in the import, export, and default attributes of aut-num objects. In turn, aut-nums may reference other objects that contribute to the specification of the policies, such as as-sets and peering-sets.
What follows is a portion of an RPSL aut-num object from the RIPE registry which describes the routing policies of AS137 (last updated 08/30/00).
aut-num: AS137
import: from AS20965 action pref=100;
from AS1299 action pref=100;
accept ANY
[...]
export: to AS1299 announce AS-GARR
[...]
changed: noc@garr.it 20000830
source: RIPE
[...]
The portion of the import (export) attribute following the
from (to) keyword is a very simple example of peering
specification. The object indicates that AS137 accepts any route sent to
it by AS20965 and by AS1299 and propagates to AS1299 all the routes originated
by ASes belonging to the as-set named AS-GARR (an as-set is
an RPSL object that specifies a set of ASes). This implies that AS137 has a
peering with AS20965 and AS1299.
|
| IRRToolSet, Peval, and IRRd |
In our service we make use of Peval, a low level policy evaluation tool conceived to write router configuration generators. Peval is part of the Internet Routing Registry Toolset (IRRToolSet) suite. Peval takes as input an RPSL expression and evaluates it by applying RPSL set operators (AND, OR, NOT) and by expanding as-sets, route-sets, and AS numbers into the corresponding sets of prefixes. Alternatively, Peval can stop the expansion at the level of ASes. We access IRR data also through the Internet Routing Registry Daemon (IRRd), a freely available stand-alone IRR database server supporting both RPSL and RPSLng.
Last Update: 28 September 2006