Extend the solution

We’ll start in your VS Code tab. In the file explorer, under playbooks, let’s revisit the playbook yang_info.yml.

The last time we ran this, we had the search_for variable set to "interface" and we picked a module from the list that had "oper" in the name. This time let’s change the value to be "oper", which will show us every operational module available on rtr1.

Line 8 in the playbook should be changed to look like:

Once edited, run the playbook:

The output should look like:

There are a few BGP-related modules showing up in the list but let’s go with the simplest option, Cisco-IOS-XE-bgp-oper.

As before, we’ll note this information and move onto finding an xpath.

Let’s now revisit the playbook yang_fetch.yml.

The last time we ran this, we had the model variable set to "Cisco-IOS-XE-interfaces-oper". This time let’s change it to "Cisco-IOS-XE-bgp-oper".

Line 8 in the playbook should be changed to look like:

Once edited, run the playbook:

The playbook will again create some files in playbooks/yang_files. We now have a couple new files, including Cisco-IOS-XE-bgp-oper.yang and Cisco-IOS-XE-bgp-oper.tree.

Click on Cisco-IOS-XE-bgp-oper.yang and as before, look for a line starting with "prefix". On line 4 you should see:

Our prefix will be bgp-ios-xe-oper.

Next, let’s look in Cisco-IOS-XE-bgp-oper.tree, which looks like:

We can see that under bgp-state-data is a key called neighbors, and under that is a key called neighbor, and under that is some promising-looking data about BGP state.

We’ll remember the xpath bgp-state-data/neighbors.

In your student workbench, under playbooks, let’s revisit the playbook configure_ios_telemetry.yml.

The last time we ran this, we had the telemetry_nodes variable set like the following:

This is a list structure, so let’s add an item to the list for the new xpath we just found. This will preserve the existing interface monitoring, and add BGP as a second subscription.

Lines 8-12 in the playbook should be changed to look like:

Once edited, run the playbook:

Expected output:

We can see that the only lines reporting changed are related to BGP, since the interface monitoring was alrady applied.

In your terminal, ssh to rtr1.

First, we’ll verify that the telemetry configuration is looking good:

You should see both subscriptions:

Next, ensure that the router sees the new subscription as valid:

Expected output:

Exit the SSH session.

Now in your terminal, we want to validate that BGP-related messages are appearing. We will run the Kafka monitor while filtering for BGP messages:

You may have to wait up to 30 seconds for the next message to appear. As soon as it does, you can press CTRL+C a few times to end the monitoring.

You’ll have a new file called bgp.json visible in your file explorer. Open it to see the whole Kafka message.

We’ll need to choose something in this message to use to detect a bad BGP state. Nested under the fields key, there is a connection/state key set to established. So, let’s make a note that our condition for the rulebook, indicating bad status, will be for fields['connection/state'] to be anything other than "established".

In your student workbench, open the file rulebooks/routing_status_cli.yml.

This file should look familiar. You can open the rulebook we used earlier, rulebooks/interface_status_cli.yml, and see that the two files are very similar.

This new rulebook has one change, which is the addition of another rule under the rules block. The action in the new rule is also the same, since the playbook we’ve been using applies both interface and BGP configurations.

The intent is that we will run this rulebook instead of the one we were using earlier, since it represents a more complete coverage of our routing configuration, and the source (Kafka topic "eda") is identical.

Let’s run it to test. You should still have a second terminal from the last time we ran ansible-rulebook. Switch to it using the navigation on the right side of the terminal. In this terminal, run the following command:

As before, no output from the ansible-rulebook command is expected whenever there are no matching conditions.

Switch back to your original terminal and connect to rtr1.

Let’s check on the current BGP state.

Example output:

This looks good, and we want to pay attention to the very last bit of data in the bottom right, State/PfxRcd. The 4 that we see now is normal in this environment.

We want to run some commands to intentionally break BGP, by giving rtr1 the wrong AS number for its neighbor (65009 instead of 65001).

Check the BGP summary again and we should see bad things happening to our BGP state (note the incorrect AS number and state being listed as Closing or Idle)

Output:

Now swap back to your ansible-rulebook (python3) terminal. You should see the playbook run.

Example output:

Notice that the second task of the playbook reported "changed" this time instead of the first.

Press CTRL+C to stop ansible-rulebook.

Most of the AAP elements are already set up from previous exercises. All we need to do is swap the old rulebook out for the new one.

Switch to your AAP tab. You may need to log in again.

In the left side navigation, go to Automation Decisions > Rulebook Activations. Your "Interface status" activation from earlier should still be running. On the far right side, click the 3 dots and select "Delete rulebook activation".

Confirm that you want to delete the activation by checking the box next to "Interface status" and clicking the "Delete rulebook activations" button. Click the Close button on the dialog that follows.

Now we will re-make the Rulebook Activation. Click on the blue "Create rulebook activation" button. On the page that follows, fill out the form with the following information:

Wait for the Activation to start (Activation status should say "Running"), then click on the History tab. Note that you have an entry titled "2 - Routing status" which, as before, means EDA is up and listening for events.

In the left side navigation, go to Automation Execution > Jobs. For now, there is nothing new here. The last run of "Router configuration" at the top of the list is the one from earlier that fixed the shutdown interface.

We are now set up to test that the new expanded rulebook is working. Switch back to the VS Code workbench and SSH to rtr1.

We’ll break BGP again.

Once these commands have been issued, switch back to your AAP tab. Look for another instance of "Router configuration" to kick off (you may again be waiting a few seconds). Once it does, click on it to monitor the progress.

You should see:

This matches what we saw on the CLI, so our new BGP monitoring is working correctly. Let’s also test that the interface monitoring is still working.

In the left side navigation, go to Automation Execution > Jobs so that we are set up again to watch for new jobs. Then, switch back to your VS Code tab. You should still be in the SSH session with rtr1. Run the commands we previously used to shutdown Tunnel0:

Switch back to your AAP tab and watch for a new instance of "Router configuration" to kick off. Once it does, click on it to monitor the progress.

You should see:

This is the same as what we were seeing before, so that is working as expected.

If desired, repeat any of these tests by breaking configurations on rtr2 instead of rtr1.

You now have both misconfiguration conditions being handled in AAP. And, you have the tools you need to extend this even further.