Speeding up with_items for cisco.ios.config

[shepherdjay]

Apologies if this is the incorrect place to raise this discussion - please point me in right direction.

Like many organizations I have an access layer with thousands of access interfaces. Most of which can be organized into groups of configurations with similar configurations.

Currently we utilize the base_interfaces_config and l2_interfaces_config module. We like this module as it is very efficient. We generate all the necessary arguments for all interfaces per device offline and feed it into each modules respective config attribute. This results in a single ssh session, one show run, and very quick deploy. We can configure a fully populated switch stack over 380 ports in less than a minute typically. If no changes are necessary the time it takes to verify no changes is around 25 seconds.

However - the downside is that these two modules contain only a small subset of an interfaces config. It doesn't include any settings like 802.1x or ip arp rate limiting, or burst limiting, etc.

We've recently tried to move our entire interface config to the cisco.ios.config module using with_items but it is very slow. The same attempt with no changes needed takes 42 seconds just to get through a single switch in the stack. I'm sure this is due to show running being executed each time.

I'm looking for ways to speed this up or perhaps be pointed in a better way. Is there a way to cache the startup config in another task first and have the cisco.ios.ios_config reference that config when deciding if changes are needed?

At the end of the day what I'm trying to achieve with ansible (and perhaps it is wrong tool) is the following:

• Provide simple group definitions of a configuration (ie... printer_port)
• Have team members map ports to that group so they don't have to manage editing a large config file (error prone) or logging into switch
• Ensure that the port config perfectly matches its group definition. (using state: replaced currently on other modules

[Qalthos]

This sounds like what the single_user_mode option was created for. If that's not sufficient, however, an example log with device interaction logging turned on would be a start towards figuring out where the slowdown is and what we can do about it.

[shepherdjay]

@Qalthos - I will try that single_user_mode option and see if it helps speed things up. I do see in that link though that entering config mode invalidates cache. Sounds like it would only speed up when verifying ports and not necessarily if a large amount of changes are required.

I don't have device interaction logging but we have a radius server and so far what we are seeing is that it is issuing "show run" every time. Given that this is with_items that makes sense.

Some thoughts I've had is perhaps just figuring out a workflow in ansible where the running config is pulled. Then I somehow store the commands ansible wants to run in a list of commands, then finally pushing those to the device.

[shepherdjay]

So when no changes are needed to interfaces user single_user_mode is faster for sure. It's still about 3x slower than using the interface modules but at least it is closer to an acceptable rate for regular use.

Worse case scenario if every interface needs to change a line item then the slowdown is about 4x over using the interface modules. This again seems to be because show and config commands are ran every time.

Here are testing results:

Time Results
Ran against test 6 switch stack 48 ports per switch

no_changes_config_module: 2 minutes 18.76s
no_changes_interface_modules: 38.179s

all_changes_config_module: 23 min 26.78s
all_changes_interface_modules: 5 min 23.11s

[shepherdjay]

Perhaps the easiest ask is to not try to speed up the cisco ios config module and instead ask for a feature enhancement to the base_interfaces module to support setting an interface template? Then we can get the speed of the base interfaces module for add/remove/changing of templates and use the ios config module to ensure those templates exist on the devices.

[shepherdjay]

Opened Feature Request #677