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

[lighty.io] BGP EVPN Route-Reflector (2021)

June 22, 2021/in Blog, SDN /by PANTHEON.tech

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

Functionality

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

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

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

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

Use-case: Telecom Data-Center

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

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

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

Test Bed

Test Bed Visualization

In this demo, we will use:

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

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

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

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

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

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

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

Our Goal: Routing

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

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

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

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

Configuration

This demo configuration is prepared and tested on Ubuntu 18.04.2.

Docker Configuration

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

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

https://hub.docker.com/u/pantheontech
sudo docker pull pantheontech/lighty-rr:9.2.0-dev

2. Download the Docker image for Arista cEOS (v. 4.26.1F)

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

3. Download the Ubuntu image from DockerHub

sudo docker pull ubuntu:latest

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

sudo docker images

Preparing the Docker Environment

1. Create Docker networks

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

2. Check all Docker networks, that have been created

sudo docker network ls

3. Create containers in Docker

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

4. Connect containers to Docker networks

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

5. Start all containers

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

6. Enable permanent IPv4 forwarding in cEOS containers

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

7. Check, whether all Docker containers have started successfully

sudo docker container ls

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

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

Preparing Ubuntu Environment

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

sudo docker exec -it host[X] bash

2. Update the machine

apt-get update

3. Install the required packages

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

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

Arista cEOS Switch configuration

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

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

Ethernet interfaces & connectivity check

1. Go into the Arista switch leaf1

sudo docker exec -it leaf1 Cli

2. Set Privilege, and go to configure-mode

enable
configure terminal

3. Setup the switch’s name

hostname leaf1

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

interface ethernet 2
no switchport
ip address 172.20.0.2/16

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

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

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

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

Configuring the Border Gateway Protocol

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

1. Enable BGP in Arista switch

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

2. Setup

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

3. Setup EVPN in BGP

address-family evpn
neighbor 172.20.0.4 activate

Configuring VxLAN Interface & VLAN

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

1. Enable VLAN with ID 10.

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

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

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

3. Configure VxLAN Interface

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

4. Assign Ethernet interface to VLAN

interface Ethernet 1
switchport mode access
switchport access vlan 10

5. Share loopback 0 to BGP-RR

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

6. Configure VLAN in BGP

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

7. Save your configuration with the ‘wr‘ command in both Arista devices and restart them with the command:

sudo docker restart leaf1 leaf2

lighty.io & BGP Route Reflector

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

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

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

sudo docker attach bgp-rr

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

sudo docker start bgp-rr --attach

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

More RESTCONF commands can be found here.

Verify device state

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

1. Check if EVPN BGP peering is established

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

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

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

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

2. Check ip route for available loopbacks from other devices

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

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

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

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

Restarting BGP-RR container

1. Stop the container

sudo docker stop bgp-rr

2. Remove BGP-RR container

sudo docker rm bgp-rr

3. Create a new container

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

4. Connect BGP-RR to docker network

sudo docker network connect net3 bgp-rr

5. Start the container again

sudo docker start bgp-rr

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

sudo docker attach bgp-rr

Testing IP Connectivity

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

1. Open Virtual PC host1

sudo docker exec -it host1 bash

2. Setup IP address for this device

ip addr add 31.1.1.1/24 dev eth1

3. Perform the same configuration at host2

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

4. Try to ping host2 to host1

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

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

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

Conclusion

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

Peter Šuňa & Peter Lučanský


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

Explore our Pantheon GitHub.

Watch our YouTube Channel.

What is Network Fabric?

[What Is] Network Fabric: Automation & Monitoring

June 9, 2021/in Blog, OpenDaylight, SDN /by PANTHEON.tech

Network fabric describes a mesh network topology with virtual or physical network elements, forming a single fabric.

What is it?

This trivial metaphor does not do justice to the industry term, which describes the performance and functionality of mostly L2 & L3 network topologies. For nodes to be interconnected and reach equal connectivity between each other, the term network fabric (NF) completely omits L1 (trivial) networks.

Primary performance goals include:

  • Abundancy – sufficient bandwidth should be present, so each node achieves equal speed when communicating in the topology
  • Redundancy – a topology has enough devices, to guarantee availability and failure coverage
  • Latency – as low as it can get

For enterprises with a lot of different users and devices connected via a network, maintaining a network fabric is essential to keep up with policies, security, and diverse requirements for each part of a network.

A network controller, like OpenDaylight, or lighty.io, would help see the entire network as a single device – creating a fabric of sorts.

Types & Future

A network topology would traditionally consist of hardware devices – access points, routers, or ethernet switches. We recognize two modern variants:

  1. Ethernet NF – an ethernet, which recognizes all components in a network, like resources, paths & nodes.
  2. IP Fabric – utilizes BGP as a routing protocol & EVPN as an overlay

The major enabler of modernizing networking is virtualization, resulting in virtual network fabric. 

Virtualization (based on the concept of NFVs – network function virtualization), replaces hardware in a network topology with virtual counterparts. This in turn enables:

  • Reduced security risks & errors
  • Improved network scaling
  • Remote maintenance & support

lighty.io: Network Fabric Management & Automation

Migrating to a fabric-based, automated network is easy with PANTHEON.tech.

lighty.io provides a versatile & user-friendly SDN controller experience, for your virtualized NF.

With ease-of-use in mind and powered by JavaSE, lighty.io is the ideal companion for your NF virtualization plans.

Try lighty.io for free!

Network controllers, such as lighty.io, help you create, configure & monitor the NF your business requires.

If OpenDaylight is your go-to platform for network automation, you can rely on PANTHEON.tech to provide the best possible support, training, or integration.

PANTHEON.tech: OpenDaylight Services

 

lyv

Validate YANG Models in OpenDaylight for Free

March 1, 2021/in Blog, SDN /by PANTHEON.tech

lighty YANG Validator

Customers can create, validate and visualize the YANG data model of their application, without the need to call any other external tool – just by using the lighty.io framework.

YANG Tools helps to parse YANG modules, represent the YANG model in Java, and serialize/deserialize YANG model data. However, a custom YANG module can contain improper data that would result in an application failure. To avoid such annoying situations, PANTHEON.tech engineers created the lighty YANG Validator.

lighty.io YANG Validator

DOWNLOAD NOW!

Send download link to:

I confirm that I have read and agree to the Privacy Policy.

Subscribe to our monthly flash-news! I have read and agree to the Privacy Policy.

lighty.io, a Software Development Kit powered by OpenDaylight and developed by PANTHEON.tech, is a very useful tool to accelerate the development of Software-Defined Networking (SDN) solutions in Java.

Its LightyController component utilizes OpenDaylight’s core components, including YANGtools, that provides a set of tools and libraries for YANG modeling of the network topology, configuration, and state data as defined by YANG 1.0 and YANG 1.1 models.

Prerequisites

  1. Download the distribution from this page.
  2. Make sure to run the tool in Linux and with Java installed.
  3. Unzip the folder and read through the README.md file

What does the lighty YANG Validator offer?

The lighty YANG Validator (lighty-yang-validator) was inspired by pyang – python YANG validation tool. It checks the YANG module using the YANG Parser module. In case of any problem during parsing, the corresponding stack trace is returned to let you know what’s wrong and where.

In addition to the pyang implementation, the lighty YANG Validator, built on top of OpenDaylight’s YANG engine, checks not only the standard YANG compatibility but it validates the given module as a module compatible with lighty.io or OpenDaylight framework.

Users can choose to validate only one module or all modules within the given directory.

It’s not necessary to have all the imported and included modules of a validating module in the same path. It is possible to use -p, –path option with a path or colon-separated paths to needed module(s). YANG Validator can search for modules recursively within the file structure.

Of course, the customer can decide to search for the file just by module name instead of specifying the whole path!

Backwards Compatibility

The lighty YANG Validator allows checking the backward compatibility of the updated YANG module via –check-update-from option. Customers can select to validate backward compatibility according to RFC6020 or RFC7950.

The lighty YANG Validator can be further used for:

  • Verification of backward-compatibility for a module
  • Notification of users about module status change (removal/deprecation)

Simplify the YANG file

The YANG file is possible to simplify based on the XML payload. The resulting data model can be reduced by removing all nodes that are defined with an “if-feature”. This functionality is very useful with huge YANG files, that are tested with some basic configuration and not all schema nodes are used.

Utilization of such trimmed YANG files can significantly speed uploading of customer’s application in the development phase when the application is started repetitively. Thus, it saves overall development time. A simplified YANG file is printed out to standard output unless the output directory is defined.

User can choose between the following output types:

  • Tree in format \<status>–\<flags> \<name>\<opts> \<type> <if-features>
  • Name-Revision in format \<module_name>@\<revision>
  • List of all modules that validated module depends on
  • JSON Tree with all the node information
  • HTML Page with javascript for the visualization of the yang tree
  • YANG File / simplified YANG file

Goal: Create a stable and reliable custom application

lighty.io was developed to provide a lightweight implementation of core OpenDaylight components so customers are able to run their applications in a plain Java SE environment. PANTHEON.tech keeps working on the improvements for that framework to make its usage as easy as possible to the customers to create stable and reliable applications.

One step forward in this journey is the lighty YANG Validator – customers can create, validate and visualize the YANG data model of their application just by using the lighty.io framework without the need to call any other external tool.

Cisco NSO a lighty.io

[NSO Guide] Cisco NSO® with lighty.io

October 3, 2020/in Blog, SDN /by PANTHEON.tech

by Samuel Kontriš | Leave us your feedback on this post!

This is a continuation of our guide on the Cisco Network Service Orchestrator. In our previous article, we have shown you how to install and run Cisco NSO with three virtual devices. We believe you had time to test it out and get to know this great tool.

Now, we will show you how to use the Cisco NSO with our SDN Framework – lighty.io. You can read more about lighty.io here, and even download lighty-core from our GitHub here.

Prerequisites

This tutorial was tested on Ubuntu 18.04 LTS. In this tutorial we are going to use:

  • Java 11
  • Maven
  • Git
  • (Optional) Postman as a REST client
  • Cisco NSO, which we installed in the previous tutorial.

Get and start the lighty.io application

To get the lighty.io 11.2.0 release, clone its GitHub repository and build it with Maven.

git clone https://github.com/PANTHEONtech/lighty-core.git
cd lighty-core
git checkout 11.2.0
mvn clean install

After the build, locate the lighty-community-restconf-netconf-app artifact and unzip its distribution from the target directory:

cd lighty-examples/lighty-community-restconf-netconf-app/target
unzip lighty-community-restconf-netconf-app-11.2.0-bin.zip
cd lighty-community-restconf-netconf-app-11.2.0

Now we can start lighty.io application by running its .jar file:

java -jar lighty-community-restconf-netconf-app-11.2.0.jar

After a few seconds we should see in the logs message that everything was started successfully:

INFO [main] (Main.java:97) - lighty.io and RESTCONF-NETCONF started in 7326.731ms

The lighty.io application should now be up and running. The default RESTCONF port is 8888.

Connect Cisco NSO to the lighty.io application

To connect Cisco NSO to the lighty.io application via NETCONF protocol we must add it as a node to the configuration datastore using RESTCONF. To do this, call a PUT request on the URI:

http://localhost:8888/restconf/data/network-topology:network-topology/topology=topology-netconf/node=nso

with the payload:

{
    "netconf-topology:node":[ { 
        "node-id":"nso",
        "host":"127.0.0.1",
        "port":2022,
        "username":"admin",
        "password":"admin",
        "tcp-only":false,
        "keepalive-delay":0,
        "netconf-node-configuration:schemaless":false
    } ]
}

The parameter nodeId specifies the name, under which we will address Cisco NSO in the lighty.io application. Parameters host and port specify, where the Cisco NSO instance is running. The default username and password for Cisco NSO is admin/admin. In case you would like to change node-id be sure to change it in the URI too.

To check if Cisco NSO was connected successfully, call a GET request on the URI:

http://localhost:8888/restconf/data/network-topology:network-topology/topology=topology-netconf/node=nso

The output should look similar to this:

{
    "network-topology:node": [
        {
            "node-id": "nso",
            "netconf-node-topology:unavailable-capabilities": {...},
            "netconf-node-topology:schemaless": false,
            "netconf-node-topology:available-capabilities": {...},
            "netconf-node-topology:password": "admin",
            "netconf-node-topology:username": "admin",
            "netconf-node-topology:tcp-only": false,
            "netconf-node-topology:port": 2022,
            "netconf-node-topology:host": "127.0.0.1",
            "netconf-node-topology:keepalive-delay": 0,
            "netconf-node-topology:connection-status": "connected"
        }
    ]
}

If Cisco NSO was connected successfully, the value of the connection-status should be connected.

Activate Cisco NSO service using lighty.io

Activation of the Cisco NSO service is similar to connecting Cisco NSO to lighty.io. We are going to activate the ACL service we created in the previous tutorial, by calling PUT REST request on URI:

http://localhost:8888/restconf/data/network-topology:network-topology/topology=topology-netconf/node=nso/yang-ext:mount/services/acl-service:acl-service=myAcl

with payload:

{
    "acl-service:acl-service": [
        {
            "ACL_Name": "myAcl",
            "ACL_Direction": "in",
            "devices": [
                {
                    "device_name": "c0",
                    "interfaces": [
                        {
                            "interface_type": "GigabitEthernet",
                            "interface_number": "1/1"
                        }
                    ]
                }
            ]
        }
    ]
}

This payload is modeled in a YANG model we created together with the ACL service in our previous tutorial. Feel free to change the values of the ACL parameters (first, check what types they are in the ACL service YANG model) and if you are changing ACL_Name, don’t forget to change it in the URI too.

Unfortunately, in the time of writing this tutorial, there is a bug in the OpenDaylight NETCONF (NETCONF-568) with parsing the output from this call. It prevents lighty.io from sending a response to the RESTCONF request we sent and we need to manually stop waiting for this response in Postman (or another REST client you are using).

Now, our service should be activated! To check activated services in Cisco NSO, call a GET request on the URI:

http://localhost:8888/restconf/data/network-topology:network-topology/topology=topology-netconf/node=nso/yang-ext:mount/services/acl-service:acl-service=myAcl

In response, you should see the service we just activated. It should look similar to this:

"acl-service:acl-service": [
    {
        "ACL_Name": "myAcl",
        "ACL_Direction": "in",
        "devices": [
            {
                "device_name": "c0",
                "interfaces": [
                    {
                        "interface_type": "GigabitEthernet",
                        "interface_number": "1/1"
                    }
                ]
            }
        ],
        "directly-modified": {
            "devices": [
                "c0"
            ]
        },
        "device-list": [
            "c0"
        ],
        "modified": {
            "devices": [
                "c0"
            ]
        }
    }
]

To check if the device was configured, log into Cisco NSO CLI and execute a show command:

ncs_cli -u admin
show configuration devices device c0 config ios:interface

You should see an output, similar to this:

admin@ncs> show configuration devices device c0 config ios:interface
FastEthernet 1/0;
GigabitEthernet 1/1 {
    ip {
        access-group {
            access-list myAcl;
            direction   in;
        }
    }
}

A Postman collection containing all REST requests we executed in this tutorial can be found here or downloaded directly from here.

Today we showed you how to connect Cisco NSO with lighty.io. Up next, our tutorial will depict how to connect ONAP SDN-C with Cisco NSO.

Leave us your feedback on this post!

10/03/2020 Update: Added the video demonstration, enjoy!


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

Explore our Pantheon GitHub.

Watch our YouTube Channel.

SDN vs. NFV

[What Is] SDN & NFV

August 26, 2020/in Blog, SDN /by PANTHEON.tech

by Filip Čúzy | Leave us your feedback on this post!

For newcomers to our blog – welcome to a series on explanations from the world of PANTHEON.tech software development. Today, we will be looking at what software-defined networking is – what it stands for, it’s past, present, future – and more.

What is SDN – Software Defined Networking?

Networks can exponentially scale and require around the clock troubleshooting, in case something goes wrong – which always can. Software-Defined Networking is a concept of decluttering enterprises of physical network devices and replacing them with software. The goal is to improve the traditional network management and ease the entire process by removing pricey, easily obsolete hardware and replace it with their virtualized counterparts.

The core component is the control plane, which encompasses one (or several) controllers, like OpenDaylight. This makes centralization of the network a breeze and provides an overview of its entirety. The main benefits of utilizing SDN are:

  • Centralization
  • Open Standards
  • Scheduling

Most network admins can relate to the feeling when you have to manage multiple network devices separately, with different ones requiring proprietary software and making your network a decentralized mess. Utilizing SDN enables you to make use of a network controller and centralize the management, security, and other aspects of your network in one place.

Network topologies enable full control of the network flow. Bandwidth can be managed to go where it needs, but it does not end there – network resources, in general, can be secured, managed, and optimized, in order to accommodate current needs. Scheduling or programmability is what differs software-defined networking from a traditional network approach.

Open standards let you know, that you do not have to rely on one hardware provider, with vendor-specific protocols and devices. Projects, such as OpenDaylight, which has been around since 2013, with contributions from major companies like Orange, RedHat, but with leading contributions from PANTHEON.tech. Being an open-source project, you can rely on the community of expert technicians on perfecting the solution with each commit or pull request.

You are also free to modify OpenDaylight yourself, but it gets easier with features from lighty.io, commercial support, or training.

The idea of a software-defined network supposedly started at Stanford University, where researchers played with the idea of virtualizing the network. The idea was to virtualize the network by making the control plane and data plane two separate entities, independent of each other.

What is NFV – Network Function Virtualization?

On the other hand, NFV or Network Function Virtualization aims to replace hardware, which serves a specific purpose, with virtual network functions (Virtual Customer Premise Equipment – vCPE). Imagine getting rid of most proprietary hardware, the difficulty of upgrading each part, and making them more accessible, scalable, and centralized.

SDN & NFV go therefore hand-in-hand in most of the aspects covered, but mainly in the goal of virtualizing most parts of the network equipment or functions.

As for the future, PANTHEON.tech’s mission is to bring enterprises closer to a complete SDN & NFV coverage, with training, support, and custom network software that will make the transition easier. Contact us today – the future of networking awaits.


You can contact us here.

Explore our PANTHEON.tech GitHub.

Watch our YouTube Channel.

More @ PATHEON.tech

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