To build a packet, as an ARP reply you must go through the controller. Using a proactive approach means "just" use rules and actions as in normal reactive way, preinstalling them on the switches.
Cheers, Luca P. Il giorno 29/mar/2013, alle ore 12:12, Arnaud M <arnau...@gmail.com> ha scritto: > is that possible to reply to arp request without the help of the controller > (that send a packet out )? > > Le 7 mars 2013 17:11, "Arnaud M" <arnau...@gmail.com> a écrit : >> >> Thanks you Rob, >> >> I'm not totally out of my confusing stage but I think I'm on the right way. >> >> So an intelligence is needed somewhere... >> Else in the controller that react to packet-in by sending packet-out and/or >> flow-mod... >> Else in an orchestrator tool that is aware of changes and pro actively push >> flows >> >> >> >> >> 2013/3/6 Rob Sherwood <rob.sherw...@bigswitch.com> >>> I think you may be confusing the time scales for "proactive" and >>> "reactive". Most people use them to mean "before or after the first >>> packet in a flow", but if you want to, for example, upon seeing an ARP >>> from host X, proactively install flow rules that match all possible >>> traffic to host X, then this is a fairly viable strategy. >>> Additionally, if your hosts are VMs and you're using an orchestration >>> system, you don't even necessarily have to wait for an ARP as the >>> orchestration system will tell you where the hosts are located, so in >>> this case, you're "reacting" to host moves in the orchestration >>> system. >>> >>> Hope this helps, >>> >>> - Rob >>> . >>> >>> On Wed, Mar 6, 2013 at 6:44 AM, Arnaud M <arnau...@gmail.com> wrote: >>> > Helle everyone, >>> > >>> > I was wondering which features could offers an openflow device managed >>> > only >>> > with proactive flow.. It seems to be very limited if the device is not >>> > hybrid, am I right ? >>> > >>> > For example we can forget layer 2 switching without reactive flow (or make >>> > it static..) >>> > >>> > Maybe the "only proactive flow management" could be useful in hybrid >>> > device >>> > because if no flow is ok, we can go to normal process (that would assume >>> > switching and other stuff..) >>> > >>> > Any idea ? >>> > >>> > _______________________________________________ >>> > openflow-discuss mailing list >>> > openflow-discuss@lists.stanford.edu >>> > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>> > > _______________________________________________ > openflow-discuss mailing list > openflow-discuss@lists.stanford.edu > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
_______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
