Merge "fixed typo"
diff --git a/SUMMARY.md b/SUMMARY.md
index 6c31ff3..99f6b55 100644
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -110,7 +110,6 @@
* [Base OpenStack](charts/base-openstack.md)
* [OpenStack](prereqs/openstack-helm.md)
* [VTN Setup](prereqs/vtn-setup.md)
- * [R-CORD](charts/rcord.md)
* [M-CORD](charts/mcord.md)
* [XOSSH](charts/xossh.md)
* [Logging and Monitoring](charts/logging-monitoring.md)
@@ -119,4 +118,3 @@
* [PONNET](charts/ponnet.md)
* [PONSIM v2](charts/ponsimv2.md)
* [PONSIM Pod](charts/ponsim-pod.md)
-
diff --git a/charts/base-kubernetes.md b/charts/base-kubernetes.md
index efe12f9..b1baf59 100644
--- a/charts/base-kubernetes.md
+++ b/charts/base-kubernetes.md
@@ -2,9 +2,10 @@
This chart contains all the XOS services that interacts with Kubernetes.
-You can install it using:
+{% include "../partials/helm/add-cord-repo.md" %}
-```bash
-helm dep update xos-profiles/base-kubernetes
-helm install -n base-kubernetes xos-profiles/base-kubernetes/
-```
\ No newline at end of file
+You can then install it using:
+
+```shell
+helm install -n base-kubernetes cord/base-kubernetes
+```
diff --git a/charts/base-openstack.md b/charts/base-openstack.md
index b48eb96..b8e4d27 100644
--- a/charts/base-openstack.md
+++ b/charts/base-openstack.md
@@ -14,13 +14,12 @@
## Single-Node Configuration
-Here is an example of deploying the `xos-profiles/base-openstack` chart
-on a single-node OpenStack server set up by the
-`automation-tools/openstack-helm/openstack-helm-dev-setup.sh` script:
+Here is an example of deploying the *base-openstack* chart on a single-node OpenStack server set up by the *automation-tools/openstack-helm/openstack-helm-dev-setup.sh* script:
-```bash
-helm dep update xos-profiles/base-openstack
-helm install -n base-openstack xos-profiles/base-openstack \
+{% include "../partials/helm/add-cord-repo.md" %}
+
+```shell
+helm install -n base-openstack cord/base-openstack \
--set computeNodes.master.name=`hostname` \
--set vtn-service.sshUser=`whoami`
```
diff --git a/charts/bbsim.md b/charts/bbsim.md
index 74b75fa..07c6c69 100644
--- a/charts/bbsim.md
+++ b/charts/bbsim.md
@@ -1,10 +1,13 @@
# BBSim Helm Chart
This chart let you install the broadband simulator.
-Note that this chart depends on [kafka](kafka.md)
+
+>**Note:** this chart depends on [kafka](kafka.md).
+
+{% include "../partials/helm/add-cord-repo.md" %}
```shell
-helm install -n bbsim bbsim
+helm install -n bbsim cord/bbsim
```
## Set a different number of ONUs
@@ -12,7 +15,7 @@
You can configure the number of ONUs through a parameter in the installation:
```shell
-helm install -n bbsim bbsim --set onus_per_pon_port={number_of_onus}
+helm install -n bbsim cord/bbsim --set onus_per_pon_port={number_of_onus}
```
## Set a different mode
@@ -23,14 +26,14 @@
You can change the behaviour via:
```shell
-helm install -n bbsim bbsim --set emulation_mode="{both|aaa|default}"
+helm install -n bbsim cord/bbsim --set emulation_mode="{both|aaa|default}"
```
Where:
-- `both` stands for authentication and DHCP
-- `aaa` stands for authentication only
-- `default` will just activate the devices
+- *both* stands for authentication and DHCP
+- *aaa* stands for authentication only
+- *default* will just activate the devices
## Start BBSim without Kafka
@@ -41,7 +44,7 @@
with:
```shell
-helm install -n bbsim bbsim --set kafka_broker=""
+helm install -n bbsim cord/bbsim --set kafka_broker=""
```
## Provision the BBSim OLT in NEM
diff --git a/charts/kafka.md b/charts/kafka.md
index 26d4645..30d43ea 100644
--- a/charts/kafka.md
+++ b/charts/kafka.md
@@ -1,14 +1,14 @@
# Kafka Helm chart
-The `kafka` helm chart is not maintained by CORD,
-but it is available online at: <https://github.com/kubernetes/charts/tree/master/incubator/kafka>
+The *kafka* helm chart is not maintained by CORD, but it is available online at: <https://github.com/kubernetes/charts/tree/master/incubator/kafka>
-To install kafka using the `cord-kafka` name, run the following commands:
+To install kafka using the *cord-kafka* name, run the following commands:
```shell
helm repo add incubator http://storage.googleapis.com/kubernetes-charts-incubator
helm install -f examples/kafka-single.yaml --version 0.8.8 -n cord-kafka incubator/kafka
```
+
> NOTE: Historically there were two kafka busses deployed (another one named
> `voltha-kafka`) but these have been consolidated.
@@ -35,22 +35,24 @@
A few examples:
- List available topics:
- ```shell
- kafkacat -b cord-kafka -L
- ```
+
+```shell
+kafkacat -b cord-kafka -L
+```
- Listen for events on a particular topic:
- ```shell
- kafkacat -b cord-kafka -C -t <kafka-topic>
- ```
+
+```shell
+kafkacat -b cord-kafka -C -t <kafka-topic>
+```
- Some example topics to listen on:
- ```shell
- kafkacat -b cord-kafka -C -t xos.log.core
- kafkacat -b cord-kafka -C -t xos.gui_events
- kafkacat -b cord-kafka -C -t voltha.events
- kafkacat -b cord-kafka -C -t onu.events
- kafkacat -b cord-kafka -C -t authentication.events
- kafkacat -b cord-kafka -C -t dhcp.events
- ```
+```shell
+kafkacat -b cord-kafka -C -t xos.log.core
+kafkacat -b cord-kafka -C -t xos.gui_events
+kafkacat -b cord-kafka -C -t voltha.events
+kafkacat -b cord-kafka -C -t onu.events
+kafkacat -b cord-kafka -C -t authentication.events
+kafkacat -b cord-kafka -C -t dhcp.events
+```
diff --git a/charts/logging-monitoring.md b/charts/logging-monitoring.md
index 01dcfcb..a051500 100644
--- a/charts/logging-monitoring.md
+++ b/charts/logging-monitoring.md
@@ -7,12 +7,14 @@
functionality, `nem-monitoring` and `logging`. Both of these charts depend on
having [kafka](kafka.md) instances running in order to pass messages.
+## Add the cord repository
-## `nem-monitoring` charts
+{% include "../partials/helm/add-cord-repo.md" %}
+
+## nem-monitoring charts
```shell
-helm dep update nem-monitoring
-helm install -n nem-monitoring nem-monitoring
+helm install -n nem-monitoring cord/nem-monitoring
```
> NOTE: In order to display `voltha` kpis you need to have `voltha`
@@ -22,18 +24,17 @@
This chart exposes two dashboards:
-- [Grafana](http://docs.grafana.org/) on port `31300`
-- [Prometheus](https://prometheus.io/docs/) on port `31301`
+- [Grafana](http://docs.grafana.org/) on port *31300*
+- [Prometheus](https://prometheus.io/docs/) on port *31301*
-## `logging` charts
+## logging charts
```shell
-helm dep up logging
-helm install -n logging logging
+helm install -n logging cord/logging
```
For smaller developer/test environments without persistent storage, please use
-the `examples/logging-single.yaml` file to run the logging chart, which doesn't
+the *examples/logging-single.yaml* file to run the logging chart, which doesn't
create PVC's.
### Logging Dashboard
diff --git a/charts/mcord.md b/charts/mcord.md
index b7e6730..cec9fa6 100644
--- a/charts/mcord.md
+++ b/charts/mcord.md
@@ -1,12 +1,12 @@
# Deploy M-CORD Profile
-To deploy the M-CORD profile, run the following:
+{% include "../partials/helm/add-cord-repo.md" %}
+
+Then, to deploy the M-CORD profile, run the following:
```shell
-helm dep update xos-profiles/mcord
-helm install -n mcord xos-profiles/mcord --set proxySshUser=ubuntu
+helm install -n mcord cord/mcord --set proxySshUser=ubuntu
```
-The value of `proxySshUser` should be set to the user account corresponding
-to the public key added to the node when
-[prepping the nodes for VTN](../prereqs/vtn-setup.md).
+The value of *proxySshUser* should be set to the user account corresponding
+to the public key added to the node when [prepping the nodes for VTN](../prereqs/vtn-setup.md).
diff --git a/charts/onos.md b/charts/onos.md
index a398039..7d7c27c 100644
--- a/charts/onos.md
+++ b/charts/onos.md
@@ -1,9 +1,11 @@
-# Deploy ONOS
+# ONOS
-To install ONOS run:
+{% include "../partials/helm/add-cord-repo.md" %}
+
+Then, to install ONOS run:
```shell
-helm install -n onos
+helm install -n cord/onos
```
**Nodeports exposed**
@@ -26,7 +28,7 @@
## ONOS logging
-### `onos-log-agent` Sidecar container
+### onos-log-agent sidecar container
By default, the onos helm chart will run a sidecar container to ship logs using
[Filebeat](https://www.elastic.co/guide/en/beats/filebeat/current/index.html)
@@ -38,11 +40,15 @@
specify which container you want to interact with. For example, to view the
ONOS logs via kubectl, you would use:
- kubectl logs onos-7bbc9555bf-2754p -c onos
+```shell
+kubectl logs onos-7bbc9555bf-2754p -c onos
+```
and to view the filebeat logs:
- kubectl logs onos-7bbc9555bf-2754p -c onos-log-agent
+```shell
+kubectl logs onos-7bbc9555bf-2754p -c onos-log-agent
+```
If this the sidecar isn't required, it can be disabled when installing the
chart by passing `--set log_agent.enabled=false` or by using a values file.
@@ -63,4 +69,4 @@
```shell
helm install -n onos -f configs/onos-debug.yaml onos
-```
\ No newline at end of file
+```
diff --git a/charts/ponnet.md b/charts/ponnet.md
index 1c2831e..b40f402 100644
--- a/charts/ponnet.md
+++ b/charts/ponnet.md
@@ -6,13 +6,12 @@
RG and components upstream of the PONSIM OLT. Note that the bridges
are not actually created until [PONSIM](ponsimv2.md) is installed.
-You can install the chart using:
+{% include "../partials/helm/add-cord-repo.md" %}
+
+You can then install the chart using:
```bash
-helm install -n ponnet ponnet
+helm install -n ponnet cord/ponnet
```
-The chart modifies the underlying Kubernetes setup by installing the `bridge`
-CNI and adding configuration files to create the two bridges. Kubernetes must
-be configured with CNI enabled. Note that this chart does not seem to work
-on `minikube`.
+The chart modifies the underlying Kubernetes setup by installing the *bridge* CNI and adding configuration files to create the two bridges. Kubernetes must be configured with CNI enabled. Note that this chart does not seem to work on *minikube*.
diff --git a/charts/ponsim-pod.md b/charts/ponsim-pod.md
index b84fea3..a8329f8 100644
--- a/charts/ponsim-pod.md
+++ b/charts/ponsim-pod.md
@@ -1,10 +1,11 @@
# PONSIM Pod
-This chart just loads TOSCA for adding a PONSIM OLT and Mininet
-AGG Switch to XOS. It is used by [SiaB](../profiles/seba/siab.md).
+This chart just loads TOSCA for adding a PONSIM OLT and Mininet AGG Switch to XOS. It is used by [SiaB](../profiles/seba/siab.md).
-You can install it using:
+{% include "../partials/helm/add-cord-repo.md" %}
-```bash
-helm install -n ponsim-pod xos-profiles/ponsim-pod/
+You can then install it using:
+
+```shell
+helm install -n ponsim-pod cord/ponsim-pod
```
diff --git a/charts/ponsimv2.md b/charts/ponsimv2.md
index a50c74d..599740e 100644
--- a/charts/ponsimv2.md
+++ b/charts/ponsimv2.md
@@ -1,16 +1,18 @@
# PONSIM v2 Helm Chart
-The `ponsimv2` chart deploys the PON Simulator (PONSIM) containers
-(a virtual OLT, ONU, and RG) in the context of VOLTHA.
+The `ponsimv2` chart deploys the PON Simulator (PONSIM) containers (a virtual OLT, ONU, and RG) in the context of VOLTHA.
This chart is used by [SiaB](../profiles/seba/siab.md).
-More details about PONSIM can be found in
-[its README](https://github.com/opencord/voltha/blob/master/ponsim/v2/README.md).
+More details about PONSIM can be found in [its README](https://github.com/opencord/voltha/blob/master/ponsim/v2/README.md).
You must install the [PONNET](ponnet.md) chart before installing this one.
-At that point you can install PONSIM using:
+At that point you can install PONSIM.
-```bash
-helm install -n ponsimv2 ponsimv2
+{% include "../partials/helm/add-cord-repo.md" %}
+
+Then, install ponsim doing:
+
+```shell
+helm install -n ponsimv2 cord/ponsimv2
```
After a successful install you will see containers like these running in the
diff --git a/charts/rcord.md b/charts/rcord.md
deleted file mode 100644
index 789d8a7..0000000
--- a/charts/rcord.md
+++ /dev/null
@@ -1,2 +0,0 @@
-# R-CORD
-
diff --git a/charts/seba-services.md b/charts/seba-services.md
index 3145bdc..a28dc97 100644
--- a/charts/seba-services.md
+++ b/charts/seba-services.md
@@ -2,9 +2,10 @@
This chart contains all the XOS services needed to install SEBA.
-You can install it using:
+{% include "../partials/helm/add-cord-repo.md" %}
-```bash
-helm dep update xos-profiles/seba-services
-helm install -n seba-service xos-profiles/seba-services/
-```
\ No newline at end of file
+You can then install it using:
+
+```shell
+helm install -n seba-service cord/seba-services
+```
diff --git a/charts/storage.md b/charts/storage.md
index 7f8fb11..cca25fc 100644
--- a/charts/storage.md
+++ b/charts/storage.md
@@ -174,7 +174,6 @@
into the `rook-ceph-system` namespace:
```shell
-cd helm-charts/storage
helm repo add rook-beta https://charts.rook.io/beta
helm dep update rook-operator
helm install --namespace rook-ceph-system -n rook-operator rook-operator
@@ -338,8 +337,10 @@
First, configure your nodes to deploy the [local-directory](#local-directory)
chart, then run:
+{% include "../partials/helm/add-cord-repo.md" %}
+
```shell
-helm install -f examples/xos-db-local-dir.yaml -n xos-core xos-core
+helm install -f examples/xos-db-local-dir.yaml -n xos-core cord/xos-core
```
### Example: XOS Database on a Ceph RBD volume
@@ -352,7 +353,7 @@
then load the XOS core charts with:
```shell
-helm install -f examples/xos-db-ceph-rbd.yaml -n xos-core xos-core
+helm install -f examples/xos-db-ceph-rbd.yaml -n xos-core cord/xos-core
```
### Example: Docker Registry on CephFS shared filesystem
diff --git a/charts/voltha.md b/charts/voltha.md
index 05e748c..2e0cc65 100644
--- a/charts/voltha.md
+++ b/charts/voltha.md
@@ -1,18 +1,8 @@
# Deploy VOLTHA
-VOLTHA depends on having a [kafka message bus](kafka.md) deployed with a name
-of `cord-kafka`, so deploy that with helm before deploying the voltha chart.
-
-
## First Time Installation
-Download the helm charts `incubator` repository:
-
-```shell
-helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/
-```
-
-Install the etcd-operator helm chart. This chart provides a convenient way of creating and managing etcd clusters. When voltha installs it will attempt to use etcd-operator to create its etcd cluster. Once installed etcd-operator can be left running.
+Install the etcd-operator helm chart first. This chart provides a convenient way of creating and managing etcd clusters. When VOLTHA installs it will attempt to use etcd-operator to create its etcd cluster. Once installed etcd-operator can be left running.
```shell
helm install -n etcd-operator stable/etcd-operator --version 0.8.0
@@ -24,21 +14,15 @@
kubectl get crd | grep etcd
```
+{% include "../partials/helm/add-cord-repo.md" %}
-
-Update dependencies within the voltha chart:
+Then, install the VOLTHA helm chart. This will create the VOLTHA pods and will create the etcd-cluster pods.
```shell
-helm dep up voltha
+helm install -n voltha cord/voltha
```
-Install the voltha helm chart. This will create the voltha pods and additionally create the etcd-cluster pods
-
-```shell
-helm install -n voltha voltha
-```
-
-Allow enough time for the 3 etcd-cluster pods to start before using the voltha pods.
+Allow enough time for the 3 etcd-cluster pods to start before using the VOLTHA pods.
## Standard Uninstall
@@ -49,7 +33,7 @@
## Standard Install
```shell
-helm install -n voltha voltha
+helm install -n voltha cord/voltha
```
## Nodeports Exposed
@@ -70,25 +54,23 @@
ssh voltha@<pod-ip> -p 30110
```
-The default VOLTHA password is `admin`.
+The default VOLTHA password is *admin*.
## Building and using development images
-In some cases you want to build custom images to try out development code.
-The suggested way to do that is:
+In some cases you may want to build custom images to try out development code. In order to do that, from the CORD repository, do:
```shell
-cd ~/cord/incubator/voltha
+cd incubator/voltha
REPOSITORY=voltha/ TAG=dev VOLTHA_BUILD=docker make build
cd ~/cord/automation-tools/developer
bash tag_and_push.sh -t dev -r 192.168.99.100:30500
```
-_This set of commands will build the VOLTHA containers and push them to a local
-[docker registry](../partials/push-images-to-registry.md) using a TAG called *dev*.
+This set of commands builds the VOLTHA containers and pushes them to a local
+[docker registry](../partials/push-images-to-registry.md) using a tag called *dev*.
-Once the images are pushed to a docker registry on the POD,
-you can use a values file like the following one:
+Once the images are pushed to a docker registry on the POD, you can create a values file like the following one, to override the default chart values, so use your images:
```yaml
# voltha-values.yaml
@@ -120,8 +102,8 @@
```
-and you can install VOLTHA using:
+Then, install VOLTHA using:
```shell
-helm install -n voltha voltha -f voltha-values.yaml
+helm install -n voltha -f voltha-values.yaml cord/voltha
```
diff --git a/charts/xos-core.md b/charts/xos-core.md
index 3d31434..487b23a 100644
--- a/charts/xos-core.md
+++ b/charts/xos-core.md
@@ -2,9 +2,10 @@
To deploy the XOS core and affiliated containers, run the following:
+{% include "../partials/helm/add-cord-repo.md" %}
+
```shell
-helm dep update xos-core
-helm install -n xos-core xos-core
+helm install -n xos-core cord/xos-core
```
**Nodeports exposed**
@@ -14,11 +15,10 @@
## Customizing security information
-We strongly recommend you to override the default values of `xosAdminUser` and
-`xosAdminPassword` with custom values.
+We strongly recommend you to override the default values of *xosAdminUser* and
+*xosAdminPassword* with custom values.
-You can do it using a [`values.yaml`](https://docs.helm.sh/chart_template_guide/#values-files)
-file like this one:
+You can do it using a [`values.yaml`](https://docs.helm.sh/chart_template_guide/#values-files) file like this one:
```yaml
# custom-security.yaml
@@ -29,14 +29,17 @@
and add it to the install command:
```shell
-helm install -n xos-core xos-core -f custom-security.yaml
+helm install -f custom-security.yaml -n xos-core cord/xos-core
```
or you can override the values from the CLI
```shell
-helm install -n xos-core xos-core --set xosAdminUser=MyUser --set xosAdminPassword=MySuperSecurePassword
+helm install -n xos-core cord/xos-core \
+ --set xosAdminUser=MyUser \
+ --set xosAdminPassword=MySuperSecurePassword
```
+
> **Important!**
> If you override security values in the `xos-core` chart, you'll need to pass
> these values, either via a file or cli arguments, to all the xos related charts
diff --git a/charts/xossh.md b/charts/xossh.md
index 675a23e..65d6b56 100644
--- a/charts/xossh.md
+++ b/charts/xossh.md
@@ -1,7 +1,9 @@
# Deploy XOSSH
-To deploy the XOS-Shell, run the following:
+{% include "../partials/helm/add-cord-repo.md" %}
+
+Then, to deploy the XOS-Shell run the following:
```shell
-helm install xos-tools/xossh -n xossh
+helm install -n xossh cord/xossh
```
diff --git a/partials/helm/add-cord-repo.md b/partials/helm/add-cord-repo.md
new file mode 100644
index 0000000..386498f
--- /dev/null
+++ b/partials/helm/add-cord-repo.md
@@ -0,0 +1,6 @@
+If you haven't done it yet, add the CORD repository to the list of your local repositories and update the repo index:
+
+```shell
+helm repo add cord https://gerrit.opencord.org
+helm repo update
+```
diff --git a/profiles/seba/troubleshoot/no-dhcp.md b/profiles/seba/troubleshoot/no-dhcp.md
index e2b9eea..9d4248c 100644
--- a/profiles/seba/troubleshoot/no-dhcp.md
+++ b/profiles/seba/troubleshoot/no-dhcp.md
@@ -12,12 +12,13 @@
Next it is important to understand that there are two ways the ONOS DHCP L2 Relay app
can operate. DHCP packets received from the RG can be relayed to the server using
-either the OLT's uplink port (that connects to the AGG switch), or they can be
-relayed directly to the AGG switch's uplink port (that connects to the BNG/DHCP-server).
-By default, a SEBA pod uses the latter mechanism.
+the OLT's uplink port (that connects to the AGG switch), as shown below.
+Or they can be relayed directly to the AGG switch's uplink port (that connects
+to the BNG/DHCP-server). By default, a SEBA pod uses the latter mechanism.
+
The configuration for the DHCP relay app can be seen in the XOS GUI
diff --git a/profiles/seba/troubleshoot/no-ping.md b/profiles/seba/troubleshoot/no-ping.md
index 152bd5d..e04a017 100644
--- a/profiles/seba/troubleshoot/no-ping.md
+++ b/profiles/seba/troubleshoot/no-ping.md
@@ -1 +1,197 @@
# I can't ping
+
+A successful ping is all about the flows in the hardware. In a SEBA pod, dataplane
+traffic does not leave the hardware. But in order to get to this point, the RG
+should have successfully authenticated, and it should have received an IP address
+from the DHCP server.
+
+In the future, we will add troubleshooting probes to understand where the datapath
+may be broken. For now, it is instructive to understand the flows in the dataplane
+and what they represent.
+
+## Flows in the PON
+
+Lets look at what the flows look like in ONOS for the PON.
+
+### ONOS flows
+
+Connect to the [ONOS CLI](../../../charts/onos.md#accessing-the-onos-cli)
+and check the flows on the device that represents the PON.
+
+```shell
+onos> flows -s any of:000000000a5a007a
+deviceId=of:000000000a5a007a, flowRuleCount=11
+-snip-
+ ADDED, bytes=0, packets=0, table=0, priority=1000, selector=[IN_PORT:65536, METADATA:de00007810, VLAN_VID:222], treatment=[immediate=[VLAN_POP], transition=TABLE:1]
+ ADDED, bytes=0, packets=0, table=1, priority=1000, selector=[IN_PORT:65536, VLAN_VID:222], treatment=[immediate=[VLAN_POP, OUTPUT:30736]]
+ ADDED, bytes=0, packets=0, table=0, priority=1000, selector=[IN_PORT:30736, VLAN_VID:0], treatment=[immediate=[VLAN_ID:222], transition=TABLE:1]
+ ADDED, bytes=0, packets=0, table=1, priority=1000, selector=[IN_PORT:30736, VLAN_VID:222], treatment=[immediate=[VLAN_PUSH:vlan, VLAN_ID:222, OUTPUT:65536]]
+```
+
+The first two flows above represent the downstream traffic from `IN_PORT` 65536 (the NNI port)
+for S-VLAN tag 222, which gets popped and transitioned to table 1, where the inner VLAN (also
+222 in this example) is popped and sent to UNI port 30736.
+
+The last two flows represent the upstream traffic, where the reverse happens. In table 0,
+untagged traffic input from UNI port 30736, has C-VLAN 222 pushed on and transitioned
+to table 2 where the outer S-VLAN tag is pushed on and then sent out of NNI port 65536.
+
+### VOLTHA flows
+
+Now lets see what those flows look like in the logical device representing the PON in VOLTHA.
+Connect to the [VOLTHA CLI](../../../charts/voltha.md#accessing-the-voltha-cli)
+
+```shell
+(voltha) logical_device 000100000a5a007a
+(logical device 000100000a5a007a) flows
+Logical Device 000100000a5a007a (type: n/a)
+Flows (12):
++----------+----------+-----------+---------+----------+----------+----------+---------+---------+--------------+--------------+----------+-----------+------------+------------+
+| table_id | priority | cookie | in_port | vlan_vid | eth_type | ip_proto | udp_src | udp_dst | metadata | set_vlan_vid | pop_vlan | push_vlan | output | goto-table |
++----------+----------+-----------+---------+----------+----------+----------+---------+---------+--------------+--------------+----------+-----------+------------+------------+
+-snip-
+| 0 | 1000 | ~6a971a41 | 30736 | 0 | | | | | | 222 | | | | 1 |
+| 1 | 1000 | ~fd1c22e3 | 30736 | 222 | | | | | | 222 | | 8100 | 65536 | |
++----------+----------+-----------+---------+----------+----------+----------+---------+---------+--------------+--------------+----------+-----------+------------+------------+
+| 0 | 1000 | ~569b8514 | 65536 | 222 | | | | | 953482770448 | | Yes | | | 1 |
+| 1 | 1000 | ~c587bdac | 65536 | 222 | | | | | | | Yes | | 30736 | |
++----------+----------+-----------+---------+----------+----------+----------+---------+---------+--------------+--------------+----------+-----------+------------+------------+
+```
+
+We see the same patterns are repeated in the logical device, where the first two
+flows above are for upstream traffic, and the bottom two are for downstream traffic.
+
+These flows from the logical device get decomposed into flows that are meant for
+the OLT as well as for the ONU.
+
+Now if we look at the device object representing the OLT below, we see there is
+one flow each for downstream and upstream in the OLT device object.
+
+```shell
+(voltha) device 0001a82d21249c28
+(device 0001a82d21249c28) flows
+Device 0001a82d21249c28 (type: openolt)
+Flows (16):
++----------+----------+-----------+------------+----------+----------+----------+---------+---------+--------------+--------------+----------+-----------+------------+------------+
+| table_id | priority | cookie | in_port | vlan_vid | eth_type | ip_proto | udp_src | udp_dst | metadata | set_vlan_vid | pop_vlan | push_vlan | output | goto-table |
++----------+----------+-----------+------------+----------+----------+----------+---------+---------+--------------+--------------+----------+-----------+------------+------------+
+-snip-
+| 1 | 1000 | ~829ee130 | 30736 | 222 | | | | | | 222 | | 8100 | 65536 | |
+| 0 | 1000 | ~c4babfb5 | 65536 | 222 | | | | | 953482770448 | | Yes | | | 1 |
++----------+----------+-----------+------------+----------+----------+----------+---------+---------+--------------+--------------+----------+-----------+------------+------------+
+```
+
+The first flow above represents upstream traffic, and the second one represents
+downstream traffic.
+The upstream flow appears to come from a UNI port `30736`, which is not a port
+on the OLT device (it's a port on the ONU). But this information is necessary
+to figure out the PON port on the OLT, from which the traffic ingresses the OLT.
+
+The downstream flow appears to not have an output port but actually
+the output is encoded in the metadata (which also includes the C-VLAN id).
+
+Ignore the `table_id` and `goto-table` fields in this table - they are meaningless.
+
+If these flows look good, lets check the flows in the device object representing the ONU:
+
+```shell
+(voltha) device 000175a511654437
+(device 000175a511654437) flows
+Device 000175a511654437 (type: brcm_openomci_onu)
+Flows (5):
++----------+----------+-----------+---------+----------+--------------+----------+-----------+--------+
+| table_id | priority | cookie | in_port | vlan_vid | set_vlan_vid | pop_vlan | push_vlan | output |
++----------+----------+-----------+---------+----------+--------------+----------+-----------+--------+
+-snip-
+| 0 | 1000 | ~c587bdac | 100 | 222 | | Yes | | 30736 |
+| 0 | 1000 | ~6a971a41 | 30736 | 0 | 222 | | | 100 |
++----------+----------+-----------+---------+----------+--------------+----------+-----------+--------+
+```
+
+Again, there is only 1 upstream flow and 1 downstream flow for this subscriber. The
+first flow shown above represents the downstream direction from the ANI port on the
+ONU (designated as port number 100) that matches on the VLAN tag 222, and pops it off
+before sending the packet out of the UNI port 30736.
+
+The 2nd flow represents the upstream direction, receiving untagged packets from the
+UNI port 30736, and pushing on the C-VLAN tag 222, before sending the packet out
+of the ANI port 100 towards the OLT.
+
+## Flows in the AGG switch
+
+If all the flows in the PON appear to be correct, then the problem may lie in the
+AGG switch.
+
+From the ONOS CLI
+
+```shell
+onos> flows -s any of:0000000000000002
+deviceId=of:0000000000000002, flowRuleCount=33
+-snip-
+ ADDED, bytes=0, packets=0, table=10, priority=32768, selector=[IN_PORT:1, VLAN_VID:222], treatment=[transition=TABLE:20]
+ ADDED, bytes=0, packets=0, table=10, priority=32768, selector=[IN_PORT:32, VLAN_VID:222], treatment=[transition=TABLE:20]
+-snip-
+ ADDED, bytes=0, packets=0, table=50, priority=1000, selector=[VLAN_VID:222], treatment=[deferred=[GROUP:0x40de0000], transition=TABLE:60]
+-snip-
+ ADDED, bytes=1948, packets=22, table=60, priority=60000, selector=[VLAN_VID:222], treatment=[immediate=[NOACTION]]
+-snip-
+```
+
+There are a number of default flows in the AGG switch for features that are not
+currently used in SEBA. We have highlighted only the meaningful flows above. In SEBA,
+for the AT&T workflow, packets are forwarded only on the basis of the S-tag.
+
+In `table=10`, packets with S-VLAN tag 222 are allowed into the the switch from
+`IN_PORT:1` (connected to the OLT) and `IN_PORT:32` (connected to the BNG).
+In `table=50` packets in the S-VLAN 222 are bridged together in the `GROUP:0x40de0000`
+In `table=60` we add an ACL flow for S-VLAN 222 to ensure that none of the other
+ACL flows (not shown above) get triggered for packets on this VLAN.
+
+Below we show details of the flooding group `GROUP:0x40de0000` which points to
+two other groups which in turn represent the two ports 1 and 32, which have been
+cross-connected together on this vlan (222).
+
+```shell
+onos> groups
+deviceId=of:0000000000000002, groupCount=3
+ id=0xde0001, state=ADDED, type=INDIRECT, bytes=0, packets=0, appId=org.onosproject.xconnect, referenceCount=1
+ id=0xde0001, bucket=1, bytes=0, packets=0, actions=[OUTPUT:1]
+ id=0xde0020, state=ADDED, type=INDIRECT, bytes=0, packets=0, appId=org.onosproject.xconnect, referenceCount=1
+ id=0xde0020, bucket=1, bytes=0, packets=0, actions=[OUTPUT:32]
+ id=0x40de0000, state=ADDED, type=ALL, bytes=0, packets=0, appId=org.onosproject.xconnect, referenceCount=1
+ id=0x40de0000, bucket=1, bytes=0, packets=0, actions=[GROUP:0xde0020]
+ id=0x40de0000, bucket=2, bytes=0, packets=0, actions=[GROUP:0xde0001]
+```
+
+You should also verify the output of the command below which should show the cross-connected ports on the VLAN.
+
+```shell
+onos> sr-xconnect
+XconnectDesc{key=XconnectKey{deviceId=of:0000000000000002, vlanId=222}, ports=[32, 1]}
+```
+
+## Using Port Statistics
+
+You can check the port stats on the AGG switch to see if the port counters
+on the switch are increasing or not. For example, with a live ping in progress, try
+
+```shell
+onos> watch portstats -nz -d of:0000000000000002
+deviceId=of:0000000000000002
+ port=1, pktRx=36, pktTx=36, bytesRx=3866, bytesTx=3842, rateRx=Infinity, rateTx=Infinity, pktRxDrp=4, pktTxDrp=0, interval=0.000
+ port=32, pktRx=31, pktTx=35, bytesRx=3364, bytesTx=3744, rateRx=Infinity, rateTx=Infinity, pktRxDrp=0, pktTxDrp=0, interval=0.000
+```
+
+Note that the port counters are increasing on both ports 1 and 32 for both
+transmitted (`pktTx`) and received packets (`pktRx`).
+
+We recommend a fast ping (with option -i 0.2) to increase the number of ping packets
+sent out per second. This will cause a significant change in the port counters.
+
+The -nz option in the command above displays only ports that have non-zero port counters.
+The -d option automatically displays the delta of the port counters from the previous collection
+point. Stats collection intervals are 5 secs by default.
+
+These stats are not currently exported to the CORD monitoring stack by ONOS. However portstats
+from the OLT are exported to Kafka by VOLTHA, and can be displayed in Grafana. Portstats
+from the ONU can similarly be exported, but is currently work-in-progress.