BGP customers of Level3 (AS3356) would do well to learn the intricacies of their filtergen system. Level3 uses filtergen to build route filters toward customer BGP sessions. You can accidentally affect what traffic gets exchanged over your AS3356 transit if you don’t manager your IRR records carefully.

Many other large networks operate their own customer-centric IRR’s too. However, I always recommend going with a 3rd party IRR. While Level3 customers are free to register their objects in Level3’s IRR, they may also use the IRR of their choice. RADB, RIPE, and ARIN are popular choices (The free ALTDB isn’t very well maintained anymore).

By default, Level 3 builds filters based on entries in their own LEVEL3 IRR. However, power-user customers don’t necessarily want to register all their objects in LEVEL3’s IRR (or worse yet – have Level3 proxy-register objects for them). If you wish for Level3 to use your records from another IRR (such as RIPE, RADB or ARIN), you can specify that. You need to let Level3 know. But you can also test the results yourself, using Level3’s WHOIS inteface.

i.e. the following queries can all produce different results (except for the the first two — which are the same thing).

whois -h filtergen.level3.net AS20205
whois -h filtergen.level3.net LEVEL3::AS20205
whois -h filtergen.level3.net RADB::AS20205
whois -h filtergen.level3.net ARIN::AS20205
whois -h filtergen.level3.net ALTDB::AS20205

By default, you will only get IPv4 results. If you want IPv6, you have to specify as follows:

whois -h filtergen.level3.net "AS20205 -v6"
whois -h filtergen.level3.net "RADB::AS20205 -v6"

I prefer using an AS-SET to group my own AS’s prefixes, plus all customer AS prefixes together. However, that gets tricky if I use a different IRR than my customers use. For example, if tell Level3 to use an AS-SET of ARIN::AS-AMPLEX, but a customer within AS-AMPLEX (say AS65000) uses RADB, then Level3’s filtergen may miss AS65000’s objects. AS65000 could re-register their objects in ARIN – but that is not a practical workaround.

Rather, I can use “remark” comments in the AS-AMPLEX AS-SET object to direct Level3 to the proper source of member objects.

i.e.

as-set: AS-AMPLEX
descr: Amplex Transit Customers
members: AS20205
members: AS65000
remarks: Level3 members: ARIN::AS20205
remarks: Level3 members: RADB::AS65000

You can achieve similar results with specialized filtergen queries, where you specify which IRR’s to fetch objects from — but it’s not as granular as using remarks in the AS-SET object.

i.e.

whois -h filtergen.level3.net "ARIN::AS-AMPLEX -searchpath=ARIN;RADB -recurseok -warnonly"

Besides Level3’s filtergen whois interface, Dan Austin and NLNOG have useful resources for troubleshooting IRR entries.