Fwiw, I would argue that the ovs-ofctl does the right thing which is "make it easier for a human" and the OF spec (arguably?) does the right thing of "make it easier for a machine". The original poster seems to be making an assumption that these two encoding should be the same, and I'm with Justin in pushing back on this assumption.
- Rob . On Tue, Jan 31, 2012 at 1:10 AM, Justin Pettit <[email protected]> wrote: > I've seen nothing that indicates there's a problem. I'm sorry you're > confused about the difference between what's on the wire and what's being > displayed to the user. I don't know how else to convince you that it's > working properly, so I'm going to stop. > > --Justin > > > On Jan 31, 2012, at 1:00 AM, edward wilson wrote: > >> hi, >> >> if use the metric /24 then ovs-ofctl dump-flows shows me nw_src=10.2.3.*, >> that means internally also it is treated as cidr mask, >> because as per openflow spec dump-flows output should be nw_src=10.*.*.* >> >> On Tue, Jan 31, 2012 at 1:27 PM, Justin Pettit <[email protected]> wrote: >> If you're concerned/confused about what's going on the wire, please fire up >> wireshark and take a look. You're giving human-readable ovs-ofctl commands >> on the command-line, which it is translating into OpenFlow commands on the >> wire. We think CIDR masks are more intuitive to deal with than the strange >> encoding OpenFlow uses (which we originally defined, by the way). If you >> put /24 on the CLI, it will go out on the wire with the OpenFlow encoding >> that you're expecting. >> >> --Justin >> >> >> On Jan 30, 2012, at 11:33 PM, edward wilson wrote: >> >> > hi >> > yes as per openvswitch we should use the metric /24 for the mask >> > 255.255.255.0 to cover IPv4 >> > 10.1.3.0 to 10.1.3.255 for a wildcard of 10.1.3.*." >> > >> > but in openflow 1.0 spec following is written >> > >> > The source and destination netmasks for IP addresses are each specified >> > with a 6-bit number >> > in the wildcard description. It is interpreted similar to the CIDR suffix, >> > but >> > with the opposite meaning, since this is being used to indicate which bits >> > in the >> > IP address should be treated as “wild”. For example, a CIDR suffix of ”24” >> > means to use a netmask of “255.255.255.0”. However, a wildcard mask value >> > of >> > “24” means that the least-significant 24-bits are wild, so it forms a >> > netmask of >> > “255.0.0.0”. >> > >> > so openflow 1.0 spec say /24 means 255.0.0.0 but in openvswitch it means >> > 255.255.255.0 >> > >> > regards >> > >> > >> > >> > On Fri, Jan 27, 2012 at 9:53 PM, Iben Rodriguez <[email protected]> >> > wrote: >> > Hi Ed, >> > >> > What do you mean wildcarded? is that like a * ? This might be a semantics >> > issue. >> > >> > Could you be confusing metric with significant bits of a mask...? >> > >> > /8 is a metric that would use the mask 255.0.0.0 to cover IPv4 >> > addresses from 10.0.0.0 to 10.255.255.255 - that might mean a wildcard >> > of 10.*.*.* >> > >> > You should use the metric /24 for the mask 255.255.255.0 to cover IPv4 >> > 10.1.3.0 to 10.1.3.255 for a wildcard of 10.1.3.*. >> > >> > >> > I b e n >> > +14087824726 >> > Skype: ibenrodriguez >> > >> > >> > >> > On Fri, Jan 27, 2012 at 2:48 AM, edward wilson >> > <[email protected]> wrote: >> > > >> > > hi, >> > > >> > > Actually the issue is according to openflow 1.0 spec when i use >> > > ovs-ofctl add-flows br0 "dl_type=0x0800 nw_proto=1 nw_dst=10.0.3.4 >> > > nw_src=10.1.3.2/8 actions=1" >> > > >> > > ovs-dump-flows br0 should give follwing output >> > > >> > > cookie=0x0, duration=21.265s, table=0, n_packets=0, n_bytes=0, >> > > icmp,nw_src=10.0.3.4,nw_dst=10.1.3.0/8 actions=output:1 >> > > >> > > that is the least significant 8 bits should be wildcarded. >> > > >> > > But in openvswitch the ovs-dump-flows br0 give me following output >> > > >> > > cookie=0x0, duration=21.265s, table=0, n_packets=0, n_bytes=0, >> > > icmp,nw_src=10.0.3.4,nw_dst=10.0.0.0/8 actions=output:1 >> > > >> > > this means least significant 24 bits are wildcarded. >> > > >> > > In openvswitch code it is shown that CIDR masks are supported for IP >> > > address, which is not openflow 1.0 compliant. >> > > >> > > I get the same result when i look at output of ovs-ofctl specking >> > > openflow. >> > > >> > > >> > > On Fri, Jan 27, 2012 at 3:21 PM, Justin Pettit <[email protected]> >> > > wrote: >> > >> >> > >> I don't think there's a problem. I'd guess if you looked at the output >> > >> of >> > >> ovs-ofctl speaking OpenFlow, you'd see the mask as defined in the spec. >> > >> However, we've made the user interface more intuitive to users, so it >> > >> uses >> > >> normal CIDR masks. >> > >> >> > >> --Justin >> > >> >> > >> >> > >> On Jan 27, 2012, at 1:11 AM, edward wilson wrote: >> > >> >> > >> > HI, >> > >> > I am using openvswitch 1.2.2 on my linux 2.6.38 fedora machine. >> > >> > I added following flow on switch >> > >> > >> > >> > ovs-ofctl add-flows br0 "dl_type=0x0800 nw_proto=1 nw_dst=10.0.3.4 >> > >> > nw_src=10.1.3.2/8 actions=1" >> > >> > >> > >> > Now when i use ovs-ofctl dump-flows br1, it shows >> > >> > >> > >> > cookie=0x0, duration=3.855s, table=0, n_packets=0, n_bytes=0, >> > >> > icmp,nw_dst=10.0.3.4,nw_src=10.0.0.0/8 actions=NORMAL >> > >> > >> > >> > >> > >> > Now openvswitch interpret this wildcard mask as CIDR suffix, and it >> > >> > has >> > >> > wildcarded 24 least significant bits, first 8 bits are non-wildcard >> > >> > But as per openflow 1.0 spec wildcard mask is interpreted as CIDR >> > >> > suffix >> > >> > with opposite meaning , i.e suffix of 8 should wildcard least >> > >> > significant 8 >> > >> > bits of ip address. >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > >> > discuss mailing list >> > >> > [email protected] >> > >> > http://openvswitch.org/mailman/listinfo/discuss >> > >> >> > > >> > > >> > > _______________________________________________ >> > > discuss mailing list >> > > [email protected] >> > > http://openvswitch.org/mailman/listinfo/discuss >> > > >> > >> >> > > _______________________________________________ > discuss mailing list > [email protected] > http://openvswitch.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
