IRRd-Discuss

[Gerald Andrew Winters]

Hello Jens-S.,

First let me summarize your question.  You are wondering
why whois.radb.net (ie, merit) returns the route 145.253.0.0/16
as belonging to AS1275 from a whois query.  Additionally, the
AS1275 NOC say's they do not own the route.  Since you feel
this is incorrect information you are wondering why we would
maintain a DB with incorrect information.

There are really two issues here.  The first issue is does
the current specifications allow for a situation like this
or is this a violation?  The second issue is a
practical issue which we should check for an error in the software
or some other practical cause for this problem.

Regarding the first issue of whether the current spec allows
for this occurence the answer is yes.  Unfortunately, once a maintainer
is registered in the DB users can register just about anything they
want to, although there are some limits.  But in this particular case
there is no checking done to veryify that an AS owns a route block.
This situation is further complicated by the fact that there are many
real life situations such as dual-homing that make the data look bad
but it may not really be bad.

So the answer is yes, the current specification does allow for situations
like this to occur.  The current spec relies on users to put good data
into the registries and the registry administrators do not have the power
to make unilateral corrections. [NOTE: the newer spec rps-auth would
not allow this sitution and specifically addresses db fraud/inconsistency.
rps-auth is expected to be implemented some time next year.]

Regarding the question of whether there is a bug in the software, here
are the facts.  Merit imports the cw/mci db once every 24 hours from
the CW ftp site.  If you go to ftp.cw.net:pub/rr and get the cw.db you
will see 145.253.0.0/16 AS1275 in it.  So whatever CW puts in their DB
is what you see on our server.  And since I have nothing to do with
the the CW database I must refer you to Rikki Nguyen who may be able
to help you.  I have cc'd him on the conversation.

Finally, let me show you some interesting results:

% whois -h whois.cw.net 145.253.0.0/16
No entries found for selected source(s)

% whois -h whois.cw.net 208.164.233.0
route:       208.164.233.0/24
descr:       MCI-STATIC-ROUTE
origin:      AS3561
mnt-by:      CW
changed:     bprater@mci.net 980422
source:      CW

% whois -h whois.ripe.net -smci 145.253.0.0/16

% Rights restricted by copyright. See http://www.ripe.net/db/dbcopyright.html

% No entries found for the selected source(s).


me% whois -h whois.ripe.net -smci 145.253.0.0/16

% Rights restricted by copyright. See http://www.ripe.net/db/dbcopyright.html

% No entries found for the selected source(s).

The preceding shows that CW does not export 145.253.0.0/16 from it's server
and implies that RIPE does not import any routes at all from CW.  So if
RIPE were to import the CW db you would also see 145.253.0.0/16 AS1275
on their server.  So let me ask the following questions to my good friends.

Rikki Nguyen:
Why are you exporting 145.253.0.0/16 AS1275 in your ftp area yet your
whois server does not show this route (is the ftp area data stale?)?

Joao:
It looks as though you do not import CW/MCI data, is this true?

--jerry




> 
> Hi,
> 
> I am using a local irrd to mirror the RA provided databases:
> 
>    IRRd> show database
>    Listening on port 43 (fd=18)
>    Memory-only indexing
>    RIPE181 Syntax
> 
>    Database    Size (kb)    Rt Obj   AutNum Obj   Serial #
>    ---------    --------     ------   ---------   ---------
>     ans            4964.4      10561       26        37592
>     canet          1095.5       9629       59        0
>     mci            7516.6      47656      562        0
>     radb          12948.8      55031     1994        75127
>     ripe           5939.2      21165     2612        6530703
> 
>    ans
>       Mirroring 198.108.0.11:43 (Next in 21:40:30)
>       Never mirrored
>       Next dbclean in 45:15:57
>    canet
>       Last loaded 04:32:20 10/21/99
>    mci
>       Last loaded 04:32:23 10/21/99
>    radb
>       Mirroring 198.108.0.11:43 (Next in 21:40:28)
>       Never mirrored
>       Next dbclean in 44:31:52
>    ripe
>       Mirroring 198.108.0.11:43 (Next in 21:39:47)
>       Never mirrored
>       Next dbclean in 45:13:46
> 
> Since my Squid web cache software uses AS based ACLs and request routing,
> I rely on the correct information in the databases. Strangely enough,
> there seems to be a mixup concerning 145.253.0.0/16..18. Squid reports
> (verified by querying RA):
> 
> > ]> 
> > ]>     145.253.0.0/18       3211
> > ]>     145.253.0.0/16       1275
> 
> The AS1275 NOC claims that 145.253.0.0/16 does not belong to AS1275. RIPE
> does report the network correctly to belong to AS3211. But when querying
> RA (and my local mirror), it also claims that CW says the network belongs
> to AS1275, even though it falls into the RIPE domain:
> 
>    $ whois -h whois.ripe.net 145.253.67.0
>    [...]
>    route:       145.253.0.0/16
>    descr:       ARCOR-IP
>    origin:      AS3209
>    [...]
> 
>    $ whois -h whois.ripe.net 145.253.0.0
>    [...]
>    route:       145.253.0.0/18
>    descr:       ARCOR-IP
>    origin:      AS3211
>    [...]
> 
>    $ whois -h whois.ra.net. 145.253.0.0
>    [...]
>    route:          145.253.0.0/18
>    descr:          ARCOR-IP
>    origin:         AS3211
>    notify:         markus.hies@arcor.net
>    mnt-by:         ARCOR-MNT
>    changed:        markus.hies@ripe.net 19980806
>    changed:        markus.hies@arcor.net 19981013
>    source:         RIPE
> 
>    route:          145.253.0.0/16
>    descr:          ARCOR-IP
>    origin:         AS1275  <-- this is the start of wrong information
>    mnt-by:         DFN-MNT
>    changed:        poldi@dfn.de 980422
>    source:         CW
> 
> Who does resolve such inconsistencies?
> 
> Yours
> Dipl.-Ing. Jens-S. Vöckler (voeckler@rvs.uni-hannover.de)
> Institute for Computer Networks and Distributed Systems
> University of Hanover, Germany; +49 511 762 4726
> 
> 
> 
>