PANTHEON.tech
  • About Us
    • Expertise
    • Services
    • References & Partners
    • Tools
  • Products
    • Orchestration
    • Automation
    • Network Functions
    • Security
  • Blog & News
  • Career
  • Contact
  • Click to open the search input field Click to open the search input field Search
  • Menu Menu
  • Link to LinkedIn
  • Link to Youtube
  • Link to X
  • Link to Instagram

The hidden costs of network downtime: Why automation is non-negotiable

November 13, 2024/in Hidden /by filip.sterling

A global outage of internet-related services seemed unimaginable – but possible, up until now. 

ITIC’s survey data shows that nearly 44% of mid-sized and large enterprises experience at least one significant unplanned outage annually. IDC’s analysis suggests that data center downtimes can average between 1.5 to 4.5 hours per incident.

One outage, which causes downtime in your data centers, can cause up to $594,000 of damages, on average.

Network automation has undergone a remarkable transformation since the early days of IT infrastructure, where manual configurations were the standard. As networks expanded and became more complex, the limitations of manual management became evident. 

The introduction of automation brought significant improvements: 

  • reducing human error
  • enhancing consistency
  • allowing for more efficient network operations

Tools, such as  SandWork offer sophisticated orchestration & automation capabilities, that streamline processes and enable scalable, robust network management – including root-cause analysis.

While root-cause analysis can explain the reason for errors, their source can be often attributed to manual network management. According to research conducted by NetBox Labs, around 57% of network operations are still performed manually. As a result, companies become more vulnerable to human errors and inefficient time utilization.

Automation has shifted from a luxury to a necessity, providing the backbone for modern network infrastructures and ensuring seamless operations in increasingly complex environments.

Devastating costs

Downtime can impact your business financially due to loss of data As per consulting firm Gartner, network downtime costs $5600 or more/minute, i.e. more than $300,000 per hour. 

These numbers include lost sales, reduced worker productivity and damage to the company’s reputation.  For a business that relies on a constant network, even a momentary downtime can result in a large loss of cash and operations. 

This clear evidence indicates the necessity of network management solutions that decrease downtime and thus ensure business continuity. As networks become increasingly complicated, the expenses associated with downtime are only set to rise; network management solutions like SandWork can reduce such risks. 

Mitigate risks by using SandWork today

SandWork is a comprehensive solution designed to minimize network downtime and improve performance through advanced orchestration and automation.

By automating  NOS installations, device configurations, and ongoing monitoring, SandWork reduces human error and ensures your network consistently performs at its best. Its greenfield checks and global intent verification proactively identify and address issues before they escalate, reducing potential disruptions.

With lifecycle management features, SandWork keeps all network elements updated for increased reliability. This platform scales network demands automatically while minimizing downtime, helping you increase reliability and significantly reduce operational costs.

Start mitigating risks with SandWork today.

Manual network management – a thing of the past

November 13, 2024/in Hidden /by filip.sterling

The modern data center world is complex and huge. Such complexity and scale need new solutions to efficiently and securely manage dynamic environments. Even the notion of manually managing the network seems like a thing of the past. Investing in senior engineers or manual interventions yields nearly zero ROI. 

According to research conducted by NetBox Labs, around 57% of network operations are still performed manually in organizations where network automation projects have been marked as “completed.” Because of this, companies expose themselves to human-error and inefficient time spent.

Introducing SandWork, a modern orchestration, automation and assurance solution of PANTHEON.tech. SandWork is designed to optimize your network operations, delivering peak performance while minimizing operational overhead.

Embracing network orchestration

Manual network management is fraught with challenges that can hinder operational efficiency and scalability. Key issues include:

  • Risk of human error: Manual configurations and interventions are prone to mistakes, leading to devastating downtime and security vulnerabilities.
  • Inefficiency: Managing large-scale networks manually is time-consuming and labor-intensive, resulting in higher OPEX.
  • Limited scalability: As networks scale, manual management becomes increasingly impractical, struggling to keep up with the demands of modern infrastructure standards.
  • Inconsistent compliance: Ensuring consistent adherence to compliance and security standards manually is challenging and often unreliable.

Worries disappear with SandWork

But how do we resolve this? SandWork addresses these issues by offering a comprehensive suite of features that automate and streamline network management processes:

  • Intent-based network orchestration: Automates the deployment of network services based on predefined intents, reducing the complexity of manual configurations.
  • Network automation: Simplifies and accelerates routine network tasks, enhancing overall efficiency and reducing the likelihood of human error.
  • Assurance capabilities: Continuously monitors and validates network performance and compliance, ensuring optimal operation and security.

Adopting SandWork

Boost productivity by taking over mundane tasks. Your IT teams will praise you for it, as it frees them up to work on strategic initiatives, instead of dull maintenance. When the processes are automated, chances of human errors are minimized, which boosts the accuracy of the process. This ensures better organization of network architecture, and can grow without any increase in labor. 

Operational costs will immediately decrease since you will not need much manual supervision and intervention. What about improving security? We can achieve a secure network with automation to comply with checks and with robust security measures like role-based access control or RBAC.

SandWork features

SandWork is equipped with advanced features that cater to the needs of modern data centers:

  • Security & compliance: Integrates with existing security frameworks to ensure data centers remain secure and compliant with industry standards.
  • Fabric lifecycle management: Manages the entire lifecycle of data center fabrics, from design to operation, ensuring seamless transitions and compliance.
  • Zero touch provisioning: Minimizes manual intervention in device configuration and initiation, suitable for both new and existing deployments.
  • Telemetry & visibility: Provides real-time insights into network performance through extensive telemetry capabilities and comprehensive dashboards.

Future-proof your network with SandWork

The increasing demands on data centers are creating new challenges for scaling and management.  Would you like to continue to rely on manual intervention?

SandWork is a flexible and powerful system that supports the latest trends in network disaggregation and open source network operating system SONiC.

No more manual network management. 

With SandWork by PANTHEON.tech, the companies can tap into a new network. By automating and streamlining processes, SandWork makes managing the complexities of a modern data center simple and future-ready. 

When you adopt SandWork, your network infrastructure is ready for today’s needs and tomorrow’s challenges.

[Case Study] Broadcom’s adoption of SONiC to modernize enterprise data center network design

November 11, 2024/in Hidden /by filip.sterling

Broadcom’s use of SONiC switches in their network infrastructure is a great example of how open-source solutions, combined with modern network orchestration tools, can redefine data center operations. 


Key takeaways

  • Broadcom operates 9 data centers worldwide, largest located in Las Vegas, housing up to 4,500 network devices, and potential expansion to support up to 6,000 switches.
  • A bespoke orchestration tool allowed them to reduce operational costs significantly
  • SONiC helped Broadcom achieve requirements in scalability, robustness, cost-effectiveness, secure tenant segmentation, high performance, and automation

As Broadcom absorbed VMware’s operations, the company needed to replace a legacy three-tier architecture. The reason was simple – they were looking to expand, scale-up and improve their data center operations. Broadcom was looking for a solution that could scale easily, reduce costs, and increase overall operational effectiveness.


Who is Broadcom?

A global tech-leader specializing in semiconductor and infrastructure software solutions. The company invests approximately $5 billion annually in research and development, supporting its extensive operations across 9 data centers. With over 40,000 employees, Broadcom’s innovations power a wide range of applications, from smartphones and data center networking and industrial automation.


The clear choice was SONiC, an open-source, community-driven network operating system. In the end, SONiC allowed Broadcom to achieve the outlined goals, creating an efficient and scalable network. Other sectors should draw inspiration from building a resilient, future-proof infrastructure.

But why SONiC? 

Broadcom’s previous network was a conventional 3-tier model, which relied heavily on vendor-specific solutions. This mainly meant high licensing and maintenance costs. 

But let’s break down what a 3-tier architecture looks like:

  • Core layer: handles most of the traffic between devices
  • Aggregation/distribution layer: connects the core & access layer, while filtering, routing and controlling traffic. Broadcom used this layer to support failover and redundancy. 
  • Access layer: primarily provides a direct connection to network devices. 

Broadcom mentioned it was drawn to SONiC for its open-source flexibility, automation potential, and scalability. This radical step made them avoid vendor-locked and pricey platforms and enjoy everything SONiC has to offer.

But what does SONiC offer?

  • Vendor independence = lower costs

One of SONiC’s greatest appeals for Broadcom was the opportunity to break free from vendor lock-in. Their legacy system required proprietary vendor intervention, which not only came with recurring licensing fees but also limited their ability to adopt alternative, more cost-effective hardware options. 

SONiC’s adaptability also allowed Broadcom to integrate and scale its infrastructure quickly at a critical moment – as it acquired VMware’s data centers. 

  • Automation and even more reduced costs

Network automation was a central goal in Broadcom’s migration to SONiC. The previous system relied heavily on manual configuration, which was labor-intensive and prone to errors. With SONiC, Broadcom initially leveraged Ansible scripts to automate configuration tasks. 

The bespoke orchestration system would be rolled out by then, thus reducing the operational overhead. – Tobin Hawkshaw, Network Architect, Broadcom

As they became more advanced, they moved to a bespoke orchestration platform, significantly reducing manual interventions. Automation allowed Broadcom to minimize operational complexity, enabled fast deployment, updates, and streamlined maintenance. By automating repetitive tasks, you are freeing staff to focus on higher-value activities, and improve service response times.

  • Robustness agrees with growing demand

Broadcom expanded its data center drastically. Currently, they operate 9 data centers all over the world. The largest being the Las Vegas DC, with up to 4500 network devices. 

map dc bc

Source: Broadcom OCP SONiC Summit 2024

It became critical to support high-density traffic with a network architecture that could scale dynamically. The legacy system, with its 3-tier design, had limited flexibility, creating bottlenecks as traffic loads increased. 

SONiC enabled Broadcom to scale up or down based on demand, with efficient horizontal and vertical expansion options. SONiC’s scalability ensured that networks could expand without extensive re-architecture or increased operational costs.

  • Improved network resilience with reduced downtime 

The migration to SONiC included adopting EVPN VXLAN, which enabled Broadcom to isolate network traffic into distinct virtual segments, enhancing both security and reliability. By implementing these advancements in SONiC, Broadcom contributed back to the community, readying the platform for broader enterprise adoption.

Introducing these technologies boosted Broadcom’s team confidence in delivering uninterrupted services. Operations remained seamless even during hardware failures or maintenance windows.

Enhanced network security 

SONiC provided Broadcom with the ability to secure its network through a decentralized architecture. Instead of a single centralized firewall, which can be a point of failure, Broadcom adopted a distributed firewall strategy. This ensured that traffic across various segments could be monitored and controlled closer to its source. This decentralized approach allows for a more secure network design with fewer vulnerabilities.

Building a future-ready infrastructure

However, this is not the end of Broadcom’s SONiC endeavor. 

Broadcom plans to improve the bespoke orchestration system currently used, as well as upgrade to 1.6 Tbps to support its high-speed East-West traffic.

Broadcom’s ongoing efforts to expand SONiC’s footprint into its WAN and campus networks illustrate the potential to create a standardized, end-to-end infrastructure that is automated, flexible, and highly reliable. 

When, if not today?

Broadcom’s adoption of SONiC is a great example of how open-source solutions can transform traditional network infrastructure. By introducing a flexible, automated, and resilient network approach, Broadcom has set a new trend for modern data centers, with significant cost savings, scalability, and operational efficiency.

OpenDaylight Evolution – A Proposal by PANTHEON.tech

July 15, 2022/in Hidden /by PANTHEON.tech

As one of the leading and active community leaders, we are keen to realize the evolution of OpenDaylight to meet new use case demands. We have attached our “OpenDaylight Evolution” white paper for your consideration and would greatly appreciate any feedback and comments you may have.

This is an architectural proposal document, focused on how to increase OpenDaylight’s:

  • Scale,
  • Performance,
  • Availability,
  • Security,

promoting feedback and thought on how to evolve OpenDaylight.

We have also pulled together a short survey to gather your feedback and would very much appreciate your support to complete this.

OpenDaylight Evolution Whitepaper
StoneWork + GNS3

[Tutorial] StoneWork + GNS3 (Complete)

May 8, 2018/in Hidden /by PANTHEON.tech

PANTHEON.tech has made StoneWork available on the GNS 3 marketplace. This makes it easy for anybody to try out our all-in-one solution, which combines multiple cloud-native network functions from our CNF portfolio, in a separate environment.

This tutorial will give you the basics on how to set-up StoneWork in an environment, where you can safely test out interaction and its positioning within your (simulated) network.

The goal of this tutorial is to have a basic setup, where we will:

  • Setup StoneWork interface IP address
  • Set the status of StoneWork to UP
  • Verify the connection by pinging the address

Components

StoneWork is a solution which, thanks to its modular architecture, enables you to combine multiple CNFs from the CNF portfolio, using only one data-plane, to increase the overall throughput, while keeping rich functionality.

GNS3 emulates network software, so you can try different virtual or real appliances in a completely separate environment and simulate a complex network.

Requirements

  • GNS3 works optimally on Linux, so we will be using Ubuntu 20.04.2.0
  • Make sure to do follow the GNS3 Linux Install documentation, which also adds Docker CE
  • Download the appliance image for Alpine Linux, a minimalistic distribution for GNS3
  • Download the appliance image for StoneWork here.

Setup the Environment: StoneWork in GNS3

After setting up your Linux environment and installing GNS3 on your distro of choice,

  1. Create a new project. We will call this one StoneWork Demo Run.
  2. Go to File – Import appliance and import both Alpine Linux & StoneWork Mini files. They will be saved as templates.
  3. Install the appliances. The default option we used is Install the appliance on your local computer. GNS3 will then inform you, in which category the appliance will appear.
  4. You will find both appliances by clicking on the next to last button, Browse all devices, on the left-side toolbar of GNS3.
gns3 appliances

Here, we can find all the imported and default appliances in GNS3

5. Drag both Alpine Linux & StoneWork Mini to the environment in the middle. Wait for the appliances to finish downloading.

6. Under the button for Browse all devices, click on Add a link. You will now be able to link both appliances together, to create a connection.

7. Click on AlpineLinux-1, and select the only available interface – eth0. Then click on StoneWorkmini-1, and select eth0 as well.

8. Click on the green button in the horizontal toolbar, to start all appliances.

StoneWork + GNS3 - Running Appliances

Both appliances are running and green-lit

Congratulations! The topology is set up and we will now continue the setup, in order for Alpine Linux and StoneWork to be able to ping (send packets to) each other.

9. Right-click on AlpineLinux-1 and select Console.

10. In the console window, type in ip add to view the IP addresses linking towards Alpine Linux.

ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
7: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN qlen 1000
    link/ether b6:74:c3:ad:4f:a5 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::b474:c3ff:fead:4fa5/64 scope link 
       valid_lft forever preferred_lft forever

11. Then, add the following command to edit the IP address:

ip addr add 10.0.0.1/24 dev eth0

12. Verify the IP address by typing ip add again. The entire output should look like this:

/ # ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
7: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN qlen 1000
    link/ether b6:74:c3:ad:4f:a5 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::b474:c3ff:fead:4fa5/64 scope link 
       valid_lft forever preferred_lft forever

Verify Connection: StoneWork in GNS3

Important: You can access the console for Alpine Linux via Right Click – Console, but StoneWork is accessed via Right Click – Auxiliary Console. Something to keep in mind, while commanding both instances.

We want to connect the interface, as well as connect both appliances.

  1. We will need to set up the configuration of StoneWork via CLI. Right-click on StoneWorkmini-1 and select Auxiliary Console. The path to StoneWork config should be the same as below. The entire command should look like this:
    cat /etc/stonework/config/day0-config.yaml
  2. If you want to change the StoneWork config, you will need to edit this file. The file should look like this:
    vppConfig:
      interfaces:
      - name: "my-eth0"
        type: AF_PACKET
        enabled: false
        physAddress: "3e:af:13:8f:a5:ba"
        afpacket:
          hostIfName: "eth0"
      - name: "my-eth1"
        type: AF_PACKET
        enabled: false
        physAddress: "52:12:91:be:c7:00"
        afpacket:
          hostIfName: "eth1"
      - name: "my-eth2"
        type: AF_PACKET
        enabled: false
        physAddress: "46:89:d6:41:44:29"
        afpacket:
          hostIfName: "eth2"
      - name: "my-eth3"
        type: AF_PACKET
        enabled: false
        physAddress: "2a:f6:78:04:64:7f"
        afpacket:
          hostIfName: "eth3"
      - name: "my-eth4"
        type: AF_PACKET
        enabled: false
        physAddress: "76:3d:2f:56:22:0f"
        afpacket:
          hostIfName: "eth4"
    
  3. To edit the config, we will edit the file via VIM:
    vim /etc/stonework/config/day0-config.yaml
  4. On your keyboard, click the A key to edit the file.
  5. In the file, set my-eth0 set enabled to true (instead of the default false). This way we make sure, that the interface will be UP & running.
  6. Then, type I on your keyboard to insert the following lines into the config, under enabled: true:
    ipAddresses:
    - "10.0.0.2/24"
  7. Save changes with ESC – colon (:) – w
  8. To exit VIM, type ESC – colon – q
  9. To update the configuration in StoneWork itself, type in the following command:
    agentctl config update --replace /etc/stonework/config/day0-config.yaml

Verify Updated Config in StoneWork

We have successfully set up the configuration of StoneWork! Now, we will verify the update in StoneWork.

  1. Type in the following command to the Auxiliary console of StoneWorkmin-1:
    agentctl config history
  2. The output will look like this:
    # agentctl config history
      SEQ  TYPE            START  INPUT      OPERATIONS          RESULT  SUMMARY                
      0    status sync     44m    <none>     <none>                      <none>                 
      1    config replace  44m    30 values  CREATE:5            ok      CONFIGURED:5           
      2    status update   43m    1  values  CREATE:1            ok      OBTAINED:1             
      3    status update   43m    1  values  CREATE:1            ok      OBTAINED:1             
      4    status update   43m    1  values  CREATE:1            ok      OBTAINED:1             
      5    status update   43m    1  values  CREATE:1            ok      OBTAINED:1             
      6    status update   43m    1  values  CREATE:1            ok      OBTAINED:1             
      7    config replace  5m     35 values  CREATE:3, UPDATE:1  ok      CONFIGURED:4           
      8    status update   5m     2  values  CREATE:1, DELETE:1  ok      OBTAINED:1, REMOVED:1  
    / # 
    
  3.  To double-check the settings in the VPP data-plane, type in vppctl into the same Terminal window, then show int. You should see, that the State of eth0 is up
     vppctl
        _______    _        _   _____  ___ 
     __/ __/ _   (_)__    | | / / _ / _ 
     _/ _// // / / / _    | |/ / ___/ ___/
     /_/ /____(_)_/___/   |___/_/  /_/    
    
    vpp# show int
                  Name               Idx    State  MTU (L3/IP4/IP6/MPLS)     Counter          Count     
    host-eth0                         1      up          9000/0/0/0     rx packets                    16
                                                                        rx bytes                    1120
                                                                        drops                         16
                                                                        ip6                           16
    host-eth1                         2     down         9000/0/0/0     
    host-eth2                         3     down         9000/0/0/0     
    host-eth3                         4     down         9000/0/0/0     
    host-eth4                         5     down         9000/0/0/0     
    local0                            0     down          0/0/0/0
  4. To verify the IP address we’ve set up for StoneWork, type in show int addr :
    vpp# show int addr
    host-eth0 (up):
      L3 10.0.0.2/24
    host-eth1 (dn):
    host-eth2 (dn):
    host-eth3 (dn):
    host-eth4 (dn):
    local0 (dn):
    

    With everything set up correctly, we will make both appliances ping each other, to verify their connection.

Ping: StoneWork & Alpine Linux

The setup of our IP addresses looks like this:

  • Alpine Linux appliance (AlpineLinux-1): 10.0.0.1
  • StoneWork (StoneWorkmini-1): 10.0.0.2

Now, you can ping both ways with the following commands:

  • AlpineLinux-1: Open Console, type in ping 10.0.0.2
    / # ping 10.0.0.2
    PING 10.0.0.2 (10.0.0.2): 56 data bytes
    64 bytes from 10.0.0.2: seq=0 ttl=64 time=1.812 ms
    64 bytes from 10.0.0.2: seq=1 ttl=64 time=0.759 ms
    64 bytes from 10.0.0.2: seq=2 ttl=64 time=1.012 ms
    64 bytes from 10.0.0.2: seq=3 ttl=64 time=2.590 ms
    ^C
    --- 10.0.0.2 ping statistics ---
    4 packets transmitted, 4 packets received, 0% packet loss
    round-trip min/avg/max = 0.759/1.543/2.590 ms
  • StoneWorkmini-1: Open Auxiliary Console, type in vppctl, then ping 10.0.0.1
    vpp# ping 10.0.0.1
    116 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=2.6766 ms
    116 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=.8829 ms
    116 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=2.2815 ms
    116 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=3.2285 ms
    116 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=2.1995 ms
    
    Statistics: 5 sent, 5 received, 0% packet loss

Congratulations again! You have managed to set up StoneWork in GNS3. The purpose of this tutorial was to show you how to set up StoneWork in GNS3, in a separate environment, so you can test & play around with it.

Make sure to:

  • Contact us, if you are interested in StoneWork for commercial purposes. This demo showed a minimalistic distribution of StoneWork.
  • Check out CDNF.io for more CNFs

(Update, 5th of April 2021 – StoneWork is available on the GNS3 marketplace!)


by Július Milan & Filip Čúzy | Leave us your feedback on this post!

You can contact us here!

Explore our PANTHEON.tech GitHub.

Watch our YouTube Channel.

[Tutorial] Create & Use Containerized RNC Application

January 26, 2018/in Hidden /by PANTHEON.tech

The lighty.io RESTCONF-NETCONF application allows to easily initialize, start and utilize the most used OpenDaylight services and optionally add custom business logic.

We provide a pre-prepared Helm 2 & Helm 3 chart inside the lighty.io RNC application, which can be easily used for Kubernetes deployment.

This article tutorial shows how to deploy RNC applications with Helm and a custom local Kubernetes engine. Let us know what you thought of and missed in this tutorial!


Deploy RNC application with Helm 2

lighty.io releases to version 15.1.0 contain Helm charts supported only by Helm 2 and Kubernetes to version 1.21 or lower. Kubernetes in version 1.22 release removed support for networking.k8s.io/v1beta1 which is required for successful Helm chart build.

Deploy RNC app with local Kubernetes engine

For deploying the RNC application, we will use and show how to install the microk8s Local Kubernetes engine. Feel free to use any other of your favorite local Kubernetes engine which you have installed. You just need to meet the condition to use k8s versions 1.21 or lower.

1) Install microk8s with a snap. We will need to specify the version to 1.21 which uses k8s on version 1.21.

sudo snap install microk8s --classic --channel=1.21/stable
sudo usermod -a -G microk8s $USER
sudo chown -f -R $USER ~/.kube
2) Verify running microK8s instance
microk8s status --wait-ready
   microk8s is running
   high-availability: no
   datastore master nodes: 127.0.0.1:19001
   datastore standby nodes: none

3) Enable required add-ons

microk8s enable dns helm

4) Initialize Helm. In microk8s, it is required to change the repository and tiller image for a successful initialization

microk8s.helm init --stable-repo-url=https://charts.helm.sh/stable --tiller-image ghcr.io/helm/tiller:v2.17.0

5) Check if all required k8s pods are working correctly.

microk8s.kubectl get pods -n kube-system

5.1) If not, check the error messages inside pods and try to resolve problems to run them correctly.

microk8s.kubectl describe pod [FAILED_POD_NAME] -n kube-system

6) Add PANTHEON.tech repositories to your Helm and update

microk8s.helm repo add pantheon-helm-repo https://pantheontech.github.io/helm-charts/
microk8s.helm repo update

7) Deploy the RNC app at version 15.1.0 with Helm.

microk8s.helm install --name lighty-rnc-app pantheon-helm-repo/lighty-rnc-app-helm --version 15.1.0

8) Check if the RNC app was successfully deployed and the k8s pod is running

microk8s.helm ls
microk8s.kubectl get pods

Configuration for your RNC app

RNC application could be configured through the Helm values file. Default RNC app values.yaml file can be found inside lighty.io GitHub.

1) Set  RESTCONF port to 8181 through the –set flag

microk8s.helm install --name lighty-rnc-app pantheon-helm-repo/lighty-rnc-app-helm --set lighty.restconf.restconfPort=8181

2) Set the RESTCONF port with providing configured values.yaml file

2.1) Download the values.yaml file

2.2) Update the image to your desired version.

image:
name: ghcr.io/pantheontech/lighty-rnc
version: 15.1.0
pullPolicy: IfNotPresent

2.3) Update the RESTCONF port or any required changes in the values.yaml file.

2.4) Deploy the RNC app with the changed values.yaml file. Use upgrade if you have already deployed the RNC application.

microk8s.helm upgrade lighty-rnc-app pantheon-helm-repo/lighty-rnc-app-helm --values [VALUES_YAML_FILE]

Deploy RNC application with Helm 3

The current lighty.io Master contains an updated Helm chart compatible with Helm 3 and Kubernetes v1.22. This example will show how to deploy the RNC app application with Helm 3 which is definitely recommended.

Download lighty.io Master

For this example, we will use the Helm chart and Docker for the NETCONF Simulator located in the lighty.io master branch. We will modify the helm chart to download the latest version of the RNC docker image.

1) Download lighty.io from GitHub repository and checkout to master branch, or download the lighty.io master zip file

git clone https://github.com/PANTHEONtech/lighty.git
git checkout master

2) Move to the lighty-rnc-app-helm directory

cd lighty/lighty-applications/lighty-rnc-app-aggregator/lighty-rnc-app-helm/helm/lighty-rnc-app-helm

3) Change Docker image inside values.yaml file to:

image:
name: ghcr.io/pantheontech/lighty-rnc
version: latest
pullPolicy: IfNotPresent

Deploy RNC App w/ local Kubernetes engine

For deploying the RNC application, we will use and show how to install the microk8s Local Kubernetes engine. Feel free to use any other of your favorite local Kubernetes engine which you have installed.

1) Install microk8s with Snap

sudo snap install microk8s --classic
sudo usermod -a -G microk8s $USER
sudo chown -f -R $USER ~/.kube

2) Enable the required add-ons

microk8s enable dns helm3

3) Deploy the RNC app

microk8s helm3 install lighty-rnc-app ./lighty-rnc-app-helm/

4) Check if the RNC app was successfully deployed and k8s pods is running.

microk8s.helm3 ls
microk8s.kubectl get pods

Create testing device from lighty.io NETCONF simulator

For testing purposes, we will need some devices. PANTHEON.tech has already created a testing tool, that simulates NETCONF devices.

We will use this device and start it inside a Docker container. A Docker file can be found inside lighty.io, which can create an image for this simulated device.

1) Download the NETCONF simulator Docker file from lighty.io to a separate folder

2) Create a Docker image from the Docker file

sudo docker build -t lighty-netconf-simulator

3) Start the Docker container with a testing device at port 17830, or any other port, by changing the -p parameter.

sudo docker run -d --rm --name netconf-simulator -p17830:17830 lighty-netconf-simulator:latest

Test RNC application with simple CRUD operation on a device

This part will show a simple use case of how to connect a device and perform some basic CRUD operations on deployed RNC applications.

1) Check the IP assigned to k8s pod for RNC app. This IP will be used as a HOST_IP parameter in requests.

microk8s.kubectl get pod lighty-rnc-app-lighty-rnc-app-helm-548774945b-4tjvz -o custom-columns=":status.podIP" | xargs

2) Check the IP assigned to the Docker container. This parameter will be used as DEVICE_IP parameter in requests.

docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' netconf-simulator

3) Connect the simulated device to the RNC application

curl --request PUT 'http://[HOST_IP]:8888/restconf/data/network-topology:network-topology/topology=topology-netconf/node=new-node' \
--header 'Content-Type: application/json' \
--data-raw '{
    "netconf-topology:node": [
        {
            "node-id": "new-node",
            "host": [DEVICE_IP],
            "port": 17830,
            "username": "admin",
            "password": "admin",
            "tcp-only": false,
            "keepalive-delay": 0
        }
    ]
}'

4) Get device information from the RNC app. Check-in response if connection-status is “connected”

curl --request GET 'http://[HOST_IP]:8888/restconf/data/network-topology:network-topology/topology=topology-netconf/node=new-node'

# Response
{
    "network-topology:node": [
        {
            "node-id": "new-node",
            "netconf-node-topology:connection-status": "connected",
            "netconf-node-topology:username": "admin",
            "netconf-node-topology:password": "admin",
            "netconf-node-topology:available-capabilities": {
               ...
            },
            "netconf-node-topology:host": "[DEVICE_IP]",
            "netconf-node-topology:port": 17830,
            "netconf-node-topology:tcp-only": false,
            "netconf-node-topology:keepalive-delay": 0
        }
    ]
}

5) Write a new topology-id to simulate device data

curl --request PUT 'http://[HOST_IP]:8888/restconf/data/network-topology:network-topology/topology=topology-netconf/node=new-node/yang-ext:mount/network-topology:network-topology' \
--header 'Content-Type: application/json' \
--data-raw '{
    "network-topology:network-topology": {
        "topology": [
            {
                "topology-id": "new-topology"
            }
        ]
    }
}'

6) Get data from the simulated device

curl  --request GET 'http://[HOST_IP]:8888/restconf/data/network-topology:network-topology/topology=topology-netconf/node=new-node/yang-ext:mount/network-topology:network-topology'

# Response
{
    "network-topology:network-topology": {
        "topology": [
            {
                "topology-id": "new-topology"
            },
            {
                "topology-id": "default-topology"
            }
        ]
    }
}

7) Remove the device from the RNC application

curl --request DELETE 'http://[HOST_IP]:8888/restconf/data/network-topology:network-topology/topology=topology-netconf/node=new-node'

8) Device Logs: Logs from the device can be shown by executing the following command:

sudo docker logs [CONTAINER ID]

9) RNC Logs: Logs from the RNC app can be shown by executing the following command:

microk8s.kubectl logs [POD_NAME]

We hope you enjoyed this tutorial! If you are interested in commercial support or a custom lighty.io integration, make sure to contact us.

Let us know what you thought of this tutorial and what you missed!


by Peter Šuňa | Leave us your feedback on this post!

You can contact us here!

Explore our PANTHEON.tech GitHub.

Watch our YouTube Channel.

More @ PATHEON.tech

  • [What Is] VLAN & VXLAN
  • [What Is] Whitebox Networking?
  • [What Is] BGP EVPN?
© 2025 PANTHEON.tech s.r.o | Privacy Policy | Cookie Policy
  • Link to LinkedIn
  • Link to Youtube
  • Link to X
  • Link to Instagram
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage {vendor_count} vendors Read more about these purposes
View preferences
{title} {title} {title}
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage {vendor_count} vendors Read more about these purposes
View preferences
{title} {title} {title}
Scroll to top