Network Automation with Nokia and Red Hat OpenShift

Contributions to this post were provided by Mohammad Zaman, Nokia SDN/Automation Engineer and Prateek Prabhudesai, Nokia FSS Solution Architect

When building and managing a data center, applying changes across multiple solutions can be time-consuming and prone to human error. Not to mention updating infrastructure management records when you complete the changes. Days of doing this manually are long gone. Today, the GSP Experience Center (GSPx) powered by the Advanced Technology Center (ATC) has deployed a new data center fabric using Nokia network architecture and the Nokia Event Driven Automation (EDA) platform.

Introduction to Nokia Event-Driven Automation

Nokia's Event-Driven Automation is a cloud-native, event-driven datacenter network management platform designed to operate modern datacenter networks with confidence, speed and scale. Unlike conventional methods like managing devices one by one, Nokia's EDA treats the network as a single system, continuously observing for topology, configurations, any changes and collecting telemetry data to ensure it behaves exactly as intended. Applying the concepts of intent-based network with automation and real-time validation, Nokia's EDA turns complex network changes into safe, predictable operations, reducing risk during deployment and eliminating human errors.

Nokia's EDA goes beyond automation into intelligent operations by leveraging AIOps and agentic AI, which correlate live network data, change history, and events to detect issues early and explain what is happening in the network. Using AI-based natural language operators can query the network, identify the root cause, and generate validated recommendations.

Data center fabric management 

Designing and operating a modern data center network is no longer about simply pushing configurations. It's about expressing intent, maintaining reliability, and continuously validating outcomes as the network evolves. This is where Nokia's Event-Driven Automation jumps in and connects the dots from day-0 design, day-1 deployment phase, all the way to day-2 operations and continuously monitoring the state of every element of the network infrastructure, whether it's an operator-induced configuration change, hardware change or failure and changes in the networks due to protocols.

Nokia's EDA simplifies the complexity of data center networks by applying the concepts of intent-based networking, validation, automation and closed-loop operations into a single, coherent operating model. Every network modification is executed as a transactional change, which is applied consistently across the entire data center fabric, eliminating partial updates leading to config drifts. The risk of human error and associated network downtime is mitigated by tracking every change or deviation in the network with EDA's built-in version control feature, which provides a history of what changed, when, and why, along with a deviation detection system. Nokia's EDA enforces validation through pre- and post-checks, ensuring intent is preserved, and network behavior remains predictable and consistent. If unexpected configurations occur, the rollback feature returns the entire data center network to a known-good state with a single click, reducing operational risk and troubleshooting time.  Reliability is the forefront of any datacenter network to which Nokia's EDA further de-risks using the built-in digital sandbox that creates a digital twin of your live network, allowing operators to simulate changes and failure scenarios before pushing any changes to production.

Modern data center operations rely on tight integration among networks, infrastructure inventory, and applications/compute platforms. With Nokia's EDA built-in App Store, you can download easy-to-install plugins like Netbox, Red Hat OpenShift, VMware vCenter/NSX, Kafka, ServiceNow, Prometheus, and OTEL with a single click, using a no-code approach. In the later section, we will see how easy it is to integrate with Netbox as a single source of truth for racks, devices, and IP Addressing, while the OpenShift plugin provides real-time application events, enabling the data center network to align automatically without human intervention.

Red Hat OpenShift integration 

One of the many features of Nokia EDA is the ability to manage network changes to hybrid cloud platforms like Red Hat OpenShift as part of the network automation process. To make this possible, the EDA application store built into the user interface provides an application for the Cloud Connect plugin. Let's take a look at the plugin's integration with Red Hat OpenShift by using the Nokia EDA Documentation. 

Cloud Connect OpenShift requirements

• Red Hat OpenShift 4.16+ (WWT tested 4.20.x)
• Install and configure the NMState Operator in OpenShift
• Configure a NodeNetworkConfigurationPolicy (NNCP) to enable listening for LLDP on network interfaces connected to an EDA-managed switch using the following example:

apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
name: enable-listen-lldp
spec:
desiredState:
    interfaces:
    - name: eno0
    lldp:
        enabled: true

• Configure a NNCP for one of the following supported Container Network Interface (CNI) plugins. Please note, that linux bridge and OVN-Kubernetes localnet secondary networks are not currently supported with this plugin.
  • MACVLAN
  • IPVLAN
  • SR-IOV / Dynamic SR-IOV

Install the Nokia Event Driven Automation Operator

After deploying Cloud Connect and setting up the service account in EDA, the next step is to deploy the operator in the Red Hat OpenShift environment, where network automation will take place.

• From the Red Hat OpenShift console, under Ecosystem > Software Catalog, search for eda in the search bar. The OpenShift operator should appear as a tile.

• Click the tile to open the operator details. If the stable channel is not shown by default, click the drop-down and select the Stable version, followed by selecting version 5.0.0.  Click Install to subscribe to the operator.

• Review the operator installation details and change the namespace from the default to eda-connect-k8s-controller (by creating a new project), as this namespace is configured later during the secret and controller config setup. Click Install.

• When the installation completes, click View Operator. Click on Create Instance in the tile for Connect Controller Config

• The default YAML is displayed, but edits will be necessary to complete the connection. Click Create.

kind: ConnectControllerConfig
apiVersion: config.eda.nokia.com/v1
metadata:
  labels:
    app.kubernetes.io/name: operator
  name: connectcontrollerconfig
  namespace: eda-connect-k8s-controller
spec:
  connectPluginName: 'k8s-controller-plugin'
  controllerImagePullSecret: 'eda-k8s-image-secret' #previously created per the Nokia docs
  edaNamespace: eda #change to the namespace in EDA
  heartBeat: '10'
  logLevel: 'debug'
  skipTLSVerify: false
  tlsCertificateData: '<INSERT>'
  tlsEnabled: true

• If successful, the status of the instance in OpenShift will show sync: SyncDone and the new connection will appear on the EDA UI.

Configure OpenShift for the EDA Operator

Once the operator is installed, the next step is to configure OpenShift to support the various operational modes of the plugin in your environment. Nokia's EDA plugin supports three specific features: Transparent, Connect Network Definition (CND) and Network Attachment Definition (NAD) annotation. 

Operational Mode Support

• The Transparent function of the EDA operator is utilized to either create a new bridge domain in EDA, or associate it with an existing bridge domain for each NAD.
• A Connect Network Definition defines bridge domain associations to the Network Attachment Definitions.
• Network Attachment Definition annotation is to identify existing bridge domains to associate with the NAD. Below is an example NAD that has the annotation to a Trunked VLAN bridge domain in EDA.  For bridges without trunk the annotation would be listed without the VLAN ID.

Bridge domain annotation

connect.eda.nokia.com/bridgedomain: <eda-bridge-domain-name> 

Bridge domain with VLAN trunk annotation

connect.eda.nokia.com/bridgedomain: <eda-bridge-domain-name>:<vlan-id>

NAD example

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    connect.eda.nokia.com/bridgedomain: ocp-bridge:100
  name: macvlan-100
  namespace: default
spec:
  config: '{
      "cniVersion": "0.3.1",
      "name": "macvlan-100",
      "type": "macvlan",
      "master": "bond0.100",
      "mode": "bridge"
    }'

CND example

apiVersion: connect.eda.nokia.com/v1
kind: ConnectNetworkDefinition
metadata:
  name: cnd01
  namespace: default
spec:
  subnets:
    - name: "eda-subnet1"
      linkedBridgeDomain: ocp-bridge
      networkAttachmentDefinitions:
        - name: default/macvlan-100
          trunkVlans:
            - 100

After successful creation of the CND and NAD definitions in OpenShift, the Nokia EDA administrator should be able to see the creation of new bridge domains (or labels added to existing ones). In addition, the OpenShift hosts' network interfaces that automatically connect to the new VLAN bridge domain appear in the Connect Interface list of the UI.

Connected Interface has a label to a newly created bridge domain, allowing the interface to pass traffic on it.

Netbox Labs integration

Netbox Labs is a platform that combines data center infrastructure management (DCIM) with IP address management under a single open source product. Products like Red Hat Ansible, Terraform and Nokia EDA all provide integration with Netbox Labs to manage changes directly to Netbox using direct API calls. 

The EDA Netbox app found in the EDA store enables synchronization of EDA resources for consistency between the DCIM and EDA. To get started with the integration process, we install the app from the EDA user interface. Here again we're using Nokia's documentation for the integration steps.

Netbox system requirements

• Create a web hook for EDA
• Create an Event Rule
• Create an API Token
• Configure User Permissions

Event-driven cable sync, Nokia EDA to NetBox

-Contributions provided by Chase Frederick, WWT Solutions Architect

A common operational gap is keeping physical connections and associated documentation up to date after changes are made to a network's automated system. The target outcome for this workflow is straightforward: when an interface is created or attached to a server in Nokia EDA, NetBox should automatically reflect an established connection between the two endpoints. 

In NetBox, an established physical connection between two endpoints is represented by a Cable object, which can connect network interfaces and other types of termination. 

TopoLink is the event to drive NetBox Cabling 

EDA models network topology with TopoNode and Topolink resources, where Topolink represents a logical link between two nodes. TopoLinks are visible in the EDA UI under Topology > Links and can also be listed via kubectl. When EDA creates or updates a TopoLink with both endpoints populated, that object contains the information required to reconcile a NetBox Cable:

• Endpoint A device & interface name
• Endpoint B device & interface name
• An operational state that can be used for validation

Taking an inter switch link (ISL) as an example, which is simply a point-to-point link that connects two devices in a topology, we have the diagram:

Along with the link definitions:

linkTemplates:
  - name: isl 
    type: interSwitch 
    speed: 25G 
    encapType: "null"
    labels: 
      eda.nokia.com/role: interSwitch

links:
  - name: leaf1-spine1-1 
    template: isl 
    endpoints: 
      - local: 
          node: leaf1
          interface: ethernet-1-1
        remote: 
          node: spine1
          interface: ethernet-1-1

Resulting from the link definition above, EDA creates the following TopoLink resource and the two Interfaces resources  

apiVersion: core.eda.nokia.com/v1
kind: TopoLink
metadata:
  labels:
    eda.nokia.com/role: interSwitch
    eda.nokia.com/source-link: leaf1-spine1-1
  name: leaf1-spine1-1
  namespace: eda
spec:
  links:
    - local:
        interface: ethernet-1-1
        interfaceResource: leaf1-ethernet-1-1
        node: leaf1
      remote:
        interface: ethernet-1-1
        interfaceResource: spine1-ethernet-1-1
        node: spine1
      speed: 25G
      type: interSwitch
status:
  members:
    - interface: ethernet-1-1
      node: leaf1
      operationalState: up
    - interface: ethernet-1-1
      node: spine1
      operationalState: up
  operationalState: up

Together, this makes TopoLink a practical trigger for keeping NetBox connectivity aligned with the observed or intended states. The EDA documentation here is a great resource for reviewing EDA topology and TopoLinks in further detai,l where you can explore setups for other types of links such as Edge Links, Local LAG, and Multihome LAG.

Reference architecture

1. EDA creates and updates the TopoLink resources as the topology is defined and reconciled.
2. A webhook receiver service is deployed with two main responsibilities:
   1. Ingest the TopoLink State
   2. Translate TopoLink endpoints into NetBox Cable Objects
3. The receiver also normalizes endpoint identifiers:
   1. Device name mapping (EDA TopoNode name to NetBox Device name)
   2. Interface name mapping (EDA interface identity to NetBox Interface identity)
4. The receiver then calls the NetBox REST API to create or update a Cable between the two interface terminations, utilizing NetBox's cable model
5. NetBox remains continuously up to date without manual cable edits, and cable is traceable from endpoints when needed.

Optionally, EDA Notifier can be configured to send TopoLink alarm notifications to the same integration endpoint for operational visibility/troubleshooting.

NetBox capabilities in Nokia EDA & considerations

Nokia EDA's NetBox plugin provides a supported foundation for synchronizing EDA resources for consistency between DCIM and EDA. This can come in many forms, such as cabling synchronization discussed above, but the result is consistent regardless of use case, such that Nokia EDA generates trusted topology events and states, NetBox remains the documentation layer for physical connectivity, and a small integration service can reconcile connectivity in NetBox using a data model and the NetBox API.

Summary and next steps

We've shown how Nokia Event Driven automation supports integrating with Netbox and Red Hat OpenShift. There are several other plugins available in the EDA application store besides these two that are built to simplify operational management and deliver network automation where it counts. We utilize Nokia EDA in the GSP Experience Center (GSPx) to manage the core and AI network infrastructure in order to build new environments more quickly, securely and with the efficiency of automation to avoid potential manual errors in switch configurations. If you'd like to see Nokia Event Driven Automation in action, reach out to your WWT care team to schedule a demo!