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