Hi, I imagined that the steps were like you mentioned... well,
Firstly, s3 send packet_in to c0, and another moment s2 send packet_in to s3that send to c0... Well, as you mentioned earlier, I need to set initial flow entries, that is, I think that is the flow from s2 to s3 ,.. one time initiated the topology, like the linear topology, the initial flow entries should be installed, I think.. so that initial flow entries must be configured in the topology script? or maybe from CLI via dpctl? thank you, On Thu, Oct 20, 2011 at 11:31, Kyriakos Zarifis <kyr.zari...@gmail.com>wrote: > Yes, that is possible. This is where in-band vs out-of-band control comes > to play: If the physical topology looks exactly like what you described then > control of sw1 can only been done in-band (meaning, the control packets are > using the same links as the data packets). In order for that to be possible, > there need to be some initial flow entries in the intermediate switches to > allow a remote switch to connect to the controller. I don't think there is a > standardized way to set up in-band control, but I am guessing a simple > version would be something like: > > - s3 connects to c0 - the controller receives packet_in from s3, which originated in s2 while it > tried to connect > - c0 sets a flow on s3 that allows traffic from s2 to reach it > - at this point s2 and s3 are connected to the controller > - sw2 picks up packet from s1 and sends packet_in to c0 > > OpenvSwitch has a pretty sophisticated approach to in-band control. If > you're interested you can take a look here : > > http://openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=DESIGN > (look for "in-band") > > On Thu, Oct 20, 2011 at 5:39 AM, scolfield <kscolfi...@gmail.com> wrote: > >> Hi, >> >> Thanks for your reply. >> It's possible openflow messages across several switches until achieve the >> controller? >> Such as host -> sw1 -> sw2 -> sw3 -> c0 or in a reverse way in linear >> topology? >> Consider that the host packet need to achieve a server connected to sw3and >> there are only >> one controller linked to one switch. >> >> -- >> scolf >> >> >> On Thu, Oct 20, 2011 at 06:32, Kyriakos Zarifis <kyr.zari...@gmail.com>wrote: >> >>> Hi, >>> >>> pyswitch itself is really not aware of any topology. It only stores state >>> that is relevant to switches separately (i.e. it stores a mapping of mac >>> addresses to local ports for a switch). >>> >>> Now, whether a control packet (like a packet_in) will reach the >>> controller if it's not directly physically connected to it is another issue, >>> and is irrelevant to what NOX application (eg pyswitch) is running. Switches >>> are connected to the controller through a separate control channel, so as >>> long as this channel has been established (which is when the switch first >>> connects to NOX), then the packet_ins will find their way to NOX through >>> that (irrespective of dataplane connectivity, which is established by NOX >>> applications) >>> >>> (another thing to consider is whether the switch-controller connection is >>> in-bound/out-of-bound) >>> >>> Does this make sense? >>> >>> On Wed, Oct 19, 2011 at 5:20 PM, scolfield <kscolfi...@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> The pyswitch example can learn topology of networks? Such as a >>>> corporation architecture when >>>> there are hierarchical switches interconnected one to another creating >>>> several "layers" of switches, >>>> at this case, the one openflow controller connected to two distinct >>>> switches, can learn which ports >>>> to send a ping packets, for example? The packet in messages will be >>>> forwarded automatically through >>>> switches until reach a controller? >>>> >>>> -- >>>> scolfield >>>> >>>> _______________________________________________ >>>> nox-dev mailing list >>>> nox-dev@noxrepo.org >>>> http://noxrepo.org/mailman/listinfo/nox-dev >>>> >>>> >>> >> >
_______________________________________________ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
