Pierre Thibaudeau wrote:
On Tue, 26 Jan 1999, Daniel Senie wrote:
Date: Tue, 26 Jan 1999 09:18:27 -0500 From: Daniel Senie <dts@senie.com> To: nanog@merit.edu Cc: briand@spare.de.teleglobe.net Subject: Re: Who uses RADB/IRR?
--------------------------------------------------------------------------------
briand@spare.de.teleglobe.net wrote:
DA> I started looking at the RADB, but haven't got ourselves setup yet. Does DA> anyone actually deny routes which aren't listed in the RADB? I guess what DA> I'm really asking is how important is it to be in the RADB? Does it get DA> more important sometime soon?
Yes, for peers and customers. Pretty important, at least for international connectivity (which is what we provide). Yes. (See below.)
You present several good points for requiring peers to register. Not all networks require their peers or customers to be in the RADB, as not all networks use the RADB or other databases.
Interesting problems arise when route filtering is applied by at least some RADB users.
ANS.NET, for example, does not (at least in some cases) accept data from the RADB when a prefix is moved from one AS to another. A move in AS might occur when a portable prefix is shifted to a new ISP, or when a portable prefix aquires its own AS and goes multi-homed. When this type of change happens and ANS doesn't pick it up, the prefix which was moved loses access to sites attached to ANS.
So, why is this a problem? The prefixes in question are not ANS customers, nor are they peers of ANS customers. How does one find out there's a lack of routing ability to ANS? Well, cnn.com doesn't work, and a few other sites. This is a BAD way to find out.
What's needed is a clean way to examine the policy databases of RADB (and other database) users to verify whether a network is being properly routed. If your policy says to only accept a particular prefix as coming from a particular AS, then the owner of the prefix needs to be able to query your database to find out that you have that policy in place.
Presently there is no list of routing policy database users, and no way to query the databases of those providers (at least that I've seen any
Daniel,
"Those providers" (to my knowledge, ALL those who build such filters) rely on publicly available data to build their access-lists. Although it's not possible to examine each carrier's filters, there is a simple way to examine the database that is at the source of these filters. i.e.:
alpha 58: whois -h radb.ra.net 204.69.207.0/24 route: 204.69.207.0/24 descr: Daniel Senie Consulting descr: 324 Still River Road descr: Bolton descr: MA 01740, USA descr: @Work Internet origin: AS6172 notify: routing@home.net notify: noc@home.net mnt-by: MAINT-AS6172 changed: fath@corp.home.net 981104 source: RADB
With this, you can be sure that those carriers who filter will permit the 204.69.207.0/24 if it is originated in AS6172; be it an immediate peer of HomeNet or a distant one like ANS.
Yes, this info is all well understood. It just DOES NOT happen that way. I had first hand experience of it not happening, and have talked with others who similarly have had experience with it not happening. I wanted to examine ANS's tables and policies directly because they did NOT pick up the RADB changes automatically. For whatever reason, a manual change was required at ANS. That case is history and the problem was solved after several days of phone calls. The bigger issue is ensuring such problems do not occur in other cases.
public info on). So, making any changes to the routing of a prefix is treacherous. I advise clients with portable address space that when they're switching providers or multi-homing, there may be loss of connectivity to some locations for a week or more (while database changes propagate) and some sites may be cut off entirely until the other site's ISP is contacted.
It is the responsibility of the admin of the Autonomous System that will eventually advertise a given network to register an appropriate route object for it.
Because some may forget or otherwise neglect this task, here is my advice: before moving from one provider to another, make sure that your new provider have done his homework. If you see a route-object with a "origin:" field containing your provider's ASN, you're in business. No need to fear: the RADB/IRR works fine with multiple route objects with different "origin:" (technically, the key for these records in the RADB/IRR system is the concatenation of the "route:" and "origin:" fields). So if your new provider registers a route object ahead of time (and this is what they should do), you will not loose connectivity through your current provider. After the switchover, it is your former provider's responsibility to delete the obsolete route object.
The cases I more commonly work on involve sites with portable address space going to multi-homing. Here, my client is actually the owner of the ASN. We're running BGP with full tables to multiple upstreams, where a single upstream and no BGP existed before. The RADB data goes in quite a while ahead, since we're in control of the AS. Based on previous experience and that of other folks, I still have very little confidence that the routes will be picked up properly by all database users. The only way we can be sure the routes are there, is to schedule downtime, cut all links but one, and see what's reachable. This is a terrible way to do such testing. I'd like to see something better and less disruptive. Since there appears no other way, I have such a test scheduled for tomorrow night with one of my clients. This client does multi-homing for redundancy and load balancing. The redundancy part is useless if there are any database interpretation problems. Perhaps now you'll understand why I really want to see a list somewhere (eg. on the RADB pages) that list all providers using the databases, and a place on each provider's network where the tables can be examined for a set of prefixes. Yes, it SHOULD all just work. No, it doesn't ALWAYS just work. When things don't work, there needs to be a way to find out where things are broken and why. Finding out by having someone notice a week later that some site they need to access is unreachable is NOT acceptable. Dan -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com