HELP !!!!! How to protect Router automatic Mac generate

In my router automatically mac address generating . I need forum help. please check the image.Automatically
00:00:00:00:00:00 mac address are comming in several ip address in which ip i am not using. Require urgent concern.
000.jpg

Someone on the Internet is scanning your network.
(it happens all day every day)

What you’re seeing in the ARP list is completely normal behavior. These entries are not MAC generations. There’s no need to panic.

What’s happening is that whenever a packet comes along whose destination IP is one of the host IPs that doesn’t exist on your LAN, the router doesn’t know that the host doesn’t exist - it just knows that it needs to learn the MAC address for the destination IP, so it sends an ARP request. Until an ARP reply is heard from the LAN, the router will use 00:00:00:00:00:00 as a place-holder MAC address. These un-answerd ARP requests will timeout very quickly.

Watch what happens when you remove one of your static ARP entries and then ping the host - you’ll see the same MAC address there, but with the ‘D’ flag (dynamic), which means that the router used ARP to learn the host’s MAC address.

If you want to prevent your router from sending ARP requests on this interface, then go into VLAN 5 interface configuration, and set arp = reply-only

This will stop the dynamic entries from forming, including hosts that really do have an IP address but aren’t in your ARP configuration as a static entry.

Hi I have the same problem on RB2011iL, several ports in the bridge. The client can not access until you clear the ARP table the MAC. RB at no extra rules.
Some idea ?
THX

I also faced this when I upgrade Router OS 6.33.5 and then this problem Occurred at my CCR 1009. After Downgrade at 6.33 now it looks ok.. After New Releases 6.34.1 and again I tried to upgrade my RB1100AHx2 I faced same issue and I go back to 6.33. It seems there is bug exist at new releases. Hope Mikrotik will solve this as early as possible.
2016-02-08.png

Hi,

I have the same issue. Once you ping an ip IP that is invalid the router will add to the ARP table an entry with zeroes 00 00 00 00 00 00. Removing that entry manually does not help - the entries re-appear automatically and never expire. Only with a reboot they go away eventually to re-appear if someone attempts to access again invalid IPs.

Running CCR 1009 with version 6.34

This seems to be a problem in the latest releases

Does anyone have a solution?

Thanks

This isn’t a problem.

It’s just reflecting the fact that the router has tried to ARP for these IP addresses, but hasn’t received any replies.
Cisco does this too - it just gives the value of “incomplete”

R1#show ip arp f0/1
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  172.16.19.10            1   000c.2934.3e46  ARPA   FastEthernet0/1
Internet  172.16.19.1             -   ca01.3f78.0006  ARPA   FastEthernet0/1
Internet  172.16.19.21            0   Incomplete      ARPA  <----------------------------- here
Internet  172.16.19.100          12   000c.29fa.156b  ARPA   FastEthernet0/1

This has always been happening in the background - you just didn’t see it previously.
There is nothing wrong, so don’t panic.

The arp entries do not expire though

And i once had 10k entries because of a large subnet being scanned…

Make an option to at least not display those!

Display or not - they’re still in the router’s brain.

If you really really hate seeing them, then just use the filter at the top of the ARP List window-
arpfilter.png

Hi all,

I’m seeing the same weird behavior for addresses that are not part of the local subnets, and the IPs should be forwarded through the default gateway. The only thing that I think it’s important to be mentioned, is the source routing decision by the use of Mangle tables and route rules.

The only workaround found so far is to set ARP in “reply-only” mode and set a static MAC for the gateway of that interface. Still there are interesting behaviors on the ARP on other interfaces as seen in the picture.

I have the same issue on CCR1009-8G-1S-1S+ with RouterOS v6.34.1 on it. I see a lot of ARPs belonging to IP address space on the internet.
Yesterday I saw a bunch of logs saying I’ve hit max ARP table size and I should increase it.
ARP-bug.png
The ONLY subnet on ether6 is 172.16.4.104/29.

Thats exactly what i was trying to explain but some people seem to not understand that a big arp table helps no one

any news?
I’m having the same problem…

If you’re seeing public IPs in your ARP cache, it’s because whatever your default GW route is, it’s using the interface as the next hop, and not using the IP of the default GW router - this forces your Mikrotik to ARP for the IP address directly on the interface, and fortunately for you, your ISP is configured for proxy-arp or else you wouldn’t be reaching the Internet.

EDIT: Actually, whatever interface you’ve routed the default GW to is NOT sending ARP replies (or else you wouldn’t be seeing all zeros)

@zerobyte Thanks for the explanation. Please note that this subnet (/24) has a dynamic route as it is declared on the WAN interface. On my side ARP is enabled on the interface.
MikroTik automatically adds that dynamic route - what can i do?

@ZeroByte, you’re right and you’re not : )

It is true that in case you use an interface as a next-hop instead of IP address, router will try to resolve gateway’s MAC to build an ARP entry and to forward the packet, as defined in Ethernet.
But, in case you have proxy-arp on the other side of the link, you will see all ARP entries resolved to one MAC - proxied one. Which in our case is not like that, you are seeing INCOMPLETEs (zeroes) but packets are still forwarded.
On the other hand, you can reproduce this problem by implementing MPLS and forward traffic onto LSPs.
As you know, LSPs are not broadcast domains and they cannot give you any ARP reply…
So, after MikroTik have introduced “*) arp - show incomplete ARP entries;” in v6.33.5 ROS, i’m hitting max ARP table entries.

It is a workaround to increase max entries but not a solution.

Thanks @rememberme

As many have said incorrectly “it is ok do not worry about it” or even “filter it out” I have yet to see a routers arp table being larger to not being a problem :wink:

Yeah - I’d noticed that and added the little EDIT part noting that I’d noticed the difference. (whoops)

I’ve used proxy arp / interface-hops in some interesting ways myself…

I doubt that most of the people on this thread are in that boat… almost certainly it’s the result of some host doing a ping sweep / port scan of the network (which must either be blocked or tolerated), and/or an unusual routing configuration that leads to lots of ARPing where host-address-forwarding would clear things up.

Don’t be so rude, who knows who is silently reading this post and laughing : )

I think we should wait for an official resolution from MikroTik team, maybe we are missing something important and this is not a BUG but a feature. Isn’t it, MikroTik? ; )

I wasn’t being rude… or at least I wasn’t meaning to be anyway.

And fwiw, I think your situation is definitely one that is in the ‘bug’ category.

Indeed
because, when I create rules in firewall to have a log.
I see that ARP packets come into the router to an unknown destination with mac 00: 00: 00: 00: 00: 00.
Even if I put one second router in sequence with a sniffer I capture packets destined for 00: 00: 00: 00: 00 being sent by the router 1

I even think it is a service or application on your own mikrotik shooting these requests.

Certainly a bug.

sorry my English is bad :slight_smile: