Re: [Ryu-devel] Problems when a BGP speaker is being shutdown

[Fujimoto Satoshi]

Hi,

I just sent the patch for your issue:

subject: [PATCH] bgp/peer: Don't stop BGPProtocol instance which already 
stops

Currently, when a connection is lost, BGP Speaker tries to
stop BGPProtocol instance, even if it already stops.
This commit fixes this by checking the status of BGPProtocol
instance before trying to stop it.

Signed-off-by: Satoshi Fujimoto
---
  ryu/services/protocols/bgp/peer.py | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ryu/services/protocols/bgp/peer.py 
b/ryu/services/protocols/bgp/peer.py
index 70b486c..1e26bfd 100644
--- a/ryu/services/protocols/bgp/peer.py
+++ b/ryu/services/protocols/bgp/peer.py
@@ -2325,7 +2325,8 @@ class Peer(Source, Sink, NeighborConfListener, Activity):
  )
  self.state.bgp_state = const.BGP_FSM_IDLE
  if self._protocol:
-self._protocol.stop()
+if self._protocol._started:
+self._protocol.stop()
  self._protocol = None
  # Create new collection for initial RT NLRIs
  self._init_rtc_nlri_path = []
-- 2.7.4

Could you try this?

Thanks,
Fujimoto

On 2018年03月23日 10:03, Fujimoto Satoshi wrote:

Hi,
Sorry for delay.

I reproduced the situation.
The cause may be that the disconnection is incomplete
when the speaker is being shutdown while the connection is existing.

Let me investigate this problem.
In the meantime, please delete all peers before shutting down.

Thanks,
Fujimoto

On 2018年03月14日 00:58, Jens Harbott wrote:

These issues were found while I was testing the
neutron-dynamic-routing service in OpenStack, see
https://bugs.launchpad.net/neutron/+bug/1750383 and
https://bugs.launchpad.net/neutron/+bug/1750129

But using a modified version of the sample program shown at
http://ryu.readthedocs.io/en/latest/library_bgp_speaker.html I can
reproduce them with only ryu:


---<--->---<--->---snip---<--->---<--->---snap---<--->---<--->---
import eventlet

# BGPSpeaker needs sockets patched
eventlet.monkey_patch()

# initialize a log handler
# this is not strictly necessary but useful if you get messages like:
#    No handlers could be found for logger "ryu.lib.hub"
import logging
import sys
log = logging.getLogger()
log.addHandler(logging.StreamHandler(sys.stderr))

from ryu.services.protocols.bgp.bgpspeaker import BGPSpeaker

def dump_remote_best_path_change(event):
 print ('the best path changed:', event.remote_as, event.prefix,\
 event.nexthop, event.is_withdraw)

def detect_peer_down(remote_ip, remote_as):
 print ('Peer down:', remote_ip, remote_as)

if __name__ == "__main__":
 speaker = BGPSpeaker(as_number=65001, router_id='10.0.0.1',
bgp_server_port=0,
best_path_change_handler=dump_remote_best_path_change,
  peer_down_handler=detect_peer_down)

 speaker.neighbor_add('10.42.0.4', 65001)
 print ("BGP started")
 count = 1
 while True:
 eventlet.sleep(10)
 prefix = '10.20.' + str(count) + '.0/24'
 print ("add a new prefix", prefix)
 speaker.prefix_add(prefix)
 count += 1
 if count == 3:
 break

 # eventlet.sleep(10)
 # print ("Remove neighbor")
 # speaker.neighbor_del('10.42.0.4')
 eventlet.sleep(10)
 print ("Shutting down")
 speaker.shutdown()
 eventlet.sleep(300)
---<--->---<--->---snip---<--->---<--->---snap---<--->---<--->---

The result differs depending on whether there is actually a BGP peer
listening at the remote end, leading to the scenarios described in the
two bugs above. When the BGP session is connected at the time of the
shutdown, these tracebacks are being shown repeatedly:

hub: uncaught exception: Traceback (most recent call last):
   File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line
80, in _launch
 return func(*args, **kwargs)
   File 
"/usr/local/lib/python2.7/dist-packages/ryu/services/protocols/bgp/utils/evtlet.py",

line 63, in __call__
 self._funct(*self._args, **self._kwargs)
   File 
"/usr/local/lib/python2.7/dist-packages/ryu/services/protocols/bgp/speaker.py",

line 542, in _expired
 self.send_notification(code, subcode)
   File 
"/usr/local/lib/python2.7/dist-packages/ryu/services/protocols/bgp/speaker.py",

line 374, in send_notification
 self._send_with_lock(notification)
   File 
"/usr/local/lib/python2.7/dist-packages/ryu/services/protocols/bgp/speaker.py",

line 386, in _send_with_lock
 self.connection_lost('failed to write to socket')
   File 
"/usr/local/lib/python2.7/dist-packages/ryu/services/protocols/bgp/speaker.py",

line 596, in connection_lost
 self._peer.connection_lost(reason)
   File 
"/usr/local/lib/python2.7/dist-packages/ryu/services/protocols/bgp/peer.py",

line 2328, in connection_lost
 self._protocol.stop()
   File 
"/usr/local/lib/python2.7/dist-packages/ryu/services/protocols/bgp/speaker.py",

line 405, in stop
 Activity.stop(self)
   File 

[Ryu-devel] [PATCH] bgp/peer: Don't stop BGPProtocol instance which already stops

[Satoshi Fujimoto]

Currently, when a connection is lost, BGP Speaker tries to
stop BGPProtocol instance, even if it already stops.
This commit fixes this by checking the status of BGPProtocol
instance before trying to stop it.

Signed-off-by: Satoshi Fujimoto 
---
 ryu/services/protocols/bgp/peer.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ryu/services/protocols/bgp/peer.py 
b/ryu/services/protocols/bgp/peer.py
index 70b486c..1e26bfd 100644
--- a/ryu/services/protocols/bgp/peer.py
+++ b/ryu/services/protocols/bgp/peer.py
@@ -2325,7 +2325,8 @@ class Peer(Source, Sink, NeighborConfListener, Activity):
 )
 self.state.bgp_state = const.BGP_FSM_IDLE
 if self._protocol:
-self._protocol.stop()
+if self._protocol._started:
+self._protocol.stop()
 self._protocol = None
 # Create new collection for initial RT NLRIs
 self._init_rtc_nlri_path = []
-- 
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] 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 >:


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

     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 

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

[Jose Carlos Ferreira de Melo Junior]

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 :

> 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>>:
>>
>> 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 >  > >>:
>>
>>  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,re
>> f_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日 

[Ryu-devel] Ryu with mininet wifi

[nadia mouawad]

Good morning,

I newly started to learn Ryu and I am trying to integrate it with
mininet-wifi.

This is my topology:
def topology():
"Create a network."
net = Mininet_wifi( controller=RemoteController,
accessPoint=OVSKernelAP)
print "*** Creating nodes"

sta1 = net.addStation( 'sta1', mac='00:00:00:00:00:02', ip='10.0.0.2/8',
position='40,40,0' )
sta2 = net.addStation( 'sta2', mac='00:00:00:00:00:03', ip='10.0.0.3/8',
position='40,50,0')

ap1 = net.addAccessPoint( 'ap1', ssid= 'new-ssid1', dpid='1', mode=
'g', channel= '5', position='25,50,0' , range = 120,
mac='00:00:00:00:00:04')
ap2 = net.addAccessPoint( 'ap2', ssid= 'new-ssid2', dpid='2', mode=
'g', channel= '5', position='50,100,0' , range = 120 ,
mac='00:00:00:00:00:05')
c0 = net.addController( 'c0' , controller = RemoteController,
ip='192.168.110.187')


When I try to run gui_topology.py or shortestpath,py  I get the following
(repeatable) output:

DPSET: Multiple connections from 0001
Multiple connections from 0001

However, I  can not see the topology or the links.

Can you help me with this ?

Regards,
Nadia
--
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] About Gathering Delay information

[IWAMOTO Toshihiro]

On Sat, 31 Mar 2018 10:16:44 +0900,
MA Moyeen wrote:
> I'm interested to gather end to end delay and flow insertion
> time. Packets will follow a backup path if the first path is
> broken. how to measure the delay between point of failure and
> destination? is it wise to use monitoring of delay as a separate Ryu
> application or I have to calculate manually within my learning
> switch application?  Thanks a lot for all of your great works and
> help. Thanks in advance for helping me by answering these questions.

You can write whatever you like, but IMO adding time.time() calls and
calculation in your switch app is the simplest approach.

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