Data traffic interruption with Ethernet errors

Hello, I have a particular problem that I would like to expose. The block of connectivity from customers is happening quite frequently.
Almost all of these customers are dual-technology (WiMAX + xDSL) with Cisco routers.
The antenna is always reachable.
The router is not reached by the antenna but the eth cable is UP and I see the MAC Address of the router in the bridging table.
In ALL the antennas I always find the "outerrors Count" ethernet counter with the value 1.

Entering the router from the xDSL, I see that the Fastethernet port is Up, often with some errors.

"CISCO#show int FastEthernet0/0
FastEthernet0/0 is up, line protocol is up
Hardware is Gt96k FE, address is 1c17.d328.XYXY (bia 1c17.d328.XYXY)
Internet address is [IP]/30
MTU 1500 bytes, BW 1900 Kbit/sec, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 03:05:24, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
342100713 packets input, 3692428404 bytes
Received 266545516 broadcasts (0 IP multicasts)
0 runts, 0 giants, 6 throttles
6 input errors, 1 CRC, 0 frame, 0 overrun, 5 ignored
0 watchdog
0 input packets with dribble condition detected
8973216 packets output, 2828873756 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
"

The ping at the point-to-point between the router and our access router, using the interface connected to the SM, fails.

The connection doesn't return to the antenna anymore until the ethernet goes down and up. This is by doing with shut / no shut from inside the Cisco or by restarting the antenna.

Dropping the antenna session from the AP the connection doesn't return when the antenna reconnects.

Mar 8 07:18:57: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor [IP] (FastEthernet0/0) is up: new adjacency
Mar 8 07:24:52: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor [IP] (FastEthernet0/0) is down: holding time expired
Mar 8 07:24:56: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor [IP] (FastEthernet0/0) is up: new adjacency
Mar 8 07:35:43: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor [IP] (FastEthernet0/0) is down: holding time expired
Mar 8 07:35:48: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor [IP] (FastEthernet0/0) is up: new adjacency
Mar 8 10:27:56: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor [IP] (FastEthernet0/0) is down: holding time expired

'conf t' 13:43:50 Mar 8 2018
'int FastEthernet0/0' 13:43:58 Mar 8 2018
'shut' 13:44:16 Mar 8 2018

Mar 8 13:44:16: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to down
'no shut' 13:44:17 Mar 8 2018
.Mar 8 13:44:18: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
.Mar 8 13:44:27: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor [IP] (FastEthernet0/0) is up: new adjacency

For now, this problem occurs only on Cisco (SM is in QinQ).

Cisco router where it happened:

- Cisco 1841

- Cisco 1801

- Cisco 1812

- Cisco 2811

It seems that the problem happens when there are some errors on the ethernet and the SM, for some reason, it doesn't work anymore as a bridg, blocks the traffic.

All the SM are, for now, PMP 450i with firmware 15.1.3

Has anyone else had similar problems recently?

PS: i have the engineering.cgi extrapolated before the shut/no shut if it were interesting ....

Hi There,

Not sure if you have resolved the issue, what I am getting is that whenever we connect the radio to a switch ( probably  layer 2) and then extend the LAN to a 3850 switch stack, the eigrp start flapping on the stack and RTO jumps to 5000 Q count start increasing and neighborship expires. We have tried many things including a Cisco TAC assistance but no 100 percent resolution yet.