https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/SFC-199 sfc <p>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</p> <p>Operating System: All<br/> Platform: All</p> SFC-199

When server and last SF are in different computes, things don't work

Bug Resolved Done Unassigned Manuel Buil Thu, 31 Aug 2017 14:18:49 +0000 Wed, 30 May 2018 06:35:03 +0000 Wed, 30 May 2018 06:35:03 +0000 unspecified Oxygen General 0 1 <p>Well, the problem is that the packet should be redirected to the classifier pipeline from table 36 to handle the final egress.</p> <p>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.</p> <p>So two options would be:</p> <ul> <li>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.</li> </ul> <ul> <li>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.</li> </ul> Development External issue ID 9083 External issue URL Rank 0|i02fnz: