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 worflow 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
Flows can also be checked in VOLTHA trhough voltctl:
voltctl device flows 17bfa0c8-bd86-4ead-b755-d612bfda9c5b
ID TABLEID PRIORITY COOKIE INPORT VLANID ETHTYPE IPPROTO UDPSRC UDPDST METADATA TUNNELID SETVLANID POPVLAN PUSHVLANID OUTPUT WRITEMETADATA METERID
2e80b1ff53a75953 0 1000 ~986cca9a 536870912 900 16 900 0x8100 1048576 0x0000004000000000 1
37931e7d3cd25140 0 10000 ~ba31a4f2 536870912 900 0x0800 17 68 67 16 CONTROLLER 0x0000004000000000 1
6c4a02b93c22ba55 0 10000 ~ce6c3527 1048576 0x88cc CONTROLLER
2ba82605da4ff200 0 10000 ~f81586a7 1048576 0x0800 17 67 68 CONTROLLER
3102d254d97eda94 0 10000 ~5eb48e6a 536870912 900 0x888e 16 CONTROLLER 0x0384004000000000 1
49f503c2f9f7203b 0 1000 ~531d5ec9 1048576 900 0x0000000000000384 16 yes 536870912 0x0384004000000010 1
DHCP Allocation¶
If the worflow 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.