flowvisor
flowvisor copied to clipboard
retune FV message blocking/squelching logic
Status: Open Project: Flowvisor Component/s: Core Affects Version/s: 0.7.2 Fix Version/s: Long Term
Type: New Feature Priority: Major Reporter: Nick Bastin Assignee: Rob Sherwood Resolution: Unresolved Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified
Description
Problem:
If a flowspace rule is incomplete, e.g., specifies IP address but not dl_type = IP, then the corresponding drop rule is also incomplete, but switches will either ignore it or ignore the IP bits (possibly broken switch implementation).
Possible solution #1: only block the exact match from the packet, not the entire flowspace rule
Possible solution #2: rewrite all incomplete flowspace rules to being complete
Possible solution #3: reject incomplete FS rules
Comments
Comment by Josh Smift [ 06/Jul/11 ]
It occurs to me that this bug is exacerbating the problems that we're seeing with large numbers of flowspace rules in Expedient-managed FlowVisors, in that this bug is the only reason we have <dl_type> settings in rspecs at all, and things like <dl_type from="2048" to="2054"/> (as a shortcut to catch both IP and ARP) are multiplying the number of rules in Expedient-controlled FlowVisors by a factor of seven.
I like Solution 2, personally: I think that if you match against nw_dst or nw_src, you're implicitly matching against IP or ARP (or any dl_type that matches those fields, I suppose). Whether you write that into the flowspace rules (which seems like it would lead to more flowspace rules again), or deal with it only at drop time (which might make it more CPU-intensive to compute drop rules), I don't have a strong feeling about, although the latter seems simpler to me – if you're about to send a drop rule, just check and sanitize it to make sure it won't block more things than you intend.
In any case, is there any chance this could be prioritized? It would both help with the Expedient flowspace explosion problem, and make rspecs simpler for experimenters.
Comment by Rob Sherwood [ 06/Jul/11 ]
So, I think there are a couple of things being confused here.
When you specify Flowspace via omni with a range, e.g., <dl_type from="2048" to="2054"/>, then it will be expanded out to seven rules by the time it gets to flowvisor (OM does the expansion, IIRC), so in that case, the dl_type is specified and this bug doesn't really apply. Also, for other reasons, we've actually changed to solution 1, and it seems to work pretty well. Was there some concern with that solution?
That said, it is news to me that you're doing the <dl_type from="2048" to="2054"/> expansion instead of just having two rules, one for IP and one for ARP. It seems like you're paying a pretty stiff penalty (7/2 or 3.5x more rules than you need) at the seemingly low benefit of having to type less in the rspec. If this is really the main cause of the flowspace explosion, there are better ways of handling this.
Comment by Josh Smift [ 06/Jul/11 ]
Sorry, my explanation there might not have been very clear.
The only reason we started specifying dl_type in rspecs in the first place was because of this bug: When we left dl_type off, and just included nw_dst, then FlowVisor would send a drop rule for the whole port, which was disastrous for shared ports like on MyPLC plnodes.
So we started adding <dl_type from="2048" to="2048">, to limit the drop rule to only the IP subnet being matched. That just added one line to each of the existing
Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-35