NETS header NETS Homepage UCAR Homepage NCAR Homepage SCD Homepage NETS Homepage About NETS Work requests & support
  Browse NETS topics: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Routing Registries and the ARIN Whois database (NETS notes)
Pete Siemsen, 2006-05-01

Introduction

This web page describes routing registries and the ARIN whois database, and the procedures used by UCAR and the FRGP to access and modify these databases. We do this for the following reasons:
  1. We maintain the Level 3 routing registry because it is the mechanism by which we inform Internet Service Providers (ISPs) (including Level 3) about the routes used by the FRGP. The ISPs use the information to configure their routers to allow the FRGP to access the Internet.
  2. We maintain the ARIN Whois database to be good Internet citizens. The database is used by the Internet community to identify the "owner" of all IP address ranges, which ARIN calls networks. This is essential when debugging routing problems or when tracking down the source of abuse (hacker attacks). If we didn't update the ARIN Whois database, people would have trouble identifying the FRGP's routes. For example, suppose an FRGP member's machine sourced a hacker attack, and no entry for the FRGP member's specific IP range existed in the ARIN Whois database. Queries to the database would return the less specific IP range owner - the FRGP, and we'd be contacted instead of the FRGP member. Time and energy would be wasted while we identified the FRGP member contact and passed the problem on to them.
Unfortunately, the relationship between routing registries and the ARIN whois database can be confusing. They are distinct databases, but they contain similar information, and both can be queried using the Unix "whois" command. Routing registries are usually used by ISPs, who use routing registry data to configure their routers. Anyone can query the routing registries for information, but that is not their primary purpose. The ARIN whois database contains information about networks (routes) allocated by ARIN, as well as information about how those networks have been partitioned by ISPs. ARIN uses this information to keep track of who "owns" each network used in the Internet. ARIN provides access to the whois database to the public. To really add to the confusion, ARIN runs a routing registry that is unrelated to the whois database. To add more confusion, routing registry software refers to "routes", while the ARIN whois database refers to the same thing as "networks".

ARIN Whois database

Introduction to ARIN

ARIN is a for-profit company tasked with assigning IP address space for North America, South America, sub-Saharan Africa, and the Caribbean. It started administering IP networks (routes) in 1997. Networks that were allocated before 1997 are recorded in the ARIN whois database, and ARIN allows the owners of those networks to maintain them free of charge. Networks that were allocated after 1997 are also recorded in the ARIN whois database, but the owners of those networks are charged a yearly maintenance fee by ARIN. When ARIN allocates a new network, the owner of the new network is charged the yearly fee. Also, when an existing network is transferred to a new owner, the new owner is charged the yearly fee, regardless of whether the previous owner was charged a fee or not.

TODO:

As of 2002-08-30, the ARIN records for NCAR/UCAR include

Introduction to the ARIN whois database

ARIN's whois database contains networks, autonomous system (AS) numbers, organizations or customers that are associated with these resources, and related Points of Contact (POC). These are the record types in the database: The database can be queried by anyone. One might use the ARIN database to find out who owns a network, in order to discover who to notify about anomalous traffic. The ARIN whois database is often used to pursue hacker attacks. It is important that ARIN's routing registry contain accurate ownership information, so that time and energy is not wasted when hacker attacks are being traced. For instance, UCAR might be unable to trace an attack on UCAR.

To update the ARIN whois database, you send email messages to ARIN. The messages follow a specific format, so that software can parse the messages and update the database. To make messages in the correct format, you get a template message from ARIN and modify it using a text editor.

How to get Information from ARIN

Using the ARIN website

The usual way to get information from ARIN is through the ARIN website. The web interface is a pretty front-end for the Unix whois program. You can use the whois program directly to get information from ARIN. See the next section.

Using whois to access ARIN

You can use the Unix whois program to get information from the ARIN whois database. On Unix systems, the man page for whois doesn't adequately describe how to use the whois program to access the ARIN whois database. To get better information, do
whois -h whois.arin.net ?
This resource is loaded with good information, so as a convenience, it is available here.

Here's an example: 

    $ whois -h whois.arin.net 128.117.0.0
    National Center for Atmospheric Research (NET-UCAR)
       P.O. Box 3000
       Boulder, CO 80307-3000
       US

       Netname: UCAR
       Netblock: 128.117.0.0 - 128.117.255.255

       Coordinator:
          Arnold, Ed  (EA8-ARIN)  [No mailbox]
          (303) 497-1282

       Domain System inverse mapping provided by:

       DNS.UCAR.EDU                 192.52.106.6
       DNS2.ITD.UMICH.EDU           141.211.125.15

       Record last updated on 14-Jun-1993.
       Database last updated on  29-Jul-2002 20:00:19 EDT.

ARIN Point Of Contact (POC) objects

In the ARIN whois database, information about people is stored in Point of Contact or POC objects. When someone looks information in the ARIN whois database, the results often contain references to one or more POCs, and the POCs supply telephone numbers and email addresses. Most POCs contain information for a single individual, but some POCs are for a "role", like "network operations center" or "network abuse report handler". This provides a little flexibility, and prevents awkwardness like having person named "Network Operations Center".

For purposes of authorization, an organization should define the following POCs:

Administrative
Required contact that is responsible for overseeing all allocations or assignments for the organization. The administrative contact is the only person authorized to return allocations/assignments to ARIN. All organizations are limited to a single administrative contact. This is the person who administers ARIN changes, not the person who has administrative responsibilities for an organization.

The administrative POC has the most authority to make changes, and is authorized to make the following changes to the ARIN whois database:

As of 2002-08-30, the administrative POC for NCAR is Pete Siemsen, an individual POC.

Technical
Optional contact responsible for the technical aspects of maintaining the assigned network address space. This POC should be able to answer troubleshooting and operational questions about the network. The technical POC may make modifications to assigned blocks and SWIPs.

The technical POC is authorized to make the following changes to the ARIN whois database:

As of 2002-08-30, the technical POC for NCAR is , a role POC that lists the phone number of the NCAR NOC and the email address of the NETS engineers. Since the technical POC is not an individual, the technical POC doesn't send changes to the ARIN whois database.

Abuse
Optional contact responsible for handling operational aspects of the acceptable or appropriate uses of the allocated network. The abuse POC has no authority to make changes to the ARIN whois database.

As of 2002-08-30, the abuse POC for NCAR is ABUSE18-ARIN, a role POC that lists the phone number of the NCAR NOC and the email address of abuse@ucar.edu.

Network Operations Center
Optional contact responsible for network operations and troubleshooting. The NOC POC has no authority to make changes to the ARIN whois database.

As of 2002-08-30, the NOC POC for NCAR is NOC116-ARIN, a role POC that lists the phone number of the NCAR NOC and the email address of the NCAR NOC.

For instance, as of August 2002, the "Technical Contact" POC for network 128.117.0.0 is "EA8-ARIN", which is Ed Arnold, and the "Technical Contact" POC for network 128.116.0.0 route object is "GW74-ARIN", which is Greg Woods. There are no "Abuse" or "NOC" POCs defined for these networks.

I plan change these, but whoa. I could change them to "PS24-ARIN", which is Pete Siemsen, but that isn't what we really want, because I might quit. We want the "Technical Contact" POC to be something that represents all the network engineers. I plan to create such a "role" POC.

There is already a POC named "ZN10-ARIN", with 303-497-1200 and "ne@ucar.edu". This can be used for a Technical POC. If, as I've been told, an email sent from a ".ucar.edu" address is sufficient to allow modification of any of this information (!) then I can change the Technical POC for our two addresses to be ZN10-ARIN.

How to create a new ARIN POC

Here's how I created a new "Abuse" POC for NCAR. I went to the ARIN Library, which contains the email templates. I saved the POC template to a local file and edited it, following the directions in the template. Then I emailed it to ARIN as follows: 
    To: hostmaster@arin.net
    From: Pete Siemsen <siemsen@ucar.edu>
    Subject: POC TEMPLATE
    Date: Wed, 28 Aug 2002 17:08:17 -0600

    Template: ARIN-POC-3.0
    1. Registration Action: N
    2. Handle:
    3. Contact Type: R
    4. Last Name or Role Account: Abuse
    5. First Name:
    6. Middle Name:
    7. Additional Information:
    8. Company Name: National Center for Atmospheric Research
    9a. Address: 1850 Table Mesa Drive
    10. City: Boulder
    11. State/Province: CO
    12. Postal Code: 80305
    13. Country Code: US
    14. Phone Type: O
    15. Phone Number: +1-303-497-1200
    16. Phone Extension:
    17. E-mail Address: abuse@ucar.edu
    18. Public Comments:

    END OF TEMPLATE
The reply email from ARIN contained the handle for the new POC: ABUSE18-ARIN.

How to modify an ARIN POC

ARIN POCs can be a "individual" or a "role" accounts, where role accounts represent multiple individuals. Copy the ARIN Modification Template into an email buffer. Then: Then send the email message to hostmaster@arin.net and be prepared to wait for a reply. Or rather, you'll get a fairly quick automated reply that says "be prepared to wait up to 3 business days for a real reply".

For example, I modified the zip code part of my ARIN POC object by sending the following email message: 

    To: hostmaster@arin.net
    From: Pete Siemsen
    Subject: modify my POC
    Reply-to: Pete Siemsen
    x-url: http://www.scd.ucar.edu/nets/intro/staff/siemsen
    Date: Wed, 31 Jul 2002 10:36:33 -0600
    Sender: siemsen@proteus

    09/01  ARIN Modification Template

    **************** Please DO NOT REMOVE Version Number ***************

    Modification Template Version Number: 1.0

    **************** Please see detailed instructions ******************

    Authorization
    0a. (R)eturn (M)odify (D)elete......: M
    0b. (A)SN ..........................:
    0c. (N)etwork.......................:
    0d. (P)oint of Contact..............: P

    ASN Information
    1a. ASN Handle......................:
    1b. AS Number.......................:

    Network Information
    2a. Network Name....................:
    2b. Start of Network Block..........:
    2c. End of Network Block............:

    Organization
    3a. Name of Organization............:

    Postal Address of Organization
    3b. Street Address..................:
    3c. City............................:
    3d. State/Province..................:
    3e. Postal Code.....................:
    3f. Country Code....................:

    Point of Contact Information
    4a. ARIN Handle ....................: PS24-ARIN
    4b. (I)ndividual (R)ole.............:
    4c. Name.(Last, First)..............:
    4d. Organization Name...............:
    4e. Street Address..................:
    4f. City............................:
    4g. State/Province..................:
    4h. Postal Code.....................: 80305
    4i. Country Code....................:
    4j. Phone Number....................:
    4k. Fax Number......................:
    4l. E-Mailbox.......................:

    Primary Name Server
    5a. Primary Host Handle.............:
    5b. Primary Server Hostname.........:
    5c. Primary Server Netaddress.......:

    Secondary Name Server(s)
    6a. Secondary Host Handle...........:
    6b. Secondary Server Hostname.......:
    6c. Secondary Server Netaddress.....:

    6a. Secondary Host Handle...........:
    6b. Secondary Server Hostname.......:
    6c. Secondary Server Netaddress.....:

    6a. Secondary Host Handle...........:
    6b. Secondary Server Hostname.......:
    6c. Secondary Server Netaddress.....:

    7.  Comment.........................:
The above example modified an "individual" POC object. The following example shows how I modified the ZN10-ARIN POC object, which is a "role" person object for NCAR. Role POC objects allow a company to define a set of individuals, any of whom can own other objects. In the following case, I modified the zip code and the email address with one request. 
    To: hostmaster@arin.net
    From: Pete Siemsen
    Subject: modify our role account
    Reply-to: Pete Siemsen
    x-url: http://www.scd.ucar.edu/nets/intro/staff/siemsen
    Date: Wed, 31 Jul 2002 11:24:03 -0600
    Sender: siemsen@proteus

     09/01  ARIN Modification Template

        **************** Please DO NOT REMOVE Version Number ***************

        Modification Template Version Number: 1.0

        **************** Please see detailed instructions ******************

        Authorization
        0a. (R)eturn (M)odify (D)elete......: M
        0b. (A)SN ..........................:
        0c. (N)etwork.......................:
        0d. (P)oint of Contact..............: P

        ASN Information
        1a. ASN Handle......................:
        1b. AS Number.......................:

        Network Information
        2a. Network Name....................:
        2b. Start of Network Block..........:
        2c. End of Network Block............:

        Organization
        3a. Name of Organization............:

        Postal Address of Organization
        3b. Street Address..................:
        3c. City............................:
        3d. State/Province..................:
        3e. Postal Code.....................:
        3f. Country Code....................:

        Point of Contact Information
        4a. ARIN Handle ....................: ZN10-ARIN
        4b. (I)ndividual (R)ole.............: R
        4c. Name.(Last, First)..............:
        4d. Organization Name...............:
        4e. Street Address..................:
        4f. City............................:
        4g. State/Province..................:
        4h. Postal Code.....................: 80305
        4i. Country Code....................:
        4j. Phone Number....................:
        4k. Fax Number......................:
        4l. E-Mailbox.......................: ne@ucar.edu

        Primary Name Server
        5a. Primary Host Handle.............:
        5b. Primary Server Hostname.........:
        5c. Primary Server Netaddress.......:

        Secondary Name Server(s)
        6a. Secondary Host Handle...........:
        6b. Secondary Server Hostname.......:
        6c. Secondary Server Netaddress.....:

        6a. Secondary Host Handle...........:
        6b. Secondary Server Hostname.......:
        6c. Secondary Server Netaddress.....:

        6a. Secondary Host Handle...........:
        6b. Secondary Server Hostname.......:
        6c. Secondary Server Netaddress.....:

        7.  Comment.........................: My phone number is 303-497-1810

ARIN Organization objects

The organization object record for NCAR has the handle "NCAR". Here's how to look up the Org object: 
    $ whois -h whois.arin.net o NCAR
    [whois.arin.net]

    OrgName: National Center for Atmospheric Research
    OrgID:   NCAR
    Address: P.O. Box 3000 Boulder, CO 80307-3000
    Country: US
    Comment:
    RegDate: 1986-03-24
    Updated: 1993-06-14
To lookup all the resources that NCAR owns, go to the ARIN website and do, like, 
    ! > NCAR

ARIN SWIP objects

SWIP stands for Shared WHOIS Project. While the original "project" is dead, the concept of SWIP is used at ARIN, and is described by the ARIN Guidelines for Reporting Reassignment Information. For general information about how IP addresses are allocated, see RFC 2050: Internet Registry IP Allocation Guidelines.

UCAR has allowed the FRGP to use the 128.116.0.0/16 network for FRGP secondaries. Chunks of 128.116.0.0/16 have been given to FRGP members. Using SWIPs, UCAR can register this in the ARIN whois database. This registers the party responsible for the chunk as UCD. This way, when some high school hacker behind UCD causes grief to the Internet, and someone queries the ARIN whois database using an IP address at the high school, information about UCD will be returned, not UCAR. If UCD registers the use of their parts of their chunk of 128.116.0.0/16 with ARIN, then a query would return information about the high school and not UCD.

From ARIN's perspective, UCAR is an "ISP" that has been "allocated" the 128.116.0.0/16 range, and UCAR has "reassigned" this range to "end-user customers". To register this in the ARIN whois database, someone should define SWIP objects in the ARIN routing registry for each fragment of 128.116.0.0/16. These fragments are defined by SWIP objects, and not regular route objects. 128.116.0.0 is defined by a regular network object.

To see how we've divided the 128.116.0.0-16, log in on the FRGP Juniper router and use the command "run show route 128.116.0.0/16 range". It shows:

We could send ARIN three "reallocate" templates to turn over responsibility for registering these ranges to the three members. They would then have to update ARIN. Or, we can assume responsibility for registering all the secondaries, and then send a "reassign-simple" template for each secondary.

Introduction to Routing Registries

Routing registries are databases of information about IP routes. Routing registries are used by Internet Service Providers to keep track of IP routes advertised by their customers. ISPs use this information to configure packet filters and the BGP routing protocol in their routers. For more detailed information about routing registries, see the Internet Routing Registry RPSL home page.

Anyone can search routing registries to get information about routes, as described below. The information in the registries is maintained by the people that "own" IP routes. For instance, Level 3 permits its customers to change the data in the Level 3 routing registry. Routing registries mirror one other, which means that you can get information about a given route by querying any routing registry, not just the registry that actually contains the information.

To get information from a routing registry, you can use the Unix whois command. Some routing registries provide a web interface to the routing registry.

Among other things, routing registries contain information about routes and the relationships between routes, as well as people's names, addresses, email addresses, and telephone numbers. This information is organized into objects. For example, a person object contains the name, address, email address and telephone number of a person, and a route object contains information about an IP route, including the prefix and what person to contact about the route.

Routing registries can contain information about as-sets, which provide information about the autonomous systems that are advertised by a site. We maintain an AS-set named AS-FRGP in the Level 3 routing registry. It lists all the ASes that are "behind" the FRGP. Level 3, Qwest and ESnet use the AS-set to define the routes that they accept from the FRGP. It is important to remember that the AS-set defines the routes that we might advertise, not necessarily the routes we do advertise. For example, AS210 (Utah) is in the AS-set, so Level 3, Qwest and ESnet would accept prefixes from the FRGP that have AS210 origins. We advertise Utah's routes to ESnet, but not to Level 3 or Qwest, because Utah's contract with the FRGP does not include access to the FRGP's commodity providers.

To make changes to routing registries, network engineers send email messages to the companies that own the registries. These messages contain specially-formatted requests to add, delete or modify objects in the registry. Routing registry software is standardized, so once you've learned how to update one routing registry, you know how to update other registries.

Data in routing registries is maintained in a distributed fashion; each customer that "owns" an IP address block is responsible for updating objects that describe the block. To keep people from updating someone else's objects, each object in a registry is "owned" by a person or set of people. Only the owner(s) can modify the object. In the Level 3 registry, objects are owned by maintainer objects. Contrast this with the ARIN whois database, where objects are owned by Point Of Contact or POC objects.

Not all ISPs use routing registries. The FRGP connects to ISPs named Level 3, Qwest, and ESnet, among others. Level 3 maintains a routing registry. Qwest and ESnet use routing registries to configure their routers, so Qwest and ESnot are sensitive to whatever we put in the Level 3 routing registry.

When we make a routing change at the FRGP, we email a routing registry update message to Level 3, and their software handles the message. We may also send a routing registry update message to message to ARIN, where ARIN's software handles the message.

When we send requests to the routing registries at Level 3 and ARIN, we update only the information that pertains to UCAR and to the FRGP and its members. The information describes the four IP blocks used by UCAR and several IP blocks used by the FRGP and its members.

UCAR is a Level 3 customer, so we are allowed to maintain entries in the Level 3 routing registry. Customers of other ISPs may not have a way to update a routing registry, yet they may want to register their routes. Such people can pay the Merit RADB Routing Registry for routing registry service. For about $250/year, the FRGP and/or UCAR could buy routing registry service from Merit. This would protect us from problems if/when we stop being Level 3 customers. Historically, we have encountered no problems when we terminated our customer relationship with an ISP, so there seems to be little reason to do this.

LV3-RR, the Level 3 Routing Registry

Introduction to LV3-RR

For a description of the Level 3 routing registry, see the Level 3 Routing Registry User Guide. That manual is of little direct value to us, as it describes a web interface that only Level 3 personnel can access. Customers have to use the much klunkier email interface. Still, it has a good description of the routing registry and the flow of information through it.

The Level 3 routing registry (LV3-RR) defines the IP blocks that are owned by Level 3's customers. For example, UCAR is a Level 3 customer, and maintains a "route object" in the LV3-RR for each IP route "owned" by UCAR. UCAR also maintains route objects in the LV3-RR for the FRGP and the FRGP members. Level 3 uses these route objects to define BGP filters in the Level 3 router that services the FRGP. If there were a mismatch between the route objects in the Level 3 registry and the actual routes owned by the FRGP, then the routes advertised by the FRGP router to Level 3 would not be accepted by the Level 3 router, and FRGP routing would fail.

Level 3 applies the contents of its routing registry to the Level 3 routers every night sometime between midnight and 7:00am EST. For each customer, the Level 3 software scans the LV3-RR for all route objects that match the "import-pol" defined in the "peer-as" object in the registry. For the FRGP, the peer-as object is AS-FRGP, which as of 2002-12-18 had an import-pol of "AS-FRGP". This meant "match all route objects that have an origin field listed in the as-set named AS-FRGP". See How to show a LV3-RR AS-set object. Note that the FRGP router advertises routes for FRGP members that don't do BGP with the FRGP.

How to get Information from the Level 3 routing registry

Using whois to access Level 3 routing registry

Use the Unix whois program to get information from the Level 3 routing registry.

Here are some examples:

How to show a LV3-RR person object
Here's how to show the person object that describes Pete Siemsen. 
$ whois -h rr.level3.net siemsen

% RIPEdb(3.0.0a13) with ISI RPSL extensions

person:        Pete Siemsen
address:       AS14041/FRGP
phone:         +1 303 497 1810
nic-hdl:       PS5-LEVEL3
mnt-by:        FRGP
changed:       siemsen@ucar.edu 20020730
source:        LEVEL3
How to show a LV3-RR route object
Careful! If there are overlapping routes in the Level 3 routing registry, then you must specify the suffix on the route in order to select the "right" entry. 
    $ whois -h rr.level3.net 128.117.0.0/16

% RIPEdb(3.0.0a13) with ISI RPSL extensions

route:         128.117.0.0/16
descr:         National Center for Atmospheric Research
               1850 Table Mesa Drive
               Boulder, CO 80305, USA
               Boulder, CO, USA
               http://www.ucar.edu/
origin:        AS194
mnt-by:        FRGP
changed:       siemsen@ucar.edu 20021223
source:        LEVEL3

route:         128.117.0.0/16
descr:         route update via web
origin:        AS14041
mnt-by:        MAINT-AS14041
changed:       thomas.lutzenberger@wcg.com 20040903
source:        WCGDB

route:         128.117.0.0/16
descr:         National Center for Atmospheric Research
descr:         1850 Table Mesa Drive
descr:         Boulder, CO 80305, USA
descr:         Boulder, CO, USA
descr:         http://www.ucar.edu/
origin:        AS194
mnt-by:        FRGP
changed:       siemsen@ucar.edu 20021223
source:        CW
How to show a LV3-RR mntner object
    $ whois -h rr.level3.net FRGP

% RIPEdb(3.0.0a13) with ISI RPSL extensions

mntner:        FRGP
descr:         AS14041/FRGP
admin-c:       MM3-LEVEL3
tech-c:        PS5-LEVEL3
upd-to:        siemsen@ucar.edu
mnt-nfy:       siemsen@ucar.edu
mnt-nfy:       frgp-eng@ucar.edu
auth:          MAIL-FROM siemsen@ucar.edu
auth:          MAIL-FROM jph@ucar.edu
auth:          MAIL-FROM mitchell@ucar.edu
auth:          MAIL-FROM jcustard@ucar.edu
notify:        frgp-eng@ucar.edu
mnt-by:        FRGP
changed:       jcustard@ucar.edu 20080915
source:        LEVEL3

mntner:        FRGP
descr:         AS14041/FRGP
admin-c:       MM2-SAVVIS
tech-c:        PS5-SAVVIS
upd-to:        siemsen@ucar.edu
mnt-nfy:       siemsen@ucar.edu
auth:          MAIL-FROM siemsen@ucar.edu
auth:          MAIL-FROM colburn@ucar.edu
auth:          MAIL-FROM mitchell@ucar.edu
auth:          MAIL-FROM jcustard@ucar.edu
notify:        siemsen@ucar.edu
mnt-by:        FRGP
changed:       siemsen@ucar.edu 20010327
source:        SAVVIS
How to show a LV3-RR AS object
$ whois -h rr.level3.net as14041

% RIPEdb(3.0.0a13) with ISI RPSL extensions

aut-num:       AS14041
as-name:       UCAR
descr:         AS record for UCAR
admin-c:       IPCC-WCG
tech-c:        IPCC-WCG
import:        from AS7911  accept ANY
export:        to AS7911  announce AS14041
notify:        noc@wcg.net
notify:        frgp-eng@ucar.edu
mnt-by:        MAINT-AS14041
changed:       brent@wcg.com 20040903
source:        WCGDB
This shows one AS object describing AS 14041.
How to show a LV3-RR AS-set object
    $ whois -h rr.level3.net AS-FRGP
    
% RIPEdb(3.0.0a13) with ISI RPSL extensions

as-set:        AS-FRGP
descr:         FRGP ASes
members:       AS104, AS194, AS210, AS2648,
               AS2902, AS7872, AS12145, AS13555,
               AS14041, AS15295, AS16519,
               AS17294, AS18815, AS25825,
               AS23458, AS31991, AS32920,
               AS36081, AS36691, AS36704, AS39990
              
admin-c:       MM3-LEVEL3
tech-c:        PS5-LEVEL3
notify:        frgp-eng@ucar.edu
mnt-by:        FRGP
changed:       jcustard@ucar.edu 20080915
source:        LEVEL3
This shows the FRGP as-set objects as it is known to two routing registries: Level 3 and Cable & Wireless. An AS-set allows an ISP like the FRGP to describe the ASes that it advertises. Maintaining an as-set is cleaner than maintaining a comprehensive list of all the individual routes that each downstream AS advertises to the FRGP.

As of 2008-01-15, the FRGP as-set contains:

AS NumberWho
104CU
194NCAR
210UEN
2648NIST/Dept. of Commerce (NOAA)
2902UW
7872USAP
12145CSU
13555CBOCES
14041FRGP
15295UNC
16519UCDHSC
17294CARL
18815City and County of Denver
25825Poudre Valley Hospital
23458Denver Health and Hospital Authority
31991Platte River Power Authority
32920Ithaka
36081State of Colorado General Government Computer
36691CSU-Pueblo
36704Colorado School of Mines
39990Boulder County Government

How to modify a Level 3 Person Object

Follow Level 3's basic instructions for How to Modify an Object in the LV3-RR. For example, I modified the telephone number in my Level 3 person object by sending the following email message: 
    To: rpsl@Level3.net
    From: Pete Siemsen
    Subject: change my person object

    person:       Pete Siemsen
    address:      AS14041/FRGP
    phone:        +1 303 497 1810
    nic-hdl:      PS5-CW
    mnt-by:       FRGP
    changed:      siemsen@ucar.edu
    source:       CW

Level 3 maintainer objects

It is unwieldy to have individuals own objects in a routing registry because people tend to switch companies, retire, die, or otherwise change. To help with this problem, Level 3 uses "maintainer objects". A maintainer object exists for each company that is a customer of Level 3. Other objects are owned by maintainer objects. Each maintainer object defines a set of people, any of whom are allowed to modify objects that are owned by the maintainer object. Only Level 3 can add a new maintainer to the registry.

For example, the Level 3 routing registry contains a maintainer object for the FRGP that looks like this: 

mntner:      FRGP
descr:       AS14041/FRGP
admin-c:     Marla Meehl
tech-c:      Pete Siemsen
upd-to:      Pete Siemsen
mnt-nfy:     Pete Siemsen
auth:        MAIL-FROM Pete Siemsen
notify:      Pete Siemsen
mnt-by:      FRGP
changed:     Pete Siemsen 001116
source:      CW

To add a Level 3 route

Send an email to the Level 3 routing registry. You'll get a confirmation message back saying if it worked or not. The email should look like this (REMEMBER TO CHANGE THE DATE IN THE "changed" FIELD). Note that you have to use a mail program that generates a "From:" line that is "siemsen@ucar.edu" or the registry software won't accept the request. Mac Mail.app will do the right thing, the Unix "mail" program didn't for me as of 2007-12-20, either from my Mac or from netserver. Also note that you'll get a confirmation containing messages about an unknown object, yet at the bottom it'll say "New OK: [route] 204.9.102.0/23", and the request will work. The problom is that the Mail.app client inserts some bullshit in the message that the Level RR doesn't like. Someday I'll figure out how to make Mail.app stop doing that. 

	    To: rpsl@Level3.net
	    From: Pete Siemsen
	    Subject: add a route object

      route:   198.59.82.0/24
      descr:   University of Colorado at Boulder
      origin:  AS14041
      mnt-by:  FRGP
      changed: siemsen@ucar.edu 20010125
      source:  LEVEL3

To delete a Level 3 route

To delete an entry, copy it exactly from the "whois" query and add
delete: siemsen@ucar.edu reason
to the end. This will only work if all the lines (except the "delete" line) match the existing route object. It's a good idea to look up the route object as described in the How to show a route section above, and cut-and-paste.

To modify a Level 3 route

To change an existing entry, you have to create a new entry and then delete the old one.

To modify a Level 3 as-set

To modify an as-set, copy it exactly from the "whois" query and change the "members" field as needed. Here's how I added some ASes to the members of the as-set named AS-FRGP. Note that you have to use a mail program that generates a "From:" line that is "siemsen@ucar.edu" or the registry software won't accept the request. Mac Mail.app will do the right thing, the Unix "mail" program didn't for me as of 2007-12-20, either from my Mac or from netserver. 
as-set:        AS-FRGP
descr:         FRGP ASes
members:       AS104, AS194, AS2648, AS2902,
                AS12145, AS14041, AS16519,
                AS32920, AS36081, AS36704
admin-c:       MM3-LEVEL3
tech-c:        PS5-LEVEL3
notify:        siemsen@ucar.edu
mnt-by:        FRGP
changed:       siemsen@ucar.edu 20070505
source:        LEVEL3
.
$oryx

How Level 3 does routing registries

Level 3 runs a program called "filtergen" every night. It updates the import policy on every Level 3 router interface. The filtergen program makes its choices based on a customer configuration record.

The Level3 "Blocked Route Report"

As of 2006-06-14, Level 3 emails Pete Siemsen an automated weekly report titled "UCAR Blocked Route Report" that shows inconsistencies in the routes that the FRGP advertises to Level 3. The report describes problems that we probably need to fix. Here are some hints about how to interpret the report from Roy Alcala of Level3, the author of the program that generates the report.

"not registered"

In the section of the report headed Registration information for advertised routes not in registry-based policy:, there was this entry:

129.82.177.0/25 (origin AS14041) not registered !

Roy said there are 2 common reasons this happens: the FRGP advertises a route that isn't registered or the FRGP advertises a route that has an incorrect origin AS. First, I checked where we get the route and if we're advertising it to Level 3:

l3-gw-1>show ip route 129.82.177.0
Routing entry for 129.82.177.0/25
  Known via "bgp 14041", distance 200, metric 20, type internal
  Last update from 129.19.63.137 1w0d ago
  Routing Descriptor Blocks:
  * 129.19.63.137, from 192.43.217.142, 1w0d ago
      Route metric is 20, traffic share count is 1
      AS Hops 0
      MPLS label: none

l3-gw-1>

…which shows that UCD is advertising the route to the FRGP, and

l3-gw-1>show ip bgp neighbors 209.245.20.25 advertised-routes | include 129.82.177.0
*>i129.82.177.0/25 129.19.63.137       20    100      0 i
l3-gw-1>

…which shows that the FRGP is readvertising it to Level3.

Then I checked that the route is registered in the Level 3 routing registry:

okapi$ whois -h rr.level3.net 129.82.117.0

% RIPEdb(3.0.0a13) with ISI RPSL extensions

route: 129.82.64.0/18
descr: Colorado State University (CSU)
       Fort Collins, CO, USA
       http://www.colostate.edu/
origin: AS12145
mnt-by: FRGP
changed: siemsen@ucar.edu 20061031
source: LEVEL3

route: 129.82.0.0/16
descr: route update via web
origin: AS14041
mnt-by: MAINT-AS14041
changed: thomas.lutzenberger@wcg.com 20040903
source: WCGDB

route: 129.82.0.0/16
descr: Colorado State University
       Computer Center
       Fort Collins
       CO 80523, USA
origin: AS209
mnt-by: MAINT-QWEST
changed: cgarner@qwest.net 19990323
source: RADB


okapi$

This shows that the specific route is not registered in the Level 3 routing registry. I need to track it down and decide whether I need to register it.

"Origin AS mismatches"

In the section of the report headed Registration information for advertised routes not in registry-based policy: , if a prefix is listed, and its origin AS doesn't match the one shown that's registered in the Level3 routing registry, the problem is that we are advertising the route with the wrong origin AS.

"Proxy route objects"

In the section of the report headed Registration information for advertised routes not in registry-based policy:, there was this entry:

164.47.109.0/24 (origin AS16519)
[found 164.47.109.0/24 in LEVEL3::AS16519] ("proxy" route object)

The ("proxy" route object) means that Level3 has placed a proxy route object in the Level3 registry just to make Level3's advertisements to its peers consistent. You can see this directly with a command like

ibex$ whois -h rr.level3.net 164.47.109.0
[Querying rr.level3.net]
[rr.level3.net]

% RIPEdb(3.0.0a13) with ISI RPSL extensions

route: 164.47.109.0/24
descr: Proxy-registered route object
origin: AS16519
remarks: auto-generated route object
remarks: this next line gives the robot something to recognize
remarks: L'enfer, c'est les autres
remarks:
remarks: This route object is for a Level 3 customer route
remarks: which is being exported under this origin AS.
remarks:
remarks: This route object was created because no existing
remarks: route object with the same origin was found, and
remarks: since some Level 3 peers filter based on these objects
remarks: this route may be rejected if this object is not created.
remarks:
remarks: Please contact routing@Level3.net if you have any
remarks: questions regarding this object.
mnt-by: LEVEL3-MNT
changed: roy@Level3.net 20060421
source: LEVEL3
(etc.)
Address comments or questions about this Web page to the Network Engineering & Telecommunications Section at nets-www@ncar.ucar.edu. The NETS is part of the Computational & Information Systems Laboratory of the National Center for Atmospheric Research, which is sponsored by the National Science Foundation and managed by the University Corporation for Atmospheric Research. This website follows the UCAR General Privacy Policy and the NCAR/UCAR/UOP Terms of Use.