Page 1 of 1

Problems with X520-DA2

Posted: Sun May 07, 2023 5:41 pm
by Luizfilipesl
Hi everyone!

Recently I bought an Intel X520-DA2 to put on my x86 server that is running RouterOs v7.8, because I was reaching the limit of 1GB on my ethernet interfaces.

Changed it up and I found some strange things going on:

I boot up RouterOs and the two interfaces were displaying, so far so good, then I notice that the L2MTU value of both 10gb interfaces were 0, I don't know if makes any difference but I found it strange because my other ethernet port has recognized the L2MTU value of 9200.

Moving on, I put traffic on those 2 10GB ports, it worked, but at some time, both ports stops responding, I have to disable and enable to make it work back.
I thought it may be the power supply from the computer that wasn't handling the power of the NIC, I changed it, and the problem still there.

Anyone have an idea of how I can fix this?

Re: Problems with X520-DA2

Posted: Fri May 12, 2023 10:52 am
by NathanA
My org uses X520-DA2 in some x86 routers, and other than a couple of quirks that I haven't gotten around to posting about yet, they have been working surprisingly well for us.

The concept of L2MTU is a RouterOS-specific thing, and has to be explicitly supported by the underlying driver for the interface. RouterOS includes many drivers for third-party network interfaces, but MikroTik does not necessarily go to the trouble of extending/modifying every driver they include from Linux for every third-party interface to support all custom RouterOS "extensions". In the case of interfaces such as the X520 whose drivers have no concept of "L2MTU", you should set normal MTU to be at minimum whatever you would need your minimum L2MTU to be.

I should mention that we are currently running X520 on RouterOS 6.49, bare-metal (not CHR). We have not experienced the lock-up/stopped responding issue you describe. So perhaps there is a RouterOS 7 specific problem there. Or if you are using CHR, perhaps there is an issue with your underlying VM hypervisor, and/or if you are exposing them to the RouterOS CHR guest with SR-IOV, perhaps there are certain bugs or issues related to that as well (either on the hardware, hypervisor, or RouterOS side). Since we run ours without virtualization, it's possible that we have simply avoided all of those issues (and with us being on ROS 6 still, which doesn't support SR-IOV anyway, we wouldn't have seen it if that is potentially a variable in the equation).

Re: Problems with X520-DA2

Posted: Sun Dec 03, 2023 10:07 pm
by PortalNET
Hi guys

it looks like i have the same problem, all the Fiber nics 10gbps, 40gbps inserted on the Mikrotik RoS 7.12.1 stable... have mtu 0..

so how raising MTU from 1500 to 1598 for example will increase the L2MTU if it still shows 0 ?

AS L2MTU its meant to use on VLANs, MPLS etc..

MTU vs L2MTU: L2MTU is for VLAN and MPLS headers and the MTU is for all remaining IP payload. This is not related only to L3 routing, but for L2 switching as well.

ACTUAL MTU: is read-only setting showing real MTU in case it is automatically decreased by the software. For example, on bridge interface Actual MTU is taken from the bridge port with the lowest MTU value

Re: Problems with X520-DA2

Posted: Mon Dec 11, 2023 12:48 am
by PortalNET
Hi guys

as an update i am also experiencing the same issue described on top... after few hours or days running the Port stops crashes and stops responding we are running RoS v7.12 stable with L6 license acquired from mikrotik..

We are running Dell R620 server with over 1K pppoe sessions.. and RX-drops and RX-ERRORS start increasing when reaching around 25k errors ports crashed...

i am running the server on bare metal with 1 of this cards


and 2 of this cards


and we also have 1 Mellanox MCX355 on other pci-e 3.0 slot which runs ok without any errors.. so i am starting to think something has changed on the new RoS v7 ? as the server is currently shutdown now and we have moved our pppoe users to the CCRs again i will make some testing tomorrow will try to pull out the cards and check the intel firmware on them to see if there is any upgrades available on intel firmware for the devices.. ATM downtime counting on the server which was supposed to be running to replace 3 ccrs