Internet Draft Cengiz Alaettinoglu
Expires September 26, 1997 USC/ISI
draft-ietf-rps-appl-rpsl-00.txt David Meyer
University of Oregon
Joachim Schmitz
DFN-NOC
March 26, 1997
Application of Routing Policy Specification Language (RPSL) on the Internet
Status of this Memo
This document is an Internet Draft, and can be found as
draft-ietf-rps-appl-rpsl-00.txt in any standard internet drafts
repository. Internet Drafts are working documents of the
Internet Engineering Task Force (IETF), its Areas, and its
Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of
six months. Internet Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not
appropriate to use Internet Drafts as reference material, or
to cite them other than as a ``working draft'' or ``work in
progress.''
Please check the I-D abstract listing contained in each
Internet Draft directory to learn the current status of this or
any other Internet Draft.
1 Introduction
This document is a tutorial on using the Routing Policy
Specification Language (RPSL) to specify routing policies. It
covers registering policies in an Internet Routing Registry
(IRR) using RPSL, and the use of tools to generate vendor
specific router configuration. It is targeted towards an
Internet/Network Service Provider (ISP/NSP) engineer who is
new to RPSL and to IRR. Readers are referred to the RPSL
reference document [1] for completeness. We recommend
reading this document before reading the reference document.
We hope that for many cases, this document will be
sufficient.
IRR is a repository of routing policies. It currently
consists of five sites: CA*Net registry in Canada, ANS, MCI
and RADB registries in the
Internet Draft Application of RPSL March 26, 1997
United States of America, and RIPE registry in Europe.
Each of these sites run independent of each other. However,
each site exchanges its data with each other at some frequency
(at least once a day or as often as every ten minutes). MCI,
Ca*Net and ANS are private registries and contain routing
policies of MCI, Ca*Net, ANS, and their customers
respectively. RADB and RIPE are public registries, and any ISP
can publish their policies in these registries. Since
registries exchange their data regularly, you need to register
your policies in only one of them. If you are an MCI,
ANS or CA*Net customer, we recommend you register your policies
with them. Otherwise, please register your policies either at
the RIPE or RADB registry, whichever is closer to you. We
recommend against registering in multiple registries since it
often eventually leads to inconsistent data between the
registries.
Routing policies registered in IRR are specified using
RPSL. RPSL is based on an earlier language known as RIPE-181 [2,
3]. Through operational use of RIPE-181 it has become apparent
that certain policies cannot be specified and a need for an
enhanced and more general language is needed. RPSL addresses
RIPE-181's limitations. RPSL obsoletes RIPE-181 [2, 3].
RPSL is object oriented; that is, objects contain pieces of
policy and administrative information. For example, each
address prefix routed in the inter-domain mesh is specified in a
route object and policies of each AS are specified in an aut-num
object. Objects have relations between each other. For example,
all route objects of an ISP refer to the Autonomous System (AS)
number of the ISP. These relations form sets of objects. We
can then use these set names to specify policies collectively to
all their members. For example, we can use the AS number of an
ISP to specify policy against all of its routes. In the
following sections, we will describe each of these objects
(rather object classes) in more detail and give numerous
examples for you to create your own objects. In most cases,
you should be able to cut and paste our examples to create your
own objects.
Once you register your policies in IRR, they are available for
others to query using a whois service. For example, to see
the route object for 128.223.0.0/16, please try the following
UNIX command:
% whois -h radb.ra.net 128.223.0.0/16
route: 128.223.0.0/16
descr: UONet
descr: University of Oregon
descr: Computing Center
descr: Eugene, OR 97403-1212
descr: USA
origin: AS3582
mnt-by: MAINT-AS3582
changed: meyer@ns.uoregon.edu 960222
source: RADB
Alaettinoglu et. al. Expires September 26, 1997 [Page 2]
Internet Draft Application of RPSL March 26, 1997
The output of the command is the ASCII representation of the
route object whose details will be covered in Section 2.3.
That is not all, once you register your policies in IRR, they
can be analyzed for consistency or used to diagnose Internet's
operational routing problems. RAToolSet [5] is a suite of
tools for analyzing this data. It contains tools (RtConfig)
to configure routers, tools (prpath and prtraceroute) to analyse
paths on the Internet, tools (roe, aoe and prcheck) to
compare, validate and register RPSL objects, and others.
The remainder of this document is organized as follows:
Section 2 introduces the fundamental RPSL objects. Section 3
discusses implementation of various common policies using
RPSL. Finally, Section 4 describes the use of RtConfig to
generate vendor specific router configurations.
2 RPSL Objects
This section introduces the fundamental RPSL objects required to
implement many typical Internet routing policies. The basic
elements are
o maintainer objects (mntner)
o autonomous system number objects (aut-num)
o route objects (route)
o set objects (as-set, route-set)
and they are described in the following sections. These
objects must be registered in the IRR, in only one of the
existing registries. In general, registration is done by
sending mail to a registry robot. The mail addresses are
different for different registries. The contents of the mail
consists of the objects you want to have registered,
separated by empty lines, and often some kind of
authorization (see below). The registry robot automatically
processes your mail, entering new objects into the database,
deleting old ones, or activating changes. Moreover, it may
send notifications and replies with an error or success report
about its actions. The first object which has to be registered,
normally is the mntner. In general, to have it properly
authenticated, a maintainer object is added manually by
registry staff. Afterwards, all other actions should be done
through the registry robot. Each registry provides documentation
on how to use it. If problems arise your registry staff is
willing to assist you.
Alaettinoglu et. al. Expires September 26, 1997 [Page 3]
Internet Draft Application of RPSL March 26, 1997
2.1 The Maintainer Object
The maintainer object is used to introduce some kind of
authorization for registrations. It lists various contact
persons and describes security mechanisms that will be
applied when updating other objects in an IRR. Registering a
mntner object is the first step in creating policies for an
AS. An example is shown in Figure 1. The maintainer is
called MAINT-AS3701. The contact person here is the same
for administrative admin-c and technical tech-c issues and is
referenced by the NIC-handle DMM65. NIC-handles are unique
identifiers for persons in registries. Refer to registry
documentation for further details on person objects and usage of
NIC-handles.
The example shows two authentication mechanisms: CRYPT-PW and
MAIL-FROM. CRYPT-PW takes as its argument a password that is
encrypted with Unix crypt(3) routine. When sending updates,
the maintainer adds the field password: <cleartext password>
to the beginning of any requests that are to be authenticated.
MAIL-FROM takes an argument that is a regular expression which
covers a set of mail addresses. Only users with any of these
mail addresses are authorized to work with objects secured by
the corresponding maintainer(1).
The security mechanisms of the mntner object will only be
applied on those objects referencing a specific mntner object.
The reference is done by adding the attribute mnt-by to an
object using the name of the mntner object as its value. In
Figure 1, the maintainer MAINT-AS3701 is maintained by itself.
2.2 The Autonomous System Object
The autonomous system object describes the import and export
policies of an AS. Each organization registers an autonomous
system object (aut-num) in the IRR for its AS. Figure 2 shows the
aut-num for AS3582 (UONET).
The autonomous system object lists contacts (admin-c, tech-c)
and here is maintained by mnt-by: MAINT-AS3701 which is the
maintainer displayed in Figure 2.
The most important attributes of the aut-num object are as-in
and as-out. The as-in clause of an aut-num specifies import
policies, while the as-out clause specifies export policies.
The corresponding clauses allow a very detailed description of
the routing policy of the AS specified. The details are given in
section 3.
------------------------------
1. Clearly, neither of these mechanisms is sufficient
to provide strong authentication or authorization.
Other public key (e.g., PGP) authentication mechanisms
are available from some of the IRRs.
Alaettinoglu et. al. Expires September 26, 1997 [Page 4]
Internet Draft Application of RPSL March 26, 1997
mntner: MAINT-AS3701
descr: Network for Research and Engineering in Oregon
remark: Internal Backbone
admin-c: DMM65
tech-c: DMM65
upd-to: noc@nero.net
auth: CRYPT-PW 949WK1mirBy6c
auth: MAIL-FROM .*@nero.net
notify: noc@nero.net
mnt-by: MAINT-AS3701
changed: meyer@antc.uoregon.edu 970318
source: RADB
Figure 1: Maintainer Object
With these clauses the aut-num object shows the relationship
to other autonomous systems by describing the peerings. In
addition, it also defines a routing entity comprising a group
of IP networks which are handled according to the rules
defined in the aut-num object. Therefore, it is closely
linked to route objects.
In this example, AS3582 imports all routes from AS3701 by using
the keyword ANY. AS3582 imports only internal routes from
AS4222, AS5650, and AS1798. The import policy for for AS2914 is
slightly more complex. Since AS2914 provides transit to
various <other ASs, AS3582 accepts routes with ASPATHs that
begin with AS2194 followed by members of AS-WNA, which is an
AS-SET (see section 2.4.1 below) describing those customers that
transit AS2914.
Since AS3582 is a multi-homed stub AS (i.e., it does not provide
transit), its export policy consists simply of ``announce
AS3582'' clauses.
The aut-num object forms the basis of a scalable and
maintainable router configuration system. For example, if
AS3582 originates a new route, it need only create a route
object for that route with origin AS3582. AS3582 can now build
configuration using this route object without changing its
aut-num object.
Similarly, if for example, AS3701 originates a new route, it
need only create a route object for that route with origin
AS3701. Both AS3701 and AS3582 can now build configuration using
this route object without modifying its aut-num object.
Alaettinoglu et. al. Expires September 26, 1997 [Page 5]
Internet Draft Application of RPSL March 26, 1997
aut-num: AS3582
as-name: UONET
descr: University of Oregon, Eugene OR
as-in: from AS3701 100 accept ANY
as-in: from AS4222 100 accept <^AS4222$>
as-in: from AS5650 100 accept <^AS5650$>
as-in: from AS2914 100 accept <^AS2914+ (AS-WNA)*$>
as-in: from AS1798 100 accept <^AS1798$>
as-out: to AS3701 announce AS3582
as-out: to AS4222 announce AS3582
as-out: to AS5650 announce AS3582
as-out: to AS2914 announce AS3582
as-out: to AS1798 announce AS3582
guardian: meyer@antc.uoregon.edu
admin-c: DMM65
tech-c: DMM65
notify: nethelp@ns.uoregon.edu
mnt-by: MAINT-AS3582
changed: meyer@antc.uoregon.edu 970316
source: RADB
Figure 2: Autonomous System Object
route: 128.223.0.0/16
descr: UONet
descr: University of Oregon
descr: Computing Center
descr: Eugene, OR 97403-1212
descr: USA
origin: AS3582
mnt-by: MAINT-AS3582
changed: meyer@ns.uoregon.edu 960222
source: RADB
Figure 3: Example of a route object
2.3 The Route Object
In contrast to aut-num objects which describe propagation
of routing information for an autonomous system as a whole,
route objects define single routes from an AS. An example was
already given in the introduction:
Alaettinoglu et. al. Expires September 26, 1997 [Page 6]
Internet Draft Application of RPSL March 26, 1997
This route object is maintained by MAINT-AS3582 and references
AS3582 by the origin attribute. By this reference it is
grouped together with other IP networks of same origin,
becoming member of the routing entity denoted by the
corresponding AS number. The routing policy is then defined
in the aut-num object for this group of routes.
Consequently, the route objects give the routes from this AS
which are distributed to peer ASs according to the rules of
the routing policy. Therefore, for any route in the global
routing table of the real world a route object must exist in
one registry of the IRR. Since routes from the global routing
table come from external peerings alone, as they are
described in the aut-num object, only route objects must be
registered in the IRR which should be seen outside your
AS. Normally, this set of external routes is different from the
routes internally visible within your AS. One of the major
reasons is that external peers need no information at all about
your internal routing specifics. Therefore, external routes are
in general aggregated combinations of internal routes, having
shorter IP prefixes where applicable according to the CIDR rules.
Please see the CIDR FAQ [4] for a tutorial introduction to
CIDR. It is strongly recommended that you aggregate your routes
as much as possible, thereby minimizing the number of routes
you inject into the global routing table and at the same time
reducing the corresponding number of route objects in the IRR.
While you may easily query single route objects using the whois
program, and submit objects via mail to the registry robots, this
becomes kind of awkward for larger sets. The RAToolSet [5]
offers several tools to make handling of route objects easier.
If you want to read policy data from the IRR and process it
by other programs, you might be interested in using peval which
is a low level policy evaluation tool. As an example, the
command
peval -h radb.ra.net -expand_all AS3582
will give you all route objects from AS3582 registered with
RADB.
A much more sophisticated tool from the RAToolSet to handle
route objects interactively is the route object editor roe.
It has a graphical user interface to view and manipulate
route objects registered at any IRR. New route objects may
be generated from templates and submitted to the registries.
Moreover, the route objects from the databases may be compared
to real life routes. Therefore, roe is highly recommended as an
interface to the IRR for route objects. Further information
on peval and roe is available together with the RAToolSet [5].
2.4 Set Objects
With routing policies it is often necessary to reference
groups of autonomous systems or routes which have identical
properties regarding a
Alaettinoglu et. al. Expires September 26, 1997 [Page 7]
Internet Draft Application of RPSL March 26, 1997
specific policy. To make working with such groups easier RPSL
allows to combine them in set objects. There are two basic
types of predefined set objects, as-set, and route-set. The
RPSL set objects are described below.
2.4.1 AS-SET Object
Autonomous system set objects (as-set) are used to group
autonomous system objects into named sets. An as-set has an
RPSL name that starts with ``AS-''. In the example in Figure
4, an as-set called AS-NERO-PARTNERS and containing AS3701,
AS4201, AS3582, AS4222, AS1798 is defined. The as-set is the
RPSL replacement for the RIPE-181 as-macro. Functionality is
the same but syntax is different.
AS-SETs are particularly useful when specifying policies for
groups such as customers, providers, or for transit. You are
encouraged to register sets for these groups because it is
most likely that you will treat them alike, i.e. you will
have a very similar routing policy for all your customers
which have an autonomous system of their own. You may as
well discover that this is also true for the providers you are
peering with, and it is most convenient to have the ASs
combined in one as-set for which you offer transit. For
example, if a transit provider specifies its import policy
using its customer's as-set (i.e., its as-in clause for the
customer contains the customer's as-set), then that customer can
modify the set of ASs that its transit provider accepts from
it. Again, this can be accomplished without requiring the
customer or the transit provider to modify its aut-num object.
as-set: AS-NERO-PARTNERS
members: AS3701, AS4201, AS3582, AS4222, AS1798
aut-num: AS3701
member-of: AS-NERO-PARTNERS
...
aut-num: AS4201
member-of: AS-NERO-PARTNERS
...
[etc]
Figure 4: as-set Object
The ASs of the set are simply compiled in a comma delimited list
following the members attribute of the as-set. This list may
also contain other AS-SETs. For an AS being member of an as-set
is indicated by the member-of attribute of the aut-num object.
Alaettinoglu et. al. Expires September 26, 1997 [Page 8]
Internet Draft Application of RPSL March 26, 1997
2.4.2 ROUTE-SET Object
A route-set is a way to name a group of routes. The syntax is
similar to the as-set. A route-set has an RPSL name that
starts with ``RS-''. The members attribute lists the members of
the set. The value of a members attribute is a list of
address prefixes, or route-set names. The members of the
route-set are the address prefixes or the names of other route
sets specified.
Figure 5 presents some example route-set objects. The set
rs-uo contains two address prefixes, namely 128.223.0.0/16
and 198.32.162.0/24. The set rs-bar contains the members of the
set rs-uo and the address prefix 128.7.0.0/16. The set
rs-empty contains no members.
route-set: rs-uo
members: 128.223.0.0/16, 198.32.162.0/24
route-set: rs-bar
members: 128.7.0.0/16, rs-uo
route-set: rs-empty
Figure 5: route-set Objects
3 Specifying Policies using RPSL
In this section we show how the various RPSL objects can be used
to specify typical Internet policies.
3.1 Provider-Customer Policies
In typical customer-provider relationships, the customer
imports all the routes that the provider has and exports its
routes to the provider. The provider's policies are
symmetrical in the sense that it exports all routes that it has
to the customer, and it imports only the customers
routes. Figure 6 illustrates one way of expressing these
policies using RPSL where AS3701 is the provider and AS3582 is
the customer. Refer to Figure 2 for AS3582's aut-num.
In this example, ``announce ANY'' means export any route that
AS3701 has registered, and ``accept <^AS3582$>'' means accept
only AS3582's routes (i.e., that have AS-PATHs of length
one, where the AS in the path is
Alaettinoglu et. al. Expires September 26, 1997 [Page 9]
Internet Draft Application of RPSL March 26, 1997
aut-num: AS3701
as-name: NERO-NET
descr: Network for Engineering and Research in Oregon
...
as-in: from AS3582 100 accept <^AS3582$>
as-out: to AS3582 announce ANY
...
guardian: meyer@antc.uoregon.edu
admin-c: DMM65
tech-c: DMM65
notify: noc@nero.net
mnt-by: MAINT-AS3701
changed: meyer@antc.uoregon.edu 970316
source: RADB
Figure 6: Provider-Customer Policies in RPSL
AS3582)(2). Note that AS3582 is taking full routing from
AS3701; this can be seen in that AS3701 is announcing ``ANY'',
and AS3582 is accepting ``ANY''. The important point in this
example is that if AS3582 adds or deletes route objects, there
is no need to update the aut-num objects. The added (or
deleted) objects will implicitly update AS3582's and AS3701's
policies, and thus affect their router configuration files.
As mentioned above, if the customer is itself a provider,
i.e. it has its own customers, the set of routes passed to
the provider includes its customers' routes as illustrated
in Figure 7. In this example, ``accept AS-NERO-PARTNERS''
means that for each AS X in the set defined by AS-NERO-PARTNERS
accept AS X's routes.
In this case shown in Figure 7, if AS3701 gets a new customer,
then it can update the definition of the AS-NERO-PARTNERS set
to include the new AS. The policies specified in the aut-num
objects for AS4600 and AS3701 do not change.
3.2 Inter-Provider Policies
In this case, the policies of both providers are to export
only their customer routes to the other provider, and to
import only the customer routes of the other provider. This
is commonly referred to as peerage. Figure 8 illustrates how
this is expressed using RPSL where both AS 3701 and AS AS2914
are providers. In this example, AS3701 advertises only the
------------------------------
2. AS-PATH regular expressions are POSIX compliant regular expressions, see
section 3.3.
Alaettinoglu et. al. Expires September 26, 1997 [Page 10]
Internet Draft Application of RPSL March 26, 1997
aut-num: AS4600
as-name: NERO-TRANSIT
descr: Network for Engineering and Research in Oregon
...
as-in: from AS3701 100 accept <^A3701+ (AS-NERO-PARTNERS)*$>
as-out: to AS3701 announce ANY
...
guardian: meyer@antc.uoregon.edu
admin-c: DMM65
tech-c: DMM65
notify: noc@nero.net
mnt-by: MAINT-AS4600
changed: meyer@antc.uoregon.edu 970316
source: RADB
Figure 7: Provider-Customer Policies in RPSL
AS paths described by the AS-SET AS-NERO-PARTNERS (i.e.,
customer routes). Likewise, we filter routes that come from
AS2914, accepting only those defined by the filter ``<^AS2914+
(AS-WNA)*$>'', i.e., those routes whose AS-PATH attribute ends
with an AS in the set defined by the AS-WNA AS-SET.
aut-num: AS3701
as-name: NERO-NET
descr: Network for Engineering and Research in Oregon
...
as-in: from AS2914 100 accept <^AS2914+ (AS-WNA)*$>
as-out: to AS2914 announce AS-NERO-PARTNERS
...
guardian: meyer@antc.uoregon.edu
admin-c: DMM65
tech-c: DMM65
notify: noc@nero.net
mnt-by: MAINT-AS3701
changed: meyer@antc.uoregon.edu 970316
source: RADB
Figure 8: Inter-Provider Policies in RPSL
3.3 AS-PATHS
In previous examples of routing policies special expressions
have been used to describe the ASs accepted from or announced
to peering partners. Actually, these expressions do not only
cover the ASs themselves but also
Alaettinoglu et. al. Expires September 26, 1997 [Page 11]
Internet Draft Application of RPSL March 26, 1997
+--------------------+ +--------------------+
| 7.7.7.1 |-----+ +-----| 7.7.7.2 |
| | | | | |
| AS1 | ======== | AS2 |
| | IX | | |
| | +-----| 7.7.7.3 |
+--------------------+ +--------------------+
Figure 9: Including interfaces in peerings definitions
their number and sequence. This is achieved by a mechanism
known as regular expressions. Those familiar with the UNIX
world or with programming languages like C or perl will most
likely already understood the details of the AS-PATHS displayed
in the examples. RPSL uses POSIX compliant regular expressions.
Regular expressions follow certain rules. Several characters
have special meanings, e.g. ``^'' denotes the beginning of a
string, ``$'' its end. Then it becomes obvious that the AS-PATH
<^AS3582$> accepted from AS3582 in Figure 7 has length one and
consists of AS3582 only.
Besides these positional indicators there are also operators,
e.g. the unary postfix operators ``+'' or ``*'' as seen in figure
8 which ASs are accepted by AS2914: <^AS2914+ (AS-WNA)*$>.
These operators work on the directly preceding regular
expressions, i.e. + only affects AS2914, and * only works on
(AS-WNA). Operator ``+'' means one or more occurrences,
operator ``*'' means zero or more occurrences. Now it becomes
obvious that the AS-PATHS accepted start with at least one
AS2914 but may as well be stuffed allowing several occurrences
of AS2914. Then the AS-PATH continues with no or any number
of any ASs out of the as-set AS-WNA. No other ASs may then
follow.
Apparently, quite complicated AS-PATHS can be expressed in a
very handy and short way. For a complete list of operators and
rules for regular expressions applicable to AS-PATHS in RPSL
refer to the RPSL document [1].
3.4 Including Interfaces in Peering Definitions
In the above examples peerings were only given among ASs.
However, the peerings may be described in much more detail by
RPSL. Actually, peerings are introduced among physical routers
using real IP addresses. These can be specified in the as-in
and as-out attributes. Figure 9 shows a simple example of two
ASs AS1 and AS2 which are connected to an exchange point
IX. While AS1 has only one connection to the exchange point
via a router interface with IP address 7.7.7.1, AS2 has two
different connections with IP address 7.7.7.2 and 7.7.7.3. The
first AS may then define its routing policy in more detail by
specifying its boundary router.
Alaettinoglu et. al. Expires September 26, 1997 [Page 12]
Internet Draft Application of RPSL March 26, 1997
aut-num: AS1
as-in: from AS2 at 7.7.7.1 accept <^AS2$>
...
This is very simple and does not make much of a difference
compared to a policy where no boundary router is specified
because AS1 in this example has only one connection to the
exchange point. However, AS1 might want to choose to accept
only announcements from AS2 which come from the router with
IP address 7.7.7.2 and disregard router 7.7.7.3. AS1 then
defines the following routing policy towards AS2:
aut-num: AS1
as-in: from AS2 7.7.7.2 at 7.7.7.1 accept <^AS2$>
...
So both routers involved in a peering may be specified and by
selecting certain pairs of routers other connections can be
denied. If no routers are included in a policy clause then it
is assumed that the policy is true for all peerings among the
ASs involved.
3.5 Describing Simple Backup Connections
The specification of peerings among ASs is not limited to one
router for each AS. In Figure 9 one of the two connections of
AS2 to the exchange point IX might be used as backup in case
the other connection fails. Let us assume that AS1 wants to
use the connection to router 7.7.7.2 of AS2 during regular
operations, and router 7.7.7.3 as backup. In a router
configuration this may be done by setting a local preference.
The equivalent in RPSL is a corresponding action definition in
the peering description. The action definitions are inserted
directly before the accept keyword.
aut-num: AS1
as-in: from AS2 7.7.7.2 at 7.7.7.1 action pref=10
from AS2 7.7.7.3 at 7.7.7.1 action pref=20
accept <^AS2$>
...
Actions may also be defined without specifying IP addresses of
routers. If no routers are included in the policy clause then
it is asumed that the actions are carried out for all peerings
among the ASs involved.
In the previous example AS1 controls where it sends its traffic
and which connection is used as backup. However, AS2 may
also define a backup connection in an as-out clause:
Alaettinoglu et. al. Expires September 26, 1997 [Page 13]
Internet Draft Application of RPSL March 26, 1997
aut-num: AS2
as-out: to AS1 7.7.7.1 at 7.7.7.2 action med=10
to AS1 7.7.7.1 at 7.7.7.3 action med=20
announce <^AS2$>
...
The definition given here for AS2 is the symmetric counterpart
to the routing policy of AS1. The selection of routing
information is done by setting the multi exit discriminator
metric med. Actually, med metrics will not be used in practice
like this; they are more suitable for load balancing including
backups. For more details on med metrics refer to the
BGP-4 RFC [6].
3.6 The aut-num Object Editor
All the examples shown in the previous sections may well be
edited by hand. They may be extracted one by one from the
IRR using the whois program, edited, and then handed back to
the registry robots. However, again the RAToolSet [5]
provides a very nice tool which makes working with aut-num
objects much easier: the aut-num object editor aoe.
The aut-num object editor has a graphical user interface to
view and manipulate aut-num objects registered at any IRR. New
aut-num objects may be generated using templates and submitted
ot the registries. Moreover, the routing policy from the
databases may be compared to real life peerings. Therefore,
aoe is highly recommended as an interface to the IRR for
aut-num objects. Further information on aoe is available
together with the RAToolSet [5].
4 Router Configuration Using RtConfig
RtConfig is a tool developed by the Routing Arbiter
project [7]) to generate vendor specific router configurations
from the policy data held in the various IRRs. RtConfig
currently supports Cisco, gated and RSd configuration formats.
RtConfig written in C++, C, lex, and yacc. It has been
publicly available since late 1994, and is currently being
used by several sites for router configuration. A few of the
sites currently using RtConfig include the Routing Arbiter
Project (USA), ANS (USA), CA*Net (Canada), IMNet (Japan),
VERIO (USA), Oregon-IX (USA), IAfrica (South Africa). The
next section describes a methodology for generating vendor
specific router configurations using RtConfig.(3)
------------------------------
3. Discussion of RtConfig internals is beyond the scope of this document.
Alaettinoglu et. al. Expires September 26, 1997 [Page 14]
Internet Draft Application of RPSL March 26, 1997
4.1 Using RtConfig
The general paradigm for using RtConfig involves registering
policy in an IRR, building a RtConfig source file, then running
running RtConfig against the source file and the IRR database
to create vendor specific router configuration for the
specified policy. The source file will contain vendor specific
commands as well as RtConfig commands; in particular, the
vendor specific policy configuration will be removed and
replaced with RtConfig commands. Commands beginning with
@RtConfig instruct RtConfig to perform special operations. An
example template file is shown in Figure 10. In this example,
commands such as ``@RtConfig import AS3582 198.32.162.1/32
AS3701 198.32.162.2/32'' instruct RtConfig to generate
vendor specific import policies where the router 198.32.162.1 in
AS3582 is importing routes from router 198.32.162.2 in AS3701.
The other @RtConfig commands instruct the RtConfig to use
certain names and numbers in the output that it generates
(please refer to RtConfig manual [7] for additional
information).
router bgp 3582
network 128.223.0.0
!
! Start with access-list 100
!
@RtConfig set cisco`access`list`no = 100
!
! NERO
!
neighbor 198.32.162.2 remote-as 3701
@RtConfig set cisco`map`name = "AS3701-EXPORT"
@RtConfig export AS3582 198.32.162.1/32 AS3701 198.32.162.2/32
@RtConfig set cisco`map`name = "AS3701-IMPORT"
@RtConfig import AS3582 198.32.162.1/32 AS3701 198.32.162.2/32
!
! WNA/VERIO
!
neighbor 198.32.162.6 remote-as 2914
@RtConfig set cisco`map`name = "AS2914-EXPORT"
@RtConfig export AS3582 198.32.162.1/32 AS2914 198.32.162.6/32
@RtConfig set cisco`map`name = "AS2914-IMPORT"
@RtConfig import AS3582 198.32.162.1/32 AS2914 198.32.162.6/32
...
Figure 10: RtConfig Template File
Once a source file is created, the file is processed by
RtConfig (the default IRR is the RADB, and the default vendor is
Cisco; however, RtConfig or command line options can be used to
override these values). The result of running RtConfig on the
source file in Figure 10 is shown in Figure 11.
Alaettinoglu et. al. Expires September 26, 1997 [Page 15]
Internet Draft Application of RPSL March 26, 1997
References
[1] C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, M. Terpstra, and
C. Villamizer: Routing Policy Specification Language (RPSL), Internet
draft, USC Information Sciences Institute, Work in Progress.
[2] T. Bates, J-M. Jouanigot, D. Karrenberg, P. Lothberg, and M. Terpstra.
Representation of IP Routing Policies in the RIPE database, Technical
Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993.
[3] T. Bates, E. Gerich, J. Joncharay, J-M. Jouanigot, D. Karrenberg,
M. Terpstra, and J. Yu. Representation of IP Routing Policies in
a Routing Registry, Technical Report ripe-181, RIPE, RIPE NCC,
Amsterdam, Netherlands, October 1994.
[4] Hank Nussbacher. The CIDR FAQ. Tel Aviv University and IBM Israel.
http://www.ibm.net.il/~hank/cidr.html
[5] The RAToolSet. http://www.ra.net/ra/RAToolSet/
[6] Y. Rekhter adn T. Li. A Border Gateway Protocol 4 (BGP-4). Request for
Comment RFC 1654. Network Information Center, July 1994.
[7] RtConfig as part of the RAToolSet.
http://www.ra.net/ra/RAToolSet/RtConfig.html
Alaettinoglu et. al. Expires September 26, 1997 [Page 16]
Internet Draft Application of RPSL March 26, 1997
router bgp 3582
network 128.223.0.0
!
! NERO
!
neighbor 198.32.162.2 remote-as 3701
no access-list 100
access-list 100 permit ip 128.223.0.0 0.0.0.0 255.255.0.0 0.0.0.0
access-list 100 deny ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
!
!
no route-map AS3701-EXPORT
route-map AS3701-EXPORT permit 1
match ip address 100
!
router bgp 3582
neighbor 198.32.162.2 route-map AS3701-EXPORT out
!
!
no route-map AS3701-IMPORT
route-map AS3701-IMPORT permit 1
set local-preference 1000
!
router bgp 3582
neighbor 198.32.162.2 route-map AS3701-IMPORT in
!
! WNA/VERIO
!
neighbor 198.32.162.6 remote-as 2914
!
no route-map AS2914-EXPORT
route-map AS2914-EXPORT permit 1
match ip address 100
!
router bgp 3582
neighbor 198.32.162.6 route-map AS2914-EXPORT out
no ip as-path access-list 100
ip as-path access-list 100 permit ^_2914(((_[0-9]+))* \
(13|22|97|132|175|668|1914|2905|2914|3361|3381|3791|3937| \
4178|4354|4571|4674|4683|5091|5303|5798|5855|5856|5881|6083 \
|6188|6971|7790|7951|8028))?$
!
no route-map AS2914-IMPORT
route-map AS2914-IMPORT permit 1
match as-path 100
set local-preference 998
!
router bgp 3582
neighbor 198.32.162.6 route-map AS2914-IMPORT in
!
! other Cisco commands
!
Figure 11: Output of RtConfig
Alaettinoglu et. al. Expires September 26, 1997 [Page 17]
Internet Draft Application of RPSL March 26, 1997
