This page describes POD configuration settings / processes to use when attempting to tunnel the fabric uplink connection over the management network using the head node to NAT that uplink traffic.
Currently, CORD only works with a single leaf configuration. This is because the fabric requires a subnet per leaf, but the NFV orchestration has not yet been updated to support multiple subnets when deploying NFVs.
- Break the fabric bond interface on the head node, so that the head node will have two fabric interfaces
- Configure vRouter to route to the secondary fabric interface on the head node
- Update fabric configuration to support secondary fabric interface on head node
Before you invoke the
./gradlew -PdeployConfig=podX.yml fetch buildImages publish deploy command, there are a few changes that should be made to the existing source code.
It is unclear that these changes should be checked into the source code tree, which is why they remain here as manual edits
- XOS address pool ranges set in
$CORD_ROOT/build/platform-install/roles/xos-install/templates/cord-services.yaml.j2, should be changes from a subnet of the default fabric network
10.6.1.0/24to each having its own
Head Node - Post Deployment
After the head node is deployed, but before any compute nodes have been booted, the networking on the head node needs to be updated. Specifically the following changes should be made in
- Remove the second NIC from the
fabricinterface bond. This means deleting the the lines in the file under the interface definition that pertain to bonding
Set this interface with no IP address and to manual configuration. It should look something like:
Create a new bridge interface and assign the secondary fabric interface into that bridge as a port
10.5.1.0/24can be any subnet, but must be different than the primary subnet for the fabric.
After updating the
/etc/network/interfacesfile, you should convince the head node to accept these network changes. This can be accomplished in various ways, including rebooting the head node, or issuing the appropriate
ifconfigcommands. If you reboot the head node you will likely have to re-deploy
If you end up deploying
XOS, you want to be sure to disable network configuration in the deployment configuration file so that the changes made to the head node configuration are not overwritten. This is done by enabling the
skipTagsin the deployment configuration file for the
arprule on head node to to the switch IP for the secondary fabric interface, i.e. the
x.x.x.254address on the subnet. The MAC address used for the
arpshould be that of the leaf switch to which the head node is connected.
Boot Compute Nodes and Switches
As CORD only works with a single leaf, be sure that all compute nodes are attached to a single leaf when they bo
Fabric Configuration - Post Compute Node Boot
Once the head node is deployed, but before booting any compute nodes, the leaf spine fabric should be configures. Below is a sample of the fabric configuration utilized on the example POD. Important highlights of this configuration are:
- lines 49 - 50: Add the IPs that will be used for the created vSGs and vCPEs. This really should be all IPs in the range
10.7.1.253inclusive, but need only be the IPs actually used as you demonstrate CORD
- lines 63 - 70: A host block for the secondary fabric interface on the head node
- lines 91 - 101: Define the secondary interface on the head node as the upstream router
This sample POD was using the subnet
10.2.1.0/24 for the fabric subnet, not
10.6.1.0/24 which is often used as the default.
Restart ONOS Fabric Applications
Add Router to VRouter
Add Default Route on Compute Nodes
On each compute node, remove any default route and add the leaf IP as the default route