Ansible arista.eos.eos_vlans: Declarative VLAN Automation

VLAN changes are the most common network ticket and also the easiest to automate safely, because the intent fits in one small data structure per device. The Ansible resource module arista.eos.eos_vlans takes that structure and reconciles the device to it, which removes both the CLI typing and the drift. The interesting part is that the same module gives you four different semantics - merged, replaced, overridden and deleted - and picking the wrong one is how automation deletes a VLAN nobody meant to touch.

Install and Inventory

ansible-galaxy collection install arista.eos
cat > inventory.yml <<'EOF'
all:
  children:
    eos_switches:
      hosts:
        leaf-01:
          ansible_host: 10.0.0.11
        leaf-02:
          ansible_host: 10.0.0.12
      vars:
        ansible_network_os: arista.eos
        ansible_connection: network_cli
        ansible_user: svc-ansible
        ansible_become: true
        ansible_become_method: enable
EOF

Use network_cli for CLI-based devices and httpapi (eAPI) where the platform supports it for faster, structured transport. Always give the playbook a service account with a role, not an admin password.

The Desired-State Variable

# group_vars/eos_switches.yml
desired_vlans:
  - vlan_id: 100
    name: SERVERS-PROD
    state: active
  - vlan_id: 110
    name: SERVERS-DEV
    state: active
  - vlan_id: 999
    name: RESERVED-NATIVE
    state: suspend

The Four States Explained

• merged - add or update the VLANs you list; everything else on the device is left alone. Safe default.
• replaced - for the VLANs you list, remove attributes you did not specify (a name or a state, for example), leaving other VLANs untouched.
• overridden - the device VLAN database is forced to match the list. Any VLAN not in the list is removed. Correct for keeping switches identical, dangerous if the list is stale.
• deleted - remove the listed VLANs and their attributes.

Playbook with Check Mode and Diff

- name: Reconcile VLAN database
  hosts: eos_switches
  gather_facts: false
  tasks:
    - name: Reconcile VLANs (merged - additive)
      arista.eos.eos_vlans:
        config: "{{ desired_vlans }}"
        state: merged
      register: vlan_result

    - name: Show what changed
      ansible.builtin.debug:
        var: vlan_result.commands

    - name: Verify the running configuration
      arista.eos.eos_command:
        commands:
          - show vlan
          - show running-config | section vlan

# dry run first - always
ansible-playbook -i inventory.yml vlans.yml --check --diff

# then apply
ansible-playbook -i inventory.yml vlans.yml

Resource modules are idempotent: a second run with no change reports changed: false and pushes no commands. If your second run still shows changes, the device has something the module cannot express (an internal VLAN, for example) or an attribute is normalised differently - read the commands output to see exactly what it tried to send.

Safe Rollout Pattern

• Keep the desired state in git and review changes like code.
• Run --check --diff in CI for every pull request.
• Apply to one canary switch with --limit, then to the rest.
• For destructive operations, snapshot the running configuration first (Arista EOS configuration sessions also help - see EOS configuration sessions).
• Never use overridden on a device whose full VLAN list you do not control.

Where This Fits

Resource modules are the declarative layer; they pair well with Nornir for inventory-driven tasks and with NAPALM getters when you need to pull state back for reporting. Validate the result with Batfish snapshot validation before it reaches production.

Testing Changes Before Production

• Syntax and lint - ansible-lint and ansible-playbook --syntax-check catch the trivial errors before they reach a device.
• YAML tests - assert the desired-state file itself is well formed (unique VLAN IDs, valid names) with a small assert task; typos in data are more common than typos in playbooks.
• Lab first - run the same playbook against a containerlab or virtual EOS instance before any production run.
• Validate the result - after applying, pull the configuration and check it with a validation engine rather than reading the task output. Batfish snapshot validation handles this well.
• Keep a rollback file - dump show running-config | section vlan before the run so reverting is a copy-paste, not an investigation.

原文链接：https://docs.ansible.com/projects/ansible/latest/collections/arista/eos/eos_vlans_module.html