-
Type: Bug
-
Status: Resolved (View Workflow)
-
Priority: Medium
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: VOLTHA v2.9
-
Component/s: openolt-adapter, rw-core
-
Labels:None
-
Story Points:5
-
Epic Link:
-
Sprint:VOLTHA 2.9 - Sprint 6
After adapter restart, roughly after 30s or so the subscriber flows were provisioned. The datapath rule is a two table rule. Because openonu adapter connection is fine and onu device is not in reconciling state the canMultipleAdapterRequestProceed OKs the ONU logical flow. But the ONU waits for techprofile download message before processing the flow. Now the openolt does not send techprofile download message to openonu adapter because it is still reconciling. It took roughly 50s post restart before rw-core actually sent down the flow to openolt adapter. By this time the rw-core timed-out on flow towards openonu (note that openonu was blocked on openolt adapter to give TP download signal) and it started reverting the flow. This caused some other issues which I will come to later.
My thoughts are that canMultipleAdapterRequestProceed should not allow flows to child adapter if the parent adapter connection is not up or parent device is in reconciling state.
Regarding another topic with flow reverts on timeout. There are two cases for flow revert. # A single Logical flow, like EAP trap, being divided between olt and onu adapter
- A logical flow is not divided, but is meant for either olt or onu, based on flow table and direction. We normally have two table rules for datapath flow and both table rules are dependent on each other.
In the first case if the flow times out for either of the adapter, it is reverted for both adapters - perfectly alright.
In the second case, if say for example the onu adapter flow times-out, it is reverted only for onu adapter and not olt adapter. I think it should be reverted for both adapters. I say this because flow removals are normally followed by other cleanups on the PON side. If OLT adapter did not receive a flow remove it does not trigger certain PON cleanup messages while ONU adapter is expecting it. There are certain timeout handlers to not block for ever but the ONU gets stuck in some unusable state unless it is rebooted or deleted->re-provisioned.