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