Page History

...

Before starting, make sure to have ONOS v2.2.0 or later on your physical machine. To download, build and run ONOS, follow this guide: Developer Quick Start

...

• Name: Interface name, can be empty or unset;

• ips: List of IP addresses for this interface, it can be the default gateway of the host;

• VLAN config, it can be: vlan-untagged only, vlan-tagged only or vlan-tagged + vlan-native.

• vlan-untagged (integer): this interface consumes untagged packet only and it belongs to a specific vlan;

• vlan-tagged (integer array): this interface can consumes consume specific tagged vlans;

• vlan-native (integer): if an untagged consumes by this port, and this is an interface with vlanconfigured as vlan-tagged setup, the device will use associate this vlan vlan ID for internal useuntagged packets;

Example of Segment Routing device settings:

...

• Name: Name for segment routing device;

• ipv4(6)NodeSid: Global unique id for IP loopback, it is used as MPLS label in forwarding;

• ipv4(6)Loopback: Router loopback IP address, it should not be part of same same subnet defined on dataplane interface;

• routerMac: Globally unique Mac address. It will be used to reply ARP requests for router IP or interface IP;

• isEdgeRouter: true if this device is edge/leaf, otherwise false;

• adjacencySids: Reserved, put empty array for now.

...

onos> devices -s
id=device:bmv2:204, available=true, role=MASTER, type=SWITCH, driver=bmv2:org.onosproject.pipelines.fabric
id=device:bmv2:205, available=true, role=MASTER, type=SWITCH, driver=bmv2:org.onosproject.pipelines.fabric
id=device:bmv2:226, available=true, role=MASTER, type=SWITCH, driver=bmv2:org.onosproject.pipelines.fabric
id=device:bmv2:227, available=true, role=MASTER, type=SWITCH, driver=bmv2:org.onosproject.pipelines.fabric
onos> links
src=device:bmv2:204/1, dst=device:bmv2:226/1, type=DIRECT, state=ACTIVE, expected=false
src=device:bmv2:204/2, dst=device:bmv2:227/1, type=DIRECT, state=ACTIVE, expected=false
src=device:bmv2:205/1, dst=device:bmv2:226/2, type=DIRECT, state=ACTIVE, expected=false
src=device:bmv2:205/2, dst=device:bmv2:227/2, type=DIRECT, state=ACTIVE, expected=false
src=device:bmv2:226/1, dst=device:bmv2:204/1, type=DIRECT, state=ACTIVE, expected=false
src=device:bmv2:226/2, dst=device:bmv2:205/1, type=DIRECT, state=ACTIVE, expected=false
src=device:bmv2:227/1, dst=device:bmv2:204/2, type=DIRECT, state=ACTIVE, expected=false
src=device:bmv2:227/2, dst=device:bmv2:205/2, type=DIRECT, state=ACTIVE, expected=false

You should see exactly 4 devices, and 8 links, each one representing a direction of the 4 bidirectional links of our 2x2 fabric.

Now you should be able to ping the hosts from the Mininet shell (T3):

mininet> h1 ping h2
PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
64 bytes from 10.0.2.2: icmp_seq=1 ttl=63 time=2.90 ms
64 bytes from 10.0.2.2: icmp_seq=2 ttl=63 time=1.86 ms
...
mininet> h3 ping h4
PING 10.0.3.2 (10.0.3.2) 56(84) bytes of data.
64 bytes from 10.0.3.2: icmp_seq=1 ttl=63 time=3.69 ms
64 bytes from 10.0.3.2: icmp_seq=2 ttl=63 time=1.29 ms
...

In the meanwile, the hosts should be learned by ONOS through ARP requests:

h1 and h2 are connnected to the same leaf and they belong to the same subnet. For this reason, their packets are bridged. Let's now try to ping hosts on different leaves, to see how packets are routed across the spines. For example, let's ping h3 from h1:

mininet> h1 ping h3

The ping should NOT work, and the reason is that ONOS doesn't know the location of h3, and as such it has not installed the necessary rules to forward packets. In a more complicated Trellis setup where the DHCP Relay app is in use, ONOS can learn host information when the host is requesting an IP address using DHCP. However, in our topology IP address are assigned statically, hence ONOS only learns host information from ARP requests/replies. Indeed, while ONOS just learned the location of h1 and h2 because of the ARP packets exchanged between these two, h3 is on a different subnet, hence no ARP exchange happens between h1 and h3.

You can use the ONOS CLI to check which hosts have been discovered so far. In this case, you should see only 2 hosts, h1 and h2:

onos> hosts

onos> hosts
id=00:AA:00:00:00:01/None, mac=00:AA:00:00:00:01, locations=[device:s204/3], vlan=None, ip(s)=[10.0.2.1], innerVlan=None, outerTPID=unknown, provider=of:org.onosproject.provider.host, configured=false
id=00:AA:00:00:00:02/10,   mac=00:AA:00:00:00:02, locations=[device:s204/4], vlan=10,   ip(s)=[10.0.2.2], innerVlan=None, outerTPID=unknown, provider=of:org.onosproject.provider.host, configured=false
id=00:AA:00:00:00:03/None, mac=00:AA:00:00:00:03, locations=[device:s205/3], vlan=None, ip(s)=[10.0.3.1], innerVlan=None, outerTPID=unknown, provider=of:org.onosproject.provider.host, configured=false
id=00:AA:00:00:00:0401/20None,   mac=00:AA:00:00:00:0401, locations=[device:s205s204/43], vlan=20None,   ip(s)=[10.0.32.21], innerVlan=None, outerTPID=unknown, provider=of:org.onosproject.provider.host, configured=false

If any host was not discovered by ONOS, try send arp request by using arping tool from mininet shell:

mininet> h1 arping 10.0.2.254

The routing and bridging rules should be installed by ONOS after the hosts have been detected. All the hosts then should be able to ping themselves:

...

id=00:AA:00:00:00:02/10,   mac=00:AA:00:00:00:02, locations=[device:s204/4], vlan=10,   ip(s)=[10.0.2.2], innerVlan=None, outerTPID=unknown, provider=of:org.onosproject.provider.host, configured=false

To have ONOS discover the hosts, we can generate ARP packets by pinging the fabric interface gateway IP address from each host. For example, let's start a ping from h3:

mininet> h3 ping 10.0.3.254
PING 10.0.3.254 (10.0.3.254) 56(84) bytes of data.
64 bytes from 10.0.3.254: icmp_seq=1 ttl=64 time=73.0 ms
64 bytes from 10.0.3.254: icmp_seq=2 ttl=64 time=18.4 ms
64 bytes from 10.0.3.254: icmp_seq=3 ttl=64 time=17.7 ms
...

10.0.3.254 is the IP address associated with the leaf switch interface attached to h3. ICMP Echo Request packets are sent to ONOS as packet-ins, which in turn sends ICMP Echo Replies as packet-out. This is equivalent to pinging the interface of a traditional router but now handled in an SDN way.

In the ONOS log, you should see messages showing that the location of h3 has been discovered. Let's try again pinging from h1:

mininet> h1 ping h3
PING 10.0.3.1 (10.0.3.1) 56(84) bytes of data.
64 bytes from 10.0.3.1: icmp_seq=1 ttl=62 time=8.87 ms
64 bytes from 10.0.3.1: icmp_seq=2 ttl=62 time=8.60 ms
64 bytes from 10.0.3.1: icmp_seq=3 ttl=62 time=8.45 ms
...

To be able to ping h4, make sure to have it discovered first using the same steps fro h3.

Congratulations!

You have completed all the steps of this example.

...