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.
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.
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.
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?
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
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!!!
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.
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.
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.
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.
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.