"Tactical" /24 announcements

Thu Aug 19 00:05:55 UTC 2021

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210818/3ec89918/attachment.html>