...
As for other ONOS applications, VPLS can be activated either:
Manually, through the ONOS Command Line (CLI), typing "app activate org.onosproject.vpls";
Automatically at ONOS start up, adding the application name "vpls" toin to the list of apps to be started automatically. Specific startup details can be defined , iin itsthe in its own cell file, on the management machine, before pushing the ONOS bits;
Manually, through the ONOS Command LIne (CLI), typing "app activate org.onosproject.vpls".
Configuring VPLS
VPLS relies on the ONOS network configuration subsystem, which is by default distributed on all ONOS nodes and shared by all ONOS applications.
In order to configure VPLS two things need to be done:
Configure two or more interfaces
Configure one or more VPLS that associate the interfaces configured together
The goal of the configuration process is to define what attachment points the hosts are connected to (so which DPID, twhich ports), and to associate them under the same overlay network, a VPLS. This will essentially determine what hosts should talk one each other (and which don’t).
Both the interfaces and the VPLS configuration itself can be applied either:
Creating a special network-cfg.json configuration file on the management machine in $ONOS/tools/package/config, before pushing the ONOS bits to the target machines. In this case - while deploying - the network-cfg.json file will be copied over the target machines and parsed;
Pushing a JSON file at run-time, using the specific REST API;
From the ONOS CLI, using the interface commands.
Configuration file format and syntax
Let’s assume the following scenario:
In this example, five hosts are sending in tagged packets with different VLAN Ids. Two networks will be created, one called VPLS-EXAMPLE-1 (VPLS1) - in green, the second one called VPLS-EXAMPLE-2 (VPLS2) - in red. Three hosts will be grouped and connected in VPLS1, while other two will be associated to VPLS2.
Hosts are grouped by VPLS in the following table:
. See example below:
Code Block | ||
---|---|---|
| ||
# Basic VPLS topology
export ONOS_NIC=192.168.56.*
export OCI="192.168.56.101"
export OC1="192.168.56.101"
export OC2="192.168.56.102"
export OCN="192.168.56.103"
export ONOS_APPS=drivers,openflow,vpls
export ONOS_GROUP=sdn
export ONOS_SCENARIOS=$ONOS/tools/test/scenarios
export ONOS_TOPO=vpls
export ONOS_USER=sdn
export ONOS_USE_SSH=true
export ONOS_WEB_PASS=rocks
export ONOS_WEB_USER=onos
topo vpls
alias vpls-reset='stc net-teardown; stc teardown; topo geant; stc setup && stc net-setup' |
Configuring VPLS
VPLS relies on the ONOS network configuration subsystem, which is by default distributed on all ONOS nodes and shared by all ONOS applications.
In order to configure VPLS two things need to be done:
Configure two or more interfaces
Configure one or more VPLS that associate the interfaces configured together
The goal of the configuration process is to define what attachment points the hosts are connected to (so which DPID, twhich ports), and to associate them under the same overlay network, a VPLS. This will essentially determine what hosts should talk one each other (and which don’t).
Both the interfaces and the VPLS configuration itself can be applied either:
Creating a special network-cfg.json configuration file on the management machine in $ONOS/tools/package/config, before pushing the ONOS bits to the target machines. In this case - while deploying - the network-cfg.json file will be copied over the target machines and parsed;
Pushing a JSON file at run-time, using the specific REST API;
From the ONOS CLI, using the interface commands.
Configuration file format and syntax
Let’s assume the following scenario:
In this example, five hosts are sending in tagged packets with different VLAN Ids. Two networks will be created, one called VPLS-EXAMPLE-1 (VPLS1) - in green, the second one called VPLS-EXAMPLE-2 (VPLS2) - in red. Three hosts will be grouped and connected in VPLS1, while other two will be associated to VPLS2.
Hosts are grouped by VPLS in the following table:
VPLS name | VLAN Id | Interface Name | OF Switch DPID | OF Port Number |
VPLS1 | 10 | vpls1h1 | 0000000000000001 | 1 |
VPLS1 | 10 | vpls1h2 | 0000000000000004 | 1 |
VPLS1 | 20 |
VPLS name | VLAN Id | Interface Name | OF Switch DPID | OF Port Number |
VPLS1 | 10 | vpls1h1 | 0000000000000001 | 1 |
VPLS1 | 10 | vpls1h2 | 0000000000000004 | 1 |
VPLS1 | 20 | vpls1h3 | 0000000000000003 | 1 |
VPLS2 | 30 | vpls2h1 | 0000000000000004 | 2 |
VPLS2 | 40 | vpls2h2 | 0000000000000002 | 1 |
...
Code Block | ||
---|---|---|
| ||
{ "ports": { "of:0000000000000001/1": { "interfaces": [ { "name": "vpls1h1", "vlan": "10" } ] }, "of:0000000000000004/1": { "interfaces": [ { "name": "vpls1h2", "vlan": "10" } ] }, "of:0000000000000004/2": { "interfaces": [ { "name": "vpls2h1", "vlan": "30" } ] }, "of:0000000000000003/1": { "interfaces": [ { "name": "vpls1h3", "vlan": "20" } ] }, "of:0000000000000002/1": { "interfaces": [ { "name": "vpls2h2", "vlan": "40" } ] } }, { "apps" : { "org.onosproject.vpls" : { "networksvpls" : [{ {"vplsNetworks" : [ { "name" : "VPLS1", "interfaces" : ["vpls1h1", "vpls1h2", “vpls1h3”"vpls1h3"] }, { "name" : "VPLS2", "interfaces" : ["vpls2h1", "vpls2h2"] } ] } } } } |
The same can be result can be achieved at run-time, using the interface configuration and VPLS CLI commands . SomeAn examples beloware as follows (see section "CLI syntax for mor " for more details):
Code Block | ||
---|---|---|
| ||
onos> interface-add -v 10 of:0000000000000001/1 vpls1h1 onos> interface-add -v 10 of:0000000000000004/1 vpls1h2 onos> interface-add -v 20 of:0000000000000003/1 vpls1h3 onos> interface-add -v 30 of:0000000000000004/2 vpls2h1 onos> interface-add -v 40 of:0000000000000002/1 vpls2h2 onos> vpls-add VPLS1 onos> vpls-add-iface VPLS1 vpls1h1 onos> vpls-add-iface VPLS1 vpls1h2 onos> vpls-add-iface VPLS1 vpls1h3 onos> vpls-add VPLS2 onos> vpls-add-iface VPLS2 vpls2h1 onos> vpls-add-iface VPLS2 vpls2h2 |
As soon as two or more interfaces are added to the same VPLS network, intents to manage broadcast will be installed.
As soon as two or more hosts connected to the same VPLS get discovered by ONOS (and VPLS), intents to manage unicast traffic will be installed.
...
VPLS allows to define networks and attach or unattach detach interfaces to them, also by command-line. There is also the option of cleaning all the state of the application for a clean start. Details on the CLI operations are detailed below:
...
Code Block | ||
---|---|---|
| ||
# Adds a new network onos> vpls-add $VPLS_NETWORK # Removes an existing network onos> vpls-del $VPLS_NETWORK # Shows the list of networks onos> vpls-list VPLS2 VPLS1 # Shows the list of attached interfaces (for a given network) or all the list of networks and interfaces in each of them the list of attached interfaces (for a given network) or all the list of networks and interfaces in each of them (if no network is provided) onos> vpls-show [$VPLS_NETWORK] VPLS2: interface=[vpls2h1, vpls2h2] VPLS1: interface=[vpls1h1, vpls1h2, vpls1h3] |
Code Block | ||
---|---|---|
| ||
# Adds an existing interface (in netcfg) to an existing network
onos> vpls-add-iface $VPLS_NETWORK $INTERFACE_NAME
# Removes an existing interface from an existing network
onos> vpls-del-iface $VPLS_NETWORK $INTERFACE_NAME
|
Issues and Troubleshooting
Things not working as expected? Time to troubleshoot!
Hosts are not communicating? Do you have at least two interfaces configured and two hosts attached - using the same VLAN Id?
Is your configuration correct? Has it been correctly parsed? The first step is to checked if the configuration has been parsed and correct running at the ONOS CLI the command "interfaces". This should give you a list of interfaces configured in the system
Any exception? Type log:exception-display in the ONOS CLI to discover it.
Are hosts connected to your OpenFlow data plane? I a host start to send out packets into the OpenFlow network you should be able to see it, even if VPLS is not installed yet or no configuration is provided. Go in the ONOS CLI and type "hosts". As result, you should see something similar to this (100, 2000, 300 in this case are the VLAN Ids used):
Example of output for the hosts command in ONOS
id=02:2D:BD:5B:9E:43/100, mac=02:2D:BD:5B:9E:43, location=of:0000000000000003/3, vlan=3500, ip(s)=10.2.7.1, 10.1.7.1
id=1E:7B:8C:0E:67:6E/2000, mac=1E:7B:8C:0E:67:6E, location=of:0000000000000004/3, vlan=3500, ip(s)=10.1.4.2, 10.1.5.2, 10.1.7.2
id=86:C0:D9:41:D5:46/100, mac=86:C0:D9:41:D5:46, location=of:0000000000000001/4, vlan=3500, ip(s)=10.2.5.1, 10.1.5.1
id=92:1D:B3:D3:BE:2A/300, mac=92:1D:B3:D3:BE:2A, location=of:0000000000000002/3, vlan=3500, ip(s)=10.2.4.1, 10.1.4.1
Please, note that you should see results only for hosts that already sent traffic into the Network. This doesn’t happen for example with Mininet, where hosts are only processes without any application running by default.
Also, as in any related Intent based ONOS applications, there are certain best-practices to follow, to see what’s going in the Intent / Flow subsystems.
(if no network is provided)
onos> vpls-show [$VPLS_NETWORK]
VPLS2: interface=[vpls2h1, vpls2h2]
VPLS1: interface=[vpls1h1, vpls1h2, vpls1h3] |
Code Block | ||
---|---|---|
| ||
# Adds an existing interface (in netcfg) to an existing network
onos> vpls-add-iface $VPLS_NETWORK $INTERFACE_NAME
# Removes an existing interface from an existing network
onos> vpls-del-iface $VPLS_NETWORK $INTERFACE_NAME |
Code Block | ||
---|---|---|
| ||
# Cleans the status of the VPLS application (i.e., removes networks, detaches interfaces and withdraws intents)
onos> vpls-clean |
Issues and Troubleshooting
Things not working as expected? Time to troubleshoot!
Hosts are not communicating? Do you have at least two interfaces configured and two hosts attached - using the same VLAN Id?
Is your configuration correct? Has it been correctly parsed? The first step is to checked if the configuration has been parsed and correct running at the ONOS CLI the command "interfaces". This should give you a list of interfaces configured in the system
Any exception? Type log:exception-display in the ONOS CLI to discover it.
Are hosts connected to your OpenFlow data plane? I a host start to send out packets into the OpenFlow network you should be able to see it, even if VPLS is not installed yet or no configuration is provided. Go in the ONOS CLI and type "hosts". As result, you should see something similar to this (100, 2000, 300 in this case are the VLAN Ids used):
Code Block | ||
---|---|---|
| ||
onos> hosts
id=00:00:00:00:00:01/10, mac=00:00:00:00:00:01, location=of:0000000000000001/1, vlan=10, ip(s)=[10.0.0.1], configured=false
id=00:00:00:00:00:02/10, mac=00:00:00:00:00:02, location=of:0000000000000004/1, vlan=10, ip(s)=[10.0.0.2], configured=false
id=00:00:00:00:00:03/20, mac=00:00:00:00:00:03, location=of:0000000000000003/1, vlan=20, ip(s)=[10.0.0.3], configured=false
id=00:00:00:00:00:04/30, mac=00:00:00:00:00:04, location=of:0000000000000004/2, vlan=30, ip(s)=[10.0.0.4], configured=false
id=00:00:00:00:00:05/40, mac=00:00:00:00:00:05, location=of:0000000000000002/1, vlan=40, ip(s)=[10.0.0.5], configured=false |
Please, note that you should see results only for hosts that already sent traffic into the Network. This doesn’t happen for example with Mininet, where hosts are only processes without any application running by default.
Also, as in any related Intent based ONOS applications, there are certain best-practices to follow, to see what’s going in the Intent / Flow subsystems. Type "intents" to see the detailed list of intents, or "intent -s" for the intents summary.
Below is an approximation of what you should see for the network "VPLS2", after pinging between interfaces "vpls2h1" and "vpls2h2". Notice that two broadcast intents are installed at the beginning, and two unicast intents once the interfaces start pinging each other.
Code Block | ||
---|---|---|
| ||
onos> intents
id=0x0, state=INSTALLED, key=VPLS2-brc-of:0000000000000002-1-FF:FF:FF:FF:FF:FF, type=SinglePointToMultiPointIntent, appId=org.onosproject.vpls
selector=[ETH_DST:FF:FF:FF:FF:FF:FF]
treatment=[NOACTION]
ingress=of:0000000000000002/1, egress=[of:0000000000000004/2]
id=0x1, state=INSTALLED, key=VPLS2-brc-of:0000000000000004-2-FF:FF:FF:FF:FF:FF, type=SinglePointToMultiPointIntent, appId=org.onosproject.vpls
selector=[ETH_DST:FF:FF:FF:FF:FF:FF]
treatment=[NOACTION]
ingress=of:0000000000000004/2, egress=[of:0000000000000002/1]
id=0x10, state=INSTALLED, key=VPLS2-uni-of:0000000000000002-1-00:00:00:00:00:05, type=MultiPointToSinglePointIntent, appId=org.onosproject.vpls
selector=[ETH_DST:00:00:00:00:00:05]
treatment=[NOACTION]
ingress=[of:0000000000000004/2], egress=of:0000000000000002/1
id=0x11, state=INSTALLED, key=VPLS2-uni-of:0000000000000004-2-00:00:00:00:00:04, type=MultiPointToSinglePointIntent, appId=org.onosproject.vpls
selector=[ETH_DST:00:00:00:00:00:04]
treatment=[NOACTION]
ingress=[of:0000000000000002/1], egress=of:0000000000000004/2 |
Are intents installed?Are intents installed? (type in the ONOS CLI "intent -s" - which stays for intents summary, type only "intents" to see the detailed list of intents)
Yes! (we’re happy!).
No! Ops….let’s check flows, since 1 intent is composed by one or more flows!
Type "flows pending-add" to see if there’s any flow for which ONOS still not received an installation confirmation
Type "flows" to see the detailed list of flows - installed or not by the system
...