[GBP-22] Source condition group gets aliased when implementing SFC with multiple acitons Created: 01/Apr/15  Updated: 15/May/15  Due: 06/May/15  Resolved: 15/May/15

Status: Resolved
Project: groupbasedpolicy
Component/s: General
Affects Version/s: unspecified
Fix Version/s: None

Type: Bug
Reporter: Thomas Bachman Assignee: Keith Burns
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Blocks
blocks GBP-18 Conditions do not work correctly - es... Resolved
External issue ID: 2934
Priority: High

 Description   

The current implementation of policy enforcement in the OpenFlow Overlay renderer for GBP only supports "allow" for action, and completely classifies and enforces the policy at the originating node. If the packet is sent across a tunnel, the receiving node adds a flag of 0xFFFFFF into the source condition group Nicira register to indicate that the packet was received from another node, and therefore already had its policy (allow) applied. This allows the packet to avoid reclassification against the original "allow" action on the destination node, and therefore the packet can simply be delivered to the destination port on the vSwitch.

Users get to define the order that actions take place, using the order field in the action references. This means that the "allow" action can happen before another action (e.g. "QoS marking"), and therefore means that the remaining policy must be enforced on the receiving node (perhaps a better example is chain – you could theoretically allow the QoS marking to be enforced on the originating node when allows is the first action, but you probably wouldn't want QoS marking to happen until it reaches the destination node when doing a chain action). However, since all packets received via the overlay tunnel port are marked with a source condition group of 0xFFFFFF, there is now ambiguity, which means you can't create a match that only selects based on the source condition group (i.e. any EPG sending traffic to that node gets the source condition group marked as 0xFFFFFF). In order to properly support distributed policy enforcement, some alternate means of marking must be used (e.g. per-source condition group mapping).



 Comments   
Comment by Keith Burns [ 01/Apr/15 ]

EP Conditions will be fixed by Deadline above

Comment by Keith Burns [ 02/May/15 ]

This can be fixed by latest pattern of mEPG+networkContainment tunnelID ordinal.

Source EP conditions can be reflected at the remote end by adding the source EP conditions to the tunnelID ordinal.

Generated at Wed Feb 07 20:00:56 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.