[ovs-discuss] Flow Monitoring

Vasu Dasari vdasari at gmail.com
Wed May 22 20:31:27 UTC 2019


Hi Ben,

I see that from nicer-ext.h:

struct nx_flow_monitor_request {
    ovs_be32 id;                /* Controller-assigned ID for this monitor.
*/
    ovs_be16 flags;             /* NXFMF_*. */
    ovs_be16 out_port;          /* Required output port, if not OFPP_NONE.
*/
    ovs_be16 match_len;         /* Length of nx_match. */
    uint8_t table_id;           /* One table's ID or 0xff for all tables. */
    uint8_t zeros[5];           /* Align to 64 bits (must be zero). */
    /* Followed by:
     *   - Exactly match_len (possibly 0) bytes containing the nx_match,
then
     *   - Exactly (match_len + 7)/8*8 - match_len (between 0 and 7) bytes
of
     *     all-zero bytes. */
};

But, the data populated by controller is in the following sequence:

        monitor_id: 32,
        out_port: 16,
        out_group: 16,
        monitor_flags: 16,
        table_id: 8,
        command: 8,
        match_and_padding

The place where the flags is being extracted
ofputil_decode_flow_monitor_request(),
I see that flags is extracted first. This could be an issue.

I have't tried out my assumption yet. Does it make sense??

Could this be a software bug?

Thanks,
-Vasu

*Vasu Dasari*


On Wed, May 22, 2019 at 1:30 PM Vasu Dasari <vdasari at gmail.com> wrote:

> Here is the data:
>
> Request:
> 0000   02 42 ac 18 00 02 02 42 c7 b9 8f ef 08 00 45 00  .B.....B......E.
> 0010   00 50 22 94 00 00 25 06 c5 4f c0 a8 41 02 ac 18  .P"...%..O..A...
> 0020   00 02 19 fe d4 22 1a fe f8 dd a4 5c 18 1d 50 18  .....".....\..P.
> 0030   ff ff 57 23 00 00 05 12 00 28 00 00 00 00 00 10  ..W#.....(......
> 0040   00 00 00 00 00 00 05 f5 e1 00 00 00 00 00 ff ff  ................
> 0050   ff ff 00 01 00 00 00 01 00 04 00 00 00 00        ..............
>
> Response:
> 0000   02 42 c7 b9 8f ef 02 42 ac 18 00 02 08 00 45 c0  .B.....B......E.
> 0010   00 5c 57 db 40 00 40 06 34 3c ac 18 00 02 c0 a8  .\W. at .@.4<......
> 0020   41 02 d4 22 19 fe a4 5c 18 1d 1a fe f9 05 50 18  A.."...\......P.
> 0030   04 b0 ae 13 00 00 05 01 00 34 00 00 00 00 00 10  .........4......
> 0040   00 05 05 12 00 28 00 00 00 00 00 10 00 00 00 00  .....(..........
> 0050   00 00 05 f5 e1 00 00 00 00 00 ff ff ff ff 00 01  ................
> 0060   00 00 00 01 00 04 00 00 00 00                    ..........
>
> Also attaching pcap file.
>
> Thanks
> -Vasu
>
> *Vasu Dasari*
>
>
> On Wed, May 22, 2019 at 12:45 PM Ben Pfaff <blp at ovn.org> wrote:
>
>> On Wed, May 22, 2019 at 10:31:13AM -0400, Vasu Dasari wrote:
>> > Hi,
>> >
>> > I am trying to perform flow monitoring from my controller. Constructed
>> the
>> > packet as follows:
>> >
>> > OpenFlow 1.4
>> >     Version: 1.4 (0x05)
>> >     Type: OFPT_MULTIPART_REQUEST (18)
>> >     Length: 40
>> >     Transaction ID: 0
>> >     Type: OFPMP_FLOW_MONITOR (16)
>> >     Flags: 0x0000
>> >         .... .... .... ...0 = OFPMPF_REQ_MORE: 0x0
>> >     Pad: 00000000
>> >     Monitor ID: 100000000
>> >     Out port: 0
>> >     Out group: OFPG_ANY (0xffffffff)
>> >     Flags: 0x000f
>> >         .... .... .... ...1 = OFPFMF_INITIAL: 0x1
>> >         .... .... .... ..1. = OFPFMF_ADD: 0x1
>> >         .... .... .... .1.. = OFPFMF_REMOVED: 0x1
>> >         .... .... .... 1... = OFPFMF_MODIFY: 0x1
>> >         .... .... ...0 .... = OFPFMF_INSTRUCTIONS: 0x0
>> >         .... .... ..0. .... = OFPFMF_NO_ABBREV: 0x0
>> >         .... .... .0.. .... = OFPFMF_ONLY_OWN: 0x0
>> >     Table ID: 0
>> >     Command: OFPFMC_ADD (0)
>> >     Match
>> >         Type: OFPMT_OXM (1)
>> >         Length: 4
>> >         Pad: 00000000
>>
>> Would you please provide a hex or binary dump of the request?  I will
>> check it out.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20190522/0528eb41/attachment-0001.html>


More information about the discuss mailing list