"Tactical" /24 announcements

Thu Aug 19 15:22:21 UTC 2021

Hi David,

On 08/19, David Bass wrote:
> Ben,
> 
> Yes, sorry.
> 
> Pulling/pushing the config data to a server, and then managing it there in
> addition to on the box.  Like, if I want to run some reports to see how
> many PL are defined on each box, it’s easier to do that with the data
> centralized and managed.
> 
Thanks for clarifying.

A bit of additional context:

We build and push whole device configs, doing a full replace on every
change.
The configs are built from centralized, version controlled data which
describes devices connectivity, customer services, etc, etc, etc.
On every change, we retrieve a diff from the device (e.g. show arch
config diff ... on IOS).

Having the *contents* of IRR derived prefix-lists in the configs has two
major downsides:
- it makes the config dependent on data that we don't own (i.e. a box
  gets a new config even though we didn't change any of our internal
  data), which in turn makes the diffs large and noisy; and
- the size of the generated configs is huge, which slows down deployment
  and makes the whole process fragile.

The tool I mentioned allows us to put a single line (syntactically
equivalent to an empty prefix list) in the generated config. The agent
"sees" that line, and fills in the details, keeping it up to date.
The contents of the list never show up in a "show run", keeping noise
levels down.

There are ultimately three sources of policy data that contribute to the
runtime operation of a device:
- config pushed from our deployment tools
- rpki-rtr data
- prefix-list contents, from our mirrors on the various IRR DBs

If I need to know what prefix lists are on a given box, and what they
contain, I can simply look at those data sources directly.

The key to reliability here is to share as much logic between
operational tools as possible, so that you can be confident that the
"ad-hoc troubleshooting tool" gives an answer that is consistent with
the "config generation tool".

Hope that kinda answers the question?

Cheers,

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210819/698afc26/attachment.sig>