AF_XDP featured image / logo

[What Is] XDP/AF_XDP and its potential

What is XDP?

XDP (eXpress Data Path) is an eBPF (extended Berkeley Packet Filter) implementation for early packet interception. Received packets are not sent to kernel IP stack directly, but can be sent to userspace for processing. Users may decide what to do with the packet (drop, send back, modify, pass to the kernel). A detailed description can be found here.

XDP is designed as an alternative to DPDK. It is slower and at the moment, less mature than DPDK. However, it offers features/mechanisms already implemented in the kernel (DPDK users have to implement everything in userspace).

At the moment, XDP is under heavy development and features may change with each kernel version. There comes the first requirement – to run the latest kernel version. Changes between the kernel version may not be compatible.

XDP Packet Processing by IO Visor

IO Visor description of XDP packet processing

XDP Attachment

The XDP program can be attached to an interface and can process the RX queue of that interface (incoming packets).  It is not possible to intercept the TX queue (outgoing packets), but kernel developers are continuously extending the XDP feature-set. TX queue is one of the improvements with high interest from the community.

XDP program can be loaded in several modes:

  • Generic – Driver doesn’t have support for XDP, but the kernel fakes it. XDP program works, but there’s no real performance benefit because packets are handed to kernel stack anyways which then emulates XDP – this is usually supported with generic network drivers used in home computers, laptops, and virtualized HW.
  • Native – Driver has XDP support and can hand then to XDP without kernel stack interaction – Few drivers can support it and those are usually for enterprise HW
  • Offloaded – XDP can be loaded and executed directly on the NIC – just a handful of NICs can do that

XDP runs in an emulated environment. There are multiple constraints implied, which should protect the kernel from errors in the XDP code. There is a limit on how many instructions one XDP can receive. However, there is a workaround in the Call Table, referencing various XDP programs that can call each other.

The XDP emulator checks the range of used variables. Sometimes it’s helpful – it doesn’t allow you to access packet offset higher than already validated by packet size.

Sometimes it is annoying because the packet pointer can be passed to a subroutine, where access may fail with out of bounds access even if the original packet was already checked for that size.

BPF Compilation

Errors reported by the BPF compiler are quite tricky, due to the program ID compiled into byte code. Errors reported by that byte code usually do not make it obvious, which C program part it is related to.

The error message is sometimes hidden at the beginning of the dump, sometimes at the end of the dump. The instruction dump itself may be many pages long. Sometimes, the only way how to identify the issue is to comment out parts of the code, to figure out which line introduced it.

XDP can’t (as of November 2019):

One of the requirements was to forward traffic between host and namespaces, containers or VMs. Namespaces do the job properly so, XDP can access either host interfaces or namespaced interfaces. I wasn’t able to use it as a tunnel to pass traffic between them. The workaround is to use a veth pair to connect the host with a namespace and attach 2 XDP handlers (one on each side to process traffic). I’m not sure, whether they can share TABLES to pass data. However, using the veth pair mitigates the performance benefit of using XDP.

Another option is to create AF_XDP socket as a sink for packets received in the physical interface and processed by the attached XDP. But there are 2 major limitations:

  • One cannot create dozens of AF_XDP sockets and use XDP to redirects various traffic classes into own AF_XDP for processing because each AF_XDP socket binds to the TX queue of physical interfaces. Most of the physical and emulated HW supports only a single RX/TX queue per interface. If there’s one AF_XDP already bound, another one will fail. There are few combinations of HW and drivers, which support multiple RX/TX queues but they have 2/4/8 queues, which doesn’t scale with hundreds of containers running in the cloud.
  • Another limitation is, that XDP can forward traffic to an AF_XDP socket, where the client reads the data. But when the client writes something to AF_XDP, the traffic is going out immediately via the physical interface and XDP cannot see it. Therefore, XDP + AF_XDP is not viable for symmetric operation like encapsulation/decapsulation. Using a veth pair may mitigate this issue.

XDP can (as of November 2019):

  • Fast incoming packet filtering. XDP can inspect fields in incoming packets and take simple action like DROP, TX to send it out the same interface it was received, REDIRECT to other interface or PASS to kernel stack for processing. XDP can alternate packet data like swap MAC addresses, change ip addresses, ports, ICMP type, recalculate checksums, etc. So obvious usage is for implementing:
  • Filerwalls (DROP)
  • L2/L3 lookup & forward
  • NAT – it is possible to implement static NAT indirectly (two XDP programs, each attached to own interface, processing and forwarding the traffic out, via the other interface). Connection tracking is possible, but more complicated with preserving and exchanging session-related data in TABLES.

by Marek Závodský, PANTHEON.tech


AF_XDP

AF_XDP is a new type of socket, presented into the Linux Kernel 4.18, which does not completely bypass the kernel, but utilizes its functionality and enables to create something alike DPDK or the AF_Packet.

DPDK (Data Plane Development Kit) is a library, developed in 2010 by Intel and now under the Linux Foundation Projects umbrella, which accelerates packet processing workloads on a broad pallet of CPU architectures.

AF_Packet is a socket in the Linux Kernel, which allows applications to send & receive raw packets through the Kernel. It creates a shared mmap ring buffer between the kernel and userspace, which reduces the number of calls between these two.

At the moment XDP is under heavy development and features may change with each kernel version. There comes the first requirement, to run the latest kernel version. Changes between the kernel version may not be compatible.

AF_XDP Basics described by redhat

As opposed to AF_Packet, AF_XDP moves frames directly to the userspace, without the need to go through the whole kernel network stack. They arrive in the shortest possible time. AF_XDP does not bypass the kernel but creates an in-kernel fast path.

It also offers advantages like zero-copy (between kernel space & userspace) or offloading of the XDP bytecode into NIC. AF_XDP can run in interrupt mode, as well as polling mode, while DPDK polling mode drivers always poll – this means that they use 100% of the available CPU processing power.

Future potential

One of the potentials in the future for an offloaded XDP (being one of the possibilities of how an XDP bytecode can be executed) is, that such an offloaded program can be executed directly in a NIC and therefore does not use any CPU power, as noted at FOSDEM 2018:

Because XDP is so low-level, the only way to move packet processing further down to earn additional performances is to involve the hardware. In fact, it is possible since kernel 4.9 to offload eBPF programs directly onto a compatible NIC, thus offering acceleration while retaining the flexibility of such programs.

Decentralization

Furthermore, all signs lead to a theoretical, decentralized architecture – with emphasis on community efforts in offloading workloads to NICs – for example in a decentralized NIC switching architecture. This type of offloading would decrease costs on various expensive tasks, such as the CPU itself having to process the incoming packets.

We are excited about the future of AF_XDP and looking forward to the mentioned possibilities!

For a more detailed description, you can download a presentation with details surrounding AF_XDP & DPDK and another from FOSDEM 2019.

Update 25/11/2019: We have upgraded this page to a guide on XDP & AF_XDP.


You can contact us at https://pantheon.tech/

Explore our Pantheon GitHub.

Watch our YouTube Channel.

cloud-native definition

[What Is] Cloud-Native and its future

The methodology of cloud-native enables applications, as we know them, to function in a cloud environment and utilize it to the fullest. But what does the cloud offer, that wasn’t here before?

Forecast: Cloudy

Services that function in the cloud are characterized by an unlimited presence – they are accessed from anywhere, with a functional connection and are located on remote servers. This can curb costs, as you do not have to create and maintain your servers in a dedicated, physical space. If you do, even more costs can arise from the expertise needed to be built within your company to support such a solution.

Cloud-native apps are designed from the ground-up to be present in the cloud and use its potential to the fullest.

Apps re-imagined

The cloud-native approach breaks down apps into microservices. One app contains a set of services, which are independent of each other – one failure does not break the entire app. If paired with service standards like Kubernetes, containers can automatically heal failures once they occur. Furthermore, cloud-native apps can use a variety of languages to build each service. This is possible due to the specified independence of each service. There is a clear separation by API

Apps are packed into containers. Containers guarantee, that all components which are needed for the application in these container images are present and ready to be immediately deployed within a container runtime. Since these containers or blocks, function as one, users can utilize horizontal scaling capabilities, based on actual demands.

Since services are split-up and independent of each other, cloud-native apps can apply a continuous delivery approach. Here, different teams can collaborate on different parts of the container, and manage a continuous development, independent development and improvement of services in the container without redeploying the whole environment.

Industry shift towards clouds

It is hard to move on from an approach, which has proven itself over the years and became a standard. However, the cloud-native approach can offer unmatched scalability & agility for the end-user, unlike traditional applications.

Integration is made easier due to the enormous involvement of the open-source community, namely the Cloud Native Computing Foundation. This foundation covers most of the major projects present in common cloud architectures, including Kubernetes.

If your company is looking forward to adapting to these changes, stay tuned for what PANTHEON.tech can offer on this front.

lighty.io Akka Clustering ability

lighty.io is Cloud-Native Ready, are you?

lighty.io, at its core, manages network devices in a virtualized network. It is therefore crucial, that it works as a robust, and at the same time, stable tool. When deployed in modern networks, lighty.io itself can not guarantee stability and an error-free network.

PANTHEON.tech engineers have managed to extend OpenDayligh/lighty.io capabilities with Akka Cluster. This fulfills requirements for dynamic, horizontal scaling of lighty.io applications.

Welcome, lighty.io, to the world of cloud-native & micro-services. 

lighty.io & containers

Thanks to lighty.io removing Karaf and using Java SE as its run-time, we have made it one of the most lightweight SDN controllers in the world. This makes not only lighty.io‘s but OpenDaylight’s components usable in the world of containers & micro-services.

We have further managed to include horizontal scaling in lighty.io and are proud to announce, that auto-scaling, up & down functionality in lighty.io Akka Cluster is available. 

Akka

Akka is a set of open-source libraries, which allow for designing scalable, resilient systems and micro-services. Its strongest points are:

  • Multi-threaded behavior
  • Transparency: in regards to communication between components and systems using them
  • Clustered architecture: for designing a scalable, on-demand and reactive system

This means, that Akka addresses common situations in any virtualized architecture – components failing without responding, messages getting lost in transit and fluctuating network latency. The key to fully utilizing Akka is combining devices into clusters.

Cluster

As we mentioned earlier, networks can experience down-time. This may be due to the collapse of one machine, and this breaking the entire chain of events. Running applications as clusters, instead of single instances, avoid this situation.

Imagine, grouping objects with a similar purpose together as Clustering. If one of the cluster members fails, another member can come to the rescue and continue in its function. This happens in an instance – the end-user doesn’t even notice that anything happened.

Requests are evenly distributed across the cluster members, thanks to load-balancing. One device won’t be overloaded with requests, as these are shared within the cluster.

If the amount of connected devices is low, the cluster will decrease in size and use fewer resources. The cluster adapts to the needs of the network and can increase or decrease in size. Due to this balance, hardware efficiency is guaranteed.

Clusters can, in some cases, fail, but potentially do not require manual intervention. If used with tools like Kubernetes, potential outages in the cluster are automatically healed. This can be a lifesaver in critical situations.

PANTHEON.tech @ Open Networking Summit Europe ’19

Here at PANTHEON.tech, we are proud to be a corporate member of the Linux Foundation and one of the sponsors of this the Open Networking Summit Europe 2019.

We were in attendance for this year’s Open Networking Summit Europe in Belgium, Antwerp. The organization was, as always, handled by the Linux Foundation Networking.

As is tradition, we were participating, networking and presenting our know-how to potential business-partners & like-minded open-source enthusiasts.

Belgium Meets Open-Source

The conference was held in Antwerp, Belgium, right next to the Antwerp Zoo. The Flanders Meeting & Convention Center does continue in the animal theme of the surroundings and contains halls filled with whale skeletons, historical zoo photos & other themed objects. It was a wonderful, spacious place, ideal for a conference of this size. We were also more than pleased, that so many attendees wore lanyards with our logo.

Part of our booth at ONS was a presentation of two demos:

  • CNF Designer: Design and visualize your CNFs and export the settings. In this demo, people used PANTHEON.tech instances of NAT44, DHCP, Ligato and ACL CNFs.
  • Raspberry Pi Access Point: We have managed to run a VPP instance on a Raspberry Pi acting as a WIFI access point, send flow data using IPFIX to Elastiflow, and visualize it in Kibana

Orange x PANTHEON.tech

PANTHEON.tech developer Samuel Kontriš was busy at a demo-stand, in cooperation with Orange, named “TransportPCE: SDN Controller & Simulators for WDM Optical Networks (OpenDaylight, FD.io, Open ROADM, lighty.io)“. TransportPCE supports both the original ODL Karaf (OSGi) and lighty.io build (without any proprietary component). We had the chance to present why lighty.io should be the right choice for your SDN controller.

It was a great opportunity to show why lighty.io deserves attention. Many people have come to ask about lighty.io and afterwards, I gladly referred them further to our PANTHEON.tech booth staff.

TransportPCE is an open-source implementation of an optical SDN controller, officially integrated into OpenDaylight Fluorine and Neon releases.

Edge Computation Offloading by PANTHEON.tech

We continued with a session/talk, lead by PANTHEON.tech VP of Engineering Miroslav Mikluš, called “Edge Computation Offloading”. Its premise was the promise of 5G and the high expectations it has set up. In his talk, he showed how Radio Access Network could be used to offload tasks from the end-user device to the edge.

 

We have shown a demo of a client application (running on an Android mobile device), that can execute compute-intensive tasks on an edge compute node. K8s has been used on a RAN site to host specialized container application, based on TensorFlow. It had received pre-trained models to classify image content.

Miroslav Mikluš - ONS Session "ECO"

As always, we appreciate the organizational skills of the Linux Foundation and would like to thank LFN, Orange and our colleagues who participated at this year’s Open Networking Summit in Antwerp.

We are proud to be working on several open-source projects, centered not only around the Linux Foundation Networking. PANTHEON.tech is looking forward to overcoming all challenges, which will ultimately contribute to the open-source community and possibly, change networking forever.

 

PANTHEON.tech at ONS19 LinkedIn ad

[Announcement] PANTHEON.tech @ ONS EU 2019!

PANTHEON.tech will be attending this years Open Network Summit Europe in Belgium, Antwerp. We are looking forward to this event, organized by the Linux Foundation Networking & Linux Network Foundation.

As is tradition, we will be participating, networking and presenting a variety of projects, ideas, and our skills to potential business-partners & like-minded open-source enthusiasts.

You will be able to meet with:

  • COO Štefan Kobza 
  • VP of Engineering Miroslav Mikuš
  • Technical Business Development Manager Martin Varga
  • Software Engineer Samuel Kontriš
  • Technical Copywriter Filip Čúzy

Come talk to us @ Booth B8

Our demo with Orange

This year, we will be presenting a demo (as part of the LF Networking Demo section), in a partnership with Orange. The presentation itself is named:

TransportPCE: SDN Controller & Simulators for WDM Optical Networks (OpenDaylight, FD.io, Open ROADM, lighty.io)

TransportPCE is an open-source implementation of an optical SDN controller officially integrated into OpenDaylight Fluorine and Neon releases. It allows managing optical WDM devices, compliant with the Open ROADM specifications, the current only open standard that focuses on WDM devices full interoperability.

Along with the controller implementation, TransportPCE also embeds a device simulator, derived from the FD.io project honeycomb. A full functional test suite was built on top of this simulator for CI/CD sake. The demo will simulate a small WDM network topology with FD.io honeycomb and shows how to create and delete a WDM service with the TransportPCE test suite. The design of TransportPCE relies on a modular approach that leverages the classical OSGi OpenDaylight framework.

This design allows considering more deployment scenarios than the monolithic WDM network management systems classically found on commercial products. lighty.io is an alternative framework to OSGI for OpenDaylight, that is developed by PANTHEON.tech and is partially open-sourced. It is thought for deployment scenarios, that require streamlined applications with minimalistic resource consumption (e.g. microservices).

TransportPCE supports both OSGi and lighty.io (without any proprietary component). The demo will propose a comparison of OSGi and lighty.io.

Who is PANTHEON.tech?

PANTHEON.tech is a software research & development company, located in Bratislava, Slovakia. Our focus lies on network technologies and the development of software, with over 17 years of experience.

We were part of developing OpenDaylight components: MD-SAL, YANG Tools, Clustering, NETCONF, RESTCONF, SNMP, OpenFlow, BGP & PCEP. We look forward to helping speed up the development of open-source networking technology & participating in the SDN revolution.

lighty.io BGP EVPN Route Reflector featured image

[lighty.io] BGP EVPN Route-Reflector

In our previous blog post, we have introduced you with a Border Gateway Protocol Route-Reflector (BGP-RR) function in SDN controller based on lighty.io. In this article, we’re going to extend the BGP function of an SDN controller with an EVPN extension in the BGP control-plane.

Functionality

This article will discuss BGP-EVPN functions in an SDN controller and how the lighty.io BGP-function can replace existing legacy route-reflectors running in service provider’s WAN/DC networks. BGP-EVPN provides:

  • Advanced Layer 2 MAC and Layer 3 IP reachability information capabilities in control-plane
  • Route-Type 2: advertising MAC/IP address, instead of traditional MAC learning mechanisms
  • Route-Type 5: advertising the IP prefix subnet prefix route

We’re going to show you a BGP-EVPN IP subnet routing use-case

A BGP-EVPN control-plane can also co-exist with various data-planes, such as MPLS, VXLAN, and PBB.

Use-case: Telecom Data-Center

In this blog, we’re going to show you the BGP-EVPN control-plane working together with VXLAN data-plane. The perfect use case for this combination would be a telecom data-center.

Virtual Extensible LAN (VXLAN) is an overlay technology for network virtualization. It provides Layer 2 extension over a shared Layer 3 underlay infrastructure network, by using the MAC address in an IP/User Datagram Protocol (MAC in IP/UDP) tunneling encapsulation. The initial IETF VXLAN standards defined a multicast-based flood-and-learn VXLAN without a control plane.

It relies on data-based flood-and-learn behavior for remote VXLAN tunnel endpoint (VTEP) peer-discovery and remote end-host learning. BGP-EVPN, as the control plane for VXLAN, overcomes the limitations of flood-and-learn mechanism.

Test Bed

Test Bed Visualization

In this demo, we will use:

  • five Docker containers & three Docker networks.
  • Docker auto-generated user-defined bridge networks with mask /16
  • Arista’s cEOS software, as we did in our previous demo

Remember, that an Arista cEOS switch creates an EtX port when starting up in the container, which is bridged to EthX port in Docker.

These auto-generated EtX ports are accessible and configurable from cEOS Cli and on start are in default L2 switching mode. This means they don’t have an IP address assigned.

Well, let’s expand our previous demo topology with few more network elements. Here is a list of Docker containers used in this demo:

  • leaf1 & leaf2: WAN switch & access/node
  • host1 & host2: Ubuntu VM
  • BGP-RR: BGP-EVPN Route Reflector

Here is a list of Docker user-defined networks used in this demo:

  • net1 (172.18.0.0/16): connects leaf1 & host1
  • net2 (172.19.0.0/16): connects leaf2 & host2
  • net3 (172.20.0.0/16: connects leaf1, leaf2 & bgp-rr

Our Goal: Routing

At the end of this blog, we want to be able to reach IP connectivity between virtual machine host1 and host2. For that, we need BGP to advertise loopback networks and VLAN information between nodes.

In this example, we are using one AS-50.

To demonstrate route-reflector EVPN functionality leaf1 & leaf2 doesn’t make an IBGP pair but creates a pair with lighty-BGP instead. This will act as a route-reflector. In VxLAN configuration we don’t set up flood vtep. This information should redistribute Route Routing to peers.

The container with lighty-BGP MUST NOT be used as forwarding node since it doesn’t know manipulate the routing table.

Configuration

This demo configuration is prepared and tested on Ubuntu 18.04.2.

Docker Configuration

Before you start, please make sure that you have Docker (download instructions, use version 18.09.6 or higher) & Postman downloaded and installed.

1. Download lighty-BGP Docker image. PANTHEON.tech has its own

https://hub.docker.com/u/pantheontech

 

sudo docker pull pantheontech/lighty-rr:9.2.0-dev

2. Download the Docker image for Arista cEOS (we used v. 4.21.0F)

sudo docker import cEOS-lab.tar.xz ceosimage:4.21.0F

3. Download the Ubuntu image from DockerHub

sudo docker pull ubuntu:latest

4. Check the Docker images, successfully installed in the repository

sudo docker images

Preparing the Docker Environment

1. Create Docker networks

sudo docker network create net1
sudo docker network create net2
sudo docker network create net3

2. Check all Docker networks, that have been created

sudo docker network ls

3. Create containers in Docker

sudo docker create --name=bgp-rr --privileged -e INTFTYPE=eth -it pantheontech/lighty-rr:9.2.0-dev
sudo docker create --name=leaf1 --privileged -e CEOS=1 -e container=docker -e EOS_PLATFORM=ceoslab -e SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 -e ETBA=1 -e INTFTYPE=eth -i -t ceosimage:4.21.0F /sbin/init
sudo docker create --name=leaf2 --privileged -e CEOS=2 -e container=docker -e EOS_PLATFORM=ceoslab -e SKIP_ZEROTOUCH_BARRIER_IN_SYSDBINIT=1 -e ETBA=1 -e INTFTYPE=eth -i -t ceosimage:4.21.0F /sbin/init
docker create  --privileged --name host1 -i -t ubuntu:latest /bin/bash
docker create  --privileged --name host2 -i -t ubuntu:latest /bin/bash

4. Connect containers to Docker networks

sudo docker network connect net1 leaf1
sudo docker network connect net1 host1
sudo docker network connect net2 leaf2
sudo docker network connect net2 host2
sudo docker network connect net3 bgp-rr
sudo docker network connect net3 leaf1
sudo docker network connect net3 leaf2

5. Start all containers

sudo docker start leaf1
sudo docker start leaf2
sudo docker start host1
sudo docker start host2
sudo docker start bgp-rr

6. Enable permanent IPv4 forwarding in cEOS containers

sudo docker exec -it leaf1 /sbin/sysctl net.ipv4.conf.all.forwarding=1
sudo docker exec -it leaf2 /sbin/sysctl net.ipv4.conf.all.forwarding=1

7. Check, whether all Docker containers have started successfully

sudo docker container ls

Optional: Use this, if you’re looking for detailed information about running Docker containers (X is replaced by device/host number)

sudo docker container inspect [leaf[X] | bgp-rr | host[X]]

Preparing Ubuntu Environment

1. Get into the machine (X is replaced by device/host number)

sudo docker exec -it host[X] bash

2. Update the machine

apt-get update

3. Install the required packages

apt-get install iproute2
apt-get install iputils-ping

4. Exit the Docker Container (CTRL+D). Repeat steps 2 & 3.

Arista cEOS Switch configuration

Now, we will configure Arista cEOS switches. We will split the configuration of Arista cEOS Switches in several steps.

Click here for full configurations of Arista switches ‘leaf1‘ & ‘leaf2‘.

Ethernet interfaces & connectivity check

1. Go into the Arista switch leaf1

sudo docker exec -it leaf1 Cli

2. Set Privilege, and go to configure-mode

enable
configure terminal

3. Setup the switch’s name

hostname leaf1

4. Setup Ethernet interface. If you use more devices than your devices could be connected in another Ethernet

interface ethernet 2
no switchport
ip address 172.20.0.2/16

5. Check if BGP-RR is reachable from the configured interface.

  • When you can’t ping ‘BGP-RR’, check if ‘leaf1′ and ‘BGP-RR’ are located in the same Docker network, or delete the previous step and try it on another Ethernet interface.
ping 172.20.0.4 source ethernet2

6. Repeat Step 5 for ‘leaf2′ & go into the Arista switch leaf2

sudo docker exec -it leaf2 Cli
enable
config t
hostname leaf2
interface ethernet 2 
no switchport
ip address 172.20.0.3/16
ping 172.20.0.4 source ethernet2

Configuring the Border Gateway Protocol

We will have identical configurations for ‘leaf1′ & ‘leaf2′. Exceptions will be highlighted in the instructions below.

1. Enable BGP in Arista switch

  • If you are still in the previous settings interface, go to the root of Arista configuration with repeating the “exit” command.
service routing protocols model multi-agent
ip routing

2. Setup

  • For ‘leaf2’, use the Router-ID ‘router-id 172.20.0.3
router bgp 50
router-id 172.20.0.2
neighbor 172.20.0.4 remote-as 50
neighbor 172.20.0.4 next-hop-self
neighbor 172.20.0.4 send-community extended
redistribute connected
redistribute attached-host

3. Setup EVPN in BGP

address-family evpn
neighbor 172.20.0.4 activate

Configuring VxLAN Interface & VLAN

We will have identical configurations for leaf1 & leaf2. Exceptions will be highlighted in the instructions below.

1. Enable VLAN with ID 10.

  • Make sure that this command is typed in root of Arista and not in BGP
  • If you are still in the BGP configuration, use the command ‘exit’
vlan 10

2. Configure loopback 0, which will be used as a VTEP (VxLAN tunnel endpoint) for VxLAN.

  • In ‘leaf2’, use IP ‘10.10.10.2/32’, instead of IP ‘10.10.10.1/32’
interface loopback 0
ip address 10.10.10.1/32

3. Configure VxLAN Interface

  • Here we’ll set up loopback 0 as a VTEP and configure VNI (VXLAN Network Identifier) to 3322.
interface Vxlan1
vxlan source-interface Loopback0
vxlan udp-port 4789
vxlan vlan 10 vni 3322
vxlan learn-restrict any

4. Assign Ethernet interface to VLAN

interface Ethernet 1
switchport mode access
switchport access vlan 10

5. Share loopback 0 to BGP-RR

  • In ‘leaf2‘, use IP ‘10.10.10.2/32’ instead of ‘10.10.10.1/32’
router bgp 50
address-family ipv4
network 10.10.10.1/32

6. Configure VLAN in BGP

  • Here we share the information about VLAN to BGP-RR
router bgp 50
vlan 10
rd 50:3322
route-target both 10:3322
redistribute learned

lighty.io & BGP Route Reflector

In this part, we will add Border Gateway Protocol configuration into the lighty.io-BGP.

There is a lot to configure, so crucial parts are commented to break it down a little.

If we want to see the logs from lighty.io, we can attach them to the started container:

sudo docker attach bgp-rr

We can start the BGP-RR container with the command:

sudo docker start bgp-rr --attach

to see logs from the beginning. Afterward, send a PUT request to BGP-RR. We should see the following messages in the logs.

More RESTCONF commands can be found here.

Verify device state

Now, we will check if all configurations were set up successfully. We will also check if VxLAN is created and the Virtual PCs are able ‘ping’ each other.

1. Check if EVPN BGP peering is established

leaf1(config)#sh bgp evpn summary
BGP summary information for VRF default
Router identifier 172.20.0.2, local AS number 50
Neighbor Status Codes: m - Under maintenance
  Neighbor         V  AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State  PfxRcd PfxAcc
  172.20.0.4       4  50                 3         6    0    0 00:00:09 Estab  0      0
leaf2(config)#sh bgp evpn summary
BGP summary information for VRF default
Router identifier 172.20.0.3, local AS number 50
Neighbor Status Codes: m - Under maintenance
  Neighbor         V  AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State  PfxRcd PfxAcc
  172.20.0.4       4  50               267       315    0    0 00:01:16 Estab  1      1

If your devices are in the state ‘Connected‘ or ‘Active‘, then you have checked this right after you sent a request to lighty.io. Usually, it takes, at most, one minute to establish a connection.

If you still see this state, then there could be something wrong in the BGP configuration. Please check your configuration in Arista CLI, by typing command ‘show running-config‘ and compare it with the full Arista configuration above.

After you verify the Arista configuration, then there could be a problem in the BGP-RR container. This can be fixed restarting the BGP-RR container.

2. Check ip route for available loopbacks from other devices

leaf1(config)#sh ip route
VRF: default
Codes: C - connected, S - static, K - kernel,
       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
       R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
       O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
       NG - Nexthop Group Static Route, V - VXLAN Control Service,
       DH - DHCP client installed default route, M - Martian,
       DP - Dynamic Policy Route
 
Gateway of last resort is not set
 
 C      10.10.10.1/32 is directly connected, Loopback0
 B I    10.10.10.2/32 [200/0] via 172.20.0.3, Ethernet2
 C      172.20.0.0/16 is directly connected, Ethernet2
leaf2(config)#sh ip route
VRF: default
Codes: C - connected, S - static, K - kernel,
       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
       R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
       O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
       NG - Nexthop Group Static Route, V - VXLAN Control Service,
       DH - DHCP client installed default route, M - Martian,
       DP - Dynamic Policy Route
 
Gateway of last resort is not set
 
 B I    10.10.10.1/32 [200/0] via 172.20.0.2, Ethernet2
 C      10.10.10.2/32 is directly connected, Loopback0
 C      172.20.0.0/16 is directly connected, Ethernet2

3. Check the VxLAN interface, if it creates and contains VTEP

leaf1#sh interfaces vxlan 1
Vxlan1 is up, line protocol is up (connected)
  Hardware is Vxlan
  Source interface is Loopback0 and is active with 10.10.10.1
  Replication/Flood Mode is headend with Flood List Source: EVPN
 Remote MAC learning via EVPN
  VNI mapping to VLANs
  Static VLAN to VNI mapping is
    [10, 3322]      
  Note: All Dynamic VLANs used by VCS are internal VLANs.
        Use 'show vxlan vni' for details.
  Static VRF to VNI mapping is not configured
  Headend replication flood vtep list is:
    10 10.10.10.2    
  VTEP address mask is None
leaf2(config)#sh interfaces vxlan 1
Vxlan1 is up, line protocol is up (connected)
  Hardware is Vxlan
  Source interface is Loopback0 and is active with 10.10.10.2
  Replication/Flood Mode is headend with Flood List Source: EVPN
 Remote MAC learning via EVPN
  VNI mapping to VLANs
  Static VLAN to VNI mapping is
    [10, 3322]      
  Note: All Dynamic VLANs used by VCS are internal VLANs.
        Use 'show vxlan vni' for details.
  Static VRF to VNI mapping is not configured
  Headend replication flood vtep list is:
    10 10.10.10.1    
  VTEP address mask is None

If you don’t see IP in the section ‘Headend replication flood vtep list is:‘, then the BGP-RR container is not started correctly. This problem can be fixed by removing BGP-RR container and starting it again.

Restarting BGP-RR container

1. Stop the container

sudo docker stop bgp-rr

2. Remove BGP-RR container

sudo docker rm bgp-rr

3. Create a new container

sudo docker create --name=bgp-rr --privileged -e INTFTYPE=eth -it pantheontech/lighty-rr:9.2.0-dev

4. Connect BGP-RR to docker network

sudo docker network connect net3 bgp-rr

5. Start the container again

sudo docker start bgp-rr

Optional: If you want to see logs from light.io, attached them to the container:

sudo docker attach bgp-rr

Testing IP Connectivity

If everything worked out, we can test IP connectivity in a virtual PC.

1. Open Virtual PC host1

sudo docker exec -it host1 bash

2. Setup IP address for this device

ip addr add 31.1.1.1/24 dev eth1

3. Perform the same configuration at host2

sudo docker exec -it host1 bash
ip addr add 31.1.1.2/24 dev eth1

4. Try to ping host2 to host1

ping 31.1.1.1
root@e344ec43c089:/# ip route
default via 172.17.0.1 dev eth0
31.1.1.0/24 dev eth1 proto kernel scope link src 31.1.1.2
172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.5
172.19.0.0/16 dev eth1 proto kernel scope link src 172.19.0.3
 
root@e344ec43c089:/# hostname -I
172.17.0.5 172.19.0.3 31.1.1.2
 
root@e344ec43c089:/# ping 31.1.1.1
PING 31.1.1.1 (31.1.1.1) 56(84) bytes of data.
64 bytes from 31.1.1.1: icmp_seq=1 ttl=64 time=114 ms
64 bytes from 31.1.1.1: icmp_seq=2 ttl=64 time=55.5 ms
64 bytes from 31.1.1.1: icmp_seq=3 ttl=64 time=53.0 ms
64 bytes from 31.1.1.1: icmp_seq=4 ttl=64 time=56.1 ms
^C
--- 31.1.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 53.082/69.892/114.757/25.929 ms

When we go back to the Arista switch, we can check routed MAC address information.

leaf1#sh mac address-table
          Mac Address Table
------------------------------------------------------------------
 
Vlan    Mac Address       Type        Ports      Moves   Last Move
----    -----------       ----        -----      -----   ---------
  10    0242.211d.8954    DYNAMIC     Et1        1       0:00:54 ago
  10    0242.8b29.b7ea    DYNAMIC     Vx1        1       0:00:40 ago
  10    0242.ac12.0003    DYNAMIC     Et1        1       0:00:14 ago
  10    0242.ac13.0003    DYNAMIC     Vx1        1       0:00:13 ago
  10    ce9a.ca0c.88a1    DYNAMIC     Et1        1       0:00:54 ago
Total Mac Addresses for this criterion: 5
 
          Multicast Mac Address Table
------------------------------------------------------------------
 
Vlan    Mac Address       Type        Ports
----    -----------       ----        -----
Total Mac Addresses for this criterion: 0
leaf2#sh mac address-table
          Mac Address Table
------------------------------------------------------------------
 
Vlan    Mac Address       Type        Ports      Moves   Last Move
----    -----------       ----        -----      -----   ---------
  10    0242.211d.8954    DYNAMIC     Vx1        1       0:00:48 ago
  10    0242.8b29.b7ea    DYNAMIC     Et1        1       0:01:03 ago
  10    0242.ac12.0003    DYNAMIC     Vx1        1       0:00:22 ago
  10    0242.ac13.0003    DYNAMIC     Et1        1       0:00:22 ago
  10    ce9a.ca0c.88a1    DYNAMIC     Vx1        1       0:00:48 ago
Total Mac Addresses for this criterion: 5
 
          Multicast Mac Address Table
------------------------------------------------------------------
 
Vlan    Mac Address       Type        Ports
----    -----------       ----        -----
Total Mac Addresses for this criterion: 0

Conclusion

We have successfully shown the lighty.io BGP functionality, which is able to replace legacy Route-Reflectors. This situation can be applied to telecom data-centers and other use-cases. It demonstrates lighty.io’s versatility and usability. Contact us for more information!

Peter Šuňa & Peter Lučanský


You can contact us at https://pantheon.tech/

Explore our Pantheon GitHub.

Watch our YouTube Channel.

lighty.io Summer 2019 News

[News] all-lighty.io Summer 2019

It has been a busy summer for PANTHEON.tech & our developers of our leading product lighty.io. For all those interested in new information, here is a round-up of all the examples and demos we have published on our social media.

Integrating lighty.io & CCSDK (ONAP)

In the last weeks, we are intensively working, together with the wonderful ONAP community, on proposing to remove existing dependencies on the OSGi Framework and Karaf from the CCSDK project – while still maintaining the same OpenDaylight services, which the community knows and uses. We will deep-dive on our proposal soon in a separate post, so stay tuned!

Spring Boot Example

Full NETCONF/RESTCONF stack for the Spring Boot runtime.

We have recently succeeded in running RESTCONF in a Springboot example, designed for lighty. Springboot is now able to run in a full OpenDaylight/lighty.io stack.

Spring Boot makes it easy to just run & create stand-alone, Spring-based Applications. It boasts no code generation or requirement for XML configuration, automatic configuration of Spring functionality and radically improves the pure Spring deployment and development.

Clustered Application Demo

lighty.io running as a clustered RESTCONF/NETCONF SDN controller application. From now on, it supports deployment in Akka cluster, so you are not limited to single-node SDN controllers.

Furthermore, you can deploy lighty.io as a Kubernetes cluster.

TransportPCE Controller

lighty.io TransportPCE Controller is now upstreamed in the OpenDaylight Project! We have previously managed to migrate TransportPCE into lighty. Now, you can see the code for yourself in the OpenDaylight repository. 

We have previously published a how-to on how to migrate the OpenDaylight TransportPCE to lighty.io.

BGP/EVPN Router

We are planning on extending the BGP function of an SDN controller with an EVPN extension in the BGP control-plane. We will discuss BGP-EVPN functions in SDN controllers and how the lighty.io BGP function can replace existing legacy BGP route reflectors, running in service provider’s WAN or DC networks.

spring.io & lighty.io integration

Match Made In Heaven: Spring Boot & lighty.io

lighty.io brings you full NETCONF/RESTCONF stack for the Spring Boot runtime.

Check out our example, which runs core OpenDaylight components integrated into a Springboot application.

You are no longer restricted to the cumbersome legacy ODL Karaf runtime. lighty.io makes accessible spring component ecosystem for wide SDN development. Go ahead and enjoy features of ODL ecosystem and advantages of the vast spring project ecosystem.

Popular Java Framework

We have recently succeeded in running RESTCONF in a Springboot example, available for lighty.io. Springboot is now able to run in a full OpenDaylight/lighty.io stack, this includes:

  • RESTCONF
  • MD-SAL
  • NETCONF

Spring Boot makes it easy to just run & create stand-alone, Spring-based Applications. It boasts no code generation or requirement for XML configuration, automatic configuration of Spring functionality and radically improves the pure Spring deployment and development.

MD-SAL, part of the OpenDaylight Controller, provides infrastructure services for data stores, RPC (& Service Routing) and notification subscriptions, as well as publish services.

Model-Driven SAL Queries is a tool developed by PANTHEON.tech, aimed at OpenDaylight developers. Its goal is to speed up work with the MD-SAL API. On top of this, we added two new features: query operations on a data store. Check out our introductory video on this project:

RESTCONF is a REST-like protocol running over HTTP. It helps to access data defined in YANG, for which it uses datastores defined in NETCONF. Its aim is to provide a simple interface with REST-like features and principles, with device abstraction based on available resources.

NETCONF, on the other hand, is a network management protocol, developed and maintained by the Internet Engineering Task Force. It is able to manage (install, delete, manipulate) network device configurations. All of these processes are done on top of an RPC layer.


You can contact us at https://pantheon.tech/

Explore our Pantheon GitHub.

Watch our YouTube Channel.

OpenDaylight Neon logo

[Comparison] OpenDaylight Neon SR1 vs. SR2

The development of OpenDaylight Sodium is already producing significant improvements, some of which are finding their way to the upcoming Service Release of Neon.

These are the test results for OpenDaylight Neon SR2. We have recorded significant improvements in the following areas:

  • Datastore snapshot-size: ~49% reduction
  • Processing time: ~58% reduction
  • In-memory size: ~25% reduction
  • Object count: ~25% reduction
  • NodeIdentifier: ~99.9% reduction
  • AugmentationIdentifier: ~99.9% reduction

These enhancements will also be present in the future, long-awaited release of Sodium.

Our commitment – more commits

PANTHEON.tech’s CTO, Robert Varga, is currently the top-single committer to OpenDaylights source-code, according to recent reports. PANTHEON.tech also resides as the number 1 contributor to its source-code.

Bitergia, a software development analytics company, regularly tracks the number of commits to OpenDaylight – based on single commiters and companies. OpenDaylight plays a significant role in PANTHEON.tech’s offerings and solutions.

Apart from PANTHEON.tech’s position as a top contributing organization to ODL, PANTHEON.tech has always been a strong supporter of the open-source community. This support covers a wide range of developers from local, private open-source development groups to international open-source platforms – such as ONAP, OPNFV or FD.io.

What is OpenDaylight?

OpenDaylight is a collaborative, open-source project, established in 2013. It aims to speed up the adoption of SDN and create a solid foundation for Network Functions Virtualization.

It was founded by global industry leaders, such as Cisco, Ericsson, Intel, IBM, Dell, HP, Red Hat, Microsoft, PANTHEON.tech and open to all.

PANTHEON.tech’s involvement in OpenDaylight goes way back to its beginnings. We have led the way in what an SDN controller is and should aspire to be. This requires dedication, which was proven over the years with an extensive amount of contribution and a successful track record, thanks to our expert developers.

Contact us, if you are interested in our solutions, which are based on, or integrate OpenDaylights framework.

OpenDaylight Sodium logo

[Release] OpenDaylight Sodium, YANG Tools & MD-SAL

It is no secret, that OpenDaylight is more than a passion project here at PANTHEON.tech. As one of the staples in the SDN revolution, we are also proud that we are one of the largest contributors to the project, with our CTO Robert Varga leading in the number of individual commits. Let us have a look at what is new.

YANG Tools 3.0.0

YANG Tools is a set of libraries and data modeling language, used to model state & configuration data. It’s libraries provide support for NETCONF and YANG for Java-based projects and applications.  What’s new in the world of the latest Yangtools release?

It implements new RFCs: RFC7952 (Defining and Using Metadata with YANG) and RFC8528 (YANG Schema Mount).

YANG parser now supports RFC6241 & RFC8528, while adding strict QName rules for “node identifiers”.

JDK11 support has been added together with lots of small bugfixes, which you can read in detail in its changelog.

MD-SAL 4.0.0

The Model-Driven Service Abstraction Layer is OpenDaylight’s kernel – it interfaces between different layers and modules. MD-SAL uses APIs to connect & bind requests and services and delegates certain types of requests.

The new version of MD-SAL has been released for ODL. MD-SAL is one of the central OpenDaylight components. This release contains mainly bugfixes and brings pre-packaged model updates for newly released IETF  models: RFC8519, RFC8528, RFC8529, RFC8530.

OpenDaylight Release Sequence

Get ready for OpenDaylight Sodium

OpenDaylights development has a new important milestone ahead: the Sodium release, currently scheduled around September 2019. This release will bring new versions of YANG Tools, MD-SAL and other core OpenDaylight components.

JDK11, as well as JKD8, is supported, providing an opportunity for OpenDaylight users to try new features of JDK11. It bids farewell to Java EE modules & JavaFX, as well as performance & bug fixes.

We believe you are also looking forward to these releases and encourage you to try them out!

Don’t forget to contact us, in case you are interested in a commercial solution for your business!


You can contact us at https://pantheon.tech/

Explore our Pantheon GitHub.

Watch our YouTube Channel.

VPPTop product logo

[Release] VPPTop

Here at PANTHEON.tech, we really enjoy perfecting the user experience around VPP and creating projects based around this framework. That is why we have developed a handy tool, which lets you analyze several crucial data points while using VPP. We call it VPPTop.

Requirements

In order to run VPPTop, you will need to install these dependencies first:

  1. [Go] version 1.11+
  2. [VPP], version 19.04-3~g1cb333cdf~b41 is recommended. You can find the installation guide here.
  3. Configure VPP, according to the README file

How to install & run

1. Follow the above requirements, in order to have all dependencies for this software installed

2. Make sure VPP is running beforehand

3. Install VPPTop via Terminal to $GOPATH/bin:

go get -u github.com/PantheonTechnologies/vpptop

4. Run the tool from Terminal:

sudo -E vpptop

What is VPPTop?

VPPTop is an application for sysadmins and testers, implemented in Go. The goal of VPPTop is to provide VPP statistics which are updated in real-time, in one terminal window.

Before the release of our tool, admins could only rely on the usage of a CLI, to first request the data flow and then receive information, which are not up-to-date, nor in real-time.

Now, you can use our VPPTop tool, to find up-to-date information on your framework!

Version 1.11 supports statistics for:

  • Interfaces
  • Nodes
  • Errors
  • Memory Usage per Thread
  • Per Thread-Data

Version 1.11 supports these functionalities:

  • Clearing counters
  • Filter by Name
  • Sorting

Why should you start to use Vector Package Processing?

The main advantages are:

  • high performance with a proven technology
  • production level quality
  • flexible and extensible

The main advantage of VPP is, that you can plug in a new graph node, adapt it to your networks purposes and run it right away. Including a new plugin does not mean, you need to change your core-code with each new addition. Plugins can be either included in the processing graph, or they can be built outside the source tree and become an individual component in your build.

Furthermore, this separation of plugins makes crashes a matter of a simple process restart, which does not require your whole build to be restarted because of one plugin failure.

You can read more in our PANTHEON.tech series on VPP.


You can contact us at https://pantheon.tech/

Explore our Pantheon GitHub.

Watch our YouTube Channel.

PANTHEON.tech joins the Telecom Infra Project

In January 2019, PANTHEON.tech has become a member of the Telecom Infra Project community – a collaborative telecom community.

The Telecom Infra Project is a network of companies which aim to share, create and collaborate on innovative technologies in the field of telecommunication. Its members comprise a variety of operators, technology providers, developers, startups and other institutions, outside of telecommunication services. It was launched in February 2016, with the aim of accelerating the pace of innovation in the telecom industry.

How it works

The Telecom Infra Project has a structure, in which its members can actively contribute and share their expertise in the wide range of telecom technologies:

Project groups design and build technologies. They are divided into three network areas, that altogether create an end-to-end network: AccessBackhaulCore and Management.

Community Labs test and validate the technologies from Project Groups in field and production trials. There are 6 active TIP Community Labs from all around the world, which share their testing results and respond to the members outputs.

Ecosystem Acceleration Centers aim to build a dedicated space with venture capital funding and experienced advisors, in order to help upcoming and promising telecom startups bring their ideas to the market and consumers.

PANTHEON.tech is proud to be part of the driving force in telecommunication innovation.We believe that we will prove ourselves worthy of this membership with our expertise in SDN, NFV or open-source solutions.

We are looking forward to cooperating with other TIP members on improving and creating technologies.


You can contact us at https://pantheon.tech/

Explore our Pantheon GitHub. Follow us on Twitter.

Watch our YouTube Channel.

 

 

PANTHEON.tech adds OC4VPP code to Sweetcomb

Recently, PANTHEON.tech has decided to contribute to FD.io’s Sweetcomb project source-code. This was mainly due to the fact, that our new project OC4VPP would compliment the idea and possibilities of the project, while improving its functionality.

What was the OC4VPP project?

Network administrators have the possibility to use protocols, such as gNMI or NETCONF, in order to communicate with sysrepo.

OC4VPP was a sysrepo plugin, with which we were able to setup and orchestrate the VPP framework. This plugin was part of our in-house solution that we were working on.

Sweetcomb and OC4VPP both use VAPI, in order to communicate with the VPP API. Here at PANTHEON.tech, our developers managed to include more YANG models into OC4VPP. But we  realized soon, that Sweetcomb was in advanced development and provided some of the functionality, we wanted to work on.

How will Sweetcomb benefit from OC4VPP?

Sweetcomb is a management agent, used to expose YANG modules, with the help of RESTCONF and NETCONF, in order to immediately allow  management of the VPP instance. It translates all communication between the Northbound interface and the VPP API.

We believe, that Sweetcomb will directly benefit from PANTHEON.tech’s solution, in form of the source-code of OC4VPP. This will provide the project with more YANG models to expand its functionality.

Due to Sweetcomb being a new project and mainly proof of concept, it currently supports only these 5 IETF-YANG models:

  • /ietf-interfaces:interfaces/interface
  • /ietf-interfaces:interfaces/interface/enabled
  • /ietf-interfaces:interfaces/interface/ietf-ip:ipv4/address
  • /ietf-interfaces:interfaces/interface/ietf-ip:ipv6/address
  • /ietf-interfaces:interfaces-state

First of all, Sweetcomb will gain support for OpenConfig models, which expands its usability and improves the projects deployment scale.

In case of OC4VPP, we managed to include 10 additional YANG models we would like to implement into the actual list of supported modules in Sweetcomb:

  • /openconfig-interfaces:interfaces/interface/config
  • /openconfig-interfaces:interfaces/interface/state
  • /openconfig-interfaces:interfaces/interface/subinterfaces/subinterface/state
  • /openconfig-interfaces:interfaces/interface/subinterfaces/subinterface/openconfig-if-ip:ipv4/openconfig-if-ip:addresses/openconfig-if-ip:address/openconfig-if-ip:config
  • /openconfig-interfaces:interfaces/interface/subinterfaces/subinterface/openconfig-if-ip:ipv4/openconfig-if-ip:addresses/openconfig-if-ip:address/openconfig-if-ip:state
  • /openconfig-local-routing:local-routes/static-routes/static/next-hops/next-hop/config
  • /openconfig-local-routing:local-routes/static-routes/static/next-hops/next-hop/interface-ref/config
  • /openconfig-local-routing:local-routes/static-routes/static/state
  • /openconfig-local-routing:local-routes/static-routes/static/next-hops/next-hop/state
  • /openconfig-local-routing:local-routes/static-routes/static/next-hops/next-hop/interface-ref/state

As a regular open-source contributor and supporter, we are glad that we were able to make this important decision and showcase crucial principles of open-source development:

Communication – Participation – Collaboration

You can find the source-code for Sweetcomb in the official GitHub.


You can contact us at https://pantheon.tech/

Explore our Pantheon GitHub. Follow us on Twitter.

Watch our YouTube Channel.

PANTHEON.tech & OpenDaylight

PANTHEON.tech is the 2nd largest OpenDaylight contributor for Q3/2018

In the last week of November 2018, Bitergia, a software development analytics company, published a report on the past and current status of the OpenDaylight project, which plays a significant role in PANTHEON.tech’s offerings and solutions.

PANTHEON.tech’s CTO Robert Varga, is leading the list of per-user-contributions to the source code of OpenDaylight, with over 980 commits to the source code in Q3 of 2018. This achievement further establishes PANTHEON.tech’s position as one of the largest contributors to the OpenDaylight project.

As for the list of companies which contribute to the source code of OpenDaylight, PANTHEON.tech is the 2nd largest contributor for Q3/2018, with 1034 commits. We were just 34 commits shy of the top contributor position, which belongs to Red Hat.

Due to ODL’s open-source nature, anyone can contribute to the project and improve it in the long-run. Any change that gets added to the source code is defined as a commit. These types of changes need an approval and can not be any type of automated activity – including bot-actions or merges. This means, that each single commit is a unique change, added to the source code.

PANTHEON.tech will continue its commitment to improving OpenDaylight and we are looking forward to being a part of the future of this project.

What is OpenDaylight?

ODL is a collaborative open source project aimed to speed up the adoption of SDN and create a solid foundation for Network Functions Virtualization (NFV).

PANTHEON.tech’s nurture for ODL goes back when it was forming. In a sense, PANTHEON.tech has led the way is and how an SDN controller is and should be. This requires dedication, which was proven over the years with the extensive amount of contribution thanks to its expert developers.

Click here if you are interested in our solutions, which are based on, or integrate ODL’s framework.


You can contact us at https://pantheon.tech/

Explore our Pantheon GitHub.

Watch our YouTube Channel.

PANTHEON.tech @ OTKD – 345 km in 33,5 hours.

PANTHEON.tech’s running team participated in the From Tatry To Danube Run (OTKD) 2018.

The relay run named From Tatry To Danube (OTKD) is 345 kilometers long run and may comprise a maximum of 12 runners per team. This year, 214 teams had taken part. PANTHEON.tech running team took part in this adventure with our 12 runners who had to cover 345 kilometers in less than 36 hours. We are proud that our colleagues were successful. The running team finished the run in the overall 33 hours 34 minutes.

The run took place from Saturday, August 18 to Sunday, August 19. The runners started on Saturday morning in Demenovská valley and ran non-stop. Day and night, in harsh weather and terrain, to reach the finish in Bratislava on the bank of Danube river. Each of the runners covered approximately 30 kilometers in average.

PANTHEON.tech believes, a healthy mind can only cherish on a healthy body is happy to support its employees in participating in such activities. See you at OTKD 2019!

[lighty.io] Welcome lighty-core to Open-Source!

PANTHEON.tech, the proven supporter of open-source software and its communities, and leader in Software Defined Networking (SDN) and the OpenDaylight (ODL) platform, decided to open-source the core components of the current go-to SDN controller development kit: lighty.io.

Last Open Networking Summit, USA witnessed the announcement of lighty.io. This ONS will be the place where all OpenDaylight users will remember.

Today, PANTHEON.tech continues to push forward the open-source community projects and its commercial applications developed on open-source software, especially the lighty.io core.

What is lighty.io?

lighty.io journey started when we realized the way to move the upstream project to the direction we envisioned was to provide a solution rather than talk about it. Therefore we’ve focused on a solution of the biggest pain point of current ODL, and turned it into the idea-bearer of the whole product. We’ve taken the biggest obstacle – Apache Karaf, out of the ODL developers lives, and hence improving their efficiency tremendously.

On the other hand the lighty.io commercial product is available for purchase is developed using the same lighty.io core which gets open-sourced today. We are tirelessly adding new features with the demand and cooperation with our customers. Such as the lighty.io Network Topology Visualisation Component, Go/Java/Python RESTCONF clients, improved RESTCONF notifications with HTTP 2.0 support, improved southbound NETCONF plugin with the implemented support of YANG actions, NETCONF simulator to name a few.

Our vision from the start was to enhance the commercial version of lighty.io with bleeding edge features and improvements that are not yet in open-source ODL. This will leverage lighty.io users capability to speed up their development and deployment. Today, users will get the chance to experience these changes, instead of waiting until such improvements appear in the upstream or developing themselves.

PANTHEON.tech released lighty.io core components under Eclipse Public License v1.0 as a continuous support to the community.

Future of SDN

We believe this generous act will result in spinning up new projects based on OpenDaylight components making them faster and cheaper to develop and will give you a competitive edge in today’s fast evolving world of micro service and cloud-oriented deployments.

We encourage all OpenDaylight users, Data Center managers, Telco and Service Provider DevOps to give lighty.io a try with their existing applications. It will be amaze you.

Today, PANTHEON.tech will officially release the lighty-core as free and open-source software at the event. Please join us in the Open Networking Summit Europe/Amsterdam at booth #14.

There is more to come, as we will reveal how lighty.io cuts down the software development costs and time, helping our customers to consume complex data center management features with ease.

Stay tuned and watch this space for the other great announcements around lighy.io which will take space in the event. Be there to witness the amazing.

Meet Martin Varga – PANTHEON.tech @ ONS 2018

Martin Varga represents PANTHEON.tech as the Technical Business Development Manager and is responsible for the growth of the company’s business portfolio and goal to establish new partnerships. Martin has over two decades of professional experience in marketing, sales management, and international business development fields.

He has acquired many titles in his long career, ranging from Artist Manager to COO. He is an excellent negotiator and peoples person.

Recently, Martin had started to be very interested in the Hi tech business, especially in the networking field, which is on the rise nowadays and will be for the next decades. He quickly got absorbed in the networking field and discovered his new passion. Hence he accepted the challenge and is using all his previously acquired experience to expand the business development for PANTHEON.tech.

Connect with Martin via his LinkedIn.

Martin will be available to establish new business relationships with international partners and to discover new market share. He will be representing PANTHEON.tech the silver sponsor of Open Networking Summit Europe which will take place on Sep 25-27 in Amsterdam.

Join Martin at PANTHEON.tech’s booth #14 in the event possibly to shake hands into a partnership which will last.

Meet Robert Varga – PANTHEON.tech @ ONS 2018

Robert Varga is PANTHEON.tech’s  Chief Technology Officer who has almost two decades of Information Technology Industry experience ranging from being a C code monkey, through various roles in telecommunications’ IT operations to architecting bleeding edge software platforms.

Robert has a deep expertise in Software Defined Networking, its applications and the OpenDaylight platform.

Within those decades, some of the technologies he had experience are: C/C++, Java, Python, various UNIX-like systems and database systems.

Robert has a very strong background in design, development, deployment, and administration of large-scale platforms with the primary focus on high availability and security.

Robert has been involved in OpenDaylight from its start, architecting, designing and implementing the MD-SAL. He is the most prolific OpenDaylight contributor and a member of the OpenDaylight Technical Steering Committee, representing kernel projects. His code contributions revolve around key infrastructure components, such as YANG Tools, MD-SAL and Clustered Data Store. He also designed and implemented the first versions of the BGP and PCEP plugins.

[visualizer id=”6717″] 

Source: Bitergia Analytics

Until today, Robert Varga had made 11,368 commits in 66 ODL projects over the course of ODL’s lifespan. That is 621,236 added and 524,842 removed lines of code and that translates roughly around 12 great novels written in </code>. ODL continues to be a great example of what an open-source software is and how international contributors can collaborate beautifully to create the next great thing.  There are currently only 13 TCLs in ODL who help steer the project forward and lead the ODL to be the most successful SDN controller in the world. He is proudly one of the ODL Technical Steering Committee Members and a committer to a range of projects.

The all-time top contributor of ODL  Robert Varga, Chief Technology Officer of PANTHEON.tech makes the company proud to be among the top contributor of such innovative, successful project.

Robert shares the PANTHEON.tech’s ambition to create the biggest and most successful open-source Software Defined Networking (SDN) controller in the world.

Robert will be available to share his deep expertise in the field and representing PANTHEON.tech the silver sponsor of Open Networking Summit Europe which will take place on Sep 25-27 in Amsterdam.

Join Robert at PANTHEON.tech’s booth #14 in the event to get a glimpse of the Software Defined Networking future.

 

lighty.io @ Open Network Summit 2018

PANTHEON.tech, the proven supporter of open-source software and its communities, leader in Software Defined Networking (SDN) and the OpenDaylight (ODL) platform, has announced the development of lighty.io at the Open Networking Summit, USA.

Since then PANTHEON.tech’s initiative had received a great positive feedback. We got to know how lighty.io eased their SDN controller development pain and shortened the development time. Or how the removal of Apache Karaf enabled them to shorten product to market time and how the improved RESTCONF NB interface helped them spend time on their applications instead of solving technical debts.

Today, we to push forward the open-source community projects and its commercial applications developed on open-source software, especially the lighty.io core.

PANTHEON.tech will be again attending another summit on 25-27 September.

Find PANTHEON.tech, the Silver sponsor of the Open Networking Summit Europe, at the booth #14.

Stay tuned and watch this space for the other great announcements around lighty.io which will take space in the event.

Meet Štefan Kobza – PANTHEON.tech @ ONS 2018

 

Štefan Kobza is Chief Operation Officer at PANTHEON.tech with almost two decades of professional Information Technology industry experience.

He started his career as a software developer and built his way up. Štefan has worked on different projects ranging from developing proprietary code for major networking vendors to rating and billing services mainly in computer networking and telecommunication industries. All of his coding experiences helped Štefan to understand his game and stay on top of the projects he is involved and for PANTHEON.tech’s current customers to provide the highest quality engineering services.

Štefan has taken part in the process of defining some IETF RFCs ¹ ², which was an experience on its own.

Lately, he had developed a special interest for open-sourced projects and its communities.

Understanding the daily life of a software developer, Štefan helps in building an ever growing and ever improving environment that helps PANTHEON.tech provide the highest quality engineering services.

You can find his published articles and activities on his LinkedIn profile.

Besides leading day-to-day business in PANTHEON.tech, Štefan also watches closely the development around OpenDaylight, OPNFV, ONAP, FD.IO, Sysrepo, Contiv, Ligato, and others.

Find Štefan representing PANTHEON.tech the silver sponsor, at booth #14 in the Open Networking Summit Europe to exchange ideas and to get a glimpse of the Software Defined Networking future.

Save the date and get your tickets. #ons2018, Amsterdam Sep 25-27