Hi,
I am trying to modify forwarding.l2_multi for backup path computation.
For this as a first step , i wanted to put some flow entries with the
priority 0x0001. But though i am setting the msg.priority to this value ,
the flows which are installed in the switch have the priority 65535.
Ia m setting the msg.priority of ofp_flow_mod message before
switch.connection.send(msg) statment
def _binstall (self, switch, in_port, out_port, match, buf = None):
out_port_temp =3
msg = of.ofp_flow_mod()
msg.match = match
msg.match.in_port = in_port
msg.idle_timeout = FLOW_IDLE_TIMEOUT
msg.hard_timeout = FLOW_HARD_TIMEOUT
msg.priority = BACKUP_PRIORITY
log.debug("Installing backup path with priority %s",msg.priority)
msg.actions.append(of.ofp_action_output(port = out_port))
msg.buffer_id = buf
switch.connection.send(msg)
1)The log.debug statement shows the priority as 1. But the flow entries are
with the priority 65535.
What is the reason for it?
2) What will be the effect of switch.connection.send(msg).
(ie) After the execution of this statement where will the control go.I
guess the control goes to the switch. If so which module of openvswitch
will handle this?
Please clarify
Regards,
Padma V
On Sat, Sep 6, 2014 at 8:07 AM, Padma Jayasankar <padmaj...@gmail.com>
wrote:
> Hi,
> I waited for complete discovery cycle..even though it is not working for
> the single,2 topology. But it is working for the custom topology which i
> created with loop.
>
> Regarding openvswitch, i followed the below instructions to install it.
>
> root@mininet-vm# cd /root
> root@mininet-vm# wget
> http://openvswitch.org/releases/openvswitch-1.10.0.tar.gz
> root@mininet-vm# tar zxvf openvswitch-1.10.0.tar.gz
>
> Build debian packages and install
> ---------------------------------
> root@mininet-vm# cd openvswitch-1.10.0/
> root@mininet-vm# apt-get install build-essential fakeroot
> root@mininet-vm# apt-get install debhelper autoconf automake libssl-dev
> pkg-config bzip2 openssl python-all procps python-qt4 python-zopeinterface
> python-twisted-conch
> root@mininet-vm# fakeroot debian/rules binary
> root@mininet-vm# cd ..
> root@mininet-vm# dpkg -i openvswitch-common*.deb
> openvswitch-datapath-dkms*.deb openvswitch-controller*.deb
> openvswitch-pki*.deb openvswitch-switch*.deb
>
> But before following debian package install mehods, i tried to install
> with -
>
> *Binary build and Install*
> ------------------------------------
>
> root@mininet-vm# cd openvswitch-1.10.0/
> root@mininet-vm# ./configure --prefix=/usr --with-linux=/lib/modules/`uname
> -r`/build
> root@mininet-vm# make
> root@mininet-vm# make install
> root@mininet-vm# make modules_install
> root@mininet-vm# rmmod openvswitch
> root@mininet-vm# depmod -a
>
> But i got some error while executing make..
>
> *My doubt is*
> 1. with debian packages install method, will i be able to change the source
> code
> and build again.
>
> 2. As per this installation guidelines openvswitch1.10.0 folder is created
> under root folder
> and i am not able to see this folder contents(permission denied).. So how to
> change the
> source code of openvswitch
>
>
>
>
>
>
> On Sat, Sep 6, 2014 at 2:33 AM, Murphy McCauley <murphy.mccau...@gmail.com
> > wrote:
>
>>
>> On Sep 5, 2014, at 11:08 AM, Padma Jayasankar <padmaj...@gmail.com>
>> wrote:
>>
>> Hi,
>> 1)I have removed ovs that come along with Mininet and installed
>> openvswitch 1.10.0. After this i tested mininet, with the following command
>> sudo mn --topo single,2 --switch ovsk --controller
>> remote,ip=192.168.56.1,port=6633
>> its working and pingall runs successfully.
>>
>> Does this sufficient to check whether the installed openvswitch works
>> fine? Please clarify.
>> Here i checked with POX controller with following 3 commands.
>>
>>
>> Probably, though I am not an authoritative source on the subject.
>>
>> ./pox.py log.level forwarding.l2_learning
>> ./pox.py log.level openflow.discovery forwarding.l2_multi
>> ./pox.py log.level openflow.discovery openflow.spanning_tree
>> forwarding.l2_multi
>>
>> For all these pingall test was successful
>>
>> 2) But when i run the pox controller with the below options
>> ./pox.py log.level openflow.discovery openflow.spanning_tree --no-flood
>> --hold-down forwarding.l2_multi
>> the ping test fails for the sudo mn command given above.
>>
>> But for another topology with loop, pingall test was successful
>> sudo mn --custom ~/mininet/custom/topo-3sw-2host.py --topo mytopo
>> --controller remote,ip=192.168.56.1,port=6633
>>
>> i have attached the custom topology file.
>>
>> Why this happens?
>>
>>
>> Did you wait a while before running the ping test? With no-flood and
>> hold-down, you have to wait for a complete discovery cycle before you can
>> expect things to work.
>>
>> Thanks,
>> Padma V
>>
>>
>>
>> On Thu, Sep 4, 2014 at 10:54 AM, Murphy McCauley <
>> murphy.mccau...@gmail.com> wrote:
>>
>>> Many features of OVS are available via specific OVS extensions to
>>> OpenFlow 1.0. They may also be available as features in higher OpenFlow
>>> versions.
>>>
>>> POX currently only supports OpenFlow 1.0, but it does support a number
>>> of OVS extensions (and others can be added).
>>>
>>> As far as I know, there are no plans to have OVS stop supporting any
>>> lower versions of OpenFlow. Certainly, the latest versions still support
>>> 1.0.
>>>
>>> -- Murphy
>>>
>>> On Sep 3, 2014, at 10:17 PM, Padma Jayasankar <padmaj...@gmail.com>
>>> wrote:
>>>
>>> HI,
>>> Regarding OVS extensions to support back up path, do u mean the fast
>>> fail over group type..
>>> If that is the case then openflow controller(i am using POX), have to
>>> support atleast OpenFlow 1.1 know..But it supports only OpenFlow 1.0 right.
>>> Further, can i use the new OVS versions to support OpenFlow 1.0. Or
>>> will they support only OpenFlow 1.3.
>>>
>>> Thanks ,
>>> Padma V
>>>
>>>
>>> On Thu, Sep 4, 2014 at 10:27 AM, Murphy McCauley <
>>> murphy.mccau...@gmail.com> wrote:
>>>
>>>> Right, you'd have to build your own version. I think you have the
>>>> right idea of asking on the mininet list for more guidance here.
>>>>
>>>> Though again... OVS has lots of extensions already for doing
>>>> failover/backup-paths (even without controller involvement), which are
>>>> already used extensively. I would not be surprised if it already had all
>>>> the capabilities you need.
>>>>
>>>> Good luck.
>>>>
>>>> -- Murphy
>>>>
>>>> On Sep 3, 2014, at 6:56 AM, Padma Jayasankar <padmaj...@gmail.com>
>>>> wrote:
>>>>
>>>> Hi,
>>>> If i have to modify the openvswitch,then do i have to remove the one
>>>> which is installed by mininet and download and install openvswitch.
>>>>
>>>> Thanks & Regards,
>>>> Padma V
>>>>
>>>>
>>>> On Fri, Aug 29, 2014 at 9:51 AM, Murphy McCauley <
>>>> murphy.mccau...@gmail.com> wrote:
>>>>
>>>>> On Aug 28, 2014, at 1:12 AM, Padma Jayasankar <padmaj...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Thanks a lot.
>>>>> I am able to see the flow tables of other switches by changing the
>>>>> port like 6635,6637..
>>>>> One more doubt.
>>>>> * If i have to add a new type of openflow message then where should i
>>>>> do it.*
>>>>> In the server where i have installed minnet, Openflow folder is also
>>>>> there.
>>>>> I am able to find Openflow.h file in openflow/include/openflow
>>>>> folder. This file has the declaration and structure definition of all
>>>>> openflow messages like port_status,Packet_in etc. So here i have to add
>>>>> the
>>>>> new message name and format i guess..
>>>>>
>>>>>
>>>>> Probably not. By default, Mininet uses Open vSwitch. So you'll want
>>>>> to modify Open vSwitch. Of course, Open vSwitch already contains features
>>>>> for backup paths...
>>>>>
>>>>> But the controller also will be using openflow protocol to listen to
>>>>> switch..So in the server in which i ghave installed the controller, where
>>>>> will it be..i believe, i have to make changes in that part too.. is it
>>>>> correct?
>>>>>
>>>>>
>>>>> Sure. In POX, this is mostly in libopenflow_01.py. You can look at
>>>>> nicira.py also to see how some extensions have been added. (It's not
>>>>> currently as clean/modular as would be desirable... cleaning it up will
>>>>> hopefully happen in a later POX version.)
>>>>>
>>>>> On Tue, Aug 26, 2014 at 11:57 PM, Murphy McCauley <
>>>>> murphy.mccau...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> On Aug 26, 2014, at 9:40 AM, Padma Jayasankar <padmaj...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> HI,
>>>>>>
>>>>>> 1. You might use l2_multi as a starting point, but you might want to
>>>>>> use something like NetworkX to base your path computation upon.
>>>>>> *what is this NetworkX..please explain*
>>>>>>
>>>>>>
>>>>>> It's a graph library for Python which you can learn a lot about by
>>>>>> doing a web search for "NetworkX".
>>>>>>
>>>>>> In the below command 'switch ' is specified as tcp:127.0.0.1:6634.
>>>>>>
>>>>>> *dpctl add-flow tcp:127.0.0.1:6634 <http://127.0.0.1:6634/>
>>>>>> in_port=1,actions=output:2*
>>>>>>
>>>>>> How is this mapped to a particular switch. In my topology if i have 3
>>>>>> switches s3,s4,s5 then how to specify one of these switches in the
>>>>>> command.
>>>>>> Please clarify.
>>>>>>
>>>>>>
>>>>>> This is a Mininet question not a POX one. Furthermore, as I already
>>>>>> mentioned, you are probably better off using the OVS tools (ovs-dpctl,
>>>>>> ovs-vsctl, ovs-ofctl, etc.). Among other things, you can usually
>>>>>> specify a
>>>>>> datapath by name when using the OVS tools (e.g., ovs-vsctl s3 ...). That
>>>>>> all said, I believe each switch in Mininet listens on a different port.
>>>>>> So
>>>>>> maybe port 6634 is s3, and 6635 is s4, etc.
>>>>>>
>>>>>> Good luck.
>>>>>>
>>>>>> -- Murphy
>>>>>>
>>>>>> On Tue, Aug 26, 2014 at 5:27 AM, Murphy McCauley <
>>>>>> murphy.mccau...@gmail.com> wrote:
>>>>>>
>>>>>>> On Aug 25, 2014, at 7:25 AM, Padma Jayasankar <padmaj...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> HI,
>>>>>>> I feel, it will be better if i explain my requirement clearly. My
>>>>>>> aim is to reduce the failure recovery time. For this, i am trying to
>>>>>>> avoid
>>>>>>> controller intervention at the time of failure. For that,in response to
>>>>>>> traffic the controller should find primary and backup path and install
>>>>>>> it
>>>>>>> in the switches.Back up path will be installed with a different(lower)
>>>>>>> priority.
>>>>>>> When a failure occurs, the switches connected to the failed link
>>>>>>> should do the following.
>>>>>>> 1) Delete the flow entries that use the failed link(in/out port)
>>>>>>> By doing this, now the traffic will be redirected through the
>>>>>>> backup path automatically as the switch has the backup path entries
>>>>>>> (which
>>>>>>> is installed at the beginning) itself.
>>>>>>> 2) Renew this backup path entries:
>>>>>>> When there is no failure, as the switches use the working path
>>>>>>> only, the back up paths will be removed automatically. But this should
>>>>>>> not
>>>>>>> happen. Hence the switches have to send some packets through this path
>>>>>>> periodically to avoid expiration. These packets should be different from
>>>>>>> normal data packets. I am referring these packets as renewal packets.
>>>>>>> These
>>>>>>> packets has to be identified uniquely, so that egress switches doesn't
>>>>>>> deliver them to hosts.
>>>>>>>
>>>>>>> 3) Restoration of working path:
>>>>>>> Once a link fails, the switches starts using the back up path. But
>>>>>>> these backup paths are less efficient than primary path. Hence once the
>>>>>>> failure is rectified and the link is up, again we should reroute the
>>>>>>> traffic through the primary path.
>>>>>>> But as the switches has backup entries, it won't direct the
>>>>>>> packets to the controller. They will route the traffic through backup
>>>>>>> path
>>>>>>> only.hence when a link is up, the corresponding switch has to send
>>>>>>> restoration packets(a special type of packet) to the controller.Then the
>>>>>>> controller will recompute the path for that flow and install the primary
>>>>>>> and backup entries.
>>>>>>>
>>>>>>> Now in implementation perspective, please clarify the below points.
>>>>>>> 1. For the (1) requirement can i use, l2_multi with changes to
>>>>>>> compute backup path.
>>>>>>> 2. How to make the switches to generate renewal packets..where
>>>>>>> should i place the code for this??
>>>>>>>
>>>>>>>
>>>>>>> 1. You might use l2_multi as a starting point, but you might want to
>>>>>>> use something like NetworkX to base your path computation upon.
>>>>>>>
>>>>>>> 2. Assuming you want to do it from the controller, maybe you want to
>>>>>>> use callDelayed() or a Timer (see the POX manual) to generate a
>>>>>>> packet-out
>>>>>>> message to send to a switch.
>>>>>>>
>>>>>>> Beyond that, I'm not sure if I'll be much help to you. Good luck!
>>>>>>>
>>>>>>> -- Murphy
>>>>>>>
>>>>>>> On Mon, Aug 25, 2014 at 10:12 AM, Murphy McCauley <
>>>>>>> murphy.mccau...@gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Aug 24, 2014, at 9:08 PM, Padma Jayasankar <padmaj...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>> In my previous mails, i asked two things
>>>>>>>> 1) I want to install back up paths proactively. According to my
>>>>>>>> understanding l2_multi does this reactively(once failure occurs,it
>>>>>>>> finds
>>>>>>>> the new path). Did u mean the same abt l2_multi.
>>>>>>>> *2)ofp_flow_mod_flags* of *ofp_flow_mod* has to be set to
>>>>>>>> * OFPFF_SEND_FLOW_REM* to invoke flow removal notification
>>>>>>>> messages.
>>>>>>>> Is it correct? please confirm
>>>>>>>>
>>>>>>>> *Does your 'Yes' holds for both*.
>>>>>>>>
>>>>>>>>
>>>>>>>> My yes was just for the second one.
>>>>>>>>
>>>>>>>> For the first one... l2_multi is reactive. It doesn't create any
>>>>>>>> switch state except in response to traffic. In general, this is a bad
>>>>>>>> design. topo_proactive is a somewhat more reasonable variation. But
>>>>>>>> you
>>>>>>>> seem to be talking about creating both primary and backup paths in
>>>>>>>> response
>>>>>>>> to traffic. I'd say this is still reactive. I mean... I guess you
>>>>>>>> could
>>>>>>>> install just the primary and then install the backup in response to
>>>>>>>> failure, but in that case I wouldn't call it a backup -- it's just a
>>>>>>>> new
>>>>>>>> path.
>>>>>>>>
>>>>>>>> Further regarding back up path renewal,
>>>>>>>> - For fast recovery, i have to enable the switches to delete the
>>>>>>>> working path entries , when the corresponding link fails(though timeout
>>>>>>>> constraint not met). Hence i can not make the switches to delete the
>>>>>>>> backup
>>>>>>>> paths on flow removal notification.
>>>>>>>> Hence i have to use renewal packets.In which part this has to be
>>>>>>>> done? It will be helpful, if i get a starting point.
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm not sure I know what you mean by renewal packets. I was
>>>>>>>> assuming you just meant packets that kept the flows from expiring.
>>>>>>>>
>>>>>>>> Regardless, I believe the way I mentioned still works. Yes, you
>>>>>>>> delete them manually when you get a flow removal message. This is in
>>>>>>>> order
>>>>>>>> to "clean them up". This has nothing to do with how you react on
>>>>>>>> failure;
>>>>>>>> this has to do with removing useless entries.
>>>>>>>>
>>>>>>>> I don't actually know what mechanism you plan to use to detect a
>>>>>>>> failure and switch to an alternate path, but I think it probably
>>>>>>>> diverges
>>>>>>>> heavily from how I'd do it, so I'm not sure how helpful I can be.
>>>>>>>>
>>>>>>>> Thanks and Regards,
>>>>>>>> Padma V
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Aug 25, 2014 at 2:27 AM, Murphy McCauley <
>>>>>>>> murphy.mccau...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Yes.
>>>>>>>>>
>>>>>>>>> On Aug 24, 2014, at 7:15 AM, Padma Jayasankar <padmaj...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> 2)When i checked the openflow specification , came to know that
>>>>>>>>> *ofp_flow_mod_flags* of *ofp_flow_mod* has to be set to
>>>>>>>>> * OFPFF_SEND_FLOW_REM* to invoke flow removal notification
>>>>>>>>> messages.
>>>>>>>>> Is it correct? please confirm
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, Aug 24, 2014 at 7:42 PM, Padma Jayasankar <
>>>>>>>>> padmaj...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>> 2)When i checked the openflow specification , came to know that
>>>>>>>>>> ofp_flow_mod_flags
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sun, Aug 24, 2014 at 6:25 PM, Padma Jayasankar <
>>>>>>>>>> padmaj...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> HI,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for quick reply.
>>>>>>>>>>>
>>>>>>>>>>> 1) I want to install back up paths pro actively. According to my
>>>>>>>>>>> understanding l2_multi does this reactively(once failure occurs,it
>>>>>>>>>>> finds
>>>>>>>>>>> the new path). Did u mean the same abt l2_multi.
>>>>>>>>>>>
>>>>>>>>>>> 2) I will implement back up path entries as per ur guidence. But
>>>>>>>>>>> to install flow entries with flow removal notification, what should
>>>>>>>>>>> be
>>>>>>>>>>> done? please provide a starting point.
>>>>>>>>>>>
>>>>>>>>>>> Tahnks and Regards,
>>>>>>>>>>> Padma V
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Aug 24, 2014 at 3:40 PM, Murphy McCauley <
>>>>>>>>>>> murphy.mccau...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Aug 24, 2014, at 2:54 AM, Padma Jayasankar <
>>>>>>>>>>>> padmaj...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> Thanks for the clarifications..
>>>>>>>>>>>> 1) For the first query, as u have said the iCMP type differs in
>>>>>>>>>>>> the entries.
>>>>>>>>>>>> 2) Regarding the back up path, i can not install them without a
>>>>>>>>>>>> timeout..Let me explain my requirement.
>>>>>>>>>>>> My aim is to improve the recovery time.
>>>>>>>>>>>> Hence i have to install backup paths along with working
>>>>>>>>>>>> paths(both have to be computed and installed).
>>>>>>>>>>>> when a link fails, the corresponding switch has to remove
>>>>>>>>>>>> the corresponding entry, involving that link.
>>>>>>>>>>>> As back up flow is already installed, the switch will use
>>>>>>>>>>>> that entry immediately.
>>>>>>>>>>>> But though we install backup path entries in the switch,
>>>>>>>>>>>> when there is no failure , it won't be used Hence because of idle
>>>>>>>>>>>> time out,
>>>>>>>>>>>> they will get expired.If we install it as permenant entries , then
>>>>>>>>>>>> this
>>>>>>>>>>>> will result in large no of flow entries in the flow tables(in
>>>>>>>>>>>> largel
>>>>>>>>>>>> networks).
>>>>>>>>>>>> Hence ,the switches has to generate some renew packets(of
>>>>>>>>>>>> small size), and send it through the back up path periodically(to
>>>>>>>>>>>> avoid
>>>>>>>>>>>> expiration). How to accomplish this.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Are you writing this reactively and using fine-grained table
>>>>>>>>>>>> entries? Despite the fact that this is how l2_multi, for example,
>>>>>>>>>>>> works...
>>>>>>>>>>>> I strongly caution against this. This introduces scaling problems
>>>>>>>>>>>> which are
>>>>>>>>>>>> generally avoidable.
>>>>>>>>>>>>
>>>>>>>>>>>> More to the point, though... I can think of several ways of
>>>>>>>>>>>> keeping the backup paths for active flows. One way (which doesn't
>>>>>>>>>>>> involve
>>>>>>>>>>>> any "renew packets" is... Install the primary table entries with
>>>>>>>>>>>> timeouts
>>>>>>>>>>>> and with flow-removal notification. Install the backup entries
>>>>>>>>>>>> with no
>>>>>>>>>>>> timeouts. If you get an expiration notification from the primary
>>>>>>>>>>>> path,
>>>>>>>>>>>> remove the backup path (unless you've failed over and are using
>>>>>>>>>>>> the backup
>>>>>>>>>>>> path; in this case, reinstall the backup path with expirations).
>>>>>>>>>>>>
>>>>>>>>>>>> 3) To start with, i created a custom topology, with 3 switches
>>>>>>>>>>>> and 2 hosts in mininet. i wrote a python script to start the
>>>>>>>>>>>> network and
>>>>>>>>>>>> test pingall. I have attached the python script.
>>>>>>>>>>>> I tried to connect that with remote POX controller
>>>>>>>>>>>> ./pox.py log.level openflow.discovery openflow.spanning_tree
>>>>>>>>>>>> --no-flood --hold-down forwarding.l2_multi
>>>>>>>>>>>>
>>>>>>>>>>>> ping was successful.
>>>>>>>>>>>> But i want to down a link and test the behaviour of ping after
>>>>>>>>>>>> the link down. How to include it in the python script.
>>>>>>>>>>>> i know the mininet command
>>>>>>>>>>>> h1 ping -c10 h2
>>>>>>>>>>>> link s3 s4 down
>>>>>>>>>>>> h1 ping -c10 h2
>>>>>>>>>>>> link s3 s4 down
>>>>>>>>>>>> h1 ping -c10 h2
>>>>>>>>>>>> But how to invoke this in the script. Is there any way? Then
>>>>>>>>>>>> only i can identify that how much time the controller takes to
>>>>>>>>>>>> recover from
>>>>>>>>>>>> failure.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This is a Mininet concern, and you should look into the Mininet
>>>>>>>>>>>> resources (the FAQ, mailing list archive, etc.).
>>>>>>>>>>>>
>>>>>>>>>>>> Sorry, if it is a very silly doubt..I am new to SDN,
>>>>>>>>>>>> Python,mininet and POX and i have a very little time to finish my
>>>>>>>>>>>> project.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Aug 24, 2014 at 4:05 AM, Murphy McCauley <
>>>>>>>>>>>> murphy.mccau...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Aug 23, 2014, at 5:42 AM, Padma Jayasankar <
>>>>>>>>>>>>> padmaj...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>> I am new to POX and Openflow. In my project.I have to compute
>>>>>>>>>>>>> working path and backup path and install them in switches.I am
>>>>>>>>>>>>> going to use
>>>>>>>>>>>>> Mininet and POX..Please guide me where to start with..
>>>>>>>>>>>>>
>>>>>>>>>>>>> In POX, i tried with
>>>>>>>>>>>>> python ./pox.py openflow.discovery forwarding.l2_multi
>>>>>>>>>>>>> and in Mininet,
>>>>>>>>>>>>> sudo mn --topo single,2 --controller
>>>>>>>>>>>>> remote,ip=192.168.1.4,6633
>>>>>>>>>>>>>
>>>>>>>>>>>>> The topology was built successfully.
>>>>>>>>>>>>> 1)I wanted to check the flow entries in the flow table of
>>>>>>>>>>>>> switch s1.
>>>>>>>>>>>>>
>>>>>>>>>>>>> i executed
>>>>>>>>>>>>> sudo dpctl dump-flows tcp:127.0.0.1:6634
>>>>>>>>>>>>>
>>>>>>>>>>>>> Initially it showed a single entry which directed the flows to
>>>>>>>>>>>>> the controller.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is probably an entry to direct the discovery packets to
>>>>>>>>>>>>> the controller.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Then i executed h1 ping -c10 h2
>>>>>>>>>>>>>
>>>>>>>>>>>>> mean while checked the flow entries using dpctl command
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now it listed some 5 entries including the previous one. For
>>>>>>>>>>>>> the same input and poutput pairs there were 2 entries..why is it
>>>>>>>>>>>>> so?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> l2_multi installs exact-match flows. There's probably a pair
>>>>>>>>>>>>> for both directions of ARP and another pair for both directions
>>>>>>>>>>>>> of ICMP.
>>>>>>>>>>>>> Check the Ethertype and IP protocol numbers for each table entry.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also, you should probably use the OVS tools (ovs-dpctl,
>>>>>>>>>>>>> ovs-ofctl, etc.) rather than the reference distribution's dpctl.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2) According to my requirements, some of the switches have to
>>>>>>>>>>>>> generate renewal packets peroiodically, to keep the back up paths
>>>>>>>>>>>>> alive.
>>>>>>>>>>>>> Which part has to be modified for this?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You haven't really explained your strategy for backup paths,
>>>>>>>>>>>>> so I don't have any idea what you're talking about here.
>>>>>>>>>>>>> Offhand, it seems
>>>>>>>>>>>>> like you could just install the entries for your backup paths
>>>>>>>>>>>>> without a
>>>>>>>>>>>>> timeout.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please clarify the doubts..
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>> Padma V
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> <mytestping.py>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>> <topo-3sw-2host.py>
>>
>>
>>
>
