I agree, I don't think you can get around the XR config bottleneck. But that's not really the end of the story. Let's think about why the loading time matters to Sander (Sander, please chime in here): 1. They have to address an immediate issue for a customer (internal or external) and the customer is impatient. 2. They're sitting there waiting for the load to complete before they can move on to their next task. Possibly having to make the same change to multiple devices. I can't really offer anything for the first case. But in the second case, automation can help address that by making changes more unattended and parallelizable. In terms of structured vs unstructured data, sure, assembling text is not a huge lift. Though, when you're talking about layering on complex use cases, then it gets more complicated. Especially if you want to compute the inverse configuration to remove service instances that are no longer needed. In terms of vendor support, I'd hope that if you're paying that kind of money, you're getting a product that meets your requirements. Something that should be assessed during vendor selection and procurement. That's just my preference; do whatever works best for your use cases. On Fri, Dec 9, 2022 at 10:35 AM Saku Ytti <saku@ytti.fi> wrote:
On Fri, 9 Dec 2022 at 17:30, Tom Beecher <beecher@beecher.cc> wrote:
Pushing thousands of lines via CLI/expect automation is def not a great idea, no. Putting everything into a file, copying that to the device, and loading from there is generally best regardless. The slowness you refer to is almost certainly just because of how XR handles config application. If I'm following correctly, that seems to be the crux of your question.
If you read carefully, that is what Steffann is doing. He is doing 'load location:file' + 'commit'. He is not punching anything by hand.
So the answer we are looking for is how to make that go faster.
In Junos answer would be 'ephemeral config', but in IOS-XR as far as I know, the only thing you can do is improve the 'load' part by moving the server closer, other than that, you get what you get. -- ++ytti