...

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 tutorialgone through them, 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.

...

When you start the VM, you'll be presented with a login screen. (If you're already logged in to into another tutorial, please log out by clicking the bottom-left icon, clicking "Logout", then click "Logout" again).

...

We've prepared a simple emulated Mininet topology, which contains some OpenFlow switches to make up the SDN network. Connected around the edges of the SDN network are emulated routers. The routers run a piece of software called Quagga, which is an open-source routing suite. Note that it is not mandatory to use Quagga; : any software/hardware capable of speaking BGP will do. 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 ASesASs.

This figure shows the topology as observed by ONOS. We can see 6 blue OpenFlow switches, and 5 peripheral nodes with yellow icons.

• The node labelled "bgp" is our Internal 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 nodes, 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 . These are labelled h1 through h4 in Mininet. ONOS can't see these hosts, because they reside in other networks that are not controlled by ONOS. 

...

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 if 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.

...

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 the 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.

...

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 that are capable of forwarding through to SDN-IP.

...

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 learned 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.

...

We see a total of 27 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 learned 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 learned from BGP to enable traffic to transit our network on these routes.

...

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.

...

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 donwon't have the time to explain go too much about Quaggathrough it. If you're interested, there's material online that will help you understand Quagga).

...

Now our external router r4 has advertised a new route to our the SDN network. 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.

...

Great! Now we can ping to h4 which is in the network we just received through BGP. This shows that whenever the routes learnt learned through BGP are updated, SDN-IP reacts to the update updates and programs the dataplane data plane 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 user guide <LINK> to learn more about configuring and deploying the application.

...