-
Type: Bug
-
Status: Resolved (View Workflow)
-
Priority: Medium
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: VOLTHA v2.1
-
Component/s: openolt-adapter, openonu-adapter, rw-core
-
Labels:
-
Story Points:8
-
Epic Link:
Currently when an EAPOL flow or any controller trap flow is sent to rw-core and flow decomposer, it only creates a parent (openolt adapter) flow. The match vlan specified in this flow can be either the default vlan 4091 or the subscriber assigned vlan. For these flows the onu adapter (or more specifically the uni port) is not given a vlan filter flow via decomposition. The onu adapter is given this vlan configuration only as part of the tech-profile-assignment task. The tech profile assignment task always uses vlan 4091, regardless if the olt adapter was given vlan 4091 or the subscriber vlan.
For onu startup/uni startup this is not noticed as an issue as both the vlan from decomposition and the hardcoded tp-task vlan are 4091. But after any subscriber vlans are pushed and any follow up tech profile tasks (p-bit remapping, uni link state update) need to be run, the olt is given the subscriber vlan while the tech profile task given to the onu uses the default 4091 vlan causing a mismatch that prevents both eapol and subscriber traffic.
The fix here could be one of:
1) pass the vlan into the tech profile task handed down from the olt adapter, have the onu adapter use that vlan, be it 4091 or subscriber
2) or do not have the tech profile task set any vlan. It only sets up the gem port, queue setup and bridge assignment, but does not setup the vlan filtering. When the core decomposed the vlan assignment task for trap flows to the parent and child, then the same task that sets vlan can be used for both 4091 or subscriber.
Option #2 will be implemented. This not only removes the hard coded 4091 assignment, but also consolidates onu vlan assignment to one task removing code duplication.
- relates to
-
VOL-1384 ONU reboot using Edgecore asfvolt16
- Resolved