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:

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:

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:

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 :

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:

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 Operator 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 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:

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:

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:

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:

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:

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 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:

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.