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 d
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
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,
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 wrote:
> If you're concerned/confused abo
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 s
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 wild
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.*.
On Fri, Jan 27, 2012 at 04:18:27PM +0530, edward wilson wrote:
> 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"
The OpenFlow spec doesn't say anything about command line interface
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
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
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_pack
11 matches
Mail list logo
