IRRd-Discuss

[Jacques Caron]

Hi again,

There is no bug here in fact... I hadn't seen the "withdrawn" attribute, 
which is interpreted correctly by IRRd, which works perfectly fine. The 
problem is then with the maintainer, as this route is not in the DB, but is 
present in "real-life" routing tables.

Sorry about that. Looks like I have 4000+ DB/real-life mismatches, then 
(and that's only for EU peers). Maybe not a good idea to filter that out in 
a single stroke :-(

Jacques.

At 02:53 18/11/99 , Gerald Andrew Winters wrote:
> 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
> >
> >
--- 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