[Ryu-devel] Fw: [PATCH 0/4] mrtlib: Support RFC8050

[IWASE Yusuke]

Dear Fujita-San,

Great to see you again.

Could you review these patches when you have time?


Thanks,
Iwase


Begin forwarded message:

Date: Fri, 30 Mar 2018 11:33:54 +0900
From: IWASE Yusuke 
To: ryu-devel@lists.sourceforge.net
Cc: IWASE Yusuke 
Subject: [PATCH 0/4] mrtlib: Support RFC8050


The following pathes fix "ryu.lib.mrtlib" to support RFC8050 (Multi-Threaded
Routing Toolkit (MRT) Routing Information Export Format with BGP Additional
Path Extensions).

IWASE Yusuke (4):
  mrtlib: Missing subclass for SUBTYPE_RIB_*_MULTICAST
  mrtlib: Support RFC8050
  test_mrtlib: Test cases for ADD_PATH
  mrtlib: Define JSON representation types

 ryu/lib/mrtlib.py | 190 ++
 ryu/tests/unit/lib/test_mrtlib.py |  61 
 2 files changed, 233 insertions(+), 18 deletions(-)

--
2.7.4



-- 
IWASE Yusuke 

--
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] Query in Bgp neighbor_add api

[Iwase Yusuke]

Hi Suresh,

Does your patch fix other problem at the following?
https://github.com/sureshkvl/ryu/commit/aebf3974d121134931d79805b35f8f252db9d7a5#diff-161a69adc7e5dd2fb041599033e9089bL1001

FYI, I made a similar patch for this issue.
Please refer to the attached patch.

Thanks,
Iwase

On 2018年06月26日 09:04, knet solutions wrote:

Hi IWAMOTO,

I updated the changes in this commit (on top of your route reflector change)

https://github.com/sureshkvl/ryu/commit/aebf3974d121134931d79805b35f8f252db9d7a5

Could you review?

How to submit this in upstream?.  Is it pull request or some other process?

Thanks
suresh



On Thu, Jun 21, 2018 at 8:18 AM, IWAMOTO Toshihiro <mailto:iwam...@valinux.co.jp>> wrote:


On Thu, 21 Jun 2018 00:39:17 +0900,
knet solutions wrote:
 >
 > [1  ]
 > [1.1  ]
> In peer.py file,  PEER port number is hard coded to BGP Port Num.
> 
>                 peer_address = (self._neigh_conf.ip_address,

>                                 const.STD_BGP_SERVER_PORT_NUM)
> 
> I think, it can be configurable parameter from the API.


It should default to 179 but it's good to be configurable.
Can you make a patch?

 > On Wed, Jun 20, 2018 at 4:15 PM, knet solutions mailto:knetsolutio...@gmail.com>>
 > wrote:
 >
 > > Hi,
 > >
 > > neighbor_add api doesnot have  the "port number" parameter.
 > >
 > >
 > > For examples
 > >
 > > Traditional BGP Router 
<--->

 > > RYU BGP Speaker
 > > (BGP runs in port 180)
 > >
 > >
 > >
 > > In the RYU BGP Speaker,
 > > bgp_speaker.neighbor_add(remote_router_id, remote_as)
 > >
 > > no option to specify the remote port number.
 > >
 > > Any suggestions?
 > >
 > > Thanks
 > > suresh
 > >




--
*/Regards,
/*
*/Knet solutions./*

https://github.com/knetsolutions/KNet
http://knet-topology-builder.readthedocs.io/
http://knetsolutions.in/



--
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

>From 14f48def88012f779ac30d2068e4c7c8b1948233 Mon Sep 17 00:00:00 2001
From: IWASE Yusuke 
Date: Wed, 27 Jun 2018 16:13:25 +0900
Subject: [PATCH] BGPSpeaker: Enable to specify remote port for neighbor

Currently, the remote port of neighbor is the hard-coded value 179.

This patch enables to specify the remote port of neighbor in
"BGPSpeaker.neighbor_add()" API.

Suggested-by: Suresh Kumar 
Signed-off-by: IWASE Yusuke 
---
 ryu/services/protocols/bgp/bgpspeaker.py  | 34 +++
 ryu/services/protocols/bgp/peer.py|  2 +-
 .../protocols/bgp/rtconf/neighbors.py | 18 +-
 3 files changed, 38 insertions(+), 16 deletions(-)

diff --git a/ryu/services/protocols/bgp/bgpspeaker.py b/ryu/services/protocols/bgp/bgpspeaker.py
index 46cbcaf1..2f53f636 100644
--- a/ryu/services/protocols/bgp/bgpspeaker.py
+++ b/ryu/services/protocols/bgp/bgpspeaker.py
@@ -112,21 +112,23 @@ from ryu.services.protocols.bgp.rtconf.neighbors import (
 DEFAULT_CAP_MBGP_VPNV4FS,
 DEFAULT_CAP_MBGP_VPNV6FS,
 DEFAULT_CAP_MBGP_L2VPNFS,
+DEFAULT_CAP_ENHANCED_REFRESH,
+DEFAULT_CAP_FOUR_OCTET_AS_NUMBER,
+DEFAULT_CONNECT_MODE,
+REMOTE_PORT,
+DEFAULT_BGP_PORT,
+PEER_NEXT_HOP,
+PASSWORD,
+DEFAULT_IS_ROUTE_SERVER_CLIENT,
+IS_ROUTE_SERVER_CLIENT,
+DEFAULT_IS_ROUTE_REFLECTOR_CLIENT,
+IS_ROUTE_REFLECTOR_CLIENT,
+DEFAULT_IS_NEXT_HOP_SELF,
+IS_NEXT_HOP_SELF,
+CONNECT_MODE,
+LOCAL_ADDRESS,
+LOCAL_PORT,
 )
-from ryu.services.protocols.bgp.rtconf.neighbors import (
-DEFAULT_CAP_ENHANCED_REFRESH, DEFAULT_CAP_FOUR_OCTET_AS_NUMBER)
-from ryu.services.protocols.bgp.rtconf.neighbors import DEFAULT_CONNECT_MODE
-from ryu.services.protocols.bgp.rtconf.neighbors import PEER_NEXT_HOP
-from ryu.services.protocols.bgp.rtconf.neighbors import PASSWORD
-from ryu.services.protocols.bgp.rtconf.neighbors import (
-DEFAULT_IS_ROUTE_SERVER_CLIENT, IS_ROUTE_SERVER_CLIENT)
-from ryu.services.protocols.bgp.rtconf.neighbors import (
-DEFAULT_IS_ROUTE_REFLECTOR_CLIENT, IS_ROUTE_REFLECTOR_CLIENT)
-from ryu.services.protocols.bgp.rtconf.neighbors import (
-DEFAULT_IS_NEXT_HOP_SELF, IS_NEXT_HOP_SELF)
-from ryu.services.protocols.bgp.rtconf.neighbors import CONNECT_MODE
-from ryu.services.protocols.bgp.rtconf.neighbors import LOCAL_ADDRESS
-from ryu.services.protocols.bgp.rtconf.neighbors import LOCAL_PORT
 f

Re: [Ryu-devel] Query regarding Ryu

[Iwase Yusuke]

Hi Vidhu,

Unfortunately, the Zebra integration feature is not documented yet.
Please refer to the following sample application for the basic usage:
https://github.com/osrg/ryu/blob/master/ryu/services/protocols/zebra/client/sample_dumper.py

e.g.) Please note it might be required the "root" (or "quagga") user privilege
# ryu-manager --zapi-server-version 3 
ryu/services/protocols/zebra/client/sample_dumper.py


"--zapi-server-version 3" specifies to use the Zebra protocol version 3 which
used on Quagga version 1.x or later, if your Quagga is version 0.99.x or so,
please specify "--zapi-server-version 2".


Thanks,
Iwase


On 2018年06月13日 21:04, Vidhu Baggan wrote:

Dear Sir
  Appreciating your concern as I have already implemented BGP in Quagga but 
could not find the way out to connect BGP (Ryu) and Quagga .

Kindly guide.
Great Regards

On Wed, Jun 13, 2018, 1:15 PM Iwase Yusuke <mailto:iwase.yusu...@gmail.com>> wrote:


Hi Vidhu,

Ryu BGP Speaker does not have data-plane to forward packets. To implement
forwarding rules, Ryu supposes to connect to some OpenFlow switches or 
Linux IP
routing stack (like Zebra). So the approach to assign IP address to 
interface is
depending on how to realize data-plane with Ryu, I guess.

Thanks,
Iwase

On 2018年06月12日 19:14, Vidhu Baggan wrote:
 > Dear Sir
 >
 > Kindly guide that in which file, we  can assign IP addresses to
interfaces in a
 > RYU-BGP router.
 >
 > Thanking you in anticipation.
 >
 >
 >
 > /Vidhu Baggan/
 > Associate Professor | School of Computer Sciences
 > Chitkara Institute of Engineering & Technology
 >
 > .
 > Mail
 >
 > CAMPUS
 > Chandigarh - Patiala National Highway,
 > Distt. Patiala - 140401.
 > (Around 35 kms from Chandigarh)
 >
 >
 >
 >
 >
 >
 > On Mon, Dec 25, 2017 at 6:38 AM, Iwase Yusuke mailto:iwase.yusu...@gmail.com>
 > <mailto:iwase.yusu...@gmail.com <mailto:iwase.yusu...@gmail.com>>> wrote:
 >
 >     Hi,
 >
 >     You mean modifying the rules of the BGP state transition (BGP FSM)?
 >     You need to original rules?
 >
 >     Ryu maintains the FSM state at "ryu/services/protocols/bgp/peer.py",
 >     so you can modify the rules if writing your code on it.
 >
 >     For example, Ryu will move on to ESTABLISHED state when received a
KEEPALIVE
 >     message if its states is OPEN_CONFIRM.
 >

https://github.com/osrg/ryu/blob/master/ryu/services/protocols/bgp/peer.py#L1987-L1992
 >   
  <https://github.com/osrg/ryu/blob/master/ryu/services/protocols/bgp/peer.py#L1987-L1992>

 >
 >     Thanks,
 >     Iwase
 >
 >
 >     On 2017年12月25日 09:52, Vidhu Baggan wrote:
 >
 >         Dear Sir
 >         Can we modify the connection states cycle of BGP.
 >         Thanking you in anticipation.
 >         Regards
 >
 >         On Dec 25, 2017 6:06 AM, "Iwase Yusuke" mailto:iwase.yusu...@gmail.com>
 >         <mailto:iwase.yusu...@gmail.com <mailto:iwase.yusu...@gmail.com>>
<mailto:iwase.yusu...@gmail.com <mailto:iwase.yusu...@gmail.com>
 >         <mailto:iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>>>> wrote:
 >
 >              Hi,
 >
 >              Could you be more specific?
 >              What does "modify" exactly mean?
 >
 >              Thanks,
 >              Iwase
 >
 >              On 2017年12月23日 09:43, Vidhu Baggan wrote:
 >
 >                  Dear Sir
 >                  Kindly guide that can we modify bgp through Ryu.
 >                  Thanking you in anticipation.
 >                  Regards
 >
 >
 >
 >   
  --

 >                  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 <mailto:Ryu-devel@lists.sourceforge.net>
<mailto:Ryu-devel@lists.sourceforge.net
<mailto:Ryu-devel@lists.sourceforge.net>>
 >         <mailto:Ryu-devel@lists.sourceforge.net
<m

Re: [Ryu-devel] Query regarding Ryu

[Iwase Yusuke]

Hi Vidhu,

Ryu BGP Speaker does not have data-plane to forward packets. To implement
forwarding rules, Ryu supposes to connect to some OpenFlow switches or Linux IP
routing stack (like Zebra). So the approach to assign IP address to interface is
depending on how to realize data-plane with Ryu, I guess.

Thanks,
Iwase

On 2018年06月12日 19:14, Vidhu Baggan wrote:

Dear Sir

Kindly guide that in which file, we  can assign IP addresses to interfaces in a 
RYU-BGP router.


Thanking you in anticipation.



/Vidhu Baggan/
Associate Professor | School of Computer Sciences
Chitkara Institute of Engineering & Technology

.
Mail

CAMPUS
Chandigarh - Patiala National Highway,
Distt. Patiala - 140401.
(Around 35 kms from Chandigarh)






On Mon, Dec 25, 2017 at 6:38 AM, Iwase Yusuke <mailto:iwase.yusu...@gmail.com>> wrote:


Hi,

You mean modifying the rules of the BGP state transition (BGP FSM)?
You need to original rules?

Ryu maintains the FSM state at "ryu/services/protocols/bgp/peer.py",
so you can modify the rules if writing your code on it.

For example, Ryu will move on to ESTABLISHED state when received a KEEPALIVE
message if its states is OPEN_CONFIRM.

https://github.com/osrg/ryu/blob/master/ryu/services/protocols/bgp/peer.py#L1987-L1992

<https://github.com/osrg/ryu/blob/master/ryu/services/protocols/bgp/peer.py#L1987-L1992>

Thanks,
Iwase


On 2017年12月25日 09:52, Vidhu Baggan wrote:

Dear Sir
Can we modify the connection states cycle of BGP.
Thanking you in anticipation.
Regards

    On Dec 25, 2017 6:06 AM, "Iwase Yusuke" mailto:iwase.yusu...@gmail.com> <mailto:iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>>> wrote:

     Hi,

     Could you be more specific?
     What does "modify" exactly mean?

     Thanks,
     Iwase

     On 2017年12月23日 09:43, Vidhu Baggan wrote:

         Dear Sir
         Kindly guide that can we modify bgp through Ryu.
         Thanking you in anticipation.
         Regards



--

         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 <mailto:Ryu-devel@lists.sourceforge.net>
<mailto:Ryu-devel@lists.sourceforge.net
<mailto:Ryu-devel@lists.sourceforge.net>>
https://lists.sourceforge.net/lists/listinfo/ryu-devel
<https://lists.sourceforge.net/lists/listinfo/ryu-devel>
         <https://lists.sourceforge.net/lists/listinfo/ryu-devel
<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 <mailto:Ryu-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/ryu-devel
<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



--
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] BGP Speakers

[Iwase Yusuke]

Hi Suresh,

Hmmm... I can not yet understand why you need to setup such topology though...
You mean you need to spawn two BGP Speakers from a single Ryu application?
If you need to maintain routes separately on SDN-Rtr1/SDN-Rtr2 and need to
select the best path for each router, the per-peer local AS setting may not be
suitable.

Thanks,
Iwase

On 2018年06月12日 20:30, knet solutions wrote:

Hi Iwase,

The use case is like below,


Rtr1---SDN-Rtr1---Rtr2--SDN-Rtr2-Rtr3


Rtr1, Rtr2, Rtr3 are traditional BGP Routers
SDN-Rtr1, and SDN-Rtr2 are BGP Speakers.


SDN-Rtr1(RYU Bgp speaker) connects to  two neighbors Rtr1 and Rtr2.
SDN-Rtr2(RYU Bgp speaker) connects to  two neighbors Rtr2 and Rtr3.

In this use case,  Any possibility of running with single BGP Speaker instance?

Thanks
Suresh


On Mon, Jun 11, 2018 at 7:30 AM, Iwase Yusuke <mailto:iwase.yusu...@gmail.com>> wrote:


Hi,

I think you need to specify the following options in order to avoid the
conflicts of listening ports.

- BGP listen host addresses (or port number)

https://github.com/osrg/ryu/blob/c29c9019ac8ab862bbc0caad7d49220f27ed0cf0/ryu/services/protocols/bgp/bgp_sample_conf.py#L51-L52

<https://github.com/osrg/ryu/blob/c29c9019ac8ab862bbc0caad7d49220f27ed0cf0/ryu/services/protocols/bgp/bgp_sample_conf.py#L51-L52>

- RPC listen host address (or port number) for BGP
   $ ryu-manager -h
     ...(snip)...
     --bgp-app-rpc-host BGP-APP_RPC_HOST
                           IP for RPC server (default: 0.0.0.0)
     --bgp-app-rpc-port BGP-APP_RPC_PORT
                           Port for RPC server (default: 50002)
     ...(snip)...

- SSH console host address (or port number) for BGP

https://github.com/osrg/ryu/blob/c29c9019ac8ab862bbc0caad7d49220f27ed0cf0/ryu/services/protocols/bgp/bgp_sample_conf.py#L400-L401

<https://github.com/osrg/ryu/blob/c29c9019ac8ab862bbc0caad7d49220f27ed0cf0/ryu/services/protocols/bgp/bgp_sample_conf.py#L400-L401>


BTW, why you need to run multiple BGP Speakers at the same time? Ryu BGP 
Speaker
supports per-peer AS number configuration, you can setup multiple 
connections
with routers in different ASs. If this feature is sufficient for your 
use-case,
it should be more appropriate than running multiple BGP Speakers.

http://ryu.readthedocs.io/en/latest/library_bgp_speaker_ref.html#ryu.services.protocols.bgp.bgpspeaker.BGPSpeaker.neighbor_add

<http://ryu.readthedocs.io/en/latest/library_bgp_speaker_ref.html#ryu.services.protocols.bgp.bgpspeaker.BGPSpeaker.neighbor_add>


Thanks,
Iwase


On 2018年06月07日 23:03, knet solutions wrote:

Can we run multiple  BGP Speakers in the RYU application?

-- 
*/Regards,

/*
*/Knet solutions./*

https://github.com/knetsolutions/KNet
<https://github.com/knetsolutions/KNet>
http://knet-topology-builder.readthedocs.io/
<http://knet-topology-builder.readthedocs.io/>
http://knetsolutions.in/




--
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 <mailto:Ryu-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/ryu-devel
<https://lists.sourceforge.net/lists/listinfo/ryu-devel>




--
*/Regards,
/*
*/Knet solutions./*

https://github.com/knetsolutions/KNet
http://knet-topology-builder.readthedocs.io/
http://knetsolutions.in/



--
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] [PATCH v2 0/3] BGPSpeaker: Advertise local routes to RR clients

[IWASE Yusuke]

The following patches update v2 patches for Iwamoto-San's comments to
drop ignoring W605 because W605 would be a syntax error in python 3.10.
  https://bugs.python.org/issue32912

With this update, the following patches should be applied with
Iwamoto-San's patches:
  [Ryu-devel] [PATCH 1/2] Fix pycodestyle W605 warnings
  [Ryu-devel] [PATCH 2/2] nx_actions: Fix NXActionSetTunnel docstring

v1:
The current implementation misses the mandatory attributes when sending
locally generated routes to its Route Reflector (RR) clients, then the
clients will reject the received routes.

The following patches fix to add or update attributes to for sending
locally generated routes its RR clients and include some improvements.

IWASE Yusuke (3):
  BGPSpeaker: Advertise local routes to RR clients
  pycodestyle: Ignore W504
  BGPSpeaker: Fix BGP state string conversion

 ryu/services/protocols/bgp/peer.py | 51 ++
 tox.ini|  5 +--
 2 files changed, 26 insertions(+), 30 deletions(-)

--
2.17.1


--
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] [PATCH v2 3/3] BGPSpeaker: Fix BGP state string conversion

[IWASE Yusuke]

The constants BGP_FSM_* are str type values and not callable.

Signed-off-by: IWASE Yusuke 
---
 ryu/services/protocols/bgp/peer.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ryu/services/protocols/bgp/peer.py 
b/ryu/services/protocols/bgp/peer.py
index 2a0e2a9f..2c6e3898 100644
--- a/ryu/services/protocols/bgp/peer.py
+++ b/ryu/services/protocols/bgp/peer.py
@@ -2000,8 +2000,8 @@ class Peer(Source, Sink, NeighborConfListener, Activity):
 # Open/Notification messages are currently handled by protocol and
 # nothing is done inside peer, so should not see them here.
 raise ValueError('Peer does not support handling of %s'
- ' message during % state' %
- (msg, self.state.bgp_state()))
+ ' message during %s state' %
+ (msg, self.state.bgp_state))

 def _handle_err_sor_msg(self, afi, safi):
 # Check if ERR capability is enabled for this peer.
--
2.17.1


--
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] [PATCH v2 2/3] pycodestyle: Ignore W504

[IWASE Yusuke]

Signed-off-by: IWASE Yusuke 
---
 tox.ini | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tox.ini b/tox.ini
index 758d1661..c1759acb 100644
--- a/tox.ini
+++ b/tox.ini
@@ -52,14 +52,15 @@ commands =

 [pycodestyle]
 exclude = pbr-*,.venv,.tox,.git,doc,dist,tools,vcsversion.py,.pyc,ryu/contrib
-# W503: line break occurred before a binary operator
+# W503: line break before binary operator
+# W504: line break after binary operator
 # E116: unexpected indentation (comment)
 # E402: module level import not at top of file
 # E501: line too long (>79 characters)
 # E722: do not use bare except, specify exception instead
 # E731: do not assign a lambda expression, use a def
 # E741: do not use variables named 'l', 'O', or 'I'
-ignore = W503,E116,E402,E501,E722,E731,E741
+ignore = W503,W504,E116,E402,E501,E722,E731,E741

 [pep8]
 exclude = pbr-*,.venv,.tox,.git,doc,dist,tools,vcsversion.py,.pyc,ryu/contrib
--
2.17.1


--
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] [PATCH 2/3] pycodestyle: Ignore W504 and W605

[Iwase Yusuke]

Hi,

Thank you for reviewing my patches!


W605 would be a syntax error in python 3.10.
https://bugs.python.org/issue32912

There are tens of docstrings like this in nx_actions.py, which
violates W605.

..
  set_field:value[/mask]->dst
..

++
| **set_field**\:\ *value*\ **[**\/\ *mask*\ **]**\->\ *dst* |
++

We can just add 'r' to the head of the docstring to make it a
rawstring, but I'd like to simplify this to

   .. option:: set_field:value[/mask]->dst

That's not as pretty as the current doc but it's easier to maintain.

What do you think?


I agree with you.
The maintainability should take precedence than the pretty looks.
Also nobody can immediately understand
> ++
> | **set_field**\:\ *value*\ **[**\/\ *mask*\ **]**\->\ *dst* |
> ++
will represent
>   set_field:value[/mask]->dst
I guess though...


> On second thought, I just used raw strings (r"""foo""").
> If we won't change this docstring in future, smaller patches would be
> better.

Thanks, it looks good to me.


On 2018年06月13日 12:06, IWAMOTO Toshihiro wrote:

On Tue, 12 Jun 2018 17:26:50 +0900,
IWAMOTO Toshihiro wrote:


On Tue, 12 Jun 2018 15:17:35 +0900,
IWASE Yusuke wrote:


Signed-off-by: IWASE Yusuke 
---
  tox.ini | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tox.ini b/tox.ini
index 758d1661..5d8712e1 100644
--- a/tox.ini
+++ b/tox.ini
@@ -52,14 +52,16 @@ commands =
  
  [pycodestyle]

  exclude = pbr-*,.venv,.tox,.git,doc,dist,tools,vcsversion.py,.pyc,ryu/contrib
-# W503: line break occurred before a binary operator
+# W503: line break before binary operator
+# W504: line break after binary operator
+# W605: invalid escape sequence


W605 would be a syntax error in python 3.10.
https://bugs.python.org/issue32912

There are tens of docstrings like this in nx_actions.py, which
violates W605.

 ..
   set_field:value[/mask]->dst
 ..

 ++
 | **set_field**\:\ *value*\ **[**\/\ *mask*\ **]**\->\ *dst* |
 ++

We can just add 'r' to the head of the docstring to make it a
rawstring, but I'd like to simplify this to

.. option:: set_field:value[/mask]->dst

That's not as pretty as the current doc but it's easier to maintain.

What do you think?


On second thought, I just used raw strings (r"""foo""").
If we won't change this docstring in future, smaller patches would be
better.

--
IWAMOTO Toshihiro



--
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] [PATCH 1/3] BGPSpeaker: Advertise local routes to RR clients

[IWASE Yusuke]

The current implementation misses the mandatory attributes when sending
locally generated routes to its Route Reflector (RR) clients, then the
clients will reject the received routes.

This patch fixes to add or update attributes to for sending locally
generated routes its RR clients.

Signed-off-by: IWASE Yusuke 
---
 ryu/services/protocols/bgp/peer.py | 47 +-
 1 file changed, 21 insertions(+), 26 deletions(-)

diff --git a/ryu/services/protocols/bgp/peer.py 
b/ryu/services/protocols/bgp/peer.py
index 70b486c0..2a0e2a9f 100644
--- a/ryu/services/protocols/bgp/peer.py
+++ b/ryu/services/protocols/bgp/peer.py
@@ -989,37 +989,32 @@ class Peer(Source, Sink, NeighborConfListener, Activity):
 elif self.is_route_server_client:
 nlri_list = [path.nlri]
 new_pathattr.extend(pathattr_map.values())
-elif self.is_route_reflector_client:
-nlri_list = [path.nlri]
+else:
+if self.is_route_reflector_client:
+# Append ORIGINATOR_ID attribute if not already exist.
+if BGP_ATTR_TYPE_ORIGINATOR_ID not in pathattr_map:
+originator_id = path.source
+if originator_id is None:
+originator_id = self._common_conf.router_id
+elif isinstance(path.source, Peer):
+originator_id = path.source.ip_address
+new_pathattr.append(
+BGPPathAttributeOriginatorId(value=originator_id))
 
-# Append ORIGINATOR_ID attribute if not already exists.
-if BGP_ATTR_TYPE_ORIGINATOR_ID not in pathattr_map:
-originator_id = path.source
-if originator_id is None:
-originator_id = self._common_conf.router_id
-elif isinstance(path.source, Peer):
-originator_id = path.source.ip_address
-new_pathattr.append(
-BGPPathAttributeOriginatorId(value=originator_id))
-
-# Append CLUSTER_LIST attribute if not already exists.
-if BGP_ATTR_TYPE_CLUSTER_LIST not in pathattr_map:
-new_pathattr.append(
-BGPPathAttributeClusterList(
-[self._common_conf.cluster_id]))
-
-for t, path_attr in pathattr_map.items():
-if t == BGP_ATTR_TYPE_CLUSTER_LIST:
-# Append own CLUSTER_ID into CLUSTER_LIST attribute
-# if already exists.
-cluster_list = list(path_attr.value)
+# Preppend own CLUSTER_ID into CLUSTER_LIST attribute if exist.
+# Otherwise append CLUSTER_LIST attribute.
+cluster_lst_attr = pathattr_map.get(BGP_ATTR_TYPE_CLUSTER_LIST)
+if cluster_lst_attr:
+cluster_list = list(cluster_lst_attr.value)
 if self._common_conf.cluster_id not in cluster_list:
-cluster_list.append(self._common_conf.cluster_id)
+cluster_list.insert(0, self._common_conf.cluster_id)
 new_pathattr.append(
 BGPPathAttributeClusterList(cluster_list))
 else:
-new_pathattr.append(path_attr)
-else:
+new_pathattr.append(
+BGPPathAttributeClusterList(
+[self._common_conf.cluster_id]))
+
 # Supported and un-supported/unknown attributes.
 origin_attr = None
 nexthop_attr = None
-- 
2.17.1


--
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] [PATCH 0/3] BGPSpeaker: Advertise local routes to RR clients

[IWASE Yusuke]

The current implementation misses the mandatory attributes when sending
locally generated routes to its Route Reflector (RR) clients, then the
clients will reject the received routes.

The following patches fix to add or update attributes to for sending
locally generated routes its RR clients and include some improvements.

IWASE Yusuke (3):
  BGPSpeaker: Advertise local routes to RR clients
  pycodestyle: Ignore W504 and W605
  BGPSpeaker: Fix BGP state string conversion

 ryu/services/protocols/bgp/peer.py | 51 ++
 tox.ini|  6 ++--
 2 files changed, 27 insertions(+), 30 deletions(-)

--
2.17.1


--
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] [PATCH 3/3] BGPSpeaker: Fix BGP state string conversion

[IWASE Yusuke]

The constants BGP_FSM_* are str type values and not callable.

Signed-off-by: IWASE Yusuke 
---
 ryu/services/protocols/bgp/peer.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ryu/services/protocols/bgp/peer.py 
b/ryu/services/protocols/bgp/peer.py
index 2a0e2a9f..2c6e3898 100644
--- a/ryu/services/protocols/bgp/peer.py
+++ b/ryu/services/protocols/bgp/peer.py
@@ -2000,8 +2000,8 @@ class Peer(Source, Sink, NeighborConfListener, Activity):
 # Open/Notification messages are currently handled by protocol and
 # nothing is done inside peer, so should not see them here.
 raise ValueError('Peer does not support handling of %s'
- ' message during % state' %
- (msg, self.state.bgp_state()))
+ ' message during %s state' %
+ (msg, self.state.bgp_state))
 
 def _handle_err_sor_msg(self, afi, safi):
 # Check if ERR capability is enabled for this peer.
-- 
2.17.1


--
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] Query BGP speaker

[Iwase Yusuke]

Hi,

Hmmm... the current implementation seems not to suppose to have the locally
generated routes when configured itself as a Route Reflector. Only supposed to
reflect the received routes.

The attached patch fixes this problem?

Thanks,
Iwase

On 2018年06月11日 20:36, knet solutions wrote:

Hi Iwase,

When i configure route_reflector,  RYU BGP Speaker couldnt establish the 
comminication with traditional bird router.

My code snippet is as below,

    # code snippet

     self.bgp_speaker = BGPSpeaker(64511, router_id,
   ssh_console=True, ssh_port=4999,
   ssh_host='localhost',
   
best_path_change_handler=self.best_path_change_handler )
    self.bgp_speaker.neighbor_add(neighbor1_id, 64511, 
is_route_reflector_client=True)
     self.bgp_speaker.neighbor_add(neighbor2_id, 64511, 
is_route_reflector_client=True)

     self.bgp_speaker.prefix_add(prefix="10.2.1.0/24 <http://10.2.1.0/24>")


The error is(observed from wireshark trace),
Bird router closes the connection with UPDATE MESSAGE ERROR(3)/ Minor code: 
Optional attribute Error(9)


In the bird log , i see the below error

Connection to peer 192.168.2.2 lost, reason: Peer closed connection Resetting 
retry connect loop: True

Peer closed connectio



Note :  If i just remove the "is_route_reflector_client=True" flag, neighbor 
establishment and update happens.


Query1:
1. To enable route_reflector in RYU,  Do i need to configuration any other API 
or parameters?


Thanks
Suresh


On Thu, May 31, 2018 at 11:41 AM, Iwase Yusuke <mailto:iwase.yusu...@gmail.com>> wrote:


Hi,

> All routers are same AS number.

This means Ryu and other routers are connected with the iBGP(internal BGP)
peering, right? On the iBGP, generally the received routes from other iBGP 
peers
will not be advertised in order to avoid network loops. If you need to 
advertise
the iBGP routers to other iBGP peers, please configure Ryu as a Route 
Reflector
(or use different AS number on other routers for external BGP peering).

To configure route reflector, please enable "is_route_reflector_client" 
option.

http://ryu.readthedocs.io/en/latest/library_bgp_speaker_ref.html#ryu.services.protocols.bgp.bgpspeaker.BGPSpeaker.neighbor_add

<http://ryu.readthedocs.io/en/latest/library_bgp_speaker_ref.html#ryu.services.protocols.bgp.bgpspeaker.BGPSpeaker.neighbor_add>

Thanks,
Iwase
<http://knetsolutions.in/>




--
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

>From 24bd6940dd3bb5b31514329ad7c1f3349eabc900 Mon Sep 17 00:00:00 2001
From: IWASE Yusuke 
Date: Tue, 12 Jun 2018 14:12:00 +0900
Subject: [PATCH] BGPSpeaker: Advertise local routes to RR clients

The current implementation misses the mandatory attributes when sending
locally generated routes to its Route Reflector (RR) clients, then the
clients will reject the received routes.

This patch fixes to add or update attributes to for sending locally
generated routes its RR clients.

Signed-off-by: IWASE Yusuke 
---
 ryu/services/protocols/bgp/peer.py | 47 +-
 1 file changed, 21 insertions(+), 26 deletions(-)

diff --git a/ryu/services/protocols/bgp/peer.py b/ryu/services/protocols/bgp/peer.py
index 70b486c0..2a0e2a9f 100644
--- a/ryu/services/protocols/bgp/peer.py
+++ b/ryu/services/protocols/bgp/peer.py
@@ -989,37 +989,32 @@ class Peer(Source, Sink, NeighborConfListener, Activity):
 elif self.is_route_server_client:
 nlri_list = [path.nlri]
 new_pathattr.extend(pathattr_map.values())
-elif self.is_route_reflector_client:
-nlri_list = [path.nlri]
+else:
+if self.is_route_reflector_client:
+# Append ORIGINATOR_ID attribute if not already exist.
+if BGP_ATTR_TYPE_ORIGINATOR_ID not in pathattr_map:
+originator_id = path.source
+if originator_id is None:
+originator_id = self._common_conf.router_id
+elif isinstance(path.source, Peer):
+originator_id = path.source.ip_address
+new_pathattr.append(
+BGPPathAttributeOriginatorId(value=originator_id))
 
-# Append ORIGINATOR_ID attribute if not already exists.
-if BGP_ATTR_TYPE_ORIGINATOR_ID not in pathattr_map:
-originator_id = path.source
-if originator_id is None:
-originator_id = self._com

Re: [Ryu-devel] BGP Speakers

[Iwase Yusuke]

Hi,

I think you need to specify the following options in order to avoid the
conflicts of listening ports.

- BGP listen host addresses (or port number)
https://github.com/osrg/ryu/blob/c29c9019ac8ab862bbc0caad7d49220f27ed0cf0/ryu/services/protocols/bgp/bgp_sample_conf.py#L51-L52

- RPC listen host address (or port number) for BGP
  $ ryu-manager -h
...(snip)...
--bgp-app-rpc-host BGP-APP_RPC_HOST
  IP for RPC server (default: 0.0.0.0)
--bgp-app-rpc-port BGP-APP_RPC_PORT
  Port for RPC server (default: 50002)
...(snip)...

- SSH console host address (or port number) for BGP
https://github.com/osrg/ryu/blob/c29c9019ac8ab862bbc0caad7d49220f27ed0cf0/ryu/services/protocols/bgp/bgp_sample_conf.py#L400-L401


BTW, why you need to run multiple BGP Speakers at the same time? Ryu BGP Speaker
supports per-peer AS number configuration, you can setup multiple connections
with routers in different ASs. If this feature is sufficient for your use-case,
it should be more appropriate than running multiple BGP Speakers.
http://ryu.readthedocs.io/en/latest/library_bgp_speaker_ref.html#ryu.services.protocols.bgp.bgpspeaker.BGPSpeaker.neighbor_add


Thanks,
Iwase


On 2018年06月07日 23:03, knet solutions wrote:

Can we run multiple  BGP Speakers in the RYU application?

--
*/Regards,
/*
*/Knet solutions./*

https://github.com/knetsolutions/KNet
http://knet-topology-builder.readthedocs.io/
http://knetsolutions.in/



--
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] BGP Query

[Iwase Yusuke]

Hi,

> I believe the high level topology which Iwase mentioned looks like:
> 

Great! Thanks Yi! That's exactly what I wanted to describe!

> To connect from Ryu to OF-Switch is simple, all you need is to connect
> NIC/interface from your Ryu machine to the OF-Switch with a ethernet cable ;)

FYI, if your Ryu is running on the same host with your OVS, you can use a "tap"
device to create a port for BGP link. Or if you can assign IP address to OVS
bridge device, we can use the reserved port "OFPP_LOCAL" for BGP link.

e.g.)
If Ryu BGP Speaker will listen on "10.0.0.1" and OVS bridge name is "s1";
  $ sudo ip addr add 10.0.0.0/24 dev s1
  $ sudo ip link set s1 up
Then, Ryu BGP Speaker can listen on the OFPP_LOCAL port of "s1".

Thanks,
Iwase

On 2018年05月31日 22:59, Yi Tseng wrote:

Hi,

I believe the high level topology which Iwase mentioned looks like:

You need to config Ryu BGP speaker so Ryu BGP speaker can send BGP advertise to 
external BGP speaker, vice versa.


For OF-Switch, you need to install flows to it so it can forward both ARP and 
BGP messages between Ryu BGP speaker and external BGP speaker


To connect from Ryu to OF-Switch is simple, all you need is to connect 
NIC/interface from your Ryu machine to the OF-Switch with a ethernet cable ;)

​

2018-05-31 20:31 GMT+08:00 Yusuke Iwase <mailto:iwase.yusu...@gmail.com>>:


Hi,



1) BGP Speaker, Do we need to specify a configuration to connect to
openflow switch?, instead of listening on a bgp port?


I guess no special configuration is required. BGP Speaker should act as a
“host” connecting to your OpenFlow network.


2) In Openflow switch, how do we configure send the packets to BGP Speaker
on separate channel.  ?


Not so complex, just execute OUTPUT action to forward BGP packets (also ARP)
to the port connecting to Ryu BGP Speaker’s host.
For example, if tcp_dst=179 then output to port 1 or so.

Thanks,
Iwase

2018/05/31 18:25、knet solutions mailto:knetsolutio...@gmail.com>>のメール:


Hi Iwase,  Logically i understood . But  technically i dont know how to do 
it.

1) BGP Speaker, Do we need to specify a configuration to connect to
openflow switch?, instead of listening on a bgp port?

2) In Openflow switch, how do we configure send the packets to BGP Speaker
on separate channel.  ?


Sorry about more questions.

Thanks
Suresh.

On Thu, May 31, 2018 at 2:37 PM, Yusuke Iwase mailto:iwase.yusu...@gmail.com>> wrote:

Hi,

Just I mean Ryu BGP Speaker should connect to the OpenFlow port on
OF-Switch as the same as the traditional routers.
I want to describe we should not use the Controller-Switch channel to
receive BGP packets (e.g. receive BGP packets via Packet-In) and
should separate the link for BGP from that for OpenFlow.

Thanks,
Iwase

2018/05/31 17:34、knet solutions mailto:knetsolutio...@gmail.com>>のメール:


Hi Iwase ,
thanks for the response.

Regarding the below line,

>The BGP port on Ryu is connected as a "to host" port onthe OF-Switch,

I couldnot understand this point. How to configure this, and little
more details about this.

Can you share something more about this.

Thanks
Suresh.


On Thu, May 31, 2018 at 12:02 PM, Iwase Yusuke
mailto:iwase.yusu...@gmail.com>> wrote:

Hi Suresh,


> Query1)
> Can we use the RYU BGP Speaker libaray, in this use case?

Yes.
I guess that use case is what exactly Ryu BGP speaker
implementation is
targeting.

> if yes, could you provide some guide lines on how to use it.

Sorry, I have no good document for such, but for example, the
following
architecture is one of the candidates.

         Ryu
OpenFlow || BGP
       OF-Switch  Router

Ryu has two (or more) connections with the OF-Switch, one is for
OpenFlow and
the other is for BGP. The BGP port on Ryu is connected as a "to
host" port on
the OF-Switch, then the OF-Switch will forward BGP packets (TCP
port = 179) to
Ryu's BGP port and the other packets will be forwarded based on
the OpenFlow
table.

Thanks,
Iwase


On 2018年05月23日 21:33, knet solutions wrote:


The BGP Speaker example shows that, the RYU BGP Speaker is a
separate process which handles packets directly from the
socket/kernel (not via Openflow encapsualtion).


My use case some thing like below,

In this below diagram,  Tradiati

Re: [Ryu-devel] BGP Query

[Iwase Yusuke]

Hi Suresh,


> Query1)
> Can we use the RYU BGP Speaker libaray, in this use case?

Yes.
I guess that use case is what exactly Ryu BGP speaker implementation is
targeting.

> if yes, could you provide some guide lines on how to use it.

Sorry, I have no good document for such, but for example, the following
architecture is one of the candidates.

 Ryu
OpenFlow || BGP
   OF-Switch  Router

Ryu has two (or more) connections with the OF-Switch, one is for OpenFlow and
the other is for BGP. The BGP port on Ryu is connected as a "to host" port on
the OF-Switch, then the OF-Switch will forward BGP packets (TCP port = 179) to
Ryu's BGP port and the other packets will be forwarded based on the OpenFlow
table.

Thanks,
Iwase


On 2018年05月23日 21:33, knet solutions wrote:


The BGP Speaker example shows that, the RYU BGP Speaker is a separate process 
which handles packets directly from the socket/kernel (not via Openflow 
encapsualtion).



My use case some thing like below,

In this below diagram,  Tradiational BGP Router (Bird routing daemon) run BGP 
and connect to the openvswtich managed by the RYU controller.   I would like to 
enable the BGP application in the controller, so that when the BGP Packet comes 
to the switch, switch sends the packet to the RYU , RYU will use BGP Speaker to 
manage the control plane for this siwtch1.


--- 
|-
Traditional BGP Router  |  
--|switch1  |

(Bird  Router)    |    | |
-- 
--


Query1)
Can we use the RYU BGP Speaker libaray, in this use case?  if yes, could you 
provide some guide lines on how to use it.



--
*/Regards,
/*
*/Knet solutions./*
Suresh.
https://github.com/knetsolutions/KNet 
http://knet-topology-builder.readthedocs.io/ 


http://knetsolutions.in/



--
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] Query BGP speaker

[Iwase Yusuke]

Hi,

> All routers are same AS number.

This means Ryu and other routers are connected with the iBGP(internal BGP)
peering, right? On the iBGP, generally the received routes from other iBGP peers
will not be advertised in order to avoid network loops. If you need to advertise
the iBGP routers to other iBGP peers, please configure Ryu as a Route Reflector
(or use different AS number on other routers for external BGP peering).

To configure route reflector, please enable "is_route_reflector_client" option.
http://ryu.readthedocs.io/en/latest/library_bgp_speaker_ref.html#ryu.services.protocols.bgp.bgpspeaker.BGPSpeaker.neighbor_add

Thanks,
Iwase


On 2018年05月30日 23:30, knet solutions wrote:


Hi,

I am building RYU SDN BGP Speaker as transit Router. The topology is as below,

All routers are same AS number.

Traditional BGP Router1-RYU BGP Speaker-- 
Traditional BGP Router2



Here
1. RYU BGP Speaker establishes neigbors with BGP Router1 and BGP Router2.
2. RYU BGP Speaker exchanges defined routes (prefix_add ) to BGP Router1 and BGP 
Router2.

3. RYU BGP Speaker learned routes from BGP Router1 and BGP Router2.

But,  RYU BGP Speaker is not  exchanging the routes learned from BGP Router1 to 
BGP Router2 and  vice versa.


How do we make it distribute routes from Router1 to Router2??? Any help is 
appreciated.




I just used only below code snippet for RYU BGP Stuff

     self.bgp_speaker = BGPSpeaker(local_as_number, router_id,
   ssh_console=True, ssh_port=4999,
   ssh_host='localhost',
   
best_path_change_handler=self.best_path_change_handler )

     self.bgp_speaker.neighbor_add(neighbor1_id, neighbor_as_number)
     self.bgp_speaker.neighbor_add(neighbor2_id, neighbor_as_number)

     self.bgp_speaker.prefix_add(prefix="10.2.1.0/24 ")


--
*/Regards,
/*
*/Knet solutions./*

https://github.com/knetsolutions/KNet
http://knet-topology-builder.readthedocs.io/
http://knetsolutions.in/



--
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] 404 error when using ryu gui. Is it a bug?

[Iwase Yusuke]

Hi,

Excuse me for jumping in.

This issue hits this bug?
https://www.mail-archive.com/ryu-devel@lists.sourceforge.net/msg13533.html

"gui_topology" seems to cover all wsgi routes, then other wsgi apps can not
register their methods.

Thanks,
Iwase


On 2018年05月08日 17:31, IWAMOTO Toshihiro wrote:

On Tue, 08 May 2018 11:39:38 +0900,
林佳烁 wrote:


[1  ]
[1.1  ]
Hi,


I want to integrate gui_topology.py which is in ryu/app/gui_topology/ with 
myapp.py.
However, I recieve 404 responses after I add a line of code into a copy version 
of gui_topology.py in a new folder.


My operation to the scripts is as follow:
$ cd ~/ryu
$ cp -r ryu/app/gui_topology ryu/app/myfolder
$ cp ryu/app/simple_switch_13.py ryu/app/myfolder/
Then I add a line of code, " app_manager.require_app(PATH + '/simple_switch_13.py') 
", at the bottom of gui_topology.py.
$ PYTHONPATH=. ./bin/ryu run ryu/app/myfolder/gui_topology.py --observe-links


Then I access http://localhost:8080 with my web browser and I get these 
reponses in the terminal of the controller.
127.0.0.1 - - [08/May/2018 10:27:34] "GET / HTTP/1.1" 200 515 0.011610
127.0.0.1 - - [08/May/2018 10:27:34] "GET /ryu.topology.css HTTP/1.1" 200 514 
0.000825
(7006) accepted ('127.0.0.1', 51232)
127.0.0.1 - - [08/May/2018 10:27:34] "GET /ryu.topology.js HTTP/1.1" 200 8652 
0.003208
127.0.0.1 - - [08/May/2018 10:27:35] "GET /v1.0/topology/switches HTTP/1.1" 404 
319 0.000844
(7006) accepted ('127.0.0.1', 51238)
127.0.0.1 - - [08/May/2018 10:27:35] "GET /v1.0/topology/ws HTTP/1.1" 404 339 
0.001272
127.0.0.1 - - [08/May/2018 10:27:35] "GET /v1.0/topology/links HTTP/1.1" 404 
316 0.000961


However, after I rename the folder frome myfolder to gui_topo. It works fine!


Is it gui_topo or gui_topology?


Is it a bug? Is there anyone can help me？


Sounds like an import issue. Please check your error messages for any
import errors. And also double check you are actually importing
the intended files. It is possible files under /usr/lib/python or so
are imported unintentionally.


--
IWAMOTO Toshihiro
--
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] Append fields in match

[Iwase Yusuke]

Hi,

Excuse me for jumping in.

How about using "dict" to store temporary match fields like;
match_fields = {
'in_port': in_port,
}
# Do something
match_fields['vlan_vid'] = vlan_vid
# Do something
match = parser.OFPMatch(**match_fields)

Thanks,
Iwase


On 2018年04月10日 14:13, IWAMOTO Toshihiro wrote:

On Mon, 09 Apr 2018 23:30:32 +0900,
marcosab...@inf.ufg.br wrote:


Hello,

I used OpenFlow 1.3.
How i set new field in OFPmatch after i build the class?
For exemple:

match = ofp.OFPMatch(in_port=port)
match.vlan_vid = vlan

When i set like this OpenFlow set 'in_port' but not add 'vlan_vid' in match.


Please check the __init__ implementation of OFPMatch.
It doesn't support such a coding style. You need to pass all the match
fields to the constructor.

--
IWAMOTO Toshihiro

--
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] Spliting flows through two ports

[Iwase Yusuke]

Hi Carlos,

You mean;
- With OFPGT_ALL, group action works as expected
- But with OFPGT_SELECT, group action does not work
right?

If group and flow entries are installed as expected, it means this problem is
not on Ryu (Controller) side, but I guess it is on your switch spec. Please
confirm your switch supports OFPGT_SELECT on group table.

Thanks,
Iwase


On 2018年04月03日 02:25, Jose Carlos Ferreira de Melo Junior wrote:

Hey Iwase,

Good news  it's working although I couldn't really divide the flow.

Here's what happened.

The flow went to two ports of the switch but the flow is replicated on the port 
2 and 3.


  in that case making the same bandwidth go on the port 2 and 3.


I used both *weight* variable as *0* and *ofp.OFPGT_ALL*

         queue_1 = _parser_.OFPActionSetQueue(0)
         actions_1 = [queue_1, _parser_.OFPActionOutput(3)]


         queue_2 = _parser_.OFPActionSetQueue(0)
         actions_2 = [queue_2, _parser_.OFPActionOutput(2)]

*weight_1 = 0*
*        weight_2 = 0*
         watch_port = ofproto_v1_3.OFPP_ANY
         watch_group = ofproto_v1_3.OFPQ_ALL

         req = _parser_.OFPGroupMod(datapath, ofp.OFPFC_ADD, *ofp.OFPGT_ALL*,
                 group_id, buckets)



I would like to divide the flow in a  way that in port 2 have 50% of the band 
and port 3 also have 50% of the band.

I changed the *weight* value to *50* and used *ofp.OFPGT_SELECT* but it didn't 
work



2018-04-01 23:09 GMT-03:00 Iwase Yusuke <iwase.yusu...@gmail.com 
<mailto:iwase.yusu...@gmail.com>>:


Hi Carlos,

 > *match = _parser_.OFPMatch(ipv4_src="192.168.2.2", 
ipv4_dst="192.168.1.1")*

This rule does not follow "7.2.3.6 Flow Match Field Prerequisite" in the
OpenFlow Spec 1.3.5, I guess. See the OpenFlow Spec for more details.
Then, please confirm your flow entries are installed on your switch like
"ovs-ofctl dump-flows s1".

Thanks,
Iwase


On 2018年04月02日 10:36, Jose Carlos Ferreira de Melo Junior wrote:

Hey Iwase,

Right now my code looks like this OFPActionGroup is in Red

*port_1 = 3*
*        queue_1 = _parser_.OFPActionSetQueue(0)*
*        actions_1 = [queue_1, _parser_.OFPActionOutput(4)]*
*
*
*
*
*        port_2 = 2*
*        queue_2 = _parser_.OFPActionSetQueue(0)*
*        actions_2 = [queue_2, _parser_.OFPActionOutput(2)]*
*
*
*        weight_1 = 50*
*        weight_2 = 50*
*        watch_port = ofproto_v1_3.OFPP_ANY*
*        watch_group = ofproto_v1_3.OFPQ_ALL*
*
*
*        buckets = [*
*                _parser_.OFPBucket(weight_1, watch_port, watch_group,
actions_1),*
*                _parser_.OFPBucket(weight_2, watch_port, watch_group,
actions_2)]*
*
*
*group_id = 1*
*
*
*        req = _parser_.OFPGroupMod(datapath, ofp.OFPFC_ADD,
ofp.OFPGT_SELECT,*
*                group_id, buckets)*

*        datapath.send_msg(req)*

*match = _parser_.OFPMatch(ipv4_src="192.168.2.2", 
ipv4_dst="192.168.1.1")*
*actions = [datapath.ofproto_parser.OFPActionGroup(1)]*
*        inst = [_parser_.OFPInstructionActions(ofp.OFPIT_APPLY_ACTIONS,
actions)]*
*        mod = datapath.ofproto_parser.OFPFlowMod(datapath, match=match,
cookie=0, command=ofp.OFPFC_ADD, idle_timeout=0, hard_timeout=0,
priority=3, instructions=inst)*
*
*
*        datapath.send_msg(mod)*


i was following the code in
http://csie.nqu.edu.tw/smallko/sdn/ryu_multipath_13.htm
<http://csie.nqu.edu.tw/smallko/sdn/ryu_multipath_13.htm>

    is it right ?





thanks



2018-04-01 22:14 GMT-03:00 Iwase Yusuke <iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com> <mailto:iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>>>:

     Hi Carlos,

     H... have you installed any "flow" entry which contained
OFPActionGroup?
     Also, in your code, you uses "group_id = 50" in OFPGroupMod 
message. Is
     OFPActionGroup using the same "group_id = 50"?

     Thanks,
     Iwase


     On 2018年04月02日 09:36, Jose Carlos Ferreira de Melo Junior wrote:

         Hi Iwase,

         Sorry for the late answer

         well... I checked the group stats as you said and it's not
being looked up

         *ovs-ofctl dump-group-stats -O OpenFlow s2*
         *OFPST_GROUP reply (OF1.3) (xid=0x2):*

*group_id=1,duration=12.837s,ref_count=0,packet_count=0,byte_count=0,bucket0:packet_count=0,byte_count=0,byte_count=0,bucket1:packet_count=0,byte_c

Re: [Ryu-devel] Spliting flows through two ports

[Iwase Yusuke]

Hi Carlos,

> *match = _parser_.OFPMatch(ipv4_src="192.168.2.2", ipv4_dst="192.168.1.1")*

This rule does not follow "7.2.3.6 Flow Match Field Prerequisite" in the
OpenFlow Spec 1.3.5, I guess. See the OpenFlow Spec for more details.
Then, please confirm your flow entries are installed on your switch like
"ovs-ofctl dump-flows s1".

Thanks,
Iwase


On 2018年04月02日 10:36, Jose Carlos Ferreira de Melo Junior wrote:

Hey Iwase,

Right now my code looks like this OFPActionGroup is in Red

*port_1 = 3*
*        queue_1 = _parser_.OFPActionSetQueue(0)*
*        actions_1 = [queue_1, _parser_.OFPActionOutput(4)]*
*
*
*
*
*        port_2 = 2*
*        queue_2 = _parser_.OFPActionSetQueue(0)*
*        actions_2 = [queue_2, _parser_.OFPActionOutput(2)]*
*
*
*        weight_1 = 50*
*        weight_2 = 50*
*        watch_port = ofproto_v1_3.OFPP_ANY*
*        watch_group = ofproto_v1_3.OFPQ_ALL*
*
*
*        buckets = [*
*                _parser_.OFPBucket(weight_1, watch_port, watch_group, 
actions_1),*
*                _parser_.OFPBucket(weight_2, watch_port, watch_group, 
actions_2)]*
*
*
*group_id = 1*
*
*
*        req = _parser_.OFPGroupMod(datapath, ofp.OFPFC_ADD, ofp.OFPGT_SELECT,*
*                group_id, buckets)*

*        datapath.send_msg(req)*

*match = _parser_.OFPMatch(ipv4_src="192.168.2.2", ipv4_dst="192.168.1.1")*
*actions = [datapath.ofproto_parser.OFPActionGroup(1)]*
*        inst = [_parser_.OFPInstructionActions(ofp.OFPIT_APPLY_ACTIONS, 
actions)]*
*        mod = datapath.ofproto_parser.OFPFlowMod(datapath, match=match, 
cookie=0, command=ofp.OFPFC_ADD, idle_timeout=0, hard_timeout=0, priority=3, 
instructions=inst)*

*
*
*        datapath.send_msg(mod)*


i was following the code in 
http://csie.nqu.edu.tw/smallko/sdn/ryu_multipath_13.htm

is it right ?





thanks



2018-04-01 22:14 GMT-03:00 Iwase Yusuke <iwase.yusu...@gmail.com 
<mailto:iwase.yusu...@gmail.com>>:


Hi Carlos,

H... have you installed any "flow" entry which contained OFPActionGroup?
Also, in your code, you uses "group_id = 50" in OFPGroupMod message. Is
OFPActionGroup using the same "group_id = 50"?

Thanks,
Iwase


On 2018年04月02日 09:36, Jose Carlos Ferreira de Melo Junior wrote:

Hi Iwase,

Sorry for the late answer

well... I checked the group stats as you said and it's not being looked 
up

*ovs-ofctl dump-group-stats -O OpenFlow s2*
*OFPST_GROUP reply (OF1.3) (xid=0x2):*

*group_id=1,duration=12.837s,ref_count=0,packet_count=0,byte_count=0,bucket0:packet_count=0,byte_count=0,byte_count=0,bucket1:packet_count=0,byte_count=0*
*
*
I'm really lost and don't know how to fix that

Do you have any idea of how can I solve this problem?


many thanks.

2018-03-29 1:33 GMT-03:00 Iwase Yusuke <iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com> <mailto:iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>>>:

     Hi Carlos,

     The group entries are looked up (or specified) by OFPActionGroup in
flow
     entries.

     If looked up, ref_count, packet_count and byte_count should be
incremented.

     mininet> sh ovs-ofctl dump-group-stats s1 -O OpenFlow13
     OFPST_GROUP reply (OF1.3) (xid=0x4):

group_id=1,duration=45.105s,ref_count=1,packet_count=5,byte_count=378,bucket0:packet_count=4,byte_count=336,bucket1:packet_count=1,byte_count=42


     Thanks,
     Iwase


     On 2018年03月27日 23:10, Jose Carlos Ferreira de Melo Junior wrote:

         Hi Iwase,

         The group entry is added...















         but I don't understand how can be looked up.
         I don't know how to do this


         Is there any other thing that I am missing 


         thanks in advanced







         2018-03-26 20:28 GMT-03:00 Iwase Yusuke
<iwase.yusu...@gmail.com <mailto:iwase.yusu...@gmail.com>
         <mailto:iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>> <mailto:iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>
         <mailto:iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>>>>:

              Hi Carlos,

               >  "*/using the group table with openflow 1.3 with no
sucess/*"
         means that I am
              > using the group table as i said before and it is not
working,
         means that I am
              > using the group specification and it doens't work.

              "Does not work" means
                - no group entry added
 

Re: [Ryu-devel] Spliting flows through two ports

[Iwase Yusuke]

Hi Carlos,

H... have you installed any "flow" entry which contained OFPActionGroup?
Also, in your code, you uses "group_id = 50" in OFPGroupMod message. Is
OFPActionGroup using the same "group_id = 50"?

Thanks,
Iwase


On 2018年04月02日 09:36, Jose Carlos Ferreira de Melo Junior wrote:

Hi Iwase,

Sorry for the late answer

well... I checked the group stats as you said and it's not being looked up

*ovs-ofctl dump-group-stats -O OpenFlow s2*
*OFPST_GROUP reply (OF1.3) (xid=0x2):*
*group_id=1,duration=12.837s,ref_count=0,packet_count=0,byte_count=0,bucket0:packet_count=0,byte_count=0,byte_count=0,bucket1:packet_count=0,byte_count=0*
*
*
I'm really lost and don't know how to fix that

Do you have any idea of how can I solve this problem?


many thanks.

2018-03-29 1:33 GMT-03:00 Iwase Yusuke <iwase.yusu...@gmail.com 
<mailto:iwase.yusu...@gmail.com>>:


Hi Carlos,

The group entries are looked up (or specified) by OFPActionGroup in flow
entries.

If looked up, ref_count, packet_count and byte_count should be incremented.

mininet> sh ovs-ofctl dump-group-stats s1 -O OpenFlow13
OFPST_GROUP reply (OF1.3) (xid=0x4):

group_id=1,duration=45.105s,ref_count=1,packet_count=5,byte_count=378,bucket0:packet_count=4,byte_count=336,bucket1:packet_count=1,byte_count=42

Thanks,
Iwase


On 2018年03月27日 23:10, Jose Carlos Ferreira de Melo Junior wrote:

Hi Iwase,

The group entry is added...















but I don't understand how can be looked up.
I don't know how to do this


Is there any other thing that I am missing 


thanks in advanced







    2018-03-26 20:28 GMT-03:00 Iwase Yusuke <iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com> <mailto:iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>>>:

     Hi Carlos,

      >  "*/using the group table with openflow 1.3 with no sucess/*"
means that I am
     > using the group table as i said before and it is not working,
means that I am
     > using the group specification and it doens't work.

     "Does not work" means
       - no group entry added
       - group entry exists, but not looked up
       - group entry looked up, but packets are not outputted
       or ...
     which you mean?


     > and about your topology: It has only 2 switches or 4???

     Only 2 switches (s1 and s2), which corresponding to "Start" and
"End" switches
     on the image you attached on your previous mail. Also h1 and h2
represents hosts
     which do ping.


     Thanks,
     Iwase

     On 2018年03月26日 21:14, Jose Carlos Ferreira de Melo Junior wrote:

         Hey Iwase,

            "*/using the group table with openflow 1.3 with no sucess/*"
means
         that I am using the group table as i said before and it is not
working,
         means that I am using the group specification and it doens't 
work.

         and about your topology: It has only 2 switches or 4???

             i don't know if my code is right or if i am missing something 
else.




         2018-03-25 21:40 GMT-03:00 Iwase Yusuke
<iwase.yusu...@gmail.com <mailto:iwase.yusu...@gmail.com>
         <mailto:iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>> <mailto:iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>
         <mailto:iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>>>>:


              Hi Carlos,

              For such purpose, OFPGT_SELECT is appropriate, I guess.

              With the topology;

                             ++             ++
                             |   s1   |             |   s2   |
              ++        |      (port 2)---(port 2)      |        
++
              | h1 |---(port 1)      |             |      (port 1)---| 
h2 |
              ++        |      (port 3)---(port 3)      |        
++
                             |        |             |        |
                             ++             ++


              I can install groups and flows entries, then can ping
between h1
         and h2 with the
              following app.


              $ git diff
              diff --git a/ryu/app/simple_switch_13.py
b/ryu/app/simple_switch_13.py
              index 06a5d0e..e1a5c3b 100644
      

[Ryu-devel] [PATCH 1/2] ofproto_v1_2: Enable to use NXAction in OpenFlow 1.2

[IWASE Yusuke]

Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 ryu/ofproto/ofproto_v1_2.py| 3 +++
 ryu/ofproto/ofproto_v1_2_parser.py | 7 +++
 2 files changed, 10 insertions(+)

diff --git a/ryu/ofproto/ofproto_v1_2.py b/ryu/ofproto/ofproto_v1_2.py
index 1c8a971..acc4ea7 100644
--- a/ryu/ofproto/ofproto_v1_2.py
+++ b/ryu/ofproto/ofproto_v1_2.py
@@ -348,6 +348,9 @@ OFPFC_MODIFY_STRICT = 2 # Modify entry strictly 
matching wildcards
 OFPFC_DELETE = 3# Delete all matching flows.
 OFPFC_DELETE_STRICT = 4 # Strictly match wildcards and priority.
 
+# By default, choose a priority in the middle.
+OFP_DEFAULT_PRIORITY = 0x8000
+
 # enum ofp_flow_mod_flags
 OFPFF_SEND_FLOW_REM = 1 << 0# Send flow removed message when flow
 # expires or is deleted.
diff --git a/ryu/ofproto/ofproto_v1_2_parser.py 
b/ryu/ofproto/ofproto_v1_2_parser.py
index 244126c..5c7ba8f 100644
--- a/ryu/ofproto/ofproto_v1_2_parser.py
+++ b/ryu/ofproto/ofproto_v1_2_parser.py
@@ -30,6 +30,7 @@ from ryu.lib.packet import packet
 from ryu import utils
 from ryu.ofproto.ofproto_parser import StringifyMixin, MsgBase
 from ryu.ofproto import ether
+from ryu.ofproto import nx_actions
 from ryu.ofproto import ofproto_parser
 from ryu.ofproto import ofproto_v1_2 as ofproto
 
@@ -4669,3 +4670,9 @@ class MTMplsTc(OFPMatchField):
 def __init__(self, header, value, mask=None):
 super(MTMplsTc, self).__init__(header)
 self.value = value
+
+
+nx_actions.generate(
+'ryu.ofproto.ofproto_v1_2',
+'ryu.ofproto.ofproto_v1_2_parser'
+)
-- 
2.7.4


--
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] [PATCH 2/2] Export Nicira messages to ofproto_v1_[2345]_parser

[IWASE Yusuke]

This patch adds a new module "nx_message" in order to export Nicira
messages, which defined only in "ofproto_v1_0_parser", to other parsers
for other OpenFlow versions.

Note: This patch exports only "NXTSetControllerId" at this time, because
other Nicira messages have alternatives of the standard OpenFlow
messages.

Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 doc/source/nicira_ext_ref.rst  |  7 +++
 ryu/ofproto/nx_message.py  | 32 
 ryu/ofproto/ofproto_v1_0_parser.py | 23 +++
 ryu/ofproto/ofproto_v1_2_parser.py |  5 +
 ryu/ofproto/ofproto_v1_3_parser.py |  5 +
 ryu/ofproto/ofproto_v1_4_parser.py |  5 +
 ryu/ofproto/ofproto_v1_5_parser.py |  5 +
 7 files changed, 82 insertions(+)
 create mode 100644 ryu/ofproto/nx_message.py

diff --git a/doc/source/nicira_ext_ref.rst b/doc/source/nicira_ext_ref.rst
index 7ca1b0c..0f10f25 100644
--- a/doc/source/nicira_ext_ref.rst
+++ b/doc/source/nicira_ext_ref.rst
@@ -2,6 +2,13 @@
 Nicira Extension Structures
 ***
 
+Nicira Extended Messages Structures
+===
+
+.. py:currentmodule:: ryu.ofproto.ofproto_v1_3_parser
+
+.. autoclass:: NXTSetControllerId
+
 .. _nx_actions_structures:
 
 Nicira Extension Actions Structures
diff --git a/ryu/ofproto/nx_message.py b/ryu/ofproto/nx_message.py
new file mode 100644
index 000..3996172
--- /dev/null
+++ b/ryu/ofproto/nx_message.py
@@ -0,0 +1,32 @@
+# Copyright (C) 2018 Nippon Telegraph and Telephone Corporation.
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+#http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+# implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+import sys
+
+from ryu.ofproto import ofproto_v1_0_parser
+
+
+def generate(parser_name):
+parser = sys.modules[parser_name]
+
+def add_attr(key, value):
+value.__module__ = parser.__name__  # Necessary for stringify stuff
+setattr(parser, key, value)
+
+_classes = [
+ofproto_v1_0_parser.NXTSetControllerId,
+]
+for cls in _classes:
+add_attr(cls.__name__, cls)
diff --git a/ryu/ofproto/ofproto_v1_0_parser.py 
b/ryu/ofproto/ofproto_v1_0_parser.py
index a288964..25bf61f 100644
--- a/ryu/ofproto/ofproto_v1_0_parser.py
+++ b/ryu/ofproto/ofproto_v1_0_parser.py
@@ -1644,6 +1644,29 @@ class NXTSetAsyncConfig(NiciraHeader):
 
 
 class NXTSetControllerId(NiciraHeader):
+"""
+Set controller connection ID message
+
+Each OpenFlow controller connection has a 16-bit identifier that is
+initially 0. This message changes the connection's ID to the given ID.
+
+Controller connection IDs need not be unique.
+
+ ==
+AttributeDescription
+ ==
+controller_id16-bit identifier value for controller connection.
+ ==
+
+Example::
+
+def send_set_controller_id(self, datapath, controller_id):
+parser = datapath.ofproto_parser
+
+msg = parser.NXTSetControllerId(datapath, controller_id)
+datapath.send_msg(msg)
+"""
+
 def __init__(self, datapath, controller_id):
 super(NXTSetControllerId, self).__init__(
 datapath, ofproto.NXT_SET_CONTROLLER_ID)
diff --git a/ryu/ofproto/ofproto_v1_2_parser.py 
b/ryu/ofproto/ofproto_v1_2_parser.py
index 5c7ba8f..9862fc9 100644
--- a/ryu/ofproto/ofproto_v1_2_parser.py
+++ b/ryu/ofproto/ofproto_v1_2_parser.py
@@ -31,6 +31,7 @@ from ryu import utils
 from ryu.ofproto.ofproto_parser import StringifyMixin, MsgBase
 from ryu.ofproto import ether
 from ryu.ofproto import nx_actions
+from ryu.ofproto import nx_message
 from ryu.ofproto import ofproto_parser
 from ryu.ofproto import ofproto_v1_2 as ofproto
 
@@ -4676,3 +4677,7 @@ nx_actions.generate(
 'ryu.ofproto.ofproto_v1_2',
 'ryu.ofproto.ofproto_v1_2_parser'
 )
+
+nx_message.generate(
+'ryu.ofproto.ofproto_v1_2_parser',
+)
diff --git a/ryu/ofproto/ofproto_v1_3_parser.py 
b/ryu/ofproto/ofproto_v1_3_parser.py
index 0324c82..7ff866c 100644
--- a/ryu/ofproto/ofproto_v1_3_parser.py
+++ b/ryu/ofproto/ofproto_v1_3_parser.py
@@ -54,6 +54,7 @@ from ryu import utils
 from ryu.ofproto.ofproto_parser import StringifyMixin, MsgBase
 from ryu.ofproto import ether
 from ryu.ofproto import nx_actions
+from r

[Ryu-devel] [PATCH 0/2] Export Nicira messages to ofproto_v1_[2345]_parser

[IWASE Yusuke]

The following patches adds a new module "nx_message" in order to export Nicira
messages, which defined only in "ofproto_v1_0_parser", to other parsers for
other OpenFlow versions.

IWASE Yusuke (2):
  ofproto_v1_2: Enable to use NXAction in OpenFlow 1.2
  Export Nicira messages to ofproto_v1_[2345]_parser

 doc/source/nicira_ext_ref.rst  |  7 +++
 ryu/ofproto/nx_message.py  | 32 
 ryu/ofproto/ofproto_v1_0_parser.py | 23 +++
 ryu/ofproto/ofproto_v1_2.py|  3 +++
 ryu/ofproto/ofproto_v1_2_parser.py | 12 
 ryu/ofproto/ofproto_v1_3_parser.py |  5 +
 ryu/ofproto/ofproto_v1_4_parser.py |  5 +
 ryu/ofproto/ofproto_v1_5_parser.py |  5 +
 8 files changed, 92 insertions(+)
 create mode 100644 ryu/ofproto/nx_message.py

--
2.7.4


--
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] Adding flag, label or any thing from switch to Controller.

[Iwase Yusuke]

Hi Nadim,

First, please confirm your situation. You want to realize the following?
1. H1 send some packets
2. S1 send the received packets to C1 as Packet-In messages
3. C1 send the packets as Packet-Out to S2
4. S1 send the packets to S3
5. S3 send the packets to C2 as Packet-In messages

And, in the above scenario, you need to determine the packets are sent from C1
or not at S3, then you want to add some labels or flags on the sent packets,
right?

For adding a label or vlan_id on C1, you can use OFPActionPushMpls or
OFPActionPushVlan actions, I guess.

e.g.)
# Add a new VLAN header and set VLAN-ID, then output
actions = [
parser.OFPActionPushVlan(),
parser.OFPActionSetField(vlan_vid=(100 | ofproto.OFPVID_PRESENT)),
parser.OFPActionOutput(out_port),
]
out = parser.OFPPacketOut(datapath=datapath, buffer_id=buffer_id,
  in_port=in_port, actions=actions, data=data)
datapath.send_msg(out)


Thanks,
Iwase


On 2018年03月30日 00:52, emi.hacker via Ryu-devel wrote:

Hello all,

  C1                             C2
  |    \                              |
S1-- S2 S3
  |
H1

In this  senerio, H1  sends pkt to S1, after that to C2 through S2 and S3.

I need S1 to add a label or flag (e.g A = 10), and I get it in Packet-In 
messages to make a decision.


I think this is possible in Ryu controller, So could you give me a simple 
example ?

Best Regards,
Nadim



--
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] [PATCH 0/4] mrtlib: Support RFC8050

[IWASE Yusuke]

The following pathes fix "ryu.lib.mrtlib" to support RFC8050 (Multi-Threaded
Routing Toolkit (MRT) Routing Information Export Format with BGP Additional
Path Extensions).

IWASE Yusuke (4):
  mrtlib: Missing subclass for SUBTYPE_RIB_*_MULTICAST
  mrtlib: Support RFC8050
  test_mrtlib: Test cases for ADD_PATH
  mrtlib: Define JSON representation types

 ryu/lib/mrtlib.py | 190 ++
 ryu/tests/unit/lib/test_mrtlib.py |  61 
 2 files changed, 233 insertions(+), 18 deletions(-)

--
2.7.4


--
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] [PATCH 3/4] test_mrtlib: Test cases for ADD_PATH

[IWASE Yusuke]

Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 ryu/tests/unit/lib/test_mrtlib.py | 61 +++
 1 file changed, 61 insertions(+)

diff --git a/ryu/tests/unit/lib/test_mrtlib.py 
b/ryu/tests/unit/lib/test_mrtlib.py
index e870f40..55c7cda 100644
--- a/ryu/tests/unit/lib/test_mrtlib.py
+++ b/ryu/tests/unit/lib/test_mrtlib.py
@@ -19,6 +19,7 @@ import bz2
 import io
 import logging
 import os
+import struct
 import sys
 import unittest
 
@@ -609,6 +610,66 @@ class TestMrtlibMrtPeer(unittest.TestCase):
 eq_(buf, output)
 
 
+class TestMrtlibMrtRibEntry(unittest.TestCase):
+"""
+Test case for ryu.lib.mrtlib.MrtRibEntry.
+"""
+
+def test_parse_add_path(self):
+peer_index = 1
+originated_time = 2
+nexthop = '1.1.1.1'
+bgp_attribute = bgp.BGPPathAttributeNextHop(nexthop)
+path_id = 3
+bgp_attr_buf = bgp_attribute.serialize()
+attr_len = len(bgp_attr_buf)
+buf = (
+b'\x00\x01'  # peer_index
+b'\x00\x00\x00\x02'  # originated_time
+b'\x00\x00\x00\x03'  # path_id
++ struct.pack('!H', attr_len)  # attr_len
++ bgp_attribute.serialize()# bgp_attributes
+)
+
+rib, rest = mrtlib.MrtRibEntry.parse(buf, is_addpath=True)
+
+eq_(peer_index, rib.peer_index)
+eq_(originated_time, rib.originated_time)
+eq_(path_id, rib.path_id)
+eq_(attr_len, rib.attr_len)
+eq_(1, len(rib.bgp_attributes))
+eq_(nexthop, rib.bgp_attributes[0].value)
+eq_(b'', rest)
+
+def test_serialize_add_path(self):
+peer_index = 1
+originated_time = 2
+nexthop = '1.1.1.1'
+bgp_attribute = bgp.BGPPathAttributeNextHop(nexthop)
+path_id = 3
+bgp_attr_buf = bgp_attribute.serialize()
+attr_len = len(bgp_attr_buf)
+buf = (
+b'\x00\x01'  # peer_index
+b'\x00\x00\x00\x02'  # originated_time
+b'\x00\x00\x00\x03'  # path_id
++ struct.pack('!H', attr_len)  # attr_len
++ bgp_attribute.serialize()# bgp_attributes
+)
+
+rib = mrtlib.MrtRibEntry(
+peer_index=peer_index,
+originated_time=originated_time,
+bgp_attributes=[bgp_attribute],
+# attr_len=attr_len,
+path_id=path_id,
+)
+
+output = rib.serialize()
+
+eq_(buf, output)
+
+
 class TestMrtlibBgp4MpMrtRecord(unittest.TestCase):
 """
 Test case for ryu.lib.mrtlib.Bgp4MpMrtRecord.
-- 
2.7.4


--
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] [PATCH 2/4] mrtlib: Support RFC8050

[IWASE Yusuke]

Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 ryu/lib/mrtlib.py | 130 --
 1 file changed, 116 insertions(+), 14 deletions(-)

diff --git a/ryu/lib/mrtlib.py b/ryu/lib/mrtlib.py
index c8f86fc..a89ccfc 100644
--- a/ryu/lib/mrtlib.py
+++ b/ryu/lib/mrtlib.py
@@ -431,6 +431,11 @@ class TableDump2MrtRecord(MrtCommonRecord):
 SUBTYPE_RIB_IPV6_UNICAST = 4
 SUBTYPE_RIB_IPV6_MULTICAST = 5
 SUBTYPE_RIB_GENERIC = 6
+SUBTYPE_RIB_IPV4_UNICAST_ADDPATH = 8
+SUBTYPE_RIB_IPV4_MULTICAST_ADDPATH = 9
+SUBTYPE_RIB_IPV6_UNICAST_ADDPATH = 10
+SUBTYPE_RIB_IPV6_MULTICAST_ADDPATH = 11
+SUBTYPE_RIB_GENERIC_ADDPATH = 12
 
 
 @TableDump2MrtMessage.register_type(
@@ -595,7 +600,8 @@ class 
TableDump2AfiSafiSpecificRibMrtMessage(TableDump2MrtMessage):
 RIB subtypes.
 
 The AFI/SAFI-specific RIB subtypes consist of the RIB_IPV4_UNICAST,
-RIB_IPV4_MULTICAST, RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST subtypes.
+RIB_IPV4_MULTICAST, RIB_IPV6_UNICAST, RIB_IPV6_MULTICAST and their
+additional-path version subtypes.
 """
 #  0   1   2   3
 #  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
@@ -614,6 +620,9 @@ class 
TableDump2AfiSafiSpecificRibMrtMessage(TableDump2MrtMessage):
 # Parser class to parse the Prefix field
 _PREFIX_CLS = None  # should be defined in subclass
 
+# Is additional-path version?
+_IS_ADDPATH = False
+
 def __init__(self, seq_num, prefix, rib_entries, entry_count=None):
 self.seq_num = seq_num
 assert isinstance(prefix, self._PREFIX_CLS)
@@ -631,7 +640,7 @@ class 
TableDump2AfiSafiSpecificRibMrtMessage(TableDump2MrtMessage):
 rest = buf[2:]
 rib_entries = []
 for i in range(entry_count):
-r, rest = MrtRibEntry.parse(rest)
+r, rest = MrtRibEntry.parse(rest, is_addpath=cls._IS_ADDPATH)
 rib_entries.insert(i, r)
 
 return entry_count, rib_entries, rest
@@ -710,10 +719,61 @@ class TableDump2RibIPv6MulticastMrtMessage(
 
 
 @TableDump2MrtMessage.register_type(
+TableDump2MrtRecord.SUBTYPE_RIB_IPV4_UNICAST_ADDPATH)
+class TableDump2RibIPv4UnicastAddPathMrtMessage(
+TableDump2AfiSafiSpecificRibMrtMessage):
+"""
+MRT Message for the TABLE_DUMP_V2 Type and the
+SUBTYPE_RIB_IPV4_UNICAST_ADDPATH subtype.
+"""
+_PREFIX_CLS = bgp.IPAddrPrefix
+_IS_ADDPATH = True
+
+
+@TableDump2MrtMessage.register_type(
+TableDump2MrtRecord.SUBTYPE_RIB_IPV4_MULTICAST_ADDPATH)
+class TableDump2RibIPv4MulticastAddPathMrtMessage(
+TableDump2AfiSafiSpecificRibMrtMessage):
+"""
+MRT Message for the TABLE_DUMP_V2 Type and the
+SUBTYPE_RIB_IPV4_MULTICAST_ADDPATH subtype.
+"""
+_PREFIX_CLS = bgp.IPAddrPrefix
+_IS_ADDPATH = True
+
+
+@TableDump2MrtMessage.register_type(
+TableDump2MrtRecord.SUBTYPE_RIB_IPV6_UNICAST_ADDPATH)
+class TableDump2RibIPv6UnicastAddPathMrtMessage(
+TableDump2AfiSafiSpecificRibMrtMessage):
+"""
+MRT Message for the TABLE_DUMP_V2 Type and the
+SUBTYPE_RIB_IPV6_UNICAST_ADDPATH subtype.
+"""
+_PREFIX_CLS = bgp.IP6AddrPrefix
+_IS_ADDPATH = True
+
+
+@TableDump2MrtMessage.register_type(
+TableDump2MrtRecord.SUBTYPE_RIB_IPV6_MULTICAST_ADDPATH)
+class TableDump2RibIPv6MulticastAddPathMrtMessage(
+TableDump2AfiSafiSpecificRibMrtMessage):
+"""
+MRT Message for the TABLE_DUMP_V2 Type and the
+SUBTYPE_RIB_IPV6_MULTICAST_ADDPATH subtype.
+"""
+_PREFIX_CLS = bgp.IP6AddrPrefix
+_IS_ADDPATH = True
+
+
+@TableDump2MrtMessage.register_type(
 TableDump2MrtRecord.SUBTYPE_RIB_GENERIC)
 class TableDump2RibGenericMrtMessage(TableDump2MrtMessage):
 """
-MRT Message for the TABLE_DUMP_V2 Type and the RIB_GENERIC subtype.
+MRT Message for the TABLE_DUMP_V2 Type and the generic RIB subtypes.
+
+The generic RIB subtypes consist of the RIB_GENERIC and
+RIB_GENERIC_ADDPATH subtypes.
 """
 #  0   1   2   3
 #  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
@@ -729,6 +789,9 @@ class TableDump2RibGenericMrtMessage(TableDump2MrtMessage):
 _HEADER_FMT = '!IHB'
 HEADER_SIZE = struct.calcsize(_HEADER_FMT)
 
+# Is additional-path version?
+_IS_ADDPATH = False
+
 def __init__(self, seq_num, afi, safi, nlri, rib_entries,
  entry_count=None):
 self.seq_num = seq_num
@@ -749,7 +812,7 @@ class TableDump2RibGenericMrtMessage(TableDump2MrtMessage):
 rest = buf[2:]
 rib_entries = []
 for i in range(entry_count):
-r, rest = MrtRibEntry.parse(rest)
+r, rest = MrtRibEntry.parse(rest, i

[Ryu-devel] [PATCH 1/4] mrtlib: Missing subclass for SUBTYPE_RIB_*_MULTICAST

[IWASE Yusuke]

Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 ryu/lib/mrtlib.py | 30 ++
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/ryu/lib/mrtlib.py b/ryu/lib/mrtlib.py
index 83b4e53..c8f86fc 100644
--- a/ryu/lib/mrtlib.py
+++ b/ryu/lib/mrtlib.py
@@ -667,22 +667,44 @@ class 
TableDump2AfiSafiSpecificRibMrtMessage(TableDump2MrtMessage):
 
 @TableDump2MrtMessage.register_type(
 TableDump2MrtRecord.SUBTYPE_RIB_IPV4_UNICAST)
+class TableDump2RibIPv4UnicastMrtMessage(
+TableDump2AfiSafiSpecificRibMrtMessage):
+"""
+MRT Message for the TABLE_DUMP_V2 Type and the
+SUBTYPE_RIB_IPV4_UNICAST subtype.
+"""
+_PREFIX_CLS = bgp.IPAddrPrefix
+
+
 @TableDump2MrtMessage.register_type(
 TableDump2MrtRecord.SUBTYPE_RIB_IPV4_MULTICAST)
-class 
TableDump2RibIPv4UnicastMrtMessage(TableDump2AfiSafiSpecificRibMrtMessage):
+class TableDump2RibIPv4MulticastMrtMessage(
+TableDump2AfiSafiSpecificRibMrtMessage):
 """
 MRT Message for the TABLE_DUMP_V2 Type and the
-RIB_IPV4_UNICAST/SUBTYPE_RIB_IPV4_MULTICAST subtype.
+SUBTYPE_RIB_IPV4_MULTICAST subtype.
 """
 _PREFIX_CLS = bgp.IPAddrPrefix
 
 
 @TableDump2MrtMessage.register_type(
 TableDump2MrtRecord.SUBTYPE_RIB_IPV6_UNICAST)
-class 
TableDump2RibIPv6UnicastMrtMessage(TableDump2AfiSafiSpecificRibMrtMessage):
+class TableDump2RibIPv6UnicastMrtMessage(
+TableDump2AfiSafiSpecificRibMrtMessage):
+"""
+MRT Message for the TABLE_DUMP_V2 Type and the
+SUBTYPE_RIB_IPV6_MULTICAST subtype.
+"""
+_PREFIX_CLS = bgp.IP6AddrPrefix
+
+
+@TableDump2MrtMessage.register_type(
+TableDump2MrtRecord.SUBTYPE_RIB_IPV6_MULTICAST)
+class TableDump2RibIPv6MulticastMrtMessage(
+TableDump2AfiSafiSpecificRibMrtMessage):
 """
 MRT Message for the TABLE_DUMP_V2 Type and the
-RIB_IPV6_UNICAST/SUBTYPE_RIB_IPV6_MULTICAST subtype.
+SUBTYPE_RIB_IPV6_MULTICAST subtype.
 """
 _PREFIX_CLS = bgp.IP6AddrPrefix
 
-- 
2.7.4


--
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] [PATCH 4/4] mrtlib: Define JSON representation types

[IWASE Yusuke]

Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 ryu/lib/mrtlib.py | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/ryu/lib/mrtlib.py b/ryu/lib/mrtlib.py
index a89ccfc..c2d50c6 100644
--- a/ryu/lib/mrtlib.py
+++ b/ryu/lib/mrtlib.py
@@ -264,6 +264,12 @@ class Ospf2MrtMessage(MrtMessage):
 # +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 _HEADER_FMT = '!4s4s'
 HEADER_SIZE = struct.calcsize(_HEADER_FMT)
+_TYPE = {
+'ascii': [
+'remote_ip',
+'local_ip',
+],
+}
 
 def __init__(self, remote_ip, local_ip, ospf_message):
 self.remote_ip = remote_ip
@@ -328,6 +334,12 @@ class TableDumpMrtMessage(MrtMessage):
 # +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 _HEADER_FMT = ''  # should be defined in subclass
 HEADER_SIZE = 0
+_TYPE = {
+'ascii': [
+'prefix',
+'peer_ip',
+],
+}
 
 def __init__(self, view_num, seq_num, prefix, prefix_len, status,
  originated_time, peer_ip, peer_as, bgp_attributes,
@@ -457,6 +469,11 @@ class 
TableDump2PeerIndexTableMrtMessage(TableDump2MrtMessage):
 HEADER_SIZE = struct.calcsize(_HEADER_FMT)
 _PEER_COUNT_FMT = '!H'
 PEER_COUNT_SIZE = struct.calcsize(_PEER_COUNT_FMT)
+_TYPE = {
+'ascii': [
+'bgp_id',
+],
+}
 
 def __init__(self, bgp_id, peer_entries,
  view_name='', view_name_len=None, peer_count=None):
@@ -540,6 +557,13 @@ class MrtPeer(stringify.StringifyMixin):
 IP_ADDR_FAMILY_BIT = 1 << 0
 AS_NUMBER_SIZE_BIT = 1 << 1
 
+_TYPE = {
+'ascii': [
+'bgp_id',
+'ip_addr',
+],
+}
+
 def __init__(self, bgp_id, ip_addr, as_num, type_=0):
 self.type = type_
 self.bgp_id = bgp_id
@@ -937,6 +961,12 @@ class Bgp4MpMrtMessage(MrtMessage):
 """
 MRT Message for the BGP4MP Type.
 """
+_TYPE = {
+'ascii': [
+'peer_ip',
+'local_ip',
+],
+}
 
 
 @MrtRecord.register_type(MrtRecord.TYPE_BGP4MP)
-- 
2.7.4


--
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] Unable to send packet out message

[Iwase Yusuke]

Hi,

If you are using OpenFlow 1.5, please confirm your OVS supports OpenFlow 1.5.
Only some newer version of OVS support OpenFlow 1.5 (some OpenFlow 1.5 features
seems not be supported yet though).
You can test the support status by checking whether
  $ ryu-manager ryu/app/simple_switch_15.py --verbose
can transfer "ping" packets between your hosts or not.

With OVS version 2.9.0, I can send Packet-Out with the following code.

$ git diff
diff --git a/ryu/app/simple_switch_15.py b/ryu/app/simple_switch_15.py
index 6a86ba7..f3503bf 100644
--- a/ryu/app/simple_switch_15.py
+++ b/ryu/app/simple_switch_15.py
@@ -21,6 +21,9 @@ from ryu.ofproto import ofproto_v1_5
 from ryu.lib.packet import packet
 from ryu.lib.packet import ethernet
 from ryu.lib.packet import ether_types
+from ryu.lib.packet import ipv4
+from ryu.lib.packet import in_proto
+from ryu.lib.packet import tcp


 class SimpleSwitch15(app_manager.RyuApp):
@@ -48,6 +51,39 @@ class SimpleSwitch15(app_manager.RyuApp):
   ofproto.OFPCML_NO_BUFFER)]
 self.add_flow(datapath, 0, match, actions)

+actions_out = [parser.OFPActionOutput(1)]
+pkt = packet.Packet()
+pkt.add_protocol(
+ethernet.ethernet(
+dst='08:2e:5f:2f:70:e2',
+src='d4:85:64:17:ea:15',
+ethertype=ether_types.ETH_TYPE_IP,
+)
+)
+pkt.add_protocol(
+ipv4.ipv4(
+dst='192.168.1.1',
+src='192.168.1.2',
+proto=in_proto.IPPROTO_TCP,
+)
+)
+pkt.add_protocol(
+tcp.tcp(
+src_port=50001,
+dst_port=50002,
+)
+)
+pkt.add_protocol(
+b'foobar'
+)
+pkt.serialize()
+match_out = parser.OFPMatch(in_port=2)
+out = parser.OFPPacketOut(
+datapath=datapath,
+buffer_id=ofproto.OFP_NO_BUFFER,
+match=match_out, actions=actions_out, data=pkt.data)
+datapath.send_msg(out)
+
 def add_flow(self, datapath, priority, match, actions):
 ofproto = datapath.ofproto
 parser = datapath.ofproto_parser


Thanks,
Iwase


On 2018年03月29日 02:30, Alvaro Jimenez Moreno wrote:

Hi Iwase, thanks for your response,

Im using OpenFlow 1.5. I tried to create an ethernet packet as you mentioned but 
no packet is sent by the switch. I dont really know what im doing wrong. I just 
want to send a packet from datapath_id == 233669375027733 to datapath_id == 
8995258462434.  Here's the code with the ethernet frame and header:


  @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
     def switch_features_handler(self, ev):
         msg = ev.msg
         datapath = msg.datapath
         ofproto = datapath.ofproto
         parser = datapath.ofproto_parser

         match_miss = parser.OFPMatch()
         actions_miss = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
                                                ofproto.OFPCML_NO_BUFFER)]
         self.add_flow(datapath, 0, match_miss, actions_miss)

         actions_out = [parser.OFPActionOutput(1)]
         #self.add_flow(datapath, 1, match_2, actions_out)
         if msg.datapath_id == 233669375027733:
             match_cpd = parser.OFPMatch(in_port=1, eth_dst='08:2e:5f:2f:70:e2', 
eth_src='d4:85:64:17:ea:15',)

             self.add_flow(datapath, 1, match_cpd, actions_out)
         elif msg.datapath_id == 8995258462434:
             match_srem = parser.OFPMatch(in_port=1, 
eth_dst='d4:85:64:17:ea:15', eth_src='08:2e:5f:2f:70:e2')

             actions_srem = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
                                                    ofproto.OFPCML_NO_BUFFER)]
             self.add_flow(datapath, 1, match_srem, actions_srem)
         #I just send the packet from datapath_id == 233669375027733
         if msg.datapath_id == 233669375027733:
             p = packet.Packet()
             eth = ethernet.ethernet(dst='08:2e:5f:2f:70:e2', 
src='d4:85:64:17:ea:15', ethertype=0x0800)

             p.add_protocol(eth)
             p.serialize()
             match_out = parser.OFPMatch(in_port=1)
             out = parser.OFPPacketOut(datapath=msg.datapath,
                                     buffer_id=ofproto.OFP_NO_BUFFER,
                                     match=match_out, actions=actions_out, 
data=p.data)

             datapath.send_msg(out)


Thanks in advance.


2018-03-23 0:29 GMT+01:00 Iwase Yusuke <iwase.yusu...@gmail.com 
<mailto:iwase.yusu...@gmail.com>>:


Hi Alvaro,

According to the OpenFlow Spec 1.3, the data field of OFPPacketOut must be 
an
Ethernet frame and I think you need to add also Ethernet header using
"ethernet.ethernet" class.

http://osrg.github.io/ryu-book/en/html/packet_lib.html#generation-of-packets-serialization

<http://osrg.github.io/ryu-book

Re: [Ryu-devel] Spliting flows through two ports

[Iwase Yusuke]

Hi Carlos,

The group entries are looked up (or specified) by OFPActionGroup in flow
entries.

If looked up, ref_count, packet_count and byte_count should be incremented.

mininet> sh ovs-ofctl dump-group-stats s1 -O OpenFlow13
OFPST_GROUP reply (OF1.3) (xid=0x4):
group_id=1,duration=45.105s,ref_count=1,packet_count=5,byte_count=378,bucket0:packet_count=4,byte_count=336,bucket1:packet_count=1,byte_count=42

Thanks,
Iwase


On 2018年03月27日 23:10, Jose Carlos Ferreira de Melo Junior wrote:

Hi Iwase,

The group entry is added...















but I don't understand how can be looked up.
I don't know how to do this


Is there any other thing that I am missing 


thanks in advanced







2018-03-26 20:28 GMT-03:00 Iwase Yusuke <iwase.yusu...@gmail.com 
<mailto:iwase.yusu...@gmail.com>>:


Hi Carlos,

 >  "*/using the group table with openflow 1.3 with no sucess/*" means that 
I am
> using the group table as i said before and it is not working, means that 
I am
> using the group specification and it doens't work.

"Does not work" means
  - no group entry added
  - group entry exists, but not looked up
  - group entry looked up, but packets are not outputted
  or ...
which you mean?


> and about your topology: It has only 2 switches or 4???

Only 2 switches (s1 and s2), which corresponding to "Start" and "End" 
switches
on the image you attached on your previous mail. Also h1 and h2 represents 
hosts
which do ping.


Thanks,
Iwase

On 2018年03月26日 21:14, Jose Carlos Ferreira de Melo Junior wrote:

Hey Iwase,

   "*/using the group table with openflow 1.3 with no sucess/*" means
that I am using the group table as i said before and it is not working,
means that I am using the group specification and it doens't work.

and about your topology: It has only 2 switches or 4???

i don't know if my code is right or if i am missing something else.




2018-03-25 21:40 GMT-03:00 Iwase Yusuke <iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com> <mailto:iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>>>:


     Hi Carlos,

     For such purpose, OFPGT_SELECT is appropriate, I guess.

     With the topology;

                    ++             ++
                    |   s1   |             |   s2   |
     ++        |      (port 2)---(port 2)      |        ++
     | h1 |---(port 1)      |             |      (port 1)---| h2 |
     ++        |      (port 3)---(port 3)      |        ++
                    |        |             |        |
                    ++             ++


     I can install groups and flows entries, then can ping between h1
and h2 with the
     following app.


     $ git diff
     diff --git a/ryu/app/simple_switch_13.py 
b/ryu/app/simple_switch_13.py
     index 06a5d0e..e1a5c3b 100644
     --- a/ryu/app/simple_switch_13.py
     +++ b/ryu/app/simple_switch_13.py
     @@ -48,6 +48,30 @@ class SimpleSwitch13(app_manager.RyuApp):
                                                 
ofproto.OFPCML_NO_BUFFER)]
               self.add_flow(datapath, 0, match, actions)

     +        buckets = [
     +            parser.OFPBucket(
     +                50, ofproto.OFPP_ANY, ofproto.OFPG_ANY,
     +                [parser.OFPActionOutput(2)]),
     +            parser.OFPBucket(
     +                50, ofproto.OFPP_ANY, ofproto.OFPG_ANY,
     +                [parser.OFPActionOutput(3)]),
     +        ]
     +        mod = parser.OFPGroupMod(
     +            datapath, ofproto.OFPGC_ADD, ofproto.OFPGT_SELECT, 1,
buckets)
     +        datapath.send_msg(mod)
     +
     +        match = parser.OFPMatch(in_port=1)
     +        actions = [parser.OFPActionGroup(1)]  # from host to 
switch
     +        self.add_flow(datapath, 1, match, actions)
     +
     +        match = parser.OFPMatch(in_port=2)
     +        actions = [parser.OFPActionOutput(1)]  # from switch to 
host
     +        self.add_flow(datapath, 1, match, actions)
     +
     +        match = parser.OFPMatch(in_port=3)
     +        actions = [parser.OFPActionOutput(1)]  # from switch to 
host
     +        self.add_flow(datapath, 1, match, actions)
     +
           def add_flow(self, datapath, priority, match, actions,
buffer_id=None):
               ofproto = datapath.ofproto
               parser = datapath.ofproto_parser


     I don't know

Re: [Ryu-devel] Problem about two controllers use REST api together

[Iwase Yusuke]

Hi,

The cause of this problem seems to be the both controller use the same REST API
(WSGI) port on the same host. How about specifying "--wsapi-port" (or
"--wsapi-host" option?

$ ryu-manager --help
...(snip)...
  --wsapi-host WSAPI_HOST
webapp listen host (default 0.0.0.0)
  --wsapi-port WSAPI_PORT
webapp listen port (default 8080)
...(snip)...

Thanks,
Iwase


On 2018??03??27?? 12:00, 634674795 wrote:

Hello??everyone??
 ?0?2 ?0?2 My project needs two controllers??and both they need REST function.
 ?0?2 ?0?2 My cmd to start contrller1??controller1 connect with 3 switches?? is:
 ?0?2 ?0?2?0?2ryu-manager --ofpcp-listen-port 6633 ofctl_rest.py Controller1.py
 ?0?2 ?0?2 Then I open another cmd window and start controller2??controller2 also 
connect with 3 switches??:

 ?0?2 ?0?2?0?2ryu-manager --ofpcp-listen-port 6634 ofctl_rest.py Controller2.py
 ?0?2 ?0?2 The next step is use mininet to bulid topology and all switches??hosts work 
very well.

 ?0?2 ?0?2 Finally??I use POSTMAN to call REST api: 
http://localhost:8080/stats/switches
I can only get 3 switches' which they are connect with controller1, the other 3 
switches connect with controller2 cannot be found.

 ?0?2 ?0?2 Can you help me? Thank you!


--
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] Spliting flows through two ports

[Iwase Yusuke]

Hi Carlos,

>  "*/using the group table with openflow 1.3 with no sucess/*" means that I am
> using the group table as i said before and it is not working, means that I am
> using the group specification and it doens't work.

"Does not work" means
 - no group entry added
 - group entry exists, but not looked up
 - group entry looked up, but packets are not outputted
 or ...
which you mean?


> and about your topology: It has only 2 switches or 4???

Only 2 switches (s1 and s2), which corresponding to "Start" and "End" switches
on the image you attached on your previous mail. Also h1 and h2 represents hosts
which do ping.


Thanks,
Iwase

On 2018年03月26日 21:14, Jose Carlos Ferreira de Melo Junior wrote:

Hey Iwase,

  "*/using the group table with openflow 1.3 with no sucess/*" means that I am 
using the group table as i said before and it is not working, means that I am 
using the group specification and it doens't work.


and about your topology: It has only 2 switches or 4???

i don't know if my code is right or if i am missing something else.




2018-03-25 21:40 GMT-03:00 Iwase Yusuke <iwase.yusu...@gmail.com 
<mailto:iwase.yusu...@gmail.com>>:


Hi Carlos,

For such purpose, OFPGT_SELECT is appropriate, I guess.

With the topology;

               ++             ++
               |   s1   |             |   s2   |
++        |      (port 2)---(port 2)      |        ++
| h1 |---(port 1)      |             |      (port 1)---| h2 |
++        |      (port 3)---(port 3)      |        ++
               |        |             |        |
               ++             ++


I can install groups and flows entries, then can ping between h1 and h2 
with the
following app.


$ git diff
diff --git a/ryu/app/simple_switch_13.py b/ryu/app/simple_switch_13.py
index 06a5d0e..e1a5c3b 100644
--- a/ryu/app/simple_switch_13.py
+++ b/ryu/app/simple_switch_13.py
@@ -48,6 +48,30 @@ class SimpleSwitch13(app_manager.RyuApp):
                                            ofproto.OFPCML_NO_BUFFER)]
          self.add_flow(datapath, 0, match, actions)

+        buckets = [
+            parser.OFPBucket(
+                50, ofproto.OFPP_ANY, ofproto.OFPG_ANY,
+                [parser.OFPActionOutput(2)]),
+            parser.OFPBucket(
+                50, ofproto.OFPP_ANY, ofproto.OFPG_ANY,
+                [parser.OFPActionOutput(3)]),
+        ]
+        mod = parser.OFPGroupMod(
+            datapath, ofproto.OFPGC_ADD, ofproto.OFPGT_SELECT, 1, buckets)
+        datapath.send_msg(mod)
+
+        match = parser.OFPMatch(in_port=1)
+        actions = [parser.OFPActionGroup(1)]  # from host to switch
+        self.add_flow(datapath, 1, match, actions)
+
+        match = parser.OFPMatch(in_port=2)
+        actions = [parser.OFPActionOutput(1)]  # from switch to host
+        self.add_flow(datapath, 1, match, actions)
+
+        match = parser.OFPMatch(in_port=3)
+        actions = [parser.OFPActionOutput(1)]  # from switch to host
+        self.add_flow(datapath, 1, match, actions)
+
      def add_flow(self, datapath, priority, match, actions, 
buffer_id=None):
          ofproto = datapath.ofproto
          parser = datapath.ofproto_parser


I don't know what "using the group table with openflow 1.3 with no sucess"
means, but please confirm your group and flow table again.

Thanks,
Iwase


On 2018年03月23日 21:11, Jose Carlos Ferreira de Melo Junior wrote:

Hey Iwase,


Split means really divide the flow I dont know if would be like a load
balancing (I think it is)

For example the image below




But I dont know if this would be possible using the group table.

2018-03-23 4:04 GMT-03:00 Iwase Yusuke <iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com> <mailto:iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>>>:


     Hi Carlos,

     What does "split flows" exactly mean?

      > req = parser.OFPGroupMod(datapath, ofp.OFPFC_ADD, 
ofp.OFPGT_SELECT,
      >                          group_id, buckets)

     If you specify OFPGT_SELECT, switch will execute "one" bucket in
the group and
     not copied like the port mirroring. If you intend to do port
mirroring, you need
     to specify OFPGT_ALL. For other available group types, please refer
to the
     OpenFlow spec and your switch's specification.

     Thanks,
     Iwase


     On 2018年03月21日 04:02, Jose Carlos Ferreira de Melo Junior wrote:

         Hi there,

         I know this topic was discuss

Re: [Ryu-devel] All the links of the topology not getting discovered.

[Iwase Yusuke]

Hi Taha,

Hmmm... I haven't tried yet though, the following parameters seems to be
configured. But sorry I don't know those parameters meanings further...
https://github.com/osrg/ryu/blob/master/ryu/topology/switches.py#L509-L513

Thanks,
Iwase

On 2018年03月26日 10:45, Taha Khan wrote:

Well, What I observed is - Number of Nodes: 13, Number of Edges:21.
Is there a way this could be increased in terms of number of edges and nodes?


Thanks!
Taha


On Sun, Mar 25, 2018 at 7:33 PM, Iwase Yusuke <iwase.yusu...@gmail.com 
<mailto:iwase.yusu...@gmail.com>> wrote:


Hi Taha,

> But do you have any rough idea, how many links should a topology have to 
not
> hit performance limit?

Sorry, I don't have any idea...

Thanks,
Iwase


On 2018年03月24日 11:07, Taha Khan wrote:

Thanks for the reply.
But do you have any rough idea, how many links should a topology have to
not hit performance limit?
This is my systems specs.
I need EventLinkAdd and EventLinkDelete to work properly as I am
planning to introduce multiple link failures from mininet.

I started with 62 nodes, 107 links and trimmed my topology to 30 Nodes
and 43 Links(86 bi-directional) and found, I was able to discover the
full topology but EventLinkDelete wasn't triggering when I tried
with mininet (link down command).
Now I have 30 Nodes, 32 Links and still EventLinkDelte is not getting
triggered though I see the full topology information in my structures
storing their information in RYU controller.








Thanks!
Taha


On Fri, Mar 23, 2018 at 3:45 AM, Iwase Yusuke <iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com> <mailto:iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>>> wrote:

     Hi Taha,

     IIRC, the similar problems had reported before on this mailing 
list.
     I think you hit the performance limit of "single" controller in
order to use
     topology discovery feature against such many switches.

     For handling such large topology, how about splitting your topology
into some
     sub-topology and having multiple controllers?

     Thanks,
     Iwase



     On 2018年03月23日 16:07, Taha Khan wrote:

         Hi

         I am using RYU-4.23 and Mininet OVS.
         I have a 62 Node topology. When I run my RYU application I
noticed that
         RYU is not able to discover all the datapaths and links
everytime I run
         my code. And also when I run (link down command ) in mininet 
CLI,
         EventLinkDelete is not getting triggered everytime I did it.
Few times I
         was actually able to discover the full topology and
EventLinkDelete was
         also getting triggered.
         Can you please suggest why is this so. I have attached codes 
below.


         Thanks!
         Taha



--

         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 <mailto:Ryu-devel@lists.sourceforge.net>
<mailto:Ryu-devel@lists.sourceforge.net
<mailto:Ryu-devel@lists.sourceforge.net>>
https://lists.sourceforge.net/lists/listinfo/ryu-devel
<https://lists.sourceforge.net/lists/listinfo/ryu-devel>
         <https://lists.sourceforge.net/lists/listinfo/ryu-devel
<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 <mailto:Ryu-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/ryu-devel
<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



--
Che

Re: [Ryu-devel] Disable/Enable switch port with ryu

[Iwase Yusuke]

Hi Valson,

How about using OFPPortMod message?
http://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#ryu.ofproto.ofproto_v1_3_parser.OFPPortMod

Thanks,
Iwase


On 2018年03月24日 04:51, Valson Pereira wrote:

Hi everyone;

How i can disable/enable a specific swicth port with ryu?

Thanks.


--
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] Spliting flows through two ports

[Iwase Yusuke]

Hi Carlos,

For such purpose, OFPGT_SELECT is appropriate, I guess.

With the topology;

  ++ ++
  |   s1   | |   s2   |
++|  (port 2)---(port 2)  |++
| h1 |---(port 1)  | |  (port 1)---| h2 |
++|  (port 3)---(port 3)  |++
  || ||
  ++ ++


I can install groups and flows entries, then can ping between h1 and h2 with the
following app.


$ git diff
diff --git a/ryu/app/simple_switch_13.py b/ryu/app/simple_switch_13.py
index 06a5d0e..e1a5c3b 100644
--- a/ryu/app/simple_switch_13.py
+++ b/ryu/app/simple_switch_13.py
@@ -48,6 +48,30 @@ class SimpleSwitch13(app_manager.RyuApp):
   ofproto.OFPCML_NO_BUFFER)]
 self.add_flow(datapath, 0, match, actions)

+buckets = [
+parser.OFPBucket(
+50, ofproto.OFPP_ANY, ofproto.OFPG_ANY,
+[parser.OFPActionOutput(2)]),
+parser.OFPBucket(
+50, ofproto.OFPP_ANY, ofproto.OFPG_ANY,
+[parser.OFPActionOutput(3)]),
+]
+mod = parser.OFPGroupMod(
+datapath, ofproto.OFPGC_ADD, ofproto.OFPGT_SELECT, 1, buckets)
+datapath.send_msg(mod)
+
+match = parser.OFPMatch(in_port=1)
+actions = [parser.OFPActionGroup(1)]  # from host to switch
+self.add_flow(datapath, 1, match, actions)
+
+match = parser.OFPMatch(in_port=2)
+actions = [parser.OFPActionOutput(1)]  # from switch to host
+self.add_flow(datapath, 1, match, actions)
+
+match = parser.OFPMatch(in_port=3)
+actions = [parser.OFPActionOutput(1)]  # from switch to host
+self.add_flow(datapath, 1, match, actions)
+
 def add_flow(self, datapath, priority, match, actions, buffer_id=None):
 ofproto = datapath.ofproto
 parser = datapath.ofproto_parser


I don't know what "using the group table with openflow 1.3 with no sucess"
means, but please confirm your group and flow table again.

Thanks,
Iwase


On 2018年03月23日 21:11, Jose Carlos Ferreira de Melo Junior wrote:

Hey Iwase,


Split means really divide the flow I dont know if would be like a load balancing 
(I think it is)


For example the image below




But I dont know if this would be possible using the group table.

2018-03-23 4:04 GMT-03:00 Iwase Yusuke <iwase.yusu...@gmail.com 
<mailto:iwase.yusu...@gmail.com>>:


Hi Carlos,

What does "split flows" exactly mean?

 > req = parser.OFPGroupMod(datapath, ofp.OFPFC_ADD, ofp.OFPGT_SELECT,
 >                          group_id, buckets)

If you specify OFPGT_SELECT, switch will execute "one" bucket in the group 
and
not copied like the port mirroring. If you intend to do port mirroring, you 
need
to specify OFPGT_ALL. For other available group types, please refer to the
OpenFlow spec and your switch's specification.

Thanks,
Iwase


On 2018年03月21日 04:02, Jose Carlos Ferreira de Melo Junior wrote:

Hi there,

I know this topic was discussed before but I would like just a simple
explanation about it.

Because I am using the group table with openflow 1.3 with no sucess.


My purpose is to split one flow in two flows and forward on port 3 and 4
using the group table.

My code is as follows:


*def group_mod(self, datapath):*
*        global ofp, _parser_, dp*
*        port_1 = 4*
*        queue_1 = _parser_.OFPActionSetQueue(0)*
*        actions_1 = [queue_1, _parser_.OFPActionOutput(port_1)]*
*
*
*
*
*        port_2 = 3*
*        queue_2 = _parser_.OFPActionSetQueue(0)*
*        actions_2 = [queue_2, _parser_.OFPActionOutput(port_2)]*
*
*
*        weight_1 = 50*
*        weight_2 = 50*
*
*
*        watch_port = ofproto_v1_3.OFPP_ANY*
*        watch_group = ofproto_v1_3.OFPQ_ALL*
*
*
*        buckets = [*
*                _parser_.OFPBucket(weight_1, watch_port, watch_group,
actions_1),*
*                _parser_.OFPBucket(weight_2, watch_port, watch_group,
actions_2)]*
*
*
*        group_id = 50*
*
*
*        req = _parser_.OFPGroupMod(datapath, ofp.OFPFC_ADD,
ofp.OFPGT_SELECT,*
*                group_id, buckets)*
*
*
*        datapath.send_msg(req)*
*
*
*
*
*
*
Hope this is right.

Could anyone help me with this issue?




-- 
Best regards,

José Carlos Ferreira
Msc student in Computer Science

Re: [Ryu-devel] All the links of the topology not getting discovered.

[Iwase Yusuke]

Hi Taha,

> But do you have any rough idea, how many links should a topology have to not
> hit performance limit?

Sorry, I don't have any idea...

Thanks,
Iwase


On 2018年03月24日 11:07, Taha Khan wrote:

Thanks for the reply.
But do you have any rough idea, how many links should a topology have to not hit 
performance limit?

This is my systems specs.
I need EventLinkAdd and EventLinkDelete to work properly as I am planning to 
introduce multiple link failures from mininet.


I started with 62 nodes, 107 links and trimmed my topology to 30 Nodes and 43 
Links(86 bi-directional) and found, I was able to discover the full topology but 
EventLinkDelete wasn't triggering when I tried with mininet (link down command).
Now I have 30 Nodes, 32 Links and still EventLinkDelte is not getting triggered 
though I see the full topology information in my structures storing their 
information in RYU controller.









Thanks!
Taha

On Fri, Mar 23, 2018 at 3:45 AM, Iwase Yusuke <iwase.yusu...@gmail.com 
<mailto:iwase.yusu...@gmail.com>> wrote:


Hi Taha,

IIRC, the similar problems had reported before on this mailing list.
I think you hit the performance limit of "single" controller in order to use
topology discovery feature against such many switches.

For handling such large topology, how about splitting your topology into 
some
sub-topology and having multiple controllers?

Thanks,
Iwase



On 2018年03月23日 16:07, Taha Khan wrote:

Hi

I am using RYU-4.23 and Mininet OVS.
I have a 62 Node topology. When I run my RYU application I noticed that
RYU is not able to discover all the datapaths and links everytime I run
my code. And also when I run (link down command ) in mininet CLI,
EventLinkDelete is not getting triggered everytime I did it. Few times I
was actually able to discover the full topology and EventLinkDelete was
also getting triggered.
Can you please suggest why is this so. I have attached codes below.


Thanks!
Taha



--
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 <mailto:Ryu-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/ryu-devel
<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



--
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] All the links of the topology not getting discovered.

[Iwase Yusuke]

Hi Taha,

IIRC, the similar problems had reported before on this mailing list.
I think you hit the performance limit of "single" controller in order to use
topology discovery feature against such many switches.

For handling such large topology, how about splitting your topology into some
sub-topology and having multiple controllers?

Thanks,
Iwase


On 2018年03月23日 16:07, Taha Khan wrote:

Hi

I am using RYU-4.23 and Mininet OVS.
I have a 62 Node topology. When I run my RYU application I noticed that RYU is 
not able to discover all the datapaths and links everytime I run my code. And 
also when I run (link down command ) in mininet CLI, EventLinkDelete is not 
getting triggered everytime I did it. Few times I was actually able to discover 
the full topology and EventLinkDelete was also getting triggered.

Can you please suggest why is this so. I have attached codes below.


Thanks!
Taha


--
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] Informing the controller about the first switch Datapath and port number which connected to the host.

[Iwase Yusuke]

Hi Soliman,

"ryu.topology" provides such feature, I guess.
How about the following APIs and events?
https://github.com/osrg/ryu/blob/master/ryu/topology/api.py#L38-L44
https://github.com/osrg/ryu/blob/e6773539b546576c13f7397769d2001c46bbfdaa/ryu/topology/event.py#L169-L186

If you want to implement your own host detection logic, the following app might
be helpful for you.
https://github.com/osrg/ryu/blob/master/ryu/topology/switches.py

Thanks,
Iwase


On 2018年03月22日 03:45, Soliman Awad Alshra´a Abdullah TU Ilmenau wrote:

Hello Dears,

In my topology, I should send packets from the host to a Ryu controller through 
many switches. I need to inform the controller about the first switch Datapath 
and port number which connected to the host.




Any idea or advice ?

Thanks in advance



--
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] Spliting flows through two ports

[Iwase Yusuke]

Hi Carlos,

What does "split flows" exactly mean?

> req = parser.OFPGroupMod(datapath, ofp.OFPFC_ADD, ofp.OFPGT_SELECT,
>  group_id, buckets)

If you specify OFPGT_SELECT, switch will execute "one" bucket in the group and
not copied like the port mirroring. If you intend to do port mirroring, you need
to specify OFPGT_ALL. For other available group types, please refer to the
OpenFlow spec and your switch's specification.

Thanks,
Iwase


On 2018年03月21日 04:02, Jose Carlos Ferreira de Melo Junior wrote:

Hi there,

I know this topic was discussed before but I would like just a simple 
explanation about it.


Because I am using the group table with openflow 1.3 with no sucess.


My purpose is to split one flow in two flows and forward on port 3 and 4 using 
the group table.


My code is as follows:


*def group_mod(self, datapath):*
*        global ofp, _parser_, dp*
*        port_1 = 4*
*        queue_1 = _parser_.OFPActionSetQueue(0)*
*        actions_1 = [queue_1, _parser_.OFPActionOutput(port_1)]*
*
*
*
*
*        port_2 = 3*
*        queue_2 = _parser_.OFPActionSetQueue(0)*
*        actions_2 = [queue_2, _parser_.OFPActionOutput(port_2)]*
*
*
*        weight_1 = 50*
*        weight_2 = 50*
*
*
*        watch_port = ofproto_v1_3.OFPP_ANY*
*        watch_group = ofproto_v1_3.OFPQ_ALL*
*
*
*        buckets = [*
*                _parser_.OFPBucket(weight_1, watch_port, watch_group, 
actions_1),*
*                _parser_.OFPBucket(weight_2, watch_port, watch_group, 
actions_2)]*
*
*
*        group_id = 50*
*
*
*        req = _parser_.OFPGroupMod(datapath, ofp.OFPFC_ADD, ofp.OFPGT_SELECT,*
*                group_id, buckets)*
*
*
*        datapath.send_msg(req)*
*
*
*
*
*
*
Hope this is right.

Could anyone help me with this issue?




--
Best regards,
José Carlos Ferreira
Msc student in Computer Science
System and Network Analyst at PoP-PE/RNP


--
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] Running multiple controllers

[Iwase Yusuke]

Hi,

I think this issue is a problem of Mininet not Ryu. I found the similar script
on Mininet's GitHub, but I don't know further.
https://github.com/mininet/mininet/blob/master/examples/controllers2.py

Thanks,
Iwase


On 2018年03月21日 00:05, Soliman Awad Alshra´a Abdullah TU Ilmenau wrote:

Hello all,

I am setting up a topology consists of 5 switches and 2 controllers, three 
switches connect to the first controller and the other connect to the second one.


    C1    C2

   /    |    \     / \

s1-- s2 - s3--s4--s5

c1 = net.addController('c1', controller=RemoteController, ip="127.0.0.1", 
port=6634)

c2 = net.addController('c2', controller=RemoteController, ip="127.0.0.2", 
port=6633)

and I use :

c1.start()

c2.start()

s1.start([c1])

s2.start([c1])

s3.start([c1])

s4.start([c2])

s5.start([c2])

unfortunately, All switches connect to both of controllers.

1 - how to force s1, s2 and s3 to  get instructions from C1 only ?

2 - how to install some entry to a certain switch ?



I look forward to hearing you

Thanks in advance
A.Soliman

*


*



--
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] [PATCH 0/2] Avoid using pip as library

[IWASE Yusuke]

As Stamatis reported on;
  [Ryu-devel] Problem with new version of Pip
Using "pip" as a Python library is not offically recommended and planned to
break in "pip" version 10.

The following patches removes an unused function and fixes an unit test file,
which are importing "pip", in order to avoid this problem.

IWASE Yusuke (2):
  utils: Remove "parse_requirements" function
  test_requirements: Avoid using pip as library

 ryu/tests/unit/test_requirements.py | 13 ++---
 ryu/utils.py| 31 ---
 2 files changed, 6 insertions(+), 38 deletions(-)

--
2.7.4


--
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] [PATCH 2/2] test_requirements: Avoid using pip as library

[IWASE Yusuke]

Because importing "pip" in Python scripts is not supported usage of
"pip", this patch fixes to use "pkg_resources" + "urllib" instead.

Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 ryu/tests/unit/test_requirements.py | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/ryu/tests/unit/test_requirements.py 
b/ryu/tests/unit/test_requirements.py
index 9f50a51..c842a0f 100644
--- a/ryu/tests/unit/test_requirements.py
+++ b/ryu/tests/unit/test_requirements.py
@@ -19,8 +19,6 @@ import sys
 import unittest
 
 import pkg_resources
-from pip.req import parse_requirements
-from pip.download import PipSession
 from six.moves import urllib
 
 from nose.tools import ok_
@@ -28,7 +26,7 @@ from nose.tools import ok_
 
 LOG = logging.getLogger(__name__)
 
-MOD_DIR = os.path.dirname(sys.modules[__name__].__file__)
+MOD_DIR = os.path.dirname('file://' + sys.modules[__name__].__file__)
 _RYU_REQUIREMENTS_FILES = [
 '../../../tools/pip-requires',
 '../../../tools/optional-requires',
@@ -51,9 +49,10 @@ OPENSTACK_REQUIREMENTS_FILES = [
 def _get_requirements(files):
 requirements = {}
 for f in files:
-req = parse_requirements(f, session=PipSession())
-for r in req:
-requirements[r.name] = str(r.req)
+response = urllib.request.urlopen(f)
+contents = response.read().decode('utf-8')
+for r in pkg_resources.parse_requirements(contents):
+requirements[r.name] = str(r)
 
 return requirements
 
@@ -82,5 +81,5 @@ class TestRequirements(unittest.TestCase):
 except pkg_resources.VersionConflict as e:
 LOG.exception(
 'Some requirements of Ryu are conflicting with that of '
-'OpenStack project: %s' % OPENSTACK_REQUIREMENTS_REPO)
+'OpenStack project: %s', OPENSTACK_REQUIREMENTS_REPO)
 raise e
-- 
2.7.4


--
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] [PATCH 1/2] utils: Remove "parse_requirements" function

[IWASE Yusuke]

This patch removes unused function "parse_requirements" in order to
avoid using "pip" as a Python library.

Note: Officially "from pip import req as pip_req" is not supported usage
of "pip".

Reported-by: Katsaounis Molyvas Stamatios <mok...@intracom-telecom.com>
Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 ryu/utils.py | 31 ---
 1 file changed, 31 deletions(-)

diff --git a/ryu/utils.py b/ryu/utils.py
index 8bfdf7d..ca14c12 100644
--- a/ryu/utils.py
+++ b/ryu/utils.py
@@ -126,34 +126,3 @@ def binary_str(data):
 """
 # convert data into bytearray explicitly
 return ''.join('\\x%02x' % byte for byte in bytearray(data))
-
-
-def parse_requirements(requirements_files=None):
-"""
-Parses requirements files and returns a list of requirements.
-
-Returned list would be like::
-
-['foo', 'bar>=X.X', ...]
-
-:param requirements_files: List of requirements files. The default
- is ['requirements.txt', 'tools/pip-requires'].
-:return: List of requirements.
-"""
-from pip import req as pip_req
-from pip.download import PipSession
-
-requirements_files = requirements_files or [
-'requirements.txt',
-'tools/pip-requires',
-]
-
-requirements = []
-for f in requirements_files:
-if not os.path.isfile(f):
-continue
-
-for r in pip_req.parse_requirements(f, session=PipSession()):
-requirements.append(str(r.req))
-
-return requirements
-- 
2.7.4


--
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] Problem with new version of Pip

[Iwase Yusuke]

Hi,

Thanks a lot for your information! It is very helpful for me!

As you mentioned on the issue #5099, Ryu imports "pip" at;
https://github.com/osrg/ryu/blob/e6773539b546576c13f7397769d2001c46bbfdaa/ryu/utils.py#L143-L144
and also;
https://github.com/osrg/ryu/blob/e6773539b546576c13f7397769d2001c46bbfdaa/ryu/tests/unit/test_requirements.py#L22-L23

For the former one, the "parse_requirements" function seems to be no longer
used, then I guess we can remove it.
And for the latter one, I think we can write an alternative way instead of using
"pip".

I will post patches for this issue soon.

Thanks,
Iwase

On 2018年03月21日 22:09, Katsaounis Molyvas Stamatios wrote:

Hello Ryu devs,

I would like to inform you about a problem concerning Ryu when used with new 
version of Pip 9.0.2


Please find more information on the issue I opened at Pip repo: 
https://github.com/pypa/pip/issues/5099


Kind regards,

*Stamatis Katsaounis
*Software Enginner

Software Development Center
__
Intracom Telecom
19.7 km Markopoulou Ave., Peania, GR 19002
_mok...@intracom-telecom.com 
_http://www.intracom-telecom.com/











*JOIN US*



Mobile World Congress Shanghai

27-29 June
Shanghai, China



Mobile World Congress Americas

12-14 September
Los Angeles, USA



Gitex Technology Week

14-18 October
Dubai, UAE



FutureCom

15-18 October

Sao Paulo, Brazil



AfricaCom

13-15 November

Cape Town, S. Africa



--
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] Unable to send packet out message

[Iwase Yusuke]

Hi Alvaro,

According to the OpenFlow Spec 1.3, the data field of OFPPacketOut must be an
Ethernet frame and I think you need to add also Ethernet header using
"ethernet.ethernet" class.
http://osrg.github.io/ryu-book/en/html/packet_lib.html#generation-of-packets-serialization

> p = packet.Packet()
> ip = ipv4.ipv4(src='172.16.10.10', dst='172.16.10.20')
> p.add_protocol(ip)
> p.serialize()

From your code, you seems to add only IPv4 header and no Ethernet header.

Thanks,
Iwase


On 2018年03月23日 01:22, Alvaro Jimenez Moreno wrote:


Hi, Im having some issues to send a packet out message between 2 ovs. Im have 3 
PCs. 2 of them act like an ovs and the third one has the Ryu controller. Im have 
a vlan (vid=44) por signal traffic between both ovs and the controller and a 
vlan (vid=10) just for transport between both ovs. I also have the 3 PCs 
physically connected by a Cisco Catalyst 2960 switch. Im figuring out how to 
send a packet out from one ovs (172.16.10.10) to the other ovs (172.16.10.20) 
without receiving a packet in message first. Now im sending the packet out in 
the switch features handler as follows:


Switch features handler:

@set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
def switch_features_handler(self, ev):
msg = ev.msg
datapath = msg.datapath
ofproto = datapath.ofproto
parser = datapath.ofproto_parser

match_miss = parser.OFPMatch()
actions_miss = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
ofproto.OFPCML_NO_BUFFER)]

self.add_flow(datapath, 0, match_miss, actions_miss)
match_2 = parser.OFPMatch(in_port=1, eth_type=0x800, ipv4_dst='172.16.10.20')

actions_out = [parser.OFPActionOutput(port=1)]
self.add_flow(datapath, 1, match_2, actions_out)

#I send the packet out just from one ovs:
if msg.datapath_id == 233669375027733:
p = packet.Packet()
ip = ipv4.ipv4(src='172.16.10.10', dst='172.16.10.20')
p.add_protocol(ip)
p.serialize()
match_out = parser.OFPMatch(in_port=1)
out = parser.OFPPacketOut(datapath=msg.datapath,
buffer_id=ofproto.OFP_NO_BUFFER,
match=match_out, actions=actions_out, data=p.data)
datapath.send_msg(out)

def add_flow(self, datapath, priority, match, actions):
ofproto = datapath.ofproto
parser = datapath.ofproto_parser

inst = [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS,
actions)]

mod = parser.OFPFlowMod(datapath=datapath, priority=priority,
match=match, instructions=inst)
datapath.send_msg(mod)

Packet in handler:

@set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
def packet_in_handler(self, ev):
msg = ev.msg
dp = msg.datapath
ofp = dp.ofproto

if msg.reason == ofp.OFPR_TABLE_MISS:
reason = 'TABLE MISS'
elif msg.reason == ofp.OFPR_APPLY_ACTION:
reason = 'APPLY ACTION'
elif msg.reason == ofp.OFPR_INVALID_TTL:
reason = 'INVALID TTL'
elif msg.reason == ofp.OFPR_ACTION_SET:
reason = 'ACTION SET'
elif msg.reason == ofp.OFPR_GROUP:
reason = 'GROUP'
elif msg.reason == ofp.OFPR_PACKET_OUT:
reason = 'PACKET OUT'
else:
reason = 'unknown'

if reason == 'PACKET OUT':
self.logger.debug('OFPPacketIn received: '
'buffer_id=%x total_len=%d reason=%s '
'table_id=%d cookie=%d match=%s ',
msg.buffer_id, msg.total_len, reason,
msg.table_id, msg.cookie, msg.match)
self.logger.debug('DATAPATH ADDRESS:%s', dp.address)

I never recieve a packet in message due o a packet out message. Any help will be 
appreciated.


Thanks in advance.



--
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] How to obtain ip address of hosts

[Iwase Yusuke]

Hi Zhang and Thanks a lot ??!

Excuse me for jumping in.

Please refer to the Ryu-Book for getting started.
For example, "Switching Hub" section describes how to get MAC address of hosts
on Ryu application. I guess you can also get IP address in the similar way.
http://osrg.github.io/ryu-book/en/html/switching_hub.html

Thanks,
Iwase

On 2018??03??09?? 15:49, ?? wrote:

You may need to read the files inside .../ryu/ryu/app.

At 2018-03-09 14:34:52, "Zhang Yifan"  wrote:

Hi,

Yeah, I can get the IP using Mininet. But I want the Ryu controller learn
the ip/mac adderss of hosts.


--?0?2Original?0?2--
*From: *?0?2"??";<15622383...@163.com >;
*Send time:*?0?2Friday, Mar 9, 2018 2:28 PM
*To:*?0?2"Zhang Yifan";
*Cc:*?0?2"ryu-devel">; "Marcos">;
*Subject: *?0?2Re: [Ryu-devel] How to obtain ip address of hosts

Hi,

I think you might need to have a look at the walkthrough on mininet.org. It
might help you a lot.

At 2018-03-09 14:06:27, "Zhang Yifan" > wrote:

Hi,

Thanks for your answer.

I also want to know if I use the command 'ping' and generate a ICMP 
packet,
how to get IP address from this packet?
Is there any method in Ryu API? I did not find it.


-- Original --
*From: *?0?2"Marcos";>;
*Send time:*?0?2Friday, Mar 9, 2018 12:12 PM
*To:*?0?2"Zhang Yifan";
*Cc:*?0?2"ryu-devel">;
*Subject: *?0?2Re: [Ryu-devel] How to obtain ip address of hosts

Hello,

You should to gerenerated traffic in hosts, so you can capture packets
and extract IP address.
On Mar 9, 2018, at 1:06 AM, Zhang Yifan > wrote:

Hi,

I use Ryu 4.23 and ?0?2Mininet 2.3.0d1 (OVS version is 2.5.2) test 
SDN
applications.

My Ryu controller connect to OpenFlow Switches, and some hosts
connect to these Switches.

I want to know how can I get the ip address of the hosts?

Thanks,
YF




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



??|30??29.9>






??|30??29.9> 




--
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] example code Openflow client talking to Ryu controller

[Iwase Yusuke]

Hi Shivaram
  (and thanks Suresh!)

You mean you want to defined own stats message structure?

I think you can use OFPExperimenterMultipart (or inherit it) to describe your
own message, but also need to implement your switch to send that message.
https://github.com/osrg/ryu/blob/master/ryu/ofproto/ofproto_v1_3_parser.py#L5672

Then I don't recommend to use experimenter message way. As Suresh(knet solutions
<knetsolutio...@gmail.com>) said, how about running small "agent" application on
your switch and then calling its API (via REST, RPC or so) from your Ryu app?

Thanks,
Iwase


On 2018年03月08日 14:53, knet solutions wrote:
I think, you are trying to implement the openflow agent for the NIC card.    In 
my perspective ,its not related to Controller stuff.


On Thu, Mar 8, 2018 at 10:14 AM, Shivaram Mysore <shivaram.mys...@gmail.com 
<mailto:shivaram.mys...@gmail.com>> wrote:


Hi Iwase,
Let me clarify the use case a little bit more.

Lets say, you run on Linux
# ethtool -S enp1s0

you will get a bunch of NIC stats.  I want to wrap the same in an openflow
message and send it to a Ryu controller running my special Ryu App which
will connect to this client and

  * ask for

http://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#ryu.ofproto.ofproto_v1_3_parser.OFPPortStatsRequest

<http://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#ryu.ofproto.ofproto_v1_3_parser.OFPPortStatsRequest>
  * and I want to wrap the NIC stats and send response via

http://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#ryu.ofproto.ofproto_v1_3_parser.OFPPortStatsReply

<http://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#ryu.ofproto.ofproto_v1_3_parser.OFPPortStatsReply>

So, I want to use the Ryu Openflow API to do this.

Does this help?

Thanks

/Shivaram


    On Wed, Mar 7, 2018 at 8:27 PM, Iwase Yusuke <iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>> wrote:

Hi Shivaram,

You mean you need to send some (stats?) message from Ryu controller to
another
Ryu controller, right?

H... Ryu implements the OpenFlow parsers as "Controller side",
parsers for
"from switch" messages have no "serialize()" method (some of messages
have both
"serialize()" and "parser()" for unit tests though). So you need to
implement
"serialize()" method on the stats "reply" message parser class to send
them to
another controller.

Thanks,
Iwase



On 2018年03月08日 13:02, Shivaram Mysore wrote:

Hi,
I am looking for example Ryu API usage where Ryu framework is used
to construct a Openflow message sent to Ryu controller.

Use case is that I just want to send say, network statistics to Ryu
Openflow controller where I have a Ryu application that is listening
to Openflow stats and meter messages.

Any pointers?

Thanks

/Shivaram



--
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 
<mailto:Ryu-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/ryu-devel
<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 <mailto:Ryu-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/ryu-devel
<https://lists.sourceforge.net/lists/listinfo/ryu-devel>




--
*/Regards,
/*
*/Knet solutions./*

https://github.com/knetsolutions/KNet
http://knet-topology-builder.readthedocs.io/
http://knetsolutions.in/



--
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/s

[Ryu-devel] [PATCH 0/2] nicira_ext: Support Network Service Header match

[IWASE Yusuke]

The following patches support the Nicira Extended match for Network Service
Header (NSH).

Note: To use NSH match, OVS v2.8 or later is required.

IWASE Yusuke (2):
  nicira_ext: Support Network Service Header match
  nicira_ext: Support DEC_NSH_TTL action

 doc/source/nicira_ext_ref.rst |  1 +
 ryu/lib/packet/ether_types.py |  1 +
 ryu/ofproto/nicira_ext.py | 39 +++
 ryu/ofproto/nx_actions.py | 36 
 ryu/ofproto/ofproto_common.py |  1 +
 ryu/ofproto/oxm_fields.py |  4 
 6 files changed, 82 insertions(+)

--
2.7.4


--
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] [PATCH 2/2] nicira_ext: Support DEC_NSH_TTL action

[IWASE Yusuke]

Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 doc/source/nicira_ext_ref.rst |  1 +
 ryu/ofproto/nicira_ext.py |  1 +
 ryu/ofproto/nx_actions.py | 36 
 3 files changed, 38 insertions(+)

diff --git a/doc/source/nicira_ext_ref.rst b/doc/source/nicira_ext_ref.rst
index 739349c..7ca1b0c 100644
--- a/doc/source/nicira_ext_ref.rst
+++ b/doc/source/nicira_ext_ref.rst
@@ -54,6 +54,7 @@ The followings shows the supported NXAction classes in 
OpenFlow1.0 or later
 .. autoclass:: NXActionCT
 .. autoclass:: NXActionNAT
 .. autoclass:: NXActionOutputTrunc
+.. autoclass:: NXActionDecNshTtl
 .. autoclass:: NXFlowSpecMatch
 .. autoclass:: NXFlowSpecLoad
 .. autoclass:: NXFlowSpecOutput
diff --git a/ryu/ofproto/nicira_ext.py b/ryu/ofproto/nicira_ext.py
index 94f38fc..4a06b64 100644
--- a/ryu/ofproto/nicira_ext.py
+++ b/ryu/ofproto/nicira_ext.py
@@ -62,6 +62,7 @@ NXAST_NAT = 36
 NXAST_CONTROLLER2 = 37
 NXAST_SAMPLE2 = 38
 NXAST_OUTPUT_TRUNC = 39
+NXAST_DEC_NSH_TTL = 48
 
 NX_ACTION_RESUBMIT_PACK_STR = '!HHIHHB3x'
 NX_ACTION_RESUBMIT_SIZE = 16
diff --git a/ryu/ofproto/nx_actions.py b/ryu/ofproto/nx_actions.py
index 8921007..18dc921 100644
--- a/ryu/ofproto/nx_actions.py
+++ b/ryu/ofproto/nx_actions.py
@@ -2984,6 +2984,41 @@ def generate(ofp_name, ofpp_name):
   self.max_len)
 return data
 
+class NXActionDecNshTtl(NXAction):
+"""
+Decrement NSH TTL action
+
+This action decrements the TTL in the Network Service Header(NSH).
+
+This action was added in OVS v2.9.
+
+And equivalent to the followings action of ovs-ofctl command.
+
+::
+
+dec_nsh_ttl
+
+Example::
+
+actions += [parser.NXActionDecNshTtl()]
+"""
+_subtype = nicira_ext.NXAST_DEC_NSH_TTL
+
+_fmt_str = '!6x'
+
+def __init__(self,
+ type_=None, len_=None, vendor=None, subtype=None):
+super(NXActionDecNshTtl, self).__init__()
+
+@classmethod
+def parser(cls, buf):
+return cls()
+
+def serialize_body(self):
+data = bytearray()
+msg_pack_into(self._fmt_str, data, 0)
+return data
+
 def add_attr(k, v):
 v.__module__ = ofpp.__name__  # Necessary for stringify stuff
 setattr(ofpp, k, v)
@@ -3032,6 +3067,7 @@ def generate(ofp_name, ofpp_name):
 'NXFlowSpecMatch',
 'NXFlowSpecLoad',
 'NXFlowSpecOutput',
+'NXActionDecNshTtl',
 ]
 vars = locals()
 for name in classes:
-- 
2.7.4


--
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] example code Openflow client talking to Ryu controller

[Iwase Yusuke]

Hi Shivaram,

You mean you need to send some (stats?) message from Ryu controller to another
Ryu controller, right?

H... Ryu implements the OpenFlow parsers as "Controller side", parsers for
"from switch" messages have no "serialize()" method (some of messages have both
"serialize()" and "parser()" for unit tests though). So you need to implement
"serialize()" method on the stats "reply" message parser class to send them to
another controller.

Thanks,
Iwase


On 2018年03月08日 13:02, Shivaram Mysore wrote:

Hi,
I am looking for example Ryu API usage where Ryu framework is used to construct 
a Openflow message sent to Ryu controller.


Use case is that I just want to send say, network statistics to Ryu Openflow 
controller where I have a Ryu application that is listening to Openflow stats 
and meter messages.


Any pointers?

Thanks

/Shivaram


--
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] Too many open files

[Iwase Yusuke]

Hi,

Hmmm... I can't say further because I don't know the details of your
environment...

FYI, on my environment, my PC might reach the performance limit for such (80
switches) topology on a single machine.

$ sudo mn --controller remote --topo linear,80
...(snip)...
*** Starting controller
c0
*** Starting 80 switches
s1 s2 s3 s4 s5 s6 s7 s8 s9 s10 s11 s12 s13 s14 s15 s16 s17 s18 s19 s20 s21 s22 
s23 s24 s25 s26 s27 s28 s29 s30 s31 s32 s33 s34 s35 s36 s37 s38 s39 s40 s41 s42 
s43 s44 s45 s46 s47 s48 s49 s50 s51 s52 s53 s54 s55 s56 s57 s58 s59 s60 s61 s62 
s63 s64 s65 s66 s67 s68 s69 s70 s71 s72 s73 s74 s75 s76 s77 s78 s79 s80 ...

*** Starting CLI:
mininet>

My PC got very slow after 80 switches started up, then I guess Ryu can not
handle these switches due to the performance limit (shortage of resource) on the
same machine.

Thanks,
Iwase


On 2018??03??08?? 11:10, Zhang Yifan wrote:

Hi Iwase,

Thanks for your reminding.

My Ryu version is 4.23, and Open vSwitch on Mininet is 2.5.2.

I think the connections between Ryu and Mininet Switch often disconnected and 
sometimes it cannot reconnect.


How can I solve the problem?

Thanks,
YF


--?0?2Original?0?2--
*From: *?0?2"Iwase Yusuke";<iwase.yusu...@gmail.com>;
*Send time:*?0?2Thursday, Mar 8, 2018 8:23 AM
*To:*?0?2"Zhang Yifan"<zhang*@qq.com>;
*Cc:*?0?2"ryu-devel"<ryu-devel@lists.sourceforge.net>;
*Subject: *?0?2Re: [Ryu-devel] Too many open files

Hi,

Well, which version of Ryu (also OVS on Mininet?) are you using?

And please check whether re-connections between Ryu and your switches occur or
not. If re-connections occurs too frequently, your switches might try to
establish new connections regardless of Ryu could close socket successfully,
then Ryu unexpectedly eats up file descriptors and reaches its limit.

Thanks,
Iwase


On 2018??03??07?? 17:11, Zhang Yifan wrote:
 > Hi,
 >
 > I have modified?0?2/etc/security/limits.conf to max, but the error still 
appears.
 >
 >
 > --?0?2Original?0?2--
 >
 >
 > Hi,
 >
 > I seem the number of "file descriptors" hits the limit of its max.
 > In most case, 1024 is the max per process and "/proc/sys/fs/file-max" 
contains
 > the max of whole of OS.
 >
 > e.g.)
 > $ ulimit -n
 > 1024
 >
 > $ cat /proc/sys/fs/file-max
 > 800471
 >
 > Thanks,
 > Iwase
 >
 >
 > On 2018??03??05?? 18:33, Zhang Yifan wrote:
 >?0?2 > Hi everyone,
 >?0?2 >?0?2 ?0?2 ?0?2I have written a ryu application, it works well with 
small topology, but
 >?0?2 > when I create a topology which has 80 switches,?0?2I obtain the 
following error:
 >?0?2 >
 >?0?2 >
 >?0?2 > hub: uncaught exception: Traceback (most recent call last):
 >?0?2 >?0?2 ?0?2 File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", 
line 59, in
 > _launch
 >?0?2 >?0?2 ?0?2 File 
"/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py",
 >?0?2 > line 151, in __call__
 >?0?2 >?0?2 ?0?2 File 
"/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py",
 >?0?2 > line 188, in server_loop
 >?0?2 >?0?2 ?0?2 File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", 
line 139, in
 >?0?2 > serve_forever
 >?0?2 >?0?2 ?0?2 File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", 
line

 >?0?2 > 214, in accept
 >?0?2 >?0?2 ?0?2 File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", 
line

 >?0?2 > 56, in socket_accept
 >?0?2 >?0?2 ?0?2 File "/usr/lib/python2.7/socket.py", line 206, in accept
 >?0?2 > error: [Errno 24] Too many open files
 >?0?2 >
 >?0?2 > I want to know how I can fix the error?
 >?0?2 >
 >?0?2 > Thanks,
 >?0?2 > YF
 >?0?2 >
 >?0?2 >
 >?0?2 >
 >?0?2 > 
--
 >?0?2 > Check out the vibrant tech community on one of the world's most
 >?0?2 > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
 >?0?2 >
 >?0?2 >
 >?0?2 >
 >?0?2 > ___
 >?0?2 > Ryu-devel mailing list
 >?0?2 > Ryu-devel@lists.sourceforge.net
 >?0?2 > https://lists.sourceforge.net/lists/listinfo/ryu-devel
 >?0?2 >
 >
 >
 > 
--
 > 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/listi

Re: [Ryu-devel] About Filtering packets in packet in event and supplying real traffic

[Iwase Yusuke]

Hi,

I think it is depending on your flow entries whether Ryu gets tons of Packet-In
or not. You can write rules to filter packets by "match" and "priority" on your
flow entries.


> Q1. How can I get the packet that I have sent through a host?

For example, to compute the shortest path, how about getting only ARP packets by
Packet-In?


> Q2. Is there any way to stop  system generated control traffic?

Writing rules for forwarding to other switch or dropping waste packets reduces
the number of Packet-In for example.


> Q3. Is there any way to get topology without waiting for switch enter event?

You can call API of "ryu.topology" whenever you need the topology info, but you
need (or confirm) your all switches to be connected in order to get whole
topology. The switch enter events can be used to wait for your switches to be
connected.
https://github.com/osrg/ryu/blob/master/ryu/topology/api.py


> Q4. How can I feed real traffic to my network?

I don't know what "real traffic" does exactly mean though, if you have got
captured packets (".pcap" or so), "tcpreplay" can be used to send those packets
into your network.


Thanks,
Iwase


On 2018年03月08日 00:35, MA Moyeen wrote:

Dear Friends
I'm trying to achieve topology initially when the Ryu program runs. I can 
collect the information when switch enter event occurs with get _ switch and get 
_ links. I want to compute shortest path when I'll send my first packet to the 
destination only. But Ryu packet in generates lots of packet.

Q1. How can I get the packet that I have sent through a host?
Q2. Is there any way to stop  system generated control traffic?
Q3. Is there any way to get topology without waiting for switch enter event?
Q4. How can I feed real traffic to my network?

I'm using openflow 1.3 and mininet along with Ryu. I'm very new to Ryu and SDN 
stuff. Please help me in this regard.

Thank you all in advance for your help.
With Best Regards
M A MOYEEN
MCS student at Dalhousie University Canada

Get Outlook for Android 





--
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] Too many open files

[Iwase Yusuke]

Hi,

Well, which version of Ryu (also OVS on Mininet?) are you using?

And please check whether re-connections between Ryu and your switches occur or
not. If re-connections occurs too frequently, your switches might try to
establish new connections regardless of Ryu could close socket successfully,
then Ryu unexpectedly eats up file descriptors and reaches its limit.

Thanks,
Iwase


On 2018??03??07?? 17:11, Zhang Yifan wrote:

Hi,

I have modified?0?2/etc/security/limits.conf to max, but the error still 
appears.


--?0?2Original?0?2--


Hi,

I seem the number of "file descriptors" hits the limit of its max.
In most case, 1024 is the max per process and "/proc/sys/fs/file-max" contains
the max of whole of OS.

e.g.)
$ ulimit -n
1024

$ cat /proc/sys/fs/file-max
800471

Thanks,
Iwase


On 2018??03??05?? 18:33, Zhang Yifan wrote:
 > Hi everyone,
 >?0?2 ?0?2 ?0?2I have written a ryu application, it works well with small 
topology, but
 > when I create a topology which has 80 switches,?0?2I obtain the following 
error:
 >
 >
 > hub: uncaught exception: Traceback (most recent call last):
 >?0?2 ?0?2 File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 59, in 
_launch

 >?0?2 ?0?2 File 
"/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py",
 > line 151, in __call__
 >?0?2 ?0?2 File 
"/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py",
 > line 188, in server_loop
 >?0?2 ?0?2 File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 
139, in
 > serve_forever
 >?0?2 ?0?2 File 
"/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", line
 > 214, in accept
 >?0?2 ?0?2 File 
"/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", line
 > 56, in socket_accept
 >?0?2 ?0?2 File "/usr/lib/python2.7/socket.py", line 206, in accept
 > error: [Errno 24] Too many open files
 >
 > I want to know how I can fix the error?
 >
 > Thanks,
 > YF
 >
 >
 >
 > 
--
 > 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



--
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] New to the list

[Iwase Yusuke]

Hi Pedro,

The usage of OFPMatch is described on the Ryu Documentation.
http://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#ryu.ofproto.ofproto_v1_3_parser.OFPMatch

And which bits of "value" field should be match against value is represented by
"mask" field, but the OpenFlow Spec 1.3.5 says "mask" is not allowed for
OXM_OF_TCP_SRC/OXM_OF_TCP_DST types. Please refer to "Table 12: Header match 
fields details" on the OpenFlow Spec 1.3.5;

https://www.opennetworking.org/wp-content/uploads/2014/10/openflow-switch-v1.3.5.pdf

Thanks,
Iwase


On 2018年03月07日 03:00, Pedro Andres Aranda Gutierrez wrote:

Hi folks,

I'm new to the list but not to Ryu. I'm trying to create an OPFMatch on the last 
2 bits of the TCP source port in an OpenFlow 1.3 application. Can that be done? 
Is it documented anywhere?


Thanks a lot,
Pedro A, Aranda

--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellet zu werden
Georg Kreisler


--
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] [PATCH v2 0/5] ofproto: Encode data field on OFPErrorMsg

[IWASE Yusuke]

The v2 patches update v1 patches to avoid a socket closed immediately after
sending some messages. If a sender closes a socket immediately after sending
some data, a receiver can fail to receive full data from the sender.

>From v1 patches:
William Fisher pointed out that Ryu on Python 3 will raise exception when
failed negotiate the OpenFlow version. The following patches include the fix
for this issue.

Also, the following patches add a new option to close socket connecting to a
switch after sending a specified message.

IWASE Yusuke (5):
  controller: Improve pylint result
  controller: Option to close socket after sending Message
  controller: Wait for switch to disconnect connection
  ofp_handler: Close socket when HELLO failed
  ofproto: Encode data field on OFPErrorMsg

 ryu/controller/controller.py   | 62 +++---
 ryu/controller/ofp_handler.py  | 13 
 ryu/ofproto/ofproto_v1_0_parser.py |  2 ++
 ryu/ofproto/ofproto_v1_2_parser.py |  2 ++
 ryu/ofproto/ofproto_v1_3_parser.py |  2 ++
 ryu/ofproto/ofproto_v1_4_parser.py |  2 ++
 ryu/ofproto/ofproto_v1_5_parser.py |  2 ++
 7 files changed, 55 insertions(+), 30 deletions(-)

--
2.7.4


--
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] [PATCH v2 5/5] ofproto: Encode data field on OFPErrorMsg

[IWASE Yusuke]

Currently, when Ryu failed to negotiate the OpenFlow version with a
switch, Ryu will send the OFPT_ERROR message with an error reason on its
data field.
But on Python 3, error reason string is a str type value and required to
be encoded into a bytes type value, otherwise causes an exception when
sending the message.

This patch fixes to encode the given str value into a bytes type value
in OFPErrorMsg.__init__() and solves this problem.

Signed-off-by: William Fisher <william.w.fis...@gmail.com>
Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 ryu/controller/ofp_handler.py  | 11 ++-
 ryu/ofproto/ofproto_v1_0_parser.py |  2 ++
 ryu/ofproto/ofproto_v1_2_parser.py |  2 ++
 ryu/ofproto/ofproto_v1_3_parser.py |  2 ++
 ryu/ofproto/ofproto_v1_4_parser.py |  2 ++
 ryu/ofproto/ofproto_v1_5_parser.py |  2 ++
 6 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/ryu/controller/ofp_handler.py b/ryu/controller/ofp_handler.py
index 6ab02fe..5c4d46d 100644
--- a/ryu/controller/ofp_handler.py
+++ b/ryu/controller/ofp_handler.py
@@ -60,11 +60,12 @@ class OFPHandler(ryu.base.app_manager.RyuApp):
 return hub.spawn(self.controller)

 def _hello_failed(self, datapath, error_desc):
-self.logger.error(error_desc)
-error_msg = datapath.ofproto_parser.OFPErrorMsg(datapath)
-error_msg.type = datapath.ofproto.OFPET_HELLO_FAILED
-error_msg.code = datapath.ofproto.OFPHFC_INCOMPATIBLE
-error_msg.data = error_desc
+self.logger.error('%s on datapath %s', error_desc, datapath.address)
+error_msg = datapath.ofproto_parser.OFPErrorMsg(
+datapath=datapath,
+type_=datapath.ofproto.OFPET_HELLO_FAILED,
+code=datapath.ofproto.OFPHFC_INCOMPATIBLE,
+data=error_desc)
 datapath.send_msg(error_msg, close_socket=True)

 @set_ev_handler(ofp_event.EventOFPHello, HANDSHAKE_DISPATCHER)
diff --git a/ryu/ofproto/ofproto_v1_0_parser.py 
b/ryu/ofproto/ofproto_v1_0_parser.py
index bfc5551..a288964 100644
--- a/ryu/ofproto/ofproto_v1_0_parser.py
+++ b/ryu/ofproto/ofproto_v1_0_parser.py
@@ -1258,6 +1258,8 @@ class OFPErrorMsg(MsgBase):
 super(OFPErrorMsg, self).__init__(datapath)
 self.type = type_
 self.code = code
+if isinstance(data, six.string_types):
+data = data.encode('ascii')
 self.data = data

 @classmethod
diff --git a/ryu/ofproto/ofproto_v1_2_parser.py 
b/ryu/ofproto/ofproto_v1_2_parser.py
index 9b4dda4..244126c 100644
--- a/ryu/ofproto/ofproto_v1_2_parser.py
+++ b/ryu/ofproto/ofproto_v1_2_parser.py
@@ -141,6 +141,8 @@ class OFPErrorMsg(MsgBase):
 super(OFPErrorMsg, self).__init__(datapath)
 self.type = type_
 self.code = code
+if isinstance(data, six.string_types):
+data = data.encode('ascii')
 self.data = data
 if self.type == ofproto.OFPET_EXPERIMENTER:
 self.exp_type = kwargs.get('exp_type', None)
diff --git a/ryu/ofproto/ofproto_v1_3_parser.py 
b/ryu/ofproto/ofproto_v1_3_parser.py
index 7730aa1..0324c82 100644
--- a/ryu/ofproto/ofproto_v1_3_parser.py
+++ b/ryu/ofproto/ofproto_v1_3_parser.py
@@ -251,6 +251,8 @@ class OFPErrorMsg(MsgBase):
 super(OFPErrorMsg, self).__init__(datapath)
 self.type = type_
 self.code = code
+if isinstance(data, six.string_types):
+data = data.encode('ascii')
 self.data = data
 if self.type == ofproto.OFPET_EXPERIMENTER:
 self.exp_type = kwargs.get('exp_type', None)
diff --git a/ryu/ofproto/ofproto_v1_4_parser.py 
b/ryu/ofproto/ofproto_v1_4_parser.py
index fca35f5..470e201 100644
--- a/ryu/ofproto/ofproto_v1_4_parser.py
+++ b/ryu/ofproto/ofproto_v1_4_parser.py
@@ -262,6 +262,8 @@ class OFPErrorMsg(MsgBase):
 super(OFPErrorMsg, self).__init__(datapath)
 self.type = type_
 self.code = code
+if isinstance(data, six.string_types):
+data = data.encode('ascii')
 self.data = data
 if self.type == ofproto.OFPET_EXPERIMENTER:
 self.exp_type = kwargs.get('exp_type', None)
diff --git a/ryu/ofproto/ofproto_v1_5_parser.py 
b/ryu/ofproto/ofproto_v1_5_parser.py
index 0394662..c19a7e8 100644
--- a/ryu/ofproto/ofproto_v1_5_parser.py
+++ b/ryu/ofproto/ofproto_v1_5_parser.py
@@ -262,6 +262,8 @@ class OFPErrorMsg(MsgBase):
 super(OFPErrorMsg, self).__init__(datapath)
 self.type = type_
 self.code = code
+if isinstance(data, six.string_types):
+data = data.encode('ascii')
 self.data = data
 if self.type == ofproto.OFPET_EXPERIMENTER:
 self.exp_type = kwargs.get('exp_type', None)
--
2.7.4


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

[Ryu-devel] [PATCH v2 3/5] controller: Wait for switch to disconnect connection

[IWASE Yusuke]

If a sender closes a socket immediately after sending some data, a
receiver can fail to receive full data from the sender.

This patch fixes to shutdown a socket with "SHUT_WR" (disallows further
sends only) and enables "Datapath" to wait for a switch to disconnect
the connection.

Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 ryu/controller/controller.py | 28 ++--
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/ryu/controller/controller.py b/ryu/controller/controller.py
index f46cf00..6213533 100644
--- a/ryu/controller/controller.py
+++ b/ryu/controller/controller.py
@@ -27,7 +27,7 @@ import logging
 import random
 from socket import IPPROTO_TCP
 from socket import TCP_NODELAY
-from socket import SHUT_RDWR
+from socket import SHUT_WR
 from socket import timeout as SocketTimeout
 import ssl

@@ -196,12 +196,10 @@ def _deactivate(method):
 method(self)
 finally:
 try:
-self.socket.shutdown(SHUT_RDWR)
-except (EOFError, IOError):
+self.socket.close()
+except IOError:
 pass

-if not self.is_active:
-self.socket.close()
 return deactivate


@@ -279,14 +277,24 @@ class Datapath(ofproto_protocol.ProtocolDesc):
 self._ports = None
 self.flow_format = ofproto_v1_0.NXFF_OPENFLOW10
 self.ofp_brick = ryu.base.app_manager.lookup_service_brick('ofp_event')
+self.state = None  # for pylint
 self.set_state(HANDSHAKE_DISPATCHER)

-@_deactivate
+def _close_write(self):
+# Note: Close only further sends in order to wait for the switch to
+# disconnect this connection.
+try:
+self.socket.shutdown(SHUT_WR)
+except (EOFError, IOError):
+pass
+
 def close(self):
-if self.state != DEAD_DISPATCHER:
-self.set_state(DEAD_DISPATCHER)
+self.set_state(DEAD_DISPATCHER)
+self._close_write()

 def set_state(self, state):
+if self.state == state:
+return
 self.state = state
 ev = ofp_event.EventOFPStateChange(self)
 ev.state = state
@@ -386,8 +394,8 @@ class Datapath(ofproto_protocol.ProtocolDesc):
 self._send_q_sem.release()
 except hub.QueueEmpty:
 pass
-# Finally, ensure the _recv_loop terminates.
-self.close()
+# Finally, disallow further sends.
+self._close_write()

 def send(self, buf, close_socket=False):
 msg_enqueued = False
--
2.7.4


--
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] [PATCH v2 4/5] ofp_handler: Close socket when HELLO failed

[IWASE Yusuke]

With this patch, when failed to negotiate the OpenFlow version with a
switch, Ryu will close the socket connecting to the switch after sending
a OFPT_ERROR message.

Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 ryu/controller/ofp_handler.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ryu/controller/ofp_handler.py b/ryu/controller/ofp_handler.py
index 4f439c2..6ab02fe 100644
--- a/ryu/controller/ofp_handler.py
+++ b/ryu/controller/ofp_handler.py
@@ -65,7 +65,7 @@ class OFPHandler(ryu.base.app_manager.RyuApp):
 error_msg.type = datapath.ofproto.OFPET_HELLO_FAILED
 error_msg.code = datapath.ofproto.OFPHFC_INCOMPATIBLE
 error_msg.data = error_desc
-datapath.send_msg(error_msg)
+datapath.send_msg(error_msg, close_socket=True)

 @set_ev_handler(ofp_event.EventOFPHello, HANDSHAKE_DISPATCHER)
 def hello_handler(self, ev):
--
2.7.4


--
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] [PATCH v2 2/5] controller: Option to close socket after sending Message

[IWASE Yusuke]

Currently, Ryu does not provide the way to close a socket connecting to
a switch after sending all enqueued messages, but provides only the way
to close the socket immediately regardless of enqueued messages.

This patch adds a new option "close_socket" into "Datapath.send_msg()"
method and this option enables to close the socket after sending the
given message. This patch is convenient to close the socket after
sending OFPT_ERROR message to the switch.

Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 ryu/controller/controller.py | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/ryu/controller/controller.py b/ryu/controller/controller.py
index c0e5865..f46cf00 100644
--- a/ryu/controller/controller.py
+++ b/ryu/controller/controller.py
@@ -362,9 +362,11 @@ class Datapath(ofproto_protocol.ProtocolDesc):
 def _send_loop(self):
 try:
 while self.state != DEAD_DISPATCHER:
-buf = self.send_q.get()
+buf, close_socket = self.send_q.get()
 self._send_q_sem.release()
 self.socket.sendall(buf)
+if close_socket:
+break
 except SocketTimeout:
 LOG.debug("Socket timed out while sending data to switch at 
address %s",
   self.address)
@@ -387,11 +389,11 @@ class Datapath(ofproto_protocol.ProtocolDesc):
 # Finally, ensure the _recv_loop terminates.
 self.close()

-def send(self, buf):
+def send(self, buf, close_socket=False):
 msg_enqueued = False
 self._send_q_sem.acquire()
 if self.send_q:
-self.send_q.put(buf)
+self.send_q.put((buf, close_socket))
 msg_enqueued = True
 else:
 self._send_q_sem.release()
@@ -406,13 +408,13 @@ class Datapath(ofproto_protocol.ProtocolDesc):
 msg.set_xid(self.xid)
 return self.xid

-def send_msg(self, msg):
+def send_msg(self, msg, close_socket=False):
 assert isinstance(msg, self.ofproto_parser.MsgBase)
 if msg.xid is None:
 self.set_xid(msg)
 msg.serialize()
 # LOG.debug('send_msg %s', msg)
-return self.send(msg.buf)
+return self.send(msg.buf, close_socket=close_socket)

 def _echo_request_loop(self):
 if not self.max_unreplied_echo_requests:
--
2.7.4


--
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] topology discovery in wireless networks

[Iwase Yusuke]

rint self.mac_to_port
self.logger.info <http://self.logger.info>("packet in %s %s %s %s", dpid, src, 
dst, in_port)



         # learn a mac address to avoid FLOOD next time.
         self.mac_to_port[dpid][src] = in_port
      #   print self.mac_to_port

        #if the destination mac address is already learned, decide
        #which port to output the packet, otherwise FLOOD

         if dst in self.mac_to_port[dpid]:
             out_port = self.mac_to_port[dpid][dst]
         else:
             out_port = ofproto.OFPP_FLOOD

         actions = [parser.OFPActionOutput(out_port)]


     @set_ev_cls(event.EventSwitchEnter)
     def get_topology_data(self, ev):
         global switches
         switch_list = get_switch(self.topology_api_app, None)
         switches=[switch.dp.id <http://switch.dp.id> for switch in switch_list]
         self.datapath_list=[switch.dp for switch in switch_list]
         #print "self.datapath_list=", self.datapath_list
         print "switches=", switches

links_list = get_link(self.topology_api_app, None)
         print links_list
 
mylinks=[(link.src.dpid,link.dst.dpid,link.src.port_no,link.dst.port_no) for 
link in links_list]

     for s1,s2,port1,port2 in mylinks:
   adjacency[s1][s2]=port1
   adjacency[s2][s1]=port2
   print s1,s2,port1,port2


On Sun, Mar 4, 2018 at 9:40 PM, Iwase Yusuke <iwase.yusu...@gmail.com 
<mailto:iwase.yusu...@gmail.com>> wrote:


Hi,

When (or in which handler) do you call "get_link()" API?
Early point of starting up? For example, in your app's "__init__()" or
"switch_features_handler()", topology service could not yet discover links.
To discover all links, it will take some seconds and you need to wait for 
it.

For another approach, how about using "EventLinkAdd" or "EventLinkDelete" to
catch new links?

https://github.com/osrg/ryu/blob/8a48b62c90745e8112bb3f7277e8ac46dabb3e4e/ryu/topology/event.py#L104-L111

<https://github.com/osrg/ryu/blob/8a48b62c90745e8112bb3f7277e8ac46dabb3e4e/ryu/topology/event.py#L104-L111>

Thanks,
Iwase


On 2018年03月05日 10:24, Myra Sh wrote:

Thank you for your reply.

I added the same code. However, I only can see the list of switches and
the list of links is empty (Links between switches are wireless.)

I used the following lines to see links.

  links_list = get_link(self.topology_api_app, None)
  print links_list

Do you have any suggestion to fix the problem?

Thank you

On Thu, Mar 1, 2018 at 9:06 PM, Iwase Yusuke <iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com> <mailto:iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>>> wrote:

     Hi,

     You can enables the LLDP topology discovery feature, provided by
"ryu.topology"
     module, to discover switches (and hosts) on your topology.
https://github.com/osrg/ryu/blob/master/ryu/topology/api.py
<https://github.com/osrg/ryu/blob/master/ryu/topology/api.py>
     <https://github.com/osrg/ryu/blob/master/ryu/topology/api.py
<https://github.com/osrg/ryu/blob/master/ryu/topology/api.py>>
https://github.com/osrg/ryu/blob/master/ryu/topology/event.py
<https://github.com/osrg/ryu/blob/master/ryu/topology/event.py>
     <https://github.com/osrg/ryu/blob/master/ryu/topology/event.py
<https://github.com/osrg/ryu/blob/master/ryu/topology/event.py>>

     =
     ...(snip)...
     from ryu.topology import api as topology_api
     from ryu.topology import event as topology_event


     class MyApp(app_manager.RyuApp):

          def my_handler(self, ...):
              ...(snip)...
              switches = topology_api.get_all_switch(self)
              ...(snip)...

          @set_ev_cls(topology_event.EventSwitchEnter)
          def _switch_enter_handler(self, ev):
self.logger.info <http://self.logger.info>
<http://self.logger.info>("switch connected: %s", ev.switch)

              ...(snip)...
     =

     Please note to enable Ryu's topology discovery service, please 
specify
     "--observe-links" option to "ryu-manager".

     $ ryu-manager --help
        ...(snip)...
        --observe-links       observe link discovery events.
        ...(snip)...


     Thanks,
     Iwase


     On 2018年03月02日 05:13, Myra Sh wrote:


         Hello,

         I am new to Ryu controller. I have a wireless network wi

Re: [Ryu-devel] Too many open files

[Iwase Yusuke]

Hi,

I seem the number of "file descriptors" hits the limit of its max.
In most case, 1024 is the max per process and "/proc/sys/fs/file-max" contains
the max of whole of OS.

e.g.)
$ ulimit -n
1024

$ cat /proc/sys/fs/file-max
800471

Thanks,
Iwase


On 2018年03月05日 18:33, Zhang Yifan wrote:

Hi everyone,
    I have written a ryu application, it works well with small topology, but 
when I create a topology which has 80 switches, I obtain the following error:



hub: uncaught exception: Traceback (most recent call last):
   File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 59, in 
_launch
   File "/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", 
line 151, in __call__
   File "/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", 
line 188, in server_loop
   File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 139, in 
serve_forever
   File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 
214, in accept
   File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 
56, in socket_accept

   File "/usr/lib/python2.7/socket.py", line 206, in accept
error: [Errno 24] Too many open files

I want to know how I can fix the error?

Thanks,
YF



--
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] Multiple Controllers(REST handler) files

[Iwase Yusuke]

Hi Suresh,

Well you mean; How to reload (or swap) application file without stopping
"ryu-manager" process, right?

If so, it might require complex manner (CLI does not support it).
"ryu.base.app_manager" has some elements to archive it, and Yamamoto-San said
Ryu's VRRP service uses them;
https://www.mail-archive.com/ryu-devel@lists.sourceforge.net/msg08600.html
but... it seems to be requires to understand what "ryu-manager" does.
https://github.com/osrg/ryu/blob/8a48b62c90745e8112bb3f7277e8ac46dabb3e4e/ryu/services/protocols/vrrp/manager.py#L71-L106

FYI, dynamic loading feature was discussed before, but not merged with some
reason.
https://www.mail-archive.com/ryu-devel@lists.sourceforge.net/msg09857.html
https://www.mail-archive.com/ryu-devel@lists.sourceforge.net/msg10046.html

Thanks,
Iwase


On 2018年03月05日 14:51, knet solutions wrote:

Hi Iwase,

1)

I am writing a application in this architecture,

app.py is entrypoint (app_manager.RyuApp), and declared the API endpoints.
controller.py is API definitions and has some applications files.

I am running this application as below,
    ryu-manager app.py

Example, this application does Multiswitch functionality.  I mean, via REST API 
i can set switch1 can act as L3Switch, switch2 act as L4Switch.


I have organized each application on separate folder. I do have many such 
applications.


Now if i want to run another application(Tcpproxy), i stop this application, and 
move to tcpproxy folder, and run it.



2)  I am looking for some pluggable manner, where i can plug all my 
applications. And run as a single application.


Hope this clarifies my problem.

Thanks
Suresh


On Mon, Mar 5, 2018 at 10:58 AM, Iwase Yusuke <iwase.yusu...@gmail.com 
<mailto:iwase.yusu...@gmail.com>> wrote:


Hi,

Could you be more specific?
What "one app.py" exactly means?

You have some REST implemented applications, then ... which application do 
you
need to make multiplex?

Just I guessing... each application are running on each host and you need to
run multi controller apps(App_A) like the following?

                +---App_A+
                |            |
FlowReducer?---+---App_A+---TCPPloxy---...(Switches)
  Monitor?      |            |  (Do load balancing)
                +---App_A ---+

Or... all applications need to run on the same host?

Thanks,
Iwase


On 2018年03月05日 13:02, knet solutions wrote:


Hi,


Can we have multiple controllers in the Ryu application.

For example, i have developed few applications(Monitor, TCPProxy,
Multiswitch, FlowReducer) etc, each application has its own REST APIs.
Each application consists of app.py, controller.py(REST handler) and
application files.
All the applications are individually working  fine.

I want to  use all the application together.
To achieve this, I guess, we have to use  with multiple controllers ? 
Is it possible.

/*Thanks
*/
/*Suresh*/



--
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 <mailto:Ryu-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/ryu-devel
<https://lists.sourceforge.net/lists/listinfo/ryu-devel>




--
*/Regards,
/*
*/Knet solutions./*

https://github.com/knetsolutions/KNet
http://knet-topology-builder.readthedocs.io/
http://knetsolutions.in/



--
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] OVSDB manager

[Iwase Yusuke]

Hi Thomas,

Thanks for your reporting!

H... I also tried to implement the similar API (as following), but no bridge
instance was created...


def create_bridge(manager, system_id, bridge_name,
  bridge_info=None, port_info=None, iface_info=None,
  bridge_insert_uuid=None, port_insert_uuid=None,
  iface_insert_uuid=None):
bridge_info = bridge_info or {}
bridge_info['name'] = bridge_name
port_info = port_info or {}
port_info['name'] = bridge_name
iface_info = iface_info or {}
iface_info['name'] = bridge_name
bridge_insert_uuid = bridge_insert_uuid or uuid.uuid4()
port_insert_uuid = port_insert_uuid or uuid.uuid4()
iface_insert_uuid = iface_insert_uuid or uuid.uuid4()

def _create_bridge(tables, insert):
iface = insert(tables['Interface'], iface_insert_uuid)
iface_info.update({
'type': 'internal',
})
for key, val in iface_info.items():
setattr(iface, key, val)

port = insert(tables['Port'], port_insert_uuid)
port_info.update({
'interfaces': [iface],
'fake_bridge': False,
})
for key, val in port_info.items():
setattr(port, key, val)

bridge = insert(tables['Bridge'], bridge_insert_uuid)
bridge_info.update({
'ports': [port],
})
for key, val in bridge_info.items():
setattr(bridge, key, val)

return iface_insert_uuid, port_insert_uuid, bridge_insert_uuid

req = ovsdb_event.EventModifyRequest(system_id, _create_bridge)

return manager.send_request(req)


Does anyone know why?

I found the corresponding API "add_bridge" on "ryu.lib.ovs.vsctl", this API
works as expected, but I couldn't investigate lacks of my implementation...
https://github.com/osrg/ryu/blob/8a48b62c90745e8112bb3f7277e8ac46dabb3e4e/ryu/lib/ovs/vsctl.py#L687-L756


Thanks,
Iwase


On 2018年02月28日 23:04, Thomas Langenskiöld wrote:
In my application I need to use the OVSDB manager to spawn ports and bridges on 
OVS switches running on separate hosts. As I need to use in-band control, I need 
to use an "active manager", i.e. the OVS switch initiates the OVSDB connection 
to the manager.


It appears that the OVSDB manager library provided in Ryu is a bit incomplete. I 
can use it to add ports, but I need to add bridges as well.


I tried to implement a function similar to the add_port function to add bridges, 
but the bridges do not show up on the OVS switches. The code is included below:


from ryu.services.protocols.ovsdb import event as ovsdb_event
import uuid

def create_bridge(manager, system_id, bridge_name):
     bridge_uuid = uuid.uuid4()
     interface_uuid = uuid.uuid4()
     port_uuid = uuid.uuid4()
     def _create_bridge(tables, insert):

     bridge = insert(tables['Bridge'], bridge_uuid)
     setattr(bridge, 'name', bridge_name)

     interface = insert(tables['Interface'], interface_uuid)
     setattr(interface, 'name', bridge_name)
     setattr(interface, 'type', 'internal')

     port = insert(tables['Port'], port_uuid)
     setattr(port, 'name', bridge_name)

     port.interfaces = [interface]
     bridge.ports = [port]

     return interface_uuid, port_uuid, bridge_uuid

     req = ovsdb_event.EventModifyRequest(system_id, _create_bridge)
     return manager.send_request(req)

The result returned is as follows:

Re: [Ryu-devel] Multiple Controllers(REST handler) files

[Iwase Yusuke]

Hi,

Could you be more specific?
What "one app.py" exactly means?

You have some REST implemented applications, then ... which application do you
need to make multiplex?

Just I guessing... each application are running on each host and you need to
run multi controller apps(App_A) like the following?

   +---App_A+
   ||
FlowReducer?---+---App_A+---TCPPloxy---...(Switches)
 Monitor?  ||  (Do load balancing)
   +---App_A ---+

Or... all applications need to run on the same host?

Thanks,
Iwase


On 2018年03月05日 13:02, knet solutions wrote:


Hi,


Can we have multiple controllers in the Ryu application.

For example, i have developed few applications(Monitor, TCPProxy, Multiswitch, 
FlowReducer) etc, each application has its own REST APIs.
Each application consists of app.py, controller.py(REST handler) and application 
files.

All the applications are individually working  fine.

I want to  use all the application together.
To achieve this, I guess, we have to use  with multiple controllers ?  
Is it possible.

/*Thanks
*/
/*Suresh*/


--
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] 回复： Link discovery not working when the number ofswitches increases

[Iwase Yusuke]

Hi,

The version 3.14 was release on 2 Oct 2014 and looks NOT patched version for
this issue.

Yeah, please update your Ryu and try again.

Thanks,
Iwase


On 2018??03??05?? 12:00, Zhang Yifan wrote:

I use ryu 3.14, error info as below,

hub: uncaught exception: Traceback (most recent call last):
 ?0?2 File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 52, in 
_launch
 ?0?2 ?0?2 func(*args, **kwargs)
 ?0?2 File "/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", 
line 102, in deactivate

 ?0?2 ?0?2 method(self)
 ?0?2 File "/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", 
line 187, in _send_loop

 ?0?2 ?0?2 self.socket.sendall(buf)
 ?0?2 File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 
390, in sendall

 ?0?2 ?0?2 tail = self.send(data, flags)
 ?0?2 File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 
384, in send

 ?0?2 ?0?2 return self._send_loop(self.fd.send, data, flags)
 ?0?2 File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py", line 
371, in _send_loop

 ?0?2 ?0?2 return send_method(data, *args)
error: [Errno 32] Broken pipe

Maybe I should update ryu and try again?

------?0?2?0?2--
*??:*?0?2"Iwase Yusuke"<iwase.yusu...@gmail.com>;
*:*?0?22018??3??5??(??) 10:48
*??:*?0?2"Zhang Yifan"<zhangyifa...@qq.com>;
*:*?0?2"ryu-devel"<ryu-devel@lists.sourceforge.net>;
*:*?0?2Re: [Ryu-devel] Link discovery not working when the number ofswitches 
increases


Hi,

Which version of Ryu are you using?

The similar issue was reported before and it should be fixed on the latest.
https://www.mail-archive.com/ryu-devel@lists.sourceforge.net/msg10491.html

Thanks,
Iwase


On 2018??03??05?? 11:33, Zhang Yifan wrote:
 > Hi everybody,
 > I am testing topology discovery with Ryu in Mininet.
 > I have written an application that implements the topology discovery by
 > defining methods that listen for events EventSwitchEnter, EventSwitchLeave,
 > EventLinkAdd and EventLinkDelete.
 > While the application works fine (in other words, it correctly discovers
 > all the switches of the network and their connections) whit a low number of
 > switches (<10), when I create network topologies with a higher number of
 > switch I obtain the following error:
 >
 > hub: uncaught exception: Traceback (most recent call last):
 >?0?2?0?2?0?2 File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", 
line 53, in
 > _launch
 >?0?2?0?2?0?2?0?2?0?2 func(*args, **kwargs)
 >?0?2?0?2?0?2 File
 > "/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", line
 > 103, in deactivate
 >?0?2?0?2?0?2?0?2?0?2 method(self)
 >?0?2?0?2?0?2 File
 > "/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", line
 > 207, in _send_loop
 >?0?2?0?2?0?2?0?2?0?2 self.socket.sendall(buf)
 >?0?2?0?2?0?2 File 
"/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py",
 > line 376, in sendall
 >?0?2?0?2?0?2?0?2?0?2 tail = self.send(data, flags)
 >?0?2?0?2?0?2 File 
"/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py",
 > line 359, in send
 >?0?2?0?2?0?2?0?2?0?2 total_sent += fd.send(data[total_sent:], flags)
 > error: [Errno 32] Broken pipe
 >
 >
 > I don't understand if this error depends on my code, which I haven't posted
 > in this message because of its length but I will do if it is allowed, or it
 > depends on performance of the controller or the network emulator.
 >
 > Thanks in advance,
 >
 > YF
 >
 >
 >
 > 
--
 > 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


--
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-dev

Re: [Ryu-devel] Link discovery not working when the number of switches increases

[Iwase Yusuke]

Hi,

Which version of Ryu are you using?

The similar issue was reported before and it should be fixed on the latest.
https://www.mail-archive.com/ryu-devel@lists.sourceforge.net/msg10491.html

Thanks,
Iwase


On 2018年03月05日 11:33, Zhang Yifan wrote:

Hi everybody,
I am testing topology discovery with Ryu in Mininet.
I have written an application that implements the topology discovery by
defining methods that listen for events EventSwitchEnter, EventSwitchLeave,
EventLinkAdd and EventLinkDelete.
While the application works fine (in other words, it correctly discovers
all the switches of the network and their connections) whit a low number of
switches (<10), when I create network topologies with a higher number of
switch I obtain the following error:

hub: uncaught exception: Traceback (most recent call last):
   File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 53, in
_launch
 func(*args, **kwargs)
   File
"/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", line
103, in deactivate
 method(self)
   File
"/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", line
207, in _send_loop
 self.socket.sendall(buf)
   File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py",
line 376, in sendall
 tail = self.send(data, flags)
   File "/usr/local/lib/python2.7/dist-packages/eventlet/greenio/base.py",
line 359, in send
 total_sent += fd.send(data[total_sent:], flags)
error: [Errno 32] Broken pipe


I don't understand if this error depends on my code, which I haven't posted
in this message because of its length but I will do if it is allowed, or it
depends on performance of the controller or the network emulator.

Thanks in advance,

YF



--
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] topology discovery in wireless networks

[Iwase Yusuke]

Hi,

When (or in which handler) do you call "get_link()" API?
Early point of starting up? For example, in your app's "__init__()" or
"switch_features_handler()", topology service could not yet discover links.
To discover all links, it will take some seconds and you need to wait for it.

For another approach, how about using "EventLinkAdd" or "EventLinkDelete" to
catch new links?
https://github.com/osrg/ryu/blob/8a48b62c90745e8112bb3f7277e8ac46dabb3e4e/ryu/topology/event.py#L104-L111

Thanks,
Iwase


On 2018年03月05日 10:24, Myra Sh wrote:

Thank you for your reply.

I added the same code. However, I only can see the list of switches and the list 
of links is empty (Links between switches are wireless.)


I used the following lines to see links.

     links_list = get_link(self.topology_api_app, None)
     print links_list

Do you have any suggestion to fix the problem?

Thank you

On Thu, Mar 1, 2018 at 9:06 PM, Iwase Yusuke <iwase.yusu...@gmail.com 
<mailto:iwase.yusu...@gmail.com>> wrote:


Hi,

You can enables the LLDP topology discovery feature, provided by 
"ryu.topology"
module, to discover switches (and hosts) on your topology.
https://github.com/osrg/ryu/blob/master/ryu/topology/api.py
<https://github.com/osrg/ryu/blob/master/ryu/topology/api.py>
https://github.com/osrg/ryu/blob/master/ryu/topology/event.py
<https://github.com/osrg/ryu/blob/master/ryu/topology/event.py>

=
...(snip)...
from ryu.topology import api as topology_api
from ryu.topology import event as topology_event


class MyApp(app_manager.RyuApp):

     def my_handler(self, ...):
         ...(snip)...
         switches = topology_api.get_all_switch(self)
         ...(snip)...

     @set_ev_cls(topology_event.EventSwitchEnter)
     def _switch_enter_handler(self, ev):
self.logger.info <http://self.logger.info>("switch connected: %s", 
ev.switch)
         ...(snip)...
=

Please note to enable Ryu's topology discovery service, please specify
"--observe-links" option to "ryu-manager".

$ ryu-manager --help
   ...(snip)...
   --observe-links       observe link discovery events.
   ...(snip)...


Thanks,
Iwase


On 2018年03月02日 05:13, Myra Sh wrote:


Hello,

I am new to Ryu controller. I have a wireless network with two
openvswitch(running on wireless nodes) both of them connected to Ryu.

Could you guide me how to enable topology discovery for this
wireless network in Ryu?

Using other SDN controllers, after connecting Openvswitches to the
controller, LLDP messages are exchanged between nodes in the network. Do
I need to activate LLDP messages manually in Ryu?

Thank you



--
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 <mailto:Ryu-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/ryu-devel
<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



--
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] Fwd: Event_Link_Delete triggering

[Iwase Yusuke]

Hi Taha,

I couldn't launch your Ryu application on my environment...


(py27) $ ryu-manager shared_arp.py
loading app shared_arp.py
Traceback (most recent call last):
  File "/home/iwase/ryu/.tox/py27/bin/ryu-manager", line 11, in 
load_entry_point('ryu==4.23', 'console_scripts', 'ryu-manager')()
  File 
"/home/iwase/ryu/.tox/py27/local/lib/python2.7/site-packages/ryu/cmd/manager.py", 
line 98, in main

app_mgr.load_apps(app_lists)
  File 
"/home/iwase/ryu/.tox/py27/local/lib/python2.7/site-packages/ryu/base/app_manager.py", 
line 415, in load_apps

cls = self.load_app(app_cls_name)
  File 
"/home/iwase/ryu/.tox/py27/local/lib/python2.7/site-packages/ryu/base/app_manager.py", 
line 392, in load_app

mod = utils.import_module(name)
  File 
"/home/iwase/ryu/.tox/py27/local/lib/python2.7/site-packages/ryu/utils.py", line 
104, in import_module

return importlib.import_module(modname)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File "/home/iwase/ryu/shared_arp.py", line 171
switch_list = get_switch(self.topology_api_app, None)
^
IndentationError: unexpected indent


I tried to fix this indentation error, similar errors ware shown.
I recommend to sort out indentations. "autopep8" is very helpful!

After my fixation, I couldn't reproduce the issue you mentioned.
Ryu was running on the stable state as following.


$ ryu-manager shared_arp.py
loading app shared_arp.py
loading app ryu.topology.switches
loading app ryu.controller.ofp_handler
instantiating app None of DPSet
creating context dpset
instantiating app ryu.topology.switches of Switches
instantiating app shared_arp.py of SimpleSwitch14
instantiating app ryu.controller.ofp_handler of OFPHandler
dpid Join SW {6: }
port state change event triggered
Switch_Enter : 

Re: [Ryu-devel] adding a flow to change the destination

[Iwase Yusuke]

Hi,

You can use SET_FIELD action for such purpose.

$ git diff
diff --git a/ryu/app/simple_switch_13.py b/ryu/app/simple_switch_13.py
index 06a5d0e..4045b8c 100644
--- a/ryu/app/simple_switch_13.py
+++ b/ryu/app/simple_switch_13.py
@@ -48,6 +48,18 @@ class SimpleSwitch13(app_manager.RyuApp):
   ofproto.OFPCML_NO_BUFFER)]
 self.add_flow(datapath, 0, match, actions)

+match = parser.OFPMatch(
+in_port=1,
+eth_dst='aa:bb:cc:dd:ee:ff',
+eth_src='11:22:33:44:55:66',
+)
+actions = [
+parser.OFPActionSetField(eth_dst='aa:bb:cc:11:22:33'),
+parser.OFPActionSetField(eth_src='11:22:33:dd:ee:ff'),
+parser.OFPActionOutput(ofproto.OFPP_NORMAL),
+]
+self.add_flow(datapath, 0, match, actions)
+
 def add_flow(self, datapath, priority, match, actions, buffer_id=None):
 ofproto = datapath.ofproto
 parser = datapath.ofproto_parser


mininet> sh ovs-ofctl dump-flows s1
 cookie=0x0, duration=13.025s, table=0, n_packets=0, n_bytes=0, priority=0 
actions=CONTROLLER:65535
 cookie=0x0, duration=13.025s, table=0, n_packets=0, n_bytes=0, 
priority=0,in_port="s1-eth1",dl_src=11:22:33:44:55:66,dl_dst=aa:bb:cc:dd:ee:ff 
actions=mod_dl_dst:aa:bb:cc:11:22:33,mod_dl_src:11:22:33:dd:ee:ff,NORMAL



Thanks,
Iwase


On 2018年03月02日 07:59, S hj wrote:


Hello,

Is it possible to add a flow with the following content in an OpenvSwitch using 
Ryu? How?


if  src=x and dest=y (match part)
then:
   src=x (mac_address)
   dest=p, (mac_address)
   actions=normal


Thank you


--
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] topology discovery in wireless networks

[Iwase Yusuke]

Hi,

You can enables the LLDP topology discovery feature, provided by "ryu.topology"
module, to discover switches (and hosts) on your topology.
https://github.com/osrg/ryu/blob/master/ryu/topology/api.py
https://github.com/osrg/ryu/blob/master/ryu/topology/event.py

=
...(snip)...
from ryu.topology import api as topology_api
from ryu.topology import event as topology_event


class MyApp(app_manager.RyuApp):

def my_handler(self, ...):
...(snip)...
switches = topology_api.get_all_switch(self)
...(snip)...

@set_ev_cls(topology_event.EventSwitchEnter)
def _switch_enter_handler(self, ev):
self.logger.info("switch connected: %s", ev.switch)
...(snip)...
=

Please note to enable Ryu's topology discovery service, please specify
"--observe-links" option to "ryu-manager".

$ ryu-manager --help
  ...(snip)...
  --observe-links   observe link discovery events.
  ...(snip)...


Thanks,
Iwase

On 2018年03月02日 05:13, Myra Sh wrote:


Hello,

I am new to Ryu controller. I have a wireless network with two 
openvswitch(running on wireless nodes) both of them connected to Ryu.


Could you guide me how to enable topology discovery for this wireless network in 
Ryu?


Using other SDN controllers, after connecting Openvswitches to the controller, 
LLDP messages are exchanged between nodes in the network. Do I need to activate 
LLDP messages manually in Ryu?


Thank you


--
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] Starting up InBand Ryu controller

[Iwase Yusuke]

Hi Soliman,

I cannot answer for the contents of the Blog post you mentioned, because it is
not the official document of Ryu project and this issue seems be on Mininet
script side.

> https://techandtrains.com/2013/10/05/in-band-controller-with-mininet-part-2/
> or
> https://github.com/hmd1st/mn_test/blob/master/inband_delay_link.py

I tried this script on my machine, but OVS switches does not seem to try to
connect to Ryu's host.
How about getting contact to the creator of this script?

Thanks,
Iwase


On 2018年02月28日 20:18, Soliman Awad Alshra´a Abdullah TU Ilmenau wrote:

Thanks for your response,

On the one hand, I have no problem when I use these instructions on

http://tocai.dia.uniroma3.it/compunet-wiki/index.php/In-band_control_with_Open_vSwitch

(sudo mn --topo linear,5 --switch ovsk,inband=True 
--controller=remote,ip=10.0.0.3)

when I check the disable-in-band="true" by
sudo ovs-vsctl --columns=other_config list bridge | grep "disable-in-band"

I get nothing as it is expected, and I can run the topology well. (pingall)

On the other hand, when I use the other topologies in (for example)

https://techandtrains.com/2013/10/05/in-band-controller-with-mininet-part-2/
or
https://github.com/hmd1st/mn_test/blob/master/inband_delay_link.py

I check the disable-in-band="true"
I get  -->   other_config: {datapath-id="0001", 
disable-in-band="true"}
  and I can't do ping betwwen all hosts.

my ovs is 2.0.2 which support Of 1.0 as default  so I uses simple_switch.py as 
a controller
And as I told you, I upgraded my ovs and tried to use the suitable controller( 
simple_switch_13.py ),  but nothing happens.

I know my problem might be simple, but I have no idea why I cannot start up the 
controller well.

Thanks in advance.
A.Soliman


-Original Message-
From: Iwase Yusuke [mailto:iwase.yusu...@gmail.com]
Sent: Friday, February 23, 2018 2:30 AM
To: Soliman Awad Alshra´a Abdullah TU Ilmenau <abdullah.alsh...@tu-ilmenau.de>
Cc: ryu-devel@lists.sourceforge.net
Subject: Re: [Ryu-devel] Starting up InBand Ryu controller

Hi Soliman,

  > root@mininet-vm:~# ovs-vsctl set Bridge s1 protocol=OpenFlow13

You are using the OpenFlow version 1.3, right?
"ryu/app/simple_switch.py" supposes the OpenFlow version 1.0, then you should use 
"ryu/app/simple_switch_13.py" instead.
To confirm which version a Ryu application supports, please check "OFP_VERSIONS"
attribute on each application class.
http://osrg.github.io/ryu-book/en/html/switching_hub.html#class-definition-and-initialization

Thanks,
Iwase


On 2018年02月23日 01:43, Soliman Awad Alshra´a Abdullah TU Ilmenau wrote:

Dear Iwase,


I run the same script code topology on
https://techandtrains.com/2013/10/05/in-band-controller-with-mininet-p
art-2/

mininet@mininet-vm:~$ sudo python Inband.py
*** Configuring hosts
h1 h2 h3
*** Starting controller
c0
*** Starting 1 switches
s1 ...
*** Starting CLI:
mininet>
__
then xterm s1

root@mininet-vm:~# ovs-vsctl show
0b8ed0aa-67ac-4405-af13-70249a7e8a96
  Bridge "s1"
  Controller "tcp:10.0.0.1:6633"
  fail_mode: secure
  Port "s1-eth2"
  Interface "s1-eth2"
  Port "s1"
  Interface "s1"
  type: internal
  Port "s1-eth1"
  Interface "s1-eth1"
  Port "s1-eth3"
  Interface "s1-eth3"
  ovs_version: "2.0.2"

root@mininet-vm:~# ovs-dpctl show
system@ovs-system:
  lookups: hit:243 missed:25 lost:0
  flows: 1
  port 0: ovs-system (internal)
  port 1: s1-eth3
  port 2: s1-eth1
  port 3: s1 (internal)
  port 4: s1-eth2
root@mininet-vm:~# ovs-vsctl set Bridge s1 protocol=OpenFlow13
root@mininet-vm:~# ovs-ofctl -O OpenFlow13 dump-flows s1 OFPST_FLOW
reply (OF1.3) (xid=0x2):
__
then xterm h1

root@mininet-vm:~/ryu# PYTHONPATH=. ./bin/ryu-manager
ryu/app/simple_switch.py loading app ryu/app/simple_switch.py loading
app ryu.controller.ofp_handler instantiating app
ryu.controller.ofp_handler of OFPHandler instantiating app
ryu/app/simple_switch.py of SimpleSwitch
__
__

Fainally, I tried to pingall

mininet> pingall
*** Ping: testing ping reachability
h1 -> X X
h2 -> X X
h3 -> X X
*** Results: 100% dropped (0/6 received)
__
_


please, could you guide me to run the Ryu Inband controller ?


Best regards
A.Soliman


-Original Message-
From: Iwase Yusuke [mailto:iwase.yusu...@gmail.com]
Sent: Thursday, February 22

[Ryu-devel] [PATCH] doc: Fix unexpected indent in ofctl.api doc

[IWASE Yusuke]

Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 ryu/app/ofctl/api.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ryu/app/ofctl/api.py b/ryu/app/ofctl/api.py
index fe76b80..1149e06 100644
--- a/ryu/app/ofctl/api.py
+++ b/ryu/app/ofctl/api.py
@@ -78,11 +78,11 @@ def send_msg(app, msg, reply_cls=None, reply_multi=False):
 
 def _my_handler(self, ev):
 # ...(snip)...
-msg = parser.OFPPortDescStatsRequest(datapath=datapath)
+msg = parser.OFPPortDescStatsRequest(datapath=datapath)
 result = ofctl_api.send_msg(
 self, msg,
-reply_cls=parser.OFPPortDescStatsReply,
-reply_multi=True)
+reply_cls=parser.OFPPortDescStatsReply,
+reply_multi=True)
 """
 return app.send_request(event.SendMsgRequest(msg=msg,
  reply_cls=reply_cls,
-- 
2.7.4


--
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] [PATCH 2/3] ofp_handler: Close socket when HELLO failed

[IWASE Yusuke]

With this patch, when failed to negotiate the OpenFlow version with a
switch, Ryu will close the socket connecting to the switch after sending
a OFPT_ERROR message.

Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 ryu/controller/ofp_handler.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ryu/controller/ofp_handler.py b/ryu/controller/ofp_handler.py
index 4f439c2..6ab02fe 100644
--- a/ryu/controller/ofp_handler.py
+++ b/ryu/controller/ofp_handler.py
@@ -65,7 +65,7 @@ class OFPHandler(ryu.base.app_manager.RyuApp):
 error_msg.type = datapath.ofproto.OFPET_HELLO_FAILED
 error_msg.code = datapath.ofproto.OFPHFC_INCOMPATIBLE
 error_msg.data = error_desc
-datapath.send_msg(error_msg)
+datapath.send_msg(error_msg, close_socket=True)
 
 @set_ev_handler(ofp_event.EventOFPHello, HANDSHAKE_DISPATCHER)
 def hello_handler(self, ev):
-- 
2.7.4


--
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] [PATCH 3/3] ofproto: Encode data field on OFPErrorMsg

[IWASE Yusuke]

Currently, when Ryu failed to negotiate the OpenFlow version with a
switch, Ryu will send the OFPT_ERROR message with an error reason on its
data field.
But on Python 3, error reason string is a str type value and required to
be encoded into a bytes type value, otherwise causes an exception when
sending the message.

This patch fixes to encode the given str value into a bytes type value
in OFPErrorMsg.__init__() and solves this problem.

Signed-off-by: William Fisher <william.w.fis...@gmail.com>
Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 ryu/controller/ofp_handler.py  | 11 ++-
 ryu/ofproto/ofproto_v1_0_parser.py |  2 ++
 ryu/ofproto/ofproto_v1_2_parser.py |  2 ++
 ryu/ofproto/ofproto_v1_3_parser.py |  2 ++
 ryu/ofproto/ofproto_v1_4_parser.py |  2 ++
 ryu/ofproto/ofproto_v1_5_parser.py |  2 ++
 6 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/ryu/controller/ofp_handler.py b/ryu/controller/ofp_handler.py
index 6ab02fe..5c4d46d 100644
--- a/ryu/controller/ofp_handler.py
+++ b/ryu/controller/ofp_handler.py
@@ -60,11 +60,12 @@ class OFPHandler(ryu.base.app_manager.RyuApp):
 return hub.spawn(self.controller)
 
 def _hello_failed(self, datapath, error_desc):
-self.logger.error(error_desc)
-error_msg = datapath.ofproto_parser.OFPErrorMsg(datapath)
-error_msg.type = datapath.ofproto.OFPET_HELLO_FAILED
-error_msg.code = datapath.ofproto.OFPHFC_INCOMPATIBLE
-error_msg.data = error_desc
+self.logger.error('%s on datapath %s', error_desc, datapath.address)
+error_msg = datapath.ofproto_parser.OFPErrorMsg(
+datapath=datapath,
+type_=datapath.ofproto.OFPET_HELLO_FAILED,
+code=datapath.ofproto.OFPHFC_INCOMPATIBLE,
+data=error_desc)
 datapath.send_msg(error_msg, close_socket=True)
 
 @set_ev_handler(ofp_event.EventOFPHello, HANDSHAKE_DISPATCHER)
diff --git a/ryu/ofproto/ofproto_v1_0_parser.py 
b/ryu/ofproto/ofproto_v1_0_parser.py
index bfc5551..a288964 100644
--- a/ryu/ofproto/ofproto_v1_0_parser.py
+++ b/ryu/ofproto/ofproto_v1_0_parser.py
@@ -1258,6 +1258,8 @@ class OFPErrorMsg(MsgBase):
 super(OFPErrorMsg, self).__init__(datapath)
 self.type = type_
 self.code = code
+if isinstance(data, six.string_types):
+data = data.encode('ascii')
 self.data = data
 
 @classmethod
diff --git a/ryu/ofproto/ofproto_v1_2_parser.py 
b/ryu/ofproto/ofproto_v1_2_parser.py
index 9b4dda4..244126c 100644
--- a/ryu/ofproto/ofproto_v1_2_parser.py
+++ b/ryu/ofproto/ofproto_v1_2_parser.py
@@ -141,6 +141,8 @@ class OFPErrorMsg(MsgBase):
 super(OFPErrorMsg, self).__init__(datapath)
 self.type = type_
 self.code = code
+if isinstance(data, six.string_types):
+data = data.encode('ascii')
 self.data = data
 if self.type == ofproto.OFPET_EXPERIMENTER:
 self.exp_type = kwargs.get('exp_type', None)
diff --git a/ryu/ofproto/ofproto_v1_3_parser.py 
b/ryu/ofproto/ofproto_v1_3_parser.py
index 7730aa1..0324c82 100644
--- a/ryu/ofproto/ofproto_v1_3_parser.py
+++ b/ryu/ofproto/ofproto_v1_3_parser.py
@@ -251,6 +251,8 @@ class OFPErrorMsg(MsgBase):
 super(OFPErrorMsg, self).__init__(datapath)
 self.type = type_
 self.code = code
+if isinstance(data, six.string_types):
+data = data.encode('ascii')
 self.data = data
 if self.type == ofproto.OFPET_EXPERIMENTER:
 self.exp_type = kwargs.get('exp_type', None)
diff --git a/ryu/ofproto/ofproto_v1_4_parser.py 
b/ryu/ofproto/ofproto_v1_4_parser.py
index fca35f5..470e201 100644
--- a/ryu/ofproto/ofproto_v1_4_parser.py
+++ b/ryu/ofproto/ofproto_v1_4_parser.py
@@ -262,6 +262,8 @@ class OFPErrorMsg(MsgBase):
 super(OFPErrorMsg, self).__init__(datapath)
 self.type = type_
 self.code = code
+if isinstance(data, six.string_types):
+data = data.encode('ascii')
 self.data = data
 if self.type == ofproto.OFPET_EXPERIMENTER:
 self.exp_type = kwargs.get('exp_type', None)
diff --git a/ryu/ofproto/ofproto_v1_5_parser.py 
b/ryu/ofproto/ofproto_v1_5_parser.py
index 0394662..c19a7e8 100644
--- a/ryu/ofproto/ofproto_v1_5_parser.py
+++ b/ryu/ofproto/ofproto_v1_5_parser.py
@@ -262,6 +262,8 @@ class OFPErrorMsg(MsgBase):
 super(OFPErrorMsg, self).__init__(datapath)
 self.type = type_
 self.code = code
+if isinstance(data, six.string_types):
+data = data.encode('ascii')
 self.data = data
 if self.type == ofproto.OFPET_EXPERIMENTER:
 self.exp_type = kwargs.get('exp_type', None)
-- 
2.7.4


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

Re: [Ryu-devel] How to know the number of flows

[Iwase Yusuke]

Hi,

Excuse me for jumping in.

How about sending OFPAggregateStatsRequest in synchronous way?
You can use "ryu.app.ofctl.api" to send an OpenFlow message synchronously.
http://ryu.readthedocs.io/en/latest/app/ofctl.html


$ git diff
diff --git a/ryu/app/simple_switch_13.py b/ryu/app/simple_switch_13.py
index 06a5d0e..04c0463 100644
--- a/ryu/app/simple_switch_13.py
+++ b/ryu/app/simple_switch_13.py
@@ -21,6 +21,7 @@ from ryu.ofproto import ofproto_v1_3
 from ryu.lib.packet import packet
 from ryu.lib.packet import ethernet
 from ryu.lib.packet import ether_types
+from ryu.app.ofctl import api as ofctl_api


 class SimpleSwitch13(app_manager.RyuApp):
@@ -74,6 +75,28 @@ class SimpleSwitch13(app_manager.RyuApp):
 datapath = msg.datapath
 ofproto = datapath.ofproto
 parser = datapath.ofproto_parser
+
+flags = 0
+cookie = 0
+cookie_mask = 0
+match = parser.OFPMatch()
+req = parser.OFPAggregateStatsRequest(
+datapath=datapath,
+flags=flags,
+table_id=ofproto.OFPTT_ALL,
+out_port=ofproto.OFPP_ANY,
+out_group=ofproto.OFPG_ANY,
+cookie=cookie,
+cookie_mask=cookie_mask,
+match=match)
+rep = ofctl_api.send_msg(
+app=self,
+msg=req,
+reply_cls=parser.OFPAggregateStatsReply,
+reply_multi=True)
+if rep:
+self.logger.info("*** flow_count=%d", rep[0].body.flow_count)
+
 in_port = msg.match['in_port']

 pkt = packet.Packet(msg.data)


$ ryu-manager ryu/app/simple_switch_13.py
loading app ryu/app/simple_switch_13.py
loading app ryu.controller.ofp_handler
loading app ryu.app.ofctl.service
loading app ryu.controller.ofp_handler
instantiating app ryu/app/simple_switch_13.py of SimpleSwitch13
instantiating app ryu.controller.ofp_handler of OFPHandler
instantiating app ryu.app.ofctl.service of OfctlService
*** flow_count=1
packet in 1 2e:89:11:b9:d8:15 ff:ff:ff:ff:ff:ff 1
*** flow_count=1
packet in 1 4e:4b:8e:90:6a:f8 2e:89:11:b9:d8:15 2
*** flow_count=2
packet in 1 2e:89:11:b9:d8:15 4e:4b:8e:90:6a:f8 1


Thanks,
Iwase


On 2018年03月01日 13:07, knet solutions wrote:
The counter has to be incremented when you  add the flows add_flows(not 
packet-in) and to be decremented flow-removed event message.


On Wed, Feb 28, 2018 at 7:39 PM, ‏Eman ‏ Bany salameh > wrote:


Hi all,

Thanks for your replays.

Yes, I decrement the counter when the flow removed by idle_timeout and used
flow-removed_handler to know this. But the problem in this case is the
packet-in generated more than once for the same packet but the flow is added
once and this increments the counter more than one time for the same flow,
which is incorrect.

I can’t understand why there is multiple packet-in generated??

Regards,

Eman Bany Salameh


On Feb 28, 2018, at 2:56 PM, Vasu Dasari > wrote:


You could look for flow-removed messages from switch and use that to
adjust flows installed in your app accordingly.

In OpenFlow version >= 1.4 you could use flow monitoring as well.  This
way you can keep a check on flows in the switch.

7.3.5.19 Flow Monitoring

https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.5.0.noipr.pdf#page149



On Feb 28, 2018, at 12:49 AM, knet solutions > wrote:


If we maintain the count in SDN controller, There is a possibility of
mismatch in the count between the switch and controller .
Each flow has a timeout(idle and hard), it will be flushed out after the
timeout period.

On Wed, Feb 28, 2018 at 1:59 PM, Moh'd Reza Abbasi > wrote:

I don't think OpenFlow v.1.3 has such a feature, but how about adding
a counter in your Ryu app to keep track of added/removed rules...

On Wed, Feb 28, 2018 at 11:53 AM, ‏Eman ‏ Bany salameh via Ryu-devel
> wrote:

Hi,

I need to know the number of flows installed on the switch before
adding new one. What I did before is to request stat from the
switch then read the length of the list returned.
This way is not useful for me.
Is there any way to count them inside packet-in handler before
adding new flow? I want to limit the number of flows added to 1500.

Regards,
Eman Bany Salameh

Re: [Ryu-devel] Uncaught exception in hello_failed (Python3)

[Iwase Yusuke]

Hi Bill,


>> A little difference though, how about doing "encode" in parser classes as the
>> following? If encoding is done in parser, the differences of Python2 and
>> Python3 can be obscured against Ryu users.
>
> Yes, this change looks good to me. It makes sense to handle the ascii
> encoding in the OFPErrorMsg class.

Thanks, I've just posted patches for this issue:
[Ryu-devel] [PATCH 0/3] ofproto: Encode data field on OFPErrorMsg


>> +if close_socket:
>> +# Forces to call _deactivate()
>> +raise CloseSocketRequest
>> +except CloseSocketRequest:
>> +pass
>
> I didn't understand this part of your change. You throw a
> CloseSocketRequest exception but immediately catch it. This seems like
> the same operation as a "break" or "return" which will drop you down
> to the finally clause. I see that _deactivate is a decorator that
> calls shutdown() on the socket for wrapped methods, but I don't see
> how it can ever be called in this case. _send_loop() is not protected
> by _deactivate.

Oops, you are right. Here should do "break". Thanks a lot!
I used "break" in the above patches.


Thanks,
Iwase


On 2018年02月28日 15:46, William Fisher wrote:

Hi Iwase,

On Mon, Feb 26, 2018 at 10:55 PM, Iwase Yusuke <iwase.yusu...@gmail.com> wrote:


A little difference though, how about doing "encode" in parser classes as
the
following? If encoding is done in parser, the differences of Python2 and
Python3
can be obscured against Ryu users.


Yes, this change looks good to me. It makes sense to handle the ascii
encoding in the OFPErrorMsg class.



Also: Ryu leaves the OF connection open after responding to the hello
failed message. The connection appears to remain in the
HANDSHAKE_DISPATCHER state. What is the best way to close the
connection?


Thanks for your pointing out.
I found that Ryu does not automatically close the OF connection when the
failure
of the version negotiation, so Ryu application need to close it manually.
I think it can be often overlooked and dangerous.

What do you think about adding "close_socket" option to
"Datapath.send_msg()"
method, which will close socket after sending the given message?


The send_msg api looks okay.  I guess there is no easier way to close
and flush the connection.


+if close_socket:
+# Forces to call _deactivate()
+raise CloseSocketRequest
+except CloseSocketRequest:
+pass


I didn't understand this part of your change. You throw a
CloseSocketRequest exception but immediately catch it. This seems like
the same operation as a "break" or "return" which will drop you down
to the finally clause. I see that _deactivate is a decorator that
calls shutdown() on the socket for wrapped methods, but I don't see
how it can ever be called in this case. _send_loop() is not protected
by _deactivate.

Regards,

-Bill

--
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] [PATCH 0/3] ofproto: Encode data field on OFPErrorMsg

[IWASE Yusuke]

William Fisher pointed out that Ryu on Python 3 will raise exception when
failed negotiate the OpenFlow version. The following patches include the fix
for this issue.

Also, the following patches add a new option to close socket connecting to a
switch after sending a specified message.

IWASE Yusuke (3):
  controller: Option to close socket after sending Message
  ofp_handler: Close socket when HELLO failed
  ofproto: Encode data field on OFPErrorMsg

 ryu/controller/controller.py   | 31 ---
 ryu/controller/ofp_handler.py  | 13 +++--
 ryu/ofproto/ofproto_v1_0_parser.py |  2 ++
 ryu/ofproto/ofproto_v1_2_parser.py |  2 ++
 ryu/ofproto/ofproto_v1_3_parser.py |  2 ++
 ryu/ofproto/ofproto_v1_4_parser.py |  2 ++
 ryu/ofproto/ofproto_v1_5_parser.py |  2 ++
 7 files changed, 37 insertions(+), 17 deletions(-)

--
2.7.4


--
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] [PATCH 1/3] controller: Option to close socket after sending Message

[IWASE Yusuke]

Currently, Ryu does not provide the way to close a socket connecting to
a switch after sending all enqueued messages, but provides only the way
to close the socket immediately regardless of enqueued messages.

This patch adds a new option "close_socket" into "Datapath.send_msg()"
method and this option enables to close the socket after sending the
given message. This patch is convenient to close the socket after
sending OFPT_ERROR message to the switch.

Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 ryu/controller/controller.py | 31 ---
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/ryu/controller/controller.py b/ryu/controller/controller.py
index 8484891..03bd381 100644
--- a/ryu/controller/controller.py
+++ b/ryu/controller/controller.py
@@ -23,15 +23,19 @@ The main component of OpenFlow controller.
 """
 
 import contextlib
-from ryu import cfg
 import logging
-from ryu.lib import hub
-from ryu.lib.hub import StreamServer
 import random
+from socket import (
+IPPROTO_TCP,
+TCP_NODELAY,
+SHUT_RDWR,
+timeout as SocketTimeout,
+)
 import ssl
-from socket import IPPROTO_TCP, TCP_NODELAY, SHUT_RDWR, timeout as 
SocketTimeout
 
-import netaddr
+from ryu import cfg
+from ryu.lib import hub
+from ryu.lib.hub import StreamServer
 
 import ryu.base.app_manager
 
@@ -200,6 +204,7 @@ def _deactivate(method):
 
 if not self.is_active:
 self.socket.close()
+
 return deactivate
 
 
@@ -335,7 +340,9 @@ class Datapath(ofproto_protocol.ProtocolDesc):
 ev = ofp_event.ofp_msg_to_ev(msg)
 self.ofp_brick.send_event_to_observers(ev, self.state)
 
-dispatchers = lambda x: x.callers[ev.__class__].dispatchers
+def dispatchers(x):
+return x.callers[ev.__class__].dispatchers
+
 handlers = [handler for handler in
 self.ofp_brick.get_handlers(ev) if
 self.state in dispatchers(handler)]
@@ -358,9 +365,11 @@ class Datapath(ofproto_protocol.ProtocolDesc):
 def _send_loop(self):
 try:
 while self.state != DEAD_DISPATCHER:
-buf = self.send_q.get()
+buf, close_socket = self.send_q.get()
 self._send_q_sem.release()
 self.socket.sendall(buf)
+if close_socket:
+break
 except SocketTimeout:
 LOG.debug("Socket timed out while sending data to switch at 
address %s",
   self.address)
@@ -383,11 +392,11 @@ class Datapath(ofproto_protocol.ProtocolDesc):
 # Finally, ensure the _recv_loop terminates.
 self.close()
 
-def send(self, buf):
+def send(self, buf, close_socket=False):
 msg_enqueued = False
 self._send_q_sem.acquire()
 if self.send_q:
-self.send_q.put(buf)
+self.send_q.put((buf, close_socket))
 msg_enqueued = True
 else:
 self._send_q_sem.release()
@@ -402,13 +411,13 @@ class Datapath(ofproto_protocol.ProtocolDesc):
 msg.set_xid(self.xid)
 return self.xid
 
-def send_msg(self, msg):
+def send_msg(self, msg, close_socket=False):
 assert isinstance(msg, self.ofproto_parser.MsgBase)
 if msg.xid is None:
 self.set_xid(msg)
 msg.serialize()
 # LOG.debug('send_msg %s', msg)
-return self.send(msg.buf)
+return self.send(msg.buf, close_socket=close_socket)
 
 def _echo_request_loop(self):
 if not self.max_unreplied_echo_requests:
-- 
2.7.4


--
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] Fwd: Event_Link_Delete triggering

[Iwase Yusuke]

Hi Taha,

I couldn't investigate why, but on your attached log messages,
"EventSwitchLeave" are shown. Datapath might be disconnected for some reason,
then "EventLinkDelete" occurred.

Thanks,
Iwase

On 2018年02月28日 00:13, Taha Khan wrote:


Hi,

I added EventLinkDelete in my code. And noticed EventLinkDelete is getting 
triggered, while discovering the topology, although I am installing flow rules 
in the switch those are getting installed successfully.
I am confused why the delete event is getting triggered at the first place or 
should I ignore it.


I am sending this email second time because I received HTTP error 550 earlier.

Thanks!
Taha



--
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] pkt.get_protocol(bgp.BGPMessage) returns None

[Iwase Yusuke]

Hi Ricardo,

I guess you caught a TCP SYN (or SYN+ACK or ACK) packet leading the BGP
handshake, so the received packet has no TCP payload.

I could get the BGP packets with the following modification of simple_switch_13.


diff --git a/ryu/app/simple_switch_13.py b/ryu/app/simple_switch_13.py
index 06a5d0e..5437a7f 100644
--- a/ryu/app/simple_switch_13.py
+++ b/ryu/app/simple_switch_13.py
@@ -21,6 +21,9 @@ from ryu.ofproto import ofproto_v1_3
 from ryu.lib.packet import packet
 from ryu.lib.packet import ethernet
 from ryu.lib.packet import ether_types
+from ryu.lib.packet import ipv4
+from ryu.lib.packet import tcp
+from ryu.lib.packet import bgp


 class SimpleSwitch13(app_manager.RyuApp):
@@ -85,13 +88,26 @@ class SimpleSwitch13(app_manager.RyuApp):
 dst = eth.dst
 src = eth.src

+ipv4_pkt = pkt.get_protocol(ipv4.ipv4)
+if ipv4_pkt:
+self.logger.info("*** ipv4: %s", ipv4_pkt)
+
+tcp_pkt = pkt.get_protocol(tcp.tcp)
+if tcp_pkt:
+self.logger.info("*** tcp: %s", tcp_pkt)
+
+bgp_pkt = pkt.get_protocol(bgp.BGPMessage)
+if bgp_pkt:
+self.logger.info("*** bgp: %s", bgp_pkt)
+
 dpid = datapath.id
 self.mac_to_port.setdefault(dpid, {})

 self.logger.info("packet in %s %s %s %s", dpid, src, dst, in_port)

 # learn a mac address to avoid FLOOD next time.
-self.mac_to_port[dpid][src] = in_port
+# ---> suppress learning in order to get all packets sent from hosts.
+# self.mac_to_port[dpid][src] = in_port

 if dst in self.mac_to_port[dpid]:
 out_port = self.mac_to_port[dpid][dst]


$ ryu-manager ryu/app/simple_switch_13.py --verbose
...(snip)...
EVENT ofp_event->SimpleSwitch13 EventOFPPacketIn
*** ipv4: 
ipv4(csum=29812,dst='10.0.0.2',flags=2,header_length=5,identification=61765,offset=0,option=None,proto=6,src='10.0.0.1',tos=0,total_length=60,ttl=1,version=4)
*** tcp: 
tcp(ack=0,bits=2,csum=17646,dst_port=179,offset=10,option=[TCPOptionMaximumSegmentSize(kind=2,length=4,max_seg_size=1460), 
TCPOptionSACKPermitted(kind=4,length=2), 
TCPOptionTimestamps(kind=8,length=10,ts_ecr=0,ts_val=3591680), 
TCPOptionNoOperation(kind=1,length=1), 
TCPOptionWindowScale(kind=3,length=3,shift_cnt=9)],seq=3591782213,src_port=39095,urgent=0,window_size=29200)

packet in 1 6a:ac:ab:96:a2:cd ea:6f:1f:bf:38:3d 1
EVENT ofp_event->SimpleSwitch13 EventOFPPacketIn
*** ipv4: 
ipv4(csum=26553,dst='10.0.0.1',flags=2,header_length=5,identification=0,offset=0,option=None,proto=6,src='10.0.0.2',tos=0,total_length=60,ttl=255,version=4)
*** tcp: 
tcp(ack=3591782214,bits=18,csum=24208,dst_port=39095,offset=10,option=[TCPOptionMaximumSegmentSize(kind=2,length=4,max_seg_size=1460), 
TCPOptionSACKPermitted(kind=4,length=2), 
TCPOptionTimestamps(kind=8,length=10,ts_ecr=3591680,ts_val=3591682), 
TCPOptionNoOperation(kind=1,length=1), 
TCPOptionWindowScale(kind=3,length=3,shift_cnt=9)],seq=3896193224,src_port=179,urgent=0,window_size=28960)

packet in 1 ea:6f:1f:bf:38:3d 6a:ac:ab:96:a2:cd 2
EVENT ofp_event->SimpleSwitch13 EventOFPPacketIn
EVENT ofp_event->SimpleSwitch13 EventOFPPacketIn
*** ipv4: 
ipv4(csum=29819,dst='10.0.0.2',flags=2,header_length=5,identification=61766,offset=0,option=None,proto=6,src='10.0.0.1',tos=0,total_length=52,ttl=1,version=4)
*** tcp: 
tcp(ack=3896193225,bits=16,csum=65089,dst_port=179,offset=8,option=[TCPOptionNoOperation(kind=1,length=1), 
TCPOptionNoOperation(kind=1,length=1), 
TCPOptionTimestamps(kind=8,length=10,ts_ecr=3591682,ts_val=3591683)],seq=3591782214,src_port=39095,urgent=0,window_size=58)

packet in 1 6a:ac:ab:96:a2:cd ea:6f:1f:bf:38:3d 1
*** ipv4: 
ipv4(csum=29767,dst='10.0.0.2',flags=2,header_length=5,identification=61767,offset=0,option=None,proto=6,src='10.0.0.1',tos=0,total_length=103,ttl=1,version=4)
*** tcp: 
tcp(ack=3896193225,bits=24,csum=55108,dst_port=179,offset=8,option=[TCPOptionNoOperation(kind=1,length=1), 
TCPOptionNoOperation(kind=1,length=1), 
TCPOptionTimestamps(kind=8,length=10,ts_ecr=3591682,ts_val=3591683)],seq=3591782214,src_port=39095,urgent=0,window_size=58)
*** bgp: 
BGPOpen(bgp_identifier='1.1.1.1',hold_time=90,len=57,my_as=65001,opt_param=[BGPOptParamCapabilityRouteRefresh(cap_code=2,cap_length=0,length=2,type=2), 
BGPOptParamCapabilityMultiprotocol(afi=1,cap_code=1,cap_length=4,length=6,reserved=0,safi=1,type=2), 
BGPOptParamCapabilityMultiprotocol(afi=2,cap_code=1,cap_length=4,length=6,reserved=0,safi=1,type=2), 
BGPOptParamCapabilityFourOctetAsNumber(as_number=65001,cap_code=65,cap_length=4,length=6,type=2)],opt_param_len=28,type=1,version=4)

packet in 1 6a:ac:ab:96:a2:cd ea:6f:1f:bf:38:3d 1


Thanks,
Iwase


On 2018年02月27日 23:16, Ricardo Bennesby wrote:

Hi,

I am running ExaBGP from a Mininet node and modified the simple_switch_13 app to 
parse the BGP messages received from a peer. However, I can correctly parse the 
IP and TCP fields of the packet, while the BGP part returns *None:*


_*The code:*_
     

Re: [Ryu-devel] I have a problem with Traffic Monitor in Ryu

[Iwase Yusuke]

Hi Jade,

Just guessing, you enables IPv6 on your Mininet node? If so, IPv6 Neighbor
Discovery packets might be counted.

If you need to avoid these packets, please disable IPv6 settings on your
machine.

Thanks,
Iwase


On 2018年02月25日 01:45, Jade Manapee wrote:

Hi Everyone,

I am new to Ryu so I read the Ryubook and follow their step. But when
I run mininet and Ryu monitor it's supposed to get nothing because I
didn't send any packet in, but it does have some traffic. I also
attached the picture.

Thank,



--
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] Fwd: Facing error while trying to get the Flow Statistics using the OFPFlowStatsRequest API

[Iwase Yusuke]

Hi,

I'm using the newer version of OVS though, I guess OVS does not supports the
OpenFlow 1.5 structured FlowStats message.
the FlowStats message was restructured in the OpenFlow 1.5 according to
introduction of the FlowDesc message, but OVS does not implement the new
structure of the FlowStats (looks like up to OF version 1.4 or earlier).
https://github.com/openvswitch/ovs/blob/bd916d13dbb845746983a6780da772154df647ba/lib/ofp-util.c#L2757-L2799

Also, the FlowDesc message does not seem to be supported, implementation not
found and the Extensible Flow Entry Statistics(EXT-334) is still on TODOs which
required to implement the FlowDesc message.
https://github.com/openvswitch/ovs/blob/master/Documentation/topics/openflow.rst#openflow-15-only

OVS seems to support the OpenFlow 1.5 partially...

Thanks,
Iwase

On 2018年02月20日 18:27, shivani dommeti wrote:

Hi,

Can  you please let me know if there is any Fix for the below stated issue which 
i see when i try to retrieve the Flow statistics using OFPFlowStatsRequest API 
with OpenFlow version1.5.


Since this is blocking some features, it would be very helpful if there is any 
fix for the following. Will be looking forward for your response.


Thanks,
Shivani Dommeti.



On Thu, Feb 15, 2018 at 5:03 PM, shivani dommeti > wrote:


Hi,

Working on:
RYU version:3.27
Ovs version: 27.2
OpenFlow version:1.5.


I  tried getting the statistics of each flow using the following API:
  match = ofp_parser .OFPMatch(in_port=1)
  req = ofp_parser .OFPFlowStatsRequest(datapath,0,1,ofp.OFPP_ANY
,ofp.OFPG_ANY,0,0,match)

And i see the following error:

EVENT ofp_event->Controller EventOFPErrorMsg
EVENT ofp_event->ofctl_service EventOFPErrorMsg
EventOFPErrorMsg received.
version=0x6, msg_type=0x1, msg_len=0x4c, xid=0x6659cf
  `-- msg_type: OFPT_ERROR(1)
OFPErrorMsg(type=0x1, code=0x2,
data=b'\x06\x12\x00\x40\x00\x66\x59\xcf\x00\x11\   

x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\x00\x00\ 

  
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\ 

  
x00\x0c\x80\x00\x00\x04\x00\x00\x00\xc1\x00\x00\x00\x00\x06\x13\x10\xb0\x00\x66\x59\xd0')

  |-- type: OFPET_BAD_REQUEST(1)
  |-- code: OFPBRC_BAD_MULTIPART(2)
  `-- data: version=0x6, msg_type=0x12, msg_len=0x40, xid=0x6659cf
      `-- msg_type: OFPT_MULTIPART_REQUEST(18)
EVENT ofp_event->Controller EventOFPPortStatsReply
OFPErrorMsg received: type=0x01 code=0x02 message=0x06 0x12 0x00 0x40 0x00
0x660x59 0xcf 0x00 0x11 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x000x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x0c
0x80 0x000x00 0x04 0x00 0x00 0x00 0xc1 0x00 0x00 0x00 0x00 0x06 0x13 0x10
0xb0 0x00 0x66 0x59 0xd0
unknown error xid 6707663


i dint see this issue when i was using OpenFlow v1.3.


Please let me know if i am missing something, and what can be done to fix 
this.

Thanks,
Shivani Dommeti.



--
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] [PATCH] ofproto_v1_5: Function to disable EXT-334

[IWASE Yusuke]

Because OVS 2.9.0 does not yet support the OXS(EXT-334), in order to use
``OFPMP_FLOW_STATS``, ``OFPMP_AGGREGATE_STATS`` and
``OFPT_FLOW_REMOVED`` messages, we need to use parsers for the OpenFlow
version 1.4.

This patch adds an utility function to disable EXT-334 features and to
use the OpenFlow 1.4 parsers for these messages.

Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 ryu/ofproto/ofproto_v1_5_parser.py | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/ryu/ofproto/ofproto_v1_5_parser.py 
b/ryu/ofproto/ofproto_v1_5_parser.py
index 0394662..f635e53 100644
--- a/ryu/ofproto/ofproto_v1_5_parser.py
+++ b/ryu/ofproto/ofproto_v1_5_parser.py
@@ -59,6 +59,36 @@ def msg_parser(datapath, version, msg_type, msg_len, xid, 
buf):
 return parser(datapath, version, msg_type, msg_len, xid, buf)
 
 
+def disable_ext_334():
+"""
+Disables features related to EXT-334.
+
+Because OVS 2.9.0 does not yet support the OXS(EXT-334), in order to use
+``OFPMP_FLOW_STATS``, ``OFPMP_AGGREGATE_STATS`` and ``OFPT_FLOW_REMOVED``
+messages, we need to use parsers for the OpenFlow 1.4.
+
+After calling this function, ``OFPFlowDescStatsReply`` has the same
+structure of ``ofproto_v1_4_parser.OFPFlowStatsReply``,
+``OFPAggregateStatsReply`` and ``OFPFlowRemoved`` have the same structures
+of each corresponding parsers of ``ofproto_v1_4_parser``.
+"""
+from ryu.ofproto import ofproto_v1_4_parser
+
+# OFPMP_FLOW_DESC/OFPMP_FLOW_STATS
+# Note: OFPMP_FLOW_STATS in OpenFlow 1.4 or earlier is renamed to
+# OFPMP_FLOW_DESC in OpenFlow 1.5
+OFPFlowDescStatsReply.cls_stats_body_cls = \
+ofproto_v1_4_parser.OFPFlowStats
+
+# OFPMP_AGGREGATE_STATS
+OFPAggregateStatsReply.cls_stats_body_cls = \
+ofproto_v1_4_parser.OFPAggregateStats
+
+# OFPT_FLOW_REMOVED
+_MSG_PARSERS[OFPFlowRemoved.cls_msg_type] = \
+ofproto_v1_4_parser.OFPFlowRemoved.parser
+
+
 @_register_parser
 @_set_msg_type(ofproto.OFPT_HELLO)
 class OFPHello(MsgBase):
-- 
2.7.4


--
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] Starting up InBand Ryu controller

[Iwase Yusuke]

Hi Soliman,

> root@mininet-vm:~# ovs-vsctl set Bridge s1 protocol=OpenFlow13

You are using the OpenFlow version 1.3, right?
"ryu/app/simple_switch.py" supposes the OpenFlow version 1.0, then you should
use "ryu/app/simple_switch_13.py" instead.
To confirm which version a Ryu application supports, please check "OFP_VERSIONS"
attribute on each application class.
http://osrg.github.io/ryu-book/en/html/switching_hub.html#class-definition-and-initialization

Thanks,
Iwase


On 2018年02月23日 01:43, Soliman Awad Alshra´a Abdullah TU Ilmenau wrote:

Dear Iwase,


I run the same script code topology on  
https://techandtrains.com/2013/10/05/in-band-controller-with-mininet-part-2/

mininet@mininet-vm:~$ sudo python Inband.py
*** Configuring hosts
h1 h2 h3
*** Starting controller
c0
*** Starting 1 switches
s1 ...
*** Starting CLI:
mininet>
__
then xterm s1

root@mininet-vm:~# ovs-vsctl show
0b8ed0aa-67ac-4405-af13-70249a7e8a96
 Bridge "s1"
 Controller "tcp:10.0.0.1:6633"
 fail_mode: secure
 Port "s1-eth2"
 Interface "s1-eth2"
 Port "s1"
 Interface "s1"
 type: internal
 Port "s1-eth1"
 Interface "s1-eth1"
 Port "s1-eth3"
 Interface "s1-eth3"
 ovs_version: "2.0.2"

root@mininet-vm:~# ovs-dpctl show
system@ovs-system:
 lookups: hit:243 missed:25 lost:0
 flows: 1
 port 0: ovs-system (internal)
 port 1: s1-eth3
 port 2: s1-eth1
 port 3: s1 (internal)
 port 4: s1-eth2
root@mininet-vm:~# ovs-vsctl set Bridge s1 protocol=OpenFlow13
root@mininet-vm:~# ovs-ofctl -O OpenFlow13 dump-flows s1
OFPST_FLOW reply (OF1.3) (xid=0x2):
__
then xterm h1

root@mininet-vm:~/ryu# PYTHONPATH=. ./bin/ryu-manager ryu/app/simple_switch.py
loading app ryu/app/simple_switch.py
loading app ryu.controller.ofp_handler
instantiating app ryu.controller.ofp_handler of OFPHandler
instantiating app ryu/app/simple_switch.py of SimpleSwitch


Fainally, I tried to pingall

mininet> pingall
*** Ping: testing ping reachability
h1 -> X X
h2 -> X X
h3 -> X X
*** Results: 100% dropped (0/6 received)
_______


please, could you guide me to run the Ryu Inband controller ?


Best regards
A.Soliman


-Original Message-
From: Iwase Yusuke [mailto:iwase.yusu...@gmail.com]
Sent: Thursday, February 22, 2018 12:24 AM
To: Soliman Awad Alshra´a Abdullah TU Ilmenau <abdullah.alsh...@tu-ilmenau.de>
Cc: ryu-devel@lists.sourceforge.net
Subject: Re: [Ryu-devel] Starting up InBand Ryu controller

Hi Soliman,

The page you mentioned was written on OCTOBER 5, 2013 and the description might 
be old (e.g., the default OpenFlow version on Mininet has been changed).

Please refer to the Ryu-Book for running "Switching Hub" application.
http://osrg.github.io/ryu-book/en/html/switching_hub.html#execution-of-ryu-application

Thanks,
Iwase


On 2018年02月22日 00:15, Soliman Awad Alshra´a Abdullah TU Ilmenau wrote:

Hello all,

I am trying to use In-band controller as described here

_https://techandtrains.com/2013/10/05/in-band-controller-with-mininet-
part-2/

_when I open “ xterm h1 ” and ask controller to start up, nothing happens !!

root@mininet-vm:~# cd ryu

root@mininet-vm:~/ryu# PYTHONPATH=. ./bin/ryu-manager
ryu/app/simple_switch.py

loading app ryu/app/simple_switch.py

loading app ryu.controller.ofp_handler

instantiating app ryu.controller.ofp_handler of OFPHandler

instantiating app ryu/app/simple_switch.py of SimpleSwitc


when I instruct h1 to ping h2

mininet> h1 ping -c3 h2

PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.

  From 10.0.0.1 icmp_seq=1 Destination Host Unreachable

  From 10.0.0.1 icmp_seq=2 Destination Host Unreachable

  From 10.0.0.1 icmp_seq=3 Destination Host Unreachable

--- 10.0.0.2 ping statistics ---

3 packets transmitted, 0 received, +3 errors, 100% packet loss, time
2015ms

pipe 3

when I use  pingall

mininet> pingall

*** Ping: testing ping reachability

h1 -> X X

h2 -> X X

h3 -> X X

*** Results: 100% dropped (0/6 received)

Any advice will be highly apprenticed

Sincerely
A.Soliman



--
 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] Fwd: Facing error while trying to get the Flow Statistics using the OFPFlowStatsRequest API

[Iwase Yusuke]

Hi Shivani,

The AGGREGATE_STATS message has the same problem as what I mentioned on my
previous mail. OpenFlow 1.5 introduced "OXS" structure (EXT-334) and this
structure is also used in The AGGREGATE_STATS message, but OVS does not support
it...

FYI, I found a workaround for this issue, but please note this is a very dirty
way.

$ git diff
diff --git a/ryu/app/simple_switch_15.py b/ryu/app/simple_switch_15.py
index 6a86ba7..b04ce81 100644
--- a/ryu/app/simple_switch_15.py
+++ b/ryu/app/simple_switch_15.py
@@ -17,12 +17,27 @@ from ryu.base import app_manager
 from ryu.controller import ofp_event
 from ryu.controller.handler import CONFIG_DISPATCHER, MAIN_DISPATCHER
 from ryu.controller.handler import set_ev_cls
+from ryu.ofproto import ofproto_v1_4
+from ryu.ofproto import ofproto_v1_4_parser
 from ryu.ofproto import ofproto_v1_5
+from ryu.ofproto import ofproto_v1_5_parser
 from ryu.lib.packet import packet
 from ryu.lib.packet import ethernet
 from ryu.lib.packet import ether_types


+# HACK: OVS 2.9.0 does not yet support the EXT-334, here injects OF14 parser
+# for the workaround.
+class OFPFlowStatsReply(ofproto_v1_5_parser.OFPMultipartReply,
+ofproto_v1_4_parser.OFPFlowStatsReply):
+pass
+
+
+ofproto_v1_5_parser.OFPMultipartReply._STATS_MSG_TYPES[
+# Note: not OFPMP_FLOW_STATS(=17), use OFPMP_FLOW_DESC(=1)
+ofproto_v1_5.OFPMP_FLOW_DESC] = OFPFlowStatsReply
+
+
 class SimpleSwitch15(app_manager.RyuApp):
 OFP_VERSIONS = [ofproto_v1_5.OFP_VERSION]

@@ -48,6 +63,8 @@ class SimpleSwitch15(app_manager.RyuApp):
   ofproto.OFPCML_NO_BUFFER)]
 self.add_flow(datapath, 0, match, actions)

+self.send_flow_stats_request(datapath)
+
 def add_flow(self, datapath, priority, match, actions):
 ofproto = datapath.ofproto
 parser = datapath.ofproto_parser
@@ -59,6 +76,40 @@ class SimpleSwitch15(app_manager.RyuApp):
 match=match, instructions=inst)
 datapath.send_msg(mod)

+def send_flow_stats_request(self, datapath):
+# HACK: Use OF14 parser
+ofp = ofproto_v1_4
+ofp_parser = ofproto_v1_4_parser
+
+cookie = cookie_mask = 0
+match = ofp_parser.OFPMatch()
+req = ofp_parser.OFPFlowStatsRequest(datapath, 0,
+ ofp.OFPTT_ALL,
+ ofp.OFPP_ANY, ofp.OFPG_ANY,
+ cookie, cookie_mask,
+ match)
+datapath.send_msg(req)
+
+@set_ev_cls(ofp_event.EventOFPFlowStatsReply, MAIN_DISPATCHER)
+def flow_stats_reply_handler(self, ev):
+# HACK: Use OF14 parser
+flows = []
+for stat in ev.msg.body:
+flows.append('table_id=%s '
+ 'duration_sec=%d duration_nsec=%d '
+ 'priority=%d '
+ 'idle_timeout=%d hard_timeout=%d flags=0x%04x '
+ 'importance=%d cookie=%d packet_count=%d '
+ 'byte_count=%d match=%s instructions=%s' %
+ (stat.table_id,
+  stat.duration_sec, stat.duration_nsec,
+  stat.priority,
+  stat.idle_timeout, stat.hard_timeout,
+  stat.flags, stat.importance,
+  stat.cookie, stat.packet_count, stat.byte_count,
+  stat.match, stat.instructions))
+self.logger.debug('FlowStats: %s', flows)
+
 @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
 def _packet_in_handler(self, ev):
 msg = ev.msg


$ ryu-manager ryu/app/simple_switch_15.py --verbose
...(snip)...
EVENT ofp_event->SimpleSwitch15 EventOFPFlowStatsReply
FlowStats: ["table_id=0 duration_sec=3644 duration_nsec=5800 priority=1 
idle_timeout=0 hard_timeout=0 flags=0x importance=0 cookie=0 packet_count=9 
byte_count=826 match=OFPMatch(oxm_fields={'in_port': 2, 'eth_dst': 
'7a:12:92:fb:67:25'}) 
instructions=[OFPInstructionActions(actions=[OFPActionOutput(len=16,max_len=65509,port=1,type=0)],len=24,type=4)]", 
"table_id=0 duration_sec=3644 duration_nsec=5500 priority=1 idle_timeout=0 
hard_timeout=0 flags=0x importance=0 cookie=0 packet_count=8 byte_count=728 
match=OFPMatch(oxm_fields={'in_port': 1, 'eth_dst': '7e:76:39:e3:b8:c1'}) 
instructions=[OFPInstructionActions(actions=[OFPActionOutput(len=16,max_len=65509,port=2,type=0)],len=24,type=4)]", 
'table_id=0 duration_sec=0 duration_nsec=0 priority=0 idle_timeout=0 
hard_timeout=0 flags=0x importance=0 cookie=0 packet_count=3 byte_count=182 
match=OFPMatch(oxm_fields={}) 
instructions=[OFPInstructionActions(actions=[OFPActionOutput(len=16,max_len=65535,port=4294967293,type=0)],len=24,type=4)]']



Thanks,
Iwase


On 2018年02月23日 01:05, shivan

Re: [Ryu-devel] Starting up InBand Ryu controller

[Iwase Yusuke]

Hi Soliman,

The page you mentioned was written on OCTOBER 5, 2013 and the description might
be old (e.g., the default OpenFlow version on Mininet has been changed).

Please refer to the Ryu-Book for running "Switching Hub" application.
http://osrg.github.io/ryu-book/en/html/switching_hub.html#execution-of-ryu-application

Thanks,
Iwase


On 2018年02月22日 00:15, Soliman Awad Alshra´a Abdullah TU Ilmenau wrote:

Hello all,

I am trying to use In-band controller as described here

_https://techandtrains.com/2013/10/05/in-band-controller-with-mininet-part-2/

_when I open “ xterm h1 ” and ask controller to start up, nothing happens !!

root@mininet-vm:~# cd ryu

root@mininet-vm:~/ryu# PYTHONPATH=. ./bin/ryu-manager ryu/app/simple_switch.py

loading app ryu/app/simple_switch.py

loading app ryu.controller.ofp_handler

instantiating app ryu.controller.ofp_handler of OFPHandler

instantiating app ryu/app/simple_switch.py of SimpleSwitc


when I instruct h1 to ping h2

mininet> h1 ping -c3 h2

PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.

 From 10.0.0.1 icmp_seq=1 Destination Host Unreachable

 From 10.0.0.1 icmp_seq=2 Destination Host Unreachable

 From 10.0.0.1 icmp_seq=3 Destination Host Unreachable

--- 10.0.0.2 ping statistics ---

3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2015ms

pipe 3

when I use  pingall

mininet> pingall

*** Ping: testing ping reachability

h1 -> X X

h2 -> X X

h3 -> X X

*** Results: 100% dropped (0/6 received)

Any advice will be highly apprenticed

Sincerely
A.Soliman



--
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] [ovs-discuss] Meter Table Support in Openvswitch

[Iwase Yusuke]

Hi Suresh and Thanks Yi!

FYI, Ryu provides "OpenFlow Switch Test Tool" for testing whether your switch
support the features of OpenFlow including the Meter.
This tool is one of the built-in application of Ryu and easy to start using.
http://osrg.github.io/ryu-book/en/html/switch_test_tool.html

Thanks,
Iwase

On 2018年02月20日 13:32, Yi Tseng wrote:

[c.c. to ovs mailing list]

2018-02-18 23:10 GMT-08:00 knet solutions >:


Hi,

Does OpenVSwitch(latest release 2.8.1 + )  support Meter table?
In the release notes, its mentioned  2.7.0 onward its supported.  Is it 
correct?

Thanks
Suresh


--
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





--
Yi Tseng (a.k.a Takeshi)
Taiwan National Chiao Tung University
Department of Computer Science
W2CNLab

https://takeshi.tw


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss



--
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] Facing error while connecting to multiple switches with different OF versions

[Iwase Yusuke]

Hi,


> 1) Is the hello failed which i am seeing in ryu 4.16, have any impact on the
> functionality of the switch? (i have tried OFPportstatus request, and it seems
> to work)

Hmmm... I think it is depending on the switch implementation.
The OpenFlow Spec 1.3.5 says the recipient of OFPT_HELLO message should (must?)
terminate the connection when the version is not acceptable, but I don't know
how switches are handling them on its internal implementation.
See "6.3.3 Connection Setup" of the OpenFlow Spec 1.3.5.


> 2)What other things i would be required to handle if i were to manage DP's
> with OF version 1.3 and 1.5 concurrently on Ryu 4.xx version

Are you trying to migrate from Ryu 3.27 to 4.xx?
Well, the APIs of "ryu.ofproto" module should keep the backward compatibility,
not so much differences as far as such usage, I guess.

IIRC, for the main difference of 3.xx and 4.xx, 4.xx drops Python 2.6 support.


> 3)Also if possible i would like to know which fix related to this issue was
made onto ryu 3.xx version that is making it not fail in 4.16 version

The following two patches are the candidates;
https://github.com/osrg/ryu/commit/7b5d6bd24a59f3482c6303400049042a54335ac2
https://github.com/osrg/ryu/commit/6792d6df2a28aac436eb9e2afb1fe07bd30a1831


Thanks,
Iwase


On 2018年02月14日 02:09, rahul b wrote:

Hi,

I am using RYU version 3.27  to manage ovs and lagopus.

ovs i need to connect on OF 1.5(For support in some specific feature in groups) 
while lagopus only supports OF 1.3


so, i am declaring my ofp versions as follows

OFP_VERSIONS = [
 ofproto_v1_3.OFP_VERSION,
 ofproto_v1_5.OFP_VERSION,
 ]

OVS successfully connects on OF version 1.5, However lagopus is facing some 
issue while connecting on 1.3

connected socket: 
address:('192.168.1.4', 44517) hello ev object at 0xb642490c> move onto config mode EVENT ofp_event->Controller 
EventOFPErrorMsg Error in the datapath None from ('192.168.1.4', 44517) EVENT 
ofp_event->dpset EventOFPStateChange EVENT ofp_event->Controller 
EventOFPStateChange EVENT ofp_event->ofctl_service EventOFPStateChange hub: 
uncaught exception: Traceback (most recent call last): File 
"/usr/lib/python2.7/site-packages/ryu/lib/hub.py", line 52, in _launch 
func(*args, **kwargs) File 
"/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line 327, in 
datapath_connection_factory datapath.serve() File 
"/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line 247, in 
serve self._recv_loop() File 
"/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line 103, in 
deactivate method(self) File 
"/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line 189, in 
_recv_loop handler(ev) File 
"/usr/lib/python2.7/site-packages/ryu/controller/ofp_handler.py", line 254, in 
error_msg_handler (version, msg_type, msg_len, xid) = 
ofproto_parser.header(msg.data) File 
"/usr/lib/python2.7/site-packages/ryu/ofproto/ofproto_parser.py", line 39, in 
header assert len(buf) >= ofproto_common.OFP_HEADER_SIZE AssertionError


dumping some more info for the above error.

DUMPING BUFF IN HEADER : 0x04 0x01 0x00 0x0c 0x6e 0xc6 0xa2 0xf2
length 12 bufsize
DUMPING BUFF IN HEADER : 0x04 0x01 0x00 0x0c 0x6e 0xc6 0xa2 0xf2 0x00 0x00 0x00 
0x00
EVENT ofp_event->Controller EventOFPErrorMsg
version=0x4, msg_type=0x1, msg_len=0xc, xid=0x6ec6a2f2
length 0 bufsize
DUMPING BUFF IN HEADER :
OFPErrorMsg received: type=0x00 code=0x00 message=
Error in the datapath None from ('192.168.1.4', 59995)



However in ryu version 4.16 this is what happens.I  get a OFPET_HELL_FAILED but 
i am able to get port info etc after lagopus is connected.

connected socket: 
address:('127.0.0.1', 55388)
hello ev 
move onto config mode
EVENT ofp_event->Controller EventOFPErrorMsg
EventOFPErrorMsg received.
version=0x4, msg_type=0x1, msg_len=0xc, xid=0xfea3027
  `-- msg_type: OFPT_ERROR(1)
OFPErrorMsg(type=0x0, code=0x0, data=b'')
  |-- type: OFPET_HELLO_FAILED(0)
  |-- code: OFPHFC_INCOMPATIBLE(0)
  `-- data:
EVENT ofp_event->dpset EventOFPSwitchFeatures
EVENT ofp_event->Controller EventOFPSwitchFeatures
EVENT ofp_event->ofctl_service EventOFPSwitchFeatures
switch features ev 
version=0x4,msg_type=0x6,msg_len=0x20,xid=0xfea3028,OFPSwitchFeatures(auxiliary_id=0,capabilities=79,datapath_id=1,n_buffers=65535,n_tables=255)
OFPErrorMsg received: type=0x00 code=0x00 message=
switch feature handle called succefully
add dpid 1 datapath  
new_info  old_info None
move onto main mode
EVENT ofp_event->dpset EventOFPStateChange
EVENT ofp_event->Controller EventOFPStateChange
DPSET: register datapath 
register datapath: 0001
**lagopus dp connected






It would be really helpful , if you could tell me

1) Is the hello failed which i am seeing in ryu 4.16, have any impact on the 
functionality of the switch? (i have tried OFPportstatus request, and it seems 
to work)


2)What other things i would be required to handle if i were to manage DP's with 
OF version 1.3 and 

Re: [Ryu-devel] How to detect congestion in a network

[Iwase Yusuke]

Hi Reza,

How about getting the PortStats periodically?
This message contains "rx_dropped", "rx_errors" and so on.
http://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#ryu.ofproto.ofproto_v1_3_parser.OFPPortStatsReply

Thanks,
Iwase


On 2018年02月09日 18:42, Moh'd Reza Abbasi wrote:
I would like to know how can I infer if link or links are congested in a network 
using Ryu controller?



Thank you
Reza


--
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] Facing error while connecting to multiple switches with different OF versions

[Iwase Yusuke]

Hi,


> 1) Is the hello failed which i am seeing in ryu 4.16, have any impact on the
> functionality of the switch? (i have tried OFPportstatus request, and it seems
> to work)

Hmmm... I think it is depending on the switch implementation.
The OpenFlow Spec 1.3.5 says the recipient of OFPT_HELLO message should (must?)
terminate the connection when the version is not acceptable, but I don't know
how switches are handling them on its internal implementation.
See "6.3.3 Connection Setup" of the OpenFlow Spec 1.3.5.


> 2)What other things i would be required to handle if i were to manage DP's
> with OF version 1.3 and 1.5 concurrently on Ryu 4.xx version

Are you trying to migrate from Ryu 3.27 to 4.xx?
Well, the APIs of "ryu.ofproto" module should keep the backward compatibility,
not so much differences as far as such usage, I guess.

IIRC, for the main difference of 3.xx and 4.xx, 4.xx drops Python 2.6 support.


> 3)Also if possible i would like to know which fix related to this issue was
made onto ryu 3.xx version that is making it not fail in 4.16 version

The following two patches are the candidates;
https://github.com/osrg/ryu/commit/7b5d6bd24a59f3482c6303400049042a54335ac2
https://github.com/osrg/ryu/commit/6792d6df2a28aac436eb9e2afb1fe07bd30a1831


Thanks,
Iwase


On 2018年02月14日 02:09, rahul b wrote:

Hi,

I am using RYU version 3.27  to manage ovs and lagopus.

ovs i need to connect on OF 1.5(For support in some specific feature in groups) 
while lagopus only supports OF 1.3


so, i am declaring my ofp versions as follows

OFP_VERSIONS = [
 ofproto_v1_3.OFP_VERSION,
 ofproto_v1_5.OFP_VERSION,
 ]

OVS successfully connects on OF version 1.5, However lagopus is facing some 
issue while connecting on 1.3

connected socket: 
address:('192.168.1.4', 44517) hello ev object at 0xb642490c> move onto config mode EVENT ofp_event->Controller 
EventOFPErrorMsg Error in the datapath None from ('192.168.1.4', 44517) EVENT 
ofp_event->dpset EventOFPStateChange EVENT ofp_event->Controller 
EventOFPStateChange EVENT ofp_event->ofctl_service EventOFPStateChange hub: 
uncaught exception: Traceback (most recent call last): File 
"/usr/lib/python2.7/site-packages/ryu/lib/hub.py", line 52, in _launch 
func(*args, **kwargs) File 
"/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line 327, in 
datapath_connection_factory datapath.serve() File 
"/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line 247, in 
serve self._recv_loop() File 
"/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line 103, in 
deactivate method(self) File 
"/usr/lib/python2.7/site-packages/ryu/controller/controller.py", line 189, in 
_recv_loop handler(ev) File 
"/usr/lib/python2.7/site-packages/ryu/controller/ofp_handler.py", line 254, in 
error_msg_handler (version, msg_type, msg_len, xid) = 
ofproto_parser.header(msg.data) File 
"/usr/lib/python2.7/site-packages/ryu/ofproto/ofproto_parser.py", line 39, in 
header assert len(buf) >= ofproto_common.OFP_HEADER_SIZE AssertionError


dumping some more info for the above error.

DUMPING BUFF IN HEADER : 0x04 0x01 0x00 0x0c 0x6e 0xc6 0xa2 0xf2
length 12 bufsize
DUMPING BUFF IN HEADER : 0x04 0x01 0x00 0x0c 0x6e 0xc6 0xa2 0xf2 0x00 0x00 0x00 
0x00
EVENT ofp_event->Controller EventOFPErrorMsg
version=0x4, msg_type=0x1, msg_len=0xc, xid=0x6ec6a2f2
length 0 bufsize
DUMPING BUFF IN HEADER :
OFPErrorMsg received: type=0x00 code=0x00 message=
Error in the datapath None from ('192.168.1.4', 59995)



However in ryu version 4.16 this is what happens.I  get a OFPET_HELL_FAILED but 
i am able to get port info etc after lagopus is connected.

connected socket: 
address:('127.0.0.1', 55388)
hello ev 
move onto config mode
EVENT ofp_event->Controller EventOFPErrorMsg
EventOFPErrorMsg received.
version=0x4, msg_type=0x1, msg_len=0xc, xid=0xfea3027
  `-- msg_type: OFPT_ERROR(1)
OFPErrorMsg(type=0x0, code=0x0, data=b'')
  |-- type: OFPET_HELLO_FAILED(0)
  |-- code: OFPHFC_INCOMPATIBLE(0)
  `-- data:
EVENT ofp_event->dpset EventOFPSwitchFeatures
EVENT ofp_event->Controller EventOFPSwitchFeatures
EVENT ofp_event->ofctl_service EventOFPSwitchFeatures
switch features ev 
version=0x4,msg_type=0x6,msg_len=0x20,xid=0xfea3028,OFPSwitchFeatures(auxiliary_id=0,capabilities=79,datapath_id=1,n_buffers=65535,n_tables=255)
OFPErrorMsg received: type=0x00 code=0x00 message=
switch feature handle called succefully
add dpid 1 datapath  
new_info  old_info None
move onto main mode
EVENT ofp_event->dpset EventOFPStateChange
EVENT ofp_event->Controller EventOFPStateChange
DPSET: register datapath 
register datapath: 0001
**lagopus dp connected






It would be really helpful , if you could tell me

1) Is the hello failed which i am seeing in ryu 4.16, have any impact on the 
functionality of the switch? (i have tried OFPportstatus request, and it seems 
to work)


2)What other things i would be required to handle if i were to manage DP's with 
OF version 1.3 and 

Re: [Ryu-devel] TCP handling in controller

[Iwase Yusuke]

Hi Tomas,

Because the contained "data" in the PACKET_IN message is an Ethernet frame
message, I guess it is difficult to implement such feature...
For example, you need to open another socket on tap interface for example, then
open "data" in PACKET_IN messages -> extract TCP payload -> forward them to that
socket.

For an alternative way, how about adding another port on your switch to which
your web server connecting?

Ryu Web Sever
 |  |
 +---+  +---+
 |  |
Host A  switch  Host B

With this approach, you don't need to analyze "data" in PACKET_IN messages, just
need to install flows for Web Server-Hosts communication.

Thanks,
Iwase


On 2018年02月02日 17:52, Thomas Boros wrote:

Hello,

I’m working on my phd thesis and I need to establish a TCP connection with a 
controller. Is there anyone, who already implemented a full TCP state diagram 
in RYU to handle incoming TCP connections towards the forwarders? I’m 
implementing a minimalist web server on a forwarders, so I need to be able to 
establish a TCP connection with the controller via the forwarders using just 
only PACKET_IN and PACKET_OUT messages.

By TCP state diagram I mean the same way as the controller responds with ICMP 
or ARP messages.

Tomas
--
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] RYU Parameters

[Iwase Yusuke]

Hi,


> 1. I am able to run simple_switch_13 and ofctl_rest by the command cd ryu &&
> ./bin/ryu-manager --verbose ryu/app/simple_switch_13.py ryu/app/ofctl_rest.py.
> However I want to know whether there is any method to import ofctl_rest in
> simple_switch_13 and run *only cd ryu && ./bin/ryu-manager --verbose
> ryu/app/simple_switch_13.py* to access the REST APIs.

Hmmm... I don't know why you need to do so..., but please try the following.

$ git diff
diff --git a/ryu/app/simple_switch_13.py b/ryu/app/simple_switch_13.py
index 06a5d0e..2218bbb 100644
--- a/ryu/app/simple_switch_13.py
+++ b/ryu/app/simple_switch_13.py
@@ -22,6 +22,8 @@ from ryu.lib.packet import packet
 from ryu.lib.packet import ethernet
 from ryu.lib.packet import ether_types

+app_manager.require_app('ryu.app.ofctl_rest')
+

 class SimpleSwitch13(app_manager.RyuApp):
 OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]


> 2. I am running cd ryu && ./bin/ryu-manager --verbose
> ryu/app/simple_switch_13.py ryu/app/ofctl_rest.py ryu/app/rest_conf.py and the
> network is set on mininet with 1 switch and 3 hosts. However,* GET
> http://localhost:8080/v1.0/conf/switches *doesn't return any dpids as shown in
> the attached image. Please let me know if I am following the correct steps.**

Sorry, I don't know the details of rest_conf_switch.py.
rest_conf_switch.py provides only the REST API interface (receiver?) to
implement your own Ryu application, so you need to implement your own logic on
your application like rest_qos.py.
In other words, rest_conf_switch.py converts REST requests to events (e.g.,
EventConfSwitchSet, EventConfSwitchDel) and notify them to other applications.
https://github.com/osrg/ryu/blob/fb224e23b9b79bbebc1c500b4f51cb83bb5bd453/ryu/app/rest_qos.py#L306-L318

Currently, Ryu does not seem to have sample RESTful application for OVSDB
protocol.


Thanks,
Iwase


On 2018年02月03日 15:44, Kaustubh Shirodkar wrote:

Hi Iwase,

Thank you for your response. I have a few more queries.

1. I am able to run simple_switch_13 and ofctl_rest by the command *cd ryu && 
./bin/ryu-manager --verbose ryu/app/simple_switch_13.py ryu/app/ofctl_rest.py *. 
However I want to know whether there is any method to import ofctl_rest in 
simple_switch_13 and run *only cd ryu && ./bin/ryu-manager --verbose 
ryu/app/simple_switch_13.py* to access the REST APIs.


2. I am running *cd ryu && ./bin/ryu-manager --verbose 
ryu/app/simple_switch_13.py ryu/app/ofctl_rest.py ryu/app/rest_conf.py *and the 
network is set on mininet with 1 switch and 3 hosts. However,* GET 
http://localhost:8080/v1.0/conf/switches *doesn't return any dpids as shown in 
the attached image. Please let me know if I am following the correct steps.**


Thanks & Regards,
Kaustubh Dinesh Shirodkar


On Fri, Feb 2, 2018 at 11:07 AM, Iwase Yusuke <iwase.yusu...@gmail.com 
<mailto:iwase.yusu...@gmail.com>> wrote:


Hi,

You are talking about "ryu.app.ofctl_rest", right?
http://ryu.readthedocs.io/en/latest/app/ofctl_rest.html
<http://ryu.readthedocs.io/en/latest/app/ofctl_rest.html>

This application is an example application which provides the APIs related 
to
the OpenFlow protocol and none to other protocols.
If you mean the OVSDB protocol, I guess you need to use another application
(e.g., "ryu.app.rest_conf_switch").

Also the parameters looking for seems to be the Floodlight controller 
specific
parameters...

Thanks,
Iwase


On 2018年02月01日 22:13, Kaustubh Shirodkar wrote:

Hi Team,

I am currently working on RYU REST APIs and have come at a standstill
regarding the response received from them. I am facing the following 
issues:

1. Is there any API by which I can extract the following parameters
related to the OVS Switch:
   a. 'connectedSince'
   b. 'inetAddress'
   c. 'systemUptimeMsec
   d. Switch Health Status e.g. "healthy":true

2. Also I need to know any device related API which would give me
'lastSeen' time of the device connected to any port.

3. I am using POSTMAN to verify the implementation of these APIs. When I
insert a flow for Floodlight Controller, I receive a JSON response for
"PUT" and "DELETE" methods. Is there any similar response received from
RYU controller?

Thanks & Regards,
Kaustubh Dinesh Shirodkar


<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>> 
  Virus-free. www.avast.com <http://www.avast.com>


<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-ema

[Ryu-devel] [PATCH 0/2] doc: Document for ryu.lib.ovs

[IWASE Yusuke]

Because the usage of "ryu.lib.ovs" is frequently asked at the Ryu-devel mailing
list, the following patches adds the document for this library.

FYI, the document page would be like:
  http://ryu-iwase.readthedocs.io/en/doc-lib-ovs/library_ovsdb.html

IWASE Yusuke (2):
  lib/ovs: Fix a typo of "--may-exist" option
  doc: Document for ryu.lib.ovs

 doc/source/library.rst   |   1 +
 doc/source/library_ovsdb.rst |  76 
 ryu/lib/ovs/bridge.py| 134 ++-
 ryu/lib/ovs/vsctl.py |  65 +++--
 4 files changed, 270 insertions(+), 6 deletions(-)
 create mode 100644 doc/source/library_ovsdb.rst

--
2.7.4


--
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] [PATCH 1/2] lib/ovs: Fix a typo of "--may-exist" option

[IWASE Yusuke]

Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 ryu/lib/ovs/vsctl.py | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/ryu/lib/ovs/vsctl.py b/ryu/lib/ovs/vsctl.py
index 2391c90..b18b5ef 100644
--- a/ryu/lib/ovs/vsctl.py
+++ b/ryu/lib/ovs/vsctl.py
@@ -1563,7 +1563,9 @@ class VSCtl(object):
 self._pre_add_port(ctx, columns)
 
 def _cmd_add_port(self, ctx, command):
-may_exist = command.has_option('--may_exist')
+# '--may_exist' is a typo but for backword compatibility
+may_exist = (command.has_option('--may_exist')
+ or command.has_option('--may-exist'))
 
 br_name = command.args[0]
 port_name = command.args[1]
@@ -1577,7 +1579,9 @@ class VSCtl(object):
  False, iface_names, settings)
 
 def _cmd_add_bond(self, ctx, command):
-may_exist = command.has_option('--may_exist')
+# '--may_exist' is a typo but for backword compatibility
+may_exist = (command.has_option('--may_exist')
+ or command.has_option('--may-exist'))
 fake_iface = command.has_option('--fake-iface')
 
 br_name = command.args[0]
-- 
2.7.4


--
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] [PATCH 2/2] doc: Document for ryu.lib.ovs

[IWASE Yusuke]

Signed-off-by: IWASE Yusuke <iwase.yusu...@gmail.com>
---
 doc/source/library.rst   |   1 +
 doc/source/library_ovsdb.rst |  76 
 ryu/lib/ovs/bridge.py| 134 ++-
 ryu/lib/ovs/vsctl.py |  57 +-
 4 files changed, 264 insertions(+), 4 deletions(-)
 create mode 100644 doc/source/library_ovsdb.rst

diff --git a/doc/source/library.rst b/doc/source/library.rst
index ff28041..cdaed76 100644
--- a/doc/source/library.rst
+++ b/doc/source/library.rst
@@ -15,3 +15,4 @@ Ryu provides some useful library for your network 
applications.
library_bgp_speaker_ref.rst
library_mrt.rst
library_ovsdb_manager.rst
+   library_ovsdb.rst
diff --git a/doc/source/library_ovsdb.rst b/doc/source/library_ovsdb.rst
new file mode 100644
index 000..df7d170
--- /dev/null
+++ b/doc/source/library_ovsdb.rst
@@ -0,0 +1,76 @@
+*
+OVSDB library
+*
+
+Path: ``ryu.lib.ovs``
+
+Similar to the :doc:`library_ovsdb_manager`, this library enables your
+application to speak the OVSDB protocol (RFC7047_), but differ from the
+:doc:`library_ovsdb_manager`, this library will initiate connections from
+controller side as ovs-vsctl_ command does.
+Please make sure that your devices are listening on either the Unix domain
+socket or TCP/SSL port before calling the APIs of this library.
+
+.. code-block:: bash
+
+# Show current configuration
+$ ovs-vsctl get-manager
+
+# Set TCP listen address
+$ ovs-vsctl set-manager "ptcp:6640"
+
+See manpage of ovs-vsctl_ command for more details.
+
+.. _RFC7047: https://tools.ietf.org/html/rfc7047
+.. _ovs-vsctl: http://openvswitch.org/support/dist-docs/ovs-vsctl.8.txt
+
+Basic Usage
+===
+
+1. Instantiate :py:mod:`ryu.lib.ovs.vsctl.VSCtl`.
+
+2. Construct commands with :py:mod:`ryu.lib.ovs.vsctl.VSCtlCommand`.
+   The syntax is almost the same as ovs-vsctl_ command.
+
+3. Execute commands via :py:mod:`ryu.lib.ovs.vsctl.VSCtl.run_command`.
+
+Example
+---
+
+.. code-block:: python
+
+from ryu.lib.ovs import vsctl
+
+OVSDB_ADDR = 'tcp:127.0.0.1:6640'
+ovs_vsctl = vsctl.VSCtl(OVSDB_ADDR)
+
+# Equivalent to
+# $ ovs-vsctl show
+command = vsctl.VSCtlCommand('show')
+ovs_vsctl.run_command([command])
+print(command)
+# >>> 
VSCtlCommand(args=[],command='show',options=[],result='830d781f-c3c8-4b4f-837e-106e1b33d058\n
ovs_version: "2.8.90"\n')
+
+# Equivalent to
+# $ ovs-vsctl list Port s1-eth1
+command = vsctl.VSCtlCommand('list', ('Port', 's1-eth1'))
+ovs_vsctl.run_command([command])
+print(command)
+# >>> VSCtlCommand(args=('Port', 
's1-eth1'),command='list',options=[],result=[])
+print(command.result[0].name)
+# >>> s1-eth1
+
+API Reference
+=
+
+ryu.lib.ovs.vsctl
+-
+
+.. automodule:: ryu.lib.ovs.vsctl
+:members:
+
+ryu.lib.ovs.bridge
+--
+
+.. automodule:: ryu.lib.ovs.bridge
+:members:
diff --git a/ryu/lib/ovs/bridge.py b/ryu/lib/ovs/bridge.py
index e48052f..9753fa2 100644
--- a/ryu/lib/ovs/bridge.py
+++ b/ryu/lib/ovs/bridge.py
@@ -15,7 +15,7 @@
 # limitations under the License.
 
 """
-slimmed down version of OVSBridge in quantum agent
+Wrapper utility library of :py:mod:`ryu.lib.ovs.vsctl`
 """
 
 import functools
@@ -92,6 +92,26 @@ class TunnelPort(object):
 
 
 class OVSBridge(object):
+"""
+Class to provide wrapper utilities of :py:mod:`ryu.lib.ovs.vsctl.VSCtl`
+
+``CONF`` is a instance of ``oslo_config.cfg.ConfigOpts``.
+Mostly ``self.CONF`` is sufficient to instantiate this class from your Ryu
+application.
+
+``datapath_id`` specifies Datapath ID of the target OVS instance.
+
+``ovsdb_addr`` specifies the address of the OVS instance.
+Automatically validated when you call ``init()`` method.
+Refer to :py:mod:`ryu.lib.ovs.vsctl.valid_ovsdb_addr` for the format of
+this address.
+
+if ``timeout`` is omitted, ``CONF.ovsdb_timeout`` will be used as the
+default value.
+
+Usage of ``timeout`` and ``exception`` is the same with ``timeout_sec``
+and ``exception`` of :py:mod:`ryu.lib.ovs.vsctl.VSCtl.run_command`.
+"""
 
 def __init__(self, CONF, datapath_id, ovsdb_addr, timeout=None,
  exception=None):
@@ -105,9 +125,25 @@ class OVSBridge(object):
 self.br_name = None
 
 def run_command(self, commands):
+"""
+Executes the given commands and sends OVSDB messages.
+
+``commands`` must be a list of
+:py:mod:`ryu.lib.ovs.vsctl.VSCtlCommand`.
+
+The given ``timeout`` and ``exception`` when instantiation will be used
+to call :py:mod:`ryu.lib.ovs.vsctl.VSCtl.run_command`.
+"""
 self.vsctl.run_command(commands, self.timeout, self.exception)
 
   

Re: [Ryu-devel] How to include Netmask in Flow table

[Iwase Yusuke]

Hi,
The following document is helpful for you?
http://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#ryu.ofproto.ofproto_v1_3_parser.OFPMatch

For example, to match the destination IPv4 network "192.168.122.0/24":
match = parser.OFPMatch(
eth_type=0x0800,
ipv4_dst=("192.168.122.0", "255.255.255.0"))

Thanks,
Iwase


On 2018年02月02日 11:14, knet solutions wrote:

Hi

I require support for adding the network(with subnetmask) in the flow table. I 
find the example of specific destination_ip match only.


My requirement is something like,

match: destination,network 192.168.122.0/24  --- 
outport:2

openflow1.3 specification says, this can be achieved via wildcard fields.

Any example programs available ?

--
*/Regards,
/*
*/Suresh Kumar
/*
*/Knet solutions./*

https://github.com/knetsolutions/KNet
http://knet-topology-builder.readthedocs.io/
http://knetsolutions.in/



--
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] RYU Parameters

[Iwase Yusuke]

Hi,

You are talking about "ryu.app.ofctl_rest", right?
http://ryu.readthedocs.io/en/latest/app/ofctl_rest.html

This application is an example application which provides the APIs related to
the OpenFlow protocol and none to other protocols.
If you mean the OVSDB protocol, I guess you need to use another application
(e.g., "ryu.app.rest_conf_switch").

Also the parameters looking for seems to be the Floodlight controller specific
parameters...

Thanks,
Iwase


On 2018年02月01日 22:13, Kaustubh Shirodkar wrote:

Hi Team,

I am currently working on RYU REST APIs and have come at a standstill regarding 
the response received from them. I am facing the following issues:


1. Is there any API by which I can extract the following parameters related to 
the OVS Switch:

  a. 'connectedSince'
  b. 'inetAddress'
  c. 'systemUptimeMsec
  d. Switch Health Status e.g. "healthy":true

2. Also I need to know any device related API which would give me 'lastSeen' 
time of the device connected to any port.


3. I am using POSTMAN to verify the implementation of these APIs. When I insert 
a flow for Floodlight Controller, I receive a JSON response for "PUT" and 
"DELETE" methods. Is there any similar response received from RYU controller?


Thanks & Regards,
Kaustubh Dinesh Shirodkar

 
	Virus-free. www.avast.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


--
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