Welcome to the 5th part of our VPP Guide series! Today, we will be asking ourselves practical questions regarding the various technologies & libraries managed in VPP – their usage, advantages, and management. Let’s jump right into it and ask ourselves:
Why does DPDK use Hugepages?
Hugepages
Hugepages is one of the techniques used in virtual memory management. In a standard environment, CPU allocates memory (virtual) for each process. Those blocks of memory are called „pages“ and for efficiency in Linux kernel the size of allocated memory is 4kB. When a process wants to access its memory, CPU has to find where this virtual memory is – this is the task of Memory Management Unit and page table lookup. Using the page table structure CPU could map virtual to physical memory.
For example, when the process needs 1GB of memory, this leads to more than 200k of pages in the page table which the CPU has to lookup for. Of course, this leads to performance slowdown. Fortunately, nowadays CPUs support bigger pages – so-called Hugepages. They can reduce the number of pages to be lookup for and usage of huge pages increases performance.
Memory Management Unit uses one additional hardware cache – Translation Lookaside Buffers (TLB). When there is address translation from virtual memory to physical memory, translation is calculated in MMU, and this mapping is stored in the TLB. So next time accessing the same page will be first handled by TLB (which is fast) and then by MMU.
As TLB is a hardware cache, it has a limited number of entries, so a large number of pages will slow down the application. So a combination of TLB with Hugepages reduces the time it takes to translate a virtual page address to a physical page address and to lookup for and so again it will increase performance.
This is the reason why DPDK, and VPP as well, uses Hugepages for large memory pool allocation, used for packet buffers. By using Hugepages allocations, performance is increased since fewer pages and fewer lookups are needed and the management is more effective.
Cache prefetching
Cache prefetching is another technique used by VPP to boost execution performance. Prefetching data from their original storage in slower memory to a faster local memory before it is actually needed significantly increase performance. CPUs have fast and local cache memory in which prefetched data is held until it is required. Examples of CPU caches with a specific function are the D-cache (data cache), I-cache (instruction cache) and the TLB (translation lookaside buffer) for the MMU. Separated D-cache and I-cache makes it possible to fetch instructions and data in parallel. Moreover, instructions and data have different access patterns.
Cache prefetching is used mainly in nodes when processing packets. In VPP, each node has a registered function responsible for incoming traffic handling. An example of registration (abf and flowprobe nodes):
/*
* Copyright (c) 2017 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
VLIB_REGISTER_NODE (abf_ip4_node) = {
.function = abf_input_ip4,
.name = "abf-input-ip4",
VLIB_REGISTER_NODE (flowprobe_ip4_node) = {
.function = flowprobe_ip4_node_fn,
.name = "flowprobe-ip4",
In abf processing function, we can see single loop handling – it loops over packets and handles them one by one.
/*
* Copyright (c) 2017 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
abf_input_inline (vlib_main_t * vm,
vlib_node_runtime_t * node,
vlib_frame_t * frame, fib_protocol_t fproto)
{
...
while (n_left_from > 0 && n_left_to_next > 0)
{
...
abf_next_t next0 = ABF_NEXT_DROP;
vlib_buffer_t *b0;
u32 bi0, sw_if_index0;
...
bi0 = from[0];
to_next[0] = bi0;
from += 1;
to_next += 1;
n_left_from -= 1;
n_left_to_next -= 1;
b0 = vlib_get_buffer (vm, bi0);
sw_if_index0 = vnet_buffer (b0)->sw_if_index[VLIB_RX];
ASSERT (vec_len (abf_per_itf[fproto]) > sw_if_index0);
attachments0 = abf_per_itf[fproto][sw_if_index0];
...
/* verify speculative enqueue, maybe switch current next frame */
vlib_validate_buffer_enqueue_x1 (vm, node, next_index,
to_next, n_left_to_next, bi0,
next0);
}
vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}
In flowprobe node, we can see quad/single loop using prefetching which can significantly increase performance. In the first loop:
/*
* Copyright (c) 2015 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
( while (n_left_from >= 4 ... ) )
it processes buffers b0 and b1 (and moreover, the next two buffers are prefetched), and in the next loop
/*
* Copyright (c) 2015 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
( while (n_left_from > 0 ... ) )
remaining packets are processed.
/*
* Copyright (c) 2018 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
flowprobe_node_fn (vlib_main_t * vm,
vlib_node_runtime_t * node, vlib_frame_t * frame,
flowprobe_variant_t which)
{
...
/*
* While we have at least 4 vector elements (pkts) to process..
*/
while (n_left_from >= 4 && n_left_to_next >= 2)
{
...
/* Prefetch next iteration. */
{
vlib_buffer_t *p2, *p3;
p2 = vlib_get_buffer (vm, from[2]);
p3 = vlib_get_buffer (vm, from[3]);
vlib_prefetch_buffer_header (p2, LOAD);
vlib_prefetch_buffer_header (p3, LOAD);
CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
}
...
/* speculatively enqueue b0 and b1 to the current next frame */
b0 = vlib_get_buffer (vm, bi0);
b1 = vlib_get_buffer (vm, bi1);
/* verify speculative enqueues, maybe switch current next frame */
vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
to_next, n_left_to_next,
bi0, bi1, next0, next1);
}
/*
* Clean up 0...3 remaining packets at the end of the frame
*/
while (n_left_from > 0 && n_left_to_next > 0)
{
u32 bi0;
vlib_buffer_t *b0;
u32 next0 = FLOWPROBE_NEXT_DROP;
u16 len0;
/* speculatively enqueue b0 to the current next frame */
bi0 = from[0];
to_next[0] = bi0;
from += 1;
to_next += 1;
n_left_from -= 1;
n_left_to_next -= 1;
b0 = vlib_get_buffer (vm, bi0);
vnet_feature_next (&next0, b0);
len0 = vlib_buffer_length_in_chain (vm, b0);
ethernet_header_t *eh0 = vlib_buffer_get_current (b0);
u16 ethertype0 = clib_net_to_host_u16 (eh0->type);
if (PREDICT_TRUE ((b0->flags & VNET_BUFFER_F_FLOW_REPORT) == 0))
{
flowprobe_trace_t *t = 0;
if (PREDICT_FALSE ((node->flags & VLIB_NODE_FLAG_TRACE)
&& (b0->flags & VLIB_BUFFER_IS_TRACED)))
t = vlib_add_trace (vm, node, b0, sizeof (*t));
add_to_flow_record_state (vm, node, fm, b0, timestamp, len0,
flowprobe_get_variant
(which, fm->context[which].flags,
ethertype0), t);
}
/* verify speculative enqueue, maybe switch current next frame */
vlib_validate_buffer_enqueue_x1 (vm, node, next_index,
to_next, n_left_to_next,
bi0, next0);
}
VPP I/O Request Handling
Why is polling faster than IRQs? How do the hardware/software IRQs work?
I/O device (NIC) event handling is a significant part of VPP. The CPU doesn’t know when an I/O event can occur, but it has to respond. There are two different approaches – IRQ and Polling, which are different from each other in many aspects.
From a CPU point of view, IRQ seems to be better, as the device disturbs the CPU only when it needs servicing, instead of constantly checking device status in case of polling. But from an efficiency point of view, interruptions are inefficient when the devices keep on interrupting the CPU repeatedly and polling is inefficient when the CPU device is rarely ready for servicing.
As in the case of packet processing in VPP, it is expected that traffic will be permanent. In such a case, the number of interruptions would rapidly increase. On the other hand, the device will be ready for service all the time. So polling seems to be more efficient for packet processing and it is the reason why VPP uses polling when processing the incoming packet.
VPP & DPDK
What API does DPDK offer? How does VPP use this library?
DPDK networking drivers are classified in two categories:
- physical for real devices
- virtual for emulated devices
The DPDK ethdev layer exposes APIs, in order to use the networking functions of these devices. For a full list of the supported features and APIs, click here.
In VPP, DPDK support has been moved from core to plugin to simplify enabling/disabling and handling DPDK interfaces. To simplify and store all DPDK relevant info, a DPDK device implementation (src/plugin/dpdk/device/dpdk.h) has a structure with DPDK data:
/* SPDX-License-Identifier: BSD-3-Clause
* Copyright(c) 2010-2014 Intel Corporation
*/
typedef struct
{
...
struct rte_eth_conf port_conf;
struct rte_eth_txconf tx_conf;
...
struct rte_flow_error last_flow_error;
...
struct rte_eth_link link;
...
struct rte_eth_stats stats;
struct rte_eth_stats last_stats;
struct rte_eth_xstat *xstats;
...
} dpdk_device_t;
containing all relevant DPDK structs used in VPP, to store DPDK relevant info.
DPDK APIs are used in the DPDK plugin only. Here is a list of DPDK features and their API’s used in VPP, with a few examples of usage.
Speed Capabilities / Runtime Rx / Tx Queue Setup
Supports getting the speed capabilities that the current device is capable of. Supports Rx queue setup after the device started.
API: rte_eth_dev_info_get()
/*
* Copyright (c) 2017 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
dpdk_device_setup (dpdk_device_t * xd)
{
dpdk_main_t *dm = &dpdk_main;
...
struct rte_eth_dev_info dev_info;
...
if (xd->flags & DPDK_DEVICE_FLAG_ADMIN_UP)
{
vnet_hw_interface_set_flags (dm->vnet_main, xd->hw_if_index, 0);
dpdk_device_stop (xd);
}
/* Enable flow director when flows exist */
if (xd->pmd == VNET_DPDK_PMD_I40E)
{
if ((xd->flags & DPDK_DEVICE_FLAG_RX_FLOW_OFFLOAD) != 0)
xd->port_conf.fdir_conf.mode = RTE_FDIR_MODE_PERFECT;
else
xd->port_conf.fdir_conf.mode = RTE_FDIR_MODE_NONE;
}
rte_eth_dev_info_get (xd->port_id, &dev_info);
Link Status
Supports getting the link speed, duplex mode and link-state (up/down).
API: rte_eth_link_get_nowait()
/*
*Copyright (c) 2015 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
dpdk_update_link_state (dpdk_device_t * xd, f64 now)
{
vnet_main_t *vnm = vnet_get_main ();
struct rte_eth_link prev_link = xd->link;
...
/* only update link state for PMD interfaces */
if ((xd->flags & DPDK_DEVICE_FLAG_PMD) == 0)
return;
xd->time_last_link_update = now ? now : xd->time_last_link_update;
clib_memset (&xd->link, 0, sizeof (xd->link));
rte_eth_link_get_nowait (xd->port_id, &xd->link);
Lock-Free Tx Queue
If a PMD advertises DEV_TX_OFFLOAD_MT_LOCKFREE capable, multiple threads can invoke rte_eth_tx_burst() concurrently on the same Tx queue without SW lock.
API: rte_eth_tx_burst()
/*
* Copyright (c) 2015 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
static clib_error_t *
dpdk_lib_init (dpdk_main_t * dm)
{
...
dpdk_device_t *xd;
...
if (xd->pmd == VNET_DPDK_PMD_FAILSAFE)
{
/* failsafe device numerables are reported with active device only,
* need to query the mtu for current device setup to overwrite
* reported value.
*/
uint16_t dev_mtu;
if (!rte_eth_dev_get_mtu (i, &dev_mtu))
{
mtu = dev_mtu;
max_rx_frame = mtu + sizeof (ethernet_header_t);
if (dpdk_port_crc_strip_enabled (xd))
{
max_rx_frame += 4;
}
}
}
Promiscuous Mode
Supports enabling/disabling promiscuous mode for a port.
API: rte_eth_promiscuous_enable(), rte_eth_promiscuous_disable(), rte_eth_promiscuous_get()
Allmulticast Mode
Supports enabling/disabling receiving multicast frames.
API: rte_eth_allmulticast_enable(), rte_eth_allmulticast_disable(), rte_eth_allmulticast_get()
/*
* Copyright (c) 2017 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
dpdk_device_stop (dpdk_device_t * xd)
{
if (xd->flags & DPDK_DEVICE_FLAG_PMD_INIT_FAIL)
return;
rte_eth_allmulticast_disable (xd->port_id);
rte_eth_dev_stop (xd->port_id);
...
Unicast MAC Filter
Supports adding MAC addresses to enable white-list filtering to accept packets.
API: rte_eth_dev_default_mac_addr_set(), rte_eth_dev_mac_addr_add(), rte_eth_dev_mac_addr_remove(), rte_eth_macaddr_get()
VLAN Filter
Supports filtering of a VLAN Tag identifier.
API: rte_eth_dev_vlan_filter()
VLAN Offload
Supports VLAN offload to hardware.
API: rte_eth_dev_set_vlan_offload(), rte_eth_dev_get_vlan_offload()
/*
* Copyright (c) 2015 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
dpdk_subif_add_del_function (vnet_main_t * vnm,
u32 hw_if_index,
struct vnet_sw_interface_t *st, int is_add)
{
...
dpdk_device_t *xd = vec_elt_at_index (xm->devices, hw->dev_instance);
int r, vlan_offload;
...
vlan_offload = rte_eth_dev_get_vlan_offload (xd->port_id);
vlan_offload |= ETH_VLAN_FILTER_OFFLOAD;
if ((r = rte_eth_dev_set_vlan_offload (xd->port_id, vlan_offload)))
{
xd->num_subifs = prev_subifs;
err = clib_error_return (0, "rte_eth_dev_set_vlan_offload[%d]: err %d",
xd->port_id, r);
goto done;
}
if ((r =
rte_eth_dev_vlan_filter (xd->port_id,
t->sub.eth.outer_vlan_id, is_add)))
{
xd->num_subifs = prev_subifs;
err = clib_error_return (0, "rte_eth_dev_vlan_filter[%d]: err %d",
xd->port_id, r);
goto done;
}
Basic Stats
Support basic statistics such as: ipackets, opackets, ibytes, obytes, imissed, ierrors, oerrors, rx_nombuf. And per queue stats: q_ipackets, q_opackets, q_ibytes, q_obytes, q_errors.
API: rte_eth_stats_get, rte_eth_stats_reset()
/*
* Copyright (c) 2015 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
dpdk_update_counters (dpdk_device_t * xd, f64 now)
{
vlib_simple_counter_main_t *cm;
vnet_main_t *vnm = vnet_get_main ();
u32 thread_index = vlib_get_thread_index ();
u64 rxerrors, last_rxerrors;
/* only update counters for PMD interfaces */
if ((xd->flags & DPDK_DEVICE_FLAG_PMD) == 0)
return;
xd->time_last_stats_update = now ? now : xd->time_last_stats_update;
clib_memcpy_fast (&xd->last_stats, &xd->stats, sizeof (xd->last_stats));
rte_eth_stats_get (xd->port_id, &xd->stats);
Extended Stats
Supports Extended Statistics, changes from driver to driver.
API: rte_eth_xstats_get(), rte_eth_xstats_reset(), rte_eth_xstats_get_names, rte_eth_xstats_get_by_id(), rte_eth_xstats_get_names_by_id(), rte_eth_xstats_get_id_by_name()
Module EEPROM Dump
Supports getting information and data of plugin module eeprom.
API: rte_eth_dev_get_module_info(), rte_eth_dev_get_module_eeprom()
VPP Library (vlib)
What funcionality does vlib offer?
Vlib is a vector processing library. It also handles various application management functions:
- buffer, memory, and graph node management and scheduling
- reliable multicast support
- ultra-lightweight cooperative multi-tasking threads
- physical memory, and Linux epoll support
- maintaining and exporting counters
- thread management
- packet tracing.
Vlib also implements the debug CLI.
In VPP (vlib), a vector is an instance of the vlib_frame_t type:
/*
* Copyright (c) 2015 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
typedef struct vlib_frame_t
{
/* Frame flags. */
u16 flags;
/* Number of scalar bytes in arguments. */
u8 scalar_size;
/* Number of bytes per vector argument. */
u8 vector_size;
/* Number of vector elements currently in frame. */
u16 n_vectors;
/* Scalar and vector arguments to next node. */
u8 arguments[0];
} vlib_frame_t;
As shown, vectors are dynamically resized arrays with user-defined “headers”. Many data structures in VPP (buffers, hash, heap, pool) are vectors with different headers.
The memory layout looks like this:
© Copyright 2018, Linux Foundation
User header (optional, uword aligned)
Alignment padding (if needed)
Vector length in elements
User's pointer -> Vector element 0
Vector element 1
...
Vector element N-1
Vectors are not only used in vppinfra data structures (hash, heap, pool, …) but also in vlib – in nodes, buffers, processes and more.
Buffers
Vlib buffers are used to reach high performance in packet processing. To do so, one allocates/frees N-buffers at once, rather than one at a time – except for directly processing specific buffer (its packets in given node), one deals with buffer indices instead of buffer pointers. Vlib buffers have a structure of a vector:
/*
* Copyright (c) 2015 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
/** VLIB buffer representation. */
typedef union
{
struct
{
CLIB_CACHE_LINE_ALIGN_MARK (cacheline0);
/** signed offset in data[], pre_data[] that we are currently
* processing. If negative current header points into predata area. */
i16 current_data;
/** Nbytes between current data and the end of this buffer. */
u16 current_length;
...
/** Opaque data used by sub-graphs for their own purposes. */
u32 opaque[10];
...
/**< More opaque data, see ../vnet/vnet/buffer.h */
u32 opaque2[14];
/** start of third cache line */
CLIB_CACHE_LINE_ALIGN_MARK (cacheline2);
/** Space for inserting data before buffer start. Packet rewrite string
* will be rewritten backwards and may extend back before
* buffer->data[0]. Must come directly before packet data. */
u8 pre_data[VLIB_BUFFER_PRE_DATA_SIZE];
/** Packet data */
u8 data[0];
};
#ifdef CLIB_HAVE_VEC128
u8x16 as_u8x16[4];
#endif
#ifdef CLIB_HAVE_VEC256
u8x32 as_u8x32[2];
#endif
#ifdef CLIB_HAVE_VEC512
u8x64 as_u8x64[1];
#endif
} vlib_buffer_t;
Each vlib_buffer_t (packet buffer) carries the buffer metadata, which describes the current packet-processing state.
- u8 data[0]: Ordinarily, hardware devices use data as the DMA target but there are exceptions. Do not access data directly, use vlib_buffer_get_current.
- u32 opaque[10]: primary vnet-layer opaque data
- u32 opaque2[14]: secondary vnet-layer opaque data
There are several functions to get data from vector (vlib/node_funcs.h):
To get a pointer to frame vector data
/*
* Copyright (c) 2015 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
always_inline void *
vlib_frame_vector_args (vlib_frame_t * f)
{
return (void *) f + vlib_frame_vector_byte_offset (f->scalar_size);
}
- to get pointer to scalar data
always_inline void *
vlib_frame_scalar_args (vlib_frame_t * f)
{
return vlib_frame_vector_args (f) - f->scalar_size;
}
Get pointer to scalar data
/*
* Copyright (c) 2015 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
always_inline void *
vlib_frame_scalar_args (vlib_frame_t * f)
{
return vlib_frame_vector_args (f) - f->scalar_size;
}
Translate the buffer index into buffer pointer
/*
* Copyright (c) 2015 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
always_inline vlib_buffer_t *
vlib_get_buffer (vlib_main_t * vm, u32 buffer_index)
{
vlib_buffer_main_t *bm = vm->buffer_main;
vlib_buffer_t *b;
b = vlib_buffer_ptr_from_index (bm->buffer_mem_start, buffer_index, 0);
vlib_buffer_validate (vm, b);
return b;
}
Get the pointer to current (packet) data from a buffer to process
/*
* Copyright (c) 2015 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
always_inline void *
vlib_buffer_get_current (vlib_buffer_t * b)
{
/* Check bounds. */
ASSERT ((signed) b->current_data >= (signed) -VLIB_BUFFER_PRE_DATA_SIZE);
return b->data + b->current_data;
Get vnet primary buffer metadata in the reserved opaque field
/*
* Copyright (c) 2015 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0<br >
*/
#define vnet_buffer(b) ((vnet_buffer_opaque_t *) (b)->opaque)
An example to retrieve vnet buffer data:
/*
* Copyright (c) 2017 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
add_to_flow_record_state (vlib_main_t * vm, vlib_node_runtime_t * node,
flowprobe_main_t * fm, vlib_buffer_t * b,
timestamp_nsec_t timestamp, u16 length,
flowprobe_variant_t which, flowprobe_trace_t * t)
{
...
u32 rx_sw_if_index = vnet_buffer (b)->sw_if_index[VLIB_RX];
Get vnet primary buffer metadata in reserved opaque2 field
/*
* Copyright (c) 2017 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
#define vnet_buffer2(b) ((vnet_buffer_opaque2_t *) (b)->opaque2)
Let’s take a look at flowprobe node processing function. Vlib functions always start with a vlib_ prefix.
/*
* Copyright (c) 2017 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
flowprobe_node_fn (vlib_main_t * vm,
vlib_node_runtime_t * node, vlib_frame_t * frame,
flowprobe_variant_t which)
{
u32 n_left_from, *from, *to_next;
flowprobe_next_t next_index;
flowprobe_main_t *fm = &flowprobe_main;
timestamp_nsec_t timestamp;
unix_time_now_nsec_fraction (×tamp.sec, ×tamp.nsec);
// access frame vector data
from = vlib_frame_vector_args (frame);
n_left_from = frame->n_vectors;
next_index = node->cached_next_index;
while (n_left_from > 0)
{
u32 n_left_to_next;
// get pointer to next vector data
vlib_get_next_frame (vm, node, next_index, to_next, n_left_to_next);
// dual loop – we are processing two buffers and prefetching next two buffers
while (n_left_from >= 4 && n_left_to_next >= 2)
{
u32 next0 = FLOWPROBE_NEXT_DROP;
u32 next1 = FLOWPROBE_NEXT_DROP;
u16 len0, len1;
u32 bi0, bi1;
vlib_buffer_t *b0, *b1;
/* Prefetch next iteration. */
// prefetching packets p3 and p4 while p1 and p2 are processed
{
vlib_buffer_t *p2, *p3;
p2 = vlib_get_buffer (vm, from[2]);
p3 = vlib_get_buffer (vm, from[3]);
vlib_prefetch_buffer_header (p2, LOAD);
vlib_prefetch_buffer_header (p3, LOAD);
CLIB_PREFETCH (p2->data, CLIB_CACHE_LINE_BYTES, STORE);
CLIB_PREFETCH (p3->data, CLIB_CACHE_LINE_BYTES, STORE);
}
/* speculatively enqueue b0 and b1 to the current next frame */
// frame contains buffer indecies (bi0, bi1) instead of pointers
to_next[0] = bi0 = from[0];
to_next[1] = bi1 = from[1];
from += 2;
to_next += 2;
n_left_from -= 2;
n_left_to_next -= 2;
// translate buffer index to buffer pointer
b0 = vlib_get_buffer (vm, bi0);
b1 = vlib_get_buffer (vm, bi1);
// select next node based on feature arc
vnet_feature_next (&next0, b0);
vnet_feature_next (&next1, b1);
len0 = vlib_buffer_length_in_chain (vm, b0);
// get current data (header) from packet to process
// currently we are on L2 so get etehernet header, but if we
// are on L3 for example we can retrieve L3 header, i.e.
// ip4_header_t *ip0 = (ip4_header_t *) ((u8 *) vlib_buffer_get_current (b0)
ethernet_header_t *eh0 = vlib_buffer_get_current (b0);
u16 ethertype0 = clib_net_to_host_u16 (eh0->type);
if (PREDICT_TRUE ((b0->flags & VNET_BUFFER_F_FLOW_REPORT) == 0))
add_to_flow_record_state (vm, node, fm, b0, timestamp, len0,
flowprobe_get_variant
(which, fm->context[which].flags,
ethertype0), 0);
...
/* verify speculative enqueue, maybe switch current next frame */
vlib_validate_buffer_enqueue_x1 (vm, node, next_index,
to_next, n_left_to_next,
bi0, next0);
}
vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}
return frame->n_vectors;
}
Nodes
As we said – vlib is also designed for graph node management. When creating a new feature, one has to initialize it, using the VLIB_INIT_FUNCTION macro. This constructs a vlib_node_registration_t, most often via the VLIB_REGISTER_NODE macro. At runtime, the framework processes the set of such registrations into a directed graph.
/*
* Copyright (c) 2016 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0<br >
*/
static clib_error_t *
flowprobe_init (vlib_main_t * vm)
{
/* ... initialize things ... */
return 0;
}
VLIB_INIT_FUNCTION (flowprobe_init);
...
VLIB_REGISTER_NODE (flowprobe_l2_node) = {
.function = flowprobe_l2_node_fn,
.name = "flowprobe-l2",
.vector_size = sizeof (u32),
.format_trace = format_flowprobe_trace,
.type = VLIB_NODE_TYPE_INTERNAL,
.n_errors = ARRAY_LEN(flowprobe_error_strings),
.error_strings = flowprobe_error_strings,
.n_next_nodes = FLOWPROBE_N_NEXT,
.next_nodes = FLOWPROBE_NEXT_NODES,
};
VLIB_REGISTER_NODE (flowprobe_walker_node) = {
.function = flowprobe_walker_process,
.name = "flowprobe-walker",
.type = VLIB_NODE_TYPE_INPUT,
.state = VLIB_NODE_STATE_INTERRUPT,
};
Type member in node registration specifies the purpose of the node:
- VLIB_NODE_TYPE_PRE_INPUT – run before all other node types
- VLIB_NODE_TYPE_INPUT – run as often as possible, after pre_input nodes
- VLIB_NODE_TYPE_INTERNAL – only when explicitly made runnable by adding pending frames for processing
- VLIB_NODE_TYPE_PROCESS – only when explicitly made runnable.
The initialization of feature is executed at some point in the application’s startup. However, constraints must be used to specify an order (when one feature has to be initialized after/before another one). To hook feature into specific feature arc VNET_FEATURE_INT macro can be used.
/*
* Copyright (c) 2016 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
VNET_FEATURE_INIT (ip4_nat44_ed_hairpin_src, static) = {
.arc_name = "ip4-output",
.node_name = "nat44-ed-hairpin-src",
.runs_after = VNET_FEATURES ("acl-plugin-out-ip4-fa"),
};
VNET_FEATURE_INIT (ip4_nat_hairpinning, static) =
{
.arc_name = "ip4-local",
.node_name = "nat44-hairpinning",
.runs_before = VNET_FEATURES("ip4-local-end-of-arc"),
};
Since VLIB_NODE_TYPE_INPUT nodes are the starting point of a feature arc, they are responsible for generating packets from some source, like a NIC or PCAP file and injecting them into the rest of the graph.
When registering a node, one can provide a .next_node parameter with an indexed list of the upcoming nodes in the graph. For example, a flowprobe node below:
/*
* Copyright (c) 2017 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0<br >
*/
...
next_nodes = FLOWPROBE_NEXT_NODES,
...
#define FLOWPROBE_NEXT_NODES { \
[FLOWPROBE_NEXT_DROP] = "error-drop", \
[FLOWPROBE_NEXT_IP4_LOOKUP] = "ip4-lookup", \
}
vnet_feature_next is commonly used to select the next node. This selection is based on the feature mechanism, as in the flowprobe example above:
/*
* Copyright (c) 2017 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
flowprobe_node_fn (vlib_main_t * vm,
vlib_node_runtime_t * node, vlib_frame_t * frame,
flowprobe_variant_t which)
{
...
b0 = vlib_get_buffer (vm, bi0);
b1 = vlib_get_buffer (vm, bi1);
// select next node based on feature arc
vnet_feature_next (&next0, b0);
vnet_feature_next (&next1, b1);
The graph node dispatcher pushes the work-vector through the directed graph, subdividing it as needed until the original work-vector has been completely processed.
Graph node dispatch functions call vlib_get_next_frame to set (u32 *)to_next to the right place in the vlib_frame_t, corresponding to the ith arc (known as next0) from the current node, to the indicated next node.
Before a dispatch function returns, it’s required to call vlib_put_next_frame for all of the graph arcs it actually used. This action adds a vlib_pending_frame_t to the graph dispatcher’s pending frame vector.
/*
* Copyright (c) 2015 Cisco and/or its affiliates. Licensed under the Apache License, Version 2.0. You may obtain a copy of the License at: http://www.apache.org/licenses/LICENSE-2.0
*/
vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}
return frame->n_vectors;
}
Pavel Kotúček
Thank you for reading through the 5th part of our PANTHEON.tech VPP Guide! As always, feel free to contact us if you are interested in customized solutions!
You can contact us at https://pantheon.tech/
Explore our Pantheon GitHub.
Watch our YouTube Channel.
[NSO Guide] Cisco NSO with SDN-C (ONAP)
/in Blog /by PANTHEON.techby Samuel Kontriš | Leave us your feedback on this post!
Welcome to the third and final part of our guide on Cisco’s Network Service Orchestrator. In previous parts, we managed to install and run the NSO on Ubuntu & connected it with lighty.io
Prerequisites
This tutorial was tested on Ubuntu 18.04 LTS. In this tutorial, we are going to use:
Get and start SDN-C
We will download and start SDN-C with only necessary components using Docker. All ONAP Docker images will be downloaded directly from docker-hub.
Create a file called docker-compose.yml with the following content:
This docker-compose file is based on this one from the official sdnc/oam Gerrit repository. The most important images are dgbuilder (which will start a webserver, where directed graphs can be created) and sdnc (the SDN-Controller itself).
To download and start images specified in the docker-compose file call this command:
Be patient, it may take a while.
In the end, when everything is up & running, we should see a log stating that Karaf was started successfully. It should look similar to this:
Directed Graph builder should be accessible through this address (port is specified in the docker-compose file):
Default login for dgbuilder is:
Upload and activate Directed Graphs
Steps how to upload DG from clipboard:
Steps to activate DG:
In these files are exported, parametrized Directed Graphs to connect your Cisco NSO instance via NETCONF protocol. You can get information about connected the Cisco NSO instance from the operational datastore. To activate ACL service (that we created in this tutorial). We will use these in later steps, so you can upload and activate them in your SDN-C instance.
You can download the corresponding JSON files here:
Connect Cisco NSO to SDN-C using DG
In the previous tutorial, we started Cisco NSO with three simulated devices. Now, we are going to connect a running Cisco NSO instance to SDN-C, using the directed graphs we just imported and activated.
But first, we need to obtain the address of Cisco NSO which we will use in the connect request. Run docker inspect command from the terminal like this:
Search for “NetworkSettings” – “Networks” – “yaml_default” – “Gateway”. The field “Gateway” contains an IP address that we will use, so save it for later. In my case it looks like this:
Now, we are going to connect to the SDN-C Karaf so we can see the log because some of the DGs write information in there. Execute these commands:
To execute the Directed Graph, call RESTCONF RPC SLI-API: execute-graph. To do this, call a POST request on URI:
With payload:
Where <module-name> is the name of the module, where the RPC you want to call is located. <rpc-name> is the name of the RPC. Additionally, you can specify parameters if they are required. We are using port 8282, which we specified in the docker-compose file.
This Postman collection contains all the requests we are going to use now. Feel free to change any attributes, according to your needs.
To connect the Cisco NSO instance, we are going to execute the connectNSO directed graph. Execute SLI-API:execute-graph RPC with this payload:
Don’t forget to set the correct nodeAddress to this request – we got this value before by executing the docker inspect command.
The parameter nodeId specifies the name, under which we will address Cisco NSO in SDN-C. Other parameters are default for the Cisco NSO.
After executing this RPC, we should see our DG – ID of the Cisco NSO node and its connection status (which will be most probably “connecting”), in the SDN-C logs output.
To check if Cisco NSO node was connected successfully, call getNSO DG. Execute SLI-API:execute-graph RPC with payload:
In the SDN-C logs, we should now see the “connected” status:
Activate Cisco NSO service using Directed Graph
We are now going to activate the ACL service we created in this tutorial, by executing activateACL directed graph.
Execute SLI-API:execute-graph RPC with this payload:
Feel free to change the values of ACL parameters (but first check what types they are in the ACL service YANG model).
Unfortunately, at the time of writing this tutorial, there is a bug in the OpenDaylight NETCONF (NETCONF-568) with parsing output from this RPC call. It prevents the ODL from sending a response to the RESTCONF request we sent (SLI-API:execute-graph RPC) and we need to manually stop waiting for this response in the Postman (or another REST client you are using).
Now, the service should be activated! To check services activated in the Cisco NSO call GET request on URI:
In response, you should see all activated services including our with name “aclFromDG”:
To check if the device was configured log into Cisco NSO CLI and execute show command:
You should see an output, similar to this:
Congratulations
You have successfully connected SDN-C with the Cisco NSO and concluded our series! In case you would like a custom integration, feel free to contact us.
Our previous articles in this series include:
3/24/2020 Update: Small tweaks in the code used in our demonstration, enjoy!
You can contact us at https://pantheon.tech/
Explore our Pantheon GitHub.
Watch our YouTube Channel.
OpenAPI 3.0 & OpenDaylight: A PANTHEON.tech Initiative
/in Blog, OpenDaylight /by PANTHEON.techPANTHEON.tech has created a commit in the official OpenDaylight repository, which updates the version of Swagger generator to OpenAPI 3.0.
This feature allows us to easily generate a JSON with RESTCONF API documentation of OpenDaylight RESTCONF applications and import it into various services, such as ServiceNow®. This feature is not only about the generation of JSON with OpenAPI. It also includes Swagger UI based on generated JSON.
What is RESTCONF API?
RESTCONF API is an interface, which allows access to datastores in the controller, via HTTP requests. OpenDaylight supports two versions of RESTCONF protocol:
What is OpenAPI?
OpenAPI, formerly known as Swagger UI, visualizes API resources and enables the user to interact with them. This kind of visualization provides an easier way to implement APIs in the back-end while automating the creation of documentation for the APIs in question.
OpenAPI Specification on the other hand (OAS for short), is a language-agnostic interface description for RESTful APIs. Its purpose is to visualize them and make the APIs readable for people and PCs alike, in YAML or JSON formats.
OAS 3.0 introduced several major changes, which made the specification structure clearer and more efficient. For a rundown of changes from OpenAPI 2 to version 3, make sure to visit this page detailing them.
How does it work?
OpenAPI is generated on the fly, with every manual request for the OpenAPI specification of the selected resource. The resource can be the OpenDaylight datastore or a device mount point.
You can conveniently access the list of all available resources over the apidoc web application. The resources are located on the top right part of the screen. Once you select the resource you want to generate the OpenAPI specification for, you just pick the desired resource and the OpenAPI specification will be displayed below.
The apidoc is packed within the odl-restconf-all Karaf feature. To access it, you only need to type
in the Karaf console. Then, you can use a web browser of your choice to access the apidoc web application over the following URL:
Once an option is selected, the page will load the documentation of your chosen resource, with the chosen protocol version.
The documentation of any resource endpoint (node, RPC’s, actions), is located under its module spoiler. When you click on the link:
you will get the OpenAPI JSON for the particular RESTCONF version and selected resource. Here is a code snippet from the resulting OpenAPI specification:
You can look through the entire export by clicking here.
Our Commitment to Open-Source
PANTHEON.tech is one of the largest contributors to the OpenDaylight source-code, with extensive knowledge that goes beyond a general service or integration.
This just goes to show, that PANTHEON.tech is heavily involved in the development and progress of OpenDaylight. We are glad to be part of the open-source community and contributors.
You can contact us at https://pantheon.tech/
Explore our PANTHEOn.tech GitHub.
Watch our YouTube Channel.
[Hands-On] Network Automation with ServiceNow® & OpenDaylight
/in Blog, OpenDaylight /by PANTHEON.techby Miroslav Kováč | Leave us your feedback on this post!
PANTHEON.tech s.r.o., its products or services, are not affiliated with ServiceNow®, neither is this post an advertisement of ServiceNow® or its products.
ServiceNow® is a complex cloud application, used to manage companies, their employees, and customers. It was designed to help you automate the IT aspects of your business – service, operations, and business management. It creates incidents where using flows, you can automate part of the work that is very often done manually. All this can be easily set up by any person, even if you are not a developer.
An Example
If a new employee is hired in the company, he will need access to several things, based on his position. An incident will be created in ServiceNow® by HR. This will trigger a pre-created, generic flow, which might, for example, notify his direct supervisor (probably manager) and he would be asked to approve this request of access.
Once approved, the flow may continue and set everything up for this employee. It may notify the network engineer, to provision the required network services like (VPN, static IPs, firewall rules, and more), in order to give a new employee a computer. Once done, he will just update the status of this task to done, which may trigger another action. It can automatically give him access to the company intranet. Once everything is done, it will notify everyone it needs to, about a successful job done, with an email or any other communication resource the company is using.
Setting Up the Flow
Let’s take it a step further, and try to replace the network engineer, who has to manually configure the services needed for the device.
In a simple environment with a few network devices, we could set up the ServiceNow® Workflow, so that it can access them directly and edit the configuration, according to the required parameters.
In a complex, multi-tenant environment we could leverage a network controller, that can serve the required service and maintain the configuration of several devices. This will make the required service functional. In that case, we will need ServiceNow® to communicate with the controller, which secures this required network service.
The ServiceNow® orchestration understands and reads REST, OpenDaylight & lighty.io – in our case, the controller. It provides us with the RESTCONF interface, with which we can easily integrate ServiceNow®, OpenDaylight, or lighty.io, thanks to the support of both these technologies.
Now, we look at how to simplify this integration. For this purpose, we used OpenAPI.
This is one of the features, thanks to which we can generate a JSON according to the OpenAPI specification for every OpenDaylight/lighty.io application with RESTCONF, which we can then import into ServiceNow®.
If your question is, whether it is possible to integrate a network controller, for example, OpenDaylight or lighty.io, the answer is yes. Yes, it is.
Example of Network Automation
Let’s say we have an application with a UI, that will let us manage the network with a control station. We want to connect a new device to it and set up its interfaces. Manually, you would have to make sure that the device is running. If not, we have to contact IT support to plug it in, create a request to connect to it. Once done, we have to create another request to set up the interfaces and verify the setup.
Using flows in ServiceNow® will let you do all that automatically. All your application needs to do, is create an incident in ServiceNow ®. This incident would be set up as a trigger, for a flow to start. It would try to create a connection using a REST request, that would be chosen from API operations, which we have from our OpenAPI JSON. This was automatically generated from YANG files, that are used in the project.
If a connection fails, then it would automatically send an email to IT support, creating a new, separate incident, that would have to be marked as done before this flow can continue. Once done, we can try to connect again using the same REST. When the connection is successful, we can choose a new API operation again, that would process the interfaces.
After that, we can choose another API operation that would get all the created settings and send that to the person, that created this incident using an email and mark this incident as done.
OpenAPI & oneOf
Since the “New York” release of ServiceNow®, the import of OpenAPI is a new feature, it has some limitations.
During usage, we noticed a few inconsistencies, which we would like to share with you. Here are some tips, what you should look out for when using this feature.
OpenAPI & ServiceNow®
OpenAPI supports the oneOf feature, which is something that is needed for choice keywords in YANG. You can choose, which nodes you want to use. Currently, the workaround for this is to use the Swagger 2.0 implementation, which does not support the oneOf feature and will list all the cases that exist in a choice statement. If you go to input variables, you may delete any input variables that you don’t want yourself.
JSONs & identical item names
Another issue is when we have a JSON that contains the same item names in different objects or levels. So if I need the following JSON:
The workaround is, to add other input variables manually, that will have the same name, like the one that is missing. Suddenly, it may appear twice in input variables, but during testing, it appears only once – where it’s supposed to. Therefore, you need to manually fill in all the missing variables using the “+” button in the input variables tab.we have the username and password twice. However, it would appear in the input variables just once. When testing the action, I was unable to fill it in like the above JSON.
Input Variables in ServiceNow®
The last issue that we have, is with ServiceNow® not requiring input variables. Imagine you create an action with REST Step. If there are some variables that you don’t need to set up, you would normally not assign any value to that variable and it would not be set.
Here, it would automatically set it to a default value or an empty string if there is no default value, which can cause some problems with decimals as well – since you should not put strings into a decimal variable.
Again, the workaround is to remove all the input variables, that you are not going to use.
This concludes our network automation with the ServiceNow guide. Leave us your feedback on this post!
You can contact us at https://pantheon.tech/
Explore our Pantheon GitHub.
Watch our YouTube Channel.
A Cloud-Native & Unified Firewall
/in Blog, CDNF.io /by PANTHEON.techby 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.
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.
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:
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.
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:
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.
Business Update: March 2020
/in News /by PANTHEON.techHere at PANTHEON.tech, we are saddened by the current situation in the world, regarding the COVID-19 outbreak and are fully supporting everybody in the front-line of this fight.
As the world is continuously relying on stable networks and improvements in technology, our day-to-day business needs to continue as usual.
Firstly, we needed to asses the situation. That is, why we have put the following, responsible counter-measures in place, as of 13th of March, 2020:
Off-Site Work: We have put our staff on off-site work. Our employees were able to utilize off-site work as a benefit at PANTHEON.tech. This way, we were sure that most of our staff would be used to this change and quickly adapt to it.
Great Software: A stable & fast VPN is a must, as well as a stable conferencing software and an efficient alternative to e-mails.
Reliable Connection: We have renewed our ISO certificates through an online-meeting system on the 27th of March, 2020. This guarantees that all standards for remote-work are also being followed. This makes off-site work and staying in touch a breeze.
Business-as-usual: PANTHEON.tech is lucky enough to work in a field, where we have the option to effectively work off-site. Our business hours are the same and work continues, as it did before.
PANTHEON.tech is continuing to strive for perfection in its solutions. It doesn’t matter if it’s in our office space, or off-site. Because our employees do not need to travel to work, they spend more time working on their own.
We miss the direct contact with our colleagues and customers but appreciate the opportunity to continue in our work. We sincerely hope that the current situation will be resolved as quickly as possible. But until then, it is business-as-usual for us.
We encourage anybody with needs within custom open-source solutions, software prototyping or network technologies to contact us. We are happy to be of assistance and create new partnerships, even in these trying times.
Nothing is changing for PANTHEON.tech – in terms of quality & delivery. We always strive for perfection.
[OpenDaylight] Sodium: A Developers Perspective
/in News, OpenDaylight /by PANTHEON.techby Robert Varga | Leave us your feedback on this post!
PANTHEON.tech continued to be the leader in terms of contributions to the OpenDaylight codebase. While our focus remained on the core platform, we also dabbled into individual plugins to deliver significant performance, scalability and correctness improvements. We are therefore glad to be a significant part of the effort that went into the newest release of OpenDaylight – Sodium.
In Sodium, we have successfully transitioned OpenDaylight codebase to require Java 11 – an effort we have been spearheading since the mid-Neon timeframe. This allows our users to not only reap the runtime improvements of Java 11 (which was possible to do with Sodium), but it allows OpenDaylight code to take advantage of features available in Java 11.
Our continued stewardship of YANG Tools has seen us deliver multiple improvements and new features, most notable of which are:
YANG Parser: has been extended to support Errata 5617 leaf-ref path expressions, which violate RFC7950, but are used by various models seen in the wild — such as ETSI NFV models. YANG parser has also received some improvements in areas of CPU and memory usage when faced with large models, ranging from 10 to 25%, depending on the models and features used.
In-memory Data Tree: the technology underlying most datastore implementations. It has been improved in multiple areas, yielding an overall memory footprint reduction of 30%. This allows better out-of-the-box scalability.
Adoption of Java 11: Java has allowed PANTHEON.tech to deploy improvements to MD-SAL Binding runtime, resulting in measurably faster dispatch of methods across the system, providing benefits to all OpenDaylight plugin code.
We have also continued improvements in the Distributed Datastore. We achieved further improvements to the persistence format, reducing in-memory & on-disk footprint by as much as 25%.
Last but not least, we have taken a hard look at the OVSDB project and provided major refactors of the codebase. This has immensely improved its ability to scale the number of connected devices, as well as individual connection throughput.
If you would like a custom OpenDaylight integration, feel free to contact us!
memif + T-REX: CNF Testing Made Easy
/in CDNF.io, News /by PANTHEON.techPANTHEON.tech’s developer Július Milan has managed to integrate memif into the T-REX Traffic Generator. T-REX is a traffic generator, which you can use to test the speed of network devices. Now you can test Cloud-Native Functions, which support memif natively in the cloud, without specialized network cards!
Imagine a situation, where multiple cloud-native functions are interconnected or chained via memif. Tracking their utilization would be a nightmare. With our memif + T-REX solution, you can make arbitrary measurements – effortlessly and straightforward. The results will be more precise and direct, as opposed to creating adapters and interconnecting them, in order to be able to measure traffic.
Our commitment to open-source has a long track record. With lighty-core being open-sourced and our CTO Robert Varga being the top-single contributor to OpenDaylight source code, we are proving once again that our heart belongs to the open-source community.
memif, the “shared memory packet interface”, allows for any client (VPP, libmemif) to communicate with DPDK using shared memory. Our solution makes memif highly efficient, with zero-copy capability. This saves memory bandwidth and CPU cycles while adding another piece to the puzzle for achieving a high-performance CNF.
It is important to note, that zero-copy works on the newest version of DPDK. However, memif & T-REX can be used in zero-copy mode, when the T-REX side of the pair is the master. The other side of the memif pair (VPP or some cloud-native function) is the zero-copy slave.
T-REX, developed by Cisco, solves the issue of buying stateful/realistic traffic generators, which can set your company back by up to 500 000$. This limits the testing capabilities and slows down the entire process. T-REX solves this by being an accessible, open-source, stateful/stateless traffic generator, fueled by DPDK.
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 may curb costs since you do not have to create and maintain your servers in a dedicated, physical space.
PANTHEON.tech is proud to be a technology enabler, with continuous support for open-source initiatives, communities & solutions.
You can contact us at https://pantheon.tech/
Explore our Pantheon GitHub.
Watch our YouTube Channel.
lighty.io: The Future of SDN-C | ONAP
/in SDN-C /by PANTHEON.techVPP 105: Memory Management & DPDK APIs
/in Blog, VPP /by PANTHEON.techWelcome to the 5th part of our VPP Guide series! Today, we will be asking ourselves practical questions regarding the various technologies & libraries managed in VPP – their usage, advantages, and management. Let’s jump right into it and ask ourselves:
Hugepages
Hugepages is one of the techniques used in virtual memory management. In a standard environment, CPU allocates memory (virtual) for each process. Those blocks of memory are called „pages“ and for efficiency in Linux kernel the size of allocated memory is 4kB. When a process wants to access its memory, CPU has to find where this virtual memory is – this is the task of Memory Management Unit and page table lookup. Using the page table structure CPU could map virtual to physical memory.
For example, when the process needs 1GB of memory, this leads to more than 200k of pages in the page table which the CPU has to lookup for. Of course, this leads to performance slowdown. Fortunately, nowadays CPUs support bigger pages – so-called Hugepages. They can reduce the number of pages to be lookup for and usage of huge pages increases performance.
Memory Management Unit uses one additional hardware cache – Translation Lookaside Buffers (TLB). When there is address translation from virtual memory to physical memory, translation is calculated in MMU, and this mapping is stored in the TLB. So next time accessing the same page will be first handled by TLB (which is fast) and then by MMU.
As TLB is a hardware cache, it has a limited number of entries, so a large number of pages will slow down the application. So a combination of TLB with Hugepages reduces the time it takes to translate a virtual page address to a physical page address and to lookup for and so again it will increase performance.
This is the reason why DPDK, and VPP as well, uses Hugepages for large memory pool allocation, used for packet buffers. By using Hugepages allocations, performance is increased since fewer pages and fewer lookups are needed and the management is more effective.
Cache prefetching
Cache prefetching is another technique used by VPP to boost execution performance. Prefetching data from their original storage in slower memory to a faster local memory before it is actually needed significantly increase performance. CPUs have fast and local cache memory in which prefetched data is held until it is required. Examples of CPU caches with a specific function are the D-cache (data cache), I-cache (instruction cache) and the TLB (translation lookaside buffer) for the MMU. Separated D-cache and I-cache makes it possible to fetch instructions and data in parallel. Moreover, instructions and data have different access patterns.
Cache prefetching is used mainly in nodes when processing packets. In VPP, each node has a registered function responsible for incoming traffic handling. An example of registration (abf and flowprobe nodes):
In abf processing function, we can see single loop handling – it loops over packets and handles them one by one.
In flowprobe node, we can see quad/single loop using prefetching which can significantly increase performance. In the first loop:
it processes buffers b0 and b1 (and moreover, the next two buffers are prefetched), and in the next loop
remaining packets are processed.
VPP I/O Request Handling
I/O device (NIC) event handling is a significant part of VPP. The CPU doesn’t know when an I/O event can occur, but it has to respond. There are two different approaches – IRQ and Polling, which are different from each other in many aspects.
From a CPU point of view, IRQ seems to be better, as the device disturbs the CPU only when it needs servicing, instead of constantly checking device status in case of polling. But from an efficiency point of view, interruptions are inefficient when the devices keep on interrupting the CPU repeatedly and polling is inefficient when the CPU device is rarely ready for servicing.
As in the case of packet processing in VPP, it is expected that traffic will be permanent. In such a case, the number of interruptions would rapidly increase. On the other hand, the device will be ready for service all the time. So polling seems to be more efficient for packet processing and it is the reason why VPP uses polling when processing the incoming packet.
VPP & DPDK
DPDK networking drivers are classified in two categories:
The DPDK ethdev layer exposes APIs, in order to use the networking functions of these devices. For a full list of the supported features and APIs, click here.
In VPP, DPDK support has been moved from core to plugin to simplify enabling/disabling and handling DPDK interfaces. To simplify and store all DPDK relevant info, a DPDK device implementation (src/plugin/dpdk/device/dpdk.h) has a structure with DPDK data:
containing all relevant DPDK structs used in VPP, to store DPDK relevant info.
DPDK APIs are used in the DPDK plugin only. Here is a list of DPDK features and their API’s used in VPP, with a few examples of usage.
Speed Capabilities / Runtime Rx / Tx Queue Setup
Supports getting the speed capabilities that the current device is capable of. Supports Rx queue setup after the device started.
API: rte_eth_dev_info_get()
Link Status
Supports getting the link speed, duplex mode and link-state (up/down).
API: rte_eth_link_get_nowait()
Lock-Free Tx Queue
If a PMD advertises DEV_TX_OFFLOAD_MT_LOCKFREE capable, multiple threads can invoke rte_eth_tx_burst() concurrently on the same Tx queue without SW lock.
API: rte_eth_tx_burst()
Promiscuous Mode
Supports enabling/disabling promiscuous mode for a port.
API: rte_eth_promiscuous_enable(), rte_eth_promiscuous_disable(), rte_eth_promiscuous_get()
Allmulticast Mode
Supports enabling/disabling receiving multicast frames.
API: rte_eth_allmulticast_enable(), rte_eth_allmulticast_disable(), rte_eth_allmulticast_get()
Unicast MAC Filter
Supports adding MAC addresses to enable white-list filtering to accept packets.
API: rte_eth_dev_default_mac_addr_set(), rte_eth_dev_mac_addr_add(), rte_eth_dev_mac_addr_remove(), rte_eth_macaddr_get()
VLAN Filter
Supports filtering of a VLAN Tag identifier.
API: rte_eth_dev_vlan_filter()
VLAN Offload
Supports VLAN offload to hardware.
API: rte_eth_dev_set_vlan_offload(), rte_eth_dev_get_vlan_offload()
Basic Stats
Support basic statistics such as: ipackets, opackets, ibytes, obytes, imissed, ierrors, oerrors, rx_nombuf. And per queue stats: q_ipackets, q_opackets, q_ibytes, q_obytes, q_errors.
API: rte_eth_stats_get, rte_eth_stats_reset()
Extended Stats
Supports Extended Statistics, changes from driver to driver.
API: rte_eth_xstats_get(), rte_eth_xstats_reset(), rte_eth_xstats_get_names, rte_eth_xstats_get_by_id(), rte_eth_xstats_get_names_by_id(), rte_eth_xstats_get_id_by_name()
Module EEPROM Dump
Supports getting information and data of plugin module eeprom.
API: rte_eth_dev_get_module_info(), rte_eth_dev_get_module_eeprom()
VPP Library (vlib)
Vlib is a vector processing library. It also handles various application management functions:
Vlib also implements the debug CLI.
In VPP (vlib), a vector is an instance of the vlib_frame_t type:
As shown, vectors are dynamically resized arrays with user-defined “headers”. Many data structures in VPP (buffers, hash, heap, pool) are vectors with different headers.
The memory layout looks like this:
Vectors are not only used in vppinfra data structures (hash, heap, pool, …) but also in vlib – in nodes, buffers, processes and more.
Buffers
Vlib buffers are used to reach high performance in packet processing. To do so, one allocates/frees N-buffers at once, rather than one at a time – except for directly processing specific buffer (its packets in given node), one deals with buffer indices instead of buffer pointers. Vlib buffers have a structure of a vector:
Each vlib_buffer_t (packet buffer) carries the buffer metadata, which describes the current packet-processing state.
There are several functions to get data from vector (vlib/node_funcs.h):
To get a pointer to frame vector data
Get pointer to scalar data
Translate the buffer index into buffer pointer
Get the pointer to current (packet) data from a buffer to process
Get vnet primary buffer metadata in the reserved opaque field
An example to retrieve vnet buffer data:
Get vnet primary buffer metadata in reserved opaque2 field
Let’s take a look at flowprobe node processing function. Vlib functions always start with a vlib_ prefix.
Nodes
As we said – vlib is also designed for graph node management. When creating a new feature, one has to initialize it, using the VLIB_INIT_FUNCTION macro. This constructs a vlib_node_registration_t, most often via the VLIB_REGISTER_NODE macro. At runtime, the framework processes the set of such registrations into a directed graph.
Type member in node registration specifies the purpose of the node:
The initialization of feature is executed at some point in the application’s startup. However, constraints must be used to specify an order (when one feature has to be initialized after/before another one). To hook feature into specific feature arc VNET_FEATURE_INT macro can be used.
Since VLIB_NODE_TYPE_INPUT nodes are the starting point of a feature arc, they are responsible for generating packets from some source, like a NIC or PCAP file and injecting them into the rest of the graph.
When registering a node, one can provide a .next_node parameter with an indexed list of the upcoming nodes in the graph. For example, a flowprobe node below:
vnet_feature_next is commonly used to select the next node. This selection is based on the feature mechanism, as in the flowprobe example above:
The graph node dispatcher pushes the work-vector through the directed graph, subdividing it as needed until the original work-vector has been completely processed.
Graph node dispatch functions call vlib_get_next_frame to set (u32 *)to_next to the right place in the vlib_frame_t, corresponding to the ith arc (known as next0) from the current node, to the indicated next node.
Before a dispatch function returns, it’s required to call vlib_put_next_frame for all of the graph arcs it actually used. This action adds a vlib_pending_frame_t to the graph dispatcher’s pending frame vector.
Pavel Kotúček
Thank you for reading through the 5th part of our PANTHEON.tech VPP Guide! As always, feel free to contact us if you are interested in customized solutions!
You can contact us at https://pantheon.tech/
Explore our Pantheon GitHub.
Watch our YouTube Channel.
[Guide] Intro to Vector Packet Processing (VPP)
/in Blog /by PANTHEON.techWelcome to our new series on how to build and program FD.io‘s Vector Packet Processing framework, also known as VPP.
The name stems from VPP’s usage of vector processing, which can process multiple packets at a time with low latency. Single packet processing and high latency were a common occurrence in the older, scalar processing approach, which VPP aims to make obsolete.
What will this series include?
This four-part series will include the following features, with the ultimate goal on getting to know your VPP framework and adapting it to your network:
Why should I start using Vector Package Processing?
The main advantages are:
The principle of VPP is, that you can plugin a new graph node, adapt it to your networks purposes and run it right off the bat. 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.
For a full list of features, please visit the official Vector Package Processing Wiki.You can also check our previous installments on VPP integration.
Preparation of VPP packages
In order to build and start with VPP yourself, you will have to:
Enjoy and explore the repository as you wish. We will continue exploring the Binary API in the next part of our series.
You can contact us at https://pantheon.tech/
Explore our Pantheon GitHub.
Watch our YouTube Channel.
[What Is] Cloud-Native and its future
/in News /by PANTHEON.techThe 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 is Cloud-Native Ready, are you?
/in News /by PANTHEON.techlighty.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.
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:
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
/in News /by PANTHEON.techHere 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:
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.
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.
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.
[Announcement] PANTHEON.tech @ ONS EU 2019!
/in News /by PANTHEON.techPANTHEON.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:
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 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.
[News] all-lighty.io Summer 2019
/in News, SDN /by PANTHEON.techIt 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.
Match Made In Heaven: Spring Boot & lighty.io
/in News /by PANTHEON.techlighty.io brings you full NETCONF/RESTCONF stack for the Spring Boot runtime.
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:
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.
[Comparison] OpenDaylight Neon SR1 vs. SR2
/in News, OpenDaylight /by PANTHEON.techThe 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:
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.
The Future of Java
/in Blog /by PANTHEON.techby Filip Čúzy | Leave us your feedback on this post!
Oracle has made headlines and created community uproar when it announced that the Java SE platform will be undergoing major changes.
The platform has had an interesting history of release cycles. At first, releases were lead by major features. No new feature meant no release – so new features determined release dates. It took, for example, three years to reach Java SE 8 from its previous version.
Since Java 9, time-driven releases with the following patterns emerged: Long Term Support releases for a 3-year cycle & new features every 6 months. When talking about Java development, three main terms need to be taken into account:
Most importantly, the product was licensed under the Binary Code License for Oracle Java SE technologies (BCL) and switched to a monthly, subscription-based plan for commercial use.
What changed?
Java SE, in its current subscription form, features additional support & functionality for mid- to large-scale enterprises (Flight Recorder, Mission Control & more). It also provides regular security updates, to ensure up-time & stability for their environment. Users can access updates for older releases of Java SE & receive commercial support. Remember – it includes the development kit & run-time.
Omitting the subscription would mean no updates, less security & stability – if you decide to stay on Java SE 8.
Publicly available patches for Oracle Java SE 8 stopped in January 2019, which left developers with two choices: get on board with the subscription that Oracle provides, or find an alternative to suit their needs.
Oracle JDK 8 is undergoing the “End of Public Updates” process, which means there are no longer free updates for commercial use after January 2019. However, since Java SE 9, Oracle is also providing Oracle’s OpenJDK builds which are free for commercial use, and there are free OpenJDK builds from other providers like AdoptOpenJDK, Azul, IBM, Red Hat, Linux distros et al.
Alternatives
OpenJDK
Developed by Oracle, with major input from a dedicated team and the Java community (including RedHat, IBM, Apple & others), this is the open-source, GPL licensed counterpart to Oracles solution. It will follow a 6-month release cycle by Oracle, in comparison to regular updates in the Java SE subscription plan.
Even though OpenJDK is based on Java SE and is, in fact, its open-source counterpart, it could, in theory, differ from Oracle JDK. This is due to the need to keep up with Java SE’s speed of performance & stability updates. Official updates are released every six months, while contributors can contribute at any time.
The only source code for OpenJDK is located here. However, certifications from Oracle for various flavors of the platform can be attained. This opens the door for companies which have their own OpenJDK implementations and distributions of the platform: Amazon, RedHat, SAP and many more.
Different sources argue, that OpenJDK may perform better than Oracle JDK, but have less stability & security – or vice versa. But for now, OpenJDK is as close to the original Oracle JDK as we can get.
GraalVM
We are mainly excited by GraalVM, due to its polyglot virtual machine. Imagine a single virtual machine, which supports all programming languages, interoperability between them and guarantees high performance for all.
Developers are able to use whatever language they want: Java, Groovy, Rust, C or Python & more.
This polyglot virtual machine can run as a standalone instance – embedded in OpenJDK and other platforms. This polyglot-mania extends into the four objectives of the Graal VM project:
When using Quarkus, the Supersonic Subatomic, Kubernetes native Java stack, you can tailor your future apps for GraalVM.
Keep an eye out on future developments of our Quarkus example in lighty-core.
For now, the consensus seems to be that the torch has been passed to OpenJDK, because of its proven stability over the years. However, GraalVM is a nice step forward and a wonderful concept, which we will follow closely.
So – what is its future?
Our own product, lighty.io, relies on Java. Juraj Veverka, PANTHEON.tech’s resident senior developer, managed to implement a simple example in Quarkus, which uses GraalVM.
We have mentioned two, out of over 20 available JVMs in this post. Bear in mind that lighty.io does not limit you in the choice of your favorite Java Virtual Machine.
You can contact us at https://pantheon.tech/
Explore our Pantheon GitHub.
Watch our YouTube Channel.
PANTHEON.tech @ KubeCon & CloudNative Con 2019
/in Blog /by PANTHEON.techBarcelona is a wonderful city and home of several important conferences, which PANTHOEN.tech attended in the past. Rastislav Szabó & Tomáš Jančiga returned to Barcelona this year, to attend KubeCon & CloudNative Con.
With over 7700 participants, KubeCon was a massive event with lots of promising presentations. “KubeCon confirmed, that IT is moving towards cloud-native principles at high-speed”, according to Rastislav Szabó, who also held a presentation named “Network Observability with IPFIX, Prometheus and Elastic Stack“.
You can check out most of the presentations in the official KubeCon 2019 Presentation Playlist here. Many interesting topics were discussed, including CNF (Cloud Native Network Functions), Kubernetes usage & future, 5G and many more. “It is unbelievable, how many presentations we managed to go through. Each of them was a great experience – we caught up with several new trends and expanded our ideas for the future”.
There were a lot of co-located events around KubeCon, which Rastislav and Tomáš could not have missed. “We were interested, as to how the tel-co industry sees these changes towards cloud-native principles. The co-located events were a perfect platform to answer our questions.” This also allowed our delegates to talk to a lot of people and to find out, how they perceive these shifts in IT.
“At the Cloud Native Network Services Day hosted by LFN, several notable presentations fulfilled our expectations. Vodafone and their take on Cloud-Native, Mellanox presented a vision of “Accelerating Container Networking”. Others, like Orange, Ericsson & Juniper also held their own presentations which we enjoyed”, according to Tomáš & Rastislav.
As a fan of FD.io, Rastislav had to take part in the FD.io Mini Summit, which took place at the same time as KubeCon.
Another important session was the “Intro + Deep Dive BoF: Telecom User Group“, where a user-group, mailing list & GitHub repository for future collaboration were presented. The main message was, that tel-co is eager to step into the cloud-native world – but to get there, there are a lot of challenges and obstacles to overcome
We are sure, that here at PANTHEON.tech we would be more than happy to welcome new customers and present our idea of how this can be achieved.
“It was a wonderful experience and we are really looking forward to the next KubeCon & CloudNativeCon!”
You can contact us at https://pantheon.tech/
Explore our Pantheon GitHub.
Watch our YouTube Channel.
[Release] OpenDaylight Sodium, YANG Tools & MD-SAL
/in News, OpenDaylight /by PANTHEON.techIt 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 PANTHEON.tech Fellow 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.
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!
You can contact us at https://pantheon.tech/
Explore our Pantheon GitHub.
Watch our YouTube Channel.