Hi David.
[...]
> Are these all direct links from the controller to each switch?
Yes.
> Is there anyway to specify
> which switch the controller can connect to?
Well... I can imagine two ways right now. But should be another(s) way(s)....
1) Create a component that imports LearningSwitch class from
forwarding.l2_learning module and associate the vswitch datapath
to 'LearningSwitch' object from this module. Here
a code snipet of the module:
def _handle_ConnectionUp (self, event):
log.debug("Connection %s" % (event.connection,))
LearningSwitch(event.connection, self.transparent)
So, to control a given vswitch (represented by event.connection
object) 'LearningSwitch' class is called. What you have to do is
choose which vswitch (datapath, in OF terms ) would instantiate
LearningSwitch objects. Others vswitches would be controlled by your
code.
2) The second way is not using high level API in mininet (AKA. command
line arguments) and use a mid level API. You can then create a
topology and associate each switch to any controller. Here comes
examples:
https://github.com/mininet/mininet/blob/master/examples/controllers2.py
https://github.com/mininet/mininet/wiki/FAQ#multiple-controllers
--
Att
Lucas Brasilino
MSc Student @ Federal University of Pernambuco (UFPE) / Brazil
twitter: @lucas_brasilino
>
> The command lines are like:
>
> sudo mn --topo tree,depth=2,fanout=2 --mac --switch ovsk --controller remote
>
> and
>
> ./pox.py log.level --DEBUG l2_learning
>
>
> output:
>
> POX 0.2.0 (carp) / Copyright 2011-2013 James McCauley, et al.
> DEBUG:core:POX 0.2.0 (carp) going up...
> DEBUG:core:Running on CPython (2.7.6/Mar 22 2014 22:59:56)
> DEBUG:core:Platform is Linux-3.13.0-24-generic-x86_64-with-Ubuntu-14.04-trusty
> INFO:core:POX 0.2.0 (carp) is up.
> DEBUG:openflow.of_01:Listening on 0.0.0.0:6633
> INFO:openflow.of_01:[00-00-00-00-00-03 3] connected
> DEBUG:.home.mininet.pox-controller.l2_learning_dc:Connection
> [00-00-00-00-00-03 3]
> INFO:openflow.of_01:[00-00-00-00-00-02 1] connected
> DEBUG:.home.mininet.pox-controller.l2_learning_dc:Connection
> [00-00-00-00-00-02 1]
> INFO:openflow.of_01:[00-00-00-00-00-01 2] connected
> DEBUG:.home.mininet.pox-controller.l2_learning_dc:Connection
> [00-00-00-00-00-01 2]
>
>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 5 May 2015 09:43:23 -0300
>> From: Lucas Brasilino <lr...@cin.ufpe.br>
>> To: Ayush Dusia <adu...@udel.edu>
>> Cc: pox-dev <pox-dev@lists.noxrepo.org>
>> Subject: Re: [pox-dev] Install actions to indirectly connected
>> switches
>> Message-ID:
>> <cage5s_cwye8-etsfn7akr_roqnb67c_3yozyqnypxzll9wu...@mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> HI Ayush
>>
>>> I am under an impression that in real scenarios with complex typologies, not
>>> all switches have direct connection to a controller. And, they are connect
>>> to a controller through other switches (which become OpenFlow 'proxy', like
>>> S1 in our example). So, I am trying to connect to S2 through S1.
>>
>> You are right. But, those 'other switches' traditionally aren't OF
>> switches. They are
>> 'ordinary switches' (I mean, learning switches) creating a 'management
>> network'.
>> This is the topology frequently seen (at least by myself).
>> So, if you are using 'learning switches' on top layer they wouldn't be a
>> 'proxy' because your layer 3 connection is direct from controller to
>> bottom layer
>> switches through the ' top switches'. Top switches are simply
>> switching layer 2 frames
>> from controller to bottom switches, they do not know that these frames
>> are OF messages.
>> You can make top switches 'learning switches' by controlling them with the
>> 'forwarding.l2_learning' Pox's component.
>> In order words, top switches' control plane would be the same (or similar) to
>> 'commercial available' learning switches.
>>
>>> My main goal is to have hierarchy in data plane, where the top layer of
>>> switches is just used for communication between controller and bottom layer;
>>> whereas, the bottom layer of switches is used to connect to the hosts and
>>> other network components.
>>>
>>> Is this feasible with POX and mininet?
>>
>> Sure it is! Just make top switches be controlled by
>> 'forwarding.l2_learning' component and bottom
>> switches be controlled by your component.
>>
>> --
>> Att
>> Lucas Brasilino
>> MSc Student @ Federal University of Pernambuco (UFPE) / Brazil
>> twitter: @lucas_brasilino
>>
>>>
>>> On Thu, Apr 23, 2015 at 9:21 PM, Lucas Brasilino <lr...@cin.ufpe.br> wrote:
>>>>
>>>> Hi Ayush:
>>>>
>>>> > I have installed a permanent rule in S1 to forward the packets to S2
>>>> > that have destination address of S2.
>>>>
>>>> Forwarding at L2, right ? Or are you doing some kind of NAT ?
>>>>
>>>> > Topology: C0 - S1 - S2
>>>> > Now, when I want to install rules in S2, how should I go about it?
>>>> >
>>>> > 1) Should I create a ofp_packet_out with destination of S2, attached
>>>> > ofp_flow_mod packet (rules for S2) as data to it and send it to S1?
>>>> >
>>>> > 2) Should I create a ofp_flow_mod packet which has destination address
>>>> > of S2 and send it to S1?
>>>>
>>>> Assuming S1 are forwarding at L2, S1 will not be an OpenFlow 'proxy'
>>>> for S2. You just need to make S2 connect to C0's IP address. For
>>>> instance. if S2 is an Open vSwitch, you just do:
>>>>
>>>> $ sudo ovs-vsctl set-controller s2 tcp:192.168.56.1:6633
>>>>
>>>> Where 192.168.56.1 is the controller's IP address.
>>>>
>>>> --
>>>> Att
>>>> Lucas Brasilino
>>>> MSc Student @ Federal University of Pernambuco (UFPE) / Brazil
>>>> twitter: @lucas_brasilino
>>>>
>>>> > On Wed, Apr 22, 2015 at 8:19 AM, Lucas Brasilino <lr...@cin.ufpe.br>
>>>> > wrote:
>>>> >>
>>>> >> Hi Ayush,
>>>> >>
>>>> >> Since controller connects to switch using a TCP session, if S1 acts
>>>> >> like a learning switch or already has rules on its flow table
>>>> >> allowing TCP connections from C0 to S2, C0 will control S2.
>>>> >>
>>>> >> Just be aware that if S1 is an OF switch and those rules mentioned
>>>> >> above expires, you will lost control over S2, even for a while.
>>>> >> What I mean is that until you restore S1 rules, some
>>>> >> switch-to-controller messages like 'Packet In', 'Port Status',
>>>> >> 'FlowRemoved'
>>>> >> and
>>>> >> so forth can be lost, leading for a network's state mismatch.
>>>> >>
>>>> >> --
>>>> >> Att
>>>> >> Lucas Brasilino
>>>> >> MSc Student @ Federal University of Pernambuco (UFPE) / Brazil
>>>> >> twitter: @lucas_brasilino
>>>> >>
>>>> >>
>>>> >>
>>>> >> 2015-04-22 0:10 GMT-03:00 Ayush Dusia <adu...@udel.edu>:
>>>> >>
>>>> >>> Hello Everyone,
>>>> >>>
>>>> >>> I have a question regarding installation of actions in switches.
>>>> >>>
>>>> >>> If I assume that a controller does not have direct connections to all
>>>> >>> the switches in a network. In that case how can a controller install
>>>> >>> actions
>>>> >>> in a switch to which it is not directly connected?
>>>> >>>
>>>> >>> e.g. for a topology like: C0 - S1 - S2
>>>> >>>
>>>> >>> How can C0 install actions in S2 through S1?
>>>> >>>
>>>> >>> Thanks,
>>>> >>> Ayush
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>
>>>
>>
>>
