Adding an Experimenter match field

[EnasAhmad]

Hi,

I am using an Aruba 2930F switch. I want to add an experimenter match field, and I am trying to follow the example in the guide of TCP sequence number. If I understand correctly the header length would be 112 bits as the following:

0xffff050a00002481000300040004

it made me confused since the Experimenter filed header should be 64 bits according to the OpenFlow documentation!

Is this how the OFPTFPT_MATCH array  in the table features message should look like:

OFTableFeaturePropMatchVer13(oxmIds=[0x80000004, 0x80000706, 0x80000906 .....(any other basic 32bit oxmids),0xffff050a00002481000300040004]) 

Can you please provide me with an example of a correct  OFPTFPT_MATCH array that has an experimenter field in addition to the basic oxm fields, and which controller can be used to achieve this?

Thanks,

Enas

[Abhay_B]

Hello Enas,

It is exciting to see that you are trying to use the customizable match fields feature on our switches.

When the OXM class type in the OXM header of a OFPTFPT_MATCH field is OFPXMC_EXPERIMENTER, the switch will parse the information in the OXM header as follows:

The OpenFlow Admin Guide talk in detail about how the OXM header needs to be setup for a customizable match field both in the OFPMP_TABLE_FEATURES message and the OFPT_FLOW_MOD message.

I am attaching a sample packet trace that defines a table (0) with 2 custom match fields TCP Sequence and Acknowledgement numbers along with the standard OXM fields ETH_TYPE and IP_PROTO. (Please rename the extension back to .pcap to open it with a packet analyzer tool like wireshark)

The packet trace also has a sample flow-mod request that adds an entry to this table with the following match,

ETH_TYPE=0x800, IP_PROTO=6, TCP_ACK_NUM(Field=6)=0x98765432,TCP_SEQ_NUM(Field=5)=0x12345678.

Hope this helps you better understand how the experimenter fields are encoded.

We used sample VAN applications to send both the OFPMP_TABLE_FEATURES and OFP_FLOW_MOD messages with experimenter match fields.

Any OpenFlow controller that supports libraries to encode an OXM_MATCH field with class type OFPXMC_EXPERIMENTER can be used. (Ex: HPE VAN, RYU etc.,)

Let me know if you have further questions on this topic.

Thanks!

Abhay

[EnasAhmad]

Thank you Abhay for your reply, you have been very helpful!

Ok so it seems you split the Experimenter header into 32bit segments. I have tried sending the same set of match fields (TCP Sequence and Acknowledgement numbers along with the standard OXM fields ETH_TYPE and IP_PROTO) to table 0, however, I get the following error:

0010:01:39:43.01 OPFL eOFNetTask:RX from tcp:10.0.0.1:6653: 0: Table 0 received 
   has match 5 which cannot be supported

I have attached the .pcap file that has the table features request. If I simply remove the two custom fields the request is executed successfully and the tables are created.

Do you know what I might be doing wrong? 

Note: I found it strange that you used 0a and 0c for the (OXM_FIELD) instead of 05 and 06 like it is described in the guide.

Thank you  in advance,

Enas

[Abhay_B]

Hello Enas,

The OXM field is the upper 7 bits of the byte and the lower bit is used to determine if the field is maskable.

Hence when the field is 5 with no masking capability, it translates to a value of 0xa for the byte and 0xc for field 6.

Regarding the error you see, I don't see anything wrong in the TABLE_FEATURES message you are pushing to the switch.

I take it you are currently running the 16.02 firmware. Can you please upgrade your switch firmware to 16.03.0003 and re-run your test? It is possible that the error you see was a switch firmware bug that was fixed in 16.03.

Thanks!

Abhay

[EnasAhmad]

I take it you are currently running the 16.02 firmware. Can you please upgrade your switch firmware to 16.03.0003 and re-run your test? It is possible that the error you see was a switch firmware bug that was fixed in 16.03.

Thanks again Abhay for your reply. You are right when I upgraded to 16.03 the error disappeared, and the match fields were added.  

The OXM field is the upper 7 bits of the byte and the lower bit is used to determine if the field is maskable. Hence when the field is 5 with no masking capability, it translates to a value of 0xa for the byte and 0xc for field 6.

Aha I see, I hope the guide gets updated to include this in defining a custom field instead of using 0x05 and 0x6 (I believe with masking capability it would be 0xb and 0xd).

Ok, now I am trying to understand the format of the flow mod message. Let's take the TCP_ACK_NUM(Field=6)=0x98765432 match example. According to the flow-mod example you sent the match for the TCP_ACK_NUM should be :

ffff 0c 18 00002481 00000004 98765432

I am a bit confused about the 0x18. which in the guide explained as the OXM_LEN: The length of the experimenter header excluding the OXM header. So why is it 0x18 since we set the oxm_len to 0x0a in the table features? 

I am trying to define a custom field of 128bits (16 bytes) that is parsed after the UDP header (8 bytes). I defined the field as the following in the table feature: 

ffff 0a 0a 00002481 0003 0008 0010  

The field is created successfully on the switch.

However, when I create a flow-mod to match against this field I get an error of OFBadMatchErrorMsgVer13(xid=46, code=BAD_FIELD, and sometimes the switch suddenly reboots!

Is this how the match of my field in the flow-mod should look like ??

ffff 0a 14 00002481 00000010 3133 5444 4538 3930 3631 3433 3638 3730

where 0x31335444453839303631343336383730 is my match data.

[Abhay_B]

Hello Enas,

Glad to know moving to 16.03 helped you progress.

I will take note of clarifiying the values associated with the OXM_FIELD in the Admin Guide.

With masking set, yes the fields would be 0xb and 0xd instead of 0xa and 0xc respectively.

Regarding your following query -

"I am a bit confused about the 0x18. which in the guide explained as the OXM_LEN: The length of the experimenter header excluding the OXM header. So why is it 0x18 since we set the oxm_len to 0x0a in the table features? "

Remember, the OXM_LEN is for the current OXM header.

In case of the TABLE_FEATURES request message, the OXM Experimenter header has only the following data post the OXM header itself:

HPE OUI ID (4 bytes) + START_TYPE (2 bytes) + OFFSET_START (2 bytes) + NUM_BYTES (2 bytes) = 10 bytes (0xa)

In case of the FLOW_MOD message, the OXM Experimenter header has the following data post the OXM header itself:

HPE OUI ID (4 bytes) + LENGTH_OF_MATCH_DATA (4 bytes) + MATCH_DATA (16bytes always) = 24 bytes (0x18)

Coming to your example,

Is this how the match of my field in the flow-mod should look like ??

ffff 0a 14 00002481 00000010 3133 5444 4538 3930 3631 3433 3638 3730

If you observe closely, the OXM_LEN in your example is set incorrectly to 20 bytes (0x14) instead of 24 bytes (0x18).

Thus the switch is rejecting the flow since it doesn't contain the 16 bytes of data it expects based on the definition of the field in TABLE_FEATURES request message.

Also, the OXM_LEN for a custom match OXM_EXPERIMENTER field which is non maskable should always be 24 bytes (0x18), the switch will only consider the relevant match data based on the LENGTH_OF_MATCH_DATA set.

Hope this helps.

Thanks!

Abhay

[EnasAhmad]

Hi Abhay, 

I really appreciate your help,

Ok so when I correct the length and I set my match field to:

ffff 0a 18 00002481 00000010 3133 5444 4538 3930 3631 3433 3638 3730

I no longer get the bad field error, however, I get the error OFBadMatchErrorMsgVer13(xid=20, code=BAD_WILDCARDS. The first pcap file attached has the packets capture. Any idea?

Moreover, I actually aim to have this same field with mask capabilities (I was trying the basic field first before moving to the more complex case). I define my field as the following in the table feature msg:

ffff 0b 0a 00002481 0003 0008 0010  

and as the following in the match msg:

ffff 0b 28 00002481 00000020 3133 5444 4538 3930 3631 3433 3638 3730 FFFF FFFF FFFF FF00 0000 FFFF 0000 0000

Where FFFF FFFF FFFF FF00 0000 FFFF 0000 0000 is my mask.

However, I get the error OFBadMatchErrorMsgVer13(xid=46, code=BAD_FIELD. The second pcap file attached has the packets capture.

I have also tried:

ffff 0b 28 00002481 00000010 3133 5444 4538 3930 3631 3433 3638 3730 FFFF FFFF FFFF FF00 0000 FFFF 0000 0000

and

ffff 0b 18 00002481 00000010 3133 5444 4538 3930 3631 3433 3638 3730 FFFF FFFF FFFF FF00 0000 FFFF 0000 0000

But got the same error. I didn't find any information that explains how to define a custom match field with masking in the guide, so any help would be useful.

Thanks a bunch!

Enas

[EnasAhmad]

Ok so I have figured the answer to my first question: I was getting code=BAD_WILDCARDS because I needed to add all the the match fields that are not set in my flow-mod to the OFTableFeaturePropWildcards of the table, including the custom fields. the trick was that I had to add the custom fields in the wildcard list in the following format 

ffff0a0a 00002481 only and not ffff0a0a 00002481 0003 0008 0010 !!

So I will wait for your answer on my second question regarding defining a custom field with mask capabilities :) 

Thanks,

Enas

[Abhay_B]

Hello Enas,

Yes the first error was because of the missing wildcards definition for the first table.

Regarding the second error, can you please enable debug for OpenFlow and share the error string returned by the switch for the flow which fails.

debug destination session

debug openflow error

It will help us understand the reason for failure much better.

Thanks!

Abhay

[EnasAhmad]

If I enable the debug for openflow errors and the destination session and then send out the flow-mod with the masked custom field the switch reboots! So I am unable to use these debug features.

However, this is the error I get in the message statistics:

OFPBMC_BAD_FIELD 1
The table doesn't support match on at least one field in the rule.

It seems I am not defining the custom match field with mask correctly. Can you please let me know what is the correct header format (in the feature table match prop and the flow-mod match entries) for a custom field with mask?

I defined it this way in the match prop. I set it to 0b instead of 0a to set the wildcard bit.

ffff 0b 0a 00002481 0003 0008 0010  

And this way in the flow-mod match:

ffff 0b 28 00002481 00000020 3133 5444 4538 3930 3631 3433 3638 3730 FFFF FFFF FFFF FF00 0000 FFFF 0000 0000

Where FFFF FFFF FFFF FF00 0000 FFFF 0000 0000 is my mask.

I set the length to 28 instead of 18 to add the 16 bytes of the mask (24+16=40 == 0x28). And I set the length to 20 instead of 10 for the same reason (16 + 16 = 32 == 0x20). However, this seems incorrect because the table does not identify the field. The pcap file (BAD_FIELD) is attached to my previous msg.