Jason Barbee

How do you know everything is wired up correctly without giving yourself a RSI typing injury? That’s what Automation is for…

In SD-Access you will probably use ISE for security, group tags, and VRFs. You might even leak routes between VRFS. Each Border will have interfaces to the core. Dual Border Dual Fusion Router scenarios quickly leave you with a lot of paths, and a lot of places to test.

Testing Goals :

1. Confirm Borders Loopbacks inside their VRFs can reach important targets outside the Border.
2. Confirm Borders and their VRFs can reach ISE/DNA.
3. Confirm Fusion Routers and their VRFs can reach the Borders, or other targets.
4. Gives a test package for acceptance testing, and health checks if you test failover.
5. Confirm Borders and their VRFs CANNOT reach things you do not want them to reach (an unreachable test)

SD-Access is focused around security. How can you confirm you can reach things you want to, and your segmentation is actually effective in not reaching things you don’t want to reach? You need to test. You don’t want to find out your ISE policies changed, and suddenly Internet Only devices are leaking into your core network.

As I went through a recent install, the complexity around borders and security lead me to build a test package for these reasons - and Ansible is my goto solution. It allows a quick and repeatable process of testing important things after changes or at the end of a project, and was fun to build!

The project is at GitHub - SDA-Testing

Let’s walk through it’s operation.

all.yml contains the configuration like targets, VRFs, interfaces to source from, etc.

ansible_connection: network_cli
ansible_user: sshuser
ansible_ssh_pass: sshpassword

borders:
  - { vrf: 'Voice', source: 'Loop11', reachable_test: [10.1.10.1, 10.3.10.1], unreachable_test: [192.168.1.1]}
  - { vrf: 'Clients', source: 'Loop10', reachable_test: [10.10.2.1, 192.168.3.1], unreachable_test: [10.0.0.1]}
  - { vrf: 'IOT', source: 'Loop9', reachable_test: [], unreachable_test: [192.168.1.1]}

cores:
  - { vrf: 'default', source: 'Vlan10', reachable_test: [10.1.100.1, 10.3.100.1, 10.2.100.1], unreachable_test: []}

ise:
  - 10.1.1.10
  - 10.1.1.11
dna:
  - 10.1.3.10
  - 10.1.3.11

inventory is your normal ansible file just add your devices there.

Learning Oppurtunity: Consider using Ansible-Vault. I stored my credentials in a vault file under roles/secrets/vars/main.yml. Remove the 2 credential variables from the all.yml and follow along below -

ansible-vault create roles/secrets/vars/main.yml

Then enter your credentials like this

ansible_user: sshuser
ansible_ssh_pass: sshpassword

Save the file maybe in your root folder of this project - like vault-pass.key.

Now, you should be able to run the entire playbook, and not have to type that password each time by using this

ansible-playbook site.yml -i inventory --vault-password-file  vault-pass.key

or without vault like this

ansible-playbook site.yml -i inventory

I can’t share the entire output or screenshots, but here’s a sanitized snip of a long Ansible output.

TASK [cores : Test Core reachability in VRF "default" from "Vlan1" to ISE] **************************************
ok: [10.1.2.2] => (item=10.4.1.10)
ok: [10.1.2.1] => (item=10.4.1.10)
ok: [10.3.2.2] => (item=10.4.1.10)
ok: [10.3.2.1] => (item=10.4.1.10)
ok: [10.3.2.1] => (item=10.4.1.11)
ok: [10.3.2.2] => (item=10.4.1.11)
ok: [10.1.2.1] => (item=10.4.1.11)
ok: [10.1.2.2] => (item=10.4.1.11)


TASK [cores : Confrim Core Unreachability in VRF "default" from "Vlan1" to Targets] *******************************
failed: [10.1.2.1] (item=10.0.0.1) => {"changed": false, "item": "10.0.0.1", "msg": "Ping succeeded unexpectedly"}