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
