On Oct 13, 2010, at 10:12 AM, Dave Scott wrote: >> Hi, Dave. You are correct that the controller "owns" all the rules on >> the switch. (Technically, there are exceptions to this, but that's a >> road I wouldn't recommend going down.) It is up to the >> controller/application to decide how to handle existing flows, but all >> the ones I know of wipe the existing flows on OpenFlow connection >> establishment. (It's kind of a nightmare to debug a controller app >> otherwise.) > > Thanks for the clarification-- I'll avoid digging into the exceptions > (emergency mode rules?) :)
The biggest user of these hidden rules is in-band control, which creates flows that ensure the switch can communicate with a controller, regardless of the flows that are configured by a user or controller. >> Would a proxy, generic port forwarding application, or IP tables rules >> work for you? I would think any of those would do the job you want and >> not interfere with any OpenFlow controllers. (Unless, of course, it's >> specifically dropping those flows, which is probably a configuration >> problem anyway.) > > I did a few experiments and it looks like iptables and NAT will do what I > want. I'll assign dom0 and the helper domains link-local 169.254.* addresses > on a private network and then use a DNAT iptables rule to readdress traffic > heading to a port on the dom0 management ip. No additional openflow hackery > needed [a pity because I was looking forward to playing with it more :)] Fantastic. I'm glad you got it working. If you want to dig into this stuff more, I've got a few items on our to-do list that I could forward your way. ;-) --Justin _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss_openvswitch.org
