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 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