On Oct 9, 2013, at 12:46 PM, Maciej Korczyński <[email protected]> wrote:
> Hi Murphy, > > Thank you very much for your mail. > > 2013/10/3 Murphy McCauley <[email protected]> > It looks like maybe your POX isn't running the latest version of the carp > branch. Can you switch to carp if necessary and pull the latest version and > try again? I've pushed a change to openflow.discovery. > > > I tried both beta and carp versions as you suggested but in both cases it > gives me the same errors as described in one of my previous mails. Are you running the *latest* carp? (Have you pulled from the repository?) > Btw, just to inform, in carp, I can't run openflow.spanning_tree with > --no-flood --hold-down options. What do you mean by "can't"? Do you get errors? Log messages? I don't seem to have a problem with: ./pox.py openflow.spanning_tree --no-flood --hold-down openflow.discovery forwarding.l2_pairs > If you can think of any further details that I could provide you, please let > me know. The last question on the FAQ is full of ideas: http://www.noxrepo.org/pox/manual > A more general question: has anyone tried topologies with loops in Mininet > and POX with more that 10 switches and it actually worked? I'm doing it with 20 switches (two hosts each) in a full mesh this very moment using the commandline above (also tested with l2_learning). > Thanks again, > Maciej > > > -- Murphy > > On Oct 1, 2013, at 3:13 PM, Maciej Korczyński <[email protected]> > wrote: > >> 2013/10/1 Murphy McCauley <[email protected]> >> I've CCed this to pox-dev, which is the right list for POX related messages. >> >> >> Thank you very much. >> >> But the first thing I'd try is: >> >> ./pox.py forwarding.l2_pairs openflow.discovery --eat-early-packets >> openflow.spanning_tree --no-flood --hold-down >> >> >> I tried it straight away but unfortunately it gives the same results. >> >> Thanks, >> Maciej >> >> >> >> -- Murphy >> >> On Oct 1, 2013, at 2:32 PM, Maciej Korczyński <[email protected]> >> wrote: >> >>> Hello, >>> I'm trying to run a spanning tree in POX (./pox.py forwarding.l2_learning >>> openflow.discovery openflow.spanning_tree --no-flood --hold-down). I've >>> built a mininet network composed of 20 switches in a full mesh with >>> multiple hosts attached to each of switches and I get the following error >>> (also see the attachment): >>> ERROR:openflow.of_01:[00-00-00-00-00-14 11] OpenFlow Error: >>> [00-00-00-00-00-14 11] Error: header: >>> [00-00-00-00-00-14 11] Error: version: 1 >>> [00-00-00-00-00-14 11] Error: type: 1 (OFPT_ERROR) >>> [00-00-00-00-00-14 11] Error: length: 36 >>> [00-00-00-00-00-14 11] Error: xid: 6220717 >>> [00-00-00-00-00-14 11] Error: type: OFPET_BAD_REQUEST (1) >>> [00-00-00-00-00-14 11] Error: code: OFPBRC_BUFFER_UNKNOWN (8) >>> [00-00-00-00-00-14 11] Error: datalen: 24 >>> [00-00-00-00-00-14 11] Error: 0000: 01 0d 00 18 00 5e eb ad 00 01 88 7f 00 >>> 09 00 08 .....^.......... >>> [00-00-00-00-00-14 11] Error: 0010: 00 00 00 08 ff fb 00 00 >>> ........ >>> ERROR:openflow.of_01:[00-00-00-00-00-14 11] OpenFlow Error: >>> [00-00-00-00-00-14 11] Error: header: >>> [00-00-00-00-00-14 11] Error: version: 1 >>> [00-00-00-00-00-14 11] Error: type: 1 (OFPT_ERROR) >>> [00-00-00-00-00-14 11] Error: length: 36 >>> [00-00-00-00-00-14 11] Error: xid: 6220718 >>> [00-00-00-00-00-14 11] Error: type: OFPET_BAD_REQUEST (1) >>> [00-00-00-00-00-14 11] Error: code: OFPBRC_BUFFER_UNKNOWN (8) >>> [00-00-00-00-00-14 11] Error: datalen: 24 >>> [00-00-00-00-00-14 11] Error: 0000: 01 0d 00 18 00 5e eb ae 00 01 88 80 00 >>> 09 00 08 .....^.......... >>> [00-00-00-00-00-14 11] Error: 0010: 00 00 00 08 ff fb 00 00 >>> ........ >>> ^CDEBUG:openflow.spanning_tree:Spanning tree updated >>> >>> I believe it might be a problem with an algorithm because when construct >>> networks composed of e.g. 7 switches in a full mesh there are no errors and >>> the communication works fine. Also, if I construct a network with loops but >>> less links (e.g. 20 switches, not in a full mesh topology but every switch >>> is connected to 50% other switches) then it works better. >>> >>> >>> >>> Could you please have a look and tell me if you had similar problems and >>> some ideas on how to fix that? >>> Also, if I'm right and it's an algorithmic problem then do we have any >>> other alternative solution to openflow.spanning_tree or we are limited in >>> our simulations to tree or star network topologies? >>> >>> Thanks, >>> Maciek >>> <log.png> >> >> > >
