Just to be more precise, I have host1------switch1------switch2-----host2 and on both switches I have
ofdatapath --detach punix:/var/run/dp0 -d <mac_switch> -i br-lan ofprotocol unix:/var/run/dp0 tcp:10.92.0.100:6633 --fail=closed Thanks a lot! waiting forward for some ideas, regards, diana On Sat, Jun 2, 2012 at 1:33 PM, Diana Marosin <marosin.di...@gmail.com>wrote: > Hello, > > I tried to set in ofprotocol the argument: "--fail=closed" , but nothing > has changed in the behavior of the switch. (I checked the list of arguments > that you can pass to ofprotocol using "--help arguments" and tryed to set > the max_backoff and the no-spt and the result was the same. > > Also I tried to set as system variable OFP_OPTIONS="--fail=closed" and > this dosen't work neither. > > I was expecting that packets in to be directly droped. > > Any ideas what is going on? > > Thanks a lot! > diana > > On Thu, May 31, 2012 at 10:50 AM, Aaron Rosen <aro...@clemson.edu> wrote: > >> I believe when your switch connects to NOX , NOX sends a flow_mod to >> delete whatever's in your flow_table so I don't think your solution would >> work unless you installed a permanent flow right before you disconnected >> your controller. That said I'm not sure what the behavior of this >> particular switch is when it loses it's connection. It might kick right >> into a learning switch.... >> >> I think what you want to do is to modify whatever calls ofdatapath and >> add the option instructing it to fail closed. >> >> Aaron >> >> >> >> >> On Thu, May 31, 2012 at 4:38 AM, Diana Marosin >> <marosin.di...@gmail.com>wrote: >> >>> Thank you Aaron, >>> >>> I would like in the beginning to set my switch to do nothing, meaning >>> not to forward any traffic if I don't have the controller started or flows >>> installed. >>> >>> Then I would like to use NOX and set some flows or set them directly >>> with dpctl. Now, if I use a flag OFP_FLOW_PERMANENT dose it mean the flow >>> is installed after I close the controller? (this is how I would expect it >>> to be) >>> >>> Making the switch "fail closed" is a setting of the switch or of the >>> openflow protocol? >>> >>> Thanks again for the reply! >>> Best, >>> Diana >>> >>> >>> On Thu, May 31, 2012 at 10:16 AM, Aaron Rosen <aro...@clemson.edu>wrote: >>> >>>> That means that the switch fails open aka will act as a normal L2 >>>> learning switch if it loses its connection with the controller. >>>> >>>> From the 1.0 spec -- NORMAL: Process the packet using the traditional >>>> forwarding path >>>> supported by the switch (i.e., traditional L2, VLAN, and L3 processing.) >>>> The switch may check the VLAN ld to determine whether or not to >>>> forward the packet along the normal processing route. If the switch can- >>>> not forward entries for the OpenFlow-speci c VLAN back to the normal >>>> processing route, it must indicate that it does not support this action. >>>> >>>> >>>> What do you mean by dumb? There should be a way to make it fail closed, >>>> meaning that it will no longer forward traffic automatically when it loses >>>> it's connection to the controller. This is particularly important if you >>>> have loops in the openflow segment of a network. >>>> >>>> Aaron >>>> >>>> On Thu, May 31, 2012 at 2:54 AM, Diana Marosin <marosin.di...@gmail.com >>>> > wrote: >>>> >>>>> Hello all, >>>>> >>>>> I've been using a bit of Mininet and you know that when just creating >>>>> a network and trying to ping for example this dosen't work, Than you start >>>>> the controller and miracle happens. On the other hand on real devices >>>>> (Linksys and TP-link with openwrt and openflow 1.0) this is not the case. >>>>> >>>>> Dose any of you know what is the *default* behavior? I guess it is >>>>> broadcasting. And also, how I could stop it? >>>>> can I install flows to drop packets? >>>>> is there any configuration file that makes my switch totally dum?, >>>>> on TP-LINK it seams I have a flow table without using the controller, >>>>> and it has actions=LOCAL, what dose it mean? >>>>> >>>>> Thank you a lot! >>>>> Diana >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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
