Hi Edward, I think I found the culprit here... Correct me if I'm wrong but you're reading this doc... right?
This spec for openflow defines how tools like openvswitch should work "under the hood". It doesn't say that that's how we as consumers of the tool should interact with it. What if they decided to use binary or hex notation for IP Addresses and Subnet masks? Does that mean that we need to use that with openvswitch too? I b e n http://www.openflow.org/documents/openflow-spec-v1.0.0.pdf On page 21 we find this text I've copied here: 5.2.3 Flow Match Structures When describing a flow entry, the following structure is used: /* IP source address wildcard bit count. 0 is exact match, 1 ignores the * LSB, 2 ignores the 2 least-significant bits, ..., 32 and higher wildcard * the entire field. This is the *opposite* of the usual convention where * e.g. /24 indicates that 8 bits (not 24 bits) are wildcarded. */ OFPFW_NW_SRC_SHIFT = 8, OFPFW_NW_SRC_BITS = 6, OFPFW_NW_SRC_MASK = ((1 << OFPFW_NW_SRC_BITS) - 1) << OFPFW_NW_SRC_SHIFT, OFPFW_NW_SRC_ALL = 32 << OFPFW_NW_SRC_SHIFT, /* IP destination address wildcard bit count. Same format as source. */ OFPFW_NW_DST_SHIFT = 14, OFPFW_NW_DST_BITS = 6, OFPFW_NW_DST_MASK = ((1 << OFPFW_NW_DST_BITS) - 1) << OFPFW_NW_DST_SHIFT, OFPFW_NW_DST_ALL = 32 << OFPFW_NW_DST_SHIFT, OFPFW_DL_VLAN_PCP = 1 << 20, /* VLAN priority. */ OFPFW_NW_TOS = 1 << 21, /* IP ToS (DSCP field, 6 bits). */ /* Wildcard all fields. */ OFPFW_ALL = ((1 << 22) - 1) ; If no wildcards are set, then the ofp_match exactly describes a flow, over the entire OpenFlow 12-tuple. On the other extreme, if all the wildcard flags are set, then every flow will match. The source and destination netmasks are each specified with a 6-bit number in the wildcard description. It is interpreted similar to the CIDR suffx, 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-signi cant 24-bits are wild, so it forms a netmask of "255.0.0.0". I b e n +14087824726 Skype: ibenrodriguez On Mon, Jan 30, 2012 at 11:33 PM, edward wilson <edward.wilson2...@gmail.com> 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 <iben.rodrig...@gmail.com> > 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 >> <edward.wilson2...@gmail.com> 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 <jpet...@nicira.com> >> > 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 >> >> > discuss@openvswitch.org >> >> > http://openvswitch.org/mailman/listinfo/discuss >> >> >> > >> > >> > _______________________________________________ >> > discuss mailing list >> > discuss@openvswitch.org >> > http://openvswitch.org/mailman/listinfo/discuss >> > > > _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
