hi ben! seems that exactly this was the problem, even though we didn't explicitly use NORMAL processing, we unnecessarily started the daemon in in-band control mode (which is the default).
while on the first start this didn't seem to cause any problems, after restarts, some hidden flows for ARP-handling which used the NORMAL "port" became effective. after starting it explicitly in --out-of-band mode, restarts worked flawlessly. regarding test-openflowd vs. ovs-vswitchd: we may eventually migrate to ovs-vswitchd but this introduces some new problems related to its configuration via a stand-alone database. I think it does makes sense for remote configuration of not only switch flows but other aspects of the switch configuration (datapaths, ordinary L2/L3 switching, etc) - on full blown servers. We however *embed* openvswitch and would like to control the datapaths via *our own* configuration database. also, we use openvswitch merely as an openflow-enabled switch. integrating another configuration database unnecessarily complicates openvswitch setup and there are also space & memory limitations to consider. I'm sure that many embedded system developers who would like to integrate openvswitch have similar concerns. Perhaps it is also possible to emulate the ovs database (JSON-RPC interface) and perform a kind of on-the-fly schema translation but this is also not very straight-forward and would make us more dependant on ovsdb schema changes. Any thoughts/ideas on that subject? cheers, Robin ----- Original Message ----- > On Tue, Oct 18, 2011 at 12:42:51PM +0200, Andreas Schultz wrote: > > There clearly is something strange going on. How can the dp receive > > something on an unknown port? > > test-openflowd doesn't set up everything necessary for proper > "OFPP_NORMAL" processing, so stuff gets screwed up. > > There's a reason that test-openflowd has "test" in its name and sits > in a directory named "tests". You can guess what it is. > _______________________________________________ > discuss mailing list > discuss@openvswitch.org > http://openvswitch.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
