I'm also in the externally managed space...very cool tool though. I love the idea of distributing some of this functionality. Are you also exporting and managing this data outside? On Tue, Aug 17, 2021 at 12:23 PM Ben Maddison via NANOG <nanog@nanog.org> wrote:
Hi Saku,
On 08/17, Saku Ytti wrote:
I share your confusion Randy. It seems like perhaps Jakob answered a slightly different question and his answer is roughly.
a) Use this as-set feature to ensure valid set of ASNs from given peer b) Validate prefix using RPKI (I'm assuming with rejecting unknowns and invalids) c) Don't punch in prefix-lists anywhere
Which in theory works, but in practice it does not, as RPKI validity cover is incomplete.
This, and (more fundamentally) RPKI-breakage gets translated into a dataplane outage.
Somewhat related, when JNPR implemented RTR the architecture was planned so that the RTR implementation itself isn't tightly coupled to RPKI validity. It was planned day1 that customers could have multiple RTR setups feeding prefixes and the NOS side could use these for other purposes too. So technically JNPR is mostly missing CLI work to allow you to feed prefix-lists dynamically over RTR, instead of punching them in vendor-specific way in config.
We already do essentially this on arista EOS using a custom agent.
It runs under the EOS process supervisor and calls home to a REST-API wrapper around bgpq3. It looks for specific config lines to work out which prefix lists to build, and then fetches them on a configurable interval.
This has been in production for a year or two, without major incident. It's all open source, available at https://github.com/wolcomm/eos-prefix-list-agent. Pull-requests <https://github.com/wolcomm/eos-prefix-list-agent.Pull-requests> welcomed ;-)
I'm in the middle of writing the equivalent tool for junos at the moment. Assuming that it works, we'll open source that too.
HTH,
Ben