aa:aa:aa:aa:aa:aa is the MAC address for sfp-sfpplus2 in IP subnet 2.2.2.0/23
1.1.1.2 is my other ISP’s gateway IP which is behind sfp-sfpplus1 in subnet 1.1.1.0/30
I thought this issue was resolved in 6.35? I’ve upgraded to 6.39.2. Same issue.
Support thought RSTP was to blame so I disabled it on my two bridge interfaces. Not sure how that would help but I tried and it didn’t resolve the problem. Neither of these two interfaces are in a bridge.
I statically configured all required ARP entries for both interfaces and set ARP to reply-only on both. This did not resolve the problem.
At this point I’m considering creating a bridge and throwing sfp-sfpplus2 in it. Then I can use bridge filter to try and filter the misplaced request?
Any check-gateway statements in /ip route with the gateway IP set to the wrong IP for the interface? Along the same lines, any policy routing in place that could be sending traffic destined for the IP of your other ISP out this interface?
sfp-sfpplus1 is connected directly to ISP 1. DIA circuit. I also do BGP with them. 2 peering sessions for full routes IPv4 and IPv6.
sfp-sfpplus2 is connected to an IX. I have 60 BGP peering sessions. 2.2.2.20 happens to be the IP of ISP 2 who hands me full routes IPv4 and IPv6.
Along the same lines, any policy routing in place that could be sending traffic destined for the IP of your other ISP out this interface?
This is still an ongoing issue with no resolution.
After many hours of troubleshooting, the “trigger” has been found to be caused by initiating a configuration export.
/export compact file=export
Without failure, every time the export is performed my upstream logs multiple misplaced ARPs. Mikrotik support confirmed that it most likely has to do with the export process exporting static entries in the routing table.
Since I have an automatic nightly export performed @ midnight MST, my upstream logs these occurrences during that time.
Initially, the packet sequence was basically two misplaced ARP requests from my router and two replies from another router at my upstream who had arp-proxy enabled. The total number of packets were four: 2x ARP Requests and 2x ARP Replies. The upstream would log two entries at their Arista.
Upon further investigation the upstream had the owner of the replying router disable arp-proxy. Now the packet sequence is basically six misplaced ARP requests from my router which go unanswered. The upstream now logs six entries at their Arista.
Crazy, thanks for the follow-up. A little disconcerting that the use of the /export command actually triggers packets being sent. Is this because of a check-gateway property in the route or MikroTik just does it?
Seems like a pretty serious design flaw somewhere if exporting the configuration can cause routing changes! Would love to know the root cause of this one.
Went in today and disabled check-gateway on both of my 0.0.0.0/0 default routes. Ran an export while sniffing traffic and sure enough the misplaced ARP requests went out again.
Proceeded to disable both the default routes. Again, ran the export while sniffing traffic and again I logged ARP requests. The interesting thing about these requests is that they are now looking for who has 0.0.0.0 instead of the IP of the other ISP’s gateway.
The final test was to remove the two disabled default route entries. I went ahead and removed them and ran the export again. Same results. Requests for who has 0.0.0.0
I adjusted my sniffer settings to include the other ISP’s interface just to see if I was requesting who has 0.0.0.0 that direction also. Negative.
I am completely stumped as to what the issue could be.