Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
...
| Code Block |
|---|
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):
...
| Code Block |
|---|
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:
| Code Block |
|---|
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 |
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:
| Code Block |
|---|
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:
| Code Block |
|---|
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.