SD-WAN

Hello.

I have some question on reassembling of IP fragments on openflow switches on default installation (VAN SDN 2.3) without additional apps.

There are output for OFPT_FEATURES_REQUEST/OFPT_FEATURES_REPLY:

provision 3800 (KA.15.15.0006):

OpenFlow 1.3
    Version: 1.3 (0x04)
    Type: OFPT_FEATURES_REPLY (6)
    Length: 32
    Transaction ID: 333
    datapath_id: 0x000a10604b38eca5
    n_buffers: 0
    n_tables: 3
    auxiliary_id: 0
    Pad: 0
    capabilities: 0x0000010f
        .... .... .... .... .... .... .... ...1 = OFPC_FLOW_STATS: True
        .... .... .... .... .... .... .... ..1. = OFPC_TABLE_STATS: True
        .... .... .... .... .... .... .... .1.. = OFPC_PORT_STATS: True
        .... .... .... .... .... .... .... 1... = OFPC_GROUP_STATS: True
        .... .... .... .... .... .... ..0. .... = OFPC_IP_REASM: False
        .... .... .... .... .... .... .0.. .... = OFPC_QUEUE_STATS: False
        .... .... .... .... .... ...1 .... .... = OFPC_PORT_BLOCKED: True
    Reserved: 0x00000000

comware 5500EI (5.20.99 R2221P02):

OpenFlow 1.3
    Version: 1.3 (0x04)
    Type: OFPT_FEATURES_REPLY (6)
    Length: 32
    Transaction ID: 172
    datapath_id: 0x000ab8af6738252b
    n_buffers: 1024
    n_tables: 1
    auxiliary_id: 0
    Pad: 0
    capabilities: 0x0000014f
        .... .... .... .... .... .... .... ...1 = OFPC_FLOW_STATS: True
        .... .... .... .... .... .... .... ..1. = OFPC_TABLE_STATS: True
        .... .... .... .... .... .... .... .1.. = OFPC_PORT_STATS: True
        .... .... .... .... .... .... .... 1... = OFPC_GROUP_STATS: True
        .... .... .... .... .... .... ..0. .... = OFPC_IP_REASM: False
        .... .... .... .... .... .... .1.. .... = OFPC_QUEUE_STATS: True
        .... .... .... .... .... ...1 .... .... = OFPC_PORT_BLOCKED: True
    Reserved: 0x00000000

Both my tested switches reports "OFPC_IP_REASM = false", but in default installation (VAN SDN 2.3) immediately follows OFPT_SET_CONFIG request with Flags: 0x0002 (IP Fragments: OFPC_FRAG_REASM (2)).
Comware 5500EI returns correctly error (OFPT_ERROR, Type: OFPET_SWITCH_CONFIG_FAILED (10), Code: OFPSCFC_BAD_FLAGS (0)) but Provision 3800 silently accept request.

Questions:

1) Do 5500EI and/or 3800 support OFPC_IP_REASM (eg. is OFPT_FEATURES_REPLY correctly answered) ?

2) Why the controller sending OFPT_SET_CONFIG with OFPC_FRAG_REASM ?

I think, that this is not compliant with "OpenFlow Switch Specification
Version 1.3.1 (Wire Protocol 0x04)" see "B.6.7 Explicit Handling of IP Fragments"  page 107.

3) Why 3800 does not respond with error (if OFPC_IP_REASM is not supported) ?

4) I stopped sending wrong "OFPT_SET_CONFIG" with controller configuration "com.hp.sdn.ctl.of.impl.ControllerManager" "suppress.setconfig=true". Is there any side effects ?

Thanks for answers, Martin Cerveny

Hello Martin Cerveny,

Thanks for your query.
We will get back to you shortly.

Thanks,
HP SDN Team

1) Do 5500EI and/or 3800 support OFPC_IP_REASM (eg. is OFPT_FEATURES_REPLY correctly answered) ?

This is correct: the 5500EI does not support OFPC_IP_REASM.  So the FEATURES_REPLY gives the correct information.

2) Why the controller sending OFPT_SET_CONFIG with OFPC_FRAG_REASM ?

I think, that this is not compliant with "OpenFlow Switch Specification
Version 1.3.1 (Wire Protocol 0x04)" see "B.6.7 Explicit Handling of IP Fragments"  page 107.

I see nothing in the OpenFlow Switch Specification that indicates that this is not compliant.

Can you please specify why you think it's not compliant?

3) Why 3800 does not respond with error (if OFPC_IP_REASM is not supported) ?

We are still researching this question. 

4) I stopped sending wrong "OFPT_SET_CONFIG" with controller configuration "com.hp.sdn.ctl.of.impl.ControllerManager" "suppress.setconfig=true". Is there any side effects ?

 Likewise, we are still researching this question.

Regards,

Scott

I think, if openflow from version 0.8.9 clarify, that switch does not support "OFPC_IP_REASM" than SDN controller should not try to set "OFPT_SET_CONFIG with OFPC_FRAG_REASM" (that should return error).

M.C>

Martin,

Yes, clearly the Comware and Provision handle it differently.

The OpenFlow specification (I'm looking at v1.3) says:

/* Handling of IP fragments. */

OFPC_FRAG_NORMAL = 0 << 1, /* No special handling for fragments. */

OFPC_FRAG_DROP = 1 << 1, /* Drop fragments. */

OFPC_FRAG_REASM = 2 << 1, /* Reassemble (only if OFPC_IP_REASM set). */

OFPC_FRAG_MASK = 3 << 1

However, that could mean that the action is to reassemble IF OFPC_IP_REASM is set and not reassemble if OFPC_IP_REASM is not set - i.e. this setting can be 0 or 1 if OFPC_IP_REASM is 0.

However, this clearly needs clarification, and it needs a consistent response from the switches.

I will discuss this with Comware and Provision engineers to see which side needs to modify their response.

Scott

Martin,

This has been confirmed as a bug in the Procurve OpenFlow implementation.

There has been a case opened to have this fixed in a future release.

Regards,

Scott

Thanks.