|
|
|
| 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 | |
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:
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 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:
- NCAR
- Main Organization record
- UCAR
- Organization record. This should be deleted in favor of the NCAR organization record, or vice versa.
- ABUSE18-ARIN
- NCAR abuse role POC, lists the NCAR NOC telephone number and an email address of abuse@ucar.edu
- NOC116-ARIN
- NCAR Network Operations Center role POC, lists the NCAR NOC telephone number and an email address of ne@ucar.edu
- ZN10-ARIN
- A role POC that lists the NCAR NOC telephone number and an email address of ne@ucar.edu
- EA8-ARIN
- Ed Arnold's individual POC
- GW74-ARIN
- Greg Woods's individual POC
- PS24-ARIN
- Pete Siemsen's individual POC. This is the administrative POC for NCAR.
- TH980-ARIN
- Tres Hofmeister's individual POC
- NET-128-116-0-0-1
- NET-128-117-0-0-1
- NET-192-43-244-0-1
- NET-192-52-106-0-1
- NET-208-167-104-128-1
- ABILENE-UC-V6
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.
whois -h whois.arin.net ?
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.
For purposes of authorization, an organization should define the following POCs:
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.
The technical POC is authorized to make the following 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.
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.
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.
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.
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
$ 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
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.
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.
From: RADb Support
Date: June 5, 2009 8:55:21 AM MDT
To: siemsen@ucar.edu
Subject: RADb maintainer account
mntner: MAINT-AS14041 descr: Univeristy Corporation for Atmospheric Research admin-c: Marla Meehl tech-c: Pete Siemsen upd-to: frgp-eng@ucar.edu mnt-nfy: frgp-eng@ucar.edu auth: *********************** mnt-by: MAINT-AS14041 changed: siemsen@ucar.edu 20090604 #16:10:01Z source: RADBYour RADb maintainer account (MAINT-AS14041) has been created.
You may now log into our new RADb web portal to review and control your RADb account and IRR objects.
Your bill for the annual fee may be viewed and paid online in the RADb web portal.
Your organization may have one or more accounts. Currently you are the only Admin for your organization. This means that currently you are the only person who may log into the RADb portal. You must use your email address to create your password and to log in. You may begin the process here: https://www.radb.net/members/
Please refer to the following link for help on registering initial route and aut-num objects: http://www.radb.net/register.html
Questions? Email us at radb-support@merit.edu
Regards,
--RADb SupportMerit Network, Inc.
1000 Oakbrook Drive, Suite 200
Ann Arbor, MI 48104-6794
United States
On-line documentation of the RADb starts at Tutorials: How to Register Objects in the RADB
Web to http://www.radb.net/login. Log in.
whois -h whois.radb.net siemsen
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.
Here are some examples:
$ 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
$ 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
$ 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
$ 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: WCGDBThis shows one AS object describing AS 14041.
$ 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 Number | Who |
|---|---|
| 104 | CU |
| 194 | NCAR |
| 210 | UEN |
| 2648 | NIST/Dept. of Commerce (NOAA) |
| 2902 | UW |
| 7872 | USAP |
| 12145 | CSU |
| 13555 | CBOCES |
| 14041 | FRGP |
| 15295 | UNC |
| 16519 | UCDHSC |
| 17294 | CARL |
| 18815 | City and County of Denver |
| 25825 | Poudre Valley Hospital |
| 23458 | Denver Health and Hospital Authority |
| 31991 | Platte River Power Authority |
| 32920 | Ithaka |
| 36081 | State of Colorado General Government Computer |
| 36691 | CSU-Pueblo |
| 36704 | Colorado School of Mines |
| 39990 | Boulder County Government |
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
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: 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
delete: siemsen@ucar.edu reason
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
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.
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.
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.
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.
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.)