Ben, 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. Niko On Thu, Jul 7, 2016 at 12:00 AM, Ben Pfaff <b...@ovn.org> wrote: > It sounds like there are two problems here. > > First, I guess that if your controller is not sending the new field, > that's a controller issue. > > Second, I don't understand what effect you expect modifying struct flow > to have. struct flow never appears in a "raw" format in OpenFlow. It's > always translated into some other form. Whether you put it into former > pad bytes or anywhere else, just adding it to struct flow will have no > effect by itself. > > On Wed, Jul 06, 2016 at 01:08:26PM -0400, Nikolai Snow wrote: > > Ben, > > Thank you for pointing me in the right direction. > > > > I have now fixed the problem on the Floodlight controller side. Now > > everything compiles and I can run Mininet and ping the hosts with > > Floodlight as the controller, the functionality looks good. However when > I > > am looking in the Wireshark output of the Openflow packets generated by > > Mininet, I am not able to see my new label (SNOW). > > > > To recall, I am replacing padding area following ofp_port_t > actset_output. > > One theory might be my field is not showing up because the padding was > not > > used in constructing the openflow packets I am looking at in wireshark. > > > > I appreciate your thoughts and input in resolving this issue. > > > > Thanks again, > > Niko > > > > On Tue, Jul 5, 2016 at 11:17 AM, Ben Pfaff <b...@ovn.org> wrote: > > > > > As I said before, it looks like your modified OVS sends a new field to > > > the controller and that your controller does not understand that field > > > and reports an error. If so, you will have to fix that in the > > > controller. > > > > > > On Tue, Jul 05, 2016 at 10:23:52AM -0400, Nikolai Snow wrote: > > > > Thank you for your response Ben. > > > > > > > > As suggested I made the following modifications, my attribute in > > > > meta-flow.h now has a value for OXM: OXM_OF_SNOW(777) since OF1.3 and > > > v2.4. > > > > I am not very sure about the type in question "777" for OXM_SNOW > field. > > > > > > > > After making the modification, compilation went smoothly but the same > > > error > > > > persisted when connecting mininet to floodlight : > > > > > > > > org.projectfloodlight.openflow.exceptions.OFParseError: Unknown > value for > > > > discriminator typeLen of class OFOxmVer13: 83458 > > > > > > > > > > > > > > > > Am I missing anything else? > > > > > > > > Thanks, > > > > Niko > > > > > > > > On Fri, Jul 1, 2016 at 8:37 PM, Ben Pfaff <b...@ovn.org> wrote: > > > > > > > > > On Thu, Jun 30, 2016 at 04:07:57PM -0400, Nikolai Snow wrote: > > > > > > Hello, > > > > > > > > > > > > Sorry about the initial message, it was truncated accidentally > before > > > > > > sending. I am trying to introduce new attributes in the Openflow > > > header. > > > > > I > > > > > > am implementing this between Open VSwitch and Floodlight. As a > test > > > I am > > > > > > inserting a new attribute in the padding of the header. > > > > > > > > > > > > This is an excerpt from open vswitch's flow.h > > > > > > > > > > > > ofp_port_t actset_output; /* Output port in action set. */ > > > > > > uint16_t SNOW; // new test variable replacing > pad*** > > > > > > > > > > > > //uint8_t pad2[2]; /* Pad to 64 bits. */ > > > > > > > > > > > > /* L2, Order the same as in the Ethernet header! (64-bit > > > aligned) */ > > > > > > struct eth_addr dl_dst; /* Ethernet destination address. > */ > > > > > > > > > > > > I followed the guide on the Open VSwitch github on how to > introduce > > > a new > > > > > > attribute and have also modified /lib/flow.c, /lib/meta-flow.h, > > > > > > /lib/meta-flow.c, /lib/nx-match.c. > > > > > > > > > > > > Excerpt from meta-flow.h > > > > > > > > > > > > /* "SNOW". > > > > > > > > > > > > * > > > > > > > > > > > > * new testing attribute. > > > > > > > > > > > > * > > > > > > > > > > > > * Type: be16. > > > > > > > > > > > > * Maskable: no. > > > > > > > > > > > > * Formatting: hexadecimal. > > > > > > > > > > > > * Prerequisites: none. > > > > > > > > > > > > * Access: read/write. > > > > > > > > > > > > * NXM: none. > > > > > > > > > > > > * OXM: none. > > > > > > > > > > > > */ > > > > > > MFF_SNOW, > > > > > > > > > > > > I can provide the other excerpts of edited OVS source if needed. > My > > > code > > > > > > compiles, and I can run mininet using this custom OVS and test > pings > > > can > > > > > be > > > > > > sent and received successfully. I run mininet the arguments > --switch > > > > > > ovsk,protocol=OpenFlow14. When I try to connect this mininet to > > > > > floodlight, > > > > > > there are errors generated in floodlight's commandline. > > > > > > > > > > > > Here is the terminal output starting at connection of the switch > > > until > > > > > > close, truncated because it repeats itself until the mininet > > > connection > > > > > is > > > > > > terminated. > > > > > > > > > > > > 15:28:02.342 INFO [n.f.c.i.OFChannelHandler: > nioEventLoopGroup-3-2] > > > New > > > > > > switch connection from /192.168.56.101:46228 > > > > > > 15:28:02.343 INFO [n.f.c.i.OFChannelHandler: > nioEventLoopGroup-3-2] > > > > > > Negotiated down to switch OpenFlow version of OF_13 for / > > > > > > 192.168.56.101:46228 using lesser hello header algorithm. > > > > > > 15:28:02.396 INFO > > > > > [n.f.c.i.OFSwitchHandshakeHandler:nioEventLoopGroup-3-2] > > > > > > Switch OFSwitch DPID[00:00:00:00:00:00:00:01] bound to class > class > > > > > > net.floodlightcontroller.core.internal.OFSwitch, description > > > > > > SwitchDescription [manufacturerDescription=Nicira, Inc., > > > > > > hardwareDescription=Open vSwitch, softwareDescription=2.5.0, > > > > > > serialNumber=None, datapathDescription=None] > > > > > > 15:28:02.535 INFO > > > > > [n.f.c.i.OFSwitchHandshakeHandler:nioEventLoopGroup-3-2] > > > > > > Defining switch role from config file: ROLE_MASTER > > > > > > 15:28:02.562 WARN [n.f.c.i.C.s.notification:main] Switch > > > > > > 00:00:00:00:00:00:00:01 connected. > > > > > > 15:28:03.033 ERROR [n.f.c.i.OFChannelHandler: > nioEventLoopGroup-3-2] > > > Error > > > > > > while processing message from switch > [00:00:00:00:00:00:00:01(0x0) > > > from > > > > > > 192.168.56.101:46228]state > > > > > > > > > > > > > > net.floodlightcontroller.core.internal.OFChannelHandler$ > CompleteState@217a252e > > > > > > io.netty.handler.codec.DecoderException: > > > > > > org.projectfloodlight.openflow.exceptions.OFParseError: Unknown > > > value for > > > > > > discriminator typeLen of class OFOxmVer13: 83458 > > > > > > at > > > > > > > > > > > > > > io.netty.handler.codec.ByteToMessageDecoder.callDecode( > ByteToMessageDecoder.java:358) > > > > > > ~[floodlight.jar:na] > > > > > > at > > > > > > > > > > > > > > io.netty.handler.codec.ByteToMessageDecoder.channelRead( > ByteToMessageDecoder.java:230) > > > > > > ~[floodlight.jar:na] > > > > > > at > > > > > > > > > > > > > > io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead( > AbstractChannelHandlerContext.java:308) > > > > > > [floodlight.jar:na] > > > > > > at > > > > > > > > > > > > > > io.netty.channel.AbstractChannelHandlerContext.fireChannelRead( > AbstractChannelHandlerContext.java:294) > > > > > > [floodlight.jar:na] > > > > > > at > > > > > > > > > > > > > > io.netty.channel.DefaultChannelPipeline.fireChannelRead( > DefaultChannelPipeline.java:846) > > > > > > [floodlight.jar:na] > > > > > > at > > > > > > > > > > > > > > io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read( > AbstractNioByteChannel.java:131) > > > > > > [floodlight.jar:na] > > > > > > at > > > > > > > > > > > > > > io.netty.channel.nio.NioEventLoop.processSelectedKey( > NioEventLoop.java:511) > > > > > > [floodlight.jar:na] > > > > > > at > > > > > > > > > > > > > > io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized( > NioEventLoop.java:468) > > > > > > [floodlight.jar:na] > > > > > > at > > > > > > > > > > > > > > io.netty.channel.nio.NioEventLoop.processSelectedKeys( > NioEventLoop.java:382) > > > > > > [floodlight.jar:na] > > > > > > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) > > > > > > [floodlight.jar:na] > > > > > > at > > > > > > > > > > > > > > io.netty.util.concurrent.SingleThreadEventExecutor$2. > run(SingleThreadEventExecutor.java:112) > > > > > > [floodlight.jar:na] > > > > > > at > > > > > > > > > > > > > > io.netty.util.concurrent.DefaultThreadFactory$ > DefaultRunnableDecorator.run(DefaultThreadFactory.java:137) > > > > > > [floodlight.jar:na] > > > > > > at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91] > > > > > > Caused by: org.projectfloodlight.openflow.exceptions. > OFParseError: > > > > > Unknown > > > > > > value for discriminator typeLen of class OFOxmVer13: 83458 > > > > > > at > > > > > > > > > > > > > > org.projectfloodlight.openflow.protocol.ver13. > OFOxmVer13$Reader.readFrom(OFOxmVer13.java:442) > > > > > > ~[floodlight.jar:na] > > > > > > ... 22 common frames omitted > > > > > > 15:28:03.040 WARN [n.f.c.i.C.s.notification:main] Switch > > > > > > 00:00:00:00:00:00:00:01 disconnected. > > > > > > 15:28:03.040 INFO [n.f.c.i.OFChannelHandler: > nioEventLoopGroup-3-2] > > > > > > [[00:00:00:00:00:00:00:01(0x0) from 192.168.56.101:46228]] > > > Disconnected > > > > > > connection > > > > > > 15:28:03.344 INFO [n.f.c.i.OFChannelHandler: > nioEventLoopGroup-3-1] > > > New > > > > > > switch connection from /192.168.56.101:46230 > > > > > > > > > > > > I have attached a .pcapng dumped from wireshark of the session. > Can > > > > > anybody > > > > > > help me understand what I am doing wrong? Thanks in advance. > > > > > > > > > > It looks like your modified OVS sends a new field to the > controller and > > > > > that your controller does not understand that field and reports an > > > > > error. > > > > > > > > > > If you're sending a new field to the controller, though, you > should put > > > > > that in the NXM: or OXM: declaration in meta-flow.h instead of > saying > > > > > "none". > > > > > > > > >
_______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
