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

Mailman List Mirror (Read Only)
1

> * Several people still peer via the route servers
> * Several transits filter their customers by RADB or a private RADB
> which feeds the IRR.

Care to name names?

route servers: see http://www.rsng.net/ for a list

Transits - I did a survey on NANOG a few months ago as to who filtered
and how (both peers and customers). About 50% of those who replied
used RADB or another similar database (possibly their own, like
CA*NET, MCI/CW, Level3 etc.) for filtering either peers or customers.
However, I suspect this number is heavilly skewed in favour of vocal
NANOG people who like IRRs. Filtering customers was way more prevalent
than filtering peers.

I said I'd repost the stuff anonymously, but some contributors often
post here and thus may chose to answer your question on or off list.

Connectivity failures can and do result when RADB records are not
properly updated, which does happen from time to time. They also
happened when records WERE properly updated, but the changes made were
deemed "too radical" by the software translating the RADB entries into
internal databases. Moving a portable prefix from one ASN to another
qualified as "too radical" a change, despite it being a semi common
occurrence.

And various people had different solutions to this, the most common
being a sort of 2 of 3 approach (RADB change, plus sanity algorithm,
plus sanity person).

> If you do either of the above, chaning a public IRR (once) is easier
> than changing n private databases. The alternative is no filtering.
> Hopefully natural selection will take its course on transits who
> do this on a regular basis.

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.

2

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

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)

3

"Alex P. Rudnev" wrote:

[snip]

And it's bad idea to have SINGLE data base. You have a chance to get new
INTERNIC -:).

That's certainly an issue... I would settle for a few databases,
especially if there was a definitive list of who did filtering
(especially filtering outside of their own customers) and valid contact
info AND test addresses for each. I'd still like a methodical, reliable
way to test a new ASN once brought online. Today one activates and then
spends a few weeks waiting for users to find landmines.

4

Alex P. Rudnev (alex@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