Hi Håvard, Routinator will only start serving verified data to the various endpoints once it has validated the entire published RPKI data set.
Here’s what’s happening on the repository side: The ARIN region --------------- In the Hosted RPKI services of most RIRs you specify which routes are authorised and ROAs are created and renewed accordingly. This means objects are created as efficiently as possible and there are no duplicates at any time. This is different in the ARIN region, where you have direct control over the cryptographic objects that are created, including the start and end validity date. It will also happily let you create overlapping ROA objects that result in the same Validated ROA Payload (VRP). I believe Amazon in particular creates short lived ROAs through the ARIN API. They create an overlapping set in bulk some time before the current set expires. This results in as much as 4000 duplicate VRPs in the ARIN repository at any point in time. Routinator filters out duplicates, so while the VRP set that is served to your routers remains pretty stable, there’s indeed a lot happening on the crypto side compared to the other RIRs. The Brazilian region -------------------- NIC.br, the Brazilian NIR, does not offer Hosted RPKI to their members. Everyone runs a Delegated CA on their own systems. However, they publish the objects they generate in a repository hosted by their parent NIR. So while Brazilian ISPs don’t have to worry about the publication of their RPKI objects to the world, they do have to make sure that their CA software resigns them every 24 hours. Out of the ~1450 CAs, it is more or less expected that a handful are broken at any moment in time for reasons you can imagine. This results in the stale or expired objects you’re seeing. NIC.br is pretty good at monitoring and chasing this though. Hope this clarifies things! Cheers, Alex > On 25 Jun 2022, at 23:27, Havard Eidnes via RPKI <[email protected]> > wrote: > >> There is a lot to learn about these systems and what is typical behavior >> and what is not normal. > > Indeed. > > In my newly started routinator instance I see a lot of log > messages saying "No valid manifest found." Following your hint > for looking at the status of the running server, I find for the > "tals": > > curl "http://127.0.0.1:9556/api/v1/status"; | egrep '(Manifest|^ ")' | > grep -v 0, | less > "afrinic": { > "validManifests": 546, > "missingManifests": 1, > "apnic": { > "validManifests": 6789, > "arin": { > "validManifests": 227, > "missingManifests": 408, > "lacnic": { > "validManifests": 3192, > "ripe": { > "validManifests": 1, > "missingManifests": 1, > ... > > What's the issue with the lots of missing manifests from the arin > region? More than the number of valid manifests? That cannot be > good? Is that a sign of garbage not being collected at the > remote site? > > And these are not the only ones (these are "repositories"): > > "https://rpki-repo.registro.br/rrdp/notification.xml": { > "validManifests": 1422, > "missingManifests": 28, > > Is this a sign that my routinator hasn't yet synced itself, or is > it an indication of something amiss at the repository side? > > Regards, > > - Håvard > -- > RPKI mailing list > [email protected] > https://lists.nlnetlabs.nl/mailman/listinfo/rpki -- RPKI mailing list [email protected] https://lists.nlnetlabs.nl/mailman/listinfo/rpki
