.. _operate:

Operate a VOLTHA POD
====================

In this page we assume that you have a VOLTHA POD (either Physical or Virtual) up and running.

Provision an OLT
----------------

The first step in order to operate a VOLTHA POD is to add an OLT to it.

If you deployed a Virtual cluster you can create a BBSim based OLT in VOLTHA with:

.. code:: bash

    voltctl device create -t openolt -H bbsim0.voltha.svc:50060

*If you have deployed multiple BBSim instances using the ``NUM_OF_BBSIM`` variable
you can list all the available BBSim OLTs with ``kubectl get svc --all-namespaces | grep bbsim``*

If you are connecting to a Physical OLT:

.. code:: bash

    voltctl device create -t openolt -H <olt-management-ip>:9191

Regardless of the OLT the command to ``enable`` an OLT in VOLTHA is always the same:

.. code:: bash

    voltctl device enable <device-id>

*The ``device id`` is the output of the ``device create`` command, or can be retrieved
with ``voltctl device list``*

If you have just one OLT create you can use :

.. code:: bash

    voltctl device enable $(voltctl device list --filter Type~openolt -q)

Once the OLT is ``enabled`` in VOLTHA you should be able to see the ONU attached
to it by listing the devices:

.. code:: bash

    voltctl device list

Authentication
--------------

If the use-case you installed (e.g. AT&T) expects EAPOL based authentication you want to make
sure that is working. Visit :ref:`workflows` for more information.

In a **Physical POD** you need to trigger authentication on your client
(if it doesn't do so automatically). You can refer to :ref:`setting-up-a-client`.

In a **Virtual POD** installed with the ``WITH_EAPOL="yes"`` flag authentication
happens automatically.

You can check the authentication state for your subscribers via the ONOS cli:

.. code:: bash

    ssh -p 8101 karaf@localhost # (pwd: karaf)
    karaf@root > aaa-users
    of:00000a0a0a0a0a00/16: AUTHORIZED_STATE, last-changed=5m14s ago, mac=2E:60:70:00:00:01, subid=BBSM00000001-1, username=user

*Note that if ONOS was not installed as parted of VOLTHA the ``ssh`` command may differ*

Subscriber provisioning
-----------------------

*Note that, depending on the workflow, authentication is not a requirement of subscriber provisioning*

The process referred to as ``Subscriber provisioning`` causes traffic flows to be created in ONOS and
 data plane path to be configured in the device, enabling different services on a specific UNI port.

In order to provision a subscriber you need to identify it. In ONOS a subscriber
is viewed as an enabled port (UNI) on the logical switch that VOLTHA exposes, for example:

.. code:: bash

    ssh -p 8101 karaf@localhost # (pwd: karaf)
    karaf@root > ports -e
    id=of:00000a0a0a0a0a00, available=true, local-status=connected 8m27s ago, role=MASTER, type=SWITCH, mfr=VOLTHA Project, hw=open_pon, sw=open_pon, serial=BBSIM_OLT_0, chassis=a0a0a0a0a00, driver=voltha, channelId=10.244.2.7:53576, managementAddress=10.244.2.7, protocol=OF_13
      port=16, state=enabled, type=fiber, speed=0 , adminState=enabled, portMac=08:00:00:00:00:10, portName=BBSM00000001-1
      port=1048576, state=enabled, type=fiber, speed=0 , adminState=enabled, portMac=0a:0a:0a:0a:0a:00, portName=nni-1048576

Once the port number representing a subscriber has been retrieved, you can provision it via:

.. code:: bash

    ssh -p 8101 karaf@localhost # (pwd: karaf)
    karaf@root > volt-add-subscriber-access of:00000a0a0a0a0a00 16

Where ``of:00000a0a0a0a0a00`` is the OpenFlow ID of the Logical Device representing the OLT
and ``16`` is the port representing that particular subscriber.

To verify that the subscriber has been provisioned:

.. code:: bash

    ssh -p 8101 karaf@localhost # (pwd: karaf)
    karaf@root > volt-programmed-subscribers
    location=of:00000a0a0a0a0a00/16 tagInformation=UniTagInformation{uniTagMatch=0, ponCTag=900, ponSTag=900, usPonCTagPriority=-1, usPonSTagPriority=-1, dsPonCTagPriority=-1, dsPonSTagPriority=-1, technologyProfileId=64, enableMacLearning=false, upstreamBandwidthProfile='Default', downstreamBandwidthProfile='Default', serviceName='', configuredMacAddress='A4:23:05:00:00:00', isDhcpRequired=true, isIgmpRequired=false}

You can also verify that the expected flows have been created and ``ADDED`` to VOLTHA:

.. code:: bash

    ssh -p 8101 karaf@localhost # (pwd: karaf)
    karaf@root > flows -s
    deviceId=of:00000a0a0a0a0a00, flowRuleCount=8
      ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:16, ETH_TYPE:eapol, VLAN_VID:900], treatment=[immediate=[OUTPUT:CONTROLLER], meter=METER:1, metadata=METADATA:384004000000000/0]
      ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:16, ETH_TYPE:ipv4, VLAN_VID:900, IP_PROTO:17, UDP_SRC:68, UDP_DST:67], treatment=[immediate=[OUTPUT:CONTROLLER], meter=METER:1, metadata=METADATA:4000000000/0]
      ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:1048576, ETH_TYPE:lldp], treatment=[immediate=[OUTPUT:CONTROLLER]]
      ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:1048576, ETH_TYPE:ipv4, IP_PROTO:17, UDP_SRC:67, UDP_DST:68], treatment=[immediate=[OUTPUT:CONTROLLER]]
      ADDED, bytes=0, packets=0, table=0, priority=1000, selector=[IN_PORT:16, VLAN_VID:0], treatment=[immediate=[VLAN_ID:900], transition=TABLE:1, meter=METER:1, metadata=METADATA:384004000100000/0]
      ADDED, bytes=0, packets=0, table=0, priority=1000, selector=[IN_PORT:1048576, METADATA:384, VLAN_VID:900], treatment=[immediate=[VLAN_POP], transition=TABLE:1, meter=METER:1, metadata=METADATA:384004000000010/0]
      ADDED, bytes=0, packets=0, table=1, priority=1000, selector=[IN_PORT:1048576, METADATA:10, VLAN_VID:900], treatment=[immediate=[VLAN_ID:0, OUTPUT:16], meter=METER:1, metadata=METADATA:4000000000/0]
      ADDED, bytes=0, packets=0, table=1, priority=1000, selector=[IN_PORT:16, VLAN_VID:900], treatment=[immediate=[VLAN_PUSH:vlan, VLAN_ID:900, OUTPUT:1048576], meter=METER:1, metadata=METADATA:4000000000/0]

*The flows above may vary in form and number from workflow to workflow, the example is given for the ATT workflow*

DHCP Allocation
---------------

If the use-case you installed expect DHCP to be handled by ONOS it's time to check
that an IP has correctly been allocated to the subscriber.

In a **Physical POD** you need to trigger a DHCP request on your client
(if it doesn't do so automatically). You can refer to :ref:`setting-up-a-client`.

In a **Virtual POD** installed with the ``WITH_DHCP="yes"`` flag a DHCP requests
happens automatically.

You can check the DHCP state for your subscribers via the ONOS cli:

.. code:: bash

    ssh -p 8101 karaf@localhost # (pwd: karaf)
    karaf@root > dhcpl2relay-allocations
    01SubscriberId=BBSM00000001-1,ConnectPoint=of:00000a0a0a0a0a00/16,State=DHCPACK,MAC=2E:60:70:00:00:01,CircuitId=BBSM00000001-1,IP Allocated=192.168.240.6,Allocation Timestamp=2020-07-27T22:39:24.140361Z

Data plane validation
---------------------

If you deployed a **Virtual POD** with a BBSim OLT you are done. BBSim does not support
data plane emulation at the moment.

If you deployed a **Physical POD** then you should now be able to reach the internet, from
your client attached to the UNI port you provisioned during the ``subscriber provisioning`` step.