Post-Mortem Assessment for End Users

Musab Muhammad
29 steps
7 minutes

## **Scenario: Post-Mortem – STP Instability Triggered by Path Cost Change** During the incident review, we found that the initial point of instability occurred on **US-BOS-SW1**, where a sudden change in the STP path cost caused Spanning Tree to recalculate its topology. This triggered temporary reconvergence events across several VLANs, leading to brief interruptions and inconsistent forwarding behavior. Since STP recalculations can propagate quickly, even a single cost mismatch on one interface can result in network-wide effects. In this post-mortem demonstration, our goal is to validate the issue on the root-cause device and then ensure the same condition does not exist anywhere else in the environment.\ \ **In this walkthrough we will be:**\ \ **Starting with a single-device map to inspect the root cause** We begin by isolating **US-BOS-SW1** on a dedicated map to examine its STP state, reviewing the interface where the cost value changed and confirming this as the initial trigger. This gives us a focused view of the affected switch before expanding the analysis. ### **Applying a Pre-built STP Intent to all IOS switches** Once the root-cause behavior is understood, we take the same STP intent and apply it across every IOS switch in the environment. This checks for: - path-cost consistency - unexpected role/state changes - topology change indicators - any similar mismatches elsewhere ### **Using Dashboards to review STP stability across the site** Dashboards help us visualize STP metrics across the network, making it easy to spot abnormal patterns or clusters of devices experiencing changes at the same time. This supports both validation and correlation with the original event timeline. ### **Generating automated post-mortem documentation** We complete the workflow by exporting a documentation package summarizing: - the detected STP path-cost change on US-BOS-SW1 - results of the STP intent across all switches - dashboard insights - CLI-based verification outputs This creates a complete post-incident analysis ready for ticketing, escalation, or audit purposes.

Let's start by looking at the original problem. First we navigate to the **Files** shortcut on the left

From here in the **Public** files we search for the "STP" issue map and either double click or select **Open**.

Here we want to understand the initial issue and what caused it.

To understand the underlying automation, we can open the **Intent** tab, go to **Map Intent** and then **Compare** to see the **Unchanged** lines and drill down into the modified lines.

Once we understand the original problem we can exit out

Let's go to a **New Map** and start the post mortem portion of the walkthrough

From here let's add the relevant devices to the map. From the top right corner go to **Device Group**.

In **Shared Device Groups**, look up "Cisco IOS Switches" and Draw Devices on Map.

Now that all relevant devices are on the map, go to the **Runbook** tab, click the plus and choose **Network Intent** and **Add**

In the **Network Intent** tab, **Add Existing Intent** and then choose **Standalone Intent**.

Here we search for "STP" and select the **Status Check**.

We first need to make sure that this is applicable to all devices so we will click the arrow and **Use Current Intent as Template**. Then **Run**.

Once we have the results we click on the **Action** button and **Show Results on Map**.

We want to edit the intent name to be more descriptive: "Post Mortem Assessment IOS Switches STP"

With results to the intent let's **Build Dashboard**. Dashboard name as "Post Mortem Assessment" and chart name as "STP Status Change" before **OK**

We can also run this on a schedule to make sure we are catching issues that might happen in the future. These will all update automatically into the dashboard.

We can open the dashboard to dig deeper and keep an eye on the results.

Start off by going into the edit dashboard view so we can make any necessary changes.

We want to add a few more dashboards to supplement the info for these devices. In our dashboard setting we simply **Select** a new dashboard, find the "Compliance" folder and add relevant dashboards to our own personal built dashboard.

We can also make some changes that will make the dashboard look neater. Go ahead and change the results to show **By Site** and unselect **Intent Results** summaries. This will make our dashboard look much neater.

Once you have taken a look at the dashboard and understand the layout, you can also export for others to see the results and underlying automations. From the top right corner **Export Dashboard to Document**, edit any settings necessary and **Create**. NetBrain will start creating the document.

In the mean time, we can add documentation to our runbook as well. Let's go back to the runbook and add a new node.

Choose the **Document** and **Add**.

We change the settings we want and **Create** the document. Before we do, the map will need to be saved so **Save and Continue**.

Choose the **Private** folder, change the name to something relevant and click **OK**.

There is an **AI Document** option that lets you change the document and customize it to your personal use.

Enter a prompt and **Create Document**.

Let's check back on the dashboard document now.

The document is now ready to download, or to modify with the AI.

## **Outcome of This Post-Mortem** At the end of this demonstration, we have: - Verified that no other similar devices share the same problem - Captured all findings in a structured, automated documentation package - Demonstrated how NetBrain accelerates post-incident analysis and prevents recurrence