- reentrant lock was not being used correctly
- fixHashGroup in group handler was not updating global store correctly
- linkUp was not being noted in seenLinks if configuration came after switches connected
- serialization error in global objective store due to missing kryo for Sets
- damaged routepath computation was not taking pair-devs into account
- switch failures were leading to improper ecmpSpg graph updates, and missed hash-group changes
- implemented more next-objective verification as group sub-system can go out-of-sync with objective-store
Change-Id: If3cfdd715e9b69820894b49def31f75ceb748863
Two things:
- In dual (paired) ToR scenarios it is possible to have the same outport
in multiple buckets in a hash group, as long as they have different labels.
When adding buckets this was taken into account. But when removing buckets,
only outport was being checked. This bug fix ensures that labels are checked
as well when removing buckets.
- In dual ToR scenarios, getting the right set of hash buckets proved difficult
with existing 'retryHash' mechanism. Repealed and replaced with a bucket corrector
mechanism that periodically corrects the hash group buckets when the topology
has been stable for the last 10 secs. Required the introduction of a VERIFY
operation in Next Objectives. Also added a cli command to trigger this
operation manually.
Change-Id: Ib0d2734060fadc6e7a4bd0d75f3409e194413a97
Introduces the concept of edge-pairs (or paired-ToRs) which
can have some subnets/prefixes reachable by both ToRs.
- Each ToR can also have prefixes reachable only by itself,
even though it is part of an edge-pair.
- The paired link between ToRs in an edge-pair is ignored
for ECMP calculations.
- Required a change in how destinations and next-hops are stored.
The neighborSet is now a destinationSet, and no longer carries
next-hop info, which is now stored in NextNeighbors. As a result,
the DestinationSetNextObjectiveStoreKey and ECMP group id do not
change as next-hops come and go.
- It is now possible to have buckets in hash groups with the same
outport but different labels.
- DefaultRoutingHandler has been rearraged to be more readable, and
clearly highlight the three major ways that routing changes can
happen in the network.
Also fixes the case where config is added after switches connect to the controller.
Change-Id: I7ce93ab201f6ef2c01cbe07a51ee78cd6a0a112e
Piggybacked in this commit:
- Fix CLI output of driver properties
- Fix mfr matching pattern in onos-drivers.xml
- Add driver support for Accton OFDPA 3
Change-Id: Ia350bd52f4e88e53565ff491d68bce5e4894bbb9
Also removing some old demo code in the SR app
Adding a couple of CLI commands for debugging
Bug fix in the DistributedGroupStore for group_exists error message
Bug fixes for ofdpa driver:
- synchronized update of flowObjectiveStore when buckets are added to or removed from groups
to avoid one thread from overwriting an update from another thread doing an update at the same time
- addBucketToL2FloodGroup now updates flowObjectiveStore after accounting for changes
- addBucketToHashGroup accounts for all added buckets, not just the first one
Change-Id: I6207c1c3c1b4379986805d73a73bc460fea8fe3f
Reasons makes Intent stuck in WITHDRAWING state:
1. The patch for CORD-1180 caused next objective queued in the objective
system if there is no next group for that next objective.
2. Default single table pipeline removes next group from flow objective
store when removing forwarding objective.
3. The flow objective Intent installer will remove forwarding objective
first, then remove next objective.
4. The flow objective Intent install will wait until all objective context
completed, however, according to reason 1, 2 and 3, the next objective
will be queued forever since there will be no next group in the store. So
the Intent state will stuck in WITHDRAWING until the Intent manager retry.
To fix this issue, we need to modify default single table pipeline, make it
not remove next group when removing forwarding objective.
Change-Id: Ia51a3361f19b60332ca1a276583cdfc036d93343
Next-objectives that edited groups are now queued in the FlowObjectiveManager instead of the driver.
During linkup immediately checking for previous portups that should be added to a hash group.
A final retry 30 secs later to catch all ports that should be part of the same hash group.
Change-Id: I7ef450149d685890ca47932b8e559a0c11dc5ab4
Create package "ofdpa" under pipeline package
Move helper functions and classes to OfdpaGroupHandlerUtility
Change-Id: I47e42f2c8afc9088ed684cd6a087233a82c452f6