Hi Jen-Wei, this spanning tree implementation does not come with NOX - you'd have to install it separately following the instructions on that page if you want to try it out
On Fri, Nov 19, 2010 at 12:44 AM, Jen-Wei Hu <jenwe...@gmail.com> wrote: > 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
