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 | ||
|---|---|---|
| ||
"apps" : {
"org.onosproject.router" : {
"router" : {
"controlPlaneConnectPoint" : "of:00000000000000b1/24",
"ospfEnabled" : "true",
"interfaces" : [ "b1-1", "b1-2" ]
}
}
},
"ports" : {
"of:00000000000000b1/25" : {
"interfaces" : [
{
"name" : "b1-1",
"ips" : [ "172.18.0.254/24" ],
"mac" : "fe:00:00:00:00:01"
}
]
},
"of:00000000000000b1/1" : {
"interfaces" : [
{
"name" : "b1-2",
"ips" : [ "172.27.0.254/24" ],
"mac" : "fe:00:00:00:00:01"
}
]
}
},
"hosts" : {
"fe:00:00:00:00:02/-1" : {
"basic": {
"ips": ["172.27.0.1"],
"location": "of:00000000000000b1/1"
}
}
} |
Line 11: Device ID and port number of the port with portName=quagga -> controlPlaneConnectPoint
Line 18: Device ID and port number of the port with portName=quagga-router or other actual uplink port
If you have a floating range, 172.27.0.0/24 in this example, check the following configurations also.
Line 27: (optional interface config for floating IP address range) Device ID and port number of the port with portName=patch-rout
Line 41: (optional interface config for floating IP gateway) Device ID and port number of the port with portName=patch-rout
...
Once you fix the vrouter.json file, re-create onos-vrouter container with the updated configuration. vrouter.sh script takes will take care of removing the existing container.
...
8. If everything's right, check fpm-connections, hosts and routes. 172.18.0.1 is the external default gateway in this example. The host with IP address 172.27.0.1 is for the floating IP but routable from outside, which will explain laterIf you added interface and host for floating IP range, you should be able to see the host in the list.
| Code Block |
|---|
onos> hosts id=FA:00:00:00:00:01/None, mac=FA:00:00:00:00:01, location=of:00000000000000b1/25, vlan=None, ip(s)=[172.18.0.1] id=FE:00:00:00:00:01/None, mac=FE:00:00:00:00:01, location=of:00000000000000b1/24, vlan=None, ip(s)=[172.18.0.254] id=FE:00:00:00:00:02/None, mac=FE:00:00:00:00:02, location=of:00000000000000b1/1, vlan=None, ip(s)=[172.27.0.1], name=FE:00:00:00:00:02/None onos> fpm-connections 172.17.0.2:52332 connected since 6m ago onos> next-hops ip=172.18.0.1, mac=FA:00:00:00:00:01, numRoutes=1 onos> routes Table: ipv4 Network Next Hop 0.0.0.0/0 172.18.0.1 Total: 1 Table: ipv6 Network Next Hop Total: 0 |
9. Add route for floating IP range manually and check the route is added.
| Code Block |
|---|
onos> route-add 172.27.0.0/24 172.27.0.1
onos> routes
Table: ipv4
Network Next Hop
0.0.0.0/0 172.18.0.1
172.27.0.0/24 172.27.0.1
Total: 2
Table: ipv6
Network Next Hop
Total: 0
onos> next-hops
ip=172.18.0.1, mac=FA:00:00:00:00:01, numRoutes=1
ip=172.27.0.1, mac=FE:00:00:00:00:02, numRoutes=1 |
10. Now you should be able to see the gateway node is in COMPLETE state when you re-trigger node initialization. You can either run command openstack-node-init gateway-01 or push the network configuration file again.
| Code Block |
|---|
onos> openstack-node-init gateway-01
onos> openstack-node-init gateway-02 |
Or
| Code Block | ||
|---|---|---|
| ||
$ curl --user onos:rocks -X POST -H "Content-Type: application/json" http://$onos-ip:8181/onos/v1/network/configuration/ -d @network-cfg.json |
| Code Block |
|---|
onos> openstack-nodes hostname=compute-01, type=COMPUTE, managementIp=10.203.25.244, dataIp=10.134.34.222, intBridge=of:00000000000000a1, routerBridge=Optional.empty init=COMPLETE hostname=compute-02, type=COMPUTE, managementIp=10.203.25.245, dataIp=10.134.34.223, intBridge=of:00000000000000a2, routerBridge=Optional.empty init=COMPLETE hostname=gateway-01, type=GATEWAY, managementIp=10.203.198.125, dataIp=10.134.33.208, intBridge=of:00000000000000a3, routerBridge=Optional[of:00000000000000b1] init=COMPLETE hostname=gateway-02, type=GATEWAY, managementIp=10.203.198.131, dataIp=10.134.33.209, intBridge=of:00000000000000a4, routerBridge=Optional[of:00000000000000b2] init=COMPLETE Total 4 nodes |
...