r/networkautomation

Hello everyone!

I am working on a project and can't seem to get one issue fixed. Have been trying to troubleshoot this issue for days now but I am not able to get it working. Just a quick background, I am a aspiring NetDevOps engineer and I am trying to learn network automation by creating different projects. In this project I have used python (jinja2 lib) and ansible. My playbook is loading the configurations from a text file directly to the devices and there is no commit command being used in the template (and the config files as well). But every time that I run the playbook I get

[ERROR]: Task failed: Action failed: b'commit\r\n% Invalid input\r\nRouter5#'

Origin: /home/kimon/automation_bgp/playbook.yml:9:5

7

8 tasks:

9 - name: Load Configuration

^ column 5

fatal: [Router5]: FAILED! => {"changed": false, "msg": "b'commit\\r\\n% Invalid input\\r\\nRouter5#'"}

And not just for one, but for all the 10 routers. Right now I am using ansible.netcommon.cli_config module and I have also tested it with arista specific config module but using that gave me even more errors. The commands that were working with cli_config started to give me error when using arista's module. I had been using ChatGpt to try to troubleshoot this issue but all the suggestion were of no use.

Please reply to this if you have ever came across this issue. Any help would be appreciated.

The following is my playbook:
---

- name: All Device Configuration

hosts: all

vars_files:

- creds/cred.yml

tasks:

- name: Load Configuration

ansible.netcommon.cli_config:

config: "{{ lookup('file', './device_configs/' + inventory_hostname + '.txt') }}"

...

Had an AI tool generate a fix for a connectivity issue, "asymmetric routing causing the resets, traffic going out the primary link and returning via backup," complete with a proposed config change to force symmetric routing. Specific, technically coherent, matched the symptom. Would've been easy to push it through the pipeline and call it fixed.

Checked routing tables on both ends before applying anything. Traffic was symmetric the whole time. Real cause was an MTU mismatch on one hop, completely different mechanism, similar-looking symptom on the surface, and the proposed fix would've done nothing for the actual problem while adding an unnecessary routing change to production.

The theory wasn't wrong because the reasoning was bad. Asymmetric routing is a real, common cause of exactly that reset pattern, so the explanation borrowed credibility from being a plausible category of problem without anyone confirming it was the actual instance happening here. That's a dangerous failure mode specifically in an automation context, because the gap between "plausible diagnosis" and "confirmed diagnosis" is exactly the gap that a human would normally catch by eyeballing the change before applying it, and automation pipelines are built to remove that eyeballing step for speed.

Now treating any AI-generated network change the same way: state what the diagnosis predicts should be true elsewhere in the system (in this case, actual routing asymmetry), verify that specific thing programmatically before the change reaches an apply stage, not just before a human signs off on it.