Community discussions

 
User avatar
ScottReed
Member Candidate
Member Candidate
Topic Author
Posts: 111
Joined: Thu Sep 24, 2009 9:47 pm
Location: Montana / Western Massachusetts

Misplaced ARPs

Thu Jul 20, 2017 9:52 pm

CCR1072-1G-8S+
rOS 6.39.2

There is an ongoing ticket for this with Mikrotik but I thought I'd ask about it here too... I've masked the MACs and IPs for security purposes.
One of my upstream providers alerted me of my router sending out ARP requests for an IP in a subnet attached to a different interface.

Below are the log entries from their Arista switch:

06:04:33.264205 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 1.1.1.2 tell 2.2.2.1, length 46
06:04:59.074388 aa:aa:aa:aa:aa:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 1.1.1.2 tell 2.2.2.1, length 46

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?

Thoughts?

Thanks in advance.
 
idlemind
Forum Guru
Forum Guru
Posts: 1102
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: Misplaced ARPs

Thu Jul 20, 2017 10:02 pm

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?
/ip route export hide-sensitive
/ip firewall export hide-sensitive
 
User avatar
ScottReed
Member Candidate
Member Candidate
Topic Author
Posts: 111
Joined: Thu Sep 24, 2009 9:47 pm
Location: Montana / Western Massachusetts

Re: Misplaced ARPs

Fri Jul 21, 2017 3:36 pm

Any check-gateway statements in /ip route with the gateway IP set to the wrong IP for the interface?
I do not believe so. Here is the route export. IP's masked.

1.1.1.2 = gateway of ISP on sfp-sfpplus1
2.2.2.20 = gateway of ISP on sfp-sfpplus2
/ip route
add check-gateway=ping distance=1 gateway=1.1.1.2
add check-gateway=ping distance=2 gateway=2.2.2.20
add distance=1 dst-address=20.20.20.0/21 type=blackhole
To clarify a few things...

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?
I do not.
 
User avatar
ScottReed
Member Candidate
Member Candidate
Topic Author
Posts: 111
Joined: Thu Sep 24, 2009 9:47 pm
Location: Montana / Western Massachusetts

Re: Misplaced ARPs

Mon Sep 18, 2017 10:51 pm

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.
 
idlemind
Forum Guru
Forum Guru
Posts: 1102
Joined: Fri Mar 24, 2017 11:15 pm
Location: USA

Re: Misplaced ARPs

Mon Sep 18, 2017 11:03 pm

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?
 
R1CH
Forum Veteran
Forum Veteran
Posts: 904
Joined: Sun Oct 01, 2006 11:44 pm

Re: Misplaced ARPs

Tue Sep 19, 2017 1:33 am

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.
 
User avatar
ScottReed
Member Candidate
Member Candidate
Topic Author
Posts: 111
Joined: Thu Sep 24, 2009 9:47 pm
Location: Montana / Western Massachusetts

Re: Misplaced ARPs

Fri Oct 13, 2017 5:51 pm

Update.

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.

Who is online

Users browsing this forum: No registered users and 68 guests