Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

...

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

...

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.

 

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.

...

Running SDN-IP

...

for the first time

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

...

Code Block
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

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.

...

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

...

Code Block
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!  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.

...