Re: [pox-dev] working with multiple switches
Hello Durga,
What's docs you're reading for deploying VLANs? Could you share it?
Thank you so much
--
Giang Nguyen
Seoul, Korea
On 8 November 2013 15:47, durga wrote:
> Yup! That's it!! That was the issue. below are the macaddr table entries ,
> also I can reach all other hosts.
>
> -
> Thank you so much. :)
>
> DEBUG:l2_switching_v5:3 --> [00:00:00:00:00:03>00:00:00:00:00:01 ARP]
> {EthAddr('00:00:00:00:00:03'): 1, EthAddr('00:00:00:00:00:01'): 2}
> DEBUG:l2_switching_v5:2 --> [00:00:00:00:00:03>00:00:00:00:00:01 ARP]
> {EthAddr('00:00:00:00:00:03'): 3, EthAddr('00:00:00:00:00:01'): 2}
> DEBUG:l2_switching_v5:1 --> [00:00:00:00:00:03>00:00:00:00:00:01 ARP]
> {EthAddr('00:00:00:00:00:03'): 2, EthAddr('00:00:00:00:00:01'): 1}
> DEBUG:l2_switching_v5:1 --> [00:00:00:00:00:01>00:00:00:00:00:03 ARP]
> {EthAddr('00:00:00:00:00:03'): 2, EthAddr('00:00:00:00:00:01'): 1}
> DEBUG:l2_switching_v5:2 --> [00:00:00:00:00:01>00:00:00:00:00:03 ARP]
> {EthAddr('00:00:00:00:00:03'): 3, EthAddr('00:00:00:00:00:01'): 2}
> DEBUG:l2_switching_v5:3 --> [00:00:00:00:00:01>00:00:00:00:00:03 ARP]
> {EthAddr('00:00:00:00:00:03'): 1, EthAddr('00:00:00:00:00:01'): 2}
>
>
> Cheers!
> Durga
>
>
>
> On Fri, Nov 8, 2013 at 5:35 PM, durga wrote:
>
>> I reread the sample program and I am understanding what you meant.
>> As soon as the controller is launched, the _handle_ConnectionUp() handler
>> is calling the L2switch module, thus for every connection established , a
>> different instance of switch is being created
>>
>> Thank you, I will work on these lines.
>>
>>
>>
>> Cheers!
>> Durga
>>
>>
>>
>> On Fri, Nov 8, 2013 at 4:55 PM, Murphy McCauley <
>> murphy.mccau...@gmail.com> wrote:
>>
>>> From a quick glance, it looks like you're making exactly the mistake I
>>> tried to mention in my previous response. It looks like you have a single
>>> MAC-to-port table which is shared between all the switches. As you pointed
>>> out, this doesn't work since the mappings are different for different
>>> switches and you're just overwriting them.
>>>
>>> The solution is simply to keep a separate separate entries for each
>>> switch. As I mentioned, l2_learning does this by creating a separate
>>> instance of LearningSwitch for each connected switch, and each instance of
>>> LearningSwitch has its own table.
>>>
>>> l2_pairs does it a different way. It uses a single switch, but the keys
>>> in the table contain both the switch *and* the MAC address (as a tuple,
>>> IIRC).
>>>
>>> -- Murphy
>>>
>>> On Nov 7, 2013, at 9:48 PM, durga wrote:
>>>
>>> can someone take the pain of going through the below code and let me
>>> know where i might be going wrong?
>>>
>>> I di try compring the results with samples provided, and don't quite
>>> find any errors (except that sample code is much cleaner ), but somehow my
>>> sw1<-->h1(host1) cannot reach sw3<-->h3(host3).
>>>
>>> Any insights would be wonderful as this has gotten a little exhaustive
>>> on me.
>>>
>>> Thank you.
>>>
>>> Cheers!
>>> Durga
>>>
>>>
>>>
>>> On Fri, Nov 8, 2013 at 2:37 PM, durga wrote:
>>>
I am working on it as of now. I did use a macport table to store.Below
debug() shows that, (a obvious error in my code), that the port number for
input and outport are same, hence my ARP gets dropped. as inport ==
outport.
Will keep the group posted as soon i understand where I am going wrong.
*log.debug("%i --> %s" event.dpid,parsedpkt)*
my swtch output:
DEBUG:openflow.of_01:Listening on 0.0.0.0:6633
> INFO:openflow.of_01:[00-00-00-00-00-01 3] connected
> DEBUG:l2_switching_v5:connected to switch with dpid 1
> INFO:openflow.of_01:[00-00-00-00-00-04 1] connected
> DEBUG:l2_switching_v5:connected to switch with dpid 4
> INFO:openflow.of_01:[00-00-00-00-00-03 4] connected
> DEBUG:l2_switching_v5:connected to switch with dpid 3
> INFO:openflow.of_01:[00-00-00-00-00-02 2] connected
> DEBUG:l2_switching_v5:connected to switch with dpid 2
> DEBUG:l2_switching_v5:1 --> [00:00:00:00:00:01>ff:ff:ff:ff:ff:ff ARP]
> {EthAddr('00:00:00:00:00:01'): 1}
> DEBUG:l2_switching_v5:2 --> [00:00:00:00:00:01>ff:ff:ff:ff:ff:ff ARP]
> {EthAddr('00:00:00:00:00:01'): 2}
> DEBUG:l2_switching_v5:3 --> [00:00:00:00:00:01>ff:ff:ff:ff:ff:ff ARP]
> {EthAddr('00:00:00:00:00:01'): 2}
> DEBUG:l2_switching_v5:4 --> [00:00:00:00:00:01>ff:ff:ff:ff:ff:ff ARP]
> {EthAddr('00:00:00:00:00:01'): 2}
> DEBUG:l2_switching_v5:3 --> [00:00:00:00:00:03>00:00:00:00:00:01 ARP]
> {EthAddr('00:00:00:00:00:03'): 1, EthAddr('00:00:00:00:00:01'): 2}
> DEBUG:l2_switching_v5:2 --> [00:00:00:00:00:03>00:00:00:00:00:01 ARP]
> {EthAddr('00:00:00:00:00:03'): 3, EthAddr('00:00:00:00:00:01'): 2}
>
> *DEBUG:l2_switching_v5:1 --> [00:00:00:00:00:03>00:00:00:00:00:01 ARP]
> *
> *{EthAddr('00:00:00:00:00:03'): 2, EthAddr('00:00:00:00:00:01'): 2} *
> *dropping*
expected:
>
Re: [pox-dev] Bind POX to Multiple IP Interfaces
Thank you! It works!
At least I tested it with L2_Switch without problems. In this case first
address to listen on should be specified as argument in def launch() of
of_01.py and the second - as CLI argument when launching pox. The only
warning appears from core about registering 'of_01" multiple times (see
debug below).
We run multiple concurrent OpenFlow_01_Tasks in this case, and the
performance might be slower than one task binding multiple listeners,
right?
mininet@mininet-vm:~/pox$ ./pox.py --unthreaded_sh log.level --DEBUG
openflow.of_01 --address=192.168.20.1 l2sw
POX 0.3.0 (dart) / Copyright 2011-2013 James McCauley, et al.
WARNING:core:Warning: Registered 'of_01' multipled times
DEBUG:core:POX 0.3.0 (dart) going up...
DEBUG:core:Running on CPython (2.7.3/Sep 26 2012 21:51:14)
DEBUG:core:Platform is
Linux-3.5.0-17-generic-x86_64-with-Ubuntu-13.04-raring
INFO:core:POX 0.3.0 (dart) is up.
DEBUG:openflow.of_01:Listening on 192.168.20.1:6633
DEBUG:openflow.of_01:Listening on 192.168.10.1:6633
INFO:openflow.of_01:[00-00-00-00-00-02 1] connected
INFO:l2sw:Controlling conID=1, dpid=2
INFO:openflow.of_01:[00-00-00-00-00-01 2] connected
INFO:l2sw:Controlling conID=2, dpid=1
On 7 November 2013 20:56, Murphy McCauley wrote:
> I think this MIGHT be as easy as making the launcher for of_01
> multi-instance aware. I don't have time to actually check, but here's a
> hacked version which at least doesn't crash immediately. :) Maybe you can
> give it a shot?
>
> def launch (port=6633, address="0.0.0.0", name=None, __INSTANCE__=None):
> if name is None:
> basename = "of_01"
> counter = 1
> name = basename
> while core.hasComponent(name):
> counter += 1
> name = "%s-%s" % (basename, counter)
>
> if core.hasComponent(name):
> log.warn("of_01 '%s' already started", name)
> return None
>
> global deferredSender
> if not deferredSender:
> deferredSender = DeferredSender()
>
> if of._logger is None:
> of._logger = core.getLogger('libopenflow_01')
>
> l = OpenFlow_01_Task(port = int(port), address = address)
> core.register(name, l)
> return l
>
> -- Murphy
>
> On Nov 7, 2013, at 5:30 AM, Anton Matsiuk wrote:
>
> > Dear Murphy,
> >
> > I am asking about possibility to bind POX Controller to listen for OF
> messages on multiple IP Interfaces. In my case, I need to bind it to 2
> interfaces: listening from Open vSwitch through Loopback, and Hardware
> switch from external eth, but, of course, the quantity doesn't mater.
> >
> > As I understood there is no possibility to run 2 instances of
> OpenFlow_01_Task concurrently (and to register them both on core) or to
> bind one instance of Task to 2 different IP's.
> >
> > I know that it is possible to solve the problem by proxying through
> iptables, but I am looking for a possibility to do it with POX in a
> straightforward and scalable way.
> >
> > --
> > Best regards,
> > Anton Matsiuk
>
>
--
Best regards,
Anton Matsiuk
Re: [pox-dev] Bind POX to Multiple IP Interfaces
On Nov 8, 2013, at 5:45 AM, Anton Matsiuk wrote:
> Thank you! It works!
>
> At least I tested it with L2_Switch without problems. In this case first
> address to listen on should be specified as argument in def launch() of
> of_01.py and the second - as CLI argument when launching pox. The only
> warning appears from core about registering 'of_01" multiple times (see debug
> below).
I actually would have thought the code would stop it from registering multiple
times using the same name. Though it's possible there's also something that
needs adjusting with dart's new on-demand loading of OpenFlow. Or... are you
specifying "of_01" in l2sw? More generally, are you directly calling of_01's
launch() from l2sw? If so, can you post the code where you do?
> We run multiple concurrent OpenFlow_01_Tasks in this case, and the
> performance might be slower than one task binding multiple listeners, right?
Probably very slightly, in theory. IIRC, though, the same task currently
listens for connections and also handles established connections. The way it
figures out which are which would require a bit of adjusting to do cheaply when
there are multiple listening connections, or listeners could be put in their
own task. Running multiple tasks seemed a bit easier, pretty elegant, and I
didn't expect the performance difference to be dramatic. But I didn't
benchmark it or anything. :)
> mininet@mininet-vm:~/pox$ ./pox.py --unthreaded_sh log.level --DEBUG
> openflow.of_01 --address=192.168.20.1 l2sw
> POX 0.3.0 (dart) / Copyright 2011-2013 James McCauley, et al.
> WARNING:core:Warning: Registered 'of_01' multipled times
> DEBUG:core:POX 0.3.0 (dart) going up...
> DEBUG:core:Running on CPython (2.7.3/Sep 26 2012 21:51:14)
> DEBUG:core:Platform is Linux-3.5.0-17-generic-x86_64-with-Ubuntu-13.04-raring
> INFO:core:POX 0.3.0 (dart) is up.
> DEBUG:openflow.of_01:Listening on 192.168.20.1:6633
> DEBUG:openflow.of_01:Listening on 192.168.10.1:6633
> INFO:openflow.of_01:[00-00-00-00-00-02 1] connected
> INFO:l2sw:Controlling conID=1, dpid=2
> INFO:openflow.of_01:[00-00-00-00-00-01 2] connected
> INFO:l2sw:Controlling conID=2, dpid=1
>
>
> On 7 November 2013 20:56, Murphy McCauley wrote:
> I think this MIGHT be as easy as making the launcher for of_01 multi-instance
> aware. I don't have time to actually check, but here's a hacked version
> which at least doesn't crash immediately. :) Maybe you can give it a shot?
>
> def launch (port=6633, address="0.0.0.0", name=None, __INSTANCE__=None):
> if name is None:
> basename = "of_01"
> counter = 1
> name = basename
> while core.hasComponent(name):
> counter += 1
> name = "%s-%s" % (basename, counter)
>
> if core.hasComponent(name):
> log.warn("of_01 '%s' already started", name)
> return None
>
> global deferredSender
> if not deferredSender:
> deferredSender = DeferredSender()
>
> if of._logger is None:
> of._logger = core.getLogger('libopenflow_01')
>
> l = OpenFlow_01_Task(port = int(port), address = address)
> core.register(name, l)
> return l
>
> -- Murphy
>
> On Nov 7, 2013, at 5:30 AM, Anton Matsiuk wrote:
>
> > Dear Murphy,
> >
> > I am asking about possibility to bind POX Controller to listen for OF
> > messages on multiple IP Interfaces. In my case, I need to bind it to 2
> > interfaces: listening from Open vSwitch through Loopback, and Hardware
> > switch from external eth, but, of course, the quantity doesn't mater.
> >
> > As I understood there is no possibility to run 2 instances of
> > OpenFlow_01_Task concurrently (and to register them both on core) or to
> > bind one instance of Task to 2 different IP's.
> >
> > I know that it is possible to solve the problem by proxying through
> > iptables, but I am looking for a possibility to do it with POX in a
> > straightforward and scalable way.
> >
> > --
> > Best regards,
> > Anton Matsiuk
>
>
>
>
> --
> Best regards,
> Anton Matsiuk
Re: [pox-dev] working with multiple switches
Hi Ngyyen,
As of now, these
https://github.com/noxrepo/pox/blob/dart/pox/forwarding/l2_nx.py
http://openvswitch.org/support/
https://github.com/noxrepo/pox/blob/dart/pox/openflow/nicira.py
I do have few questions to ask, and would do them sometime this week ..
Cheers!
Durga
On Fri, Nov 8, 2013 at 10:16 PM, Giang Nguyen wrote:
> Hello Durga,
>
> What's docs you're reading for deploying VLANs? Could you share it?
>
> Thank you so much
>
> --
> Giang Nguyen
> Seoul, Korea
>
>
> On 8 November 2013 15:47, durga wrote:
>
>> Yup! That's it!! That was the issue. below are the macaddr table entries
>> , also I can reach all other hosts.
>>
>> -
>> Thank you so much. :)
>>
>> DEBUG:l2_switching_v5:3 --> [00:00:00:00:00:03>00:00:00:00:00:01 ARP]
>> {EthAddr('00:00:00:00:00:03'): 1, EthAddr('00:00:00:00:00:01'): 2}
>> DEBUG:l2_switching_v5:2 --> [00:00:00:00:00:03>00:00:00:00:00:01 ARP]
>> {EthAddr('00:00:00:00:00:03'): 3, EthAddr('00:00:00:00:00:01'): 2}
>> DEBUG:l2_switching_v5:1 --> [00:00:00:00:00:03>00:00:00:00:00:01 ARP]
>> {EthAddr('00:00:00:00:00:03'): 2, EthAddr('00:00:00:00:00:01'): 1}
>> DEBUG:l2_switching_v5:1 --> [00:00:00:00:00:01>00:00:00:00:00:03 ARP]
>> {EthAddr('00:00:00:00:00:03'): 2, EthAddr('00:00:00:00:00:01'): 1}
>> DEBUG:l2_switching_v5:2 --> [00:00:00:00:00:01>00:00:00:00:00:03 ARP]
>> {EthAddr('00:00:00:00:00:03'): 3, EthAddr('00:00:00:00:00:01'): 2}
>> DEBUG:l2_switching_v5:3 --> [00:00:00:00:00:01>00:00:00:00:00:03 ARP]
>> {EthAddr('00:00:00:00:00:03'): 1, EthAddr('00:00:00:00:00:01'): 2}
>>
>>
>> Cheers!
>> Durga
>>
>>
>>
>> On Fri, Nov 8, 2013 at 5:35 PM, durga wrote:
>>
>>> I reread the sample program and I am understanding what you meant.
>>> As soon as the controller is launched, the _handle_ConnectionUp()
>>> handler is calling the L2switch module, thus for every connection
>>> established , a different instance of switch is being created
>>>
>>> Thank you, I will work on these lines.
>>>
>>>
>>>
>>> Cheers!
>>> Durga
>>>
>>>
>>>
>>> On Fri, Nov 8, 2013 at 4:55 PM, Murphy McCauley <
>>> murphy.mccau...@gmail.com> wrote:
>>>
From a quick glance, it looks like you're making exactly the mistake I
tried to mention in my previous response. It looks like you have a single
MAC-to-port table which is shared between all the switches. As you pointed
out, this doesn't work since the mappings are different for different
switches and you're just overwriting them.
The solution is simply to keep a separate separate entries for each
switch. As I mentioned, l2_learning does this by creating a separate
instance of LearningSwitch for each connected switch, and each instance of
LearningSwitch has its own table.
l2_pairs does it a different way. It uses a single switch, but the
keys in the table contain both the switch *and* the MAC address (as a
tuple, IIRC).
-- Murphy
On Nov 7, 2013, at 9:48 PM, durga wrote:
can someone take the pain of going through the below code and let me
know where i might be going wrong?
I di try compring the results with samples provided, and don't quite
find any errors (except that sample code is much cleaner ), but somehow my
sw1<-->h1(host1) cannot reach sw3<-->h3(host3).
Any insights would be wonderful as this has gotten a little exhaustive
on me.
Thank you.
Cheers!
Durga
On Fri, Nov 8, 2013 at 2:37 PM, durga wrote:
> I am working on it as of now. I did use a macport table to store.Below
> debug() shows that, (a obvious error in my code), that the port number for
> input and outport are same, hence my ARP gets dropped. as inport ==
> outport.
>
> Will keep the group posted as soon i understand where I am going wrong.
>
> *log.debug("%i --> %s" event.dpid,parsedpkt)*
>
> my swtch output:
> DEBUG:openflow.of_01:Listening on 0.0.0.0:6633
>
>> INFO:openflow.of_01:[00-00-00-00-00-01 3] connected
>> DEBUG:l2_switching_v5:connected to switch with dpid 1
>> INFO:openflow.of_01:[00-00-00-00-00-04 1] connected
>> DEBUG:l2_switching_v5:connected to switch with dpid 4
>> INFO:openflow.of_01:[00-00-00-00-00-03 4] connected
>> DEBUG:l2_switching_v5:connected to switch with dpid 3
>> INFO:openflow.of_01:[00-00-00-00-00-02 2] connected
>> DEBUG:l2_switching_v5:connected to switch with dpid 2
>> DEBUG:l2_switching_v5:1 --> [00:00:00:00:00:01>ff:ff:ff:ff:ff:ff ARP]
>> {EthAddr('00:00:00:00:00:01'): 1}
>> DEBUG:l2_switching_v5:2 --> [00:00:00:00:00:01>ff:ff:ff:ff:ff:ff ARP]
>> {EthAddr('00:00:00:00:00:01'): 2}
>> DEBUG:l2_switching_v5:3 --> [00:00:00:00:00:01>ff:ff:ff:ff:ff:ff ARP]
>> {EthAddr('00:00:00:00:00:01'): 2}
>> DEBUG:l2_switching_v5:4 --> [00:00:00:00:00:01>ff:ff:ff:ff:ff:ff ARP]
>> {EthAddr('00:00:00:00:00:01'): 2}
>> DEBUG:l2_switching_v5:3 --> [00:00:00:00:00:0
