[sdnog] Can not get the real ASNs using traceroute -a

[Nishal Goburdhan]

On 24 Sep 2020, at 17:07, Willy Manga wrote:
> On 24/09/2020 18:06, Sara Alamin wrote:
>> [...]
>> this correct,  but on RADB as Patrick showed us,  we don't get the 
>> same answer. so aren't these databases syncing from each other? and 
>> as Nishal's said this is always CANAR prefix , so how come RADB 
>> accept different origins for the same prefix.
>
> Each registry has its own rules :)

you statement is correct, but it’s not the answer to her question.
it is *OK* to have the same object with multiple origin-as.  it’s a 
feature;  not a bug.

imagine if you had your prefix (P) and you used AS1 as your transit 
provider.
if you were planning to move to AS2, and you were smart, you would 
register the same object, with AS2, as the origin-as *before* you moved. 
  that would allow operators around the world, to change their BGP 
filters *in advance of the change*.   later, when you had moved to AS2, 
you would then go back and delete the old object, because it was no 
longer valid.   right?  :-)

when you look at the IRR, always pay special attention to the 
“SOURCE:” field.  in this case, the “source:     RADB: tells you 
that these objects are registered directly into the RADB.  registering 
information in the RADB is easy;  you pay the annual fee, and you 
register whatever you want.  there are really no checks;  and, the thing 
is, because the RADB was considered a “global” database, it’s 
really difficult to make 100% accurate checks.  afrinic tried this when 
they initially launched their database (they meant well) but very soon 
found out that the internet is more than the sum of the prefixes that 
are in one database.  i’ll write more below ..


> My humble advice here is:
> - for each Internet number resource you have received an
> allocation/assignement, register your objects in the database of the
> respective Regional Internet Registry

NO!  THIS IS HORRIBLE ADVICE!   if you are a netop, please do *NOT* do 
this.


> - then if you really need to register in another registry, go ahead
> - AND KEEP ALL YOUR OBJECTS ACCURATE IN ALL REGISTRY

NO, THIS IS HORRIBLE ADVICE!

pick a *single* registry, and register all your objects there.  that way 
it is a lot easier to keep your objects accurate.  unfortunately, the IP 
monopolists, er….RIRs, operate registries that limit registration of 
objects, to only those that they lease to you.  if you’re in this 
situation, then, simply use a registry like the RADB, which does not 
have these restrictions.  there’s a small fee, but it’s not a crazy 
amount for a business to cover.

there’s a better reason for using just one registry.  let’s assume 
your AS-SET is AS-NET1, and that you register all your objects with 
IRR1, and that you have a controlfreak in your organisation that keeps 
this always in sync.  and today, that is six (6) objects.  good.

now, let’s say you you try to register different objects in IRR2, and 
you accidentally forget one.  so the total number of objects that you 
register in IRR2, is five (5).

you have no way of knowing how a third party that is using tools to 
automatically build network filters for you, is going to process this 
information.  will they use IRR1?   will they use IRR2?  will they use 
both?  what happens to objects that are missing - do they get 
overwritten (eg.  a filter list of 6 objects is created from IRR1, but 
then, overwritten by a filter list of 5 objects from IRR2 …)
and the problem only gets worse if you try to add in *more* IRR 
databases.  and wait until you find out how operators misuse the 
“SOURCE” field to make filters.  wooroorook!!!

please.  as someone who has spent a fair amount of time teaching 
networks how to use IRR tools, please, just use one IRR source.  specify 
this in peeringdb  (like  RADB::AS-PCH).  and keep your life, and the 
life of the netops around you, simple!  if you are not going to be a 
transit ASN, and have just a few objects (eg, you are an business that 
just wants to multihome) then use the afrinic irr.  if you’re planning 
to be a large transit provider, and have clients and resources from 
wonderful places, it’ll be easier for you to use the RADB.

a word of caution;  since sudan is in north africa, and back when IP 
resources for africa was colonis^W managed by three other external RIRs, 
sudan fell into the RIPE-NCC region.  so there are old networks, that 
likely still have this in place.  some time ago, the RIPE-NCC community 
stopped the registration of new objects into their IRR for non-RIPE 
members.  and whilst this won’t affect your already registered 
objects, it means that you won’t be able to add new ones.  if you fit 
into this category, consider either moving to the afrinic, or RADB 
registries.

if you’re interested in the IRR, a really good tool to help you 
navigate is:  http://irrexplorer.nlnog.net


>> according to RPKI stats, We have only one ISP,  MAXNET (AS37211 ) has 
>> generated ROA for their prefixes. I hope others do it soon.
>
> SUDATEL (AS15706) as well. They created their ROA during the first
> AFRINIC e-deployathon at least for their v6 prefix :2001:4228::/32 
> [1].
>
> 1. I did not recall why they did not add their v4 prefix in the same
> certificate. But it should be straightforward.

probably to make sure that their v6 prefix did not mysteriously vanish 
off the internet  (ie. ROA concerns).  we have already seen system 
failures at RIRs where this has happened before.  but perhaps, now that 
they know that even the failure mode is generally safe, maybe we’ll 
see more.  ISA.

-n.