overview/operate.rst - voltha-docs - Gitiles

 .. _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.
	.. _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.