IRRs [was Re: OPS: BGP spew from ASN 7374]

Cengiz Alaettinoglu cengiz at isi.edu
Thu Apr 8 16:20:30 UTC 1999


Alex P. Rudnev (alex at Relcom.EU.net) on April 8:
> 
> > > 
> > > If common and consistent tools and rules were used to build filters from
> > > a SINGLE public database, and if the database site listed contact
> > > information and test addresses for each network using the database, I
> > > think folks could live with that.
> > 
> > Well if they could agree on a routing policy language, that would be a
> > fine start.
> Btw, RADB and RIPE problem is the fact this data bases was not designed 
> to build such lists. Try to extract PREFIX list for AS-DEMOS macro from 
> RIPE - it take you about 30 - 40 minutes and you should doing all 
> recursions yourself. Then try to build complex filter.
> 
> RADB abd RIPE are doing good work, but they should be improved to make 
> this _LIST EXTRACTION_ be easy operation (whois -h whois.ripe.net 
> PREFIX-LIST:AS-RELCOM+AS-DEMOS-AS2555 -> 1.2.3.4 255.255.255.0 ... EOF - 
> fast answer). And more and more people use this data bases.

It takes about 2 seconds using IRRd/RAToolSet combo. If you wanted
this in Cisco prefix format, you could use RtConfig or write a sed
script. 

[cat peval]$ time ./peval -h radb.ra.net -p 43 -protocol irrd AS-DEMOS
Warning: key not found error for query !gAS5566.

Warning: key not found error for query !gAS8268.

Warning: key not found error for query !gAS9113.

({212.92.128.0/18, 212.48.128.0/19, 212.46.0.0/19, 212.40.192.0/19,
212.19.0.0/19, 195.230.64.0/19, 195.209.192.0/19, 195.209.96.0/19,
195.209.112.0/20, 195.209.32.0/19, 195.170.32.0/19, 195.133.0.0/16,
195.112.96.0/19, 195.112.96.0/20, 195.112.112.0/20, 195.98.32.0/19,
195.42.160.0/19, 194.117.64.0/19, 194.87.0.0/16, 194.87.0.0/17,
194.87.128.0/17, 194.87.192.0/18, 194.87.192.0/19, 194.87.224.0/19,
194.87.0.0/18, 194.87.0.0/19, 194.85.224.0/20, 194.85.224.0/21,
194.85.232.0/21, 194.85.236.0/24, 194.85.237.0/24, 194.85.234.0/24,
194.85.235.0/24, 194.85.233.0/24, 194.85.228.0/24, 194.85.229.0/24,
194.85.230.0/24, 194.85.231.0/24, 194.85.226.0/24, 194.85.224.0/24,
194.85.225.0/24, 194.85.208.0/20, 194.85.216.0/24, 194.85.217.0/24,
194.85.218.0/24, 194.85.219.0/24, 194.85.220.0/24, 194.85.221.0/24,
194.85.222.0/24, 194.85.223.0/24, 194.85.219.0/27, 194.85.215.0/24,
194.85.212.0/24, 194.85.208.0/24, 194.85.209.0/24, 194.85.210.0/24,
194.85.211.0/24, 194.85.188.0/24, 194.85.184.0/24, 194.85.113.0/24,
194.85.11.0/24, 193.233.0.0/16, 193.233.224.0/22, 193.233.192.0/20,
193.233.208.0/20, 193.233.160.0/20, 193.233.144.0/22,
193.233.108.0/22, 193.233.80.0/21, 193.233.48.0/21, 193.232.230.0/23,
193.232.192.0/19, 193.232.223.0/24, 193.232.218.0/24,
193.232.219.0/24, 193.232.216.0/24, 193.232.214.0/24,
193.232.212.0/24, 193.232.213.0/24, 193.232.208.0/24,
193.232.209.0/24, 193.232.210.0/24, 193.232.211.0/24,
193.232.206.0/24, 193.232.207.0/24, 193.232.200.0/24,
193.232.201.0/24, 193.232.202.0/24, 193.232.203.0/24,
193.232.196.0/24, 193.232.197.0/24, 193.232.198.0/24,
193.232.199.0/24, 193.232.194.0/24, 193.232.195.0/24, 193.232.81.0/24,
193.232.0.0/19, 193.232.31.0/24, 193.232.28.0/24, 193.232.26.0/24,
193.232.24.0/24, 193.232.25.0/24, 193.232.16.0/24, 193.232.17.0/24,
193.232.18.0/24, 193.232.19.0/24, 193.232.20.0/24, 193.232.21.0/24,
193.232.22.0/24, 193.232.23.0/24, 193.232.0.0/24, 193.232.1.0/24,
193.232.2.0/24, 193.232.3.0/24, 193.232.4.0/24, 193.232.5.0/24,
193.232.6.0/24, 193.232.7.0/24, 193.232.8.0/24, 193.232.9.0/24,
193.232.10.0/24, 193.232.11.0/24, 193.232.12.0/24, 193.232.13.0/24,
193.232.14.0/24, 193.232.15.0/24, 193.124.171.0/24, 193.124.114.0/24,
193.124.3.0/24, 192.124.185.0/24, 192.124.182.0/23, 192.124.180.0/24,
192.124.176.0/24, 192.124.172.0/24, 192.124.173.0/24,
192.124.170.0/23, 192.124.171.0/24, 192.91.186.0/24, 159.93.0.0/16,
157.186.0.0/16, 147.45.0.0/16, 62.76.9.0/24}) 
0.06user 0.03system 0:02.27elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (356major+70minor)pagefaults 0swaps


> 
> And it's bad idea to have SINGLE data base. You have a chance to get new 
> INTERNIC -:).
> 
> 
> > 
> > -- 
> > Alex Bligh
> > GX Networks (formerly Xara Networks)
> > 
> > 
> > 
> > 
> 
> Aleksei Roudnev, Network Operations Center, Relcom, Moscow
> (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
> (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
> 


Cengiz

-- 
Cengiz Alaettinoglu           Information Sciences Institute
http://www.isi.edu/~cengiz    University of Southern California




More information about the NANOG mailing list