Re: [Ryu-devel] Reg: Experimenter message

[Iwase Yusuke]

Hi Subha,

How about the following?

Example:

experimenter = 
exp_type = 
data = b'\x00\x00...'  # as a raw binary data
msg = ofproto.OFPExperimenter(
datapath, experimenter=experimenter, exp_type=exp_type, data=data)
datapath.send_msg(msg)

Thanks,
Iwase


On 2017年12月05日 15:44, Subha wrote:

Hi Team,

Can you pls let me know how to send an experimenter message using ryu 
controller.

Any json file example ?

I referred the following example, but still not getting a clear idea.

http://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#experimenter

Thanks,
subha.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot



___
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel

[Ryu-devel] Reg: Experimenter message

[Subha]

Hi Team,

Can you pls let me know how to send an experimenter message using ryu
controller.

Any json file example ?

I referred the following example, but still not getting a clear idea.

http://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#experimenter


Thanks,
subha.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel

Re: [Ryu-devel] SET CONTROLLER IP - GET CONNECTED SWITCHES

[Iwase Yusuke]

Hi Alessandro,

Well... I might misunderstand your situation...
You just want to tell your controller's IP/port to your switches when starting
your topology up, right?
In other words, it is not required to configure the controller address
dynamically after the topology was created.

If so, did you try to add the controller address in your Mininet script?

Example:
...(snip)...
net = Mininet(controller=RemoteController)

net.addController('c1', ip='192.168.1.1', port=6653)
net.addController('c2', ip='192.168.1.2', port=6653)

s1 = net.addSwitch('s1')
s2 = net.addSwitch('s2')
...(snip)...


If you need to configure the controller address dynamically, you need to get
your switch's names and dpids before calling the APIs on my previous mail.


Thanks,
Iwase


On 2017年12月05日 00:32, Alessandro Gaballo wrote:

Hi,
the API you suggested regarding the switch name is not what I need
because it simply returns the datapath object, which I already have
since I'm saving them when a new packet is received. What I need is the
name of the switch, the one I'm using in Mininet to be clear. Is that
simply the id? So s1 is the datapath with id=1 and so on? I also noticed
the switches with different names such as (si1, sio1) are not able to
connect to the controller.

Concerning the setting of the controller address I don't get the correct
flow.
I thought there was a simply api to use in my ryu application that would
define the ip and then make all the switches connect to that address
from mininet. With the examples you gave me I see multiple port and
addresses, so I'm still not sure.

Thanks,
Alessandro


On 04/12/2017 00:05, Iwase Yusuke wrote:


Hi again,


- how do I set the IP address of the controller?


You are using Open vSwitch, right?
If so, you need to configure your switches via OVSDB (like "ovs-vsctl"
command),
and Ryu provide some options to use OVSDB.

First, it might be the easiest way I guess, you can use the APIs of
"ryu.lib.ovs".
The usage and arguments are very similar to "ovs-vsctl" command.
https://github.com/osrg/ryu/blob/63f81837fd73cc31edbfe9ba6814ae3f38e34a16/ryu/lib/ovs/bridge.py#L133


In this case, you need to set the OVSDB manager address to your OVS
before
Ryu connect to your switches like;
$ ovs-vsctl set-manager "ptcp:6640"

Example code:
===
from ryu.cfg import CONF
from ryu.lib.ovs import bridge

ovs_bridge = bridge.OVSBridge(CONF, 1, "tcp:127.0.0.1:6640")
ovs_bridge.set_controller(["tcp:127.0.0.1:6653"])
===

The similar to the first way, the OVSDB Manager library provides the
reactive
connection to OVS.
"reactive" means Ryu will wait for the incoming OVSDB connections from
the
switch side (on the other hand, "proactive" way is using "ryu.lib.ovs"
and it
will connect to switches from the controller side)
http://ryu.readthedocs.io/en/latest/library_ovsdb_manager.html

Example code:
===
from ryu.services.protocols.ovsdb import api as ovsdb
from ryu.services.protocols.ovsdb import event as ovsdb_event


class MyApp(app_manager.RyuApp):
     @set_ev_cls(ovsdb_event.EventNewOVSDBConnection)
     def handle_new_ovsdb_connection(self, ev):
     system_id = ev.system_id
     address = ev.client.address
     self.logger.info(
     'New OVSDB connection from system-id=%s, address=%s',
     system_id, address)

     ovsdb.set_controller(self, system_id, "s1", "tcp:127.0.0.1:6633")
===

The third way, this way might be not answer for your original question
tough,
Ryu can connect to your switches from the controller side with
"--ofp-switch-address-list" option.

Example:
$ ryu-manager --help
...(snip)...
   --ofp-switch-address-list OFP_SWITCH_ADDRESS_LIST
     list of IP address and port pairs (default
empty).
     e.g., "127.0.0.1:6653,[::1]:6653"
...(snip)...

Mostly, OVS instances on Mininet will listen on 6653+increment like;
mininet> sh ovs-vsctl show
c8fb2af7-1088-4f3e-92f7-fc09d20f7d40
     Bridge "s1"
     Controller "tcp:127.0.0.1:6653"
     Controller "ptcp:6654"  # <--- waiting for controller on 6653+1
...(snip)...
     Bridge "s2"
     Controller "tcp:127.0.0.1:6653"
     Controller "ptcp:6655"  # <--- waiting for controller on 6653+2
...(snip)...



- how do I get the list of the connected switches? Is there a simple

api

or do I need to explicitly save the various datapath? Also how do I map
a datapath to the switch name?


You can use "ryu.app.ofctl.app" for such purpose.
Please refer to the following mail for the usage example.
https://www.mail-archive.com/ryu-devel@lists.sourceforge.net/msg09357.html



Thanks,
Iwase


On 2017年12月02日 01:41, Alessandro Gaballo wrote:

Hi, I have 2 questions:

- how do I set the IP address of the controller?
- how do I get the list of the connected switches? Is there a simple api
or do I need to explicitly save the various datapath? Also how do I map
a datapath to the switch name?

Re: [Ryu-devel] Flow removed handler fails , Cannot parse header in OF version 1.5

[rahul b]

Hi Iwase,

Yes, i intend to use, OF 1.5 only.
Thanks for your help on this issue.!

Regards,
Rahul




On Tuesday, December 5, 2017, Iwase Yusuke  wrote:

> Hi Rahul,
>
> Could you keep the Ryu-devel mailing list?
>
> Well... if you keep this change on only your local, I think it has no side
> effect with the OpenFlow 1.3-1.5.
> It seems to replace the parser for OFPT_FLOW_REMOVED message as expected.
> With the OpenFlow 1.0-1.2, it might have some problems, but you intend to
> use
> only 1.5, right?
>
> Thanks,
> Iwase
>
>
> On 2017年12月05日 00:35, rahul b wrote:
>
>> Hi Iwase,
>> Thanks for taking your time to explain the problem.
>>
>> Flow removed handler is  a very critical piece for me, So i am planning
>> to put in a hack in *"ryu/ofproto/ofproto_parser.py" *as follows.
>>
>>   if(msg_type == 11):
>>  LOG.info("Overriding the Parser Version for  ofp_type 11")
>> *msg_parser = _MSG_PARSERS.get(4)  # use OF 1.3 parser*
>> else:
>>  msg_parser = _MSG_PARSERS.get(version)
>>
>> with this hack, i am able to decode the ofp_type 11 message.
>>
>> I Wanted to know as per your knowledge do you think this could cause any
>> side effects/errors in any other features.?
>>
>> Thanks & Regards,
>> Rahul
>>
>>
>> On Mon, Dec 4, 2017 at 10:12 AM, Iwase Yusuke > > wrote:
>>
>> Hi Rahul,
>>
>> I manually decoded the binary data OVS sent, OVS does not seem to
>> follow the
>> OFPT_FLOW_REMOVED message format which the OpenFlow Spec 1.5 defines.
>>
>> For example, I received the following message on my environment;
>> ===
>> Encountered an error while parsing OpenFlow packet from switch. This
>> implies
>> the switch sent a malformed OpenFlow packet. version 0x06 msg_type 11
>> msg_len 72 xid 0 buf 0x06 0x0b 0x00 0x48 0x00 0x00 0x00 0x00 0x00
>> 0x00 0x00
>> 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x02 0x00 0x00 0x00 0x00 0x25 0x0d
>> 0xb5
>> 0x85 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x03
>> 0x00
>> 0x00 0x00 0x00 0x00 0x00 0x00 0xee 0x00 0x01 0x00 0x16 0x80 0x00 0x00
>> 0x04
>> 0x00 0x00 0x00 0x01 0x80 0x00 0x06 0x06 0xfe 0x97 0x30 0x28 0x44 0xad
>> 0x00 0x00
>> ===
>>
>> "buf 0x06 0x0b 0x00 ..." shows the binary data which Ryu received
>> from OVS.
>> And the OpenFlow Spec 1.5 defines the the OFPT_FLOW_REMOVED message
>> like;
>> ===
>> struct ofp_flow_removed {
>>struct ofp_header {
>>  uint8_t version;  /* OFP_VERSION. */
>>  uint8_t type; /* One of the OFPT_ constants. */
>>  uint16_t length;  /* Length including this ofp_header. */
>>  uint32_t xid; /* Transaction id associated with this packet.
>>   Replies use the same id as was in the
>> request
>>   to facilitate pairing. */
>>} header;
>>uint8_t table_id; /* ID of the table */
>>uint8_t reason;   /* One of OFPRR_*. */
>>uint16_t priority;/* Priority level of flow entry. */
>>uint16_t idle_timeout;/* Idle timeout from original flow mod.
>> */
>>uint16_t hard_timeout;/* Hard timeout from original flow mod.
>> */
>>uint64_t cookie;  /* Opaque controller-issued identifier.
>> */
>>struct ofp_match match;   /* Description of fields. Variable size.
>> */
>>//struct ofp_stats stats; /* Statistics list. Variable size. */
>> };
>> ===
>>
>> If follows the above format;
>> ===
>> struct ofp_header {
>>0x06 version
>>0x0b type (= OFPT_FLOW_REMOVED(11))
>>0x00 0x48 length
>>0x00 0x00 0x00 0x00 xid
>> }
>> 0x00 table_id
>> 0x00 reason
>> 0x00 0x00 priority
>> 0x00 0x00 idle_timeout
>> 0x00 0x00 hard_timeout
>> // "0x00 0x01 0x02 0x00" is a part of cookie ...? match ...?
>>...(snip)...
>> ===
>>
>> Please confirm OVS supports the OFPT_FLOW_REMOVED message with
>> OpenFlow 1.5.
>> To follow the OpenFlow Spec 1.5, it is required to support "EXT-334",
>> it might
>> be on the TODOs of OVS project.
>> https://github.com/openvswitch/ovs/blob/master/Documentation
>> /topics/openflow.rst#openflow-15-only
>> > n/topics/openflow.rst#openflow-15-only>
>>
>> I read some source code of OVS, the OFPT_FLOW_REMOVED message is not
>> updated
>> from the format of OpenFlow 1.1...
>> https://github.com/openvswitch/ovs/blob/99cf99597ffa9f09e66d
>> 646d04de8d1c7e6d52c8/lib/ofp-util.c#L3306
>> > d646d04de8d1c7e6d52c8/lib/ofp-util.c#L3306>
>>
>>
>> Thanks,
>> Iwase
>>
>> On 2017年12月01日 23:38, rahul b wrote:
>>
>> Hi i am using,
>>
>> (Open vSwitch) 2.7.4
>> DB Schema 7.14.0
>>
>> Openflow version 1.5
>>
>>  

Re: [Ryu-devel] Datapath issue

[Iwase Yusuke]

Hi,

> " Datapath in process of terminating; send() to 10.0.0.100 discarded "

This message shows Ryu could not send a message because the connection to your
switch was already disconnected and "send_loop" thread was closed.

Please confirm that the connection between controller-switch kept established.
If keeping the connection is difficult, I guess you need to wait for the
connection re-establishment before sending stats requests.

Example:

Your AppDatapath Your SW
   |   |  disconnected  |
   |   |X---|
   |   send_msg()  ||
   |-->||
   |   |(*) |  (*) output message you reported
   |   |reconnect   |
   | SwitchFeatures ev ||
   |<--||
   |   ||
 Restart
 stats loop here

Please note when reconnecting to your switch, a new Datapath instance will be
created, so the stored Datapath instance needs to be replaced by the new one.

Thanks,
Iwase

On 2017年12月05日 00:27, shahid javed wrote:

Hi All,

I am trying to get switch status updates under a link high load, I have the 
following method which sends request to switches to reply with their stats. The 
issue I am having is when a packet gets dropped due to high load I am not able 
to resend the packet. I tried the --verbose to get the debug log and I get the 
following:


" Datapath in process of terminating; send() to 10.0.0.100 discarded "

def send_stats_requests(self):

     for switchAddress in range(100,106):

    # I have stored all datapath objects in a dictionary with key as 
address of switch

     state = self.dp.get(switchAddress,9)[1]

     if state == 0:
     datapath = self.dp.get(switchAddress)[0]
     ofp = datapath.ofproto
     ofp_parser = datapath.ofproto_parser
     req =  ofp_parser.OFPDescStatsRequest(datapath,0)

     datapath.send_msg(req)

     elif state == 1:
     print str(switchAddress) + ' Status Recieved'

     self._timer = Timer(6, self.send_stats_requests)
     self._timer.start()


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot



___
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel

Re: [Ryu-devel] Flow removed handler fails , Cannot parse header in OF version 1.5

[Iwase Yusuke]

Hi Rahul,

Could you keep the Ryu-devel mailing list?

Well... if you keep this change on only your local, I think it has no side
effect with the OpenFlow 1.3-1.5.
It seems to replace the parser for OFPT_FLOW_REMOVED message as expected.
With the OpenFlow 1.0-1.2, it might have some problems, but you intend to use
only 1.5, right?

Thanks,
Iwase


On 2017年12月05日 00:35, rahul b wrote:

Hi Iwase,
Thanks for taking your time to explain the problem.

Flow removed handler is  a very critical piece for me, So i am planning to put 
in a hack in *"ryu/ofproto/ofproto_parser.py" *as follows.


  if(msg_type == 11):
         LOG.info("Overriding the Parser Version for  ofp_type 11")
*msg_parser = _MSG_PARSERS.get(4)  # use OF 1.3 parser*
else:
         msg_parser = _MSG_PARSERS.get(version)

with this hack, i am able to decode the ofp_type 11 message.

I Wanted to know as per your knowledge do you think this could cause any side 
effects/errors in any other features.?


Thanks & Regards,
Rahul


On Mon, Dec 4, 2017 at 10:12 AM, Iwase Yusuke > wrote:


Hi Rahul,

I manually decoded the binary data OVS sent, OVS does not seem to follow the
OFPT_FLOW_REMOVED message format which the OpenFlow Spec 1.5 defines.

For example, I received the following message on my environment;
===
Encountered an error while parsing OpenFlow packet from switch. This implies
the switch sent a malformed OpenFlow packet. version 0x06 msg_type 11
msg_len 72 xid 0 buf 0x06 0x0b 0x00 0x48 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x02 0x00 0x00 0x00 0x00 0x25 0x0d 0xb5
0x85 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x03 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0xee 0x00 0x01 0x00 0x16 0x80 0x00 0x00 0x04
0x00 0x00 0x00 0x01 0x80 0x00 0x06 0x06 0xfe 0x97 0x30 0x28 0x44 0xad 0x00 
0x00
===

"buf 0x06 0x0b 0x00 ..." shows the binary data which Ryu received from OVS.
And the OpenFlow Spec 1.5 defines the the OFPT_FLOW_REMOVED message like;
===
struct ofp_flow_removed {
   struct ofp_header {
     uint8_t version;  /* OFP_VERSION. */
     uint8_t type;     /* One of the OFPT_ constants. */
     uint16_t length;  /* Length including this ofp_header. */
     uint32_t xid;     /* Transaction id associated with this packet.
                          Replies use the same id as was in the request
                          to facilitate pairing. */
   } header;
   uint8_t table_id;         /* ID of the table */
   uint8_t reason;           /* One of OFPRR_*. */
   uint16_t priority;        /* Priority level of flow entry. */
   uint16_t idle_timeout;    /* Idle timeout from original flow mod. */
   uint16_t hard_timeout;    /* Hard timeout from original flow mod. */
   uint64_t cookie;          /* Opaque controller-issued identifier. */
   struct ofp_match match;   /* Description of fields. Variable size. */
   //struct ofp_stats stats; /* Statistics list. Variable size. */
};
===

If follows the above format;
===
struct ofp_header {
   0x06 version
   0x0b type (= OFPT_FLOW_REMOVED(11))
   0x00 0x48 length
   0x00 0x00 0x00 0x00 xid
}
0x00 table_id
0x00 reason
0x00 0x00 priority
0x00 0x00 idle_timeout
0x00 0x00 hard_timeout
// "0x00 0x01 0x02 0x00" is a part of cookie ...? match ...?
   ...(snip)...
===

Please confirm OVS supports the OFPT_FLOW_REMOVED message with OpenFlow 1.5.
To follow the OpenFlow Spec 1.5, it is required to support "EXT-334", it 
might
be on the TODOs of OVS project.

https://github.com/openvswitch/ovs/blob/master/Documentation/topics/openflow.rst#openflow-15-only



I read some source code of OVS, the OFPT_FLOW_REMOVED message is not updated
from the format of OpenFlow 1.1...

https://github.com/openvswitch/ovs/blob/99cf99597ffa9f09e66d646d04de8d1c7e6d52c8/lib/ofp-util.c#L3306




Thanks,
Iwase

On 2017年12月01日 23:38, rahul b wrote:

Hi i am using,

(Open vSwitch) 2.7.4
DB Schema 7.14.0

Openflow version 1.5

On deleting a flow i am encountering this error, this is a message sent
in response to the flow rule being removed.

However  the flow deletion is going successfully, but Ryu is not able to
parse this message i believe.


Encountered an error while parsing OpenFlow packet from switch. This
implies the switch sent a malformed OpenFlow packet. version 0x06
msg_type 11 msg_len 72 xid 0 buf 0x06 0x0b 0x00 0x48 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x07 0xd0 0x00 0x64 0x02 0x00 0x00 

Re: [Ryu-devel] SET CONTROLLER IP - GET CONNECTED SWITCHES

[Alessandro Gaballo]

Hi,
the API you suggested regarding the switch name is not what I need 
because it simply returns the datapath object, which I already have 
since I'm saving them when a new packet is received. What I need is the 
name of the switch, the one I'm using in Mininet to be clear. Is that 
simply the id? So s1 is the datapath with id=1 and so on? I also noticed 
the switches with different names such as (si1, sio1) are not able to 
connect to the controller.

Concerning the setting of the controller address I don't get the correct 
flow.
I thought there was a simply api to use in my ryu application that would 
define the ip and then make all the switches connect to that address 
from mininet. With the examples you gave me I see multiple port and 
addresses, so I'm still not sure.

Thanks,
Alessandro


On 04/12/2017 00:05, Iwase Yusuke wrote:

> Hi again,
>
> > - how do I set the IP address of the controller?
>
> You are using Open vSwitch, right?
> If so, you need to configure your switches via OVSDB (like "ovs-vsctl" 
> command),
> and Ryu provide some options to use OVSDB.
>
> First, it might be the easiest way I guess, you can use the APIs of
> "ryu.lib.ovs".
> The usage and arguments are very similar to "ovs-vsctl" command.
> https://github.com/osrg/ryu/blob/63f81837fd73cc31edbfe9ba6814ae3f38e34a16/ryu/lib/ovs/bridge.py#L133
>  
>
>
> In this case, you need to set the OVSDB manager address to your OVS 
> before
> Ryu connect to your switches like;
> $ ovs-vsctl set-manager "ptcp:6640"
>
> Example code:
> ===
> from ryu.cfg import CONF
> from ryu.lib.ovs import bridge
>
> ovs_bridge = bridge.OVSBridge(CONF, 1, "tcp:127.0.0.1:6640")
> ovs_bridge.set_controller(["tcp:127.0.0.1:6653"])
> ===
>
> The similar to the first way, the OVSDB Manager library provides the 
> reactive
> connection to OVS.
> "reactive" means Ryu will wait for the incoming OVSDB connections from 
> the
> switch side (on the other hand, "proactive" way is using "ryu.lib.ovs" 
> and it
> will connect to switches from the controller side)
> http://ryu.readthedocs.io/en/latest/library_ovsdb_manager.html
>
> Example code:
> ===
> from ryu.services.protocols.ovsdb import api as ovsdb
> from ryu.services.protocols.ovsdb import event as ovsdb_event
>
>
> class MyApp(app_manager.RyuApp):
>     @set_ev_cls(ovsdb_event.EventNewOVSDBConnection)
>     def handle_new_ovsdb_connection(self, ev):
>     system_id = ev.system_id
>     address = ev.client.address
>     self.logger.info(
>     'New OVSDB connection from system-id=%s, address=%s',
>     system_id, address)
>
>     ovsdb.set_controller(self, system_id, "s1", "tcp:127.0.0.1:6633")
> ===
>
> The third way, this way might be not answer for your original question 
> tough,
> Ryu can connect to your switches from the controller side with
> "--ofp-switch-address-list" option.
>
> Example:
> $ ryu-manager --help
> ...(snip)...
>   --ofp-switch-address-list OFP_SWITCH_ADDRESS_LIST
>     list of IP address and port pairs (default 
> empty).
>     e.g., "127.0.0.1:6653,[::1]:6653"
> ...(snip)...
>
> Mostly, OVS instances on Mininet will listen on 6653+increment like;
> mininet> sh ovs-vsctl show
> c8fb2af7-1088-4f3e-92f7-fc09d20f7d40
>     Bridge "s1"
>     Controller "tcp:127.0.0.1:6653"
>     Controller "ptcp:6654"  # <--- waiting for controller on 6653+1
> ...(snip)...
>     Bridge "s2"
>     Controller "tcp:127.0.0.1:6653"
>     Controller "ptcp:6655"  # <--- waiting for controller on 6653+2
> ...(snip)...
>
>
> > - how do I get the list of the connected switches? Is there a simple 
> api
> > or do I need to explicitly save the various datapath? Also how do I map
> > a datapath to the switch name?
>
> You can use "ryu.app.ofctl.app" for such purpose.
> Please refer to the following mail for the usage example.
> https://www.mail-archive.com/ryu-devel@lists.sourceforge.net/msg09357.html 
>
>
>
> Thanks,
> Iwase
>
>
> On 2017年12月02日 01:41, Alessandro Gaballo wrote:
>> Hi, I have 2 questions:
>>
>> - how do I set the IP address of the controller?
>> - how do I get the list of the connected switches? Is there a simple api
>> or do I need to explicitly save the various datapath? Also how do I map
>> a datapath to the switch name?
>>
>> --
>>  
>>
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Ryu-devel mailing list
>> Ryu-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net

[Ryu-devel] Datapath issue

[shahid javed]

Hi All,

I am trying to get switch status updates under a link high load, I have the
following method which sends request to switches to reply with their stats.
The issue I am having is when a packet gets dropped due to high load I am
not able to resend the packet. I tried the --verbose to get the debug log
and I get the following:

" Datapath in process of terminating; send() to 10.0.0.100 discarded "

def send_stats_requests(self):

for switchAddress in range(100,106):

   # I have stored all datapath objects in a dictionary with key as
address of switch
state = self.dp.get(switchAddress,9)[1]

if state == 0:
datapath = self.dp.get(switchAddress)[0]
ofp = datapath.ofproto
ofp_parser = datapath.ofproto_parser
req =  ofp_parser.OFPDescStatsRequest(datapath,0)

datapath.send_msg(req)

elif state == 1:
print str(switchAddress) + ' Status Recieved'

self._timer = Timer(6, self.send_stats_requests)
self._timer.start()
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel