hi, my rb433 has last update.
as you can see in attached image.we have about 9mb/s unknown load;disabling the address of interface has no effect.
please see attachment

Hi
http://www.speedguide.net/port.php?port=5200
http://www.speedguide.net/port.php?port=37083

there is not an explicit info, you can drop it with firewall and see what happens or what application or protocol stops working

Hi
http://www.speedguide.net/port.php?port=5200
http://www.speedguide.net/port.php?port=37083

there is not an explicit info, you can drop it with firewall and see what happens or what application or protocol stops working

tried this, no change. no packet on firewall role status tab.

both src and dst interfaces are on RB411 ? if not what device they are ??

both src and dst interfaces are on RB411 ? if not what device they are ??

yes.( rb433)

This is traffic that was destined from one host on the disabled IP network to another host on the same IP network. Disabling the IP address on the Mikrotik is not enough to take away that IP range, and not enough to stop the host from sending the packets- As long as the client device wants to send these packets, it can do so. What's interesting is that the Mikrotik is receiving them at the IP interface instead of simply bridging them to the destination host....

I also noticed that the IP address was associated with a hotspot - perhaps the source host of the traffic has the Mikrotik's MAC address stuck in its ARP cache as the holder of IP address 172.17.6.137 (which in a hotspot scenario is easily the case) - You need to find the device by its MAC address. Try making a quick packet capture with the sniffer tool and examining the packets to find the MAC of the sender - then track that down by using the Hosts list on the bridge or hotspot menus (or even the switch menu if your router has a hardware switch)

This is traffic that was destined from one host on the disabled IP network to another host on the same IP network. Disabling the IP address on the Mikrotik is not enough to take away that IP range, and not enough to stop the host from sending the packets- As long as the client device wants to send these packets, it can do so. What's interesting is that the Mikrotik is receiving them at the IP interface instead of simply bridging them to the destination host....

I also noticed that the IP address was associated with a hotspot - perhaps the source host of the traffic has the Mikrotik's MAC address stuck in its ARP cache as the holder of IP address 172.17.6.137 (which in a hotspot scenario is easily the case) - You need to find the device by its MAC address. Try making a quick packet capture with the sniffer tool and examining the packets to find the MAC of the sender - then track that down by using the Hosts list on the bridge or hotspot menus (or even the switch menu if your router has a hardware switch)

thank you for reply.ok i will do it. thank you again.

and now problem comes back. we have no ipv6 enabled device in our network. whats is this???? loop? what??
as you see RSTP is enabled.what is this fake traffic? 2nd print screen is for next router that connected to this router by lan cable.you can see fake traffic.

This is not a loop or "fake" traffic.

IPv6 addresses starting with fe80 are built in to every IPv6-enabled interface.
Two hosts that want to talk to each other using IPv6 can easily do so using these addresses, which are called "link-local" addresses.

Luckily, the link-local addresses contain the MAC address (unless the hosts are spoofing) of the conversation:
The dst address in the first row translates to MAC address 44:19:b7:1f:c7:0a
The dst address in the second row translates to MAC address c8:3a:35:14:7d:d8
The src addresses in those rows don't follow the EUI-64 standard (there's no ff:fe in the middle), which leads me to believe those are Windows machines because Windows doesn't use the EUI-64 version of its MAC address to generate link-local IPv6 addresses. Since you have IPv6 loaded in your router, you should easily be able to ping these hosts on IPv6 and look them up in the IPv6 Neighbors table (the IPv6 equivalent of ARP).

Be sure to specify the Interface when doing the ping, because fe80::/10 addresses exist on all interfaces at once, so you have to specify WHICH fe80:: network you want to test.

I suspect that there is some UPnP stuff going on and you have devices that are sharing files directly with each other - I suspect that someone has a media server attached to the wireless and is streaming from it.

we have no ipv6 enabled device in our network.

I recommend doing a quick packet capture instead. Torch can be a bit ambiguous (at least to me) as to which direction the packets are actually going and who is really the source/dst of the traffic.

I set up a test ping (and dropped it on the target so the traffic would be one way).

On the sending Mikrotik, torch shows the ping-to address as the SRC, and shows activity in the TX direction....
Yet on the receiving Mikrotik, The ping-to address shows up in torch as the DST and activity in the RX direction....

Given my playing around w/ torch and one-way pings, it would appear that the host sending the traffic is fe80::4619:b7ff:fe1f:c70a and it is located somewhere on ether1.
(I know this looks backwards but from my experiments, the RX/TX rate fields are always relative to the interface being torched, and I can't decide what makes the SRC/DST addresses decide which column to go into in the display, but I found that when receiving packets, the SRC address is the actual sender's IP. (when TX packets, the SRC is actually the destination in my experiments - weird)

Like I said - you can get definitive information by doing a packet sniffer on the same interface and examining the capture file in Wireshark.