The ONOS does not process the incoming LLDP packet from switches.
The ONOS only process LLDP packets if LLDP packet has "ONOS Discovery" optional TLV.
So, this changes process incoming LLDP packet from switch and make a link information and onos can utilize it.
Also, this patch changes the requested appId of DefaultForwardingObjective generated by PacketManager.
So, AppId in result of flows cli will be printed to actual requested appId.
ONOS-7748
Change-Id: I2611b34655bec2369b8817ce0cd29fb2edbed845
Current LLDP/BDDP-based Topology Detection is vulnerable to the
creation of fake links via forged, modified, or replayed LLDP packets.
This patch fixes this vulnerability by authenticating LLDP/BDDP packets
using a Message Authentication Code and adding a timestamp to prevent
replay. We use HMAC with SHA-256 has our Messge Authentication Code and
derive the key from the config/cluster.json file via the
ClusterMetadata class.
Change-Id: I01dd6edc5cffd6dfe274bcdb97189f2661a6c4f1
This patch solves the PENDING_UPDATE and PENDING_ADD_RETRY issue
observed on the ONS EU topology.
The P4Runtime action profile group handling has been re-implemented to
be robust against inconsistencies of the device mirror, which is now
periodically synchronized with the device state. Similarly, we implement
a routine in the P4RuntimeClient to cleanup unused action profile
members.
This patch includes also:
- Refactor PI handle classes to allow creating handles without the
entity instance
- Use list instead of collections in P4RuntimeClient methods, as order
of updates sent and/or entities received from the device is important
Change-Id: I2e7964ce90f43d66680131b47ab52aca32ab55d2
needed to support rebooting ONOS nodes
Change-Id: I44d34c649750ffc3d6b0205ee02c8c88391f1f8a
(cherry picked from commit ccee77a024c14c3cef68457028ea71edc0555f54)
- eliminated annotations in a few remaining abstract component classes
- cleaned up gui/gui2 feature bundle lists
- added version to the karaf features patch
- loading onos-rest by default in karaf features patch
- onos-gui loading still WIP
Change-Id: Ie5a74c0daee939a9d2de30e1737e4f88dd2ae478
The request roleforSync call handles the request.
The store selects a role and this in turn issues a
handleMastershipEvent call that deals with applying the request
Adapting NETCONF device provider to mark online only after session establishment.
Change-Id: Id16937ced3af31b5b65bc6e5b0794557cf900a57
Also reduces default pipeconf watchdog probe interval
Also fixes NPE on GDP when device is unreachable
Change-Id: Ie2fe1874b0883a037596d9a555a2f8cc030a55a6
(cherry picked from commit d797e2c28505fbdbb8597038ebcf977a053bae72)
This patch is an attempt to solve issues observed when restarting both
switches and ONOS nodes. Most of the issues seemed to depend on a
brittle mastership handling when deploying the pipeline.
With this patch, GDP registers devices to the core with available=false
(i.e. offline) and marks them online only when the P4 pipeline has been
deployed to the device. A new PiPipeconfWatchdogService takes care of
deploying pipelines and producing event when devices are ready.
Moreover, we fix a race condition where pipeconf-related behaviors
were not found. This was caused by GDP enforcing the merged
driver name in the network config, while external entities (e.g.
Mininet) were pushing a JSON blob with the base driver name. This patch
removes the need to rely on such a trick and instead uses
pipeconf-aware logic directly in the driver manager (change #19622).
Finally, we fix issues in P4RuntimeClientImpl that were causing the
stream channel not detecting unreachable devices. The solution is to
follow gRPC APIs and re-instantiate a new channel once the first fails.
Change-Id: I6fbc91859c0fb58a6db3bc197b7081a8fe9f97f7
Refactoring aims at providing a more robust connection procedure of
P4Runtime-based devices.
Refactoring requires devices to be registered to the core with
available=false (i.e. offline), and marked online only when the P4
pipeline has been deployed to the device. Also, it leaves the duty of
handling pipeconf-specific drivers to the driver subsystem, instead of
having the GeneralDeviceProvider take care of it, which resulted to be
brittle.
Changes include:
- Choose not to mark device online when re-asserting mastership role by
declaring special device annotation.
- Lookup drivers in device projectable model unsing driver service
device-based method, which is consistent with the way other subsystems
look for device drivers.
- In DriverManager, when looking for device drivers, consider the case
of pipeconf-programmable devices, in which case a special "merged"
driver needs to instantiated at runtime.
- In PacketManager, push flow objectives only if device is available
(i.e. after pipeline has been deployed).
Change-Id: I80f78a4f40730a06cb82fa55fefab08a91a89268
