IRRd-Discuss

[Gerald Andrew Winters]

Jacques,

Thanks for the bug report and indeed it is a bug of 
some kind with the indexing.  I am working on it and
will report back to you.

--jerry

> 
> Hi,
> 
> I'm setting up tools to perform prefix- and as-path-based filtering from 
> our peers using the RADB. Before installing the filters generated by the 
> tools onto our routers, I wanted to check that we wouldn't be losing too 
> many routes for some reason (routes not registered...).
> 
> I came up with strange results... The very first prefix present in routing 
> tables and not in my filters that I found was 198.80.113.0/24. So I checked 
> the databases, and found that the output of !g queries is not complete...
> 
> There is a route object for this prefix:
> 
> route:         198.80.113.0/24
> descr:         Andrew Hougie
>                 28 Hillfield Road
>                 West Hampsteead, London NW6 1QE
> origin:        AS1670
> withdrawn:     19980213
> member-of:     RS-COMM_ANS_CORE
> mnt-by:        ANS
> changed:       mds@ans.net 19980213
> source:        ANS
> 
> It does appear in RIPE inverse lookup queries:
> 
> (ops-dev.psi.com)$ whois -h whois.ripe.net " -a -i origin AS1670" | grep 
> route: | grep 198.80.113.0
> route:       198.80.113.0/24
> 
> But it does not appear in !gas1670:
> 
> (ops-dev.psi.com)$ whois -h whois-rpsl.radb.net '!gas1670'
> A1565
>   204.149.66.0/24 152.181.240.0/22 152.181.168.0/22 152.181.248.0/22 
> 152.189.240.0/22 152.189.248.0/22 152.189.168.0/22 207.24.25.0/24 
> 152.178.24.0/21 152.186.24.0/21 152.182.248.0/21 152.190.248.0/21 
> 204.151.108.24/29 204.151.108.16/29 204.151.109.0/24 207.24.30.0/24 
> 198.80.115.0/24 207.24.31.0/24 147.225.71.0/24 152.181.172.0/22 
> 152.189.172.0/22 152.181.244.0/22 152.189.244.0/22 152.182.224.0/22 
> 152.190.224.0/22 152.182.228.0/22 152.190.228.0/22 152.181.252.0/22 
> 152.189.252.0/22 152.182.244.0/22 152.190.244.0/22 152.182.216.0/22 
> 152.190.216.0/22 152.182.220.0/22 152.190.220.0/22 198.80.112.0/24 
> 152.186.112.0/21 198.80.112.0/20 204.150.190.0/25 204.150.219.0/25 
> 204.148.112.0/21 152.198.0.0/16 195.99.158.0/24 207.24.28.0/24 
> 204.150.67.0/25 204.150.67.128/25 204.150.181.0/25 204.150.181.0/27 
> 204.150.181.16/28 204.150.181.32/27 204.150.181.128/25 204.150.190.128/25 
> 204.150.191.0/25 204.150.191.128/25 204.150.219.128/25 204.150.220.0/25 
> 204.150.220.128/25 204.150.222.128/25 204.150.223.0/25 204.150.223.128/25 
> 152.212.208.0/21 152.212.124.0/22 204.150.67.0/24 204.150.190.0/24 
> 204.150.191.0/24 204.150.220.0/24 204.150.222.0/24 204.150.223.0/24 
> 207.24.26.0/24 207.24.27.0/24 207.24.112.0/24 204.150.219.0/24 
> 204.150.181.0/24 195.93.128.0/25 195.93.128.128/25 195.93.129.0/25 
> 195.93.129.128/25 195.93.130.0/26 195.93.130.64/26 195.93.160.0/22 
> 195.93.164.0/22 195.93.168.0/22 195.93.172.0/22 195.93.176.0/22 
> 195.93.180.0/22 195.93.184.0/22 195.93.188.0/22 195.93.192.0/24 
> 152.182.240.0/22 152.211.96.0/19 152.189.242.0/23 152.189.240.0/23 
> 204.151.167.0/24
> C
> 
> So, I'm puzzled... Does !g "aggregate" prefixes, by hiding smaller prefixes 
> that are inside larger ones, for instance? That would explain such a 
> problem (there is a route for 198.80.112.0/20). But it apparently is not 
> the case (there is a route for 198.80.112.0/24 also), and I don't see 
> anything to that effect in the source...
> 
> Any insights? Maybe the database indexes are corrupted?
> 
> (I have 4000 more to check once this one issue is fixed...).
> 
> Jacques.
> 
> --- Jacques Caron
>      PSInetworks Europe Network Engineer
>      Planete.net IT Manager
>      Mail:   8/10 rue Nieuport - 78140 Velizy - France
>      Phone:  +33 (0)1 34 63 19 71 - Fax: +33 (0)1 34 63 19 51
> 
>