[22792] in North American Network Operators' Group
Re: Who uses RADB/IRR?
daemon@ATHENA.MIT.EDU (batz)
Sun Jan 24 06:23:43 1999
Date: Sun, 24 Jan 1999 05:20:55 -0500 (EST)
From: batz <batsy@vapour.net>
Reply-To: batz <batsy@vapour.net>
To: Dean Anderson <dean@av8.com>
cc: Daniel Senie <dts@senie.com>, nanog@merit.edu
In-Reply-To: <3.0.32.19990122180559.00a85fd8@odie.av8.com>
On Fri, 22 Jan 1999, Dean Anderson wrote:
:I started looking at the RADB, but haven't got ourselves setup yet. Does
:anyone actually deny routes which aren't listed in the RADB?
Depends on what you mean by deny. If you are generating access-lists
from RAdb entries, obviously you will only be accepting those routes.
Unless you were doing as_path based filtering, you are implicitly
filtering those other routes. Manually adding unregistered routes would
alleviate this problem until you had convinced them it was in their
interest to register.
I guess what
:I'm really asking is how important is it to be in the RADB? Does it get
:more important sometime soon?
It's not like you won't be able to peer with anyone after a certain
date, but there are important reasons to register.
-If you are multihomed, your upstreams will have synchronized access-lists
allowing you more control over the shape of your traffic.
-Convenient automated, synchronized and *authenticated* updates to your peers.
-Portable central source for customer and local routing information.
-Making IPMA/Merit/CAIDA projects more accurate.
Am I correct in thinking that ANS and CAnet both require registration
of their customers routes?
:I would also tend to think [based on limited BGP knowledge] that it would
:only be a problem if your direct upstream used the RADB or if your upstream
:is RADB filtered by their peers. Is this true?
I'm sure that a site that used RtConfig for generating access-lists
would only do so for customers that had assured the site that their
registrations were current and worthy of production. Otherwise,
routes are added manually.
-j
--
jamie.reid
Chief Reverse Engineer
Superficial Intelligence Research Division
Defective Technologies
