Skip to content

Lab 2 - Using Cisco Workflows for automated response

Overview

In this lab, you will build on the event handling and workflow created in Lab 1, by setting up an Automation Remote for Cisco Workflows to talk to your infrastructure through. An Automation Remote enables your workflows to communicate with resources inside your network that do not have access to the internet. Because many user-deployed devices are not exposed to the internet, Automation Remotes bridge the gap between those devices and the cloud so that they can be incorporated into your workflows. See the Automation Remote documentation for more details.

You will define a rule-based remediation workflow, allowing for autonomous closed-loop infrastructure operations.

By the end of this lab, you will:

  • Be able to have Cisco Workflows talk to devices in your infrastructure.
  • Configure static / rule-based workflows where you can automate defined response and remediation.

This will show one way to have automated response, before we bring in cognitive agentic response.

The following diagram illustrates the event flow we are building:

flowchart LR
    A[Device] -->|syslog| B[Splunk]
    B -->|webhook| C[Cisco Workflows]
    C -->|commands| D[Remote Server]
    D --> A

Step 1: Registering a remote server to Workflows

  1. Go to meraki.cisco.com
  2. Browse to Automation > Targets > Remote Targets click + New Remote.
  3. Set the Display name to <your_name>-remote and click Save.
  4. Back on the Remote Targets page, click the ... under Actions and choose Connect.
  5. Click Generate Package from the popup. This will generate and automatically download a file remotePackage.zip.

  6. Copy the file over to the wf-remote server (198.18.1.204). Note: The password for this account is cisco: 

    scp remotePackage.zip root@198.18.1.204:/root/

    Windows Users

    Use WinSCP to connect to 198.18.1.204 with username root, navigate to /root/ on the remote side, and drag and drop remotePackage.zip from your local machine.

  7. SSH to the wf-remote server and run the registration script: 

    ssh root@198.18.1.204
./register_remote.py /root/remotePackage.zip

    Windows Users

    Use PuTTY to connect to 198.18.1.204 with username root, then run the registration script shown above.

You will be prompted to say 'yes' to initiate registration after it checks the existing status. If there are old certifications or registration (i.e. you ran the script and/or registered before) it will first prompt to remove the certificates before prompting to register.

Example output: 

root@default-hostname:~# ./register_remote.py /root/remotePackage.zip
[*] Extracting base64 from zip file: /root/remotePackage.zip
[+] Found config file: scdozier-remote_remoteconfig_20260129T215214.txt
[+] Successfully extracted base64 string from zip
[*] Decoding OVF user-data string...
[+] Successfully decoded cloud-config
[*] Extracting YAML configuration files...
[*] Files found in cloud-config:
    - /etc/ao-remote/values.yaml
    - /etc/ao-remote/ca-key-pair.yaml
[+] Found values.yaml at: /etc/ao-remote/values.yaml
[+] Found ca-key-pair.yaml at: /etc/ao-remote/ca-key-pair.yaml

======================================================================
XDR Remote Appliance Configuration
======================================================================
Remote Name:     <your_name>-remote
Remote ID:       1744720:02T4G1V7NYIII0DoURJal8r4JSjHUqqvPs2
MQTT Broker:     tcps://us-remote.workflows.meraki.com:8883
Proxy:
======================================================================


[!] Existing XDR containers are already running
[*] Would you like to stop and remove them before re-registering? (yes/no)
>
9. Wait a few seconds, and then refresh the Workflow's Targets page. You should see your remote move into a Connected status.

Note

The official process for registering a remote server differs from this a bit. Cisco Workflows currently only supports remote servers running on virtual VMWare appliances where you can pass the initialization/registration text into an OVF template. Since dCloud doesn't support OVF templates, we feed the remotePackage into a python script that runs the same cloud init script that the OVF template would have triggered. Cisco is working on making the official remote server deployment more flexible for deployments outside of OVF / VMWare. For the full documentation on deploying a remote server, see the official Cisco Workflows documentation.

Step 2: Configuring remote targets

2.1 Configuring R3 as a target

  1. In Automation > Targets go to + New target and set:
    • Target type: Terminal endpoint
    • Display name: <your_name>-R3
    • Remote Keys: <your_name>-remote (this specifies that this device should use the remote server to connect)
    • Protocol: SSH
    • Host/IP Address: 198.18.1.103
    • Port: 22
    • Prompt: #
  2. Under Default Account Keys, click the down arrow and say Add new and specify:
    • Account Key Type: Terminal password-based credentials
    • Display Name: <your_name>-R3-creds
    • User name: cisco
    • Password: cisco

  3. Ensure that the status of the devices shows as Valid which is ensuring a basic connection check to the device.

    Note

    If the target cannot connect, verify the IP address is correct and that Remote Keys is set to your remote server. Without the Remote Keys configured, Workflows will attempt to connect over the internet instead of through your remote server.

Step 3: Create Standalone Notification Workflow

In this step, you will convert your Lab 1 notification workflow into a reusable standalone workflow. The main workflow (<your_name>-unshut-int) will contain a JSONPath Query, Terminal Commands, and a Sub-workflow Call that invokes the notification sub-workflow (<your_name>-notify2).

3.1 Duplicate Your Lab 1 Notification Workflow

  1. Go to Automation → Workspace
  2. Find your workflow <your_name>-notify from Lab 1
  3. Click the ... menu on the workflow row
  4. Select Duplicate
  5. A new workflow named Copy(1) <your_name>-notify will be created

3.2 Configure the Duplicated Workflow

  1. Click on the duplicated workflow Copy(1) <your_name>-notify to open it in the editor
  2. In the right-side panel, click the General tab
  3. Change the Display Name to <your_name>-notify2

3.3 Add an Input Variable for the Message

We need to make this workflow accept a message as input so other workflows can pass in custom messages.

  1. In the right-side panel, click Variables to expand the variables section
  2. Click + Add variable
  3. Configure the new variable using the Variable Browser (the puzzle piece icon allows you to select variables):
    • Data Type: String
    • Name: message_body
    • Scope: Input
    • Check Required for workflow to run
    • Default Value: -1 (this helps identify if it wasn't set properly)

3.4 Update the Webex Activity to Use the Input Variable

  1. Click on the Post Message to Room activity in the workflow canvas to select it
  2. In the activity properties panel, find the Markdown Message field
  3. Clear the existing content
  4. Click the variable reference icon and navigate to: Workflow > Input > message_body
  5. This links the message content to whatever is passed into the workflow

3.5 Validate the Workflow

  1. Click Validate in the upper right corner
  2. Ensure there are no validation errors
  3. If validation passes, the workflow is ready to be called from other workflows

Step 4: Create the Remediation Workflow

Now you will create the main workflow that parses the webhook, sends commands to the device, and calls the notification sub-workflow.

4.1 Create a New Workflow

  1. Go to Automation → Workspace
  2. Click +Create
  3. Set the Intent to Workflow with Automation Rule
  4. Set the Display Name to <your_name>-unshut-int
  5. Click Continue
  6. You will be given an empty canvas. When you drag your first activity, the Start and End blocks will appear.

4.2 Configure the Automation Rule

  1. Click anywhere on the workflow canvas (not on any activity) to show the workflow properties
  2. In the left panel, expand Automation Rules, then set the rule type to Webhook Rule

4.3 Configure the Workflow Target

Before adding activities, we need to configure the workflow target settings.

  1. Click anywhere on the workflow canvas (not on any activity) to show the workflow properties
  2. In the right-side panel, find the Target section
  3. Select No Target

4.4 Add JSONPath Query Activity (Parse Webhook)

Now we'll add an activity to extract the device IP from the webhook payload.

  1. In the left panel, click Activities
  2. Search for JSONPath Query
  3. Drag the JSONPath Query activity onto the canvas below the Start block
  4. Connect the Start block to the JSONPath Query activity (drag from Start's output to JSONPath's input)

4.5 Configure the JSONPath Query Activity

  1. Click on the JSONPath Query activity to select it
  2. In the right-side panel, configure:
    • Display Name: get_device_ip
  3. In the Source JSON to Query field:
    • Click the variable reference icon to open the Variable Browser
    • Navigate to: Rule > Webhook Rule > Output > Request Body

  4. Under JSONPath Queries, click + Add and configure:

    • JSONPath Query: $.result.dvc
    • Property Name: target_device
    • Property Type: String

    Info

    The JSONPath $.result.dvc extracts the device IP address from Splunk's webhook payload. The extracted value will be stored in a variable called target_device that we'll use to route commands to the correct device.

4.6 Add Terminal Commands Activity

  1. In the left panel under Activities, search for Terminal
  2. Drag the Execute Terminal Commands activity below the JSONPath Query activity
  3. Connect the JSONPath Query output to the Execute Terminal Commands input

4.7 Configure the Terminal Commands Activity

  1. Click on the Execute Terminal Commands activity to select it
  2. Set the Display Name to unshut interface
  3. In the Terminal > Input Commands section, enter the following commands (one per line): 
    conf t
int lo0
no sh
end
send log "Cisco Workflows has automated unshutting an interface."

4.8 Override the Workflow Target

  1. With the Execute Terminal Commands activity still selected
  2. In the Target section, select Override workflow target

  3. Set the target to <your_name>-R3

    Note

    We are manually overriding to R3 for simplicity. In a production environment with many devices (targets), you'd likely want dynamic selection of targets based on the webhook payload, and use target groups and selection conditions. For this lab, we're keeping the target simple, since in lab3 we will integrate a remote inventory/access tool (Cisco CX RADKit) that prevents having to duplicate device inventory in Workflows.

4.9 Add the Notification Sub-Workflow

  1. In the left panel, click Workflows (not Activities)
  2. Search for <your_name>-notify2
  3. Drag your <your_name>-notify2 workflow onto the canvas below the Terminal Commands activity
  4. Connect the Execute Terminal Commands output to the notify2 input

4.10 Configure the Notification Input

  1. Click on the <your_name>-notify2 workflow block to select it
  2. Find the message_body input field

  3. variable reference icon and navigate to: Activities > unshut interface > Response body

    Note

    This passes the terminal command output (showing what commands ran and their results) to the Webex notification. You could add additional text before/after this variable if you want more context in your notifications.

    Notification sub-workflow configuration with message_body variable reference

4.11 Validate the Complete Workflow

  1. Click Validate in the upper right corner
  2. Ensure there are no validation errors
  3. Fix any errors before proceeding

Your completed workflow should look like this:

flowchart LR
    A([Start]) --> B[get_device_ip<br/>JSONPath]
    B --> C[unshut interface<br/>Terminal Cmd]
    C --> D[notify2<br/>Sub-workflow]

Step 5: Update the Trigger Rule

Now we need to update the webhook rule from Lab 1 to trigger our new remediation workflow instead of the simple notification workflow.

  1. Go to Automation → Rules
  2. Find and click on your webhook rule from Lab 1
  3. In the Actions section, change the Workflow from your Lab 1 notification workflow to <your_name>-unshut-int
  4. Click Save

Step 6: Validation

6.1 Prepare R3 for Testing

  1. SSH to R3: 
    ssh cisco@198.18.1.103
  2. Ensure the loopback0 interface is up: 
    show ip int brief | include Loopback0
  3. If up, clear the log to start fresh: 
    clear log

6.2 Trigger the Event

  1. Shut down the loopback0 interface: 
    conf t
int lo0
shut

6.3 Monitor the Workflow

  1. Wait approximately 90 seconds for Splunk to process the syslog and trigger the webhook
  2. Go to Automation → Workspace
  3. Find your <your_name>-unshut-int workflow
  4. Click ... > View runs to see workflow executions

6.4 Verify Success

  1. Check R3 - the loopback0 interface should be back up: 
    show ip int brief | include Loopback0
  2. Check your Webex space for the notification with command output
  3. Check the workflow run for successful completion of all activities

Step 7: Troubleshooting

If the workflow doesn't run or fails:

  1. Webhook not firing: Check Splunk search and alert configuration from Lab 1
  2. Workflow validation errors: Review each activity's configuration and variable references
  3. Target not found: Verify the target group contains your R3 device and the JSONPath correctly extracts the device IP
  4. Terminal commands fail: Check that the remote server is connected and R3 credentials are correct
  5. Notification fails: Verify the notify2 workflow's Webex target override is configured

To view detailed errors:

  1. Go to Automation → Workspace
  2. Click on your workflow
  3. Click ... > View runs
  4. Click on a failed run to see detailed error messages for each activity

Summary

You have successfully configured automated remediation infrastructure:

Component Name Purpose
Remote Server <your_name>-remote Allows Workflows to send commands to on-prem devices
Terminal Target <your_name>-R3 Device endpoint for SSH commands
Target Group <your_name>-routers Collection of devices for workflow targeting
Notification Workflow <your_name>-notify2 Reusable sub-workflow for Webex notifications
Remediation Workflow <your_name>-unshut-int Main workflow: parse event → send commands → notify

What You Built

flowchart TB
    A[Splunk Webhook] --> B["&lt;your_name&gt;-unshut-int<br/>1. Parse device IP<br/>2. Send CLI commands<br/>3. Call notification"]
    B --> C[Remote Server<br/>R3 via SSH<br/>no shut]
    C --> D["&lt;your_name&gt;-notify2<br/>Webex Message"]

In the next lab, you will configure Cisco Workflows to have cognitive agentic intelligence, where it determines the next steps instead of you defining what commands to run. We will also leverage Cisco IQ's remote device connectivity (formerly known as CX RADKit) to simplify managing devices across the estate.

Updated at 2026-03-18 16:54:41