A bug introduced in gerrit 17344
Change-Id: I0a477233d6d1511542fdbace54a7b32bc2db2835
(cherry picked from commit 1e58aa6b3ba501becbca52bf336bc5807f64a1f2)
Multi-stage flows are required in two cases:
- VLAN table: filtering rule need to be installed before assignment rule
- TMAC table: unicacst rule need to be installed before multicast rule (QMX only)
Change-Id: I2cccc42a2c08b00f887b22bad54c7107794beafa
Also in this commit:
- Triggering swap group creation and accounting for it in DestinationSet
- Fixes in ofdpa2 and ofdpa3 pipeline to allow SR Continue operation
- Renaming mplsSet in DestinationSet to notBos
- Removing unused RandomDestinationSet
- Bug fix in ofdpa driver for swap group chain creation
- Bug fix in ofdpa driver for verify group operation
- Better internal bookeeping of device ports and associated neighbors
Change-Id: I2b8f1c4c0b305ef847d57ca7a5320943e06d190d
With this patch we introduce a special vlan for transporting
traffic for leaf-spine pseudowires. Each l-s pw is assigned
a different vlan from the range 4000-2000. This information is
kept internally and exposed to the user with the "pseudowires"
cli command.
Leaf-Leaf pseudowire traffic is still transported untagged, but
we will probably soon need to use special transport vlans there
also.
Change-Id: If6d0b7176a9bd4b89fb7d46db2a49e048bd953ee
Current code does not detect properly a mismatch
between nextobj and flowobjstore. In particular
it is able to detect only missing chains and
duplicated chains, while falls if allactivekeys
has more chains with respect to the next we want
to verify. I think flapping links or subsequent
events (for example several mcast-join follow by
mcast-delete) can create easily this problem.
Imagine we send a next with two treatments
Next(x,y) where x and y are the output ports.
AllActiveKeys has three chains AllActiveKeys(x,y,z)
where x, y and z are the output ports.
existingPortAndLabel is not able to detect the
extraneous chain related to the port z
Change-Id: I41fa47347a8c1d4188d990d96f48a898a4df59e1
Rationale: if we add more than one sink a number
of sink add events are generated. For each event
we create a mcast path, right now we do not support
Mcast group editing. This means that a new nextobjective
will be created for each sink.
In particular, this patch enables the mcast group editing
to solve the following issue:
Sink1 arrives -> fwdObj A -> Next B (this has one output)
Sink2 arrives -> fwdObj A -> Next C (this has two outputs)
Next B and Next C shares a part of the chain. Reordering happens
during the creation of the Nexts:
Next C created -> flow A -> Group C
Next B created -> flow A -> Group B
Failure, traffic does not reach all the sinks. Other side effect is the
disalignment between SR app and flow/group because McastHandler believes
mcast group is associated to the Next C
It includes minor refactoring of the group handler
Change-Id: Ib59ba6b63ff411ed46ca8216677046a78cc92ac6
When introducing the mplsSwap groups, we affected the pseudowire instantiation.
This is now fixed with this patch.
Change-Id: I6f98c49b954017bb0ea899d5ecc15c5a1b8ba340
In this commit:
- a new mechanism in DefaultRoutingHandler to update route-path maps in all instances,
for the entire topology, after every route event has been processesed.
- fixed a race condition in LinkHandler
- avoids retrying flows in the ofdpa3 driver as this issue has been fixed in the switch
- a new CLI command to check internal link state
Change-Id: I307d0a96cc46569294d15d042b3bcb1fde735f1b
Modified the processSimpleNextObjective method to be able to create the
Group chain MPLS Swap - MPLS Interface - L2 Interface , when the MPLS Label
is set to the Treatment.
Change-Id: I72d502ba2f0da811d14d28c170d2e119c3dc8221
Rationale: appkryo returns immutable lists serializable
which do not support removeIf and addAll methods
Change-Id: I25f7f818677d78cad65122f476702f9e194fd620
The rationale for this change is: unhandled exceptions
prevent Runnable to be scheduled in future.
We need to protect the body of runnable.
Related to [CORD-2532] and [CORD-2533].
In the pipeliner we use checkers and groups listener
to get notification about groups. The error scenario:
unhandled exception in the context of a group checker
will kill the checker. We create a multicast group, which
requires firstly a l2interfacegroup. The latter has been
already created in the past. No notification from groups
and no checker -> failure. Multicast group is not created
and forwarding objective in pending (forever).
Potentially, it can fix other errors scenario.
Change-Id: I6ea0548c112002b9ce415103891dc01431bc1dc8
- Added pw support for pseudowires containing leaf and spine switches as endpoints.
- Inject empty pw config if it is not found for the first time
- Minor refactoring such as more log messages and fixing missing javadoc
Change-Id: Ib57d39cfa36fcd48c01b5781c7445a3f1ffcfbda
Changes
- Adds Policer config behavior and its implementation
- Implements id mapping
- Adds tests for OpenFlowPolicerConfig
- Adds free id api to MeterService and MeterStore
- Improves test for MeterStore
Change-Id: Ibb47375430e253131d9d9c8a60e61023ee6c8225
- OFPortDesc cache managed by AbstractOpenFlowSwitch was not always maintained properly.
reorganized data structure to maintain per OFPortDesc, last known instance
Change-Id: I1b26d7ca284e44bf9744c30374394c581653d78f
