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 >
