IRRd-Discuss

[Jens-S. Voeckler]

On Thu, 21 Oct 1999, Gerald Andrew Winters wrote:

First let me thank you for your detailled information, and efforts into
helping me to a wider scaled understanding. 

]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.

The AS1275 NOC (noc@noc.dfn.de) just told me this morning (CET) that they
deleted the historical entry from MCI after my inquiry.

]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.]

This sounds good.

]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.

And I mirror it from you every 24 hours :-)

]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.

Thank you very much. 

]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)

That is as it should be.

]% 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?

I fear I launched an avalanche here. As I said, about six hours ago, after
receiving a query from me on this issue, the DFN (AS1275) NOC send a delete
message to the CW/MCI for (all) their networks formerly registered there
for some obscure, archaic and historical reasons. They claimed that in "old
times", networks had to be registered both, with RIPE and MCI. Since it
seems to be cleared up by now, and due to the fresh deletes, I would expect
the CW/MCI server to provide fresher data than the mirror.

Many thanks again to all people involved for their fast reaction in solving
this issue. In less than 12 hours I expect that my mirror will to be up to
date, too.

]--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?

Le deagh dhùrachd,
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