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:
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:
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:
The parameter nodeIdspecifies 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:
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:
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:
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.
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.
In our previous blog post, we have introduced you with a Border Gateway Protocol Route-Reflector (BGP-RR) function in SDN controller based on lighty.io. In this article, we’re going to extend the BGP function of an SDN controller with an EVPN extension in the BGP control-plane.
Functionality
This article will discuss BGP-EVPN functions in an SDN controller and how the lighty.io BGP-function can replace existing legacy route-reflectors running in service provider’s WAN/DC networks. BGP-EVPN provides:
Advanced Layer 2 MAC and Layer 3 IPreachability information capabilities in control-plane
Route-Type 2: advertising MAC/IP address, instead of traditional MAC learning mechanisms
Route-Type 5: advertising the IP prefix subnet prefix route
We’re going to show you a BGP-EVPN IP subnet routing use-case
A BGP-EVPN control-plane can also co-exist with various data-planes, such as MPLS, VXLAN, and PBB.
Use-case: Telecom Data-Center
In this blog, we’re going to show you the BGP-EVPN control-plane working together with VXLAN data-plane. The perfect use case for this combination would be a telecom data-center.
Virtual Extensible LAN (VXLAN) is an overlay technology for network virtualization. It provides Layer 2 extension over a shared Layer 3 underlay infrastructure network, by using the MAC address in an IP/User Datagram Protocol (MAC in IP/UDP) tunneling encapsulation. The initial IETF VXLAN standards defined a multicast-based flood-and-learn VXLAN without a control plane.
It relies on data-based flood-and-learn behavior for remote VXLAN tunnel endpoint (VTEP) peer-discovery and remote end-host learning. BGP-EVPN, as the control plane for VXLAN, overcomes the limitations of flood-and-learn mechanism.
Test Bed
In this demo, we will use:
five Docker containers & three Docker networks.
Docker auto-generated user-defined bridge networks with mask /16
Arista’s cEOS software, as we did in our previous demo
Remember, that an Arista cEOS switch creates an EtX port when starting up in the container, which is bridged to EthX port in Docker.
These auto-generated EtX ports are accessible and configurable from cEOS Cli and on start are in default L2 switching mode. This means they don’t have an IP address assigned.
Well, let’s expand our previous demo topology with few more network elements. Here is a list of Docker containers used in this demo:
leaf1 & leaf2: WAN switch & access/node
host1 & host2: Ubuntu VM
BGP-RR: BGP-EVPN Route Reflector
Here is a list of Docker user-defined networks used in this demo:
At the end of this blog, we want to be able to reach IP connectivity between virtual machine host1 and host2. For that, we need BGP to advertise loopback networks and VLAN information between nodes.
In this example, we are using one AS-50.
To demonstrate route-reflector EVPN functionality leaf1 & leaf2 doesn’t make an IBGP pair but creates a pair with lighty-BGP instead. This will act as a route-reflector. In VxLAN configuration we don’t set up flood vtep. This information should redistribute Route Routing to peers.
The container with lighty-BGP MUST NOT be used as forwarding node since it doesn’t know manipulate the routing table.
Configuration
This demo configuration is prepared and tested on Ubuntu 18.04.2.
Docker Configuration
Before you start, please make sure that you have Docker (download instructions, use version 18.09.6 or higher) & Postman downloaded and installed.
1. Downloadlighty-BGP Docker image. PANTHEON.tech has its own
Now, we will configure Arista cEOS switches. We will split the configuration of Arista cEOS Switches in several steps.
Click here for full configurations of Arista switches ‘leaf1‘ & ‘leaf2‘.
Ethernet interfaces & connectivity check
1. Go into the Arista switch leaf1
sudo docker exec -it leaf1 Cli
2. Set Privilege, and go to configure-mode
enable
configure terminal
3. Setup the switch’s name
hostname leaf1
4. Setup Ethernet interface. If you use more devices than your devices could be connected in another Ethernet
interface ethernet 2
no switchport
ip address 172.20.0.2/16
5. Check if BGP-RR is reachable from the configured interface.
When you can’t ping ‘BGP-RR’, check if ‘leaf1′ and ‘BGP-RR’ are located in the same Docker network, or delete the previous step and try it on another Ethernet interface.
ping 172.20.0.4 source ethernet2
6. Repeat Step 5 for ‘leaf2′ & go into the Arista switch leaf2
sudo docker exec -it leaf2 Cli
enable
config t
hostname leaf2
interface ethernet 2
no switchport
ip address 172.20.0.3/16
ping 172.20.0.4 source ethernet2
Configuring the Border Gateway Protocol
We will have identical configurations for ‘leaf1′ & ‘leaf2′. Exceptions will be highlighted in the instructions below.
1. Enable BGP in Arista switch
If you are still in the previous settings interface, go to the root of Arista configuration with repeating the “exit” command.
service routing protocols model multi-agent
ip routing
2. Setup
For ‘leaf2’, use the Router-ID ‘router-id 172.20.0.3‘
Now, we will check if all configurations were set up successfully. We will also check if VxLAN is created and the Virtual PCs are able ‘ping’ each other.
1. Check if EVPN BGP peering is established
leaf1(config)#sh bgp evpn summary
BGP summary information for VRF default
Router identifier 172.20.0.2, local AS number 50
Neighbor Status Codes: m - Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc
172.20.0.4 4 50 3 6 0 0 00:00:09 Estab 0 0
leaf2(config)#sh bgp evpn summary
BGP summary information for VRF default
Router identifier 172.20.0.3, local AS number 50
Neighbor Status Codes: m - Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd PfxAcc
172.20.0.4 4 50 267 315 0 0 00:01:16 Estab 1 1
If your devices are in the state ‘Connected‘ or ‘Active‘, then you have checked this right after you sent a request to lighty.io. Usually, it takes, at most, one minute to establish a connection.
If you still see this state, then there could be something wrong in the BGP configuration. Please check your configuration in Arista CLI, by typing command ‘show running-config‘ and compare it with the full Arista configuration above.
After you verify the Arista configuration, then there could be a problem in the BGP-RR container. This can be fixed restarting the BGP-RR container.
2. Check ip route for available loopbacks from other devices
leaf1(config)#sh ip route
VRF: default
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service,
DH - DHCP client installed default route, M - Martian,
DP - Dynamic Policy Route
Gateway of last resort is not set
C 10.10.10.1/32 is directly connected, Loopback0
B I 10.10.10.2/32 [200/0] via 172.20.0.3, Ethernet2
C 172.20.0.0/16 is directly connected, Ethernet2
leaf2(config)#sh ip route
VRF: default
Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service,
DH - DHCP client installed default route, M - Martian,
DP - Dynamic Policy Route
Gateway of last resort is not set
B I 10.10.10.1/32 [200/0] via 172.20.0.2, Ethernet2
C 10.10.10.2/32 is directly connected, Loopback0
C 172.20.0.0/16 is directly connected, Ethernet2
3. Check the VxLAN interface, if it creates and contains VTEP
leaf1#sh interfaces vxlan 1
Vxlan1 is up, line protocol is up (connected)
Hardware is Vxlan
Source interface is Loopback0 and is active with 10.10.10.1
Replication/Flood Mode is headend with Flood List Source: EVPN
Remote MAC learning via EVPN
VNI mapping to VLANs
Static VLAN to VNI mapping is
[10, 3322]
Note: All Dynamic VLANs used by VCS are internal VLANs.
Use 'show vxlan vni' for details.
Static VRF to VNI mapping is not configured
Headend replication flood vtep list is:
10 10.10.10.2
VTEP address mask is None
leaf2(config)#sh interfaces vxlan 1
Vxlan1 is up, line protocol is up (connected)
Hardware is Vxlan
Source interface is Loopback0 and is active with 10.10.10.2
Replication/Flood Mode is headend with Flood List Source: EVPN
Remote MAC learning via EVPN
VNI mapping to VLANs
Static VLAN to VNI mapping is
[10, 3322]
Note: All Dynamic VLANs used by VCS are internal VLANs.
Use 'show vxlan vni' for details.
Static VRF to VNI mapping is not configured
Headend replication flood vtep list is:
10 10.10.10.1
VTEP address mask is None
If you don’t see IP in the section ‘Headend replication flood vtep list is:‘, then the BGP-RR container is not started correctly. This problem can be fixed by removing BGP-RR container and starting it again.
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 pinghost2 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 checkrouted MAC address information.
leaf1#sh mac address-table
Mac Address Table
------------------------------------------------------------------
Vlan Mac Address Type Ports Moves Last Move
---- ----------- ---- ----- ----- ---------
10 0242.211d.8954 DYNAMIC Et1 1 0:00:54 ago
10 0242.8b29.b7ea DYNAMIC Vx1 1 0:00:40 ago
10 0242.ac12.0003 DYNAMIC Et1 1 0:00:14 ago
10 0242.ac13.0003 DYNAMIC Vx1 1 0:00:13 ago
10 ce9a.ca0c.88a1 DYNAMIC Et1 1 0:00:54 ago
Total Mac Addresses for this criterion: 5
Multicast Mac Address Table
------------------------------------------------------------------
Vlan Mac Address Type Ports
---- ----------- ---- -----
Total Mac Addresses for this criterion: 0
leaf2#sh mac address-table
Mac Address Table
------------------------------------------------------------------
Vlan Mac Address Type Ports Moves Last Move
---- ----------- ---- ----- ----- ---------
10 0242.211d.8954 DYNAMIC Vx1 1 0:00:48 ago
10 0242.8b29.b7ea DYNAMIC Et1 1 0:01:03 ago
10 0242.ac12.0003 DYNAMIC Vx1 1 0:00:22 ago
10 0242.ac13.0003 DYNAMIC Et1 1 0:00:22 ago
10 ce9a.ca0c.88a1 DYNAMIC Vx1 1 0:00:48 ago
Total Mac Addresses for this criterion: 5
Multicast Mac Address Table
------------------------------------------------------------------
Vlan Mac Address Type Ports
---- ----------- ---- -----
Total Mac Addresses for this criterion: 0
Conclusion
We have successfully shown the lighty.io BGP functionality, which is able to replace legacy Route-Reflectors. This situation can be applied to telecom data-centers and other use-cases. It demonstrates lighty.io’s versatility and usability. Contact us for more information!
We may request cookies to be set on your device. We use cookies to let us know when you visit our websites, how you interact with us, to enrich your user experience, and to customize your relationship with our website.
Click on the different category headings to find out more. You can also change some of your preferences. Note that blocking some types of cookies may impact your experience on our websites and the services we are able to offer.
Essential Website Cookies
These cookies are strictly necessary to provide you with services available through our website and to use some of its features.
Because these cookies are strictly necessary to deliver the website, refuseing them will have impact how our site functions. You always can block or delete cookies by changing your browser settings and force blocking all cookies on this website. But this will always prompt you to accept/refuse cookies when revisiting our site.
We fully respect if you want to refuse cookies but to avoid asking you again and again kindly allow us to store a cookie for that. You are free to opt out any time or opt in for other cookies to get a better experience. If you refuse cookies we will remove all set cookies in our domain.
We provide you with a list of stored cookies on your computer in our domain so you can check what we stored. Due to security reasons we are not able to show or modify cookies from other domains. You can check these in your browser security settings.
Analytics Cookies
These cookies collect information that is used either in aggregate form to help us understand how our website is being used or how effective our marketing campaigns are or to help us customize our website and application for you in order to enhance your experience.
If you do not want that we track your visit to our site you can disable tracking in your browser here:
Google Analytics:
LeadFeeder:
Other external services
We also use different external services like Google Webfonts, Google Maps, and external Video providers. Since these providers may collect personal data like your IP address we allow you to block them here. Please be aware that this might heavily reduce the functionality and appearance of our site. Changes will take effect once you reload the page.
Google Webfont Settings:
Google Map Settings:
Google reCaptcha Settings:
Vimeo and Youtube video embeds:
Privacy Policy
You can read about our cookies and privacy settings in detail on our Privacy Policy Page.
