Community
cancel
Showing results for 
Search instead for 
Did you mean: 
bkwon1
Novice
551 Views

Intel XL710-QDA2 NIC produces all-Zero source MAC for LLDPDU

Jump to solution

Hello there.

 

Intel XL710-QDA2 (and X710-DA2 also) produces All-Zero source MAC for LLDP Discovery (LLDPDU).

Cisco switch consider this all-zero source MAC as attack signature, and drops the packet.

 

Red Hat told us that this all-zero MAC comes from NIC itself (not OS fault)

 

Is there a way to fix this problem?

 

This wasn't happening from old Niantic 82599 NIC

(Source MAC is NIC's port MAC on 82599)

 

I've attached tcpdump and capture picture.

Thank you!

0 Kudos
1 Solution
CrisselleF_C_Intel
Moderator
500 Views

Hello bkwon1, 


Thank you for the patience on this matter.


We've already heard from our engineering team and they found a particular issue that could be the same with yours. They need to first make sure that it is indeed the same issue, kindly refer to information below and confirm.


There is a SW lldp service included with RedHat. Have you stop the lldpad SW and enable the FW lldp and test. If the proper MAC address is now showing, then we are dealing with the same issue.


Further information if it is the same issue:

It was found to be a RedHat issue when they apply patches to the open-lldp source tree.

The http://open-lldp.org/ tree is patched with out-of-tree patches while RHEL builds the lldpad rpm. This is a part of a standard build procedure.

The patch that causes a regression is:

Patch25:  open-lldp-v1.0.1-25-l2_linux_packet-correctly-process-return-value-of-ge.patch


You can build from the open-lldp.org source and test that as well.


Looking forward to your reply.


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


Best regards,

Crisselle C

Intel® Customer Support


View solution in original post

13 Replies
CrisselleF_C_Intel
Moderator
542 Views

Hello bkwon1,


Thank you for posting in Intel Ethernet Communities. 


Kindly provide the following information that would help us in checking your request.


1.) Exact Operating System used.

2.) Driver version used and where was the driver downloaded from

3.) How many cards are affected by this issue?

4.) Please share the PBA and serial number of the adapter. You may refer to the link below on where to find the PBA number. Providing photos of the adapter focusing on the markings (white sticker) found on the physical card will be highly appreciated for us to double check on it. The PBA consists 6-digit number located at the last part of the serial number.

https://www.intel.com/content/www/us/en/support/articles/000007022/network-and-i-o/ethernet-products...


Awaiting to your response.


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


Best regards,

Crisselle C

Intel® Customer Support


bkwon1
Novice
539 Views

1.) Exact Operating System used.

  -> Red Hat RHEL 7.6

2.) Driver version used and where was the driver downloaded from

 -> i40e driver 2.3.2-k (RHEL 7.6 inbox driver)

 -> firmware 10.51.5

3.) How many cards are affected by this issue?

  -> more than 2

  -> test lab has 2

4.) Please share the PBA and serial number of the adapter. You may refer to the link below on where to find the PBA number. Providing photos of the adapter focusing on the markings (white sticker) found on the physical card will be highly appreciated for us to double check on it. The PBA consists 6-digit number located at the last part of the serial number.

  -> Serial MYI017003F

  -> Serial MYI01700BX

 

thank you

 

CrisselleF_C_Intel
Moderator
536 Views

Hello bkwon1,


Thank you for the prompt reply. 


We hope you don't mind providing the additional information below in line with your answers. 


1.) You mentioned that the adapter has driver version 2.3.2. With this we'd like to check if you have tried the latest driver for your adapter and check if it will help in fixing the issue? 

2.) Can you also share where was the firmware version 10.51.5 was downloaded from? Is this a custom firmware for your adapter?

3.) Can you provide the PBA of your adapter? It consists 6-3 digit number located at the last part of the serial number. The information you have provided is the serial number. 


We hope to hear from you soon.


Should there be no response, we will follow up after 3 business days. 


Best regards,

Crisselle C

Intel® Customer Support


bkwon1
Novice
533 Views

Hello, please see below ans

 

1.) You mentioned that the adapter has driver version 2.3.2. With this we'd like to check if you have tried the latest driver for your adapter and check if it will help in fixing the issue? 

- At this time we're conducting BMT so changing driver is not easy.

Besides, driver release note did not mentioned about all-zero MAC.

 

2.) Can you also share where was the firmware version 10.51.5 was downloaded from? Is this a custom firmware for your adapter?

support.hpe.com

 

3.) Can you provide the PBA of your adapter? It consists 6-3 digit number located at the last part of the serial number. The information you have provided is the serial number. 

H44490-019 

CrisselleF_C_Intel
Moderator
522 Views

Hello bkwon1,


Appreciate your swift response.


Please allow us to check on this further. Rest assured that we will give an update as soon as possible but no later than 3 business days.


Hoping for your patience.


Best regards,

Crisselle C

Intel® Customer Support


CrisselleF_C_Intel
Moderator
516 Views

Hello bkwon1,


We sincerely apologize for the delay on this matter.


Please be informed that we are still checking on your request. We will give an update as soon as there is any findings but no later than 2-3 business days.


Thank you for your kind understanding.


Best regards,

Crisselle C

Intel® Customer Support


bkwon1
Novice
515 Views

Hello, Crisselle, 

 

This is what we know as of now:

- This All-Zero source MAC for LLDP from X710-DA2 is not OEM vendor specific. Means, DELL's X710-DA2 produces same results (what operator told us)

 

- Changing private-flag produces follow results:

(Case 1) disable-fw-lldp on 

- LLDPDU source MAC all zero 00:00:00:00:00:00

- LLDPDU has server's port information

- PCAP packet 1~8, 24

(Case 2) disable-fw-lldp off

- LLDPDU source MAC = physical port MAC

- LLDPDU does NOT have server port information

- PCAP packet 9~22

 

--------------------------

Below is what Cisco switch TAC told us:

 

RE: Re:RE: Re:SR 689295409 : [KT]N9K-C93180YC-EX/Unable to verifylldpinformation

 

 

 

Hi Mr.Choi,

 

From the log, I observed switch discarded  LLDP packet received from server due to invalid source mac address.

 

show system internal lldp event-history errors

 

85) Event:E_DEBUG, length:76, at 727526 usecs after Tue Jun 16 13:34:34 2020

[102] Received bad LLDP Packet on if_index 0x1a001400in lldp_process_rx_data

 

86) Event:E_DEBUG, length:59, at 727486 usecs after Tue Jun 16 13:34:34 2020

[102] lldp_pkt_parse: Not a lldp packet. Eth src addr wrong.   <<<<<<<<<<<< source mac address is wrong.

 

 

RE: Re:RE: Re:RE: Re:SR 689295409 : [KT]N9K-C93180YC-EX/Unable toverifylldpinformation

 

 

 

Hi Mr.Choi,

 

As mentioned before, switch will consider frame with all zero source mac as invalid packet and drop it.

 

Software 7.0(3)I7.3 and earlier. N9K will process this packet but this is incorrect behavior. from 7.0(3)I7.4 and later version. we have changed mechanism to drop this frame, thats the reason for why it is working on 7.0(3)I7.3 and not working on later version.

 

It is not reasonable that server send all zero source mac frame, normally, server bonding mac address should only be externally visible on one of NIC address.

 

Thanks

CrisselleF_C_Intel
Moderator
505 Views

Hello bkwon1,


Thank you for the additional information provided.


We are still actively working on this issue for you and we are involving higher level Engineers to sort this out as soon as possible. We will give you an update no later than 2-3 business days.


We appreciate your kind understanding.


Best regards,

Crisselle C

Intel® Customer Support


CrisselleF_C_Intel
Moderator
501 Views

Hello bkwon1, 


Thank you for the patience on this matter.


We've already heard from our engineering team and they found a particular issue that could be the same with yours. They need to first make sure that it is indeed the same issue, kindly refer to information below and confirm.


There is a SW lldp service included with RedHat. Have you stop the lldpad SW and enable the FW lldp and test. If the proper MAC address is now showing, then we are dealing with the same issue.


Further information if it is the same issue:

It was found to be a RedHat issue when they apply patches to the open-lldp source tree.

The http://open-lldp.org/ tree is patched with out-of-tree patches while RHEL builds the lldpad rpm. This is a part of a standard build procedure.

The patch that causes a regression is:

Patch25:  open-lldp-v1.0.1-25-l2_linux_packet-correctly-process-return-value-of-ge.patch


You can build from the open-lldp.org source and test that as well.


Looking forward to your reply.


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


Best regards,

Crisselle C

Intel® Customer Support


View solution in original post

bkwon1
Novice
477 Views

Hello, 

Customer changed lldpad from version 1.0.1-3 to 1.0.1-2 (old version) and ran test again - now LLDPDU shows proper source MAC addresses. They'll notify RH about same.

 So, I think we're dealing with same issue.

Do we have any more leads from engineering (like RH's plan to release fix on this matter).

Thank you!

 

CrisselleF_C_Intel
Moderator
464 Views

Hello bkwon1, 


Thank you for the confirmation.


Please allow me to forward your reply to our engineering team. Although this should be raised on RH's side, I will still try to check internally if they have any more leads for the fix. 


We will get back to you as soon as we've heard form them but no later than 2-4 business days.


Hoping for your kind patience. 


Best regards,

Crisselle C

Intel® Customer Support


CrisselleF_C_Intel
Moderator
429 Views

Hello bkwon1,


Thank you for the patience.


Since this is an OS issue, we have been informed that you should continue working with RH for update information.


Please see below for further information about the issue from our engineering team:

It was found to be a RedHat issue when they apply patches to the open-lldp source tree.

The http://open-lldp.org/ tree is patched with out-of-tree patches while RHEL builds the lldpad rpm. This is a part of a standard build procedure.

The patch that causes a regression is:

Patch25:  open-lldp-v1.0.1-25-l2_linux_packet-correctly-process-return-value-of-ge.patch


You could build from the open-lldp.org source and test that as well.


We sincerely apologize for any inconvenience that this might have cause. Please do not hesitate 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 within 3 business days, please be advised that we will proceed with ticket closure. 


Best regards,

Crisselle C

Intel® Customer Support


CrisselleF_C_Intel
Moderator
408 Views

Hello bkwon1,


Good day!


Since you have accepted our answer as solution, we will now proceed with ticket closure. Thank you for your time and cooperation throughout the process. Should you have any other concerns or assistance needed in the future, feel free to contact us and we will be glad to be of help.


Thank you for continuing to use of Intel products!


Best regards,

Crisselle C

Intel® Customer Support


Reply