On Thu, Oct 12, 2017 at 12:23 PM, Vincent Jahjah <[email protected] > wrote:
> Hello ODLers, > > > I have been using OpenFlowPlugin a bit, and I have been noticing strange > behavior regarding the rules I've been installing in the newer version of > my code. > > > I have been successfully installing flows with ArbitraryBitMask on ipv4 > addresses, but I have found that some such specific flows were causing > errors in openflowplugin. > > > Here is the code relevant to the error: > > > https://pastebin.com/yJDZesXU > > > Here are the errors I get every time I install a rule that walks through > these lines: > > > https://pastebin.com/c9HYLBt6 > > Explaination: I may or may not know the IP of the flows. If I do not know > the IP of the flows, I put an "any" kind of mask that is scattered across > the least significant n bits of the unknown ip addresses. > > > If the IP address is known, typically, I will not set a mask, and I will > put the known address instead. This may lead to having the "set" the fields > twice, overwriting the previous values... but the resulting values always > seem clean. Last attempt, I printed the contents of my matcher, and got the > following: > > > (first flow installed: the known address was injected, which caused an > error) > > SRC: Ipv4Address [_value=10.99.99.1] DEST: Ipv4Address [_value=0.0.0.0] > SRCM:DottedQuad [_value=255.255.255.255] DESTM: DottedQuad [_value=0.0.0.3] > ​Can you please start a wireshark on the controller side and monitor the OpenFlow message between controller and switch? I suspect in the above case switch might be throwing some error saying invalid match. As per https://tools.ietf.org/html/rfc5735 0.0.0.0/8 addresses are used for source address only. I think wireshark will give you more information on what's happening at the switch level. The exception in pastebin is basically a deserialization exception , it means it was not able to parse the ipv4 destination address that came from the switch. So again, we need to have a look at the wireshark trace to see what's happening here. > > (second flow installed: I purposefully commented the lines that would set > the destination, resulting in null destination fields. This did not cause > any errors. I know this from experiment, although it was not obvious with > this experiment alone.) > SRC: Ipv4Address [_value=0.0.0.0] DEST: null > SRCM:DottedQuad [_value=0.0.0.3] DESTM: null > > > Interestingly, if I invert the values, I still get an error, and still an > error concerning the destination. > > The flows that don't fail are installed correctly, as they are shown by > "ovs-ofctl dump-flows". > > > ... My question is... what's wrong here? Obviously, "10.99.99.1" and > "255.255.255.255" are valid Ipv4Addresses and DottedQuads. They are by no > means "malformed". > > > Why would the flow fail to install? What is malformed? > > > Vincent > > _______________________________________________ > openflowplugin-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > > -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
