<-
OCCAID > Lobby > Routing Registry Tutorial

Routing Registry Tutorial

Just like the real Internet, every member of the OCCAID community is required to register routing information about its network in a centralized routing registry. The routing registry is a policy information database that aims for better organization and integrity for the Internet routing table, and the same for the OCCAID community.

The routing registry uses a special language called Routing Policy Specification Language (RPSL) defined under RFC2622. RPSL is used to describe information about an Autonomous System (AS)'s routing policy, such as how it is connected to its adjacent ASes, and information about the IP address blocks an AS is claiming ownership on the Internet.

On the real world Internet, we have the Internet Routing Registry with some popular systems of registries such as Merit RADB and ALTDB. Here at OCCAID community, we use the centralized registry called TNRA Routing Registry. The TNRA Routing Registry uses Merit's IRRD software.

In order to maintain the integrity of the OCCAID community and also to better organize our routing information, every member's AS is filtered against TNRA registry. Therefore, every new member connecting to OCCAID must register its network information on TNRA as soon as possible. Failure to register network information to TNRA registry may result in sporadic routing and reachability problems accross the OCCAID community.

This tutorial will familiarize you with the RPSL language and also guide you with step by step in registering your network information to TNRA. Note that if RPSL is something that is new to you, this tutorial should help you how it works and how you use it in its basic form. RPSL is widely adapted by many backbone networks of the Internet to filter routing updates and build policy information.

In addition to this tutorial, you should take further readings about RPSL. It is also recommended that you read RFC2622.

top

Step 1. Create your maintainer object.

About the Maintainer Object

The maintainer object is your primary Point of Contact to describe your network's architecture. Your maintainer object is used to authorize any object creations, modifications, or deletions as well as being operational point of contact for operational issues with your network. In other words, if your network does not have a maintainer object, it cannot be maintained on the registry. There are four methods of authorization that can be used to authenticate object submissions through your maintainer object. They are listed below in decreasing order of security:

GPG
PGP
CRYPT-PW
MAIL-FROM


GPG, PGP and CRYPT-PW are authentication methods using encryption mechanisms. MAIL-FROM is not recommended because MAIL-FROM considers your "From:" e-mail address as its trust domain. Because e-mail addresses are easily spoofed, MAIL-FROM is a big security risk. We suggest that you use CRYPT-PW as it is generally secure, and very simple to use for authenticating object submissions.

To create your encrypted password using CRYPT-PW method, you can use any kind of widely available programs that can convert cleartext password into DES encrypted password string. You can also use the Crypt Calculator on Merit's RADB web site.

Register a Maintainer

First of all, in order to register an object in the registry, you must have an AS number. If you already have an AS number with one of the Regional Internet Registries (RIRs), you are all set. But if you don't have one from your RIR, you can simply use your private AS number that OCCAID assigned you*.

* Note: You cannot use private AS numbers on real world Internet routing registries such as RADB and ALTDB. You can do that safely on the TNRA registry which holds information only about the OCCAID connected networks.

Maintainer objects specify the persons who are allowed to execute updates to the registry, and how they are authenticated. When an information about your network such as AS or route information object is submitted, a Maintainer object is referenced in the submitted object using the mnt-by attribute. If a Maintainer object is not referenced, the submission will be rejected. So, in order to register information about your network to the registry, you must register a Maintainer object first.

To register your maintainer object, first you need to determine the names and e-mail addresses of persons from your organization who are allowed to update and/or submit network information objects such as Route and AS objects. Use the maintainer object template below to fill in the fields with appropriate information. The value of mnt-by attribute should be the same value of the mntner attribute. Later, you will find out that all objects must be signed with mnt-by attribute, which registers the object being submitted under your maintainer. Feel free to take a look at the example below.

Then copy the maintainer object template you just completed into an e-mail message and send it off to db-admin@cnacs.occaid.org. All maintainer object registrations must be reviewed by a human and a TNRA registry database administrator will review your template and then add the object to the registry. It may take up to several days as OCCAID is a volunteer based project and everyone is busy, but we will try our best to complete it early as possible.

NOTE: You should only send Maintainer object templates to db-admin@cnacs.occaid.org. Other network information objects including AS, Route, AS-SET, etc must be sent to auto-dbm@irrd.occaid.org. Maintainer objects are subject to human intervention before being committed to the registry. Other network information objects are instantly committed to the registry upon successful update sent to auto-dbm@irrd.occaid.org. If your Maintainer object is already created, but you wish to make changes, you may send modification of Maintainer object to auto-dbm@irrd.occaid.org for instantaneous modification.

Maintainer Template

mntner:
descr:
admin-c:
tech-c:
upd-to:
mnt-nfy:
auth:
notify:
mnt-by:
changed:
source: TNRA

Maintainer Example

Example MAINTAINER Template


mntner: MAINT-TOWARDEX Maintainer ID (Pick a name. But it should begin with MAINT- prefix)
descr: TowardEX Technologies Network Description of your organization
admin-c: HITS-ARIN Name or Handle of the Administrative Contact. If you have a nic-handle with your RIR such as ARIN, use your RIR handle. If not, just putting your full name should suffice.
tech-c: JDH73-ARIN Name or Handle of the Technical Contact. See above.
upd-to: ip-admin@twdx.net Email address to notify on during failed updates.
mnt-nfy: ip-admin@twdx.net Email address to notify on during successful updates.
auth: CRYPT-PW f00mac47b9a/RTo. Encrypted password generated using Merit RADB's Crypt Calculator
notify: ip-admin@twdx.net Email address to notify on any updates.
mnt-by: MAINT-TOWARDEX Same as mntner attribute
changed: ndf@towardex.com 20030617 Email address and date (YYYYMMDD) object changed
source: TNRA Name of the registry database you are submitting the object to

top

Step 2. Register AS and Policy Information

Registering the aut-num object

Now that you have Maintainer object installed into the registry, you need to register an object that details your AS's routing policy, such as how you are connected to the rest of the world.

In order to do this, you need some basic working knowledge of RPSL language to express your routing policy (for information about RPSL, read RFC2650). But unless you run a big network where you peer with another OCCAID members, you don't really need to worry about expressing your AS policies in RPSL, as you only have one upstream AS (AS30071/TBONE). In this case, you can just follow the example below.

If you are using CRYPT-PW authorization, you will need to put your password at the top of the aut-num object message beginning with the password: attribute. See example below to see how it is done.

Again, you need to sign your object with mnt-by attribute containing your Maintainer ID you submitted in the mntner attribute of the Maintainer object. Also don't forget to fill out the changed: field too.

Follow the example below, and it is a pretty straight forward process. If your AS is quite complex, where you peer with everybody, then you should read the RFC mentioned above.

From point here on, you should send all object submissions (including this aut-num object) to auto-dbm@irrd.occaid.org, NOT db-admin@cnacs.occaid.org. The Merit IRRD server runs on the auto-dbm@irrd.occaid.org email address and will immediately check the submitted object for syntax and authorization. If errors are detected, object is rejected and you will receive a FAILURE message back with reasons why it is rejected. If no errors are found, the submitted object will be commited to registry instantly in matter of seconds.

Aut-num Template

aut-num:
as-name:
descr: 
import: 
export: 
admin-c:
tech-c:  
notify:
mnt-by:     
changed:     
source:      TNRA

Aut-num Example

Example AUT-NUM Template


password: f00bar If you use CRYPT-PW in your Maintainer object for authentication, put your cleartext password here. If you do not use CRYPT-PW, erase the password: attribute.
aut-num: AS64646 Your AS Number
as-name: ASN-CNACS Short name for your AS (Do not use spaces)
descr: ACS Community Network
Weehawken, New Jersey
Descriptive name and general location of your network
import: from AS30071
accept ANY
Simple routing policy for inbound
export: to AS30071
announce AS64646
Simple routing policy for outbound
admin-c: SC1578-ARIN Name or Handle of the Admin Contact.
tech-c: TBC491-ARIN Name or Handle of the Tech Contact.
notify: nclist@cnacs.occaid.org Email address to notify on updates.
mnt-by: MAINT-CNACS Which maintainer can update this object.
changed: scl@choicestream.com 20021225 Email address and date (YYYYMMDD) object changed
source: TNRA Name of the registry database you are submitting the object to

If you are not very clear with the import: and export: attributes, it is probably because your AS has very simple BGP routing policy (i.e. accept all routes from your upstream and export your AS routes to your upstream). In that case you can use something like this:

import: from AS-ANY accept ANY
export: to AS-ANY announce ASYour AS Number

top

Step 3. Register Routes

Registering the route object

Now that your Maintainer and aut-num objects are installed into the registry, you now need to register an object that shows the routes your AS is originating, or rather claiming ownership of to rest of the world. This is done by submitting a route object. Again, if you use CRYPT-PW, you will need to add password: attribute at the top of the template, followed by your cleartext password.

Route object is pretty straight forward that you can simply follow the example below and send it off to auto-dbm@irrd.occaid.org for processing. Again, make sure you sign the template with your Maintainer object under mntner attribute, as well as put your email address and today's date in the changed attribute.

Route Template

route:
descr:
origin:
remarks:
notify:
mnt-by:
changed:
source: TNRA

Route Example

Example ROUTE Template


route: 65.124.16.0/24 Route in CIDR format
descr: TowardEX Technologies Inc
Systems Group SPECS-1
Boxborough, MA
Description and location of the network
origin: AS27552 AS originating this route
mnt-by: MAINT-TOWARDEX Which Maintainer object can update this entry
changed: haesu@towardex.com 20030808 Email address and date (YYYYMMDD) object changed
source: TNRA Name of the registry database you are submitting the object to

top

More Information and Caveats

1. What should I do after registering my network information using the above three step process?
Nothing really. You're all set. But if your AS is complex and you peer with many members and other networks, and if you also have downstream AS receiving connection from you, you should fill out an AS-SET object and submit it to auto-dbm@irrd.occaid.org. If you are this advanced, then you are in beyond the scope of this tutorial, thus you should pursue further readings on RFC2622 and RFC2650. Also Google search would help you too (as always).

2. I am quite confused which email address is which..
db-admin@cnacs.occaid.org is an address that humans read. You should send your first Maintainer object request to db-admin address as it requires a human to review the request first. Further, if you see any problems with the TNRA registry, you send it to db-admin address requesting help.
auto-dbm@irrd.occaid.org is an address that a computer reads. You should send all object submissions to this address with exception of creating Maintainer object. Do NOT send any other emails to auto-dbm, they will be ignored and deleted and NO human being will read them. Sending any emails that are not within the scope of auto-dbm's purpose is like talking to a wall.

3. Is there a way to check out the objects that I submitted?
Yep, whois -h whois.occaid.org OBJECT will do. Substitute OBJECT with the one you are looking for. For example, if you are querying for 65.124.16.0/24 route, you would do whois -h whois.occaid.org 65.124.16.0/24 and the system will return the database entry for it.

4. How about IPv6 support??
IPv6 support is coming soon, but we don't have it at this time.

5. I run an Internet routing registry for public networks. Should I mirror your TNRA registry too?
NO! NEVER mirror our database. Our database contains information only about OCCAID connected networks, and contains private ASNs and bogon routes that are only unique within our community. DO NOT, UNDER NO CIRCUMSTANCES, EVER MIRROR THIS DATABASE OUTSIDE OF THE OCCAID NETWORK, OR YOU WILL SUFFER THE CONSEQUENCES. You have been warned.

6. Is there a tutorial or more information available on the web that details advanced RPSL configurations, such as route-set, AS-SET, etc objects? I read the RFC but a tutorial would be nice.
Yes, ISI has an excellent tutorial about advanced RPSL and using RtConfig and RPSL to generate router configs. You can view it at http://www.isi.edu/ra/rps/training/tutorial/.