[CORD-2585]
Lint check documentation with markdownlint
Change-Id: I213d201148252ac103f3e608194fac96497b94b4
(cherry picked from commit d4b4b2da3b6e5bd8587e30d820d02c0e79eef779)
diff --git a/docs/README.md b/docs/README.md
index a8fee96..3b84df8 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -2,17 +2,18 @@
The E-CORD (Enterprise CORD) profile is `Official` as of 4.1.
-## Service Manifest
-E-CORD includes two service manifests:
+## Service Manifest
-#### [ecord-global](https://github.com/opencord/platform-install/blob/master/profile_manifests/ecord-global.yml)
+E-CORD includes two service manifests:
+
+### [ecord-global](https://github.com/opencord/platform-install/blob/master/profile_manifests/ecord-global.yml)
| Service | Source Code |
|-------------|---------------|
| vNaaS | https://github.com/opencord/vnaas |
| ONOS | https://github.com/opencord/onos-service |
-#### [ecord-local](https://github.com/opencord/platform-install/blob/master/profile_manifests/ecord.yml)
+### [ecord-local](https://github.com/opencord/platform-install/blob/master/profile_manifests/ecord.yml)
| Service | Source Code |
|--------------|---------------|
@@ -25,14 +26,14 @@
| OpenStack | https://github.com/opencord/openstack |
| ONOS | https://github.com/opencord/onos-service |
-## Model Extensions
+## Model Extensions
+
E-CORD does not extend CORD's core models.
-## GUI Extensions
+## GUI Extensions
+
E-CORD includes two GUI extension:
* [vnaas](https://github.com/opencord/vnaas/tree/master/xos/gui)
* [veestat](https://github.com/opencord/vEE/tree/master/xos/veestat)
-
-
diff --git a/docs/cfm.md b/docs/cfm.md
index 5fbc229..4541e58 100644
--- a/docs/cfm.md
+++ b/docs/cfm.md
@@ -1,20 +1,46 @@
# Configuring CFM
-This guide describes how to configure CFM monitoring for an E-Line generated in a local E-CORD POD. This monitoring will then be viewable in the “Delay and Jitter” link in the CORD UI. It assumes that your POD already has a global E-CORD node and at least 2 local E-CORD instances, with each local E-CORD having a CFM capable device (e.g. Microsemi EA1000) connected.It is assumed that these devices are already detected and connected in ONOS as per [the E-CORD installation guide](installation_guide.md).
-The guide acceses an ONOS_CORD instance at `onos-cord`, which has the ssh port 8102 and the web port 8182. Change the IP adddresses to your own, and if these ports have been forwarded for some reason on your setup, make sure to accommodate as necessary.
+This guide describes how to configure CFM monitoring for an E-Line generated in
+a local E-CORD POD. This monitoring will then be viewable in the “Delay and
+Jitter” link in the CORD UI. It assumes that your POD already has a global
+E-CORD node and at least 2 local E-CORD instances, with each local E-CORD
+having a CFM capable device (e.g. Microsemi EA1000) connected.It is assumed
+that these devices are already detected and connected in ONOS as per [the
+E-CORD installation guide](installation_guide.md).
-This guide describes a minimal CFM setup, with a single MD (maintenance domain) and MA (maintenance association), two MEPs (measurement endpoints), and one DM (delay measurement).
+The guide acceses an ONOS_CORD instance at `onos-cord`, which has the ssh port
+8102 and the web port 8182. Change the IP adddresses to your own, and if these
+ports have been forwarded for some reason on your setup, make sure to
+accommodate as necessary.
-You can also find a [Postman](https://www.getpostman.com/) JSON collection that contains the JSON necessary to setup CFM under `cord/orchestration/profiles/ecord/examples/`.
+This guide describes a minimal CFM setup, with a single MD (maintenance domain)
+and MA (maintenance association), two MEPs (measurement endpoints), and one DM
+(delay measurement).
-Detailed information on the CFM application itself can be found on the [ONOS Wiki](https://wiki.onosproject.org/display/ONOS/Layer+2+Monitoring+with+CFM+and+Services+OAM).
+You can also find a [Postman](https://www.getpostman.com/) JSON collection that
+contains the JSON necessary to setup CFM under
+`cord/orchestration/profiles/ecord/examples/`.
+
+Detailed information on the CFM application itself can be found on the [ONOS
+Wiki](https://wiki.onosproject.org/display/ONOS/Layer+2+Monitoring+with+CFM+and+Services+OAM).
## Creating an MD
-Post the following JSON file to `onos-cord:8182/onos/cfm/md/` on your local instances. Make sure you have a header with basic authorization set to username “onos” and password “rocks”, as this will be required for this and all future JSON requests in this guide.
-NOTE: MDs and MAs are stored in a distributed store within the same cluster. In our testing setup, ONOS_CORD and ONOS_Fabric exist on two separate clusters. If you see the MD on the ONOS_Fabric (i.e. the MD shows up after running cfm-md-list) after instantiating it on the first local node, do not push the JSON on the second node. Otherwise, feel free to push on the second node.
+Post the following JSON file to `onos-cord:8182/onos/cfm/md/` on your local
+instances. Make sure you have a header with basic authorization set to username
+“onos” and password “rocks”, as this will be required for this and all future
+JSON requests in this guide.
-If you are creating more than one MD, they must have different `mdNumericId`s. Be aware that devices will only be able to take delay measurements from others on the same MD.
+> NOTE: MDs and MAs are stored in a distributed store within the same cluster.
+> In our testing setup, ONOS_CORD and ONOS_Fabric exist on two separate
+> clusters. If you see the MD on the ONOS_Fabric (i.e. the MD shows up after
+> running cfm-md-list) after instantiating it on the first local node, do not
+> push the JSON on the second node. Otherwise, feel free to push on the second
+> node.
+
+If you are creating more than one MD, they must have different `mdNumericId`s.
+Be aware that devices will only be able to take delay measurements from others
+on the same MD.
```json
{"md": {
@@ -27,11 +53,20 @@
```
## Creating an MA
-Created MAs should be a part of a pre-defined MD, and are associated with a particular VLAN ID, defined in the `vid-list`. We defined an MD called `onf`, so we post the following JSON to `onos-cord:8182/onos/cfm/md/onf/`.
-NOTE: MAs are also stored in a distributed store. See the previous note in “Setting up MDs” for possible consequences.
+Created MAs should be a part of a pre-defined MD, and are associated with a
+particular VLAN ID, defined in the `vid-list`. We defined an MD called `onf`,
+so we post the following JSON to `onos-cord:8182/onos/cfm/md/onf/`.
-If you are creating more than one MA, they must have different `maNumericId`s and `vid`s, while `component-id`s may be reused. The `rmep-list` defines the list of MEP IDs that can be associated with this vlan. We only have two MEPs here since we are monitoring an Eline. All MEPs an MA might use must be defined in the `rmep-list`, as changes made to the `rmep-list` after the MA has already been pushed to a device will not be reflected in that device's copy of the MA.
+> NOTE: MAs are also stored in a distributed store. See the previous note in
+> “Setting up MDs” for possible consequences.
+
+If you are creating more than one MA, they must have different `maNumericId`s
+and `vid`s, while `component-id`s may be reused. The `rmep-list` defines the
+list of MEP IDs that can be associated with this vlan. We only have two MEPs
+here since we are monitoring an Eline. All MEPs an MA might use must be defined
+in the `rmep-list`, as changes made to the `rmep-list` after the MA has already
+been pushed to a device will not be reflected in that device's copy of the MA.
```json
{
@@ -59,9 +94,15 @@
```
## Creating a MEP
-A measurement endpoint (MEP) is associated with a NETCONF device, and one must be created for each device. A MEP can only be created for the device connected to the current local node, and must be associated with an MA. The MEP ID must already exist on that MA’s `rmep-list` and must not already be in use by another device.
-With our MD set to onf, and MA set to ma-vlan-1, we post the following JSON to `onos-cord:8182/onos/cfm/md/onf/ma/ma-vlan-1/mep`
+A measurement endpoint (MEP) is associated with a NETCONF device, and one must
+be created for each device. A MEP can only be created for the device connected
+to the current local node, and must be associated with an MA. The MEP ID must
+already exist on that MA’s `rmep-list` and must not already be in use by
+another device.
+
+With our MD set to onf, and MA set to ma-vlan-1, we post the following JSON to
+`onos-cord:8182/onos/cfm/md/onf/ma/ma-vlan-1/mep`
```json
{
@@ -80,16 +121,31 @@
}
```
-Since we have 2 Microsemi devices, we will also need to post MEP creation JSON to our second local node, making sure to change the `mepId` and `deviceId`. In our example, we defined two MEP IDs, 10 and 20, to be used with our first and second local nodes. Both MEPs must be set up correctly in order to create a delay measurement (DM).
+Since we have 2 Microsemi devices, we will also need to post MEP creation JSON
+to our second local node, making sure to change the `mepId` and `deviceId`. In
+our example, we defined two MEP IDs, 10 and 20, to be used with our first and
+second local nodes. Both MEPs must be set up correctly in order to create a
+delay measurement (DM).
## Creating a DM
-Check the `remote_mep_state` of your created meps to ensure that they have a value of `RMEP_OK` before creating delay measurements. You can do so by performing a GET; in our case, we would perform a GET on `onos-cord:8182/onos/cfm/md/onf/ma/ma-vlan-1/mep/10` on our first local node, and on `onos-cord:8182/onos/cfm/md/onf/ma/ma-vlan-1/mep/20` on our second local node.
-DMs are associated with a single MEP, and a maximum of 2 can exist on a single MEP.
+Check the `remote_mep_state` of your created meps to ensure that they have a
+value of `RMEP_OK` before creating delay measurements. You can do so by
+performing a GET; in our case, we would perform a GET on
+`onos-cord:8182/onos/cfm/md/onf/ma/ma-vlan-1/mep/10` on our first local node,
+and on `onos-cord:8182/onos/cfm/md/onf/ma/ma-vlan-1/mep/20` on our second local
+node.
-IMPORTANT: The `measurementsEnabled` in the sample JSON below are required for the CFM stat UI to function properly.
+DMs are associated with a single MEP, and a maximum of 2 can exist on a single
+MEP.
-To create a DM on our first local instance, the following JSON is submitted by POST to `onos-cord:8182/onos/cfm/md/onf/ma/ma-vlan-1/mep/10`. Notice that the remoteMepId is set to 20 because we are trying to get the delay measurement to 20 from 10.
+> IMPORTANT: The `measurementsEnabled` in the sample JSON below are required
+> for the CFM stat UI to function properly.
+
+To create a DM on our first local instance, the following JSON is submitted by
+POST to `onos-cord:8182/onos/cfm/md/onf/ma/ma-vlan-1/mep/10`. Notice that the
+remoteMepId is set to 20 because we are trying to get the delay measurement to
+20 from 10.
```json
{
@@ -121,8 +177,16 @@
}
```
-We don’t need to create a DM on the second local instance for this DM to work. Make sure that you aren’t setting the `remoteMepId` equal to the mepId you are trying to create the DM on.
+We don’t need to create a DM on the second local instance for this DM to work.
+Make sure that you aren’t setting the `remoteMepId` equal to the mepId you are
+trying to create the DM on.
## Viewing Delay and Jitter
-At this point, we are done configuring CFM and can now view delay and jitter statistics in the CORD UI under “Delay and Jitter”. Login into the CORD UI at `onos-cord/xos` with the username `xosadmin@opencord.org`, and the password generated in the local node under `/opt/credentials/xosadmin@opencord.org`. The "Delay and Jitter" link will be on the left navigation panel once you have successfully logged in.
+At this point, we are done configuring CFM and can now view delay and jitter
+statistics in the CORD UI under “Delay and Jitter”. Login into the CORD UI at
+`onos-cord/xos` with the username `xosadmin@opencord.org`, and the password
+generated in the local node under `/opt/credentials/xosadmin@opencord.org`. The
+"Delay and Jitter" link will be on the left navigation panel once you have
+successfully logged in.
+
diff --git a/docs/dev_guide.md b/docs/dev_guide.md
index fb5d9d2..d2e0361 100644
--- a/docs/dev_guide.md
+++ b/docs/dev_guide.md
@@ -1,56 +1,83 @@
# E-CORD Developer Guide
-This page describes general guidelines for developers who want to download and work on the E-CORD source code, or need to mock special development environments.
+This page describes general guidelines for developers who want to download and
+work on the E-CORD source code, or need to mock special development
+environments.
## Download the E-CORD source code
-E-CORD is part of the default CORD code base. To know how you can download the CORD source code, go [here](https://guide.opencord.org/install.html).
-Each E-CORD service lives in a specific repository. A list of E-CORD services and links to their repositories is available in the [main page of this guide](https://guide.opencord.org/profiles/ecord/).
-NOTE: The E-CORD source code is available from the 4.1 release (branch) of CORD.
+E-CORD is part of the default CORD code base. To know how you can download the
+CORD source code, see [Building and Installing CORD](/install.md). Each E-CORD
+service lives in a specific repository. A list of E-CORD services and links to
+their repositories is available in the [main page of this
+guide](/profiles/ecord/).
+
+> NOTE: The E-CORD source code is available from the 4.1 release (branch) of
+> CORD.
## Developer Environments
-As for other CORD profiles, E-CORD can also be deployed in environments other than physical PODs. This creates a more convenient environment for developers, using less resources and providing a faster development life-cycle.
+As for other CORD profiles, E-CORD can also be deployed in environments other
+than physical PODs. This creates a more convenient environment for developers,
+using less resources and providing a faster development life-cycle.
Two environments are available, depending on your needs:
+
* Local Developer Machine: a development environment running directly on your laptop
* CORD-in-a-Box
### Mock/local Machine Development Environment
-To understand what a local development environment is, what it can help you with, and how to build it, look at [this page](https://guide.opencord.org/xos/dev/workflow_mock_single.html).
+To understand what a local development environment is, what it can help you
+with, and how to build it, look at [this
+page](/xos/dev/workflow_mock_single.md).
When it’s time to specify the PODCONFIG file, use
+
* *ecord-mock.yml* for local sites, instead of the default value (rcord-mock.yml)
* *ecord-global-single.yml* to mock global nodes, instead of the default value (rcord-mock.yml)
### CORD-in-a-Box (CiaB) development
-To understand what CiaB is and what it can help you with, look [here](https://guide.opencord.org/xos/dev/workflow_pod.html).
+To understand what CiaB is and what it can help you with, look
+[here](/xos/dev/workflow_pod.md).
-To build E-CORD CiaB, follow the steps [here](https://guide.opencord.org/install_virtual.html).
+To build E-CORD CiaB, follow the steps [here](/install_virtual.md).
When it’s time to specify the PODCONFIG file, use
-* *ecord-virtual.yml* for local sites, instead of the default value (rcord-virtual.yml)
-* *ecord-global-single.yml* to deploy global nodes, instead of the default value (rcord-virtual.yml)
-**NOTE** When inspecting CiaB you will also need, on the global node to use
+* *ecord-virtual.yml* for local sites, instead of the default value
+ (rcord-virtual.yml)
+* *ecord-global-single.yml* to deploy global nodes, instead of the default
+ value (rcord-virtual.yml)
-```
+> NOTE: When inspecting CiaB you will also need, on the global node to use.
+
+```shell
export VAGRANT_CWD=~/cord/build/scenarios/single
```
-instead of
+instead of
-```
+```shell
export VAGRANT_CWD=~/cord/build/scenarios/cord
```
-More detailed instructions on how to develop and deploy using CiaB can be found in the troubleshooting [guide](https://guide.opencord.org/troubleshooting.html).
+More detailed instructions on how to develop and deploy using CiaB can be found
+in the [troubleshooting guide](/troubleshooting.md).
## Run an E-CORD test subscriber
-When using local PODs, you can emulate E-CORD test subscribers, doing the following.
-* ssh into the the head node
-* ```cd /opt/cord/build/platform-install```
-* ```ansible-playbook -i inventory/head-localhost --extra-vars "@/opt/cord_profile/genconfig/config.yml" ecord-test-subscriber-playbook.yml```
+When using local PODs, you can emulate E-CORD test subscribers, doing the
+following.
+
+1. ssh into the the head node
+
+2. `cd /opt/cord/build/platform-install`
+
+3. Deploy a test subscriber:
+
+ ```
+ ansible-playbook -i inventory/head-localhost --extra-vars "@/opt/cord_profile/genconfig/config.yml" ecord-test-subscriber-playbook.yml
+ ```
+
diff --git a/docs/installation_guide.md b/docs/installation_guide.md
index 91b63b6..9edf940 100644
--- a/docs/installation_guide.md
+++ b/docs/installation_guide.md
@@ -1,21 +1,29 @@
# Installation Guide
-Installing E-CORD is based on the standard CORD
-[installation process](https://guide.opencord.org/install_physical.html). This
-section describes the additional steps required.
+Installing E-CORD is based on the standard CORD [installation
+process](https://guide.opencord.org/install_physical.html). This section
+describes the additional steps required.
## Hardware Requirements (BOM)
-Following is a list of hardware needed to create a typical E-CORD deployment. References will be often made to the generic CORD BOM.
-
-> The hardware suggested is a reference implementation. Hardware listed have been usually used by ONF and its community for lab trials and deployments to validate the platform and demonstrate it's capabilities. You’re very welcome to replace any of the components and bring in yours into the ecosystem. As a community, we would be happy to acknowledge your contribution and put new tested devices in the BOM as well.
+Following is a list of hardware needed to create a typical E-CORD deployment.
+References will be often made to the generic CORD BOM.
+
+> The hardware suggested is a reference implementation. Hardware listed have
+> been usually used by ONF and its community for lab trials and deployments to
+> validate the platform and demonstrate it's capabilities. You’re very welcome
+> to replace any of the components and bring in yours into the ecosystem. As a
+> community, we would be happy to acknowledge your contribution and put new
+> tested devices in the BOM as well.
The following suggests specific hardware.
### Global Node
-* 1x development machine - same model used for a [generic CORD POD](https://guide.opencord.org/install_physical.html#bill-of-materials-bom--hardware-requirements)
-* 1x compute node (server) - same model used for a [generic CORD POD](https://guide.opencord.org/install_physical.html#bill-of-materials-bom--hardware-requirements)
+* 1x development machine - same model used for a [generic CORD
+ POD](https://guide.opencord.org/install_physical.html#bill-of-materials-bom--hardware-requirements)
+* 1x compute node (server) - same model used for a [generic CORD
+ POD](https://guide.opencord.org/install_physical.html#bill-of-materials-bom--hardware-requirements)
### Local Site (POD)
@@ -23,39 +31,59 @@
* Everything listed in the BOM of a generic CORD POD
-> **WARNING**: Currently E-CORD does not support more than 1 fabric switch per
-> POD. While soon will be possible to use more than one fabric switch, it is useless now to buy more than a fabric switch per local site.
+> WARNING: Currently E-CORD does not support more than 1 fabric switch per POD.
+> While soon will be possible to use more than one fabric switch, it is useless
+> now to buy more than a fabric switch per local site.
* 1x Centec v350, used as “Ethernet Edge switch”
* 1x CPE, composed by
* 1x 2-port TP-Link Gigabit SFP Media converter, model MC220L(UN)
* 1x Microsemi EA1000 programmable SFP
-* 1x Gigabit SFP transceiver, to be plugged into Ethernet Edge
- switch. Please ensure the wavelength of this SFP matches the
- Microsemi SFP; in our case this is 1310nm.
- In our rack we use the following [device](https://www.amazon.com/gp/product/B00U8PN0NQ/ref=oh_aui_detailpage_o04_s00?ie=UTF8&psc=1)
+* 1x Gigabit SFP transceiver, to be plugged into Ethernet Edge switch. Please
+ ensure the wavelength of this SFP matches the Microsemi SFP; in our case this
+ is 1310nm. In our rack we use the following
+ [device](https://www.amazon.com/gp/product/B00U8PN0NQ/ref=oh_aui_detailpage_o04_s00?ie=UTF8&psc=1)
* 1x single mode fiber cable to connect the CPE to the Ethernet Edge switch
-* 1x 40G to 4x10G QSFP+ module to connect the Ethernet Edge switch to the access leaf fabric switch (EdgeCore QSFP to 4x SFP+ DAC, model ET6402-10DAC-3M, part M0OEC6402T06Z)
-
-> **NOTE**: The role of the CPE is to receive end-user traffic, tag it with a VLAN id, and forward it to the Ethernet Edge switch. Additionally, the CPE sends and receives OAM probes to let CORD monitor the status of the network. For lab trials, a combination of two components has been used to emulate the CPE functionalities: a media converter, used to collect users’ traffic from an Ethernet CAT5/6 interface (where a traditional host, like a laptop, is connected) and send it out from its other SFP interface; a programmable SFP (plugged into the SFP port of the media converter), that a) tags the traffic with a specific VLAN id and forwards it to the Ethernet Edge switch; b) sends and receives OEM probes to let CORD monitor the network. The programmable SFP is currently configured through NETCONF, using the ONOS Flow Rule abstraction translated into NETCONF XML for the drivers, and the ONOS-based CarrierEthernet application to generate the Flow Rules based on requests.
+* 1x 40G to 4x10G QSFP+ module to connect the Ethernet Edge switch to the
+ access leaf fabric switch (EdgeCore QSFP to 4x SFP+ DAC, model
+ ET6402-10DAC-3M, part M0OEC6402T06Z)
+
+> NOTE: The role of the CPE is to receive end-user traffic, tag it with a
+> VLAN id, and forward it to the Ethernet Edge switch. Additionally, the CPE
+> sends and receives OAM probes to let CORD monitor the status of the network.
+> For lab trials, a combination of two components has been used to emulate the
+> CPE functionalities: a media converter, used to collect users’ traffic from
+> an Ethernet CAT5/6 interface (where a traditional host, like a laptop, is
+> connected) and send it out from its other SFP interface; a programmable SFP
+> (plugged into the SFP port of the media converter), that a) tags the traffic
+> with a specific VLAN id and forwards it to the Ethernet Edge switch; b) sends
+> and receives OEM probes to let CORD monitor the network. The programmable SFP
+> is currently configured through NETCONF, using the ONOS Flow Rule abstraction
+> translated into NETCONF XML for the drivers, and the ONOS-based
+> CarrierEthernet application to generate the Flow Rules based on requests.
## Local Site Connectivity
-The main CORD physical POD
-[installation guide](https://guide.opencord.org/install_physical.html#connectivity-requirements)
-already provides a basic POD connectivity diagram. These connections
-are also needed to bring up an E-CORD local site. Carefully review them before going through this section.
+The main CORD physical POD [installation
+guide](https://guide.opencord.org/install_physical.html#connectivity-requirements)
+already provides a basic POD connectivity diagram. These connections are also
+needed to bring up an E-CORD local site. Carefully review them before going
+through this section.
-<img src="static/images/connectivity-diagram.png" alt="E-CORD connectivity diagram" style="width: 800px;"/>
+
### Legend
+
* **Red lines**: data plane connections
* **Light blue lines**: control plane connections
-* **Bold (BOLD!) lines**: 10G/40G fiber network connections, depending on your hardware
+* **Bold (BOLD!) lines**: 10G/40G fiber network connections, depending on your
+ hardware
* **Bold lines**: 1G fiber network connections
* **Thin lines**: 1G copper network connections
-The diagram has been populated with letters and numbers that reference specific devices or ports. Letters only reference devices (i.e. A is the CPE). Letters and numbers reference a port. For example, A1 is the "fiber" port on the CPE.
+The diagram has been populated with letters and numbers that reference specific
+devices or ports. Letters only reference devices (i.e. A is the CPE). Letters
+and numbers reference a port. For example, A1 is the "fiber" port on the CPE.
* **A** - the CPE
* **B** - the the Ethernet Edge Device
@@ -65,44 +93,52 @@
* **C1** - the fabric switch port facing the Ethernet Edge Device
* **C2** - the fabric switch port facing the head node (if any)
* **C3** - the fabric switch port facing the compute node (if any)
-* **C4** - the main fabric switch port connecting the POD to the upstream network (or directly to the fabric switch of the second POD)
-* **C5** - the main fabric switch port connecting the POD to the upstream network (or directly to the fabric switch of the third POD)
+* **C4** - the main fabric switch port connecting the POD to the upstream
+ network (or directly to the fabric switch of the second POD)
+* **C5** - the main fabric switch port connecting the POD to the upstream
+ network (or directly to the fabric switch of the third POD)
* **E** - the remote fabric switch (of "POD2" in lab trials with 3 PODs)
-* **E1** - the remote fabric switch port of "POD2", facing the fabric switch in POD1
+* **E1** - the remote fabric switch port of "POD2", facing the fabric switch in
+ POD1
* **F** - the remote fabric switch (of "POD3" in lab trials with 3 PODs)
-* **F1** - the remote fabric switch port of "POD3", facing the fabric switch in POD1
+* **F1** - the remote fabric switch port of "POD3", facing the fabric switch in
+ POD1
A letter, plus "N" represents a generic port on a specific device.
## Installing the Global Node
-To install the global node, you should follow the steps described in
-the main
-[physical POD installation](https://guide.opencord.org/install_physical.html). At
-a high level, bootstrap the development machine and download the code.
+To install the global node, you should follow the steps described in the main
+[physical POD installation](https://guide.opencord.org/install_physical.html).
+At a high level, bootstrap the development machine and download the code.
### Global Node Configuration File
-When it’s time to write your POD configuration, use the [physical-example.yml](https://github.com/opencord/cord/blob/master/podconfig/physical-example.yml) file as a template. Either modify it or make a copy of it in the same directory.
-Fill in the configuration with your own head node data.
+When it’s time to write your POD configuration, use the
+[physical-example.yml](https://github.com/opencord/cord/blob/master/podconfig/physical-example.yml)
+file as a template. Either modify it or make a copy of it in the same
+directory. Fill in the configuration with your own head node data.
-As `cord_scenario`, use `single`. This won’t install OpenStack and other software, which are not needed on the global node.
+As `cord_scenario`, use `single`. This won’t install OpenStack and other
+software, which are not needed on the global node.
As `cord_profile`, use `ecord-global`.
### POD Build
-Continue the installation as described in the standard installation guide by running the make build target:
+Continue the installation as described in the standard installation guide by
+running the make build target:
-```
+```shell
make build
```
### DNS Services Restart
-As soon as the procedure is finished you need to restart two services on the POD.
+As soon as the procedure is finished you need to restart two services on the
+POD.
-```
+```shell
sudo service nsd restart
sudo service unbound restart
```
@@ -111,13 +147,14 @@
## Installing an E-CORD Local Site
-To install each local site you should follow the steps described in the
-main
-[physical POD installation](https://guide.opencord.org/install_physical.html). Bootstrap
-the development machine and download the code.
+To install each local site you should follow the steps described in the main
+[physical POD installation](https://guide.opencord.org/install_physical.html).
+Bootstrap the development machine and download the code.
-When it’s time to write your POD configuration, use the [physical-example.yml](https://github.com/opencord/cord/blob/master/podconfig/physical-example.yml) file as a template. Either modify it or make a copy of it in the same directory.
-Fill in the configuration with your own head node data.
+When it’s time to write your POD configuration, use the
+[physical-example.yml](https://github.com/opencord/cord/blob/master/podconfig/physical-example.yml)
+file as a template. Either modify it or make a copy of it in the same
+directory. Fill in the configuration with your own head node data.
As `cord_scenario` use `cord`.
@@ -125,53 +162,67 @@
## Configure the Global Node
-It is essential to configure the global node properly, in order to
-instruct it about the existing local sites, have them connected and
-coordinated. Configuring the global node consists of two parts, an
-XOS/Tosca configuration and an ONOS/JSON.
+It is essential to configure the global node properly, in order to instruct it
+about the existing local sites, have them connected and coordinated.
+Configuring the global node consists of two parts, an XOS/Tosca configuration
+and an ONOS/JSON.
### Configuring XOS (Tosca Configuration)
-The first part consists of instructing XOS running on the global node
-about the set of local sites. To configure your XOS instance, do the following:
-
+The first part consists of instructing XOS running on the global node about the
+set of local sites. To configure your XOS instance, do the following:
+
* Create your TOSCA file, using as template the file on your
development/management machine, under
- *CORD_ROOT/orchestration/profiles/ecord/examples/vnaasglobal-service-reference.yaml*
+ `CORD_ROOT/orchestration/profiles/ecord/examples/vnaasglobal-service-reference.yaml`
(available also online,
[here](https://github.com/opencord/ecord/blob/master/examples/vnaasglobal-service-reference.yaml)).
-
- * Save it on the global node.
-
- * SSH into your global node.
-
- * On the global node, run the following command:
-```
+
+* Save it on the global node.
+
+* SSH into your global node.
+
+* On the global node, run the following command:
+
+```shell
python /opt/cord/build/platform-install/scripts/run_tosca.py 9000 xosadmin@opencord.org YOUR_XOS_PASSWORD PATH_TO_YOUR_TOSCA FILE
```
->**NOTE**: If the XOS password has been auto-generated, you can find it on the global node, in
-```
+> NOTE: If the XOS password has been auto-generated, you can find it on the
+> global node, in
+
+```shell
/opt/credentials/xosadmin@opencord.org
```
### Configuring ONOS (JSON Configuration)
To configure ONOS on the global node:
+
* SSH into the global node.
* Login to ONOS_CORD: *ssh -p 8102 onos@onos-cord*.
-* In the ONOS CLI (*onos>*) verify that apps are loaded by executing: `apps -a -s`
- The following applications should be enabled:
- ```
- org.onosproject.drivers
- org.opencord.ce-api
- org.opencord.ce.global
- ```
- If one or more apps mentioned above are not present in the list, they can be activated with `app activate APP-NAME`.
+* In the ONOS CLI (*onos>*) verify that apps are loaded by executing: `apps -a
+ -s`
+
+ The following applications should be enabled:
+
+ ```shell
+ org.onosproject.drivers
+ org.opencord.ce-api
+ org.opencord.ce.global
+ ```
+
+ If one or more apps mentioned above are not present in the list, they can be
+ activated with `app activate APP-NAME`.
+
* Logout from ONOS (CTRL+D or exit)
-* Anywhere, either on the global node itself or on any machine able to reach the global node, write your ONOS configuration file. The following is an example configuration for a global node that communicates with two local sites, with domain names site1 and site2.
-
- ```
+
+* Anywhere, either on the global node itself or on any machine able to reach
+ the global node, write your ONOS configuration file. The following is an
+ example configuration for a global node that communicates with two local
+ sites, with domain names site1 and site2.
+
+ ```json
{
"apps" : {
"org.opencord.ce.global.vprovider" : {
@@ -227,19 +278,22 @@
}
}
```
-
-> **NOTE** Under the key “topics” you can specify as many topics (string of your choice) as you prefer for sake of load balancing the communication with the underlying (local-site) controllers among the instance of the global ONOS cluster. For each domain you also have to specify one of these topics.
-
-> **NOTE**: If the XOS password has been auto-generated, you can find it on the global node, in /opt/credentials/xosadmin@opencord.org
+
+ > NOTE: Under the key “topics” you can specify as many topics (string of
+ > your choice) as you prefer for sake of load balancing the communication with
+ > the underlying (local-site) controllers among the instance of the global ONOS
+ > cluster. For each domain you also have to specify one of these topics.
* Use CURL to push your file:
- ```
- curl -X POST -H "content-type:application/json" http://YOUR-GLOBAL-NODE-IP:8182/onos/v1/network/configuration -d @YOUR-JSON-FILE.json --user onos:rocks
- ```
+
+ ```shell
+ curl -X POST -H "content-type:application/json" http://YOUR-GLOBAL-NODE-IP:8182/onos/v1/network/configuration -d @YOUR-JSON-FILE.json --user onos:rocks
+ ```
## Configure the Local Sites
Local sites configuration consists of four parts:
+
* Ethernet Edge (Centec V350) configuration
* Fabric Breakout configuration (optional)
* ONOS_Fabric configuration
@@ -248,18 +302,24 @@
### Configure the Ethernet Edge device - B - (Centec v350)
The steps below assume that
+
* The Centec device to an A(Access)-leaf fabric switch
* ONOS_CORD is running
-Follow the steps below to assign an IP address to the Ethernet Edge device and connect it to ONOS_CORD.
+Follow the steps below to assign an IP address to the Ethernet Edge device and
+connect it to ONOS_CORD.
#### Set a Management IP Address on the Switch OOB Interface
-The switch management interface should be set with a static IP address (DHCP not supported yet), in the same subnet of the POD internal/management network (by default 10.6.0.0/24).
+The switch management interface should be set with a static IP address (DHCP
+not supported yet), in the same subnet of the POD internal/management network
+(by default 10.6.0.0/24).
-> **NOTE**: Please, use high values for the IP last octet, since lower values are usually allocated first by the MAAS DHCP server running on the head node.
+> NOTE: Please, use high values for the IP last octet, since lower values
+> are usually allocated first by the MAAS DHCP server running on the head node.
To configure the static IP address, do the following:
+
* Log into the CLI of the Centec switch (through SSH or console cable)
* *configure terminal*
* *management ip address YOUR_MGMT_ADDRESS netmask YOUR_NETMASK*
@@ -272,114 +332,150 @@
cable to connect to the Centec Etherned Edge, you need to properly configure
the interface on which the breakout cable is connected.
-By default, all 32 ports are running in 1 x 40G mode. The `/etc/accton/ofdpa.conf` needs to be modified to break out 1 x 40G into 4 x 10G.
+By default, all 32 ports are running in 1 x 40G mode. The
+`/etc/accton/ofdpa.conf` needs to be modified to break out 1 x 40G into 4 x
+10G.
+
Do the following:
+
* ssh into the fabric switch (username and password are usually root/onl)
* `vi /etc/accton/ofdpa.conf`
-* uncomment this line `port_mode_1=4x10g # front port 1` for the port you have the breakout cable connected to
-* save the file and exit from it.
+* uncomment this line `port_mode_1=4x10g # front port 1` for the port you
+ have the breakout cable connected to
+* save the file and exit from it.
* `cd ~`
* `./killit`
* `./connect -bg`
-For any more reference you can go to this particular step [Fabric configuration guide](https://wiki.opencord.org/display/CORD/Hardware+Switch+Installation+Guide#HardwareSwitchInstallationGuide-C3)
+For any more reference you can go to this particular step [Fabric configuration
+guide](https://wiki.opencord.org/display/CORD/Hardware+Switch+Installation+Guide#HardwareSwitchInstallationGuide-C3)
### Set ONOS-CORD as the Openflow Controller
-To set ONOS-CORD as the default switch OpenFlow controller and verify the configuration:
+To set ONOS-CORD as the default switch OpenFlow controller and verify the
+configuration:
+
* Log into the CLI of the Centec switch (through SSH or console cable)
* *configure terminal*
* *openflow set controller tcp YOUR-LOCAL-SITE-HEAD-IP 6654*
* *end*
* *show openflow controller status*
-
-The local site configurations explained below need to happen on the head nodes of all local sites.
+
+The local site configurations explained below need to happen on the head nodes
+of all local sites.
### ONOS_Fabric Configuration
ONOS_Fabric manages the underlay network (the connectivity between the fabric switches).
To configure ONOS_Fabric do the following:
+
* SSH on the local site head node
* Log into ONOS_Fabric: `ssh -p 8101 onos@onos-fabric`
* In the ONOS CLI (*onos>*) verify that apps are loaded: `apps -a -s`
- The list of applications enabled should include:
- ```
- org.onosproject.segmentrouting
- org.opencord.ce.api
- org.opencord.ce.local.bigswitch
- org.opencord.ce.local.channel.http
- org.opencord.ce.local.fabric
- ```
- If one or more apps mentioned above are not present in the list, they can be activated with `app activate APP-NAME`
- * Check that the site domain id is correctly set in ONOS, running
- ```
- cfg get org.opencord.ce.local.bigswitch.BigSwitchManager
- ```
- The value should be `YOUR-HEAD-NODE-IP-fabric-onos`
-* Check that the fabric switch is connected to onos typing devices. If no devices are there, make sure your fabric switch is connected to ONOS and go through the [Fabric configuration guide](https://guide.opencord.org/appendix_basic_config.html#connect-the-fabric-switches-to-onos).
+
+ The list of applications enabled should include:
+
+ ```shell
+ org.onosproject.segmentrouting
+ org.opencord.ce.api
+ org.opencord.ce.local.bigswitch
+ org.opencord.ce.local.channel.http
+ org.opencord.ce.local.fabric
+ ```
+
+ If one or more apps mentioned above are not present in the list, they can be
+ activated with `app activate APP-NAME`
+
+* Check that the site domain id is correctly set in ONOS, running
+
+ ```shell
+ cfg get org.opencord.ce.local.bigswitch.BigSwitchManager
+ ```
+
+ The value should be `YOUR-HEAD-NODE-IP-fabric-onos`
+
+* Check that the fabric switch is connected to onos typing devices. If no
+ devices are there, make sure your fabric switch is connected to ONOS and go
+ through the [Fabric configuration
+ guide](https://guide.opencord.org/appendix_basic_config.html#connect-the-fabric-switches-to-onos).
* Logout from ONOS (CTRL+D or exit)
-* Anywhere, either on the head node itself or on any machine able to reach the head node, write your ONOS configuration file.
- Following, is an example configuration for a local site.
-
- ```
- {
- "apps" : {
- "org.opencord.ce.local.fabric" : {
- "segmentrouting_ctl": {
- "publicIp": "YOUR-HEAD-NODE-IP",
- "port": "8181",
- "username": "onos",
- "password": "rocks",
- "deviceId": "of:C-DPID"
+* Anywhere, either on the head node itself or on any machine able to reach the
+ head node, write your ONOS configuration file.
+
+ Following, is an example configuration for a local site.
+
+ ```json
+ {
+ "apps" : {
+ "org.opencord.ce.local.fabric" : {
+ "segmentrouting_ctl": {
+ "publicIp": "YOUR-HEAD-NODE-IP",
+ "port": "8181",
+ "username": "onos",
+ "password": "rocks",
+ "deviceId": "of:C-DPID"
+ }
+ },
+ "org.opencord.ce.local.bigswitch" : {
+ "mefPorts" :
+ [
+ {
+ "mefPortType" : "INNI",
+ "connectPoint" : "of:C-DPID/C1",
+ "interlinkId" : "EE-1-to-fabric"
+ },
+ {
+ "mefPortType" : "ENNI",
+ "connectPoint" : "of:C-DPID/C4 (duplicate as many time as needed, depending how many uplink / connections to other PODs you have)",
+ "interlinkId" : "fabric-1-to-fabric-2"
}
- },
- "org.opencord.ce.local.bigswitch" : {
- "mefPorts" :
- [
- {
- "mefPortType" : "INNI",
- "connectPoint" : "of:C-DPID/C1",
- "interlinkId" : "EE-1-to-fabric"
- },
- {
- "mefPortType" : "ENNI",
- "connectPoint" : "of:C-DPID/C4 (duplicate as many time as needed, depending how many uplink / connections to other PODs you have)",
- "interlinkId" : "fabric-1-to-fabric-2"
- }
- ]
- },
- "org.opencord.ce.local.channel.http" : {
- "global" : {
- "publicIp" : "YOUR-GLOBAL-NODE-IP",
- "port" : "8182",
- "username" : "onos",
- "password" : "rocks",
- "topic" : "ecord-domains-topic-one"
- }
+ ]
+ },
+ "org.opencord.ce.local.channel.http" : {
+ "global" : {
+ "publicIp" : "YOUR-GLOBAL-NODE-IP",
+ "port" : "8182",
+ "username" : "onos",
+ "password" : "rocks",
+ "topic" : "ecord-domains-topic-one"
}
}
}
- ```
+ }
+ ```
* Use CURL to push your file
- ```
- curl -X POST -H "content-type:application/json" http://YOUR-LOCAL-HEAD-NODE-IP:8181/onos/v1/network/configuration -d @YOUR-JSON-FILE.json --user onos:rocks
- ```
+
+ ```shell
+ curl -X POST -H "content-type:application/json" http://YOUR-LOCAL-HEAD-NODE-IP:8181/onos/v1/network/configuration -d @YOUR-JSON-FILE.json --user onos:rocks
+ ```
#### MEF Ports
-Under the key `mefPorts` there is the list of physical ports that have to be exposed to the global node. These ports represent MEF ports and can belong to different physical devices, but they will be part of a single abstract “bigswitch” in the topology of the global ONOS (see [E-CORD topology abstraction](https://guide.opencord.org/profiles/ecord/overview.html#e-cord-topology-abstraction)). These ports represent also the boundary between physical topologies controlled by different ONOS controllers.
+Under the key `mefPorts` there is the list of physical ports that have to be
+exposed to the global node. These ports represent MEF ports and can belong to
+different physical devices, but they will be part of a single abstract
+“bigswitch” in the topology of the global ONOS (see [E-CORD topology
+abstraction](https://guide.opencord.org/profiles/ecord/overview.html#e-cord-topology-abstraction)).
+These ports represent also the boundary between physical topologies controlled
+by different ONOS controllers.
In the Json above:
-* *of:C-DPID/C1* is the DPID and the port of the fabric device where the Ethernet Edge Device is connected to.
-* *of:C-DPID/C4* is the DPID and the port of the fabric device where the transport network is connected to (in the example fabric switches are connected together).
+
+* *of:C-DPID/C1* is the DPID and the port of the fabric device where the
+ Ethernet Edge Device is connected to.
+* *of:C-DPID/C4* is the DPID and the port of the fabric device where the
+ transport network is connected to (in the example fabric switches are
+ connected together).
This is hinted through the `interlinkId` value.
#### Topic Attribute
-The `topic` attribute under the `org.opencord.ce.local.channel.http` is a string of your choice. It is used to run an election in an ONOS cluster to choose the ONOS instance that interacts with the global node.
+The `topic` attribute under the `org.opencord.ce.local.channel.http` is a
+string of your choice. It is used to run an election in an ONOS cluster to
+choose the ONOS instance that interacts with the global node.
### ONOS_CORD Configuration
@@ -392,96 +488,117 @@
[here](https://wiki.onosproject.org/display/ONOS/NETCONF)).
The Ethernet Edge device is managed through OpenFlow.
-Both the devices, at the end of the configuration procedure should
-show up in ONOS_CORD, which can be confirmed by typing `devices` in the ONOS CLI (*onos>*).
+
+Both the devices, at the end of the configuration procedure should show up in
+ONOS_CORD, which can be confirmed by typing `devices` in the ONOS CLI
+(`onos>`).
To configure ONOS_CORD do the following:
+
* SSH into the head node
* Login to onos-cord: `ssh -p 8102 onos@onos-cord`
* At the ONOS CLI verify that apps are loaded: `apps -a -s`
- The following applications should be enabled:
- ```
- org.onosproject.drivers.microsemi
- org.onosproject.cfm
- org.opencord.ce.api
- org.opencord.ce.local.bigswitch
- org.opencord.ce.local.channel.http
- org.opencord.ce.local.vee
- ```
- If one or more apps mentioned above are not present in the list, they can be activated with app activate APP-NAME
-* Create a new JSON file and write your configuration. As a template, you can use the JSON below:
- ```
- {
- "devices": {
- "netconf:YOUR-CPE-IP:830": {
- "netconf": {
- "username": "admin",
- "password": "admin",
- "ip": "A-IP",
- "port": "830"
- },
- "basic": {
- "driver": "microsemi-netconf",
- "type": "SWITCH",
- "manufacturer": "Microsemi",
- "hwVersion": "EA1000"
- }
- }
+
+ The following applications should be enabled:
+
+ ```shell
+ org.onosproject.drivers.microsemi
+ org.onosproject.cfm
+ org.opencord.ce.api
+ org.opencord.ce.local.bigswitch
+ org.opencord.ce.local.channel.http
+ org.opencord.ce.local.vee
+ ```
+
+ If one or more apps mentioned above are not present in the list, they can be
+ activated with app activate APP-NAME
+
+* Create a new JSON file and write your configuration. As a template, you can
+ use the JSON below:
+
+ ```json
+ {
+ "devices": {
+ "netconf:YOUR-CPE-IP:830": {
+ "netconf": {
+ "username": "admin",
+ "password": "admin",
+ "ip": "A-IP",
+ "port": "830"
},
- "links": {
- "netconf:A-IP:830/0-of:B-DPID/B1" : {
- "basic" : {
- "type" : "DIRECT"
- }
- },
- "of:B-DPID/B1-netconf:A-IP:830/0" : {
- "basic" : {
- "type" : "DIRECT"
- }
- }
- },
- "apps" : {
- "org.opencord.ce.local.bigswitch" : {
- "mefPorts" :
- [
- {
- "mefPortType" : "UNI",
- "connectPoint" : "netconf:A-IP:830/0"
- },
- {
- "mefPortType" : "INNI",
- "connectPoint" : "of:B-DPID",
- "interlinkId" : "EE-2-fabric"
- }
- ]
- },
- "org.opencord.ce.local.channel.http" : {
- "global" : {
- "publicIp" : "YOUR-GLOBAL-NODE-IP",
- "port" : "8182",
- "username" : "onos",
- "password" : "rocks",
- "topic" : "ecord-domains-topic-one"
- }
- }
+ "basic": {
+ "driver": "microsemi-netconf",
+ "type": "SWITCH",
+ "manufacturer": "Microsemi",
+ "hwVersion": "EA1000"
}
}
- ```
+ },
+ "links": {
+ "netconf:A-IP:830/0-of:B-DPID/B1" : {
+ "basic" : {
+ "type" : "DIRECT"
+ }
+ },
+ "of:B-DPID/B1-netconf:A-IP:830/0" : {
+ "basic" : {
+ "type" : "DIRECT"
+ }
+ }
+ },
+ "apps" : {
+ "org.opencord.ce.local.bigswitch" : {
+ "mefPorts" :
+ [
+ {
+ "mefPortType" : "UNI",
+ "connectPoint" : "netconf:A-IP:830/0"
+ },
+ {
+ "mefPortType" : "INNI",
+ "connectPoint" : "of:B-DPID",
+ "interlinkId" : "EE-2-fabric"
+ }
+ ]
+ },
+ "org.opencord.ce.local.channel.http" : {
+ "global" : {
+ "publicIp" : "YOUR-GLOBAL-NODE-IP",
+ "port" : "8182",
+ "username" : "onos",
+ "password" : "rocks",
+ "topic" : "ecord-domains-topic-one"
+ }
+ }
+ }
+ }
+ ```
+
* Load the following the Json file just created using curl:
- ```
- curl -X POST -H "content-type:application/json" http://YOUR-LOCAL-SITE-HEAD-IP:8182/onos/v1/network/configuration -d @YOUR-JSON-FILE.json --user onos:rocks
- ```
-> **Warning** The JSON above tries to configure devices and links at the same time. It may happen that ONOS denies your request of link creation, since it does not find devices present (because their creation is still in progress). If this happens, just wait few seconds and try to push again the same configuration, using the *curl* command above.
+ ```shell
+ curl -X POST -H "content-type:application/json" http://YOUR-LOCAL-SITE-HEAD-IP:8182/onos/v1/network/configuration -d @YOUR-JSON-FILE.json --user onos:rocks
+ ```
-# Done!
-After the global node and the local sites are properly configured, the global node should maintain an abstract view of the topology and you should see UNIs distributed on the map of the XoS GUI. You can start requests to setup Ethernet Virtual Circuit (EVC) from XoS.
+> WARNING: The JSON above tries to configure devices and links at the same
+> time. It may happen that ONOS denies your request of link creation, since it
+> does not find devices present (because their creation is still in progress).
+> If this happens, just wait few seconds and try to push again the same
+> configuration, using the *curl* command above.
-# Demo: Create an E-Line Using the GUI
+## Done
+
+After the global node and the local sites are properly configured, the global
+node should maintain an abstract view of the topology and you should see UNIs
+distributed on the map of the XoS GUI. You can start requests to setup Ethernet
+Virtual Circuit (EVC) from XoS.
+
+## Demo: Create an E-Line Using the GUI
* SSH into global node
* From */opt/credentials/xosadmin@opencord.org* copy the XOS password
-* From a computer, able to reach the global node, open a browser and go to *YOUR_GLOBAL_NODE_IP/xos*
+* From a computer, able to reach the global node, open a browser and go to
+ *YOUR_GLOBAL_NODE_IP/xos*
* Use the following username/password to access:
* Username: `xosadmin@opencord.org`
* Password: YOUR_PASSWORD_COPIED_AT_THE_STEP_BEFORE
@@ -494,47 +611,65 @@
* Input a CORD Site name (i.e. test demo)
* Input a VLAN id (i.e. 100)
* Click on another CORD symbol
-* Click “Finish connection”. This will populate the field “Connect point 2 ID” in the right menu
+* Click “Finish connection”. This will populate the field “Connect point 2 ID”
+ in the right menu
* Click save changes on the right menu
-A line should appear between the two icons, meaning that a request to connect the two end-points has been saved. The line should become green in few seconds. Green lines are good signs of a working environment.
+A line should appear between the two icons, meaning that a request to connect
+the two end-points has been saved. The line should become green in few seconds.
+Green lines are good signs of a working environment.
## End-Point Communication
-You should now be able to let communicate together the two end-points
-connected to the CPEs. Each of the two end-points need to be
-configured to send-out packets tagged with the same VLAN Id(s).
+You should now be able to let communicate together the two end-points connected
+to the CPEs. Each of the two end-points need to be configured to send-out
+packets tagged with the same VLAN Id(s).
-Assuming you just configured VLAN id 100 in the UI, and that the two end-points will communicate together using the 192.168.1.0/24 subnet, on each head do the following:
+Assuming you just configured VLAN id 100 in the UI, and that the two end-points
+will communicate together using the 192.168.1.0/24 subnet, on each head do the
+following:
+
* *apt-get install vlan*
* *sudo modprobe 8021q*
* Activate by default at startup the vlan module
* *sudo sh -c 'grep -q 8021q /etc/modules || echo 8021q >> /etc/modules'*
* *vi /etc/network/interfaces* and add an alias, VLAN tagged interface
- ```
- auto YOUR_INTERFACE_CONNECTED_TO_INTERNAL_NETWORK.100
- iface YOUR_INTERFACE_CONNECTED_TO_INTERNAL_NETWORK.100 inet static
- address 192.168.1.1 (for the first head node, or 2 for the second one)
- netmask 255.255.255.0
- ```
+
+ ```shell
+ auto YOUR_INTERFACE_CONNECTED_TO_INTERNAL_NETWORK.100
+ iface YOUR_INTERFACE_CONNECTED_TO_INTERNAL_NETWORK.100 inet static
+ address 192.168.1.1 (for the first head node, or 2 for the second one)
+ netmask 255.255.255.0
+ ```
+
* Save
* Bring up the interface with *sudo ifup YOUR_INTERFACE_CONNECTED_TO_THE_CPE.100*
-## Success: Ping!
+## Success: Ping
+
If everything works fine, the two hosts should be able to ping one each other.
-# Connecting to Internet
-A local E-CORD pod is also capable of connecting an enterprise to the public Internet through the same CPE we leverage to setup the EVC.
+## Connecting to Internet
+
+A local E-CORD pod is also capable of connecting an enterprise to the public
+Internet through the same CPE we leverage to setup the EVC.
In order to achive this connectivity you need to:
+
* Generate traffic with a different c-tag form the ones used in your EVCs.
-* Install a rule in the MicroSemi EA1000 CPE to take the newly tagged traffic and push a different s-tag than the one used for EVCs.
-* Configure the IP of the leaf switch interface to which the upstream router is connected. The IP of this interface needs to be on the same subnet as the upstream router.
+* Install a rule in the MicroSemi EA1000 CPE to take the newly tagged traffic
+ and push a different s-tag than the one used for EVCs.
+* Configure the IP of the leaf switch interface to which the upstream router is
+ connected. The IP of this interface needs to be on the same subnet as the
+ upstream router.
* Configure in ONOS fabric a default route to the upstream router.
-* Configure a cross connect into the fabric to ensure the traffic gets forwarded towards the compute node where the vEG instances get spawned.
+* Configure a cross connect into the fabric to ensure the traffic gets
+ forwarded towards the compute node where the vEG instances get spawned.
* Create a subsciber. A an example of how to run a test one is
- [here](https://guide.opencord.org/profiles/ecord/dev_guide.html#run-an-e-cord-test-subscriber). This
- subscriber creates an instance of the different services needed to
+ [here](https://guide.opencord.org/profiles/ecord/dev_guide.html#run-an-e-cord-test-subscriber).
+ This subscriber creates an instance of the different services needed to
connect to the public Internet.
-At this point you should be able to connect to the public Internet through your E-CORD local pod.
+At this point you should be able to connect to the public Internet through your
+E-CORD local pod.
+
diff --git a/docs/overview.md b/docs/overview.md
index 5bbbda1..971d3b9 100644
--- a/docs/overview.md
+++ b/docs/overview.md
@@ -1,110 +1,198 @@
# What is E-CORD?
-Enterprise CORD (E-CORD) is a CORD use case that offers enterprise connectivity services over metro and wide area networks, using open source software and commodity hardware.
+Enterprise CORD (E-CORD) is a CORD use case that offers enterprise connectivity
+services over metro and wide area networks, using open source software and
+commodity hardware.
-<img src="static/images/overview.png" alt="E-CORD overview" style="width: 800px;"/>
+
-E-CORD builds on the CORD platform to support enterprise customers, and allows Service Providers to offer enterprise connectivity services (L2 and L3VPN).
-It can also go beyond these simple connectivity services to include Virtual Network Functions (VNFs) and service composition capabilities to support disruptive cloud-based enterprise services.
+E-CORD builds on the CORD platform to support enterprise customers, and allows
+Service Providers to offer enterprise connectivity services (L2 and L3VPN). It
+can also go beyond these simple connectivity services to include Virtual
+Network Functions (VNFs) and service composition capabilities to support
+disruptive cloud-based enterprise services.
-Enterprise customers can use E-CORD to rapidly create on-demand networks between any number of endpoints or company branches. These networks are dynamically configurable, implying connection attributes and SLAs can be specified and provisioned on the fly. Furthermore, enterprise customers may choose to run network functions such as firewalls, WAN accelerators, traffic analytic tools, virtual routers, etc. as on-demand services that are provisioned and maintained inside the service provider network.
+Enterprise customers can use E-CORD to rapidly create on-demand networks
+between any number of endpoints or company branches. These networks are
+dynamically configurable, implying connection attributes and SLAs can be
+specified and provisioned on the fly. Furthermore, enterprise customers may
+choose to run network functions such as firewalls, WAN accelerators, traffic
+analytic tools, virtual routers, etc. as on-demand services that are
+provisioned and maintained inside the service provider network.
-# Glossary
+## Glossary
The section provides a list of the basic terms used in E-CORD
-
- * **Local POD**: Each local CORD POD (also identified in the guide as an E-CORD site) is a standard CORD POD equipped with specific access equipment. It is usually located in the Service Provider’s Central Offices and is mainly used to: 1) connect the enterprise user to the Service Provider network; and 2) run value added user services (e.g., firewalls, traffic analytic tools, WAN accelerators) at the edge of the network, close to the enterprise sites. Upstream, the POD usually connects to the Service Provider metro/transport network or to the public internet.
-
-* **Global Node**: The global node is a single machine running either in the cloud, or in any other part of the Service Provider network, used to coordinate connectivity and services among all the local PODs of the E-CORD deployment. It consists of an instance of XOS (global orchestrator) and ONOS (controlling the transport network interconnecting edge sites).
-# System Overview
+* **Local POD**: Each local CORD POD (also identified in the guide as an E-CORD
+ site) is a standard CORD POD equipped with specific access equipment. It is
+ usually located in the Service Provider’s Central Offices and is mainly used
+ to: 1) connect the enterprise user to the Service Provider network; and 2)
+ run value added user services (e.g., firewalls, traffic analytic tools, WAN
+ accelerators) at the edge of the network, close to the enterprise sites.
+ Upstream, the POD usually connects to the Service Provider metro/transport
+ network or to the public internet.
-A typical E-CORD deployment is made of one global node and multiple (minimum two) CORD sites (PODs), connected to the same transport network.
+* **Global Node**: The global node is a single machine running either in the
+ cloud, or in any other part of the Service Provider network, used to
+ coordinate connectivity and services among all the local PODs of the E-CORD
+ deployment. It consists of an instance of XOS (global orchestrator) and ONOS
+ (controlling the transport network interconnecting edge sites).
-<img src="static/images/ecord-dataplane.png" alt="E-CORD dataplane" style="width: 800px;"/>
+## System Overview
-Each site is a standard CORD POD comprised of one or more compute nodes, and one or more fabric switches. The transport network provides connectivity between the CORD sites. It can be anything from a converged packet-optical network, to a single packet switch for demo purposes. The transport network can be composed of white-box switches, legacy equipment, or a mix of both. The minimum requirement in order to deploy E-CORD is to provide Layer 2 connectivity between the PODs, specifically between the leaf fabric switches that face the upstream/metro network of the COs.
+A typical E-CORD deployment is made of one global node and multiple (minimum
+two) CORD sites (PODs), connected to the same transport network.
-> Usually, for lab trials, the leaf switches of the two sites (PODs) are connected directly through a cable, or through a legacy L2 switch.
+
-## Global Node
+Each site is a standard CORD POD comprised of one or more compute nodes, and
+one or more fabric switches. The transport network provides connectivity
+between the CORD sites. It can be anything from a converged packet-optical
+network, to a single packet switch for demo purposes. The transport network can
+be composed of white-box switches, legacy equipment, or a mix of both. The
+minimum requirement in order to deploy E-CORD is to provide Layer 2
+connectivity between the PODs, specifically between the leaf fabric switches
+that face the upstream/metro network of the COs.
-The global node is responsible for orchestrating users’ requests and to manage the connectivity and the services provisioning. It runs only an instance of XOS and an instance of ONOS (specifically ONOS_CORD). The ONOS instance (ONOS_CORD) manages the end-to-end traffic forwarded between the sites.
-
+> NOTE: Usually, for lab trials, the leaf switches of the two sites (PODs) are
+> connected directly through a cable, or through a legacy L2 switch.
+
+### Global Node
+
+The global node is responsible for orchestrating users’ requests and to manage
+the connectivity and the services provisioning. It runs only an instance of XOS
+and an instance of ONOS (specifically ONOS_CORD). The ONOS instance (ONOS_CORD)
+manages the end-to-end traffic forwarded between the sites.
+
The global ONOS is composed of three modules:
-* **Carrier Ethernet Orchestrator**: Exposes a Northbound REST interface to receive requests to create Ethernet Virtual Circuits (EVCs).
+* **Carrier Ethernet Orchestrator**: Exposes a Northbound REST interface to
+ receive requests to create Ethernet Virtual Circuits (EVCs).
-* **Virtual Provider**: Manages the abstract view of the local E-CORD sites topologies.
+* **Virtual Provider**: Manages the abstract view of the local E-CORD sites
+ topologies.
-* **Global HTTP Channel**: Supports communication with the local sites.
+* **Global HTTP Channel**: Supports communication with the local sites.
-## Local Sites
+### Local Sites
-Local sites are responsible for collecting users’ traffic and forwarding it either to other local sites or to the Internet. Each local site comes with two ONOS controllers that are part of the reference architecture of CORD: ONOS_CORD and ONOS_Fabric. The Carrier Ethernet application of E-CORD uses both controllers to provision the physical network:
-
- * **ONOS_CORD**: Runs the application that controls the edge access, including the CPE devices and the Ethernet Edge (EE) devices.
-
-* **ONOS_Fabric**: Runs the application configuring the cross connections within the fabric of CORD, to bridge the CPEs to the transport network and to the remote sites.
-
-The following components are added to ONOS_CORD:
+Local sites are responsible for collecting users’ traffic and forwarding it
+either to other local sites or to the Internet. Each local site comes with two
+ONOS controllers that are part of the reference architecture of CORD: ONOS_CORD
+and ONOS_Fabric. The Carrier Ethernet application of E-CORD uses both
+controllers to provision the physical network:
+
+* **ONOS_CORD**: Runs the application that controls the edge access, including
+ the CPE devices and the Ethernet Edge (EE) devices.
+
+* **ONOS_Fabric**: Runs the application configuring the cross connections
+ within the fabric of CORD, to bridge the CPEs to the transport network and to
+ the remote sites.
+
+The following components are added to ONOS_CORD:
+
* CE-API
* Bigswitch service
-* HTTP channel
+* HTTP channel
* CE-VEE
-
-The following components are added to ONOS_Fabric:
+
+The following components are added to ONOS_Fabric:
+
* CE-API
* Bigswitch service
-* HTTP channel
+* HTTP channel
* CE-fabric
-
-The CE-API, the bigswitch service, and the HTTP channel are common to both ONOS_CORD and ONOS_Fabric. They are used to put in communication the ONOS running on the global node and the ones running on the local sites.
-
-The local sites abstract their network topology and expose it to the global node. They receive requests from the global ONOS, and provision the network for the EVCs setup.
-## Service Graph
+The CE-API, the bigswitch service, and the HTTP channel are common to both
+ONOS_CORD and ONOS_Fabric. They are used to put in communication the ONOS
+running on the global node and the ones running on the local sites.
-The global node implements a single service called **vNaaS** (**virtual Network as a Service**) that is responsible for controlling end-to-end connectivity between the PODs.
-
-Each local site implements multiple services that collectively control the underlying hardware and software, and are thus able to connect the Enterprise Subscriber from the edge of the Central Office to the upstream network.
-
+The local sites abstract their network topology and expose it to the global
+node. They receive requests from the global ONOS, and provision the network for
+the EVCs setup.
+
+### Service Graph
+
+The global node implements a single service called **vNaaS** (**virtual Network
+as a Service**) that is responsible for controlling end-to-end connectivity
+between the PODs.
+
+Each local site implements multiple services that collectively control the
+underlying hardware and software, and are thus able to connect the Enterprise
+Subscriber from the edge of the Central Office to the upstream network.
+
A representation of the default E-CORD local site service graph is shown below.
-<img src="static/images/xos-service-chain.png" alt="XOS Service Graph" style="width: 600px;"/>
+
The local graph consists of five different services with different responsibilities.
-
- * **vCPE (Virtual Customer Premise Equipment)**: Inserts an 802.1ad (QinQ) header to the upstream packets of an Enterprise Subscriber and removes it for downstream flows. Packets are tagged with a vlanId (the Service Provider tag, s-tag) and then forwarded to the Ethernet Edge. The s-tag is associated with one or more c-tag (customer tags, the vlanId of the 802.1q protocol) to isolate the traffic within the Service Provider network. The vCPE function is very similar to that of vOLT in R-CORD.
-
- * **vEE (Virtual Ethernet Edge)**: Aggregates traffic from multiple customers with CPEs and applies policing and forwarding to the fabric. The vEE is also responsible for making routing decisions on the traffic. The vEE filters the traffic meant for the enterprise network and sends it through pseudo-wire in the fabric directly to the transport network and the other enterprise branch. If the vEE recognizes that the traffic is instead meant for the public Internet, it will send it to the vEG and then to the vRouter.
-
- * **vEG (Virtual Enterprise Gateway)**: Runs selected VNFs, such as bandwidth metering, firewall, diagnostics etc, and possibly forwards the traffic to the vRouter.
-
- * **vRouter (Virtual Router)**: Responsible for sending traffic out of the CORD POD to the public Internet. It is the same service that is present in the R-CORD service chain. More information about it can be found [here](https://guide.opencord.org/vrouter.html#connecting-to-upstream-networks-using-vrouter).
-
-* **PWaaS**: Enables a “pass-through”** in the leaf-spine fabric, allowing traffic to directly go out to the metro network. This is done through a configuration of the segment routing application.
+
+* **vCPE (Virtual Customer Premise Equipment)**: Inserts an 802.1ad (QinQ)
+ header to the upstream packets of an Enterprise Subscriber and removes it
+ for downstream flows. Packets are tagged with a vlanId (the Service Provider
+ tag, s-tag) and then forwarded to the Ethernet Edge. The s-tag is
+ associated with one or more c-tag (customer tags, the vlanId of the 802.1q
+ protocol) to isolate the traffic within the Service Provider network. The
+ vCPE function is very similar to that of vOLT in R-CORD.
+
+* **vEE (Virtual Ethernet Edge)**: Aggregates traffic from multiple customers
+ with CPEs and applies policing and forwarding to the fabric. The vEE is also
+ responsible for making routing decisions on the traffic. The vEE filters the
+ traffic meant for the enterprise network and sends it through pseudo-wire in
+ the fabric directly to the transport network and the other enterprise
+ branch. If the vEE recognizes that the traffic is instead meant for the
+ public Internet, it will send it to the vEG and then to the vRouter.
+
+* **vEG (Virtual Enterprise Gateway)**: Runs selected VNFs, such as bandwidth
+ metering, firewall, diagnostics etc, and possibly forwards the traffic to
+ the vRouter.
+
+* **vRouter (Virtual Router)**: Responsible for sending traffic out of the
+ CORD POD to the public Internet. It is the same service that is present in
+ the R-CORD service chain. More information about it can be found
+ [here](/vrouter.md#connecting-to-upstream-networks-using-vrouter).
+
+* **PWaaS**: Enables a “pass-through”** in the leaf-spine fabric, allowing
+ traffic to directly go out to the metro network. This is done through a
+ configuration of the segment routing application.
## Topology Abstraction
-The global node maintains an abstract view of the underlying topology for the sake of scalability and to separate domain-specific and domain-agnostic concerns. Note that in a single CORD POD there are two independent ONOS controllers: ONOS_CORD and ONOS_Fabric. For each local site, the E-CORD application exposes two abstract devices to the global node: one is exposed by the ONOS_CORD and the other by the ONOS_Fabric. They represent an aggregation of the real network elements that compose the topology of a local site.
+The global node maintains an abstract view of the underlying topology for the
+sake of scalability and to separate domain-specific and domain-agnostic
+concerns. Note that in a single CORD POD there are two independent ONOS
+controllers: ONOS_CORD and ONOS_Fabric. For each local site, the E-CORD
+application exposes two abstract devices to the global node: one is exposed by
+the ONOS_CORD and the other by the ONOS_Fabric. They represent an aggregation
+of the real network elements that compose the topology of a local site.
-The picture below shows how the two topologies get abstracted and exposed to the ONOS instance running on the global node.
+The picture below shows how the two topologies get abstracted and exposed to
+the ONOS instance running on the global node.
-<img src="static/images/topology-abstraction-01.png" alt="Topology Abstraction" style="width: 600px;"/>
+
-In this way, the global ONOS has fewer devices and link data structures to deal with. Path computation involves only these aggregated items, while the actual network provisioning is achieved by the local site controllers.
-
+In this way, the global ONOS has fewer devices and link data structures to deal
+with. Path computation involves only these aggregated items, while the actual
+network provisioning is achieved by the local site controllers.
+
The relevant topology information for the global node include
-* **User-to-Network Interfaces (UNIs)**: See [MEF specs](https://www.mef.net/resources/technical-specifications).
+* **User-to-Network Interfaces (UNIs)**: See [MEF
+ specs](https://www.mef.net/resources/technical-specifications).
-* **Network-to-Network Interfaces (NNIs)**: See [MEF specs](https://www.mef.net/resources/technical-specifications).
+* **Network-to-Network Interfaces (NNIs)**: See [MEF
+ specs](https://www.mef.net/resources/technical-specifications).
* **Associated bandwidth capacities**: For admission control.
-
-The NNI ports are annotated with an inter-link identifier (`interlinkId`) so that the global node can understand which ports are at the ends of which inter-domain links.
-
-The inter-domain link connects to devices controlled by different ONOS controllers at local level. See the ONOS_FABRIC and ONOS_CORD json configuration sections in the installation guide for more examples,
-<img src="static/images/topology-abstraction-02.png" alt="Topology Abstraction" style="width: 600px;"/>
+The NNI ports are annotated with an inter-link identifier (`interlinkId`) so
+that the global node can understand which ports are at the ends of which
+inter-domain links.
+
+The inter-domain link connects to devices controlled by different ONOS
+controllers at local level. See the ONOS_FABRIC and ONOS_CORD json
+configuration sections in the installation guide for more examples,
+
+
+
diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md
index 6b4d24e..1c5867b 100644
--- a/docs/troubleshooting.md
+++ b/docs/troubleshooting.md
@@ -4,219 +4,273 @@
## Reset the nodes
-Through these steps we will bring all your pods back to a clean state.
+Through these steps we will bring all your pods back to a clean state.
You will need the reset scripts under:
-```
+
+```shell
CORD_ROOT/orchestration/profiles/ecord/examples/
```
+
### Global node
+
Let's start with the global node.
-#### Reset Step
+#### Global Reset Step
+
* SSH into the global node
* execute these commands
- ```
- cd CORD_ROOT/orchestration/profiles/ecord/examples/
- chmod +x reset-global.sh
- ./reset-global.sh YOUR_GLOBAL_NODE_IP YOUR_PROPER_PATH_TO_THE_GLOBAL_JSON_CONFIG_FILE
- ```
- an example of the last command is:
- ```
- ./reset-global.sh 127.0.0.1 ~/global-onos-fabric.json
- ```
-#### Check Step
+ ```shell
+ cd CORD_ROOT/orchestration/profiles/ecord/examples/
+ chmod +x reset-global.sh
+ ./reset-global.sh YOUR_GLOBAL_NODE_IP YOUR_PROPER_PATH_TO_THE_GLOBAL_JSON_CONFIG_FILE
+ ```
+
+ an example of the last command is:
+
+ ```shell
+ ./reset-global.sh 127.0.0.1 ~/global-onos-fabric.json
+ ```
+
+#### Global Check Step
+
Once the reset step is finished we can check if the state is what we expect.
##### XOS
+
* Login into the XOS UI at:
- ```
- http://<YOUR_GLOBAL_NODE_IP>/xos
- ```
+
+ ```html
+ http://<YOUR_GLOBAL_NODE_IP>/xos
+ ```
+
* Click on the *vNaaS* tab on the left
* Click on *Ethernet Virtual Lines* and make sure nothing is there
-* Click on *Bandwidth Profiles* and make sure there is at least one bandwidth profile
-* Click on *User Network Interfaces* and make sure there that your UNIs are present
+* Click on *Bandwidth Profiles* and make sure there is at least one bandwidth
+ profile
+* Click on *User Network Interfaces* and make sure there that your UNIs are
+ present
##### ONOS
-* Log into ONOS_CORD: `ssh -p 8102 onos@onos-cord`
-* In the ONOS CLI (onos>) verify that apps are loaded: `apps -a -s`
- The list of applications enabled should include:
- ```
- org.opencord.ce.api
- org.opencord.ce.global
- ```
+* Log into ONOS_CORD: `ssh -p 8102 onos@onos-cord`
+* In the ONOS CLI (onos>) verify that apps are loaded: `apps -a -s`
+
+ The list of applications enabled should include:
+
+ ```shell
+ org.opencord.ce.api
+ org.opencord.ce.global
+ ```
### Local Node(s)
+
Let's continue with all your local pods.
-#### Reset Step
+#### Local Reset Step
+
* SSH into the local head node
* exectue these commands
- ```
- cd CORD_ROOT/orchestration/profiles/ecord/examples/
- chmod +x reset-local.sh
- ./reset-local.sh YOUR_LOCAL_NODE_IP YOUR_PATH_TO_ONOS_FABRIC_JSON_CONFIG_FILE YOUR_PATH_TO_THE_ONOS_CORD_JSON_CONFIG_FILE
- ```
- an example of the last one is:
- ```
- ./reset-local.sh 127.0.0.1 ~/local-1-onos-fabric.json ~/local-1-onos-cord.json
- ```
-#### Check Step
+ ```shell
+ cd CORD_ROOT/orchestration/profiles/ecord/examples/
+ chmod +x reset-local.sh
+ ./reset-local.sh YOUR_LOCAL_NODE_IP YOUR_PATH_TO_ONOS_FABRIC_JSON_CONFIG_FILE YOUR_PATH_TO_THE_ONOS_CORD_JSON_CONFIG_FILE
+ ```
+
+ an example of the last one is:
+
+ ```shell
+ ./reset-local.sh 127.0.0.1 ~/local-1-onos-fabric.json ~/local-1-onos-cord.json
+ ```
+
+#### Local Check Step
+
Once the reset step is finished we can check if the state is what we expect.
##### ONOS Fabric
+
Let's start with the ONOS_CORD.
+
* Log into ONOS_Fabric: `ssh -p 8101 onos@onos-fabric`
-* In the ONOS CLI (onos>) verify that apps are loaded: `apps -a -s`
+* In the ONOS CLI (onos>) verify that apps are loaded: `apps -a -s`
The list of applications enabled should include:
- ```
- org.onosproject.segmentrouting
- org.opencord.ce.api
- org.opencord.ce.local.bigswitch
- org.opencord.ce.local.channel.http
- org.opencord.ce.local.fabric
- ```
+
+ ```shell
+ org.onosproject.segmentrouting
+ org.opencord.ce.api
+ org.opencord.ce.local.bigswitch
+ org.opencord.ce.local.channel.http
+ org.opencord.ce.local.fabric
+ ```
+
* Check that the BigSwitchManager configuration is properly set by typing
- ```
- cfg get org.opencord.ce.local.bigswitch.BigSwitchManager
- ```
- The output should be:
- ```
- org.opencord.ce.local.bigswitch.BigSwitchManager
- name=domainId, type=string, value=<YOUR_LOCAL_NODE_IP>-fabric-onos, defaultValue=local-domain, description=Domain ID where this ONOS is running
- ```
+
+ ```shell
+ cfg get org.opencord.ce.local.bigswitch.BigSwitchManager
+ ```
+
+ The output should be:
+
+ ```shell
+ org.opencord.ce.local.bigswitch.BigSwitchManager
+ name=domainId, type=string, value=<YOUR_LOCAL_NODE_IP>-fabric-onos, defaultValue=local-domain, description=Domain ID where this ONOS is running
+ ```
##### ONOS CORD
+
Let's now take a look at the ONOS_CORD.
* Log into ONOS_CORD: `ssh -p 8102 onos@onos-cord`
-* Verify that apps are loaded: `apps -a -s`
- The list of applications enabled should include:
- ```
- org.onosproject.drivers.microsemi
- org.onosproject.cfm
- org.opencord.ce.api
- org.opencord.ce.local.bigswitch
- org.opencord.ce.local.channel.http
- org.opencord.ce.local.vee
- ```
+* Verify that apps are loaded: `apps -a -s`
-* Verify that at least 3 devices, a netconf one and two openflow are presentbyt typing `devices` in the ONOS CLI.
- An example is:
- ```
- onos> devices
- id=netconf:10.6.0.160:830, available=true, local-status=connected 34s ago, role=MASTER, type=SWITCH, mfr=Microsemi, hw=EA1000, sw=2.6.33-arm1-MSEA1000--00392-ge9ee017.1.0.0.96-dirty, serial=SJC162300029 , driver=microsemi-netconf, ipaddress=10.6.0.160, locType=geo, name=netconf:10.6.0.160:830, port=830, protocol=NETCONF
- id=of:0000001e08095936, available=true, local-status=connected 1m53s ago, role=MASTER, type=SWITCH, mfr=2004-2015 Centec Networks Inc, hw=48T4X, sw=3.1.16.17.alpha, serial=E101ZB141004, driver=default, channelId=10.6.0.150:48073, managementAddress=10.6.0.150, protocol=OF_13
- id=of:00003cfdfe9df039, available=true, local-status=connected 1m53s ago, role=MASTER, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.3.2, serial=None, driver=ovs, channelId=10.6.0.14:34793, managementAddress=10.6.0.14, protocol=OF_13
- ```
+ The list of applications enabled should include:
+
+ ```shell
+ org.onosproject.drivers.microsemi
+ org.onosproject.cfm
+ org.opencord.ce.api
+ org.opencord.ce.local.bigswitch
+ org.opencord.ce.local.channel.http
+ org.opencord.ce.local.vee
+ ```
+
+* Verify that at least 3 devices, a netconf one and two openflow are present by
+ typing `devices` in the ONOS CLI.
+
+ An example is:
+
+ ```shell
+ onos> devices
+ id=netconf:10.6.0.160:830, available=true, local-status=connected 34s ago, role=MASTER, type=SWITCH, mfr=Microsemi, hw=EA1000, sw=2.6.33-arm1-MSEA1000--00392-ge9ee017.1.0.0.96-dirty, serial=SJC162300029 , driver=microsemi-netconf, ipaddress=10.6.0.160, locType=geo, name=netconf:10.6.0.160:830, port=830, protocol=NETCONF
+ id=of:0000001e08095936, available=true, local-status=connected 1m53s ago, role=MASTER, type=SWITCH, mfr=2004-2015 Centec Networks Inc, hw=48T4X, sw=3.1.16.17.alpha, serial=E101ZB141004, driver=default, channelId=10.6.0.150:48073, managementAddress=10.6.0.150, protocol=OF_13
+ id=of:00003cfdfe9df039, available=true, local-status=connected 1m53s ago, role=MASTER, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.3.2, serial=None, driver=ovs, channelId=10.6.0.14:34793, managementAddress=10.6.0.14, protocol=OF_13
+ ```
+
* Check that the BigswitchManagerConfiguration is properly set by typing
- ```
- cfg get org.opencord.ce.local.bigswitch.BigSwitchManager
- ```
- The output should be:
- ```
- org.opencord.ce.local.bigswitch.BigSwitchManager
- name=domainId, type=string, value=<YOUR_LOCAL_NODE_IP>-fabric-onos, defaultValue=local-domain, description=Domain ID where this ONOS is running
- ```
+
+ ```shell
+ cfg get org.opencord.ce.local.bigswitch.BigSwitchManager
+ ```
+
+ The output should be:
+
+ ```shell
+ org.opencord.ce.local.bigswitch.BigSwitchManager
+ name=domainId, type=string, value=<YOUR_LOCAL_NODE_IP>-fabric-onos, defaultValue=local-domain, description=Domain ID where this ONOS is running
+ ```
+
* Check that the BigswitchManagerConfiguration is properly set by typing
- ```
- cfg get org.onosproject.netconf.ctl.impl.NetconfControllerImpl
- ```
- The output should be:
- ```
- org.onosproject.netconf.ctl.impl.NetconfControllerImpl
- name=sshLibrary, type=string, value=apache_mina, defaultValue=apache_mina, description=Ssh Llbrary instead of Apache Mina (i.e. ethz-ssh2
- name=netconfConnectTimeout, type=integer, value=120, defaultValue=5, description=Time (in seconds) to wait for a NETCONF connect.
- name=netconfReplyTimeout, type=integer, value=120, defaultValue=5, description=Time (in seconds) waiting for a NetConf reply
- ```
+
+ ```shell
+ cfg get org.onosproject.netconf.ctl.impl.NetconfControllerImpl
+ ```
+
+ The output should be:
+
+ ```shell
+ org.onosproject.netconf.ctl.impl.NetconfControllerImpl
+ name=sshLibrary, type=string, value=apache_mina, defaultValue=apache_mina, description=Ssh Llbrary instead of Apache Mina (i.e. ethz-ssh2
+ name=netconfConnectTimeout, type=integer, value=120, defaultValue=5, description=Time (in seconds) to wait for a NETCONF connect.
+ name=netconfReplyTimeout, type=integer, value=120, defaultValue=5, description=Time (in seconds) waiting for a NetConf reply
+ ```
### UNI Configuration assurance
-Before pushing the UNI there is one last set of checks to make to be sure the state is properly configured:
+
+Before pushing the UNI there is one last set of checks to make to be sure the
+state is properly configured:
+
* SSH into the global node
* Log in the global ONOS: `ssh -p 8102 onos@onos-cord`
* type `bigswitch-ports`
-* find the port where *mefPortType=UNI* and write down its port number.
- An example is
- ```
- onos> bigswitch-ports
- DefaultPortDescription{number=1, isEnabled=true, type=FIBER, portSpeed=1000, annotations={interlinkId=EE-1-to-fabric, portName=eth-0-50, mefPortType=INNI, portMac=00:1e:08:09:59:69, domainId=10.90.1.30-cord-onos}}
- DefaultPortDescription{number=2, isEnabled=true, type=FIBER, portSpeed=1000, annotations={portName=Optics, mefPortType=UNI, domainId=10.90.1.30-cord-onos}}
- ```
- Where UNI port is number 2
-* log into the XOS UI.
- ```
- http://<YOUR_GLOBAL_NODE_IP>/xos
- ```
+* find the port where *mefPortType=UNI* and write down its port number.
+
+ An example is
+
+ ```shell
+ onos> bigswitch-ports
+ DefaultPortDescription{number=1, isEnabled=true, type=FIBER, portSpeed=1000, annotations={interlinkId=EE-1-to-fabric, portName=eth-0-50, mefPortType=INNI, portMac=00:1e:08:09:59:69, domainId=10.90.1.30-cord-onos}}
+ DefaultPortDescription{number=2, isEnabled=true, type=FIBER, portSpeed=1000, annotations={portName=Optics, mefPortType=UNI, domainId=10.90.1.30-cord-onos}}
+ ```
+
+ Where UNI port is number 2
+
+* log into the XOS UI.
+
+ ```shell
+ http://<YOUR_GLOBAL_NODE_IP>/xos
+ ```
+
* Click on the vNaaS tab on the left
* Click on User Network Interfaces
-* Please make sure the port number (the number after the / in the Cpe id) matches what you wrote down.
- If not, press the hour glass at the far right and edit the number after the / making it match yours. Then on the bottom right click the save and you are done.
-
+* Please make sure the port number (the number after the / in the Cpe id)
+ matches what you wrote down.
+
+ If not, press the hour glass at the far right and edit the number after the /
+ making it match yours. Then on the bottom right click the save and you are
+ done.
+
## RESET Successful
-At this point you should be again in a clean state with all the configuration properly pushed.
+
+At this point you should be again in a clean state with all the configuration
+properly pushed.
## Data Plane Debugging
-So you have successfully set up the EVC in the CORD UI. And yet when
-you try to ping, traffic does not seem to go through. Here we will
-walk you through the different steps to check if and where the data
-path is failing.
-1. First you want to check the flow rules on the MicroSemi SFP.
-To do that, log into the ONOS CORD instance on the pod. You can use
-the UI (port 8182) or the CLI (port 8102). You should see a flow rule
-that matches on the c-tag (you specified it when creating the EVC) and
-pushes the s-tag (this is automatically allocated) on top. A second rule
-reverses this process: match on s-tag and pop it off. This is all we
-can verify for this part of the data path, as the Microsemi driver
-does not support port or flow stats (thus we cannot confirm if the
-packets are actually hitting the device).
+So you have successfully set up the EVC in the CORD UI. And yet when you try to
+ping, traffic does not seem to go through. Here we will walk you through the
+different steps to check if and where the data path is failing.
-2. The next step is to verify the Ethernet edge (Centec in our case)
- switch. This one is also controlled by the same ONOS CORD
- instance from the previous step. First, check if a meter has been
- installed on the switch; the parameters should match the bandwidth
- profile you selected when provisioning the EVC. Next, you should
- also see a flow rule that matches on the s-tag and outputs to the
- fabric port. A second flow rule does the same for the reverse path.
- You can also look at the port counters of the Ethernet edge and
- confirm that both the input port (where the SFP is connected) and
- the output port (where the fabric is connected) are steadily incrementing
- as you'd expect from your ping.
+1. First you want to check the flow rules on the MicroSemi SFP. To do that,
+ log into the ONOS CORD instance on the pod. You can use the UI (port 8182)
+ or the CLI (port 8102). You should see a flow rule that matches on the c-tag
+ (you specified it when creating the EVC) and pushes the s-tag (this is
+ automatically allocated) on top. A second rule reverses this process: match
+ on s-tag and pop it off. This is all we can verify for this part of the data
+ path, as the Microsemi driver does not support port or flow stats (thus we
+ cannot confirm if the packets are actually hitting the device).
-3. To check the fabric data path, start by connecting to the ONOS
- FABRIC instance. This time you will need to connect to the CLI
- (port 8101). First check if the VLAN cross connect is properly
- installed, by checking the output of the ```netcfg```
- command. Search for the *xconnect* configuration for
- *org.onosproject.segmentrouting*, then verify (1) the given vlan
- corresponds to the s-tag, and (2) the given ports connect the
- fabric to the Ethernet edge and to the transport/next
- CO. Afterwards, check the output of the ```flows``` command, where
- you can see how the VLAN cross connect gets instantiated in the
- switch's tables. Again, check the input/output ports and the VLAN
- ID. You can also relate this to the output of the ```groups```
- command. An example output is given below.
+2. The next step is to verify the Ethernet edge (Centec in our case) switch.
+ This one is also controlled by the same ONOS CORD instance from the previous
+ step. First, check if a meter has been installed on the switch; the
+ parameters should match the bandwidth profile you selected when provisioning
+ the EVC. Next, you should also see a flow rule that matches on the s-tag and
+ outputs to the fabric port. A second flow rule does the same for the reverse
+ path. You can also look at the port counters of the Ethernet edge and
+ confirm that both the input port (where the SFP is connected) and the output
+ port (where the fabric is connected) are steadily incrementing as you'd
+ expect from your ping.
-```
-onos> flows
-deviceId=of:0000cc37ab7cc2fa, flowRuleCount=7
- id=7300003f50706b, state=ADDED, bytes=0, packets=0, duration=14, liveType=UNKNOWN, priority=32768, tableId=10, appId=org.onosproject.segmentrouting, payLoad=null, selector=[IN_PORT:37, VLAN_VID:1], treatment=DefaultTrafficTreatment{immediate=[], deferred=[], transition=TABLE:20, meter=None, cleared=false, metadata=null}
- id=7300004524fea3, state=ADDED, bytes=0, packets=0, duration=14, liveType=UNKNOWN, priority=32768, tableId=10, appId=org.onosproject.segmentrouting, payLoad=null, selector=[IN_PORT:30, VLAN_VID:1], treatment=DefaultTrafficTreatment{immediate=[], deferred=[], transition=TABLE:20, meter=None, cleared=false, metadata=null}
- id=730000009feee7, state=ADDED, bytes=0, packets=0, duration=13, liveType=UNKNOWN, priority=1000, tableId=50, appId=org.onosproject.segmentrouting, payLoad=null, selector=[VLAN_VID:1], treatment=DefaultTrafficTreatment{immediate=[], deferred=[GROUP:0x40010000], transition=TABLE:60, meter=None, cleared=false, metadata=null}
- id=1000082927ca9, state=ADDED, bytes=283894, packets=3336, duration=4911, liveType=UNKNOWN, priority=40000, tableId=60, appId=org.onosproject.core, payLoad=null, selector=[ETH_TYPE:lldp], treatment=DefaultTrafficTreatment{immediate=[OUTPUT:CONTROLLER], deferred=[], transition=None, meter=None, cleared=true, metadata=null}
- id=10000a168723c, state=ADDED, bytes=269365, packets=3169, duration=4911, liveType=UNKNOWN, priority=40000, tableId=60, appId=org.onosproject.core, payLoad=null, selector=[ETH_TYPE:bddp], treatment=DefaultTrafficTreatment{immediate=[OUTPUT:CONTROLLER], deferred=[], transition=None, meter=None, cleared=true, metadata=null}
- id=73000030665163, state=ADDED, bytes=0, packets=0, duration=4911, liveType=UNKNOWN, priority=40000, tableId=60, appId=org.onosproject.segmentrouting, payLoad=null, selector=[ETH_TYPE:ipv6, IP_PROTO:58], treatment=DefaultTrafficTreatment{immediate=[OUTPUT:CONTROLLER], deferred=[], transition=None, meter=None, cleared=false, metadata=null}
- id=73000030db30ed, state=ADDED, bytes=0, packets=0, duration=4911, liveType=UNKNOWN, priority=40000, tableId=60, appId=org.onosproject.segmentrouting, payLoad=null, selector=[ETH_TYPE:arp], treatment=DefaultTrafficTreatment{immediate=[OUTPUT:CONTROLLER], deferred=[], transition=None, meter=None, cleared=false, metadata=null}
-onos> groups
-deviceId=of:0000cc37ab7cc2fa, groupCount=3
- id=0x1001e, state=ADDED, type=INDIRECT, bytes=0, packets=0, appId=org.onosproject.segmentrouting
- id=0x1001e, bucket=1, bytes=0, packets=0, actions=[OUTPUT:30]
- id=0x10025, state=ADDED, type=INDIRECT, bytes=0, packets=0, appId=org.onosproject.segmentrouting
- id=0x10025, bucket=1, bytes=0, packets=0, actions=[OUTPUT:37]
- id=0x40010000, state=ADDED, type=ALL, bytes=0, packets=0, appId=org.onosproject.segmentrouting
- id=0x40010000, bucket=1, bytes=0, packets=0, actions=[GROUP:0x10025]
- id=0x40010000, bucket=2, bytes=0, packets=0, actions=[GROUP:0x1001e]
-```
+3. To check the fabric data path, start by connecting to the ONOS FABRIC
+ instance. This time you will need to connect to the CLI (port 8101). First
+ check if the VLAN cross connect is properly installed, by checking the
+ output of the `netcfg` command. Search for the *xconnect* configuration for
+ *org.onosproject.segmentrouting*, then verify (1) the given vlan corresponds
+ to the s-tag, and (2) the given ports connect the fabric to the Ethernet
+ edge and to the transport/next CO. Afterwards, check the output of the
+ `flows` command, where you can see how the VLAN cross connect gets
+ instantiated in the switch's tables. Again, check the input/output ports and
+ the VLAN ID. You can also relate this to the output of the `groups` command.
+ An example output is given below.
+
+ ```shell
+ onos> flows
+ deviceId=of:0000cc37ab7cc2fa, flowRuleCount=7
+ id=7300003f50706b, state=ADDED, bytes=0, packets=0, duration=14, liveType=UNKNOWN, priority=32768, tableId=10, appId=org.onosproject.segmentrouting, payLoad=null, selector=[IN_PORT:37, VLAN_VID:1], treatment=DefaultTrafficTreatment{immediate=[], deferred=[], transition=TABLE:20, meter=None, cleared=false, metadata=null}
+ id=7300004524fea3, state=ADDED, bytes=0, packets=0, duration=14, liveType=UNKNOWN, priority=32768, tableId=10, appId=org.onosproject.segmentrouting, payLoad=null, selector=[IN_PORT:30, VLAN_VID:1], treatment=DefaultTrafficTreatment{immediate=[], deferred=[], transition=TABLE:20, meter=None, cleared=false, metadata=null}
+ id=730000009feee7, state=ADDED, bytes=0, packets=0, duration=13, liveType=UNKNOWN, priority=1000, tableId=50, appId=org.onosproject.segmentrouting, payLoad=null, selector=[VLAN_VID:1], treatment=DefaultTrafficTreatment{immediate=[], deferred=[GROUP:0x40010000], transition=TABLE:60, meter=None, cleared=false, metadata=null}
+ id=1000082927ca9, state=ADDED, bytes=283894, packets=3336, duration=4911, liveType=UNKNOWN, priority=40000, tableId=60, appId=org.onosproject.core, payLoad=null, selector=[ETH_TYPE:lldp], treatment=DefaultTrafficTreatment{immediate=[OUTPUT:CONTROLLER], deferred=[], transition=None, meter=None, cleared=true, metadata=null}
+ id=10000a168723c, state=ADDED, bytes=269365, packets=3169, duration=4911, liveType=UNKNOWN, priority=40000, tableId=60, appId=org.onosproject.core, payLoad=null, selector=[ETH_TYPE:bddp], treatment=DefaultTrafficTreatment{immediate=[OUTPUT:CONTROLLER], deferred=[], transition=None, meter=None, cleared=true, metadata=null}
+ id=73000030665163, state=ADDED, bytes=0, packets=0, duration=4911, liveType=UNKNOWN, priority=40000, tableId=60, appId=org.onosproject.segmentrouting, payLoad=null, selector=[ETH_TYPE:ipv6, IP_PROTO:58], treatment=DefaultTrafficTreatment{immediate=[OUTPUT:CONTROLLER], deferred=[], transition=None, meter=None, cleared=false, metadata=null}
+ id=73000030db30ed, state=ADDED, bytes=0, packets=0, duration=4911, liveType=UNKNOWN, priority=40000, tableId=60, appId=org.onosproject.segmentrouting, payLoad=null, selector=[ETH_TYPE:arp], treatment=DefaultTrafficTreatment{immediate=[OUTPUT:CONTROLLER], deferred=[], transition=None, meter=None, cleared=false, metadata=null}
+ onos> groups
+ deviceId=of:0000cc37ab7cc2fa, groupCount=3
+ id=0x1001e, state=ADDED, type=INDIRECT, bytes=0, packets=0, appId=org.onosproject.segmentrouting
+ id=0x1001e, bucket=1, bytes=0, packets=0, actions=[OUTPUT:30]
+ id=0x10025, state=ADDED, type=INDIRECT, bytes=0, packets=0, appId=org.onosproject.segmentrouting
+ id=0x10025, bucket=1, bytes=0, packets=0, actions=[OUTPUT:37]
+ id=0x40010000, state=ADDED, type=ALL, bytes=0, packets=0, appId=org.onosproject.segmentrouting
+ id=0x40010000, bucket=1, bytes=0, packets=0, actions=[GROUP:0x10025]
+ id=0x40010000, bucket=2, bytes=0, packets=0, actions=[GROUP:0x1001e]
+ ```
+