Ex.

No : Setup your own virtual SDN lab

1(i) i) Virtualbox/Mininet Environment for SDN -
http://mininet.org

Aim:

To setup our own virtual SDN lab i) Virtualbox/Mininet Environment

for SDN - http://mininet.org
Objective:
1. Learn installation on Mininet emulator.
2. Learn basic commands in Mininet.
3. Learn how to create different topologies in Mininet.
Procedure:
Mininet is a virtual test bed enabling the development and testing of
network tools and protocols. With a single command, Mininet can
create a realistic virtual network on any type of machine (Virtual
Machine (VM), cloud-hosted, or native). Therefore, it provides. an
inexpensive solution and streamlined development running in line with
production networks1
.Mininet offers the following features:
• Fast prototyping for new networking protocols.
• Simplified testing for complex topologies without the need of buying
expensive hardware.
• Realistic execution as it runs real code on the Unix and Linux kernels.
• Open source environment backed bay large community

contributing extensive documentation.

 Figure1.Hardware network vs. Mininet emulated network.

Mininet is useful for development, teaching, and research as it is easy

to customize and interact with it through the CLI or the GUI. Mininet
was originally designed to experiment with OpenFlow2 and Software-
Defined Networking (SDN)3. This lab, however, only focuses on
emulating a simple network environment without SDN-based devices.
Mininet’s logical nodes can be connected into networks. These nodes
are sometimes called containers, or more
accurately, network namespaces. Containers consume sufficiently fewer
resources that networks of over a thousand nodes have created, running
on a single laptop. A Mininet container is a process (or group of
processes) that no longer has access to all the host system’s native
network interfaces. Containers are then assigned virtual Ethernet
interfaces, which are connected to other containers through a virtual
switch 4 Mininet connects a host and a switch using a virtual Ethernet
(veth) link. The veth link is analogous to a wire connecting two virtual
interfaces, as illustrated below.
Each container is an independent network name space, a light weight
virtualization feature that provides individual processes with separate
network interfaces, routing tables, and Address Resolution Protocol
(ARP) tables. Mininet provides network emulation opposed to
simulation, allowing all network software at any layer to be simply run
as is; i.e. nodes run the native network software of the physical
machine. On the other hand, in a simulated environment applications
and protocol implementations need to be ported to run within the
simulator before they can be used.
Invoke Mininet using the default topology
Step 1. Launch a Linux terminal by holding the Ctrl+Alt+T keys or by
clicking on the Linux terminal icon.
Step 2. To start a minimal topology, enter the command shown below.
When prompted for a password, type password and hit enter. Note that
the password will not be visible as you type it.
$sudomn
The above command starts Mininet with a minimal topology, which consists of
a switch connected to two hosts as shown below.

Figure4. Mininet’s default minimal topology

When is using the sudo mn command, Mininet initializes the topology
and launches its command line interface which looks like this:

mininet>
Step3.To display the list of Mininet CLI commands and examples on
their usage, type the The following command:

help

Step4.To display the available nodes, type the following command:

 nodes

Step 5. It is useful sometimes to display the links between the devices

in Mininet to understand the topology. Issue the command shown

below to see the available links.

Test connectivity
h1pingh2
Mininet>dump: This command shows the dump information about all
nodes available in the current Mininet network.
Creation of Topologies in mininet;
Linear topology
In mininet we have various topologies like minimal, single, reversed, linear, tree
topology etc.

• Minimal/Simple: It is the most basic topology with two hosts

and one switch. To run minimal topology We simply run the
following command in the terminal window i.e.
Sudo mn—topo minimal
Single Topology: It is the simple topology with one switch and N hosts. To run
this topology we run following command in terminal window i.e.
Sudo mn–topo single,3

• Reversed Topology: It is similar to the single connection but order

of connection between hosts and switch is reversed. To run reversed
 topology we use the command in terminal window i.e.
Sudo mn–topo reversed,3

Result:

Thus the above setup our own virtual SDN lab Virtualbox/Mininet
Environment for SDN has been successfully executed.
 Ex. No : Setup your own virtual SDN lab using ODL
1(ii) https://www.kathara.org

Aim:
To setup our own virtual SDN lab with https://www.kathara.org

Procedure:
SDN with OpenDaylight controller
Setting up the OpenDaylight controller

Figure3.1:Running the controller

 Figure3.2:Installed all required features

Figure3.3:Run the SDN network with OpenDaylight

Here, we use OpenFlow1.3 protocol, and connect to the OpenDaylight controller
setup on port 6633.

Result:
Thus the above setup our own virtual SDN using ODL has been
successfully executed.
 Ex. No :
Setup your own virtual SDN lab using GNS3
1(iii)

Aim:

To Setup your own virtual SDN lab GNS3

Step 1 : Install VMware

Install VMware Fusion (Mac) or VMware Workstation (Windows). Normally these are
paid ($$) commercial products, but SOECS has free licenses for Pacific students.

Do not use the stripped-down free VMware Player. It does not come with support for
the VIX API, which allows programs (like the GNS3 network simulator) to control the
operation of virtual machines.

VirtualBox is supported by GNS3.

Step 2: Install GNS3

Note: Install GNS3 inside your native operating system. Do not put it inside your
Ubuntu VM or you'll run into an eventual issue with nested virtual machines. We'll use
Ubuntu for class projects and homework assignments.

1. Go to https://www.gns3.com/
2. Select “Free Download"
3. Select Windows, Mac, or Linux as appropriate, and then “Download"
4. Create your GNS3 Community Account as prompted, login, and then return to
the Download page
5. Run the installer you downloaded and accept the default options. (If prompted,
permit ubridge to run as root to capture packets)

Step 3: Install GNS3 VM

After installing the base GNS3 program, you next need to install the “GNS3 VM”. It’s
a Ubuntu Linux virtual machine that has all the necessary software pre-installed that
allows you to simulate more complicated devices. This is why VMware was needed as
the first installation step - it will be doing some of the virtualization heavy lifting.

1. Go to https://www.gns3.com/software/download-vm
2. Select the image for “VMware Workstation and Fusion"
 3. Extract the .zip file
4. Launch VMware (Fusion or Workstation)
5. Select “Import” (or “Open a Virtual Machine”) and navigate to the .ovf file
("GNS3 VM.ovf") that you just downloaded and unzipped
6. Let VMware import it as a new VM. Accept the default location and accept the
default name it offers ("GNS3 VM") since that will simplify locating it later.

Step 4: GNS3 Setup

1. Launch GNS3
2. Mac: You will see the prompt “uBridge requires root permissions to interact
with network interfaces”. Say YES, that will allow us to connect GNS3 with the
real network if we desire.
3. Next, choose how to run your GNS3 network simulations. Your choices are:
1. Run appliances on my local computer
2. Run appliances in a virtual machine <- Choose this option
3. Run appliances on a remote server
4. Next, enter the GNS3 local server settings
1. The default server path, binding, and port are fine here
5. Next, enter the “GNS 3 VM” settings
1. If you correctly installed the GNS3 VM above (downloaded it, imported it
into VMware, and accepted the default name of “GNS 3”), it should be
auto-detected now. One CPU core and 2048MB of RAM should be
sufficient to accommodate all the virtual routers we might want to
simulate at any given time. Hopefully.
6. VMware should be automatically launched now, and start running the GNS 3
VM by itself. This is thanks to the VIX API that allows GNS3 to control
VMware.
7. Complete the setup wizard. Note: You can change these settings at any time by
locating the “Setup Wizard” from the application menus.

Step 5: Install Mikrotik Router into GNS3

Out of the box, GNS3 doesn’t come with any routers, just a very basic switch, hub, and
a stripped down “computer” suitable for basic network connectivity tests. That’s about
it. However, by integrating with some emulator software (QEMU) and a x86/x64
virtualization engine (VMware), it has the capability to run real operating systems for
routers. As in, you can give GNS3 the same binary image you'd load on the real router,
and (with proper configuration...) it will "just work". So, rather than working with a
facsimile of a router, you can interact with the real router software.

Let's configure GNS3 with the image of a real router from MikroTik, which is the same
vendor as the routers that are in the networking lab in CTC 214. As a bonus, unlike
certain other vendors (cough Cisco cough), their OS images are freely available and
easy to download.

First, obtain the router OS image:

1. Go to https://mikrotik.com/
2. Click on “Software"
3. Scroll down to their “Cloud Hosted Router” section. That’s just their marketing
term for a software router (Linux + their proprietary command line interface)
that could run on any old PC that has a couple of network cards in it.
4. Look at the column labeled “Stable”, and go down to the row labeled “Raw disk
image”. That’s the download link you want.
1. For example, in August 2020 the latest stable release was 6.47.1, and the
download link for the raw disk image
was https://download.mikrotik.com/routeros/6.47.1/chr-6.47.1.img.zip
5. Unzip the file

Next, configure GS3 to recognize this image as a valid router, suitable for placement
into a network diagram:

1. In GNS3, go to the Preferences window

2. Locate the QEMU section in the panel window, and under it, the section labeled
“Qemu VMs"
3. Select “New” to create a new Qemu VM template
4. Select “Run this Qemu VM on the GNS3 VM"
5. Enter a name for your image - “Mikrotik 6.47.1” is a helpful and obvious name -
and click Next
6. Select the amount of RAM for your router OS - 256MB is sufficient here, and
given that we will eventually want multiple routers, it’s best not to pick too large
of a number
7. Choose your console type - “Telnet” - and click Finish
8. Choose your disk image, which is the .img file you downloaded previously.
Allow GNS3 to copy it to the default images directory, and click Next.
9. Your template is now created, but there’s a few subtle but important network
settings to change. Locate the “Network” panel for the Mikrotik image you
created.
1. Currently it says 1 adapter (Ethernet) of type e1000. Change it to have 4
adaptors. No point in having a router with a single network interface!
Click “Edit", select the “Network” tab, and change the 1 to a 4.
2. Change the Name format from “Ethernet” to “Ether” to match the router
CLI syntax.
 3. Finally, fix an annoying display issue. GNS3 numbers its ports starting
from 0, but Mikrotik numbers its ports starting at 1. You can anticipate the
frustration if you mix this up in a lab and network data is going out across
the wrong wire to the wrong destination. To fix this, click on the
“Configure custom adapters” button and re-name the Port names
from Ethernet0,...,Ethernet3 to Ether1,..,Ether4. That will match the
Mikrotik labels in the OS.
10.Under the “General Settings” panel, change the “Category” from “End Devices”
to “Routers" so this device is in the router category.
11.Under the "General Settings" panel, change the "Symbol" that appears in the
network diagrams. Click on Browse, and under "Classic", find the icon for the
"Router".
12.Under the "General Settings" panel, change the "On Close" option from "Power
Off" (Harsh! Abrupt! Router OS will complain!) to "Send the Shutdown Signal
(ACPI)" which is gentle and orderly.
13.Select “Ok” to edit the Preferences panel entirely.

Behind the scenes, GNS3 will copy the disk image for the Mikrotik router into the
GNS VM (in VMware) that you installed previously. That VM contains all the
necessary software and settings to virtualize this router.

Now you have a router that can be added to your network!

Step 6: First Network

1. Create a “New Blank Project” and call it lab01.

2. Drag two “VPCS” (Virtual PCs) onto the blank network diagram from the panel
at left (found under the “Browse End Devices” button) . If prompted to
"Choose a server", select "GNS3 VM".
3. Drag a “Mikrotik 6.x” router onto the network diagram from the panel at left
(found under the “Browse Routers” button)
4. Using the “Add a link” button on the left panel, wire up the network using
virtual Ethernet cables! Make your network look like the network below.
o Note: The PCs only have 1 interface, so you can’t connect the wire to the
wrong port there
o Note: The Router has 4 interfaces. The ports you plug your network wires
into must be consistent with the way you configure your router in
software. For now, just carefully match the diagram. In future labs, when
you’re more comfortable, you can make port decisions on your own.
o Note: Wondering why your diagram doesn’t show port labels? Press the

“Show/Hide Interface Labels” button.

Lab 1 Network Diagram (Note: Subnet labels and dashed borders are for
informational use only)

5. Press the Start button to launch your two virtual PCs and router. All the links
should turn from RED to GREEN.
6. Press the Console Connect to All Nodes button to pull up a terminal to all
three devices. (You could right-click on each and choose Console as well, but
we need to configure all three).
At the MikroTIk console:

1. Note: We are configuring the router first, because we can’t configure the PC
network fully until the default gateway (the router) exists.
2. Enter the default Mikrotik login of admin with a blank password.
3. Select N when prompted to view the license file.
4. Configure two interfaces (corresponding to the two wires plugged in)
1. ip address add address=10.11.12.254/24 interface=ether1
2. ip address add address=20.30.40.254/24 interface=ether2
5. Print the configuration to confirm: ip address print

At the PC1 console:

1. Show the help menu for available command (recall that this is a rudimentary
simulated PC): help
2. Configure an IP address: ip 10.11.12.1/24 10.11.12.254
1. This sets up a subnet of 10.11.12/24, assigns the PC the IP address
10.11.12.1, with a default gateway of 10.11.12.254 (which is the router)
3. Show the configuration: show ip
4. Save the configuration to persist after power cycling: save

At the PC2 console:

1. Configure an IP address: ip 20.30.40.1/24 20.30.40.254

1. This sets up a subnet of 20.30.40/24, assigns the PC the IP address
20.30.40.1, with a default gateway of 20.30.40.254 (which is the router)
2. Show the configuration: show ip
3. Save the configuration to persist after power cycling: save

Finally, demonstrate the network is functional:

1. Go to the PC 1 console
2. Ping PC2 through the router: ping 20.30.40.1
3. You should see something to the effect of 84 bytes from 20.30.40.1 icmp_seq=1
ttl=63 time=2.699 ms indicating that PC2 is responding to PC1.
4. Press CTRL-C to exit

Result:

Thus the above setup our own virtual SDN using GNS3 has been
successfully executed.
 Ex. No : 2 Create a simple mininet topology with SDN controller and use
Wireshark to capture and visualize the OpenFlow messages
such as OpenFlow FLOW MOD, PACKET IN, PACKET
OUT etc.

Aim:
To create a simple mininet topology with SDN controller and use Wireshark to capture
and visualize the OpenFlow messages such as OpenFlow FLOW MOD, PACKET IN,
PACKET OUT etc.

Procedure:
Standalone Open Flow network with controller
Setup
In order to setup a local controller, the default controller “open vswitch-test controller”
was installed. This controller is setup to run in a different terminal (fig2.1) before
running the Mininet SDN network.

Figure2.1:Activating open vswitch test controller

Figure2.2:StartupSDN

Understand the network setup.

 Figure2.3:Observe nodes, network and paths

Here, we can observe an activated controller and its links in addition to the default
nodes setup insection 1.

Check the flow table of the switch.

Figure2.4:Flow table before any messages are passed

Unlike insection1, the flow table of the OVS switch is not empty. It contains a single
flow entry. Observing some fields of this entry:
Action : CONTROLLER
priority : 0
duration : 22.137s
no -packets : 12
no-byte : 976
Attempt pings between hosts.

Figure2.5:Ping between hosts

The pings are successful, and have a 0% packet loss rate. Unlike in section 1, here the
controller is taking the routing decisions and setting up the path for the package to be
sent.
Check the switch flow table after pings.

Figure2.6:Flow table after pings

The image 2.6 shows the complete flow table after pinging is done in both directions to
and from h1 and h2.
Hence, it can be observed that the first four entries are (internet control message
protocol) ICMP packet flows, the next four are (address resolution protocol) ARP
packet flows.
Each of these sets off our entries describes a particular flow of either the request
(icmp_type=8; arp_op=1) or reply (icmp_type=0; arp_op=2) from h1 to h2 and vice
versa. This can be seen by observing the fields dl src and dl dst, which gives the source
and destination data link layer (MAC) address. Alternatively, the nw src and nw dst
shows the network layer address of the flow being forwarded by the switch. Similarly,
the in port shows the port name in the SDN. Finally, the output port for a packet with
the corresponding properties of the flow entry is specified in the ‘actions’ field.
The priority of all the above mentioned flows is 1, which is higher than the controller-
bound flow with a priority of 0.The idle timeout is 60s.It is expected that this flow will
be removed from the table once this time period has passed with no activity of
transmitting packets.
It can be noted that with 5 pings done in either direction in figure 2.5 above, the n
packets of each flow type that was passed after the flow entry was set up is 4.
The last entry is the same as in figure2.4, with the expected increase in the duration,
npackets and nbytes fields. This entry will always be visible in the following sections.

Check the switch flow table after enabling background ‘snoop’.

Before running the background snoop command, we wait for the flow entries to
timeout, and get a result for ‘dpctl dump-flows’ similar to figure 2.4.We run ‘snoop &’
after this, and observe the flow table shown below. Here, the packets used by the
controller to monitor the network are listed as well. Primarily, the OFPTECHO request
and reply packets, which are used to measure network conditions and liveliness of the
network[1], are seen.

Figure2.7: Running ‘snoop’ in the background.

After some more activity has happened in the network, in the form of pings in both
directions, we can see several new flow entries that communicate between the switch
s1 and the controller c0.

Figure2.8:Flow table with snoop active after ping

The image figure2.8 above shows the first few flow entries. Below are some images
that take a look at these entries in detail. The Open Flow OFPT flow entries are of
mainly three types:
OFPT PACKET_IN: Packet sent into controller from switch.
OFPT PACKET_OUT: Packet sent out from controller to switch.
OFPT FLOW MOD: Packet sent from controller to switch to modify the state of an
Open Flow switch[1].
 Figure 2.9: OpenFlow flow entries: CLI
Highlighted in figure 2.9 are the flows that have CLI packets encapsulated inside.
First, the switch sends the packet-into the controller, encapsulating the unmatched
message. The controller then sends a flow-mod that modifies the flow table, and
returns the CLI packet with the packet-out. An icmp-csum or check-sum is used to
confirm correct reception of this packet.

Analysis with Wireshark

Two flow-mod entries created as shown in fig.3.7

Set flow entry action=port1 (c)Set flow entry action=port2
Figure3.9:Flow-mod packets

Corresponding to the two new flow entries in figure 3.7, two OFPT FLOW MOD
packets have been captured. A closer look at the content of the packet reveals that the
content is mostly identical, as shown in figures 3.9b and 3.9c, but with different port
numbers under the ”action” field.

(a)Filtering packet-in packet type (b)Components of a packet-in with an IPv6

packet
Figure3.10:Packet-in packets

Result:

Thus the creation of simple mininet topology with SDN controller and
use Wireshark to capture and visualize the OpenFlow messages such as
OpenFlow FLOW MOD, PACKET IN, PACKET OUT etc has been
successfully created.
 Ex. No : 3 Create a SDN application that uses the Northbound API to
program flow table rules on the switch for various use cases
like L2 learning switch, Traffic Engineering, Firewall etc

Aim:

To create a SDN application that uses the Northbound API to program flow table rules
on the switch for various use cases like L2 learning switch, Traffic Engineering,
Firewall etc

Procedure:

Running the L2 learning Switch

To run the L2 learning Switch inside the OpenDaylight distribution simply install
the odl-l2switch-switch-ui feature;

feature:install odl-l2switch-switch-ui

Create a network using mininet

sudo mn --controller=remote,ip=<Controller IP> --topo=linear,3 --switch

ovsk,protocols=OpenFlow13
sudo mn --controller=remote,ip=127.0.0.1 --topo=linear,3 --switch
ovsk,protocols=OpenFlow13

The above command will create a virtual network consisting of 3 switches. Each
switch will connect to the controller located at the specified IP, i.e. 127.0.0.1

sudo mn --controller=remote,ip=127.0.0.1 --mac --topo=linear,3 --switch

ovsk,protocols=OpenFlow13

The above command has the “mac” option, which makes it easier to distinguish
between Host MAC addresses and Switch MAC addresses.

Generating network traffic using mininet

h1 ping h2

The above command will cause host1 (h1) to ping host2 (h2)
pingall

pingall will cause each host to ping every other host.

Checking Address Observations

Address Observations are added to the Inventory data tree.
The Address Observations on a Node Connector can be checked through a browser or a
REST Client.

Address Observations

Checking Hosts
Host information is added to the Topology data tree.

● Host address
● Attachment point (link) to a node/switch

This host information and attachment point information can be checked through a
browser or a REST Client.
http://10.194.126.91:8080/restconf/operational/network-topology:network-topology/
topology/flow:1/

Hosts

Checking STP status of each link

STP Status information is added to the Inventory data tree.

● A status of “forwarding” means the link is active and packets are flowing on it.
● A status of “discarding” means the link is inactive and packets are not sent over
it.

The STP status of a link can be checked through a browser or a REST Client.

http://10.194.126.91:8080/restconf/operational/opendaylight-inventory:nodes/node/
openflow:1/node-connector/openflow:1:2
STP status

Mininet commands

link s1 s2 down

This will bring the link between switch1 (s1) and switch2 (s2) down

link s1 s2 up

This will bring the link between switch1 (s1) and switch2 (s2) up

link s1 h1 down

This will bring the link between switch1 (s1) and host1 (h1) down

Result:

Thus the create a SDN application that uses the Northbound API to
program flow table rules on the switch for various use cases has been
successfully executed.
 Ex. No : 4 Create a simple end-to-end network service with two VNFs
using vim-emu

Aim:

To create a simple end-to-end network service with two VNFs using vim-emu
https://github.com/containernet/vim-emu

Procedure:

Step : 1 Installation

Open vSwitch must be installed on the host on which you want to install OSM and
vim-emu.

$ sudo apt-get install openvswitch-switch

Install OSM and vim-emu

Install OSM together with the emulator.

$ ./install_osm.sh --vimemu

Start the emulator

Check if the emulator is running:

$ docker ps | grep vim-emu

If not, start it with the following command:

$ docker run --name vim-emu -t -d --rm --privileged --pid='host' --network=netosm -

v /var/run/docker.sock:/var/run/docker.sock vim-emu-img python3
examples/osm_default_daemon_topology_2_pop.py

Configure environment
You need to set the correct environment variables, i.e., you need to get the IP address
of the vim-emu container to be able to add it as a VIM to your OSM installation:

$ export VIMEMU_HOSTNAME=$(sudo docker inspect -f

'{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' vim-emu)

Step 2: Attach OSM to vim-emu

# connect OSM to emulated VIM

$ osm vim-create --name emu-vim1 --user username --password password --auth_url
http://$VIMEMU_HOSTNAME:6001/v2.0 --tenant tenantName --account_type
openstack

# list vims
$ osm vim-list
+----------+--------------------------------------+
| vim name | uuid |
+----------+--------------------------------------+
| emu-vim1 | a8175948-efcf-11e7-94ad-00163eba993f |
+----------+--------------------------------------+

Step 3: On-board example pingpong service

The example can be found in the vim-emu git repository: https://osm.etsi.org/gitweb/?

p=osm/vim-emu.git;a=summary.

# Clone the vim-emu repository containing the pingpong example

$ git clone https://osm.etsi.org/gerrit/osm/vim-emu.git
# VNFs
$ osm vnfd-create vim-emu/examples/vnfs/ping.tar.gz
$ osm vnfd-create vim-emu/examples/vnfs/pong.tar.gz

# NS
$ osm nsd-create vim-emu/examples/services/pingpong_nsd.tar.gz

# You can now check OSM's GUI to see the VNFs and NS in the catalog. Or:
$ osm vnfd-list
+-----------+--------------------------------------+
| vnfd name | id |
+-----------+--------------------------------------+
| ping | 2c632bc7-15f6-4997-a581-b9032ea4672c |
| pong | e6fe076d-9d1f-4f05-a641-44b3e09df961 |
+-----------+--------------------------------------+

$ osm nsd-list
+----------+--------------------------------------+
| nsd name | id |
+----------+--------------------------------------+
| pingpong | 776746fe-7c48-4f0c-8509-67da1f8c0678 |
+----------+--------------------------------------+

Step 4: Instantiate example pingpong service

$ osm ns-create --nsd_name pingpong --ns_name test --vim_account emu-vim1

Step 5: Check service instance

# using OSM client

$ osm ns-list
+------------------+--------------------------------------+--------------------+---------------
+-----------------+
| ns instance name | id | operational status | config status | detailed
status |
+------------------+--------------------------------------+--------------------+---------------
+-----------------+
| test | 566e6c36-5f42-4f3d-89c7-dadcca01ae0d | running | configured |
done |
+------------------+--------------------------------------+--------------------+---------------
+-----------------+

Step 6: Interact with deployed VNFs

# connect to ping VNF container (in another terminal window):

$ sudo docker exec -it mn.dc1_test-1-ubuntu-1 /bin/bash
# show network config
root@dc1_test-nsi:/# ifconfig
eth0 Link encap:Ethernet HWaddr 02:42:ac:11:00:03
inet addr:172.17.0.3 Bcast:0.0.0.0 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
 RX packets:8 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:648 (648.0 B) TX bytes:0 (0.0 B)

ping0-0 Link encap:Ethernet HWaddr 4a:57:93:a0:d4:9d

inet addr:192.168.100.3 Bcast:192.168.100.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

# ping the pong VNF over the attached management network

root@dc1_test-1-ubuntu-1:/# ping 192.168.100.4
PING 192.168.100.4 (192.168.100.4) 56(84) bytes of data.
64 bytes from 192.168.100.4: icmp_seq=1 ttl=64 time=0.596 ms
64 bytes from 192.168.100.4: icmp_seq=2 ttl=64 time=0.070 ms
--- 192.168.100.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.048/0.059/0.070/0.011 ms

Step 7: Shut down

# delete service instance

$ osm ns-delete test

Step 8: Check created vim-emu and its status

# connect to vim-emu Docker container to see its logs ( do in another terminal

window)
$ sudo docker logs -f vim-emu

# check if the emulator is running in the container

$ sudo docker exec vim-emu vim-emu datacenter list
+---------+-----------------+----------+----------------+--------------------+
| Label | Internal Name | Switch | # Containers | # Metadata Items |

+=========+=================+==========+================+=====
===============+
 | dc2 | dc2 | dc2.s1 | 0| 0|
+---------+-----------------+----------+----------------+--------------------+
| dc1 | dc1 | dc1.s1 | 0| 0|
+---------+-----------------+----------+----------------+--------------------+
# check running service
$ sudo docker exec vim-emu vim-emu compute list
+--------------+----------------------------+---------------+------------------
+-------------------------+
| Datacenter | Container | Image | Interface list | Datacenter interfaces
|

+==============+============================+===============+=
=================+=========================+
| dc1 | dc1_test.ping.1.ubuntu | ubuntu:trusty | ping0-0 | dc1.s1-eth2
|
+--------------+----------------------------+---------------+------------------
+-------------------------+
| dc1 | dc1_test.pong.2.ubuntu | ubuntu:trusty | pong0-0 | dc1.s1-eth3
|
+--------------+----------------------------+---------------+------------------
+-------------------------+

Result:
Thus the creation of a simple end-to-end network service with two VNFs using
vim-emu has been successfully executed.
 Ex. No : 5
Install OSM and onboard and
orchestrate network service.

Aim:

To install OSM and onboard and orchestrate network service.

Procedure:
Pre-requirements:

In order to install OSM, you will need, at least, a single server or VM with the
following requirements:

● RECOMMENDED: 4 CPUs, 16 GB RAM, 80GB disk and a single interface with

Internet access
● MINIMUM: 2 CPUs, 8 GB RAM, 50GB disk and a single interface with Internet
access
● Base image: Ubuntu22.04
o Ubuntu22.04 cloud image (64-bit variant required)

Ubuntu22.04 server image (64-bit variant required)

Steps to install standalone OSM client:

1. Steps to install OSM Client in Ubuntu 22.04 (RECOMMENDED)

OSM client is installed by default in the host where OSM is installed, but it can be also
installed as a standalone client in an Ubuntu 22.04 system, following the procedure
below:

# Clean the previous repos that might exist

sudo sed -i "/osm-download.etsi.org/d" /etc/apt/sources.list

# Install dependencies
sudo apt-get update
sudo apt-get install -y python3 python3-dev python3-pip

# Add OSM debian repo

curl -q -o OSM-ETSI-Release-key.gpg
https://osm-download.etsi.org/repository/osm/debian/ReleaseFIFTEEN/OSM%20ETSI
%20Release%20Key.gpg
sudo apt-key add OSM-ETSI-Release-key.gpg
sudo add-apt-repository -y "deb [arch=amd64]
https://osm-download.etsi.org/repository/osm/debian/ReleaseFIFTEEN stable devops
IM osmclient"
sudo apt-get update

# Install OSM IM and osmclient packages from deb repo

sudo apt-get install python3-osm-im python3-osmclient

# Install osmclient and osm_im dependencies via pip

sudo -H python3 -m pip install -r
/usr/lib/python3/dist-packages/osm_im/requirements.txt -r /usr/lib/python3/dist-
packages/osmclient/requirements.txt

# Install charm to be able to build OSM packages with charms

sudo snap install charm --classic
2. Steps to install OSM Client in Ubuntu 22.04 via pip (ALTERNATIVE)

# Install dependencies
sudo apt-get update
sudo apt-get install -y git wget make
sudo apt-get install -y python3 python3-dev python3-pip

# Upgrade pip to the latest version (with sudo, to install it globally for all users)
sudo -H python3 -m pip install -U pip

# Decide which version to use (e.g., v15.0)

export OSM_CLIENT_VERSION=v15.0

# Install OSM IM and its dependencies via pip (installed with sudo, to install it
globally for all users)
sudo -H python3 -m pip install -r
"https://osm.etsi.org/gitweb/?p=osm/IM.git;a=blob_plain;f=requirements.txt;hb=$
{OSM_CLIENT_VERSION}"
sudo -H python3 -m pip install "git+https://osm.etsi.org/gerrit/osm/IM.git@$
{OSM_CLIENT_VERSION}#egg=osm-im" --upgrade

# Clone osmclient repo and checkut the desired version

git clone https://osm.etsi.org/gerrit/osm/osmclient
git -C osmclient checkout ${OSM_CLIENT_VERSION}

# Install osmclient using pip

sudo -H python3 -m pip install -r osmclient/requirements.txt
sudo -H python3 -m pip install ./osmclient

# Install charm to be able to build OSM packages with charms

sudo snap install charm --classic
3. Steps to install OSM Client in RHEL

# Install dependencies
sudo dnf upgrade -y
sudo dnf install -y libcurl-devel openssl-devel
sudo dnf install -y git wget make patch gcc
sudo dnf install -y python310 python310-devel

# Upgrade pip to the latest version (with sudo, to install it globally for all users)
sudo -H python3 -m pip install -U pip

# Decide which version to use (e.g., v43.0)

export OSM_CLIENT_VERSION=v15.0

# Install OSM IM and its dependencies via pip (installed with sudo, to install it
globally for all users)
sudo -H python3 -m pip install -r
"https://osm.etsi.org/gitweb/?p=osm/IM.git;a=blob_plain;f=requirements.txt;hb=$
{OSM_CLIENT_VERSION}"
sudo -H bash -c "PATH=$PATH:/usr/local/bin python3 -m pip install
\"git+https://osm.etsi.org/gerrit/osm/IM.git@${OSM_CLIENT_VERSION}#egg=osm-
im\" --upgrade"

# Clone osmclient repo and checkut the desired version

git clone https://osm.etsi.org/gerrit/osm/osmclient
git -C osmclient checkout ${OSM_CLIENT_VERSION}

# Install osmclient using pip

sudo -H python3 -m pip install -r osmclient/requirements.txt
sudo -H python3 -m pip install ./osmclient

# Install charm to be able to build OSM packages with charms

wget -O charm.sh
"https://osm.etsi.org/gitweb/?p=osm/tests.git;a=blob;f=charm.sh;hb=$
{OSM_CLIENT_VERSION}"
sudo cp charm.sh /usr/sbin/charm
sudo chmod 755 /usr/sbin/charm
4. steps to install OSM Client for developers in Ubuntu 22.04

# Install dependencies
sudo apt-get update
sudo apt-get install -y git wget make
sudo apt-get install -y python3 python3-setuptools python3-dev python3-pip

# Upgrade pip to the latest version (with sudo, to install it globally for all users)
sudo -H python3 -m pip install -U pip

# Decide which version to use (e.g., v15.0)

export OSM_CLIENT_VERSION=v15.0

# Install OSM IM and its dependencies via pip (installed with sudo, to install it
globally for all users)
sudo -H python3 -m pip install -r
"https://osm.etsi.org/gitweb/?p=osm/IM.git;a=blob_plain;f=requirements.txt;hb=$
{OSM_CLIENT_VERSION}"
sudo -H python3 -m pip install "git+https://osm.etsi.org/gerrit/osm/IM.git@$
{OSM_CLIENT_VERSION}#egg=osm-im" --upgrade

# Clone osmclient repo and checkut the desired version

git clone https://osm.etsi.org/gerrit/osm/osmclient
cd osmclient
git checkout ${OSM_CLIENT_VERSION}

# Install osmclient directly from the repo for development purposes

python3 -m pip install --user -e osmclient -r osmclient/requirements.txt -r
osmclient/requirements-dev.txt

# Install charm to be able to build OSM packages with charm

sudo snap install charm --classic

# Logout and login so that PATH can be updated. Executable osm will be found in
/home/ubuntu/.local/bin
which osm

5. Steps to install OSM Client in Windows with WSL

OSM client can be easily installed in Windows by installing an Ubuntu distro on Linux
with Windows Subsystem for Linux (WSL).

Once WSL is installed with an Ubuntu 22.04 distro, you can install OSM following the
instruccions in (#how-to-install-osm-client-in-ubuntu-2204)

6. Steps to install OSM Client directly in Windows with Conda and Git

OSM can also be installed in Windows with Miniconda and Git

You can install both programs with Chocolatey, the package manager for Windows.
Open a CMD window and run the following commands:

choco install -y git make wget

choco install -y miniconda3
Then, open Windows environment variables > User environment variables, and add the
following entries to the Path user environment variable in order to make Conda
executables reachable from all terminals:

● C:\tools\miniconda3
● C:\tools\miniconda3\Scripts
● C:\tools\miniconda3\Library\bin
Make sure that aliases for Python are disabled in Windows Configuration. Go to
Settings > Apps > Apps & features, and click on “Manage app execution aliases”. Then
disable aliases for Python.

Open Git Bash and run the following commands to create a Conda environment with
Python 3.8 and initialize all shells to work with Conda:

conda create -n osm-env python=3.10

conda init --all
# Logout
Then install OSM client as follows:

# Install conda and install some packages via conda (which will install dependent
libraries)
conda activate osm-env

# Upgrade pip to the latest version (with sudo, to install it globally for all users)
python -m pip install -U pip
# Decide which version to use (e.g., v15.0)
export OSM_CLIENT_VERSION=v15.0

# Clone IM repo and checkut the desired version

git clone https://osm.etsi.org/gerrit/osm/IM
git -C IM checkout ${OSM_CLIENT_VERSION}

# Install OSM IM using pip

python -m pip install -r IM/requirements.txt
# make -C IM clean
python -m pip install ./IM

# Clone osmclient repo and checkut the desired version

git clone https://osm.etsi.org/gerrit/osm/osmclient
git -C osmclient checkout ${OSM_CLIENT_VERSION}

# Install osmclient using pip

python -m pip install -r osmclient/requirements.txt
# Required DLLs for python-magic
python -m pip install python-magic-bin
python -m pip install ./osmclient

# Try OSM client

python -m osmclient.scripts.osm
# Logout from Git Bash
Open Git Bash again and edit .bash_profile to activate the Conda environment
persistently. If desired, add an alias to osm executable:

conda activate osm-env

alias 'osm=python -m osmclient.scripts.osm'
That will complete OSM client installation for Windows.

Installation of Network Service Orchestration:

Software Requirements

To implement Network Service Orchestration, you require the following software:

 ● Oracle Communications Unified Inventory Management 7.3.4.

See UIM Installation Guide for installation instructions.

● Oracle Communications Design Studio 7.3.4.1

See Design Studio Installation Guide for installation instructions.

Installing Network Service Orchestration Components

Steps to install and integrate the Network Service Orchestration components:

1. Install UIM on a WebLogic server. See UIM Installation Guide for installation
instructions.
2. Navigate to the UIM_Home/cartridges/base directory and deploy the following
UIM cartridges into UIM in the order they are listed:
o ora_uim_baseextpts
o ora_uim_basemeasurements
o ora_uim_basetechnologies
o ora_uim_basespecifications
o ora_uim_baserulesets
o OracleComs_NSO_BaseCartridge

See UIM Cartridge Guide for instructions about deploying cartridges into UIM.

3. (Optional) If you want to use the sample cartridges that are provided with
Network Service Orchestration, navigate to
the UIM_Home/cartridges/sample directory and deploy the sample cartridges
into UIM.

Note:
Before deploying the sample cartridges, deploy the ora_uim_common cartridge.

See "About the Sample Network Services" for more information about the
sample cartridges provided with Network Service Orchestration.

See "Implementing the Sample Network Services" for information about

implementing the sample network services.

4. (Optional) Integrate Network Service Orchestration with northbound

applications for asynchronous communication. See "Integrating Network Service
Orchestration With Northbound Applications for Asynchronous
Communication".
 5. Integrate the VIM with Network Service Orchestration. See "Integrating the
VIM with Network Service Orchestration" for more information.
6. (Optional) Integrate the SDN controller with Network Service Orchestration.
See "Registering the SDN Controller" for more information.

Result:
Thus the above network of OSM and onboard and orchestrate network service
has been successfully installed.