Arista Network Orchestration

Michiel Saelen

This use case shows an example of DataMiner orchestrating an Arista core network with different types of end devices. It is important that the VLANs are configured correctly on all the interfaces to ensure that the IP flows can reach the correct destination. The cleanup of the VLANs is also important, as this ensures that the flow does not reach unwanted destinations or use bandwidth on other interfaces that are not part of the service. In this solution, there are two physically separate core networks (A and B). The end devices in this solution are CISCO Nexus, CISCO ASR, and Aperi Chassis.

USE CASE DETAILS

This is an example of a dual-path service definition used in the solution. As you can see, the end devices (source and destination) are split up into multiple resource blocks. This is to cope with the different types of end devices. For example, the application block is optional and is only applicable to the Aperi Chassis devices. The application can be a simple pass-through, encoding or decoding application. The core network is represented by a single (virtual) resource block. The system will reserve capacity on all used interfaces in the core network. Resources for the available interfaces in the Arista network are automatically created by the Automation engine. DataMiner will identify and book a route in the network during the booking creation.

With the custom booking wizard, operators can create a new booking with minimal effort. They first need to configure the VLAN settings for the different paths (A and/or B).

Then they need to configure the source and destination interfaces for the A and/or B path.

DataMiner will automatically select a path in the network for which the interfaces still have sufficient bandwidth available. Once the bookings have been created, the Details button gives operators a quick and easy way to get an overview of the path selected by DataMiner.

This is the visual overview of the booked service. In the service overview, operators can easily see the status of the interfaces of the end devices, and if needed they can dive into the interfaces of the core network.

When more details are needed, they can focus on one network path by selecting that network path in the visual overview.

The logging of the bookings is done in a uniform way, so that it is easy for operators to search for specific words (e.g. “attempt”). Operators can also enable debug logs for a booking to see the raw commands that are used to configure the interfaces. As you can see in the logs, some actions are executed with a maximum wait time. This means that the action will be executed after that wait time unless that same action has already been executed during the wait time. This has been implemented to prevent multiple bookings from doing heavy actions at the same time (e.g. saving the running config to the startup config).