Page tree

Have questions? Stuck? Please check our FAQ for some common questions and answers.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Welcome to the SDN-IP tutorial!

Getting Started

This tutorial is designed to be an introduction to how SDN-IP runs in practice. We'll go through starting up a simple emulated network, and we'll see how SDN-IP controls this network to move data from place to place.

If you haven't done so already, it's highly recommended that you go through the ONOS Tutorial first. This will give you some familiarity with the basic functionality of ONOS. In addition, you should read through the SDN-IP Architecture <LINK> document to get an overview of how SDN-IP works.

Hopefully you've already done the ONOS tutorial, so you already have the ONOS tutorial VM available. If not, check out the Setup your environment <LINK> section of the ONOS tutorial to get the VM ready.

The network topology

We've prepared a simple emulated Mininet topology, which contains 6 OpenFlow switches. Connected around the edges of the SDN network are 4 emulated routers. The routers run Quagga, which is an open-source routing suite. In our case we run the BGP part of Quagga on them, to simulate external BGP routers belonging to other administrative domains. The goal of SDN-IP is to be able to talk BGP with these routers in order to exchange traffic between the different external ASes.

This figure shows the topology as observed by ONOS. We can see 6 blue OpenFlow switches, and 5 hosts around the edge.

  • The host labelled "bgp" is our Internal BGP Speaker. It sits inside our SDN network, and its job is to peer with all the External BGP Routers, learn BGP routes from them, and relay those routes to the SDN-IP application running on ONOS.
  • The other four hosts, labelled r1 through r4, are the External BGP Routers. They are the border routers that reside in other networks that want to exchange traffic with us.
  • Behind each router is a host, and these are labelled h1 through h4 in Mininet. ONOS can't see these hosts, because the reside in other network that are not controlled by ONOS. 

Start up the network

Double-click the "SDN-IP Mininet" icon on the desktop to start up the network. 

We can look at the configuration of the hosts in the Mininet terminal.

mininet> h1 ip addr show
    inet brd scope global h1-eth0
mininet> h2 ip addr show
    inet brd scope global h2-eth0

Each host is in a different IP subnet. When SDN-IP is up and running, these hosts will be able to communicate with one another despite being in different networks. This is because the SDN network is able to route traffic based on BGP routes.


Also, double-click the "ONOS" icon on the desktop to start up the ONOS console. If you run the "devices" command, you should see the network has started up and connected to ONOS.

Running SDN-IP for the first time

If you try and ping between any two hosts right now, you'll notice nothing is working.

mininet> h1 ping h2
PING ( 56(84) bytes of data.
From icmp_seq=1 Destination Net Unreachable
From icmp_seq=2 Destination Net Unreachable
From icmp_seq=3 Destination Net Unreachable

Even though ONOS is running and connected to switches, there are no applications loaded so there is nothing to tell ONOS how to control the network. We can also use the summary command to verify there are no flows or intents in the network.

onos> summary
node=, version=1.0.0.SNAPSHOT
nodes=1, devices=6, links=14, hosts=5, clusters=1, paths=46, flows=0, intents=0

Install the application

First we need to install some helper applications that SDN-IP relies on. These features let ONOS read in various configuration files and respond to ARP requests on behalf of hosts.

onos> feature:install onos-app-config
onos> feature:install onos-app-proxyarp

Now lets install the SDN-IP application so we can get some traffic flowing between our networks.

onos> feature:install onos-app-sdnip

A lot happens as soon as we install the SDN-IP application. The first thing it does is install point-to-point intents to allow the external BGP peers to communicate with our internal BGP speaker. This allows the external BGP routers to relay the routes they are capable of forwarding through to SDN-IP.

We can see the routes that SDN-IP has learnt with the "routes" command.

onos> routes
prefix=, nexthop=
prefix=, nexthop=
prefix=, nexthop=

Don't worry if you don't see all of the routes straight away - sometimes it takes a minute or so for the BGP sessions to establish and advertise the routes to ONOS.

Now that ONOS has learnt some routes, it has programmed those routes into the switches using the intent API. If we look at the intent summary, we can see the different intents that SDN-IP is using.

onos> intents -s
Connectivity               total=             27   installed=        27
Connectivity               withdrawn=          0   failed=            0
Connectivity               submitted=          0   compiling=         0
Connectivity               installing=         0   recompiling=       0
Connectivity               withdrawing=        0
PointToPoint               total=             24   installed=        24
PointToPoint               withdrawn=          0   failed=            0
PointToPoint               submitted=          0   compiling=         0
PointToPoint               installing=         0   recompiling=       0
PointToPoint               withdrawing=        0
MultiPointToSinglePoint    total=              3   installed=         3
MultiPointToSinglePoint    withdrawn=          0   failed=            0
MultiPointToSinglePoint    submitted=          0   compiling=         0
MultiPointToSinglePoint    installing=         0   recompiling=       0
MultiPointToSinglePoint    withdrawing=        0
SinglePointToMultiPoint    total=              0   installed=         0
SinglePointToMultiPoint    withdrawn=          0   failed=            0
SinglePointToMultiPoint    submitted=          0   compiling=         0
SinglePointToMultiPoint    installing=         0   recompiling=       0
SinglePointToMultiPoint    withdrawing=        0
Path                       total=              0   installed=         0
Path                       withdrawn=          0   failed=            0
Path                       submitted=          0   compiling=         0
Path                       installing=         0   recompiling=       0
Path                       withdrawing=        0
LinkCollection             total=              0   installed=         0
LinkCollection             withdrawn=          0   failed=            0
LinkCollection             submitted=          0   compiling=         0
LinkCollection             installing=         0   recompiling=       0
LinkCollection             withdrawing=        0
UnknownType                total=              0   installed=         0
UnknownType                withdrawn=          0   failed=            0
UnknownType                submitted=          0   compiling=         0
UnknownType                installing=         0   recompiling=       0
UnknownType                withdrawing=        0
All                        total=             27   installed=        27
All                        withdrawn=          0   failed=            0
All                        submitted=          0   compiling=         0
All                        installing=         0   recompiling=       0
All                        withdrawing=        0

We see a total of 28 intents. The 24 PointToPointIntents are simple end-to-end flows which allow the external BGP routers to communicate with our internal BGP speaker. The three MultiPointToSinglePoint intents are the forwarding rules for the routes that we've learnt through BGP. Each route is translated into one MultiPointToSinglePoint intent which matches the traffic for that route at the ingress ports of the network, and forwards it along to the router who advertised the route to us. This is how we use routing information learnt from BGP to enable traffic to transit our network on these routes.

Now that the intents are installed, we can ping through the network. Go back to the Mininet console and try ping between a pair of hosts.

mininet> h1 ping h2
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=62 time=0.693 ms
64 bytes from icmp_seq=2 ttl=62 time=0.139 ms
64 bytes from icmp_seq=3 ttl=62 time=0.149 ms

The ping succeeds! You can try pinging between some of the other hosts such as h1, h2 and h3. We can't ping h4 yet, but we'll address that in the next section.

Advertising a new route

Now that we've got a the system up and running, let's see what happens when there's a change in the BGP routes. We're going to make one of the external routers advertise a new route, which will allow us to talk to a new host. Right now r4 is not advertising any routes, and so we can't talk to h4. Let's verify this by trying to ping h4.

mininet> h1 ping h4
PING ( 56(84) bytes of data.
From icmp_seq=1 Destination Net Unreachable
From icmp_seq=2 Destination Net Unreachable
From icmp_seq=3 Destination Net Unreachable
From icmp_seq=4 Destination Net Unreachable

Yep, looks like we can't reach h4 yet.

To make r4 advertise a new route, we have to change the configuration of the BGP router. In our case, the BGP router is a Quagga process, so we'll connect to the Quagga CLI and configure r4 to advertise a new route. (The Quagga CLI is complex and includes lots of options, but considering this is not a Quagga tutorial we don't have the time to explain too much about Quagga. If you're interested, there's material online that will help you understand Quagga).

First, from Mininet we can start up an xterm so we can connect to the Quagga CLI.

mininet> xterm r4

A little xterm window will pop up. The next few commands will by typed into this xterm window.

We can use telnet to connect to the Quagga CLI.

root@ubuntu:~# telnet localhost 2605
Connected to localhost.
Escape character is '^]'.
Hello, this is Quagga (version 0.99.23).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

User Access Verification

It will prompt for a password, which is sdnip. Once the password is entered, we'll drop into a prompt r4>

Now we can begin to configure the router to advertise a new network.

r4> enable
r4# configure terminal
r4(config)# router bgp 65004
r4(config-router)# network
r4(config-router)# exit
r4(config)# exit

Now our external router r4 has advertised a new route to our SDN network. Now we're done with the xterm window, so you can close it. Let's go back to our ONOS terminal and see if ONOS has received the new route.

onos> routes
prefix=, nexthop=
prefix=, nexthop=
prefix=, nexthop=
prefix=, nexthop=

We see the new route to has appeared in the list. Also, when SDN-IP received the route it installed a new MultiPointToSinglePoint intent into the network.

onos> intents -s
MultiPointToSinglePoint    total=              4   installed=         4
MultiPointToSinglePoint    withdrawn=          0   failed=            0
MultiPointToSinglePoint    submitted=          0   compiling=         0
MultiPointToSinglePoint    installing=         0   recompiling=       0
MultiPointToSinglePoint    withdrawing=        0

Our number of MultiPointToSinglePoint intents has increased to 4. Now let's see if we can ping to our new network.

mininet> h1 ping h4
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=62 time=0.595 ms
64 bytes from icmp_seq=2 ttl=62 time=0.182 ms
64 bytes from icmp_seq=3 ttl=62 time=0.164 ms

Great! Now we can ping to h4 which is in the network we just received through BGP. This shows that whenever the routes learnt through BGP are updated, SDN-IP reacts to the update and programs the dataplane accordingly. 

Exploring further

Thanks for completing the SDN-IP tutorial. Now that you've had a glimpse of how SDN-IP works, feel free to poke around and explore the system further. If you're looking to run SDN-IP in your own network, head over to the Users Guild <LINK> to learn more about configuring and deploying the application.

  • No labels