RouterOS v6.x with Ubiquiti AirFiber 24 v2.0 - RX Error FCS

Have an AF 24 link running v2.0 firmware. Root end terminated at a CCR1016-12G on RouterOS v6.12. Remote end terminated at a RB1200 on RouterOS v6.7. Using stock PoE injectors. UBNT ToughCable all within distance spec. Grounded.

Since going to AF 24 v2.0 I’m seeing ridiculously high Rx FCS ERRORs and Rx CODE ERRORs on the interfaces of each router.

OSPF randomly drops out on the link and lately some customers have been complaining about intermittent connectivity. Not sure if this is related or not.

Anyone else having this problem?

Thanks,
Scott

If this was a result after only updating the Ubiquiti equipment, I would be contacting Ubiquiti support as it is possible they have introduced a problem.

OK, slightly updated information to share.

First of all, the CCR on v6.12 is logging hundreds of “fcs error on link” events. About one per minute.

The problem started on 4/24/14 when I upgraded the CCR from v6.7 to v6.12. To be exact, it started at 11:22 exactly one minute after I upgraded the router OS and router firmware.

We did the AirFiber 24 v2.0 upgrade on 4/15/14 and ran without any of these errors on RouterOS v6.7

I am only seeing these errors logged on the interface which the AirFiber is on.

We are seeing the exact same thing, with the AF24/CCR
but also with some older Trango licensed gear, and the CCR.

It’s not exclusive to the AF24, is what I’m trying to say.. The CCR is the common denominator.

Richard

Just out of curiosity what does speed and duplex look like on each side? High FCS errors most often are caused by duplex mismatch. If it was due to a code upgrade, maybe the autoneg algorithm broke?

@IPANetEngineer

The speed and duplex is matched at both ends using autonegotiation. I double checked to make sure the radios and the router interfaces are all 1000/FULL - and they are. There are no speed/duplex issues.

I downgraded both AirFibers to 1.5.

I continue to see one “FCS ERROR” per minute in the log of both routers.

@joregoldman

No, this was not a result of updating the UBNT gear. I should have made it clearer in my first post that the upgrade to v2.0 of each AirFiber occurred a few weeks before the router at the root end (the CCR) was updated from v6.7 to v6.12.

When the CCR was on v6.7 and the AirFibrs on v2.0, this issue was non-existent. It started with an upgrade to RouterOS v6.12

Thanks,
Scott

Hello,

Starting from ROS 6.11 there are changes related ethernet:

*) ethernet - added option to enable rx/tx flow control
(will be disabled by default);
*) ethernet - added ability to specify advertised modes for copper ports;

Maybe the CCR-s have some eth buffering problems? What about enabling flow control ?

Also check that you are using the latest bios on your CCR!!!

/system/routerboard/print

Aleksander

@sasskass

I am aware of the changes to ethernet.

I am running firmware v3.13 as of the day I upgraded the CCR to v6.12

I have enabled flow control on both the AirFibers and on the CCR. Doesn’t seem to help.

Thanks,
Scott

We are seeing the exact same thing. v6.12 and AF v2.0. Happening on both an internal ethernet port and
on an sfp port with a Planet ethernet SFP. Tried it with flow control disabled and enabled on both devices
with the same result.

The same here and this is certainly an ccr issue because we have one 1100ahx2 on the other end and no fcr errors.

Same issue with here but with a Titanium Rocket M5 plugged direct into ethernet port on CCR.
Getting FCS errors every so often - seems pretty random.

Not service affecting at the moment as far as we can tell but it is a little annoying.
No ethernet negotiation issues - 1Gbps-Full at both ends.

I might try upgrade to 6.13 but will have to be during the night.

@colinhowlin

Let me know what RouterOS v6.13 does for you. Also, if it has a new firmware upgrade in it too.

We get the FCS errors logged one a minute, both ends of the link.

CCR at root. RB1200 at remote.

Never saw these ever before until I upgraded the CCR to v6.12

Scott

I put a ubnt tough switch inbetween my tik and air fibre.
No more fcs errors on tik, but the tough switch reports rx errors on the port connected to the air fibre.

This is clearly an air fibre problem.
Have seen this on approx. 80% of all air fibre deployed.

My place: 3xAF24 v1.5 connected to CCR1016-12G running ROS 6.4. no FCS errors on every interface.
CCR is doing pppoe,bgp,queues pushing up to 400-450 mbps through these af24 links.

@tgrand

Interesting, but as @marcin21 points out, he has no problems with CCR on RouterOS v6.5.

My scenario is very similar to his, I was also pushing 400-450mbps and no FCS Errors while on RouterOS v6.7

My problem started after the upgrade to v6.12

I will be downgrading next Monday and will post results.

Scott

Sow how does it look after downgrade? Is it firmware related problem ?
Because I’m hesitating to upgrade AF to 2.x as it gives significant improvments.

RouterOS downgrade did not fix it.

I put a managed switch in between the AF 24 and the CCR. As stated by someone above, the switch begins to log errors on the port connected to the AF 24 and the issue is eliminated from the router.

I went back to UBNT support on this and am awaiting a reply.

This is basically not a Mikrotik issue or RouterOS issue as far as I’m concerned. I’m baffled as to why the upgrade to the CCR started the problem in the first place, but the truth is in the pudding once I installed that switch.

I’ll update this thread when I have more info.

Thanks, and please consider to upgrate to 6.15, also the BIOS [firmware]
BUT LEAVE 1200 TO 6.7!!!..

is there other RF equipment is on the same site ?

What type of cable used ?

Hi everybody, I’m currently having same issue here, FCS errors on RB750GL (on 6.15) port
with UBNT NS5 Loco (latest firmware and RF Armor shields) connected.
NS5 Loco is powered by PoE injector.

What I did so far without success:

  • replaced cable (tough cable) connectors
  • replaced cable by certified Cat.6
  • replaced RB750GL (also on 6.15)

I’m about to replace NS5Loco now and see…

By reading “other RF equipment”, would you count LNB from satellite dish as well?
I’ve mounted NS5Loco right on the same pole above the dish.
Could this be a possible source of the FCS errors caused by RF interference of LNB?

Interesting thing is: I have another shielded NS5Loco on same RB750GL other port, wired and powered same way.
No FCS errors at all. NS5Loco is “looking” in other direction behind dish.
Additionally a SXT is connected and powered same way, looking other direction - also no errors at all.

What do you think? Could LNB cause FCS errors?