The question about gre protocol type supported by SONiC

[kaiyu22]

Description
I have tested two gre protocol type (0x6558, 0x88be) in mirror session, and found that only 0x88be is passed and 0x6558 failed. The error message is due to SAI_STATUS_ATTR_NOT_SUPPORTED_0.
(Please see the detail attached to below section)

My question is that does SONiC support gre type 0x6558 or shoud use 0x88be in mirror?
I saw that the gre type 0x6558 is used in below link.
https://github.com/Azure/sonic-swss/blob/master/swssconfig/sample/mirror.json

PS:

1. 0x6558: Trans Ether Bridging [RFC1701]
2. 0x88be: Encapsulated Remote SPAN (ERSPAN)
3. ASIC vendor: Broadcom

Steps to reproduce the issue:

1. docker exec swss swssconfig /root/mirror.json (use gre_type 0x6558)
2. ip route add 2.2.2.0/24 via 10.10.1.1 dev Ethernet0
3. check syslog and orchagent process

Describe the results you received:
The below is the error message printed in the syslog

Nov  8 08:26:43.354171 sonic ERR syncd: _brcm_sai_create_mirror_session:465 Error processing mirror attributes
Nov  8 08:26:43.354171 sonic ERR syncd: :- processEvent: attr: SAI_MIRROR_SESSION_ATTR_TC: 5
Nov  8 08:26:43.354248 sonic ERR syncd: :- processEvent: attr: SAI_MIRROR_SESSION_ATTR_MONITOR_PORT: oid:0x1000000000002
Nov  8 08:26:43.354314 sonic ERR syncd: :- processEvent: attr: SAI_MIRROR_SESSION_ATTR_TYPE: SAI_MIRROR_SESSION_TYPE_ENHANCED_REMOTE
Nov  8 08:26:43.354380 sonic ERR syncd: :- processEvent: attr: SAI_MIRROR_SESSION_ATTR_ERSPAN_ENCAPSULATION_TYPE: SAI_ERSPAN_ENCAPSULATION_TYPE_MIRROR_L3_GRE_TUNNEL
Nov  8 08:26:43.354452 sonic ERR syncd: :- processEvent: attr: SAI_MIRROR_SESSION_ATTR_IPHDR_VERSION: 4
Nov  8 08:26:43.354521 sonic ERR syncd: :- processEvent: attr: SAI_MIRROR_SESSION_ATTR_TOS: 200
Nov  8 08:26:43.354589 sonic ERR syncd: :- processEvent: attr: SAI_MIRROR_SESSION_ATTR_TTL: 10
Nov  8 08:26:43.354658 sonic ERR syncd: :- processEvent: attr: SAI_MIRROR_SESSION_ATTR_SRC_IP_ADDRESS: 100.0.0.1
Nov  8 08:26:43.354728 sonic ERR syncd: :- processEvent: attr: SAI_MIRROR_SESSION_ATTR_DST_IP_ADDRESS: 2.2.2.2
Nov  8 08:26:43.354796 sonic NOTICE orchagent: :- handle_switch_shutdown_request: switch shutdown request
Nov  8 08:26:43.354882 sonic ERR syncd: :- processEvent: attr: SAI_MIRROR_SESSION_ATTR_SRC_MAC_ADDRESS: 00:05:64:2F:0F:1C
Nov  8 08:26:43.354951 sonic ERR syncd: :- processEvent: attr: SAI_MIRROR_SESSION_ATTR_DST_MAC_ADDRESS: 6C:EC:5A:08:12:9A
Nov  8 08:26:43.355020 sonic ERR syncd: :- processEvent: attr: SAI_MIRROR_SESSION_ATTR_GRE_PROTOCOL_TYPE: 25944
Nov  8 08:26:43.355089 sonic ERR syncd: :- processEvent: failed to execute api: create, key: SAI_OBJECT_TYPE_MIRROR_SESSION:oid:0xe0000000005cd, status: SAI_STATUS_ATTR_NOT_SUPPORTED_0
Nov  8 08:26:43.355158 sonic ERR syncd: :- syncd_main: Runtime error: :- processEvent: failed to execute api: create, key: SAI_OBJECT_TYPE_MIRROR_SESSION:oid:0xe0000000005cd, status: SAI_STATUS_ATTR_NOT_SUPPORTED_0
Nov  8 08:26:43.355229 sonic NOTICE syncd: :- exit_and_notify: sending switch_shutdown_request notification to OA
Nov  8 08:26:43.355298 sonic NOTICE syncd: :- exit_and_notify: notification send successfull
Nov  8 08:26:43.355366 sonic WARNING syncd: :- exit_and_notify: sleep forever to keep data plane active
Nov  8 08:26:43.360209 sonic INFO supervisord: orchagent terminate called after throwing an instance of 'std::invalid_argument'
Nov  8 08:26:43.360209 sonic INFO supervisord: orchagent   what():  parse error - unexpected end of input
Nov  8 08:26:43.616859 sonic INFO swss.sh[2762]: 2017-11-08 08:26:43,616 INFO exited: orchagent (terminated by SIGABRT (core dumped); not expected)
Nov  8 08:26:43.918990 sonic INFO supervisord 2017-11-08 08:26:43,616 INFO exited: orchagent (terminated by SIGABRT (core dumped); not expected)

Describe the results you expected:
Pass

Additional information you deem important (e.g. issue happens only occasionally):

**Output of `show version`:**

SONiC Software Version: SONiC.SONiC-Ingrasys-v1.3.0-437419c
Distribution: Debian 8.9
Kernel: 3.16.0-4-amd64
Build commit: 437419c
Build date: Fri Oct 27 09:02:25 UTC 2017
Built by: sonic@sonic

Docker images:
REPOSITORY                TAG                             IMAGE ID            SIZE
docker-syncd-brcm         SONiC-Ingrasys-v1.3.0-437419c   cdcee25d83a4        318.3 MB
docker-syncd-brcm         latest                          cdcee25d83a4        318.3 MB
docker-orchagent-brcm     SONiC-Ingrasys-v1.3.0-437419c   fcb06af1a06d        259.1 MB
docker-orchagent-brcm     latest                          fcb06af1a06d        259.1 MB
docker-lldp-sv2           SONiC-Ingrasys-v1.3.0-437419c   71c44d8b4d46        256.5 MB
docker-lldp-sv2           latest                          71c44d8b4d46        256.5 MB
docker-dhcp-relay         SONiC-Ingrasys-v1.3.0-437419c   c5ea6ae37ceb        253.5 MB
docker-dhcp-relay         latest                          c5ea6ae37ceb        253.5 MB
docker-database           SONiC-Ingrasys-v1.3.0-437419c   e38cab48359e        251.7 MB
docker-database           latest                          e38cab48359e        251.7 MB
docker-snmp-sv2           SONiC-Ingrasys-v1.3.0-437419c   97e0ae330326        291.3 MB
docker-snmp-sv2           latest                          97e0ae330326        291.3 MB
docker-teamd              SONiC-Ingrasys-v1.3.0-437419c   44ef14751dc7        256.1 MB
docker-teamd              latest                          44ef14751dc7        256.1 MB
docker-platform-monitor   SONiC-Ingrasys-v1.3.0-437419c   af75bbc58bf1        271 MB
docker-platform-monitor   latest                          af75bbc58bf1        271 MB
docker-fpm-quagga         SONiC-Ingrasys-v1.3.0-437419c   3b724be6ed5f        262.7 MB
docker-fpm-quagga         latest                          3b724be6ed5f        262.7 MB

[kaiyu22]

After investigating, I found that the root cause seems to be the value of "queue" in json file.
Please refer the test script downloaded from MSFT, the content is shown as below.
https://github.com/Azure/sonic-mgmt/blob/59f569213e5530fa74b96490b4ca80b333d6d1ed/ansible/roles/test/tasks/everflow/logic_test/config_valid.json

[
    {
        "MIRROR_SESSION_TABLE:session1": {
            "src_ip": "1.1.1.1",
            "dst_ip": "2.2.2.2",
            "gre_type": "25944",
            "dscp": "50",
            "ttl": "10",
            "queue": "5"
        },
        "OP": "SET"
    }
]

If "queue" is set to "5", no matter what the gre type is 0x6558 or 0x88be Broadcom SAI will return "SAI_STATUS_ATTR_NOT_SUPPORTED_0".
On the other hand, the value of "queue" will be "0" if minigraph.xml has configured "ErspanDestinationIpv4".
Please refer the file /etc/swss/config.d/mirror.json under docker swss. The content is shown as below.

  [
       {
           "MIRROR_SESSION_TABLE:everflow0": {
               "src_ip": "100.0.0.1",
               "dst_ip": "2.2.2.2",
               "gre_type": "0x88be",
               "queue": "0",
               "dscp": "8",
               "ttl": "255"
           },
           "OP": "SET"
       }
   ]

If "queue" is set to "0", the test is passed no matter what the gre type is 0x6558 or 0x88be.

We also observed the code in orchagent/mirrororch.cpp. The content is shown as below.
https://github.com/Azure/sonic-swss/blob/136621b497d8a51577c7a33e67c7d0fb68a04f2d/orchagent/mirrororch.cpp

/* Some platforms don't support SAI_MIRROR_SESSION_ATTR_TC and only
 * support global mirror session traffic class. */
if (session.queue != 0)
{
    attr.id = SAI_MIRROR_SESSION_ATTR_TC;

Maybe it can explan why Broadcom returned "SAI_STATUS_ATTR_NOT_SUPPORTED_0".
Boradcom didn't support SAI_MIRROR_SESSION_ATTR_TC in current master.
(SAI v3.0.3.2-13, OPENNSL v3.2.3.3-2)

Hi @stcheng,
Could you give us the comment?

Thanks for your help.

[ramachandrareddygaddam]

Could you pl try by removing the 'queue' entry in mirror session.
"MIRROR_SESSION": {
"everflow0": {
"dscp": "50",
"src_ip": "10.1.0.32",
"ttl": "10",
"dst_ip": "20.0.0.10",
"gre_type": "0x6558"
}
}

[stcheng]

moving away from 0x6558; we're using 8949 and 88be for now.

[aatrens-juniper]

Hi Folks,

Curious if this has actually been fixed - can we expect to be able to do GRE (0x6558) encapsulated Everflow monitoring on SONiC? Or, going forward, will only ERSPAN (0x88be) be supported?

Cheers,

--Andrew