srl-labs/intent-based-ansible-lab

Intent-based fabric management with Ansible

A practical example of using Ansible to manage the configuration of an SR Linux fabric with the intent-based approach leveraging the official Ansible collection for SR Linux - read the tutorial on learn.srlinux.dev for a complete walkthrough of this project.

---

Run this lab in GitHub Codespaces for free.
Learn more about Containerlab for Codespaces.

---

Quick Start Guide to run in codespaces

1. Deploy the lab topology:

sudo clab deploy -t topo.yml

2. Run the Ansible playbook:

ansible-playbook -i inv/ -e intent_dir=/workspaces/intent-based-ansible-lab/intent_examples/infra/underlay_with_fabric_intent --diff playbooks/cf_fabric.yml

intent-based-ansible-lab's Issues

roles vars vs host vars

@wdesmedt I wanted to check why did you decide to add host variables in each role's vars section. Why don't you put host vars into the inventory, making it a single place where host_vars are defined.

Imagine you grow your fabric from 4 leaves to 6 leaves. With the current approach you would have to add clab-xxx-l5 and clab-xxx-l6 vars to all the roles, instead of just adding the relevant nodes into the inventory.

Add CI

Automated testing of playbook roles (ansible-test?)

Implement intent validation

Intent validation with e.g. custom filters + pydantic or builtin jsonschema criteria.

Don't use environment variables for intent environment

Currently the intent environment is being specified using an environment environment, this is a non-native Ansible concept so isn't supported by for example Ansible Tower/AWX. Instead just use env as a fact directly as is being set in https://github.com/srl-labs/intent-based-ansible-lab/blob/dev/playbooks/roles/initialize/tasks/main.yml#L11.

This is what we have changed in our internal fork to make it work with AWX.

remove unused group

@wdesmedt this looks like a leftover

intent-based-ansible-lab/inv/ansible-inventory.yml

Lines 45 to 50 in fd9b1f3

	sros:
	hosts:
	clab-4l2s-dcgw1:
	ansible_host: 172.20.21.250
	clab-4l2s-dcgw2:
	ansible_host: 172.20.21.251

Support setting the commit message

I would like to be able to specify the commit message that gets used in the JSON-RPC call to the device. That way we can use the Git commit message as commit message on the device when integrating it with our CI/CD pipeline.

Use of labels

Rather than specifying individual interfaces or network-instances, use labels as properties to resources that can be referenced by other resources/services (e.g. l2vpn with interfaces tagged with label xxx, l3vpn with interfaces and macvrfs tagged with label yyy, ...

Add support for BGPaaS

PE-CE routing in the overlay.

Generic verision match lookup workflow

Often, lookup vars that match the full version is not feasible. Instead, a generic version lookup logic can be introduced:

1. first lookup vars from the full version match (as it is done today) - e.g. 23.3.3
2. if not found, lookup vars from the major version - 23.3
3. if not found, lookup vars from the year release - 23
4. if not found, lookup vars from the default location - e.g. default/vars.yml

Add support for routed interfaces in l3vpn

Move to filters for high-level intent

Coding in Jinja/YAML is error-prone and difficult to troubleshoot. Proposal to move to custom filters (l2vpn, l3vpn) to generate low-level device configuration from high-level intent.

Support for 'fabric intent'

Define high-level fabric intent model that gets transformed in the custom low-level per-device intent (=device abstraction layer), currently used for underlay via the infra role. Still support input into the per-device intent to suppport configuration that is not covered by the fabric intent.
Fabric intent should define a.o.

• 'ASN range' for BGP-underlay
• roles: spine, leaf, bleaf, dcgw
• external access handoff: vlan, vxlan
• underlay-routing: OSPF, ISIS, BGP, BGP-UNNUMBERED - blueprint currently defines BGP only
• ISL prefix: from which inter-switch links are getting addresses from: ipv4, /31
• VTEP prefix: from which system loopback interface gets address from (/32)
• ISL ports (leaf, spine, bleaf)
• ACCESS or DOWNLINK port (leaf)