-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Medium
-
Resolution: Fixed
-
Affects Version/s: VOLTHA v2.9
-
Fix Version/s: VOLTHA v2.12
-
Component/s: onos-olt
-
Labels:None
-
Story Points:1
After the refactor done on Olt app (5.x), we noticed that Sadis service is always being queried during flows removal.
If the operator changes some of the Sadis configuration related to an already provisioned subscriber, the flow may not be removed during ONU reboot, delete or “volt-remove-subcriber-access” execution.
That happens because Sadis fields are used to create the flow removal request, so if you change a field that composes the flow entry (e.g: c-tag, s-tag, q-tag, priorities, etc.), Olt app will try to uninstall a nonexistent flow based on that modification and will spare the real one which was created based on the older Sadis entry.
E.g:
Suppose you have a subscriber with a Sadis service configured with ponCTag=900.
After running the command “volt-add-subscriber-access”, flows with that information will be installed:
karaf@root > flows -s 20:16:56
deviceId=of:00000a0a0a0a0a0a, flowRuleCount=9
ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:16777216, ETH_TYPE:lldp], treatment=[immediate=[OUTPUT:CONTROLLER]]
ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:256, ETH_TYPE:ipv4, IP_PROTO:17, UDP_SRC:68, UDP_DST:67], treatment=[immediate=[OUTPUT:CONTROLLER, VLAN_ID:900], meter=METER:1, metadata=METADATA:4000000001/0]
ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:16777216, ETH_TYPE:ipv4, IP_PROTO:2], treatment=[immediate=[OUTPUT:CONTROLLER]]
ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:256, ETH_TYPE:eapol], treatment=[immediate=[OUTPUT:CONTROLLER, VLAN_PUSH:vlan, VLAN_ID:900], meter=METER:1, metadata=METADATA:384004000000001/0]
ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:16777216, 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:16777216, METADATA:384, VLAN_VID:900], treatment=[immediate=[VLAN_POP], transition=TABLE:1, meter=METER:1, metadata=METADATA:384004000000100/0]
ADDED, bytes=0, packets=0, table=0, priority=1000, selector=[IN_PORT:256, VLAN_VID:0], treatment=[immediate=[VLAN_ID:900], transition=TABLE:1, meter=METER:1, metadata=METADATA:384004001000000/0]
ADDED, bytes=0, packets=0, table=1, priority=1000, selector=[IN_PORT:256, VLAN_VID:900], treatment=[immediate=[VLAN_PUSH:vlan, VLAN_ID:900, OUTPUT:16777216], meter=METER:1, metadata=METADATA:4000000000/0]
ADDED, bytes=0, packets=0, table=1, priority=1000, selector=[IN_PORT:16777216, METADATA:100, VLAN_VID:900], treatment=[immediate=[VLAN_ID:0, OUTPUT:256], meter=METER:1, metadata=METADATA:4000000000/0]
If you change that Sadis service to have ponCTag=800 and then run the command “volt-remove-subscriber-access“, the Olt app will end up using the new value as reference while creating the flow delete request.
As a result, flows using the ponCTag=900 are going to be spared.
karaf@root > sadis BBSM000a0001-1 20:21:11 [id:BBSM000a0001-1,nasPortId:BBSM000a0001-1,uplinkPort:-1,slot:-1,hardwareIdentifier:null,ipaddress:null,nasId:null,circuitId:BBSM000a0001-1,remoteId:BBSIM_OLT_10,uniTagList:[UniTagInformation{uniTagMatch=0, ponCTag=800, ponSTag=900, usPonCTagPriority=-1, usPonSTagPriority=-1, dsPonCTagPriority=-1, dsPonSTagPriority=-1, technologyProfileId=64, enableMacLearning=false, upstreamBandwidthProfile='Default', downstreamBandwidthProfile='Default', upstreamOltBandwidthProfile='Default', downstreamOltBandwidthProfile='Default', serviceName='hsia', configuredMacAddress='A4:23:05:00:00:00', isDhcpRequired=true, isIgmpRequired=false}]] karaf@root > volt-remove-subscriber-access of:00000a0a0a0a0a0a 256 20:21:21 20:21:24.643 INFO [Olt] Un-provisioning subscriber on of:00000a0a0a0a0a0a/256[BBSM000a0001-1] karaf@root > flows -s 20:21:31 deviceId=of:00000a0a0a0a0a0a, flowRuleCount=9 ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:16777216, ETH_TYPE:lldp], treatment=[immediate=[OUTPUT:CONTROLLER]] ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:256, ETH_TYPE:ipv4, IP_PROTO:17, UDP_SRC:68, UDP_DST:67], treatment=[immediate=[OUTPUT:CONTROLLER, VLAN_ID:900], meter=METER:1, metadata=METADATA:4000000001/0] ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:16777216, ETH_TYPE:ipv4, IP_PROTO:2], treatment=[immediate=[OUTPUT:CONTROLLER]] ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:256, ETH_TYPE:eapol], treatment=[immediate=[OUTPUT:CONTROLLER, VLAN_PUSH:vlan, VLAN_ID:4091], meter=METER:1, metadata=METADATA:ffb004000000001/0] ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:16777216, 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:16777216, METADATA:384, VLAN_VID:900], treatment=[immediate=[VLAN_POP], transition=TABLE:1, meter=METER:1, metadata=METADATA:384004000000100/0] ADDED, bytes=0, packets=0, table=0, priority=1000, selector=[IN_PORT:256, VLAN_VID:0], treatment=[immediate=[VLAN_ID:900], transition=TABLE:1, meter=METER:1, metadata=METADATA:384004001000000/0] ADDED, bytes=0, packets=0, table=1, priority=1000, selector=[IN_PORT:256, VLAN_VID:900], treatment=[immediate=[VLAN_PUSH:vlan, VLAN_ID:900, OUTPUT:16777216], meter=METER:1, metadata=METADATA:4000000000/0] ADDED, bytes=0, packets=0, table=1, priority=1000, selector=[IN_PORT:16777216, METADATA:100, VLAN_VID:900], treatment=[immediate=[VLAN_ID:0, OUTPUT:256], meter=METER:1, metadata=METADATA:4000000000/0]
We are used to change subscriber configuration on the fly, and I’d say it’s expected that the operator perform such kind of changes.
There are workarounds to clean those stuck resources:
- Changing the Sadis file to be exactly the same as during installation;
- Reboot Olt;
- Delete Olt then create it again.
1.
|
Jenkins failure related to VOL-4746 |
|
To Do | Unassigned |