Enterprises require workflows to understand internal processes, how they apply to different branches, and divide responsibility to achieve a common goal. Using a workflow enables to pick & choose, which models are required.

Although there are many alternatives, BPMN is a standard widely used across several fields to graphically depict business processes and manage them.

Notable, although underrated, are its benefits for network administrators. BPMN enables network device management & automation, without having to fully comprehend the different programming languages involved in each task.

What is BPMN?

The Business Process Model & Notation (BPMN) standard graphically represents specifics of business processes in a business process model. In cooperation with the Camunda platform, which provides its own BPMN engine, it can do wonders with network orchestration automation.

BPMN lets enterprises graphically depict internal business procedures and enables companies to render these procedures in a standardized manner. Using BPMN removes the need for software developers to adjust business logic since the entire workflow can be managed through a UI.

In the case of network management, it provides a level of independence, abstracted from the network devices themselves.

This logic behind how business processes are standardized as workflows is present in the Open Network Automation Platform (ONAP) as well.

What is ONAP?

ONAP is an orchestration and automation framework, featuring an open-source software concept, that is robust, real-time, policy-driven, for physical and virtual network functions.

ONAP allows network scaling and VNF/CNF implementations in a fully automated manner. Read our in-depth post on what ONAP is and how you can benefit from its usage. BPMN is implemented within ONAP via Camunda.

Camunda is an open-source platform, used in the ONAP Service Orchestrator – where it serves as one of the core components of the project to handle BPMN 2.0 process flows.

Relationship between ONAP & BPMN

The Service Orchestrator (SO) component, includes a BPMN Execution Engine. Two Camunda products are utilized within ONAP SO:

• Cockpit: View BPMN 2.0 workflow definitions
• Modeler: Edit BPMN 2.0 process flows

The SO component is mostly composed of Java & Groovy code, including a Camunda BPMN code-flow.

PANTHEON.tech circumvents the need for SO and uses the Camunda BPMN engine directly. This resulted in a project with SO functionality, without the additional SO components – sort of a microONAP concept.

Features: Camunda & BPMN

The business process modeling is a single action of network orchestration. As with any project integration, it is important to emphasize the project’s strong points, which enabled us to achieve a successful use case.

Benefits of Camunda/BPMN

• Automation: BPMN provides a library of reusable boxes, which make their use more accessible by avoiding/hiding unnecessary complexity
• Performant BPMN Engine: the engine provides good out-of-the-box performance, with a variety of operator/DevOps UI tools, as well as BPMN modeling tools
• User Interface: OOTB user interface, with the option of creating a custom user interface
• DevOps: easy manipulation & development of processes
• Scalability: in terms of performance tuning and architecture development for lots of tasks
• Interoperability: extensible components, REST integration, or script hooks for Groovy, JavaScript & more
• REST API: available for BPMN engine actions
• Exceptional Error Handling
  
• Scalability: tasks with high execution cadence can be externalized and be implemented as scalable microservices. That provides not only scalability to the system itself but can be applied to the teams and organizations as well
  
• Process tracking: the execution of the process is persisted and tracked, which helps with system recovery and continuation of the process execution in partial and complete failure scenarios.

What PANTHEON.tech had to mitigate is, for example, parallelism – running several processes at once. Timing estimation limits the high precision configuration of network devices. Imagine you want to automate a process starting with Task 1. After a certain time, Task 2 takes effect. Timers in BPMN however need manual configuration to tune the interval between jobs & processes.

Our deep dive into this topic resulted in a concept for automating network configurations in spine-leaf data centers, using a lightweight ONAP SO architecture alternative.

Use Case: Virtual Network Configuration in Spine-Leaf Data Centers

PANTHEON.tech has achieved, that the design of this use-cases custom architecture is fully functional and meets the required criteria – to fully adopt network automation in a demanding environment.

Our use-case shows how BPMN can be used as a network configuration tool in, for example, data centers. In other words – how ONAP’s SO and lighty.io could be used to automate your data center.

If you are interested in this use case, make sure to contact us and we can brief you on the details.

by Filip Gschwandtner | Leave us your feedback on this post!

You can contact us here!

Explore our PANTHEON.tech GitHub.

Watch our YouTube Channel.

PANTHEON.tech has made its data plane for managing cloud-native network functions, StoneWork, available on the GNS 3 marketplace. This makes it easy for anybody to try out our all-in-one solution, which can combine 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

Read the complete post after subscribing:

StoneWork | An IPSec Appliance

Our We have created a portfolio is steadily growing. Our latest addition is StoneWork.

Here, StoneWork enables you to securely and remotely access your management plane.

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.

One of the many features of StoneWork is IPSec, which we will talk about in this post.

StoneWork IPSec + SONiC

This case study briefly describes, how the StoneWork IPsec appliance can be used on your SONiC enabled switch to secure & tunnel your OOB management SONiC interface.

Stonework is part of our CNF portfolio. It is an enhanced VPP distribution, which serves as an all-in-one switch/router/firewall.

Stoneworks (IPSec) test setup by PANTHEON.tech

If you are interested in the deployment script, click here to contact us!

In this demonstration, two SONiC OS instances are provisioned to represent two IPSec gateways. But instead of actual physical switches, each SONiC OS runs inside a Docker container with a P4-simulated SAI behavioral model software switch ASIC underneath.

This P4 ASIC is also running as a separate container, to keep the emulated physical interfaces separated from kernel-space ports. A link between the ASIC and SONiC container is a network namespace reference /var/run/netns/sw_net that P4 ASIC expects to point to ASIC container from the filesystem of the SONiC container.

On top of that, there is a StrongSwan appliance running in a container, using the same network namespace as SONiC for the sake of AF_PACKET. In total there are three containers to represent one switch.

In-between the switches there is a “bridge” container, used only to capture traffic and verify that it is indeed encrypted. On the opposite side of switches, there are containers representing hosts – one is used as a TCP client, the other as a server.

What is SONiC?

SONiC is a Linux-based, network operating system, available as an open-source project, meant for network routers & switches.

The architecture is similar to that of OpenDaylight or lighty.io – it is composed of modules, on top of a centralized infrastructure, which is easily scalable.

Its main benefits are the usage of the Redis-engine infrastructure & placement of modules into Docker containers. The primary functional components are DHCP-Relay, PMon, SNMP, LLDP, BGP, TeamD, Database, SWSS, SyncD.

SONiC covers all the components needed for a complete L3 device. Its main use-case presents a cloud-data center, with the possibility of sharing software stacks among different platforms. Currently, over 100 platforms are officially supported.

An important concept of SONiC is that it does not interact with the hardware directly. Instead, its programs switch ASIC via the vendor-neutral Switch Abstraction Interface or SAI for short.

This approach, on one hand, allows maintaining vendor independence, while decoupling the network software and hardware. On the other hand, it creates boundaries on what can be performed with the underlying networking hardware.

At present, enterprises practice approaches in securing external perimeters of their networks. From centralized Virtual Private Networks (VPN), through access without a VPN to using solutions, such as EntGuard VPN.

For encryption, protection, security, meet EntGuard – the ultimate, enterprise VPN solution.

The most dangerous cyber-threats are those, which are not yet identified. Enterprises need to act proactively and secure access to their networks.

Contact us for more information!

Work-From-Home & Cybersecurity

We saw an increased need of working from home last year. But what was first a necessity, seems to stay as a popular alternative to working from an office.

That also means, that as an enterprise, you need to go the extra mile to protect your employees, your, and their data. A VPN will:

• Encrypt your internet traffic
• Protect you from data-leaks
• Provide secure access to internal networks – with an extra layer of security!

Encrypt – Secure – Protect.

With EntGuard VPN, PANTHEON.tech utilized years of working on network technologies and software, to give you an enterprise-grade product, that is built for the cloud.

With the world rapidly shifting towards virtual spaces, it is projected that the spending on cybersecurity will increase by 10% in 2021. EntGuard will save you costs, without compromising quality.

Built on WireGuard®

We decided to build EntGuard VPN on the critically-acclaimed WireGuard® protocol. The protocol focuses on ease-of-use & simplicity, as opposed to existing solutions like OpenVPN – while achieving incredible performance! Did you know that WireGuard® is natively supported in the Linux kernel and FD.io VPP since 2020?

WireGuard® is relied on for high-speeds and privacy protection. Complex, state-of-the-art cryptography, with lightweight architecture. An incredible combination.

Unfortunately, it’s not easy to maintain WireGuard® in enterprise environments, that’s why we have decided to bring you EntGuard, which gives you the ability to use WireGuard® tunnels in your enterprise environment.

EntGuard Highlights

• Supported server platforms: Linux
• Clients: Windows, Linux; Android, macOS
• Simple Management
• State-of-the-art Cryptography (WireGuard®)
• Built-In Roaming
• Container Ready
• Certification & Support Services
• Premium Features: Be the first to try out new features, such as – MFA, LDAP, Radius, end-station remote support, traffic monitoring, problem analysis and more!

About our CNFs

The PANTHEON.tech, cloud-native network functions portfolio keeps on growing. At the start of 2020, we introduced you to the project, which at the moment houses 18 CNF’s. Make sure to keep up-to-date with our future products, by following us and our social media!

Join us in reminiscing and reminding you, what PANTHEON.tech has managed to create, participate in, or inform about in 2020.

Project: CDNF.io

In the first quarter of the year, we have made our latest project, CDNF.io, accessible to the public. Cloud-native functions were long overdue in our portfolio and let me tell you – there are lots of them, ready to be deployed anytime.

We have prepared a series of videos, centered around our CNFs, which you can conveniently view here:

Perhaps you like to read more than hear someone explain things to you? We wrote a few posts on:

• The Road from PNFs, to VNFs, to CNFs
• Integrating Network Service Mesh with Cloud-Native Network Functions | by Milan Lenčo & Pavel Kotúček
• A Cloud-Native Firewall | by Filip Gschwandtner

Integration Scenarios

Apart from our in-house solutions, we have worked on demonstrating several scenarios with common technologies behind them: ServiceNow® & Cisco’s Network Services Orchestrator.

In terms of ServiceNow®, our posts centered around:

• Network Automation with ServiceNow® & OpenDaylight | by Miroslav Kováč
• Cloud-Native Firewall Orchestration with ServiceNow® | by Slavomír Mazúr

Cisco’s NSO got a nearly all-inclusive treatment, thanks to Samuel Kontriš, with a defacto NSO Guide on:

• NSO Integration w/ SDN-C (ONAP)
• NSO Integration w/ lighty.io
• Cisco Network Service Orchestrator

This includes two videos about the Network Service Orchestrator:

Open-Source Software Releases

We have made several projects available on our GitHub, which we regularly maintain and update. What stole the spotlight was the lighty.io NETCONF Device Simulator & Monitoring Tool, which you can download here.

PANTHEON.tech has also been active in adding new features to existing open-source projects, such as:

• Integrating memif with T-REX | by Július Milan
• Updating Swagger in OpenDaylight to OpenAPI 3.0

lighty.io, our open-source passion project, celebrated its 13th release, which also included a separate post highlighting improvements and changes. 

Thoughts, Opinions & Information

Since we did not want to exclude people who might not be that knowledgable about what we do, we have created a few series on technologies and concepts PANTHEON.tech is engaged in, such as:

• What is AF_XDP | by Marek Závodský
• The Difference Between Binding-Aware & Binding Independent
• What is SDN & NFV

We try to listen closely to what Robert Varga, the top-single contributor to the OpenDaylight source-code, has to say about OpenDaylight. That allowed us to publish opinion/informative pieces like:

• The Future of Karaf
• A Developers perspective on OpenDaylight Sodium
• Ultimate Guide to OpenDaylight | with Samuel Kontriš

Step into a new decade

We would like to thank everybody who does their part in working and contributing to projects in PANTHEON.tech, but open-source projects as well. 2020 was challenging, to say the least, but pulling together, makes us stronger – together.

Happy holidays and new years to our colleagues, partners, and readers – from PANTHEON.tech.

• Declarative: You will say what you want, but not how
• Imperative: You describe how to do something

Declarative Approach

Users will mainly use the declarative approach when describing how services should start, for example: “I want 3 instances of this service to run simultaneously”.

In the declarative approach, a YAML file containing the wished configuration will be read and applied towards the declarative statement. A controller will then know about the YAML file and apply it where needed. Afterwards, the K8s scheduler will start the services, where it has the capacity to do so.

Kubernetes, or K8s for short, lets you decide between what approach you choose. When using the imperative approach, you will explain to Kubernetes in detail, how to deploy something. An imperative way includes the commands create, run, get & delete – basically any verb-based command.

Will I ever manage imperatively?

Yes, you will. Even when using declarative management, there is always an operator, which translates the intent to a sequence of orders and operations which he will do. Or there might be several operators who cooperate or split the responsibility for parts of the system.

Although declarative management is recommended in production environments, imperative management can serve as a faster introduction to managing your deployments, with more control over each step you would like to introduce.

Each approach has its pro’s and con’s, where the choice ultimately depends on your deployment and how you want to manage it.

While software-defined networking aims for automation, once your network is fully automated, enterprises should consider IBN (Intent-Based Networking) the next big step.

Intent-Based Networking (IBN)

Intent-Based Networking is an idea introduced by Cisco, which makes use of artificial intelligence, as well as machine learning to automate various administrative tasks in a network. This would be telling the network, in a declarative way, what you want to achieve, relieving you of the burden of exactly describing what a network should do.

For example, we can configure our CNFs in a declarative way, where we state the intent – how we want the CNF to function, but we do not care how the configuration of the CNF will be applied to, for example, VPP.

For this purpose, VPP-Agent will send the commands in the correct sequence (with additional help from KVscheduler), so that the configuration will come as close as possible to the initial intent.

by Filip Gschwandtner | Leave us your feedback on this post!

Updated 11/05/2020: Our Unified Firewall Demo was updated with additional insight, as to how we achieved great results with our solution.

We differentiate generally between a hardware and software firewall. Software firewalls can reside in the userspace (for example, VPP) or the kernel space (for example, NetFilter). These serve as a basis for cloud-native firewalls. The main advantage of software firewalls is the ability to scale without hardware. This is done in the virtual machines or containers (Docker), where these firewalls reside and function from.

One traditional firewall utility in Linux is named iptables. It is configured via command-line and acts as an enforcer of rules and configuration of Netfilter. You can find a great how-to in the Ubuntu Documentation on configuring iptables, which is found pre-installed in most Linux distributions.

For a more performance-oriented firewall solution, you can turn to the evergreen, Vector Packet Processing framework and Access Control Lists (ACLs).

Our CNF Project offers such a cloud-native function – Access Control List (ACL)-based firewall between CNF interfaces with FD.io VPP dataplane and Ligato management plane.

If we have sparked your interest in this solution, make sure to contact us directly. Until then, make sure to watch our CNF project closely – there is more to come!

Firewall Solutions

Multiple solutions mean a wide variety of a user or company is able to choose from. But since each firewall uses a different API, we can almost immediately see an issue with the management of multiple solutions. Some APIs are more fully-fledged than others while requiring various levels of access (high level vs. low-level API) and several layers of features.

At PANTHEON.tech, we found that having a unified API, above which a management system would reside, would make a perfectly balanced firewall.

Cloud-Native: We will be using the open-source Ligato, micro-services platform. The advantage is, Ligato being cloud-native.

Implementation: The current implementation unifies the ACL in FD.io‘s VPP and the NetFilter in the Linux Kernel. For this purpose, we will be using the open-source VPP-Agent from Ligato.

Separate Layers: This architecture enables us to extend it to any configurable firewall, as seen below.

Layer Responsibilities: Computer networks are divided into network layers, where each layer has a different responsibility. We have modeled (proto-model) a unification API and translation to technology-specific firewall configuration. The unified layer has a unified API, which it translates and sends to the technology-specific API. The current implementation is via the VPP-Agent Docker container.

Ligato and VPP-Agent: In this implementation, we make full-use of VPP-Agent and Ligato, via gRPC communication. Each firewall has an API, modeled like a proto-model. This makes resolving failures a breeze.

Resolving Failures: Imagine that, in a cloud, software can end with a fatal error. The common solution is to suspend the container and restart it. This means, however, that you need to set up the configuration again or synchronize it with an existing configuration from higher layers.

Fast Reading of Configurations: There is no need to load everything again throughout all layers, up until the concrete firewall technology. These can be often slow in loading the configuration. Ligato resolves this via the configurations residing in the Ligato platform, in an external key-value storage (ETCD, if integrated with Ligato).

How did we do this?

We created this unifying API by using a healthy subset of all technologies. We preferred simplified API writing – since, for example in iptables, there can be lots of rules which can be written in a more compact way.

We analyzed several firewall APIs, which we broke down into basic blocks. We defined the basic filters for packet traffic, meaning the way from which interface, which way the traffic is flowing. Furthermore, we defined rules, based on the selector being the final filter for rules and actions, which should occur for selected traffic (simple allow/deny operation).

There are several types of selectors:

• L2 (according to the sources MAC address)
• L3 (IP and ICMP Selector)
• L4 (Only TCP traffic via flags and ports / UDP traffic via ports)

The read/write performance of our Unified Firewall Layer solution, was tested using VPP and iptables (netfilter), at 250k rules. The initial tests ended with poor writing speed. But we experimented with various combinations and ended up putting a lot of rules into a few rule-groups.

That did not go as planned either.

A deep analysis showed that the issue is not within Ligato, since task-manager showed that the VPP/Linux kernel was fully working. We made an additional verification for iptables, only by using go-iptables library. It was very slow when adding too many rules in one chain. Fortunately, iptables provides us with additional tools, which are able to export and import data fast. The disadvantage is, that the export format is poorly documented. However, I did an iptables export and insert of data closely before the commit, and imported the data back afterward.

# Generated by iptables-save v1.6.1
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:DOCKER - [0:0]
:DOCKER-ISOLATION-STAGE-1 - [0:0]
:DOCKER-ISOLATION-STAGE-2 - [0:0]
:DOCKER-USER - [0:0]
:testchain - [0:0]
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN
<<insert new data here>>
COMMIT

Our Open-Source Commitment

We achieved a speed increase for 20k rules in 1 iptable chain – from 3 minutes and 14 seconds to a few seconds. This showed a perfect performance fix for the VPP-Agent, which we committed to the Ligato VPP-Agent repository.

This also benefited updates, since each updated has to be implemented as a delete and create case (recreated each time). I made it as an optional method with a custom number of rules, from which it applies. Using too few rules can result in great speed with the default approach (via API iptables rule). Now, we have a solution for using a lot of rules as well. Due to the lack of detailed documentation of the iptables-save output format, I decided on turning this option off by default.

The results of the performance test are:

• 25 rule-groups x 10000 rules for each rule-group
• Write: 1 minute 49 seconds
• Read: 359.045785ms

Reading is super-fast, due to all data being in the RAM in the Unified Layer. This means, that it’s all about one gRPC call with encoding/decoding.

If we have sparked your interest in this solution, make sure to contact us directly.