Merge "SEBA-782 cordctl SEBA tutorial"
diff --git a/developer/workflows/onos-apps.md b/developer/workflows/onos-apps.md
index 105276a..352cbfa 100644
--- a/developer/workflows/onos-apps.md
+++ b/developer/workflows/onos-apps.md
@@ -115,7 +115,7 @@
```yaml
-aaaAppUrl: "myregistrydomain.com:30160/repository/aaa-app-1.10.0-SNAPSHOT.oar"
+aaaAppUrl: "http://myregistrydomain.com:30160/repository/aaa-app-1.10.0-SNAPSHOT.oar"
aaaAppVersion: "1.10.0.SNAPSHOT"
```
@@ -128,5 +128,5 @@
```
> You can find a full list of the application names and URLs here:
-> - https://github.com/opencord/helm-charts/blob/master/xos-profiles/seba-services/values.yaml#L43-L53
-> - https://github.com/opencord/helm-charts/blob/master/workflows/att-workflow/values.yaml#L40-L41
\ No newline at end of file
+> - https://github.com/opencord/helm-charts/blob/master/xos-profiles/seba-services/values.yaml#L43-L53
+> - https://github.com/opencord/helm-charts/blob/master/workflows/att-workflow/values.yaml#L40-L41
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/operating_cord/elk_stack.md b/operating_cord/elk_stack.md
index 6546452..80c2326 100644
--- a/operating_cord/elk_stack.md
+++ b/operating_cord/elk_stack.md
@@ -196,4 +196,33 @@
}
}
' | jq .hits.hits
-```
\ No newline at end of file
+```
+
+### Get Operational status of the RADIUS server
+
+Operational status can be queried from Elastic search using Rest API calls.
+Three possible values for operational status are:
+1) In Use
+2) Unknown
+3) Unavailable
+
+```bash
+curl -XGET "http://localhost:$ELK_PORT/_search" -H 'Content-Type: application/json' -d'
+{
+ "query": {
+ "bool": {
+ "filter": {
+ "term": {
+ "kafka_topic": "radiusoperationalstatus.events"
+ }
+ }
+ }
+ }
+}' | jq .hits.hits[0]._source.radiusoperationalstatus
+```
+
+Example Response:
+
+```bash
+"In Use"
+```
diff --git a/prereqs/hardware.md b/prereqs/hardware.md
index dabfe11..6f1173e 100644
--- a/prereqs/hardware.md
+++ b/prereqs/hardware.md
@@ -84,7 +84,7 @@
* Celestica Tellion GP-1204
* Movistar ONU (with CPE included) (manifactured by Telefonica: <http://www.movistar.es/particulares/movil/moviles/hgu>)
* **XGS-PON**
- * **OLT**: EdgeCore ASFVOLT16 (for more info <bartek_raszczyk@edge-core.com>)
+ * **OLT**: Edgecore ASXvOLT16 (for more info <bartek_raszczyk@edge-core.com>)
* Compatible **OLT optics**
* Hisense/Ligent: LTH7226-PC, LTH7226-PC+
* Source Photonics: XPP-XG2-N1-CDFA
diff --git a/profiles/seba/configuration.md b/profiles/seba/configuration.md
index 780ea1a..0df79b0 100644
--- a/profiles/seba/configuration.md
+++ b/profiles/seba/configuration.md
@@ -6,8 +6,8 @@
In this page we are describing the process as a three steps process:
-- [Fabric Setup](./configuration.md#fabric-setup)
-- [OLT Provisioning](./configuration.md#olt-provisioning)
+- [POD Setup](./configuration.md#pod-setup)
+- [PON Provisioning](./configuration.md#pon-provisioning)
- [Subscriber Provisioning](./configuration.md#subscriber-provisioning)
as that is what logically makes sense, but be aware that all the configurations
@@ -17,7 +17,15 @@
you will need to create your own, but the following can serve as a
reference:
-## Fabric Setup
+## POD Setup
+
+The POD Setup consists of
+
+- Fabric configuration (In this case a single aggregation switch, see [Fabric](../../fabric/README.md) for more information)
+- `BNGPortMapping` configuration (see [Fabric-crossconnet](../../fabric-crossconnect/README.md) for more information)
+- DHCP L2 Relay configuration (see [ONOS DHCP L2 RELAY Application](https://github.com/opencord/dhcpl2relay/#configuration) for more information)
+
+For simplicity this is encapsulated in a single TOSCA recipe:
```yaml
tosca_definitions_version: tosca_simple_yaml_1_0
@@ -103,7 +111,13 @@
For instructions on how to push TOSCA into a CORD POD, please
refer to this [guide](../../xos-tosca/README.md).
-## OLT Provisioning
+## PON Provisioning
+
+The PON Provisioning consists of preparing all the configurations needed by ONOS and VOLTHA to manage the PON network,
+su as:
+
+- [OLT](../../olt-service/README.md#create-an-OLT)
+- [Technology Profile](https://github.com/opencord/voltha/tree/master/common/tech_profile)
```yaml
tosca_definitions_version: tosca_simple_yaml_1_0
@@ -111,6 +125,7 @@
- custom_types/oltdevice.yaml
- custom_types/onudevice.yaml
- custom_types/voltservice.yaml
+ - custom_types/technologyprofile.yaml
description: Create an OLT Device in VOLTHA
topology_template:
node_templates:
@@ -128,16 +143,78 @@
device_type: openolt
host: 10.90.0.122
port: 9191
- switch_datapath_id: of:0000000000000002 # the openflow switch to which the OLT is connected
+ switch_datapath_id: of:0000000000000002 # the openflow id of the switch to which the OLT is connected
switch_port: "1" # the port on the switch on which the OLT is connected
outer_tpid: "0x8100"
uplink: "65536"
nas_id: "NAS_ID"
- serial_number: "10.90.0.122:9191"
+ serial_number: EC1721000208 # the serial number of the OLT device
requirements:
- volt_service:
node: service#volt
relationship: tosca.relationships.BelongsToOne
+
+ technologyProfile:
+ type: tosca.nodes.TechnologyProfile
+ properties:
+ profile_id: 64
+ technology: xgspon
+ profile_value: >
+ {
+ "name": "4QueueHybridProfileMap1",
+ "profile_type": "XPON",
+ "version": 1.0,
+ "num_gem_ports": 1,
+ "instance_control": {
+ "onu": "multi-instance",
+ "uni": "single-instance",
+ "max_gem_payload_size": "auto"
+ },
+ "us_scheduler": {
+ "additional_bw": "auto",
+ "direction": "UPSTREAM",
+ "priority": 0,
+ "weight": 0,
+ "q_sched_policy": "hybrid"
+ },
+ "ds_scheduler": {
+ "additional_bw": "auto",
+ "direction": "DOWNSTREAM",
+ "priority": 0,
+ "weight": 0,
+ "q_sched_policy": "hybrid"
+ },
+ "upstream_gem_port_attribute_list": [{
+ "pbit_map": "0b11000000",
+ "aes_encryption": "True",
+ "scheduling_policy": "StrictPriority",
+ "priority_q": 1,
+ "weight": 0,
+ "discard_policy": "TailDrop",
+ "max_q_size": "auto",
+ "discard_config": {
+ "min_threshold": 0,
+ "max_threshold": 0,
+ "max_probability": 0
+ }
+ }
+ ],
+ "downstream_gem_port_attribute_list": [{
+ "pbit_map": "0b11000000",
+ "aes_encryption": "True",
+ "scheduling_policy": "StrictPriority",
+ "priority_q": 1,
+ "weight": 0,
+ "discard_policy": "TailDrop",
+ "max_q_size": "auto",
+ "discard_config": {
+ "min_threshold": 0,
+ "max_threshold": 0,
+ "max_probability": 0
+ }
+ }
+ ]
+ }
```
For instructions on how to push TOSCA into a CORD POD, please
@@ -147,6 +224,8 @@
Once the POD has been configured, you can create a subscriber.
+This section will guide you through the configuration of `Subscriber` and associated `BandwidthProfile`s.
+
To create a subscriber, you'll need to know the serial number of the ONU it is
attached to.
@@ -221,17 +300,41 @@
tosca_definitions_version: tosca_simple_yaml_1_0
imports:
- custom_types/rcordsubscriber.yaml
+ - custom_types/bandwidthprofile.yaml
description: Create a test subscriber
topology_template:
node_templates:
+
+ high_speed_bp:
+ type: tosca.nodes.BandwidthProfile
+ properties:
+ air: 2000
+ cbs: 2000
+ cir: 2000
+ ebs: 2000
+ eir: 2000
+ name: High Speed Internet
+
# A subscriber
my_house:
type: tosca.nodes.RCORDSubscriber
properties:
name: My House
+ status: pre-provisioned # the status we want to create the subscriber in
c_tag: 111
s_tag: 222
- onu_device: BRCM1234 # Serial Number of the ONU Device to which this subscriber is connected
+ onu_device: BRCM22222222 # Serial Number of the ONU Device to which this subscriber is connected
+ tech_profile_id: 64 # The ID of the technology profile that needs to be applied to this subscriber
+ nas_port_id : some-value # radius specific attributes
+ circuit_id: some-value # radius specific attributes
+ remote_id: some-value # radius specific attributes
+ requirements:
+ - upstream_bps:
+ node: high_speed_bp
+ relationship: tosca.relationships.BelongsToOne
+ - downstream_bps:
+ node: high_speed_bp
+ relationship: tosca.relationships.BelongsToOne
```
For instructions on how to push TOSCA into a CORD POD, please
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 84f6eb3..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,60 +60,18 @@
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:
```bash
-make latest [NUM_OLTS=n]
+make latest [NUM_OLTS=n] [NUM_ONUS_PER_OLT=m]
```
-
-With the `latest` target, you can specify the number of OLT/ONU/RG chains (up to 4) that you want to
-create. Each OLT associates with a single ONU; adding multiple ONUs per OLT is future work. If you
-specify more than one OLT you will see several OLT/ONU/RG containers when you run `kubectl -n voltha
-get pod`:
-
-```bash
-$ kubectl -n voltha get pod
-NAME READY STATUS RESTARTS AGE
-...
-olt0-774f9cb5f7-2z256 1/1 Running 0 6m31s
-olt1-5f7c44f554-rkdbq 1/1 Running 0 6m31s
-olt2-d949c6c9f-jcmgz 1/1 Running 0 6m31s
-onu0-7db8455577-8n8ks 1/1 Running 0 6m30s
-onu1-d64b87d79-kqmd5 1/1 Running 0 6m31s
-onu2-5bb54b889-8g6w8 1/1 Running 0 6m31s
-rg0-84b6654764-ztb4r 1/1 Running 0 6m30s
-rg1-b8ccb5cfd-r2586 1/1 Running 0 6m30s
-rg2-574c7d9f6-f5knh 1/1 Running 0 6m30s
-...
-```
-
-Likewise `brctl show` will output:
-
-```bash
-$ brctl show
-bridge name bridge id STP enabled interfaces
-docker0 8000.02429b163213 no
-nni0 8000.e62fcf80f1ed no vethac65f4a9
- vethcdad8664
-nni1 8000.06298b5e03f5 no veth4c8048bf
- vethdd2f29d1
-nni2 8000.aef29aa3595a no vetha7186d8a
- vethd9610930
-pon0 8000.a24b3df352ac no veth1b61ec08
- veth3f1056c1
-pon1 8000.824c4346fb80 no veth631eb0a8
- vethdae92661
-pon2 8000.6e30a2216b3c no veth66b840fa
- veth72f061ad
-```
-
-Above there are three separate datapath chains: `rg0 -> pon0 -> onu0 -> olt0 -> nni0`, `rg1 -> pon1
--> onu1 -> olt1 -> nni1`, etc. All of the `nniX` bridges connect to the agg switch in Mininet on
-different ports. A subscriber is created for each RG `rgX` with S-tag of `222+X` and C-tag of
-`111`. After `rgX` is authenticated, it will get an IP address on subnet `172.18.X.0/24` and ping
-`172.18.X.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:
@@ -126,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
@@ -219,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
@@ -255,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:
@@ -269,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"`:
@@ -328,6 +326,7 @@
"HEALTHY"
```
+
## Install NEM charts
Run these commands:
@@ -360,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
@@ -400,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
```
@@ -416,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 \
@@ -448,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
@@ -457,10 +458,11 @@
Enter the RG pod in the voltha namespace:
```bash
-RG_POD=$( kubectl -n voltha get pod -l "app=rg0" -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
@@ -484,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"
@@ -495,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'
@@ -510,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
@@ -540,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
@@ -555,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