Hi, I am using Open vSwitch in my setup yes.
So I will try to use the resubmit action in the next live bucket as you mentioned. Although I'm not sure that it's implemented in the controller that I am using (Ryu)... I will investigate it further. Thanks for your help. Best, Clément On 19 February 2015 at 15:17, Eder Leão Fernandes < ederleaofernan...@gmail.com> wrote: > Hi, > > On Thu Feb 19 2015 at 11:12:13 AM Clément Rault <rault.clem...@gmail.com> > wrote: > >> Hi, >> >> Ok, so you're saying that the group actions are processed right at the >> end, after processing all the flow tables, right? >> >> No, a group action - or any other action - from an apply action > instruction is executed just after the flow match. Only actions written to > the action set (write action instruction), are executed after processing > all tables. > > >> What do you mean by group chaining? I don't think it's possible to link >> to another group entry inside a group entry. >> > > Group chaining is a group that allows group buckets to have group actions. > I.e, from one group, it is possible to send the packet to another group. I > do not know if your switch supports it (Open vSwitch, from my knowledge > does not support it, for example) > > >> >> The problem is that it's also not possible to use Goto Table in a group >> entry since it's an instruction and not an action. >> >> One possible solution to send the packet back to the pipeline is the Open > vSwitch resubmit action. > Please refer to this thread: > http://openvswitch.org/pipermail/discuss/2014-August/014807.html > > Looks like the patch was accepted. > > https://github.com/openvswitch/ovs/blob/18080541d2768c17c17711c35b4d4a23ab3e4153/lib/ofp-actions.c#L4883 > > So, if you are using OVS, instead of using the metadata field, try to add > a resubmit action to the next live bucket, sending the packet to the next > table. Following your example: > > > > > > *Table 0:Apply Gr 0 actionsGr 0:bucket 1 : If port 1 is up then forward > the packet there* > *bucket 2: resubmit packet to table 1* > > > > > > *Table 1:Apply Gr 1 actionsGr 1:If port 2 is up then forward the packet > there* > > Best Regards, > Eder. > > >> Best, >> Clément >> >> On 18 February 2015 at 20:27, Eder Leão Fernandes < >> ederleaofernan...@gmail.com> wrote: >> >>> True, >>> >>> metadata is an instruction, so you cannot add it to the group bucket >>> action set. >>> >>> The problem is not the group order of execution. If you had specified >>> the write metadata instruction, it would have been executed after the apply >>> action instruction. >>> Another reason for your setup failure is the fact that a group action >>> inside an apply actions will process a copy of the packet, just like when >>> you have an output action inside this instruction type. So the pipeline >>> keeps processing the packet in the state before the group action. >>> >>> What you need to figure is how will you signalize the failure. Does your >>> switch supports group chaining? After the first bucket of the failover >>> group, a second bucket could point for another group, with the actions you >>> need to apply and the output for the failover port. >>> >>> Best Regards, >>> Eder, >>> >>> >>> >>> >>> On Wed Feb 18 2015 at 2:31:10 PM Clément Rault <rault.clem...@gmail.com> >>> wrote: >>> >>>> Hi, >>>> >>>> Thanks for your answer Eder. >>>> >>>> I need two fast failover groups (and even more in my complete setup) >>>> because I wanna do some others actions in the bucket and it wouldn't work >>>> with only one group. >>>> >>>> The software switch I'm using does support fast failover groups (the >>>> example you gave is working for example). >>>> >>>> But I think that I found why my example is not working. And it's >>>> because setting the metadata field in a group is not possible because it's >>>> an instruction and only actions can be used in groups. >>>> >>>> Do you have an idea about that? >>>> >>>> Do you think that it has to do with the fact that group entries >>>> actions are processed almost right at the end and that's why it's not >>>> possible to go back to flow tables after that? Therefore setting the >>>> metadata in the group entries is not possible. >>>> >>>> Best, >>>> Clément >>>> >>>> On 17 February 2015 at 23:00, Eder Leão Fernandes < >>>> ederleaofernan...@gmail.com> wrote: >>>> >>>>> Hi Clément, >>>>> >>>>> Your setup does not seem wrong. My question is why do you need two >>>>> fast failover groups? Is it not better just to add a second bucket to Gr >>>>> 0? >>>>> >>>>> With fast failover groups you could set the first bucket watch_port to >>>>> the port 1. If port 1 is down, the group will try to execute the second >>>>> bucket, which has the action to forward for port 2. >>>>> >>>>> Another thing to check is if the software switch you are using with >>>>> mininet supports fast failover groups. >>>>> >>>>> Best Regards, >>>>> Eder. >>>>> >>>>> >>>>> On Tue, Feb 17, 2015 at 12:33 PM, Clément Rault < >>>>> rault.clem...@gmail.com> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> >>>>>> I am currently trying to implement an algorithm allowing an >>>>>> alternative path to be found without the need to contact the controller. >>>>>> And for that I need to use group entries of the fast failover type. In my >>>>>> algorithm, I'm using action buckets of multiple group entries on a single >>>>>> packet and I'm wondering if it's possible in practice (with OpenFlow) *as >>>>>> group entries actions are processed almost right at the end and it might >>>>>> not be possible to go back to flow tables after that*. >>>>>> >>>>>> >>>>>> For example I have the following (simple) *scenario*: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *Table 0:Apply Gr 0 actions, Goto Table 1Gr 0:If port 1 is up then >>>>>> forward the packet there, put metadata to 1Table 1:If metadata is at 0 >>>>>> then >>>>>> Apply Gr 1 actionsGr 1:If port 2 is up then forward the packet there* >>>>>> >>>>>> >>>>>> I tried it (with mininet and ryu) but it didn't work and I'm worried >>>>>> that it's because it's not possible to apply the actions of multiple >>>>>> group >>>>>> entries. And probably because group entries actions are processed after >>>>>> going through all the flow tables. >>>>>> >>>>>> >>>>>> I would really appreciate, if anyone can kindly help me to >>>>>> understand, *if the following scenario is not working because of a >>>>>> design "issue" of Openflow or because it's an implementation issue (with >>>>>> ryu in my case)*. >>>>>> >>>>>> >>>>>> Thanks in advance, >>>>>> >>>>>> Best, >>>>>> Clément >>>>>> >>>>>> _______________________________________________ >>>>>> openflow-discuss mailing list >>>>>> openflow-discuss@lists.stanford.edu >>>>>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Eder Leão Fernandes >>>>> >>>>> MSc Candidate >>>>> Faculdade de Engenharia Elétrica e Computação >>>>> Universidade de Campinas >>>>> >>>> >>>> >>
_______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
