Tag Archives: NFV

vSONIC Virtual Switch on EVE-NG

SONiC is an open source network operating system based on Linux that runs on switches from multiple vendors and ASICs. SONiC offers a full-suite of network functionality, like BGP and OSPF, VXLAN that has been production-hardened in the data centers of some of the largest cloud-service providers.

The community around SONiC has been growing and includes Juniper including Apstra, Arista, Nokia, Alibaba, Comcast, Cisco, Broadcom, Nvidia-Mellanox and VMware. SONiC underpins Microsoft’s Azure networking services. According to IDC, a SONiC data-center switch market will be worth $2 billion by 2024.

Some term it as ‘Linux of Networking’.

In this blog, we will see how to spin up a sample topology using vSONIC Virtual Switch on EVE-NG.

To start with, we will use mssonic.yml file which lists the generic parameters for spinning up the instance.

  1. Copy mssonic.yml file into “/opt/unetlab/html/templates/intel” or “/opt/unetlab/html/templates/amd” based on your cpu. In my case, I am using EVE-NG on macbook so I have used Intel.

root@eve-ng:~# ls -l /opt/unetlab/html/templates/intel/ | grep mssonic

-rw-r–r– 1 root root 1993 Jul 30 22:41 mssonic.yml


2. Create a folder under “opt/unetlab/addons/qemu/” with name “mssonic-version/” like “mssonic-3.1.2”.

Keyword “mssonic” is important as using this only, eve-ng will recognize this image.

root@eve-ng:~# ls -l /opt/unetlab/addons/qemu/ | grep ms

drwxr-xr-x 2 root root 4096 Jul 30 22:48 mssonic-3.1.2



3. Gunzip the .gz file to extract the image file.

root@eve-ng:/opt/unetlab/addons/qemu/mssonic-3.1.2# gunzip sonic-vs-3.1.2.img.gz

root@eve-ng:/opt/unetlab/addons/qemu/mssonic-3.1.2# ls -l

total 2380932

-rw-r–r– 1 root root 2438070272 Jul 30 22:55 sonic-vs-3.1.2.img

4. Rename sonic-vs-3.1.2.img to virtioa.qcow2. Please make sure to rename only and don’t convert it.

root@eve-ng:/opt/unetlab/addons/qemu/mssonic-3.1.2# mv sonic-vs-3.1.2.img virtioa.qcow2

root@eve-ng:/opt/unetlab/addons/qemu/mssonic-3.1.2# ls -l

total 2380932

-rw-r–r– 1 root root 2438070272 Jul 30 22:58 virtioa.qcow2

5. Fix the permissions as usual on eve-ng.

root@eve-ng:/opt/unetlab/addons/qemu/mssonic-3.1.2# /opt/unetlab/wrappers/unl_wrapper -a fixpermissions


Now we all set to use this under EVE-NG

I have made a simple leaf-spine topology using Sonic Virtual Switches

6. Open the Eve-NG UI.

Add the new Node, and select Sonic Router as below.

7. Change any settings here if you need however defaults should be good.

8. I have built a simple Leaf-Spine topology using 4 Sonic VS.

9. Start one or more Switches and let it boot.


Connected to

Escape character is ‘^]’.

Jul 31 15:30:59.295935 2021 sonic INFO sonic-ztp[3850]: ZTP service started.

Jul 31 15:30:59.295971 2021 sonic INFO sonic-ztp[3850]: Failed to set system MAC address as the random number generator seed input.

Jul 31 15:30:59.295999 2021 sonic INFO sonic-ztp[3850]: Checking running configuration to load ZTP configuration profile.

Jul 31 15:30:59.893505 2021 sonic INFO sonic-ztp[3845]: Waiting for system online status before continuing ZTP. (This may take 30–120 seconds).

Debian GNU/Linux 9 sonic ttyS0

Jul 31 15:31:34.932822 System is ready

Jul 31 15:31:36.290136 2021 sonic INFO sonic-ztp[3845]: System is ready to respond.

Jul 31 15:31:36.308466 2021 sonic INFO sonic-ztp[3850]: Link up detected for interface Ethernet0

Jul 31 15:31:36.308525 2021 sonic INFO sonic-ztp[3850]: Link up detected for interface Ethernet1

Jul 31 15:31:36.308554 2021 sonic INFO sonic-ztp[3850]: Link up detected for interface Ethernet2

Jul 31 15:31:36.308581 2021 sonic INFO sonic-ztp[3850]: Link up detected for interface Ethernet3

Jul 31 15:31:36.308609 2021 sonic INFO sonic-ztp[3850]: Link up detected for interface Ethernet4

Jul 31 15:31:36.308637 2021 sonic INFO sonic-ztp[3850]: Link up detected for interface Ethernet5

Jul 31 15:31:36.308664 2021 sonic INFO sonic-ztp[3850]: Link up detected for interface Ethernet6

Jul 31 15:31:36.308741 2021 sonic INFO sonic-ztp[3850]: Link up detected for interface Ethernet7

Jul 31 15:31:36.308769 2021 sonic INFO sonic-ztp[3850]: Link up detected for interface Ethernet8

Jul 31 15:31:36.308821 2021 sonic INFO sonic-ztp[3850]: Link up detected for interface Ethernet9

Jul 31 15:31:36.308850 2021 sonic INFO sonic-ztp[3850]: Link up detected for interface Ethernet10

Jul 31 15:31:36.309163 2021 sonic INFO sonic-ztp[3850]: Link up detected for interface Ethernet11

Jul 31 15:31:36.340452 2021 sonic INFO sonic-ztp[3850]: Link up detected for interface Ethernet12

Jul 31 15:31:36.340489 2021 sonic INFO sonic-ztp[3850]: Link up detected for interface Ethernet13

Jul 31 15:31:36.340761 2021 sonic INFO sonic-ztp[3850]: Link up detected for interface Ethernet14

Default username/pwd – admin/YourPaSsWoRd

10. Once up and running, you would see lots of ztp related messages which can be disabled using below command.

sudo config ztp disable

sudo config save -y

11. Once done, you can go into sonic cli, using sonic-cli

admin@sonic:~$ sonic-cli



sonic# ?

  clear        Clear commands

  configure    Enter configuration mode

  copy         Perform file copy operations

  exit         Exit from the CLI

  fast-reboot  fast-reboot [options] (-h shows help)

  image        Image related commands

  logger       Enter messages into the system log

  no           No commands under Exec mode

  ping         Send ICMP ECHO_REQUEST to network hosts

  ping6        Send ICMPv6 ECHO_REQUEST to network hosts

  reboot       reboot [options] (-h shows help)

  renew        Renew commands

  show         Show running system information

  terminal     Set terminal settings

  tpcm         SONiC image installation manager

  traceroute   Print the route packets take to the host

  traceroute6  Print the route packets take to the IPv6 host

  warm-reboot  warm-reboot [options] (-h shows help)

  write        Save config


to prove its working, lets configure IP Addresses on Interfaces and see if we can ping each other.

On Leaf-1:

sonic(config)# hostname leaf-1





leaf-1# show running-configuration interface Ethernet 0


interface Ethernet0

 mtu 9100

 speed 25000

 fec none

 no shutdown

 ip address


On Spine-1:

spine-1# show running-configuration interface Ethernet0


interface Ethernet0

 mtu 9100

 speed 25000

 fec none

 no shutdown

 ip address


12. Ping the other end to find everything is working

spine-1# ping

PING ( 56(84) bytes of data.

64 bytes from icmp_seq=1 ttl=64 time=5.32 ms

64 bytes from icmp_seq=2 ttl=64 time=1.34 ms


— ping statistics —

2 packets transmitted, 2 received, 0% packet loss, time 1001ms

rtt min/avg/max/mdev = 1.349/3.336/5.323/1.987 ms


That’s all, hope you like it.. In next sessions, we can go through some more specific scenarios around it.


Software Defined Networking – SDN

SDN as I mentioned in previous discussion is to separate out the Control Plane from Router or any network component and provide the centralized place to control the whole Network Topology. You know in any Network device, we have Control Plane, Mgmt Plane and Data plane doing their own set of work (e.g in Cisco 6509 you have Line cards acting as Dataplane, Route Processor as Control Plane and Mgmt plane is how you are accessing the device via SSH/Telnet etc) and in SDN you are separating out the Control plane from these Network devices to make them only works as pure Forwarding devices.

All the routing protocols and control data is taken care by Centralized location which in SDN terminology is called “SDN Controller”. SDN Controller talks to Infrastructure (Forwarding Network devices) via Southbound APIs and Controller can talk to Applications above it via Northbound APIs as you can see in image below.


Source :-www.opennetworking.org

So you will build Applications like any software on your desktop which talks to Controller and Controller then talks to Forwarding devices via Southbound APIs. In this way you will have centralized way of communicating with Forwarding Network devices and Network devices only work will be to send the traffic from one source to destination as fast as possible without worrying about Control protocols like OSPF, BGP, ISIS etc.

Most common Southbound interface is Openflow which is Open source protocol developed by ONF (Open Networking Foundation). Network devices can be specialized hardware switches from companies like Cisco, Brocade, Juniper etc. or they can be Virtual devices (VMs) for which they are called Open vSwitch. Only requirement for Hardware switches to use with Openflow is that those switches should be able to support Openflow. There are several products in market from various hardware vendors which supports Openflow i.e. Juniper EX9200 Ethernet Switches, MX960 Router, Big Switch Networks – Big Virtual Switch and many many more.

Openflow is not the only protocol which you use for Controller to talk to Network devices; instead other protocols like SNMP, NetConfig, OVSDB are also there but most common protocol in use is Openflow only and all the companies who are currently building the Openflow support are members of ONF as I explained above.

There are various pre-built VM packages you can get today from Internet which you can run from VMware or Virtual Box and they will open the Interface from where you can create your own topologies to work with. Topologies like 1 Virtual Controller, 3 OpenvSwitches with 3 Hosts. Those VM Images will come pre-built with SDN Controllers, Open vSwitch with support for Openflow, Mininet to create and run example topologies, Wireshark, JDK 1.8, Eclipse Luna etc etc.

In next blogs, i will try to give more from hands on perspective from one of these VM Packages and will also talk about how some projects are currently using this.

Please let me know if you have any queries.

Mohit Mittal


As we are faced with more n more SDN and NFV terms in Telecom Networking these days, i thought of discussing same here and give you my understanding of what i think of these technologies.

Currently Communication service providers (CSPs) like BT, ATnT are facing numerous challenges from OTT (Over the Top) players like Netflix, Youtube, Hulu etc. CSP doesn’t get any revenues while subscribers like us use these OTT services. Still however, the infrastructure needed to handle all this growing data traffic needs to grow more to meet the expanding capacity and customer requirements. As a result, infrastructure costs are growing faster than customer/subscriber revenue growth.

Network functions Virtualization (NFV) offers a new way to design, deploy and manage networking services. NFV decouples the network functions, such as network address translation (NAT), firewall, domain name service (DNS), caching, etc., from proprietary hardware appliances, so they can run in software. (Think of GNS3 software if you have used it on your laptop). NFV is just much more that. You must have heard that Cisco or Juniper or any vendor’s hardware are some hundred thousand pounds. You can’t use Juniper Line card in Alcatel or Cisco or vice versa. This is a challenge for Service Providers. Previously Cisco or any Hardware vendor for that matter used to sell their products based upon traffic capacity they can handle like Gig, 10G per seconds however now the Dell, HP servers can meet those requirements without you having to buy the proprietary hardware from vendors like Cisco. All you need to do is take any server and run custom software on top of it which can acts as Firewall, DNS etc. etc.  NFV utilizes standard IT virtualization technologies that run on high-volume service, switch and storage hardware to virtualize network functions.

This will surely put a dent in hardware vendors profit but if they have to keep up with client expectations they have to take this turn. Offcourse there are limitations because of using server instead of dedicated vendor router but then Service providers are not going to replace their Core MPLS routers with NFV. NFV is still new to market and is in very nascent stage to understand its various usecases.


PIC Courtesy : http://www.moorinsightsstrategy.com

SDN (Software-Defined Networking) on the other hand is a concept related to NFV, but they refer to different domains. If you are aware of how any router works, you will be able to understand it very quickly. Every Router has 3 different planes. One is Management Plan, 2nd Control Plane and 3rd Forwarding Plane. Using Management Plane Router delivers Management Functions like SSH, TACACs etc. Control Plane is where all routing protocols is processed Like OSPF, BGP, RIP, etc etc. Forwarding Plane is using which Router sends/receive the Actual traffic out/in from its interfaces.

Now work of SDN is to separate out this Control Plane from Router or any network component and provide the centralized place to control the whole Network Topology. In this way the areas like Internal Data Centres of organizations where nothing much changes happens in Control Plane you can separate out this functionality from servers/network components and use servers purely for forwarding traffic as fast as possible. There are number of tools which helps in providing this functionality and with time I think we would be able to get more on that.

However SDN as a concept is not just using Openflow switches using open flow protocol.. Other vendors are implementing it as an Automatic provisioning tool using totally different concepts but still calling it as SDN as that what it is, you are using software to influence networks.

As you can see above, NFV and SDN are somewhat different concepts and can operate independently however they are generally implemented together and can act as powerful tool in today’s network environments.

That’s all for this blog. I will discuss more on these topics in later blogs. Do let me know your comments or feedback and what you think of these technologies!



Mohit Mittal