Re: Who uses RADB/IRR?

[Daniel Senie <dts () senie com>]

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