Not So Fast Ansible, Cisco IOS Can’t Keep Up…
Remember how earlier releases of Nexus-OS started dropping configuration commands if you were typing them too quickly (and how it was declared a feature ;)?
Mark Fergusson had a similar experience on Cisco IOS. All he wanted to do was to use Ansible to configure a VRF, an interface in the VRF, and OSPF routing process on Cisco CSR 1000v running software release 15.5(3).
Here’s what he was trying to deploy. Looks like a configuration straight out of an MPLS book, right?
ip vrf Customer_A
rd 65000:1
route-target import 65000:1
route-target export 65000:1
!
interface GigabitEthernet1.146
ip vrf forwarding Customer_A
ip address 155.1.146.1 255.255.255.0
ip ospf 2 area 0
router ospf 2 vrf Customer_A
router-id 155.1.146.1
redistribute bgp 65000 subnets
Guess what… when he tried to push that configuration to his CSR 1000v with Ansible ios_config module the in-VRF OSPF router process refused to start claiming it cannot get a router ID (%OSPF-4-NORTRID: OSPF process 2 failed to allocate unique router-id and cannot start). The whole thing worked when he tried to configure OSPF a bit later – looks like it takes some time to get a subinterface ready after it’s been configured, and if you’re typing too quickly you’re out of luck.
I could see two immediate solutions to this problem:
- Get a router that has a decent API and all-or-nothing commit mechanism;
- Split the configuration in two parts and push them to the device using two ios_config calls. It takes Ansible long enough to work through its gazillion layers of abstraction for Cisco IOS to realize what just happened.
On a somewhat tangential note, a friend of mine called the current state of network automation “Unix Scripting in 1970s”. Unfortunately he wasn’t too far off…
To learn more about network automation with Ansible start with our Ansible for Networking Engineers webinar and when you’re ready to move from writing playbooks to building solutions enroll into Building Network Automation Solutions online course.
Sure - except that instead of config files, you have to manually run all of the commands that init and RC scripts do when you first install, and when you type "write mem" it just copies your bash history file to rc.local for the next time you reboot.
I ran into this before Palo Alto released a community plugin for configuring anything (previously only certain, specific things could be configured with the PAN ansible module) I was using the ios module to try and configure PAN through the CLI. I ran into the same issue above - lines would get missed.
Copy and pasting valid sections of config ought to work without issues.
I think the only way to describe the IOS behavior in that case is: seriously annoying bug that can cause unexpected problems for people configuring equipment.
There should not be race conditions like that between entering parts of a configuration and the configs becoming active --- they could buffer the remaining config lines until the subinterface is at least created
and ready to be the subject of more config lines.
> ip ospf 2 area 0
IOS will automagically create ospf 2 instance with default settings. Here, if the sole interface is not UP, OSPF will throw an id error.
But after the manual id assignment later
> router-id 155.1.146.1
the OSPF process should be fine.
Probably "clear ip ospf process" will save the deal?