Ethernet Products
Determine ramifications of Intel® Ethernet products and technologies
5019 Discussions

E-810C, GRE and VLANs

ErnestoR
Novice
7,872 Views

Hi,

we are using E810-C-Q2 cards on Centos 8.3 both as 2x1x100GbE and split as 8x10GbE; no differences on the two configurations.

We are using them in a DPDK-based solution for Virtual Network Functions and Software Defined Networking, so they manage any kind of traffic and packets.

All works fine, except when they receive GRE packets with a single VLAN or no VLAN at all: those packets are simply lost somewhere in the NIC and not sent to DPDK drivers. We tried also disabling DPDK and using the Linux ice driver: same result, so apparently it's the firmware that drops the (valid!) packets. If the GRE packet is encapsulated in two VLANS, the NIC correctly sends the packet to the driver. This just to say that we are confident everything around just works fine: it's enough to hide the packet in two VLANs so that the NIC ignores it and passes it. But when it recognizes the packet as GRE, it drops it. No offloading is configured.

 

Any idea why this occurs? Any way to disable this default behaviour?

 

NVM 2.5, CentOS 8.3 DPDK 20.11

 

Thanks

Ernesto

 

0 Kudos
36 Replies
Caguicla_Intel
Moderator
4,781 Views

Hello Ernesto,


Thank you for posting in Intel Ethernet Communities. 


Can you confirm if you are having the exact same issue as described on the link below? 

Refer to my reply ‎06-04-2021 01:20 AM item number 3 for the translation of the query.

https://community.intel.com/t5/Ethernet-Products/%D0%9F%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D0%B0-%D1%81-GRE-47-%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%B0%D0%BC%D0%B8-%D0%BF%D1%80%D0%B8-%D0%BF%D1%80%D0%BE%D1%85%D0%BE%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B8-%D1%87%D0%B5%D1%80%D0%B5%D0%B7-%D1%81%D0%B5%D1%82%D0%B5%D0%B2%D0%BE%D0%B9-%D0%B0%D0%B4%D0%B0%D0%BF%D1%8...


If yes, kindly provide the following information for us to escalate this request to our engineering level.

1. Driver version of your E810-C-Q2?

2. PBA number of the adapter. You may refer to the link below on where to find the PBA number. It consist of 6-3 digit number located at the last part of the serial number. This would help us identify if you are using an Original Equipment Manufacturer or retail version of Intel Ethernet Adapter.

Identify Your Intel® Network Adapter Model Using PBA Number

https://www.intel.com/content/www/us/en/support/articles/000007022/ethernet-products/500-series-network-adapters-up-to-10gbe.html


Awaiting to hear from you soon.


Should there be no response from you, I’ll make sure to reach out after 3 business days.


Best regards,

Crisselle C.

Intel® Customer Support


0 Kudos
ErnestoR
Novice
4,770 Views

Hi Crisselle,

looks like the same issue. There is no mention about the double VLAN in the other thread, but yes: the "drop" effect is definitely the same.

We have the solution deployed with tens of cards, and since the solution is dpdk-based, the linux driver version is irrelevant I think; in the lab we have 1.5.8.

Also for PBA number: there are too many cards deployed everywhere where we have no physical access to the servers. In the lab, one of the cards has a different label attached. Three lines:

B49691B2B048

008 0521AD

K91258 - 006

We procured the nics in different times and from different vendors, so it is definitely possible they have different label structure. So the above one is just one of them

 

Thank you very much for your help

Ernesto

 

0 Kudos
Caguicla_Intel
Moderator
4,763 Views

Hello Ernesto,


Thank you for the reply.


Please allow us to escalate this request to our higher level for for further investigation. We will get back to you as soon as possible but no later than 3 business days.


Hoping for your kind patience.


Best regards,

Crisselle C.

Intel® Customer Support


0 Kudos
Caguicla_Intel
Moderator
4,715 Views

Hello Ernesto,


Good day!


Please be informed that this has been escalated to our E810 engineering team. Rest assured that we will give you an update as soon as we heard from them but no later than 2-4 business days.


Thank you for your kind understanding.


Best regards,

Crisselle C.

Intel® Customer Support


0 Kudos
ErnestoR
Novice
4,703 Views

Thank you Crisselle,

just one correction on my statements: the problem disappears when there are three (and not two) VLANs.

Sorry for the confusion: all our traffic is encapsulated inside a VLAN and the original two VLANs become actually three when they reach us.

Thanks

Ernesto

 

0 Kudos
Caguicla_Intel
Moderator
4,674 Views

Hello Ernesto,


Thank you for the clarification. We will share this as well to our engineering team.


Please be informed that this request is still escalated on their end. Rest assured that we will give you an update as soon as we heard form them but no later than 2-4 business days.


Thank you for your kind understanding and stay safe!


Best regards,

Crisselle C.

Intel® Customer Support


0 Kudos
RomanVTrepalin
New Contributor I
4,670 Views

Приветствую всех!

Это та же самая проблема, что и в моем описании. В конце ветки я упоминал уже, что пакеты GRE упакованные в два тега картой не отбрасываются. Во всех иных случаях они классифицируются картой как Unknown Packets и отбрасываются.

 

С уважением, Роман.

0 Kudos
Caguicla_Intel
Moderator
4,621 Views

Hello Ernesto,


Good day!


We'd like to inform you that this request is still escalated on our engineering's end. We will give you an update as soon as possible but no later than 2-4 business days. 


Thank you for the patience.


Best regards,

Crisselle C.

Intel® Customer Support


0 Kudos
ErnestoR
Novice
4,590 Views

Hello Crisselle,

I fully understand you cannot commit to any date, yet having some more insight would really help.

Did the engineers ever take a look at it? If not, is there an average waiting time?

Is it still under analysis? If so is there an average duration of analysis like this? Not a commitment on the future, but a number from the past: like financial forecasts: no obligations, no commitments, nothing: just how it was in the past.

Is it a recognized bug? If so what's its priority?

Or what's the current status in the engineering group?

 

Thanks

Ernesto

 

0 Kudos
Caguicla_Intel
Moderator
4,578 Views

Hello Ernesto,


Good day!


We totally understand the importance of this request and how this has impacted your workflow. With this, we sincerely apologize for the delay and inconvenience that this might have caused. 


To answer your question, this is still under investigation by our engineers and they are currently working with validation team with the pcap file (from other customer). Rest assured that we will give an update as soon as there is any findings but no later than 2-4 business days.


Thank you for your kind understanding.


Best regards,

Crisselle C.

Intel® Customer Support 


0 Kudos
Caguicla_Intel
Moderator
4,535 Views

Hello Ernesto,


Apologies for the delay on this matter. 


Please be informed that we are still waiting for an update from our engineering team. We will get back to you as soon as we heard any findings from them but no later than 2-4 business days.


Thank you for taking the rime in reading this message and stay safe!


Best regards,

Crisselle C.

Intel® Customer Support 


0 Kudos
Caguicla_Intel
Moderator
4,506 Views

Hello Ernesto,


Thank you for the patience on this matter. 


Based on pcap that the other user have attached/shared, the GRE version is set to 1 which is Enhanced GRE. This is the reason there is an error entry and gets rejected. – ice ddp package parser supports GRE version = 0. Enhanced GRE (GRE version = 1) is not supported.


As far as GRE is concerned we have exact same support in OS and Comms package, so enhanced GRE is not supported in comms package as well.  


Engineering is looking into implementing this. 


With this, can you confirm if the above is in your setup?


Looking forward to your reply.


We will follow up after 3 business days in case we don't hear from you.


Best regards,

Crisselle C.

Intel Customer Support


0 Kudos
ErnestoR
Novice
4,497 Views
Hi Crisselle,
Our software stays in the middle doing nat, pat, vlan retagging and so on, so we are not in the condition to change or even know what kind of traffic is arriving. Getting to the conclusion that gre was the issue was itself a nightmare in the “some packets get dropped” issue.

Is there a way to disable the parser while keeping packet hash and multiple queue splitting?

Thanks

0 Kudos
Caguicla_Intel
Moderator
4,456 Views

Hello Ernesto,


Appreciate your swift response.


Please allow us to re-escalate this request to our engineers. We will give you an update as soon as we heard from them but no later than 2-5 business days.


Thank you for your kind patience.


Best regards,

Crisselle C.

Intel Customer Support


0 Kudos
Caguicla_Intel
Moderator
4,405 Views

Hello Ernesto,


Good day!


Please be informed that we already re-escalated this request to our engineers. Rest assured that we will get back to you as soon as there is any findings but no later than 2-4 business days.


Thank you for your kind patience and stay safe!


Best regards,

Crisselle C.

Intel Customer Support


0 Kudos
Caguicla_Intel
Moderator
4,364 Views

Hello Ernesto,


Thank you for the patience on this matter.


Kindly refer to below information for the update from our engineering team.


Question: Is there a way to disable the parser while keeping packet hash and multiple queue splitting?

Answer: Parser is required to classify the packets, cannot disable it.


Feel free to let us know if you have additional questions and clarifications on this matter.


Awaiting to your reply.


Should there be no response from you, I’ll make sure to reach out after 3 business days.


Best regards,

Crisselle C.

Intel® Customer Support


0 Kudos
ErnestoR
Novice
4,360 Views

Thank you Crisselle,

Unpleasant but very clear and complete.

Is it possible to be notified when Enhanced GRE will be implemented or should I just read firmware release notes?

Thanks for your support

Ernesto

 

0 Kudos
Caguicla_Intel
Moderator
4,356 Views

Hello Ernesto,


Appreciate your swift response.


Please allow me to check this with our engineers. We will get back to you as soon as we heard from them but no later than 2-3 business days. 


Thank you for your kind patience.


Best regards,

Crisselle C.

Intel® Customer Support


0 Kudos
AldyC_Intel
Moderator
4,321 Views

Hello Ernesto,


Greetings,

Please be advised that our engineers will be submitting this as a feature request. Unfortunately, they do not have a clear ETA on when/if the feature will be implemented. The request must first go through an approval process. 


Rest assured that we will get back to you as soon as there is any findings but no later than 2-4 business days.


Thank you for your kind patience.


Best regards,


Aldy C.

Intel Customer Support


0 Kudos
ErnestoR
Novice
4,307 Views

Hi Crisselle,

I think there's a big misunderstanding here.

What do you mean by "feature request"?

Your card drops packet. Do you think a feature is required to fix it?

Thanks

Ernesto

 

0 Kudos
Reply