[SFC-199] When server and last SF are in different computes, things don't work Created: 31/Aug/17  Updated: 30/May/18  Resolved: 30/May/18

Status: Resolved
Project: sfc
Component/s: General
Affects Version/s: unspecified
Fix Version/s: Oxygen

Type: Bug
Reporter: Manuel Buil Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


External issue ID: 9083

 Description   

The packet goes back to the compute where it got encapsulated and then hits table=0, table=36 and table=51, where it apparently does not hit any table



 Comments   
Comment by Jaime CaamaƱo Ruiz [ 31/Aug/17 ]

Well, the problem is that the packet should be redirected to the classifier pipeline from table 36 to handle the final egress.

This table 36 is managed by genius with what is called terminating service actions, which redirects traffic incoming from tunnel ports to the proper application pipeline based on VNI value. The problem for this being that, for egress, we are reusing the same VNI that SFC uses, 0, and that SFC might have a terminating service action there too, and that the Genius API does not allow to coordinate priorities through terminating service actions with the same VNI.

So two options would be:

  • to manually register a flow on table 36, with higher priority that whatever might be there from SFC. And then on the classifier pipeline, if the packet is not at chain egress, redirect it to the SFC pipeline. Quite feasible.
  • to use a different VNI for egress. SFC most likely needs to be aware of this VNI. And it would be difficult to reserve a VNI value for specific use other than 0 given that netvirt might be using any other possible value. At least there is no reservation procedure in place that I am aware.
Generated at Wed Feb 07 20:38:53 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.