As I explained it before, our intent is to create a new label, construct a flow with that label and apply actions on packets matching that label. So far we have succeeded in creating new OF labels and creating flows that can contain our custom labels. We are having issues with executing actions after a match (i.e. setting a field) and we suspect our match logic might not be working.
Our motivation on trying to modify in_port is to see if the matching packets are sent to a different port than their originally intended port. In our case we are redirecting to a port to which another host is listening and hence the ping is redirected if things are working as anticipated. Hence, we check if the packets that are destined for the initial port we are matching on are in fact being sent to the port we are modifying it with our flow's set_field by seeing if the pings all respond appropriately when testing with Mininet and by reading packet captures. We have observed the expected changes with in_port but not with our new label. The new label merely displays the hard coded value of our choosing or the wild carded value of 0 when we attempt to mimic the same code paradigms as other labels in OVS. I might be committing a serious blunder here and your advise is highly appreciated. On Wed, Aug 10, 2016 at 5:54 PM, Ben Pfaff <b...@ovn.org> wrote: > On Wed, Aug 10, 2016 at 10:36:03AM -0400, Nikolai Snow wrote: > > You were correct, the controller was the issue. The field now matches > > between the controller and the switch as we can see values set manually > in > > nx-match.c on the controller when we query for the value. > > > > To address the second issue, we have tried created a flow using ovs-ofctl > > that should match our new field and change the value, but when we send > > packets between the hosts, the value change does not take effect. > > We add the new flow as such, > > > > ovs-ofctl add-flow s1 SNOW=0,actions=set_field:4"->"SNOW > > > > When we dump the flows, it appears. However, when we read a packet > capture, > > the value remains 0. > > We have tested adding flows which change the field in_port and > successfully > > tested this by setting the value to 2 whenever we see it is 1 as such, > > > > ovs-ofctl add-flow s1 in_port=1,actions=set_field:2"->'in_port > > > > The value does in fact get set and whenever a ping is sent to host 1, it > is > > not received. When checking the packet capture, we see the flow added and > > the value of the in_port is changed and host 2 receives more pings. > > When looking through our modifications we found that when hard coding the > > value of our new field in nx-match.c, the value is passed to the network > > and can be seen in captures and on the controller side. > > We suspect that we are missing a portion of the modification that should > > pass the value into the struct flow within the struct match which is > called > > in nx_put_raw. > > Can you please share your thoughts on what the problem is with our > changes? > > Thanks again. > > I guess I don't understand how you'd observe the in_port changing, so I > don't understand what this demonstrates. > > Did you write code to actually modify whatever SNOW is? > > Basically, you're saying, "We modified OVS and there's a bug in our > code. What's the bug?" I don't know how to answer that. >
_______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
