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.
Start up the network
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.
A picture of the topology is shown below <MAKE PICTURE>
(call out BGP speaker)
Double-click the "SDN-IP Mininet" icon on the desktop to start up the network.
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.
Installing the SDN-IP application
If you try and ping between any two hosts right now, you'll notice nothing is working.
mininet> h1 ping h2 PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data. From 192.168.1.254 icmp_seq=1 Destination Net Unreachable From 192.168.1.254 icmp_seq=2 Destination Net Unreachable From 192.168.1.254 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=127.0.0.1, version=1.0.0.SNAPSHOT nodes=1, devices=6, links=14, hosts=5, clusters=1, paths=46, flows=0, intents=0
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=192.168.1.0/24, nexthop=10.0.1.1 prefix=192.168.2.0/24, nexthop=10.0.2.1 prefix=192.168.3.0/24, nexthop=10.0.3.1 prefix=192.168.4.0/24, nexthop=10.0.4.1
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= 28 installed= 28 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= 4 installed= 4 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= 28 installed= 28 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 4 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 192.168.2.1 (192.168.2.1) 56(84) bytes of data. 64 bytes from 192.168.2.1: icmp_seq=1 ttl=62 time=0.693 ms 64 bytes from 192.168.2.1: icmp_seq=2 ttl=62 time=0.139 ms 64 bytes from 192.168.2.1: icmp_seq=3 ttl=62 time=0.149 ms
The ping succeeds!