As you directed me not to miss table-miss entry, i used it, now ITS WORKING
PERFECTLY, handoff is performing at its best , with 3 packets loss in
mininet, now the problem is, BUT FOR DEPLOYING THIS CODE ON WU MESH, i
heard that HARD_TIMEOUT does not work on WU mesh test bed, so what i think
is to use "OFPFC_DELETE or OFPFC_DELETE_STRICT " can we make controller to
delete flows by itself, instead of using HARD_TIMEOUT, if that can be
done, how to use OFPFC_DELETE? IS THERE A WAY FOR THAT?
Thanks a lot
On Tue, Apr 25, 2017 at 7:00 PM, Yi Tseng <a86487...@gmail.com> wrote:
> Hi,
>
> Because you removed table-miss flow entry, so the switch will not send any
> packet-in message to the controller.
>
>
> --Yi
>
> 2017-04-25 16:38 GMT-07:00 varun hrithik <varunlikitha1...@gmail.com>:
>
>> Based on what you insisted me, i used idletimeout to delete flows, but my
>> controller is not receiving my packetIn message automatically, when station
>> moves to different AP, I am including my controller code, Let me know if i
>> need add a loop to direct the packetIn message to controller or am i
>> missing with some logic in my code?
>>
>> # Copyright (C) 2011 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.
>>
>> 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_3
>> from ryu.lib.packet import packet
>> from ryu.lib.packet import ethernet
>>
>>
>> class SimpleSwitch13(app_manager.RyuApp):
>> OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]
>>
>> def __init__(self, *args, **kwargs):
>> super(SimpleSwitch13, self).__init__(*args, **kwargs)
>> self.mac_to_port = {}
>>
>> @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
>> def switch_features_handler(self, ev):
>> datapath = ev.msg.datapath
>> ofproto = datapath.ofproto
>> parser = datapath.ofproto_parser
>>
>> # install table-miss flow entry
>> #
>> # We specify NO BUFFER to max_len of the output action due to
>> # OVS bug. At this moment, if we specify a lesser number, e.g.,
>> # 128, OVS will send Packet-In with invalid buffer_id and
>> # truncated packet data. In that case, we cannot output packets
>> # correctly. The bug has been fixed in OVS v2.1.0.
>> match = parser.OFPMatch()
>> actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
>> ofproto.OFPCML_NO_BUFFER)]
>> 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
>>
>> inst = [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS,
>> actions)]
>> if buffer_id:
>> mod = parser.OFPFlowMod(datapath=datapath, buffer_id=buffer_id,
>> idle_timeout=50,
>> priority=priority, match=match,
>> instructions=inst)
>> else:
>> mod = parser.OFPFlowMod(datapath=datapath, idle_timeout=50,
>> priority=priority,
>> match=match, instructions=inst)
>> datapath.send_msg(mod)
>>
>> def del_flow(self, datapath, match):
>> ofproto = datapath.ofproto
>>
>> mod = datapath.ofproto_parser.OFPFlowMod(datapath=datapath,
>> match=match, cookie=0,
>> command=ofproto.OFPFC_DELETE, idle_timeout=0, hard_timeout=0,
>> priority=priority)
>> datapath.send_msg(mod)
>> """
>> def add_flow1(self, datapath, priority, match, actions,
>> buffer_id=buffer_id):
>> ofproto = datapath.ofproto
>> parser = datapath.ofproto_parser
>>
>> inst = [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS,
>> actions)]
>> if buffer_id:
>> mod = parser.OFPFlowMod(datapath=datapath, buffer_id=buffer_id,
>> idle_timeout=50,
>> priority=2000, match=match,
>> instructions=inst)
>> else:
>> mod = parser.OFPFlowMod(datapath=datapath, idle_timeout=50,
>> priority=2000,
>> match=match, instructions=inst)
>> datapath.send_msg(mod)
>> """
>> @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
>> def _packet_in_handler(self, ev):
>> # If you hit this you might want to increase
>> # the "miss_send_length" of your switch
>> if ev.msg.msg_len < ev.msg.total_len:
>> self.logger.debug("packet truncated: only %s of %s bytes",
>> ev.msg.msg_len, ev.msg.total_len)
>> msg = ev.msg
>> datapath = msg.datapath
>> ofproto = datapath.ofproto
>> parser = datapath.ofproto_parser
>> in_port = msg.match['in_port']
>>
>> pkt = packet.Packet(msg.data)
>> eth = pkt.get_protocols(ethernet.ethernet)[0]
>>
>> dst = eth.dst
>> src = eth.src
>>
>> 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
>>
>> 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)]
>>
>> # install a flow to avoid packet_in next time
>> if out_port != ofproto.OFPP_FLOOD:
>> match = parser.OFPMatch(in_port=in_port, eth_dst=dst)
>> # verify if we have a valid buffer_id, if yes avoid to send both
>> # flow_mod & packet_out
>> if msg.buffer_id != ofproto.OFP_NO_BUFFER:
>> #self.del_flow(datapath, match)
>> self.add_flow(datapath, 1, match, actions, msg.buffer_id)
>> return
>> else:
>> self.del_flow(datapath, match)
>> self.add_flow(datapath, 2, match, actions, msg.buffer_id)
>> data = None
>> if msg.buffer_id == ofproto.OFP_NO_BUFFER:
>> data = msg.data
>>
>> out = parser.OFPPacketOut(datapath=datapath, buffer_id=msg.buffer_id,
>> in_port=in_port, actions=actions,
>> data=data)
>> datapath.send_msg(out)
>>
>>
>> On Mon, Apr 24, 2017 at 1:10 PM, Yi Tseng <a86487...@gmail.com> wrote:
>>
>>> Hi
>>>
>>>
>>>
>>> *Please don't drop mailing list*
>>> If flows had been removed, the controller should received PacketIn
>>> message again, the simple switch application should install new flow into
>>> the switch.
>>>
>>> --
>>> Yi
>>>
>>> 2017-04-24 11:03 GMT-07:00 varun hrithik <varunlikitha1...@gmail.com>:
>>>
>>>> yeah, removing flows is fine, i want t know how those flows can be
>>>> added to the new ap, such that when a station is in between two APs( i.e,
>>>> if the station are connected to two APs at the same time) , new AP should
>>>> be able to connect wid station, so that new flows are created.
>>>>
>>>> On Mon, Apr 24, 2017 at 12:47 PM, Yi Tseng <a86487...@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I think the easiest way is to set idle timeout for every flow, if any
>>>>> host move to another device(AP), the original flow will be removed.
>>>>>
>>>>> --
>>>>> Yi
>>>>>
>>>>> 2017-04-24 9:00 GMT-07:00 varun hrithik <varunlikitha1...@gmail.com>:
>>>>>
>>>>>> I have created a topolgy which has 5 stations moving around 5 access
>>>>>> points using mininet-wifi (tool) extension of mininet which allows GUI
>>>>>> format of wireless network simualtion.
>>>>>> Now im trying to handle mobility of those moving stations using ryu
>>>>>> controller example code (simple_switch_13.py),
>>>>>>
>>>>>> NOW THE PROBLEM IS,
>>>>>>
>>>>>> When the stations are inbetween two accespoints which have access
>>>>>> range overlapped, the packets are not getting transferred from one ap to
>>>>>> another (mobility is not working), so i want to know how to add and
>>>>>> delete
>>>>>> flows in the ryu controller code(simple_switch_13.py), so that my
>>>>>> mobility
>>>>>> works.
>>>>>>
>>>>>> SORRY FOR THE BIG QUESTION !
>>>>>>
>>>>>> Thank you
>>>>>> Varun Siripurapu
>>>>>>
>>>>>> ------------------------------------------------------------
>>>>>> ------------------
>>>>>> 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
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Yi Tseng (a.k.a Takeshi)
>>> Taiwan National Chiao Tung University
>>> Department of Computer Science
>>> W2CNLab
>>>
>>> https://takeshi.tw
>>>
>>
>>
>
>
> --
> Yi Tseng (a.k.a Takeshi)
> Taiwan National Chiao Tung University
> Department of Computer Science
> W2CNLab
>
> https://takeshi.tw
>
------------------------------------------------------------------------------
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
