Hi, Niky Thanks for your detail information. Currently, we also have same confusion. We also find there is a basic spanning-tree on Openflow Wiki ( http://www.openflowswitch.org/wk/index.php/Basic_Spanning_Tree). Is it included into NOX's apps? Does this spanning-tree app do the same thing which you described?
Thanks, Jen-Wei On Wed, Nov 17, 2010 at 1:37 PM, Niky Riga <nr...@bbn.com> wrote: > The problem might be triggered by broadcast packets. > > When the controller receives a packet that has as destination address the > bcast MAC address > (ff:ff:ff:ff:ff:ff), an ARP packet for example, it will send the packet > to the special outport OFPP_FLOOD. > OFPP_FLOOD is translated at the switch to all ports other than the input > port. > > In your topology if End1 sends an ARP request packet then Openflow1 will > send a copy to > Openflow2 and Openflow3, both of which are going to send a copy to > Openflow4. > When Openflow4 receives a packet from Openflow2(3) then it will send a copy > to > End2 and to Openflow3(2) respectively. Openflow2(3) will give the packet > back to > Openflow1 and the loop starts again. > > The correct solution would be to implement a minimum spanning tree on the > topology to disseminate > broadcast packets. An easy way out, which I have used before, is to set the > NO_FLOOD flag in some ports > to break the loop. For example you can choose that Openflow1 will forward > bcast packets only to Openflow2, > and set the NO_FLOOD flag on the port that connects Openflow1 to Openflow3. > This flag will basically > exclude this port when the action specifies as outport the OFPP_FLOOD port. > > Note that if you are using a learning switch module then the loops will > also cause multiple copies of the > same packet to be delivered to the destination even for unicast packets. > This happens because until > the controller learns the mapping between mac addresses and ports, it will > flood packets. > > Hope this helps, > Niky > > > Kyriakos Zarifis wrote: > >> Are you running 'discovery'? If so, the events you see could be the LLDP >> packets sent by that component. >> >> On Tue, Nov 16, 2010 at 5:55 PM, Rohit Manohar <rdman...@ncsu.edu<mailto: >> rdman...@ncsu.edu>> wrote: >> >> I am trying to build the following topology in Nox: >> Openflow2 >> -------- >> -------- >> ---------- >> --------- >> End1 ---------- >> Openflow1 >> Openflow4 ------------ End2 >> --------- >> --------- >> --------- >> --------- >> Openflow3 >> >> When I register Openflow4 with NOX, some sort of traffic loop is >> getting created. NOX is continuously registering packet-in events >> even when I haven't set up any flows. >> Are cycles not supported by NOX? If yes, do I need to indicate it >> in the .conf file? >> >> Regards, >> -- Rohit Manohar >> Graduate Student >> North Carolina State University >> Raleigh, US. >> >> >> _______________________________________________ >> nox-dev mailing list >> nox-dev@noxrepo.org <mailto:nox-dev@noxrepo.org> >> >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> nox-dev mailing list >> nox-dev@noxrepo.org >> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >> >> > > > _______________________________________________ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org >
_______________________________________________ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
