Hi,
To process the packet using the flow entries,
you need to output the packet to "OFPP_TABLE" port.
For just forwarding (Not mirroring), please refer to the following.
$ git diff
diff --git a/ryu/app/simple_switch_13.py b/ryu/app/simple_switch_13.py
index 3e7c598..9d3741c 100644
--- a/ryu/app/simple_switch_13.py
+++ b/ryu/app/simple_switch_13.py
@@ -48,6 +48,11 @@ class SimpleSwitch13(app_manager.RyuApp):
ofproto.OFPCML_NO_BUFFER)]
self.add_flow(datapath, 0, match, actions)
+ match = parser.OFPMatch(in_port=ofproto.OFPP_CONTROLLER)
+ mirror_port = 3
+ actions = [parser.OFPActionOutput(mirror_port)]
+ 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
@@ -114,6 +119,8 @@ class SimpleSwitch13(app_manager.RyuApp):
if msg.buffer_id == ofproto.OFP_NO_BUFFER:
data = msg.data
+ in_port = ofproto.OFPP_CONTROLLER
+ actions = [parser.OFPActionOutput(ofproto.OFPP_TABLE)]
out = parser.OFPPacketOut(datapath=datapath, buffer_id=msg.buffer_id,
in_port=in_port, actions=actions, data=data)
datapath.send_msg(out)
If you want to do mirroring, it is more complex.
Because you need to install the flows:
-one is to forward packets without mirroring
- one is to do mirroring + forwarding.
And, you need to switch these flows by 'in_port' match field.
With the fixed topology, it might be more simple,
but it is still difficult to calculate the flows, I think.
To capture the packet at controller-switch link is not suitable for your
purpose?
I think filtering the packet by Wireshark is more easy way.
Thanks,
Iwase
On 2016年05月27日 19:22, Maurizio Marrocco wrote:
> Hi,
> I tried to mirror PacketOut msg to port 3 and it's OK
> But I don't know how identify this packet from controller to switch.
> I tried to install flow when match the field inPort=ofproto.OFPP_CONTROLLER,
> but don't work
> Here the piece of code:
> """Mirror all control traffic, from control port to output 3 - don't work """
> match3 = parser.OFPMatch(in_port=ofproto.OFPP_CONTROLLER)
>
> actions3 =[parser.OFPActionOutput(3)]
> self.add_flow(datapath,1, match3, actions3)
> also because with dpctl I see the flow table and this entry was matched with
> in_port=-3 Value.
>
> Furthermore, I tried group action for mirroring, but don't works because from
> OFv1.3 spec:
> "Set-Field actions for OXM types OFPXMT_OFB_IN_PORT,
> OXM_OF_IN_PHY_PORT and OFPXMT_OFB_METADATA are not supported, because those
> are not header fields."
> in fact, with wireshark I have ad error: OFBAC_BAD_SET_TYPE (i.e. unsupported
> type in SET_FIELD ACTION)
> Any other ideas?
> I really need for my thesis to instruct my RYU program to said:
> if(receive OFPT_PACKET_OUT)
> mirror(port 3)
>
> Another thing: if run TCPDUMP to h3, i don't see the OPENFLOW packet right?
> because OPENFLOW protocol is specified only for controller-switch
> communication
> Thanks for helps.
>
>
> ________________________________________
> Da: Iwase Yusuke <[email protected]>
> Inviato: giovedì 26 maggio 2016 05.53
> A: [email protected]
> Cc: [email protected]
> Oggetto: Re: [Ryu-devel] How I can identify a packet from the Ryu-controller
> to OpenFlow v1.3 switch?
>
> Hi,
>
> You want to do the port mirroring only the packets sent by packet_out
> messages, right?
> I think there are some way to do this.
> For example, please refer to the following snippet.
> I added a output action in to packet_out message (not into flow_mod messages).
>
> $ git diff
> diff --git a/ryu/app/simple_switch_13.py b/ryu/app/simple_switch_13.py
> index 3e7c598..55ff4e7 100644
> --- a/ryu/app/simple_switch_13.py
> +++ b/ryu/app/simple_switch_13.py
> @@ -114,6 +114,10 @@ class SimpleSwitch13(app_manager.RyuApp):
> if msg.buffer_id == ofproto.OFP_NO_BUFFER:
> data = msg.data
>
> + # add output action for port mirroring
> + mirror_port = 3
> + actions.append(parser.OFPActionOutput(port=mirror_port))
> +
> out = parser.OFPPacketOut(datapath=datapath,
> buffer_id=msg.buffer_id,
> in_port=in_port, actions=actions,
> data=data)
> datapath.send_msg(out)
>
>
> If you want to identify the packets from the controller at the switches,
> this might be more complex, I think.
> Maybe you need to install the specific flows for
> in_port=ofproto.OFPP_CONTROLLER packets
> or to use group actions for mirroring.
>
> Thanks,
> Iwase
>
>
> On 2016年05月25日 20:44, Maurizio Marrocco wrote:
>> Hi, I try with in_port=ofproto.OFPP_CONTROLLER in PktOut msg but don't work.
>> In other words, how can Mirror all control traffic (pkt_out messages), from
>> controller to port output 3?
>> How can match this?
>> I post the source with attachment to this email.
>>
>>
>> ________________________________________
>> Da: Iwase Yusuke <[email protected]>
>> Inviato: mercoledì 25 maggio 2016 03.37
>> A: [email protected]
>> Cc: [email protected]
>> Oggetto: Re: [Ryu-devel] How I can identify a packet from the Ryu-controller
>> to OpenFlow v1.3 switch?
>>
>> Hi,
>>
>> On 2016年05月25日 02:39, Maurizio Marrocco wrote:
>>> Hi to everyone,
>>>
>>> I need an help for my thesis,
>>>
>>> I want to identify a control packet from Python RYU-controller. In other
>>> words: How I can to do the following instruction?
>>>
>>> |If(I receive a OFPT_PACKET_OUT msg fromryu-controller)dosomething
>>> (forexample all control traffic from controller must mirroring to an output
>>> port)|
>>>
>>> and How can I match this rule?
>>>
>>> I saw in OpenFlow v1.3 specification that there is a
>>> ofproto.OFPP_CONTROLLER reserved port: How can I use it as an ingress port?
>>>
>>> >From OFv1.3 spec.: "OFPP_CONTROLLER: Represents the control channel
>>> with the OpenFlow controller. Can be used as an ingress port or as an
>>> output port.
>>>
>>> When used as an output port, encapsulate the packet in a packet-in message
>>> and send it using the OpenFlow protocol.
>>>
>>> When used as an ingress port, identify a packet originating from the
>>> controller."
>>
>> How about setting "in_port=ofp.OFPP_CONTROLLER" in OFPPacketOut message?
>>
>> http://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#ryu.ofproto.ofproto_v1_3_parser.OFPPacketOut
>>
>> Thanks,
>> Iwase
>>
>>>
>>> Thanks for the help.
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Mobile security can be enabling, not merely restricting. Employees who
>>> bring their own devices (BYOD) to work are irked by the imposition of MDM
>>> restrictions. Mobile Device Manager Plus allows you to control only the
>>> apps on BYO-devices by containerizing them, leaving personal data untouched!
>>> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
>>>
>>>
>>>
>>> _______________________________________________
>>> Ryu-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Mobile security can be enabling, not merely restricting. Employees who
>> bring their own devices (BYOD) to work are irked by the imposition of MDM
>> restrictions. Mobile Device Manager Plus allows you to control only the
>> apps on BYO-devices by containerizing them, leaving personal data untouched!
>> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
>>
>>
>>
>> _______________________________________________
>> Ryu-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
>
>
>
> _______________________________________________
> Ryu-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Ryu-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ryu-devel