Core changes supporting fabric traceable implementation.
Includes minor fixes to the OFDPA traceable unit tests
Change-Id: I2f0d1172022a8fc725df9e96526092c59ddc0e0b
- Exposes some ofdpa specific tables and types
- Introduces a new driver behavior PipelineTraceable
- OfdpaPipelineTraceable is the first implementation of the
new driver behavior
- New abstractions are introduced to encapsulate the input/output
of the traceables processing
- Implements some basic unit tests for Ofdpa implementation
Change-Id: I89d3fdeda445983ec7ebfa9ebb78afb1c6d3fd8f
- Inserting VLAN and PCP in the treatment of the IGMP trap flow. Uniforming it to VOD flow.
- Removing VLAN match and insertinbg VLAN push for EAPOL.
- Removing VLAN match if not required, pushing it or swapping it and setting the PCP in DHCP.
Change-Id: I40a6a75f81c582735f54186e165fab7c2d21b355
(cherry picked from commit a93905c0c4e866441fe15c0fff93c774c3e35166)
- portNextObjStore is not updated when adding or removing portNextObjective
- Group keys for L2IG in flowObjectiveStore are deleted while modifying L2IG, which in turn causes an exception
- L3UG pointing to L2IG, which is already removed, is not removed
- Empty L2FG, with VLAN ID removed from the configuration, is not removed
- Bridging and unicast routing rules for hosts are not updated when changing port VLAN from untagged to tagged and vice versa
Change-Id: I9454fe553ae53e0fc8839a4ad629c0b5b9039a36
Changes:
- Avoids to sends duplicate next when there are multiple sources
- Introduces a backpressure mechanism to not flood the pipeliners
- Guarantees there are at least 30s between each mcast corrector
execution
- Introduce a pool of 4 verifiers in FlowObjectiveManager to
separate the thread used for the installation/removal of the
FlowObjectives
- Improves logging in verifyGroup
Change-Id: I45aac0f80c9eb6afd763f21977d62df4a98f686e
Additionally adds a cleanUp method for the pipeliners
to reset the internal states between different executions.
This was another regression introduced by 23223.
Fixes also a memory leak caused by re-init of the grouphandler
without terminating its internal references
Change-Id: I06e9e005110c5237cb3bdf893cc71975fb94281e
- Introduced a new method to indicate whether the pipeliner is ready to receive objectives or not
- Ensure init() in OfDpa2Pipeline and OvsOfdpaPipeline can only be invoked once
This is to avoid processing duplicated DEVICE_ADDED events introduced by gerrit 18899
Change-Id: Icb08935cb1f2761d7c98b5086fc27b6a0d8bc0cf
This will happen after the installation of the group
that punts the packets to the controller (0xc0000000).
Prevents hosts being learned with the assigned vlan.
Change-Id: I46d880309c75430ebbb76f289b371955dd68af2d
Verify fails without firing the callback:
- objective is not removed from the queue till is expiration
- InOrderFlowObjectiveManger can remain in stalled state
Change-Id: I9922c8498100a5af3e0d7ce2f39e080ba4c90b14
In OVS, for example, the following conntrack action is possible:
ct(commit,zone=44,exec(load:0x5->NXM_NX_CT_MARK[])
The Nicira 'load' action here is nested inside the NiciraCt action.
Change-Id: Ia1e681d2a43d9696ce9f1e8c05eae90322961dbb
Make sure packet in still happens even when filtering obj is absent.
VLAN assignment won't happen in this case,
meaning that whatever VLAN a packet carries is the original VLAN and therefore should be persisted.
Change-Id: Ia005abe6354ad4008f88e7378ba4c06bc6b80c81
- when double tagged filtering objective an inner vlan criteria is submitted
- update to ofdpa and ovsofdpa drivers to evaluate the inner vlan criteria correctly
Change-Id: I33170c9b83482a5f26f13f7098a9b24a92da9544
criteria to EAPOL trap flows.
* Adding purgeOnDisconnect property to MeterManager
* DeviceListener implementation on MeterManager
* Adding purgeMeter(DeviceId deviceId) method to MeterStore
* Calling the above method when DEVICE_AVAILABILITY_CHANGE is received
* Adding vlanId match criteria to EAPOL trap flows (OltPipeline change)
Change-Id: Ibb254302efe94edf1fd596f74a6eef6587410475
(cherry picked from commit 91b38543d822a0d9d092f9b3ff7760b1a206226a)
When we want to create a meter, MeterManager & DefaultMeter.Builder gives the following error:
java.lang.IllegalArgumentException: Must specify a cell id.
at com.google.common.base.Preconditions.checkArgument(Preconditions.java:134)
at org.onosproject.net.meter.DefaultMeter$Builder.build(DefaultMeter.java:241)
at org.onosproject.net.meter.DefaultMeter$Builder.build(DefaultMeter.java:184)
at org.onosproject.net.meter.impl.MeterManager.submit(MeterManager.java:204)
It seems that MeterManager still uses meter id instead of meter cell id. It must be changed with the proper value.
Change-Id: I623746b38af1148ca7f33efe5e48d6590a11051a
Note: Cord OLT application must create meters for the technology profile implementation and it uses 1.13.1 version.
Also fix confusing comments and variable names
Note: suppress line number checkstyle for Ofdpa2GroupHandler
Change-Id: I00e56b679da1247a7c0ffba838c9df329ab54f11
In addition,
- Update processVersatile to handle more selectors in ovs-ofdpa
This also fixes the issue of XConnect ACL flow not being programmed correctly
- Refactor the code a bit to reduce duplication
Change-Id: I190aad904d3e6625ff9f089c74e3b98077bbe4a3
