Manuel, About the first problem, I'll have to check, but I think we need to consider the metadata in the match, and the metadata in the action. Notice the match "metadata=0x10000000000/0xffffff0000000000" has the value 1 as expected, since this particular flow is for SFC and goes to table 83 which is the SFC SFF. The metadata set in the action is most likely for the next service after SFC. So, in this flow the packet will be sent to SFC, who will process it and when/if it gets resubmit back to table 17, the next service to be invoked will be L3VPN as indicated by "write_metadata:0x8000010000000000/0xfffffffffffffffe" in the SFC flow in table 17.
About the second problem, it sounds like the packets arent classified correctly. That is, if this flow gets hit: table=83, n_packets=338, n_bytes=37768, priority=5 actions=drop And these 2 are not hit: table=83, n_packets=0, n_bytes=0, priority=250,nsp=11 actions=goto_table:86 table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388619 actions=goto_table:86 Then the packets dont have NSH and the packets get encapsulated with NSH by the classifier. Regards, Brady -----Original Message----- From: Manuel Buil <[email protected]<mailto:manuel%20buil%20%[email protected]%3e>> To: [email protected] <[email protected]<mailto:%[email protected]%22%20%[email protected]%3e>> Cc: Kency Kurian <[email protected]<mailto:kency%20kurian%20%[email protected]%3e>>, Faseela K <[email protected]<mailto:faseela%20k%20%[email protected]%3e>> Subject: [sfc-dev] Two potential bugs in Carbon SFC? Date: Thu, 20 Apr 2017 15:13:46 +0200 Hey guys, I am using a build from Monday and I found two things which might be wrong. Before adding them to bugzilla, I wanted to check with you. ### Number 1 ### @Faseela, Kency here you might help :) When creating the RSP this flow is created in table=17 of the SFF: table=17, n_packets=6, n_bytes=252, priority=10,metadata=0x10000000000/0xffffff0000000000 actions=write_metadata:0x8000010000000000/0xfffffffffffffffe,goto_table:83 As far as I understood, the first 4 bits of the metadata should point to the id of the service and here it points to id = 8 which according to this file in genius: https://git.opendaylight.org/gerrit/gitweb?p=genius.git;a=blob;f=mdsalutil/mdsalutil-api/src/main/java/org/opendaylight/genius/mdsalutil/NwConstants.java;h=9b2a2a94283684c8e56a9a53df32b48d878dd83a;hb=refs/heads/master id = 8 ==> L3VPN_SERVICE_INDEX It should be SFC_SERVICE_INDEX = 1; right? ### Number 2 ### After creating the RSP all my packets are dropped at table=83: table=83, n_packets=0, n_bytes=0, priority=250,nsp=11 actions=goto_table:86 table=83, n_packets=0, n_bytes=0, priority=250,nsp=8388619 actions=goto_table:86 table=83, n_packets=338, n_bytes=37768, priority=5 actions=drop Instead of getting dropped, they should go back to table=17 so that they are moved to the next registered service or? For example, pinging with the client to the SFF does not work because of this. Thanks, Manuel _______________________________________________ sfc-dev mailing list [email protected]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/sfc-dev
_______________________________________________ sfc-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/sfc-dev
