Ansible Network Automation - Issue Rendering Jinja2 Template - Invalid input

Solution Verified - Updated -

Environment

This issue primarily affects users running ansible-core 2.19+ with network collections earlier than ansible.netcommon 8.2.1, most commonly in standalone community environments. Ansible Automation Platform (AAP) is not impacted when using the default Execution Environments, as both ee-minimal and ee-supported ship with ansible-core 2.16. However, users who build custom Execution Environments that include ansible-core 2.19 or newer may be affected and should ensure they are using an updated version of ansible.netcommon.

Issue

Recent community reports around Ansible network automation stem from a regression introduced in ansible-core 2.19 related to how network *_config modules handle templating of the src parameter. Historically, some network modules supported inline Jinja2 templating directly within src (for example, src: template.j2). In ansible-core 2.19, core Ansible enhancements changed some underlying behaviors used during network configuration generation. Several network collections depended on the previous behavior, which led to breakage when those assumptions changed.

   - name: Apply configuration from template
     arista.eos.eos_config:
       src: template.j2

Resolution

The regression has been addressed in ansible.netcommon 8.2.1, which restores expected behavior for src in network *_config modules when used with ansible-core 2.19+.

Install or upgrade ansible.netcommon from Ansible Galaxy
This installs the latest released version (including the 8.2.1 fix):

ansible-galaxy collection install ansible.netcommon --upgrade

To verify the installed version:

ansible-galaxy collection list ansible.netcommon

Install a specific version (for controlled environments)
If you want to pin to a specific version:

ansible-galaxy collection install ansible.netcommon:==8.2.1

Install into a virtual environment

python3 -m venv venv
source venv/bin/activate
python -m pip install ansible
ansible-galaxy collection install ansible.netcommon --upgrade

(Optional) Install directly from GitHub for testing only
This is not recommended for production, but can be useful for validation or CI:

ansible-galaxy collection install \
  git+https://github.com/ansible-collections/ansible.netcommon.git

We strongly encourage community users to open questions and issues on forum.ansible.com, which allows Red Hat engineers and maintainers to engage directly, ask clarifying questions, and provide guidance that benefits the broader Ansible community. For Red Hat customers using Ansible Automation Platform, the recommended path is to open a support case through the Red Hat Customer Portal (access.redhat.com, where issues can be tracked formally and addressed according to support SLAs. Using these channels ensures problems are visible, actionable, and communicated back to both customers and the wider community, helping us improve Ansible more effectively for everyone.

Root Cause

In these cases, the network module is not rendering the Jinja2 template before sending the configuration to the device. Instead, the template content is treated like a literal configuration file and pushed as-is. As soon as the device encounters the first {{ ... }} sequence, it fails parsing the configuration and the task stops with a device-side syntax error.

Diagnostic Steps

When a playbook uses a network *_config module with src: some_template.j2 and the template contains Jinja2 variables, the task may fail at the device CLI with an error indicating invalid input. The error string often includes the first unrendered Jinja2 expression (the first {{ ... }} the device receives).
Example (device-side error surfaced through Ansible):

[ERROR]: Task failed: Action failed: b'{{ another_command }}\r\n% Invalid input\r\n...#'
...
"msg": "b'{{ another_command }}\\r\\n% Invalid input\\r\\n...#'"

Key indicators:
- The error contains raw Jinja2 such as {{ another_command }} (or whatever variable is first in the file).
- The network device returns a syntax-style error (% Invalid input, Unknown command, etc.).
- The module invocation often shows src content inlined in the failure output with the unrendered {{ ... }} still present.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments