Forwarding this to the list. It has been a while since I was
experimenting with virtual switches but
I think there is a configuration file that you specify the
connections/topology.
I am sure you can figure this out with LLDP messages from your nox
controller, but this seems like
an overkill for this scenario.
--niky
-------- Original Message --------
Subject: Re: [nox-dev] Cycles
Date: Fri, 19 Nov 2010 00:13:06 -0500
From: Rohit Manohar <rdman...@ncsu.edu>
To: Niky Riga <nr...@bbn.com>
References:
<aanlktiku1q4trxybuxk24h2g4l6yjd7_1sxjaoavq...@mail.gmail.com>
<aanlktima_jmehh=sk2rm9as0qq8ykvkw9rpbde1_b...@mail.gmail.com>
<4ce36a27.6030...@bbn.com>
How do I identify which port is connected to which switch? I add
devices as './dpctl addif nl:0 eth0' specifying the port being used
for
connection, but I am not able to figure out which device is at the
other of the link.
On Wed, Nov 17, 2010 at 12:37 AM, 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
--
Rohit Manohar
Graduate Student
North Carolina State University
Raleigh, US.
_______________________________________________
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
