after we have replacer our older PC running on MK as central router, we have very strange problem.
We have replacer it with CCR1036-12G-4S.
the bridged network is connected to central router with Catalyst 3650x.
On switch there are downlink ports as protected port for customer port isolation.
Out biggest problem is that we can sometimes see comunication from other protected port when some customer downloads something.
I can se only customers download, upload not. It means only data that MK CCR sending to customers ip. But i cant understand how can i see TCP unicast comunication like as boradcast in whole network, also between protected ports.
If this happends a lot of MK Wireless links goes down. Most of them are NSTREME. In log message i can see someting like pooling timeout. After wireless link goes down, we cant scan any wireless network until we reboot mikrotik.
This broadcasting send 20-30 mbps but only for 1-3 sec long.i hapends 3-5 times per day. In each situation several nstreme links goes down. In most of time the same ones.
if you see unicast packets on other than expected interfaces then it means that the switch doesn’t know the destination MAC address (so it floods it to all interfaces except the one the packet arrived through)).
It can easily happen that gateway’s ARP record’s lives longer time than the MAC in switch forwarding database (5minutes usually). In normal case a device responds to the packets and then switch knows what interface it has to use next time to deliver the packet.
Have you any idea why it si happening only on new, replaced router?
We have some more routers in same broadcast domain in the same vlan and they works without any problem.
isnt ther any difference while we are talking about router without nat, only routing publis IPs?
I also found that my old PC router was v5.8 and new CCR runs on 6.32.1.
Is there any difference in arp/mac timing in these versions?
There maybe more reasons like different ARP table behavior on the routers - IMHO there is no way how to view all the entries in the cache on ROS (not the valid ones only).
If the traffic is directed to valid MAC (i.e. existing device which is not present in ‘show mac address-table’ sometimes) then I don’t know how to prevent the situation except changing either ARP timeout or MAC address table timeout. I thing decreasing ARP timeout is rather dangerous (and tricky way because at least on linux the ARP cache timeout is more complicated thing and timed out entries are still in cache an can be (re)used). Increasing MAC timeout on switch could be better but it can happen it will not solve the problem completely.
I was hunting some strange “broadcasts” (which were not showing on broadcast nor multicast packet counters) in rather large L2 segment behind linux router. On the end sniffed traffic showed that unicast traffic was appearing on improper ports just because the MAC table entry was missing for the MAC.