Traffic Matrix Workflow

The Traffic Matrix capability in Planner enables you to create a detailed traffic matrix by capturing real-time telemetry data from your production network. Routing Director utilizes this real-time telemetry data from your network and provides a detailed view of traffic patterns across multiple routing scenarios. Understanding these metrics allows you to simulate traffic scenarios and predict how changes will impact network performance.

Routing Director allows you to gather link utilization metrics, RSVP-TE tunnels, and SR policy utilization metrics, while importing a production network. Routing Director later uses this data to measure the volume of data transmitted over time and compares it to the maximum capacity of the interface. This offers insights into hourly and daily traffic patterns and facilitates further analysis.

Similarly, Routing Director allows you to gather tunnel-related metrics while importing a production network. Routing Director later uses this data to analyze traffic distribution and efficiency.

The traffic matrix provides the data necessary to compute how much of a network's capacity is being used. It is essential for network planning and optimization, providing insights into capacity planning, trend analysis, and path optimization. By utilizing inputs such as topology models and interface traffic statistics, you can generate realistic traffic matrices, which is crucial for preparing for future network loads. It also facilitates trend analysis through historical traffic data, allowing you to identify patterns and predict future network behavior.

Note: We create demands modeled on the telemetry that we collect using the Segment Routing Traffic Engineering (SR-TE) or Resource Reservation Protocol- Traffic Engineering (RSVP-TE) tunnel statistics.

To generate and utilize traffic matrix:

Note: This workflow is not applicable if you import a network model by uploading a file in JSON or .gz format.

Import a live network with data. For more information, see Create a Network Model.

Note: If you want to edit an already imported network model, select the model and click the edit (pencil) icon, then select an option: Traffic/Demand Generation to modify statistics generation, Import from File to upload a new JSON file if there are large-scale configuration changes, or Import Stats from File to update only the traffic statistics, and make the necessary changes. For more information, see Edit a Network Model.
Load the statistics file.
On the Working Model page, select the model that you imported and click More > View Stats. The View Stage page appears.
Select the statistics file that you want to load and click Load Traffic/Build Demand.
(Optional) Manage the statistics file. You can view the list of statistic files and its details in the table, export, or delete the statistics file. For more information, see About the View Stats Page.

After you load a statistic file, Routing director uses the link utilization and tunnel-related data from the production network that you have imported and analyze traffic distribution and efficiency. You can view the following on your offline network:

View link utilization data in the network information table of the Link tab (Planning > Networks > Offline Models > Model-Name > Open). For more information see, About the Link Tab (Planner).
View tunnel traffic on the Tunnel tab (Planning > Networks > Offline Models > Model-Name > Open). For more information see, About the Tunnel Tab (Planner).

Note: You can only view the last 30 days of traffic data as the retention period is 30 days (by default). To modify the default retention period in VictoriaMetrics, do the following:

Fetch the existing retention period using the command: kubectl get sts vmstorage-victoria-metrics-cluster2 -n northstar -o yaml | grep retentionPeriod

The output displays the existing retention period in days.
Update the retention period to a desired value using the command: kubectl patch vmcluster victoria-metrics-cluster2 -n northstar --type merge -p '{"spec":{"retentionPeriod":"Xd"}}', where X represents the number of days.
Repeat Step 1 to verify if the retention period has been updated to the new value.

Since the retention period affects the cluster, the associated pods restarts automatically.