Table of Contents


Appendix A
RIPE-181

RIPE (Reséaux IP Européens) is a collaborative organization that consists of European Internet providers. RIPE and other contributors have developed a database language called RIPE-181 upon which all routing registries build their policies. The RIPE-181 language is now used to build the Routing Arbiter Database (RADB) that runs on the Route Servers (RS) of the Network Access Points (NAPs). The purpose of this Appendix is to make you familiar with some of the RIPE-181 objects and terminology.

RIPE Objects

The RIPE-181 language defines a set of objects used to define routing and filtering policies between different autonomous systems. The main objects comprising the registry are defined as follows:

•  maintainer: Indicating a registered maintainer of the autonomous system
•  aut-num: Indicating a specific autonomous system
•  route: Indicating a list of routes

Maintainer Object

The maintainer object specifies the registered party that is allowed to perform updates to the RADB. The first step in registering information in the database is to register one or more maintainer objects for the autonomous system. The format of the maintainer object looks like the following:

•  mntner: MAINT-AS1239 (Describes the maintainer name.)
•  descr: free text (A description of the Maintainer Object.)
•  admin-c: Jane Doe (Name or uniquely assigned NIC-handle of an administrative contact person.)
•  upd-to: bilx@ra.net (Update to any unauthorized update request of an object maintained by this maintainer will be forwarded to this address.)
•  mnt-nfy: abc@Jean.net (Maintainer notification. A notification of changes, additions, and deletions will be e-mailed to this address.)
•  auth: MAIL-FROM Joex@ddi.digital.n (Specifies a scheme to be used to identify and authenticate update requests from this maintainer. For example: MAIL-FROM specifies e-mail addresses of people allowed to modify the object.)
•  changed: xx@sprint.net 950621 (Who changed this object last and when was this change made.)
•  source: RADB (Defines the source of the information.)

AS Object

The AS object provides the contact information and the routing policies of an AS. The format of the AS object looks like the following:

•  aut-num: AS1111
•  descr: MYNET backbone (Description of the autonomous system.)
•  as-in: AS123 AND NOT AS456 (Description of accepted routing information from AS peers; there can be multiple as-in and as-out lines, to describe all facets of the routing policy.)
•  as-in: AS789 AS888
•  as-out: AS1111 AS2222 (Description of generated routing information sent to other AS peers.)
•  admin-c: Jane Doe (Name or uniquely assigned NIC-handle of an administrative contact person.)
•  tech-c: Jean Doe (Name or uniquely assigned NIC-handle of a technical contact person.)
•  mnt-by: MAINT-AS1790 (Registered maintainer name.)
•  changed: xx@test.net 951126 (Who changed this object last and when was this change made.)
•  source: RADB (Defines the source of the information.)

This AS object indicates that autonomous system number AS1111 belongs to "MYNET backbone," its maintainer's object name is "MAINT-AS1790," the last changes for this object were done by xx@sprint.net on 11/26/95, and the source of the record is the Routing Arbiter Database.

Route Object

The route object indicates a route that is injected on the Internet. The route object keeps track of the autonomous system that originated the route and hence would provide contact information about the maintainer of the route. The route object also references community objects (to be discussed in the next section) to group multiple routes under a single community name.

The following record indicates that the route aggregate 171.68.0.0/15 is part of Cisco Systems with origin AS200 and belongs to the COMM_NSFNET community.

•  route: 171.68.0.0/15
•  descr: Cisco Systems, Inc.
•  descr: 1525 O'Brien Drive
•  descr: Menlo Park
•  descr: CA 94025, USA
•  origin: AS200 (The autonomous system announcing this route.)
•  comm-list: COMM_NSFNET (List of communities this route is part of.)
•  mnt-by: MAINT-AS200
•  changed: nsfnet-admin@merit.edu 950312
•  source: RADB

Community Objects

Community objects define a group of routes that have something in common but as yet cannot be represented by a single AS or a group of ASs. Communities are useful in setting special access and usage policies (but not routing policies) to a group of routes. An example of a community object is COMM_ESNET, which represents the Energy Science Community. Each community is represented in the database via a community tag (comm-list) and a community object. The community tag represents the routes belonging to a certain community. To illustrate, let us look at the following example:

•  route: 13.13.0.0/16
•  descr: MYCOMPANY
•  origin: AS200
•  comm-list: COMM_ESNET COMM_US_FED
•  mnt-by: MAINT-AS200
•  changed: nsfnet-admin@merit.edu 950312
•  source: RADB
•  community: COMM_ESNET
•  descr: The Energy Science Community
•  authority: Energy Sciences Network (ESnet)
•  guardian: routing@es.net (E-mail address of the guardian of the AS.)
•  tech-c: Joe Smith
•  admin-c: Jane Doe
•  mnt-by: MAINT-ESNET
•  changed: xx@yy.gov
•  source: RADB

The preceding example shows that route 13.13.0.0/16 belongs to COMM_ESNET and COMM_US_FED communities; the community object COMM_ESNET is a description of the maintainer of that community.

Communities are just a representation of access and usage policies of certain routes and by themselves cannot set routing policies. They can, however, be used in conjunction with an AS's routing policies to define a set of routes for which the AS sets policy. Communities can be used for statistical purposes. A list of ASs belonging to Energy Science Community, for example, could be easily found by querying the database and looking for the comm-list tags.

AS Macros

AS macros are a way of grouping multiple ASs under one name. This will save the AS guardian the trouble of updating the as-in and the as-out field in the aut-num object anytime a new AS is added. The guardian would simply add or remove an AS from the macro as-list and hence the new list would be automatically applied to the aut-num. Following is an example:

•  aut-num: AS123
•  descr: SomeNet
•  as-in: from AS456 accept ANY
•  as-out: to AS456 announce AS-MYLIST
•  admin-c: Joe Smith
•  tech-c: Jane Doe
•  mnt-by: MAINT-AS123
•  changed: xx@xx.com
•  source: RADB
•  as-macro: AS-MYLIST
•  descr: ASs that I would like to announce
•  as-list: AS1111 AS2222 AS3333
•  guardian: Joe@xx.net
•  admin-c: Joe Smith
•  tech-c: Jane Doe
•  mnt-by: MAINT-AS123
•  changed: xx@xx.com
•  source: RADB

Based on the preceding descriptions, the as-list from the AS-MYLIST macro is applied where it is called by the AS object. Thus, the policy would be evaluated as follows:

•  aut-num: AS123
•  descr: SomeNet
•  as-in: from AS456 accept ANY
•  as-out: to AS456 announce AS1111 AS2222 AS3333 (The macro AS-MYLIST was applied here.)
•  guardian: Joe@xx.net
•  admin-c: Joe Smith
•  tech-c: Jane Doe
•  mnt-by: MAINT-AS123
•  changed: xx@xx.com
•  source: RADB

Setting Policies in the AS Object

The AS object is used to identify the autonomous system and to set policies between it and other ASs. These policies are basically a list of ASs to be accepted or a list of ASs to be advertised. An example of the fields used to set the policies are "as-in," which indicates the ASs to be accepted, and "as-out," which indicates the ASs to be advertised. Given the previous AS object for MYNET, figure A-1, illustrates how the policies are set.


Figure A-1  Setting policies in the AS object.

Given the connectivity illustrated in figure A-1, AS1111 chooses to accept any updates coming from AS123, AS789, and AS888 but no updates from AS456. AS1111 would like to advertise routes originating from AS1111 and its customer AS2222 to all other ASs, which leads to the following AS policy for AS1111:

•  as-in: AS123 AND NOT AS456
•  as-in: AS789 AS888
•  as-out: AS1111 AS2222

The first statement indicates that AS1111 will accept routes from AS123 but not from AS456. The second statement indicates that AS1111 will also accept routes from AS789 and AS888. The third statement indicates that AS1111 will advertise to everybody its own AS1111 plus its customer AS2222.

An AS that accepts routes from its neighbors and in turn advertises these routes to other neighbors is accepting to become a transit AS. ISPs are very careful about what routes they announce because no ISP wants to carry somebody else's traffic unless it is required to do so. In figure A-1, AS1111 is accepting routes from its neighbors and is only advertising its local and customer routes. This way, AS1111 will not receive any traffic destined to other than its own and customer networks.

The following are examples of policy setting using the AS object. In the first, AS123 accepts any routes coming from AS456 and only advertises its local routes (routes originated by AS123) to AS456.

•  aut-num: AS123
•  descr: SomeNet
•  as-in: from AS456 100 accept ANY
•  as-out: to AS456 announce AS123
•  guardian: Sam@xx.com
•  admin-c: Joe Smith
•  tech-c: Joe Smith
•  remarks: SomeNet Services
•  mnt-by: MAINT-AS123
•  changed: Some@body.com
•  source: RADB

Note the 100 in the as-in statement. This number indicates a relative cost for the route. Later, if the AS learns this route from other sources, the numbers associated with the identical routes will help the AS determine which one to take; it prefers the route with the lower number (lower cost).

In this next example, AS123 accepts only routes originated from AS456, announces all its routes to AS456, and uses route 10.10.0.0/16 learned from AS789 as a default route:

•  aut-num: AS123
•  descr: SomeNet
•  as-in: from AS456 100 accept AS456
•  as-out: to AS456 announce ANY
•  default: AS789 1 {10.10.0.0/16}
•  guardian: Sam@xx.com
•  admin-c: Joe Smith
•  tech-c: Joe Smith
•  remarks: SomeNet Services
•  mnt-by: MAINT-AS123
•  changed: Some@body.com
•  source: RADB

The 1 in the default statement is used in case multiple default statements are used in the same object; if one default goes away, the second will be used.

Setting Policies Based on Routes

In the same way that policies can be applied to the whole AS, they can be applied to specific routes. An autonomous system may choose to accept or deny a specific route out of all the routes that it announces or accepts from its neighbors. The routes are usually either a specific CIDR range or the default route 0.0.0.0/0.

In the following example, AS123 accepts only the route 10.10.0.0/16 from AS456 and advertises only the default route 0.0.0.0/0 to AS456.

•  aut-num: AS123
•  descr: SomeNet
•  as-in: from AS456 100 accept {10.10.0.0/16}
•  as-out: to AS456 announce {0.0.0.0/0}
•  guardian: Sam@xx.com
•  admin-c: Joe Smith
•  tech-c: Joe Smith
•  remarks: SomeNet Services
•  mnt-by: MAINT-AS123
•  changed: Some@body.com
•  source: RADB

In the following example, AS123 will accept 10.10.0.0/16, 11.11.0.0/16, and 12.12.0.0/16 from AS456 and will announce all routes except 0/0 to AS456:

•  aut-num: AS123
•  descr: SomeNet
•  as-in: from AS456 100 accept {10.10.0.0/16, 11.11.0.0/16, 12.12.0.0/16}
•  as-out: to AS456 announce ANY AND NOT {0.0.0.0/0}
•  guardian: Sam@xx.com
•  admin-c: Joe Smith
•  tech-c: Joe Smith
•  remarks: SomeNet Services
•  mnt-by: MAINT-AS123
•  changed: Some@body.com
•  source: RADB

A Practical Multi-AS Example of Routing Policies

Unless you are implementing and maintaining your AS routing policies at a NAP route server, you probably never will need to write RIPE language. However, understanding the logic behind policies is important; this logic can be applied to any situation where multiple ASs interconnect.

For a final example, we will consider policies not just with respect to a single AS, but in the more complex, more realistic situation of several interconnected networks. The AS object for each will reflect multiple in and out policies because of the multiple connections and the varying requirements of each network. We will begin with a textual description of the desired routing and then translate this into RIPE AS objects, one requirement at a time.

Figure A-2 illustrates an example in which AS4 is a major provider that is hooked up to the rest of the world via one of the NAPs. This environment has the following requirements:

1.  AS1 is multihomed to AS2 and AS4. AS1 uses AS4 as a primary route for all its external destinations. In case of link failure with AS4, AS1 uses AS2 as an exit point. AS1 sets a default toward AS2 and AS4 based on the single route 10.10.0.0/16 that it accepts from both ASs. AS1 prefers the default toward AS4 in normal operation.
2.  AS2 and AS3 are customers of AS4. AS2 and AS3 also have a private link to be used as the primary link for their inter-AS traffic. For all other Internet traffic, AS2 and AS3 will go via AS4.
3.  In case of a link failure between AS2 and AS4 or AS3 and AS4, AS2 and AS3 would like to use each other as a transit network to reach the outside world.
4.  In case of a direct link failure between AS2 and AS3, AS4 would be used to pass the traffic between the two ASs.
5.  In normal situations, AS4 should always reach AS1, AS2, and AS3 via the direct link to each of those ASs.


Figure A-2  Practical multi-AS example.

The following discussions consider each of these requirements in turn:

Requirement 1

To fulfill the first requirement, AS1 will default to both AS2 and AS4 with a lower cost to AS4 (AS4 would be preferred). To set the default, AS1 will accept route 10.10.0.0/16 from both ASs. AS1 may choose to accept as many routes as it wants, but it does not need to. From the other end, AS2 and AS4 will send the single route 10.10.0.0/16 to AS1. The corresponding RIPE configuration would look like the following.

•  aut-num: AS1
•  as-out: to AS2 announce AS1 (AS1 announces its routes only to AS2.)
•  as-out: to AS4 announce AS1 (AS1 announces its routes only to AS4.)
•  default: AS4 10 {10.10.0.0/16} (AS1 sets its default toward AS4 with a cost of 10.)
•  default: AS2 20 {10.10.0.0/16} (AS1 sets its default toward AS2 with a higher cost of 20.)

The 10 and 20 numbers above are relative costs with respect to AS2 and AS4. The peer with the lowest cost is used for default over ones with higher costs. The {10.10.0.0/16} is a route learned from both ASs and is used to indicate the default route. In normal cases, AS1 would prefer AS4. In case of a failure, the {10.10.0.0/16} route will not be learned from AS4, and the default will fall over to AS2. From AS2 and AS4 the configuration would be:

•  aut-num: AS2
•  as-out: to AS1 announce {10.10.0.0/16} (Announce a single route to AS1.)
•  as-in: from AS1 1 accept AS1
•  aut-num:AS4
•  as-out: to AS1 announce {10.10.0.0/16} (Announce a single route to AS1.)
•  as-in: from AS1 1 accept AS1

Requirement 2

To fulfill the second requirement, AS2 and AS3 would have to receive each other's routes from both the private link and AS4. To prefer the private link for inter-AS traffic, from AS2's perspective, the cost for the AS3 routes coming from AS3 should be lower than the cost of the AS3 routes coming from AS4. Similarly, from AS3's perspective, the cost of the AS2 routes coming from AS2 should be lower than the cost of the AS2 routes coming from AS4. The following RIPE configs should achieve this.

•  aut-num: AS2
•  as-in: from AS3 5 accept AS3
•  as-in: from AS4 10 accept ANY
•  as-out: to AS3 announce ANY
•  as-out: to AS4 announce AS1 AS2

This also applies to AS3:

•  aut-num: AS3
•  as-in: from AS2 5 accept AS2
•  as-in: from AS4 10 accept ANY
•  as-out: to AS2 announce ANY
•  as-out: to AS4 announce AS3

Requirement 3

With the preceding configuration, AS2 is accepting only AS3 routes from AS3 and AS3 is accepting only AS2 routes from AS2. In case of a link failure between AS2 and AS4, AS2 would not be able to reach the outside world because AS3 is not advertising these routes to it. In the same way, a link failure between AS3 and AS4 will prevent AS3 from reaching the outside world.

To take care of this situation AS2 and AS3 would have to announce all routes to each other and would have to accept all routes from each other. In normal situations (no link failures), AS2 would get all the outside routes from AS3 and from AS4; in the same way, AS3 would get the outside routes from AS2 and AS4. To prefer AS4, the cost of the routes from AS4 should be lower. The following will fulfill this requirement:

•  aut-num: AS2 (This is AS2's final configuration.)
•  as-in: from AS1 1 accept AS1
•  as-in: from AS3 5 accept AS3 (From AS3, set AS3 originated routes with a cost of 5.)
•  as-in: from AS3 12 accept ANY (From AS3, set all other routes with a cost of 12.)
•  as-in: from AS4 10 accept ANY (From AS4, set all routes with a cost of 10.)
•  as-out: to AS1 announce {10.10.0.0/16} (Announce a single route to AS1.)
•  as-out: to AS3 announce ANY (Announce all routes to AS3.)
•  as-out: to AS4 announce AS1 AS2 AS3 (Announce AS1, AS2, AS3 routes to AS4.)

The preceding configuration will make AS2 prefer all AS3's local routes via the private link because of the better cost of 5. All other routes will be accessed via AS4 because of the better cost of 10. Also, because AS4 should be able to reach AS2 via AS3 in case of a direct link failure, AS2 should advertise AS3 routes to AS4.

The same reasoning is applied for AS3:

•  aut-num: AS3 (This is AS3's final configuration.)
•  as-in: from AS2 5 accept AS2
•  as-in: from AS2 12 accept ANY
•  as-in: from AS4 10 accept ANY
•  as-out: to AS2 announce ANY
•  as-out: to AS4 announce AS3 AS2

Requirement 4

This requirement mandates that in case of a link failure between AS2 and AS3, the two ASs should be able to reach each other via AS4. This is achieved by allowing AS4 to announce all routes to AS2 and AS3.

•  aut-num: AS4
•  as-out: to AS2 announce ANY
•  as-out: to AS3 announce ANY

Requirement 5

AS4 should always reach AS1, AS2, or AS3 via the direct link. This requirement is achieved by having AS4 always set a lower cost via the direct link.

•  aut-num: AS4 (This is AS4's final configuration.)
•  as-in: from AS1 1 accept AS1
•  as-in: from AS2 5 accept AS1 AS2
•  as-in: from AS2 10 accept AS3
•  as-in: from AS3 5 accept AS3
•  as-in: from AS3 10 accept AS2
•  as-out: to AS1 announce {10.10.0.0/16}
•  as-out: to AS2 announce ANY
•  as-out: to AS3 announce ANY

In the preceding configuration, AS4 is accepting AS2 routes from AS2 and AS3 with a lower cost from AS2. Also, AS4 is accepting AS3 routes from AS2 and AS3 with a lower cost from AS3. As such, AS4 will always use the direct link unless a failure occurs.

Finding Information in the Database

One way to search the database is to run WHOIS on a Unix machine connected to the Internet. The syntax is: 

    whois -h hostname -s <source-database> key

Where <source-database> is the database where the information is kept, such as RIPE or RADB. The key is a keyword such as an IP CIDR block from a route object, an autonomous system number, a maintainer, or a community-list, and so on. The following is the output of whois -h whois.ra.net -s radb 171.68.0.0, which shows Cisco Systems as the owner of that route.

•  route: 171.68.0.0/15
•  descr: BN-CIDR-171.68
•  origin: AS109
•  mnt-by: MAINT-AS200
•  changed: vaf@valinor.barrnet.net 950517
•  source: RADB
•  route: 171.68.0.0/15
•  descr: Cisco Systems, Inc.
•  descr: 1525 O'Brien Drive
•  descr: Menlo Park
•  descr: CA 94025, USA
•  origin: AS200
•  comm-list: COMM_NSFNET
•  mnt-by: MAINT-AS200
•  changed: nsfnet-admin@merit.edu 950312
•  source: RADB


Table of Contents