Merge "fix Edgecore vOLT model name in gitbook documents"
diff --git a/installation/platform.md b/installation/platform.md
index d8666fc..67deb21 100644
--- a/installation/platform.md
+++ b/installation/platform.md
@@ -10,7 +10,7 @@
Then, to install the CORD Platform you can use the corresponding chart:
```shell
-helm install -n cord-platform cord/cord-platform --version=6.1.0
+helm install -n cord-platform cord/cord-platform --version=7.0.0
```
### Disabling monitoring and logging
@@ -28,7 +28,7 @@
To disable both of them you can use:
```shell
-helm install -n cord-platform cord/cord-platform --version=6.1.0 --set logging.enabled=false --set nem-monitoring.enabled=false
+helm install -n cord-platform cord/cord-platform --version=7.0.0 --set logging.enabled=false --set nem-monitoring.enabled=false
```
## Alternatively, install the CORD Platform as set of Separate Components
diff --git a/profiles/seba/install.md b/profiles/seba/install.md
index 8b18206..c9761dc 100644
--- a/profiles/seba/install.md
+++ b/profiles/seba/install.md
@@ -24,7 +24,7 @@
Then, proceed with the SEBA chart installation:
```shell
-helm install -n seba cord/seba --version=1.0.0
+helm install -n seba cord/seba --version=2.0.0-alpha1
```
### Alternatively, install SEBA as separate components
diff --git a/profiles/seba/known-issues.md b/profiles/seba/known-issues.md
index f9fb8f8..78fbfad 100644
--- a/profiles/seba/known-issues.md
+++ b/profiles/seba/known-issues.md
@@ -1,35 +1,20 @@
# Known Issues
-## SEBA 1.0 Release
+## SEBA 2.0-alpha Release
-There are known major issues having to do with rebooting of the physical hardware, both
-the OLT and the AGG switch, as well as continuously deleting/re-creating of an OLT Device via NEM. These issues are described in more detail in below:
+This release of SEBA is qualified as 'alpha' due to known major issues related to the use of OLT software from Broadcom referred to as BAL - Broadband Adaptation Layer. The SEBA 2.0-alpha release uses [BAL 2.6](https://github.com/balapi/bal-api-2.6), which is no longer supported by Broadcom.
-* [SEBA-388](https://jira.opencord.org/browse/SEBA-388)
- With this issue, DHCP may not work after AGG switch reboot. A possible workaround is to use a different config for the DHCPl2Relay app that uses the OLT's uplink to reach the DHCP Server, instead of the Switch's uplink. More details are described [here](troubleshoot/no-dhcp.md)
-* [SEBA-385](https://jira.opencord.org/browse/SEBA-385)
- With this issue, the OLT may not pass traffic anymore after reboot. Currently, the only workaround is to, enter the ONOS CLI and force a 'device-remove <<device-id>' for the device from VOLTHA (in other words, force VOLTHA to reconnect to ONOS), and then perform the authentication/dhcp steps again for the subscribers
-* [SEBA-393](https://jira.opencord.org/browse/SEBA-393)
- With this issue, if an OLT device gets deleted and re-created many times within a short period of time (10+ times within an hour or so), VOLTHA may run into an issue where it's unable to save any information pertaining the OLT device such as its ports or any ONU devices connected to those ports. The workaround for this issue is to re-install VOLTHA and re-create the OLT device through NEM.
+These issues are described in more detail in below:
-Fixes to these issues will be addressed soon after the release.
+* [SEBA-670](https://jira.opencord.org/browse/SEBA-670)
+ This issue can be triggered by disable and subsequent re-enable of the ONU via NEM (or VOLTHA). In the SEBA pod, using the AT&T workflow, these actions are accompanied by the removal of subscriber flows upon disable of the ONU, and the reprogramming of eapol flows upon re-enable of the ONU. An irrecoverable error is seen in BAL (specifically bal_core_dist) which does not allow flows to be added to the OLT. As a result authentication of RG's fail.
+* [SEBA-775](https://jira.opencord.org/browse/SEBA-775)
+ This issue is closely related to SEBA-670. The fundamental issue is the removal of flows in the OLT which possibly leaves behind state in BAL 2.6 that does not allow the subsequent reprogramming of flows. It can be triggered by the disable/re-enable of ONUs (as in SEBA-670) or by the remove-subscriber followed by the add-subscriber calls (without change of ONU state). It can be triggered in systems with a single-ONU, as well as in multi-ONU cases. Empirically the issue is more easily reproduced in multi-ONU scenarios. It is observed with single gem ports as well as when multiple gem ports are used for a subscriber in the technology profile.
+* [SEBA-777](https://jira.opencord.org/browse/SEBA-777)
+ Due to the issues mentioned above, subscriber speed profiles cannot be updated reliably, as the update requires the removal of subscriber flows that point to a bandwidth meter, and the reprogramming of flows that point to a new meter.
+* [SEBA-776](https://jira.opencord.org/browse/SEBA-776)
+ This issue is seen sometimes with the use of multiple gem ports in a technology profile. Packet duplication appears to mirror the number of gem ports - using 4 gem ports results in 4 packets for every packet transmitted.
-Another minor issue that does not affect functionality is related to the state of an ONU on the VOLTHA CLI, after disable/re-enable of the ONU.
+Fixes to these issues will be addressed in a future release as we upgrade the OLT software to BAL 3.0.
-```shell
-(voltha) devices
-Devices:
-+------------------+-------------------+------+------------------+------------------+-------------+-------------+----------------+----------------+------------------+------------------------+-------------------------+--------------------------+----------------------+------------------------------+
-| id | type | root | parent_id | serial_number | admin_state | oper_status | connect_status | parent_port_no | host_and_port | reason | proxy_address.device_id | proxy_address.channel_id | proxy_address.onu_id | proxy_address.onu_session_id |
-+------------------+-------------------+------+------------------+------------------+-------------+-------------+----------------+----------------+------------------+------------------------+-------------------------+--------------------------+----------------------+------------------------------+
-| 0001a82d21249c28 | openolt | True | 000100000a5a007a | 10.90.0.122:9191 | ENABLED | ACTIVE | REACHABLE | | 10.90.0.122:9191 | | | | | |
-| 00014f81e9f21dbb | brcm_openomci_onu | True | 0001a82d21249c28 | ALPHe3d1cf9d | ENABLED | ACTIVE | REACHABLE | 536870912 | | initial-mib-downloaded | 0001a82d21249c28 | | 1 | 1 |
-| 0001666321e17127 | brcm_openomci_onu | True | 0001a82d21249c28 | ALPHe3d1ced5 | ENABLED | ACTIVE | REACHABLE | 536870912 | | initial-mib-downloaded | 0001a82d21249c28 | | 2 | 2 |
-| 000175a511654437 | brcm_openomci_onu | True | 0001a82d21249c28 | ISKT71e80080 | ENABLED | ACTIVE | REACHABLE | 536870927 | | omci-flows-pushed | 0001a82d21249c28 | 15 | 1 | 1 |
-| 0001cb66a703449d | brcm_openomci_onu | True | 0001a82d21249c28 | ALPHe3d1cfe3 | ENABLED | ACTIVE | REACHABLE | 536870912 | | initial-mib-downloaded | 0001a82d21249c28 | | 3 | 3 |
-| 0001246c72a99ddd | brcm_openomci_onu | True | 0001a82d21249c28 | ALPHe3d1cf8e | ENABLED | ACTIVE | REACHABLE | 536870912 | | initial-mib-downloaded | 0001a82d21249c28 | | 4 | 4 |
-| 000192f54601ecb4 | brcm_openomci_onu | True | 0001a82d21249c28 | ALPHe3d1cf70 | ENABLED | ACTIVE | REACHABLE | 536870912 | | initial-mib-downloaded | 0001a82d21249c28 | | 5 | 5 |
-+------------------+-------------------+------+------------------+------------------+-------------+-------------+----------------+----------------+------------------+------------------------+-------------------------+--------------------------+----------------------+------------------------------+
-```
-
-In the `reason` column of the devices table, the state of the ONU devices are displayed. Normally after an ONU is disabled, and then re-enabled, it should display the `initial-mib-downloaded` state, indicating that the RG behind the ONU should be ready to re-authenticate (as per the AT&T workflow). However, in this release, the state is incorrectly displayed as `omci-flows-pushed`. This does not affect authentication, dhcp or the subscribers.
+In addition, OLT-reboot [SEBA-385](https://jira.opencord.org/browse/SEBA-385) can result in some ONUs not returning to ACTIVE state in VOLTHA.
diff --git a/profiles/seba/siab.md b/profiles/seba/siab.md
index eed5f44..d81a26c 100644
--- a/profiles/seba/siab.md
+++ b/profiles/seba/siab.md
@@ -31,11 +31,14 @@
To build a SiaB that uses the released service versions specified in the Helm charts:
```bash
-make # or 'make stable'
+make [stable] [NUM_OLTS=n] [NUM_ONUS_PER_OLT=m] # `make` and `make stable` are the same
```
> NOTE that `make` or `make stable` will install SEBA with the container versions that are
-> defined in the helm charts. If you want to install SEBA 1.0 please use: `make siab-1.0`
+> defined in the helm charts. If you want to install SEBA 2.0 please use: `make siab-2.0-alpha1`
+
+You can specify the number of OLTs (up to 4) and number of ONUs per OLT (up to 4) that you want to
+create.
After a successful install, you will see the message:
@@ -57,6 +60,9 @@
make run-tests
```
+Note that the tests currently assume a single OLT/ONU, so some tests will
+likely fail if you have configured multiple OLTs and ONUs.
+
### Quick start: Build SiaB using latest development code
To build a SiaB that uses the latest development code:
@@ -64,69 +70,8 @@
```bash
make latest [NUM_OLTS=n] [NUM_ONUS_PER_OLT=m]
```
-
-With the `latest` target, you can specify the number of OLTs (up to 4) and number of ONUs per OLT that you want to
-create. Each OLT associates with "m" number of ONUs. If you specify more than one OLT you will see several OLT/ONU/RG containers when you run `kubectl -n voltha get pod`:
-
-Naming convention:
-```
-1st OLT - olt0-xxx
-2nd OLT - olt1-xxx
-1st ONU attached to 1st OLT - onu0-0-xx (onu<olt>-<onu>)
-2nd ONU attached to 1st OLT - onu0-1-xx
-1st ONU attached to 2nd OLT - onu1-0-xx
-2nd ONU attached to 2nd OLT - onu1-1-xx
-RG also follows the same naming logic as ONU (rg0-0-xx, rg0-1-xx, rg1-0-xx, rg1-1-xx)
-linux bridges interconnecting ONU and RG also follows the same naming logic as ONU (pon0.0, pon0.1 ..)
-```
-
-```bash
-$ kubectl -n voltha get pod
-NAME READY STATUS RESTARTS AGE
-voltha olt0-774f9cb5f7-9mwwg 1/1 Running 0 33m
-voltha olt1-5f7c44f554-n47mv 1/1 Running 0 33m
-voltha onu0-0-5768c4567c-tc2rt 1/1 Running 0 33m
-voltha onu0-1-859c87ccd9-sr9fq 1/1 Running 0 33m
-voltha onu1-0-6c58d9957f-6bbk4 1/1 Running 0 33m
-voltha onu1-1-8555c74487-6fzwb 1/1 Running 0 33m
-voltha rg0-0-77fcd5d6bc-55cxt 1/1 Running 0 33m
-voltha rg0-1-57cdc6956f-xm2gp 1/1 Running 0 33m
-voltha rg1-0-7d6689bd85-tgjcp 1/1 Running 0 33m
-voltha rg1-1-54994485c5-swnd2 1/1 Running 0 33m
-```
-
-Likewise `brctl show` will output:
-
-```bash
-$ brctl show
-bridge name bridge id STP enabled interfaces
-docker0 8000.02427dd2bfc4 no veth0fbf0dd
-nni0 8000.76030be9e97b no veth3c7ade40
- vethc01838f1
-nni1 8000.ae08243d745e no vethe0df415e
- vetheef40c90
-pon0.0 8000.2aa5060d44b7 no vethaa880e65
- vethae9c7b9d
-pon0.1 8000.3602b50c2521 no veth32a2f3d2
- veth971b571b
-pon1.0 8000.7efc437e91e4 no veth1ea11fe3
- veth51cbc451
-pon1.1 8000.e2423416a798 no veth3323ad21
- veth3718d925
-```
-
-Above there are four separate datapath chains:
-```
-rg0-0 -> pon0.0 -> onu0-0 -> olt0 -> nni0
-rg0-1 -> pon0.1 -> onu0-1 -> olt0 -> nni0
-rg1-0 -> pon1.0 -> onu1-0 -> olt1 -> nni1
-rg1-1 -> pon1.1 -> onu1-1 -> olt1 -> nni1
-```
-All of the `nniX` bridges connect to the agg switch in Mininet on different ports.
-
-A subscriber is created for each RG `rg<olt>-<onu>` with S-tag of `222+<olt>` and C-tag of `111+<onu>`.
-After `rg<olt>-<onu>` is authenticated, it will get an IP address on subnet `172.18+<olt>.<onu>.0/24` and ping
-`172.18+<olt>.<onu>.10` as its BNG.
+You can specify the number of OLTs (up to 4) and number of ONUs per OLT (up to 4) that you want to
+create.
After a successful install, you will see the message:
@@ -142,11 +87,12 @@
make run-tests-latest
```
-Note that the tests currently assume a single OLT, so some tests will likely fail if you have configured multiple OLTs.
+Note that the tests currently assume a single OLT/ONU, so some tests will
+likely fail if you have configured multiple OLTs and ONUs.
## Installation procedure
-The rest of this page describes a manual method for installing SEBA-in-a-Box.
+The rest of this page describes a manual method for installing SEBA-in-a-Box. It also provides an overview of what is installed by each chart.
### Prerequisites
@@ -235,7 +181,7 @@
Install the `cordctl` command line tool:
```bash
-export CORDCTL_VERSION=1.0.0
+export CORDCTL_VERSION=1.1.1
export CORDCTL_PLATFORM=linux-amd64
curl -L -o /tmp/cordctl "https://github.com/opencord/cordctl/releases/download/$CORDCTL_VERSION/cordctl-$CORDCTL_PLATFORM"
sudo mv /tmp/cordctl /usr/local/bin/cordctl
@@ -271,6 +217,16 @@
helm install -n onos onos
```
+You should see the following pods running:
+
+```bash
+$ kubectl get pod
+NAME READY STATUS RESTARTS AGE
+cord-kafka-0 1/1 Running 1 14h
+cord-kafka-zookeeper-0 1/1 Running 0 14h
+onos-558445d9bc-c2cd5 2/2 Running 0 14h
+```
+
## Install VOLTHA charts
Run these commands to install VOLTHA:
@@ -285,57 +241,83 @@
kubectl get crd | grep etcd
# After EtcdCluster CRD is in place
helm dep up voltha
-helm install -n voltha -f configs/seba-ponsim.yaml voltha
+helm install -n voltha voltha --set etcd-cluster.clusterSize=1
```
**Before proceeding**
-Run: `kubectl get pod|grep etcd-cluster`
+Run: `kubectl get pod -l app=etcd`
You should see the etcd-cluster pod up and running.
```bash
-$ kubectl get pod|grep etcd-cluster
-etcd-cluster-q9zhrwvllh 1/1 Running 0 20m
+$ kubectl get pod -l app=etcd
+NAME READY STATUS RESTARTS AGE
+etcd-cluster-jcjk2x97w6 1/1 Running 0 14h
```
+You should see the VOLTHA pods created:
+
+```bash
+$ kubectl get pod -n voltha
+NAME READY STATUS RESTARTS AGE
+default-http-backend-798fb4f44c-fb696 1/1 Running 0 14h
+freeradius-754bc76b5-22lcm 1/1 Running 0 14h
+netconf-66b767bddc-hbsgr 1/1 Running 0 14h
+nginx-ingress-controller-5fc7b87c86-bd55x 1/1 Running 0 14h
+ofagent-556cd6c978-lknd4 1/1 Running 0 14h
+vcli-67c996f87d-vw4pk 1/1 Running 0 14h
+vcore-0 1/1 Running 0 14h
+voltha-6f8d7bf7b-4gkkj 1/1 Running 1 14h
+```
+
+
## Install Ponsim charts
Run these commands to install Ponsim (after installing VOLTHA):
```bash
cd ~/cord/helm-charts
-helm install -n ponnet ponnet
+NUM_OLTS=1 # can be between 1 and 4
+NUM_ONUS_PER_OLT=1 # can be between 1 and 4
+helm install -n ponnet ponnet --set numOlts=$(NUM_OLTS) --set numOnus=$(NUM_ONUS_PER_OLT)
# Wait for CNI changes
~/cord/helm-charts/scripts/wait_for_pods.sh kube-system
-helm install -n ponsimv2 ponsimv2
+helm install -n ponsimv2 ponsimv2 --set numOlts=$(NUM_OLTS) --set numOnus=$(NUM_ONUS_PER_OLT)
# Iptables setup
sudo iptables -P FORWARD ACCEPT
```
+Setting `numOlts` and `numOnus` is optional; the default is 1.
+
**Before proceeding**
-Run: `kubectl -n voltha get pod`
+Run: `kubectl -n voltha get pod -l app=ponsim`
-Make sure that all of the pods in the voltha namespace are in Running state.
```bash
-$ kubectl -n voltha get pod
-NAME READY STATUS RESTARTS AGE
-default-http-backend-846b65fb5f-rklfb 1/1 Running 0 6h
-freeradius-765c9b486c-6qs7t 1/1 Running 0 6h
-netconf-7d7c96c88b-29cv2 1/1 Running 0 6h
-nginx-ingress-controller-6db99757f7-d9cpk 1/1 Running 0 6h
-ofagent-7d7b854cd4-fx6gq 1/1 Running 0 6h
-olt0-5455744678-hqbwh 1/1 Running 0 6h
-onu0-5df655b9c9-prfjz 1/1 Running 0 6h
-rg0-75845c54bc-fjgrf 1/1 Running 0 6h
-vcli-6875544cf-rfdrh 1/1 Running 0 6h
-vcore-0 1/1 Running 0 6h
-voltha-546cb8fd7f-5n9x4 1/1 Running 3 6h
+$ kubectl -n voltha get pod -l app=ponsim
+NAME READY STATUS RESTARTS AGE
+olt0-f4744dc5-xdrjb 1/1 Running 0 15h
+onu0-0-6bf67bf6c6-76gn7 1/1 Running 0 15h
+rg0-0-7b9d5cdb5c-jc8p5 1/1 Running 0 14h
```
-If you see the olt pod in CrashLoopBackOff state, try deleting (`helm delete --purge`) and reinstalling the ponsimv2 chart.
+Make sure that all of the pods in the voltha namespace are in Running state.
+If you see the `olt0` pod in CrashLoopBackOff state, try deleting (`helm delete --purge`) and reinstalling the ponsimv2 chart.
+
+If you install more than one OLT/ONU then you will see more containers above. The naming convention:
+```
+1st OLT - olt0-xxx
+2nd OLT - olt1-xxx
+1st ONU attached to 1st OLT - onu0-0-xx (onu<olt>-<onu>)
+2nd ONU attached to 1st OLT - onu0-1-xx
+1st ONU attached to 2nd OLT - onu1-0-xx
+2nd ONU attached to 2nd OLT - onu1-1-xx
+RG follows the same naming logic as ONU (rg0-0-xx, rg0-1-xx, rg1-0-xx, rg1-1-xx)
+Linux bridges interconnecting ONU and RG follow the same naming logic as ONU (pon0.0, pon0.1 ...)
+Linux bridges interconnecting OLT and Mininet follow same naming logic as OLT (nni0, nni1, ...)
+```
Run `http GET http://127.0.0.1:30125/health|jq '.state'`. It should return `"HEALTHY"`:
@@ -344,6 +326,7 @@
"HEALTHY"
```
+
## Install NEM charts
Run these commands:
@@ -376,26 +359,26 @@
Run these commands:
```bash
-helm install -n ponsim-pod xos-profiles/ponsim-pod
+helm install -n ponsim-pod xos-profiles/ponsim-pod --set numOlts=$(NUM_OLTS) --set numOnus=$(NUM_ONUS_PER_OLT)
~/cord/helm-charts/scripts/wait_for_pods.sh
```
+The TOSCA creates a subscriber for each RG `rg<olt>-<onu>` with S-tag of `222+<olt>` and C-tag of `111+<onu>`.
+
**Before proceeding**
-Log into the XOS GUI at `http://<hostname>:30001` (credentials: admin@opencord.org / letmein). You should see an AttWorkflowDriver Service Instance with authentication state AWAITING.
-
-To run the check from the command line:
+Log into the XOS GUI at `http://<hostname>:30001` (credentials: admin@opencord.org / letmein). You should see an AttWorkflowDriver Service Instance with authentication state AWAITING. To check this from the command line:
```bash
cordctl model list AttWorkflowDriverServiceInstance -f "authentication_state=AWAITING"
```
-This will show only the AttWorkflowDriver Service Instances in AWAITING state. Wait until you see something like:
+This will show only the AttWorkflowDriver Service Instances in AWAITING state. Wait until you see a line for each ONU:
```bash
$ cordctl model list AttWorkflowDriverServiceInstance -f "authentication_state=AWAITING"
-OWNER_ID SERIAL_NUMBER OF_DPID UNI_PORT_ID STATUS_MESSAGE ID NAME
-2 PSMO12345678 of:0000aabbccddeeff 128 ONU has been validated - Awaiting Authentication 56
+ID NAME OF_DPID OWNER_ID SERIAL_NUMBER STATUS_MESSAGE UNI_PORT_ID
+56 of:0000d0d3e158fede 2 PSMO00000000 ONU has been validated - Awaiting Authentication 128
```
## Install Mininet
@@ -416,7 +399,7 @@
```bash
cd ~/cord/helm-charts
-helm install -n mininet mininet
+helm install -n mininet mininet --set numOlts=$(NUM_OLTS) --set numOnus=$(NUM_ONUS_PER_OLT)
~/cord/helm-charts/scripts/wait_for_pods.sh
```
@@ -432,30 +415,32 @@
Run: `brctl show`
-You should see two interfaces on each of the pon0 and nni0 Linux bridges.
+You should see two interfaces on the `ponX.Y` and `nniX` Linux bridges.
```bash
$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429d07b4e2 no
-pon0 8000.bec4912b1f6a no veth25c1f40b
+pon0.0 8000.bec4912b1f6a no veth25c1f40b
veth2a4c914f
nni0 8000.0a580a170001 no veth3cc603fe
vethb6820963
```
-## Enable pon0 to forward EAPOL packets
+You will see more bridges if you've configured multiple OLTs and ONUs. All of the `nniX` Linux bridges connect to the agg switch in Mininet on different ports.
-This is necessary to enable the RG to authenticate. Run these commands:
+## Enable pon bridges to forward EAPOL packets
+
+This is necessary to enable the RG to authenticate:
```bash
-echo 8 > /tmp/pon0_group_fwd_mask
-sudo cp /tmp/pon0_group_fwd_mask /sys/class/net/pon0/bridge/group_fwd_mask
+echo 8 > /tmp/group_fwd_mask
+for BRIDGE in /sys/class/net/pon*; do sudo cp /tmp/group_fwd_mask $BRIDGE/bridge/group_fwd_mask; done
```
## ONOS customizations
-Right now it’s necessary to install some custom configuration to ONOS directly. Run this command:
+It’s necessary to install some custom configuration to ONOS directly. Run this command:
```bash
http -a karaf:karaf POST \
@@ -464,7 +449,7 @@
The above command instructs the ONU to exchange untagged packets with the RG, rather than packets tagged with VLAN 0.
-At this point the system should be fully installed and functional.
+At this point the system should be fully installed and functional.
## Validating the install
@@ -473,10 +458,11 @@
Enter the RG pod in the voltha namespace:
```bash
-RG_POD=$( kubectl -n voltha get pod -l "app=rg0-0" -o jsonpath='{.items[0].metadata.name}' )
+RG_POD=$( kubectl -n voltha get pod | grep rg0-0 | awk '{print $1}' )
kubectl -n voltha exec -ti $RG_POD bash
```
+If you built SiaB with multiple OLTs and ONUs, you can choose any RG to authenticate.
Inside the pod, run this command:
```bash
@@ -500,8 +486,7 @@
**Before proceeding**
-In the XOS GUI, the AttDriverWorkflow Service Instance should now be in APPROVED state.
-You can check for this on the command line by running:
+In the XOS GUI, the AttDriverWorkflow Service Instance should now be in APPROVED state. You can check for this on the command line by running:
```bash
cordctl model list AttWorkflowDriverServiceInstance -f "authentication_state=APPROVED"
@@ -511,12 +496,11 @@
```bash
$ cordctl model list AttWorkflowDriverServiceInstance -f "authentication_state=APPROVED"
-OF_DPID UNI_PORT_ID STATUS_MESSAGE ID NAME OWNER_ID SERIAL_NUMBER
-of:0000aabbccddeeff 128 ONU has been validated - Authentication succeeded 56 2 PSMO12345678
+ID NAME OF_DPID OWNER_ID SERIAL_NUMBER STATUS_MESSAGE UNI_PORT_ID
+56 of:0000d0d3e158fede 2 PSMO00000000 ONU has been validated - Authentication succeeded 128
```
-The FabricCrossconnect Service Instance should have a check in the Backend status column in the GUI.
-You can check for this on the command line by running:
+The FabricCrossconnect Service Instance should have a check in the Backend status column in the GUI. You can check for this on the command line by running:
```bash
cordctl model list FabricCrossconnectServiceInstance -f 'backend_status=OK'
@@ -526,8 +510,8 @@
```bash
$ cordctl model list FabricCrossconnectServiceInstance -f 'backend_status=OK'
-SWITCH_DATAPATH_ID SOURCE_PORT ID NAME OWNER_ID S_TAG
-of:0000000000000001 2 59 5 222
+ID NAME OWNER_ID S_TAG SOURCE_PORT SWITCH_DATAPATH_ID
+59 4 222 2 of:0000000000000001
```
### Obtain an IP address for the RG
@@ -556,7 +540,7 @@
**Before proceeding**
-Make sure that eth0 inside the RG container has an IP address on the 172.18.0.0/24 subnet:
+`rg<olt>-<onu>` will get an IP address on subnet `172.18+<olt>.<onu>.0/24`. Make sure that eth0 inside the RG container has an IP address on the proper subnet:
```bash
$ ifconfig eth0
@@ -571,7 +555,7 @@
### Ping the emulated BNG
-The emulated BNG has an IP address of 172.18.0.10. After successfully running dhclient you should be able to ping it from the RG.
+`rg<olt>-<onu>` pings `172.18+<olt>.<onu>.10` as its BNG.
```bash
$ ping -c 3 172.18.0.10
diff --git a/profiles/seba/workflows/att-install.md b/profiles/seba/workflows/att-install.md
index e1182de..3a80da0 100644
--- a/profiles/seba/workflows/att-install.md
+++ b/profiles/seba/workflows/att-install.md
@@ -5,7 +5,7 @@
## Install the `att-workflow` chart
```shell
-helm install -n att-workflow cord/att-workflow --version=1.0.2
+helm install -n att-workflow cord/att-workflow --version=1.2.4
```
> NOTE: if you have installed the `cord-platform` chart as a sum of its components,
diff --git a/quickstart/seba_quickstart.md b/quickstart/seba_quickstart.md
index 10a9cc7..1aa43c0 100644
--- a/quickstart/seba_quickstart.md
+++ b/quickstart/seba_quickstart.md
@@ -6,26 +6,30 @@
## Install components as a whole
+The commands below will bring up the SEBA 2.0-alpha release
+
```shell
# Add the CORD repository and update indexes
helm repo add cord https://charts.opencord.org
helm repo update
# Install the CORD platform
-helm install -n cord-platform --version 6.1.0 cord/cord-platform
+helm install -n cord-platform --version 7.0.0 cord/cord-platform
# Wait until 3 etcd CRDs are present in Kubernetes
kubectl get crd | grep -i etcd | wc -l
# Install the SEBA profile
-helm install -n seba --version 1.0.0 cord/seba
+helm install -n seba --version 2.0.0-alpha1 cord/seba
# Install the AT&T workflow
-helm install -n att-workflow --version 1.0.2 cord/att-workflow
+helm install -n att-workflow --version 1.2.4 cord/att-workflow
```
## Alternatively, install as separate components
+The commands below will bring up SEBA using the latest released versions of the Helm charts. The resulting system should work but it may not correspond to an official SEBA release.
+
```shell
# Add the official Kubernetes incubator repostiory (for Kafka) and update the indexes
helm repo add incubator http://storage.googleapis.com/kubernetes-charts-incubator
@@ -63,12 +67,12 @@
kubectl get crd | grep -i etcd | wc -l
# Install the rest of the SEBA profile components
-helm install -n voltha cord/voltha
+helm install -n voltha --version 1.0.6 cord/voltha # Install VOLTHA 1.7.0
helm install -n seba-service cord/seba-services
helm install -n base-kubernetes cord/base-kubernetes
# Install the AT&T workflow
-helm install -n att-workflow --version 1.0.2 cord/att-workflow
+helm install -n att-workflow cord/att-workflow
```
## Verify your installation and next steps