Juniper MX80 strange dst MAC address behavior

[Stanislaw <me () nek0 net>]

Today I was investigating strange unknown unicast traffic in LAN of IX 
which I operate. It was about 200 kbps of constant unknown unicast load.
Unknown unicast is a rare ocasion in IX LAN as participants MAC 
addresses are almost persistent.

I added a server in the vlan and started sniffing:
all the unicast was coming from one participant MAC. One of the frames:
XX:XX:XX:XX:ee:98 > 5e:5c:ab:31:c0:cb, ethertype IPv4 (0x0800), length 
1434: XX.XX.16.30.80 > XX.XX.76.137.41934: Flags [.], seq 
1619512599:1619513967, ack 3595347045, win 235, options [nop,nop,TS val 
3650267181 ecr 1841068329], length 1368: HTTP
Okay, destination MAC 5e:5c:ab:31:c0:cb isn't really in switches FDB 
table.

I looked up the routing table and figured out that router announcing the 
bestpath for XX.XX.76.137 has MAC 5e:5e:ab:31:c0:cb.

So customers sent a frame to: 5e:*5c*:ab:31:c0:cb
The right address should be : 5e:*5e*:ab:31:c0:cb

I tried next packet in dump, the same story:
customer sends to: *90*:c6:9a:*e5*:2f:c1
right mac is     : *b0*:c6:9a:*e4*:2f:c1

I converted differencing bytes to binary representation:
90: 10010000
b0: 10110000

e5: 11100101
e4: 11100100

I guess all the unknown unicast frames MAC addresses were having the 
same slightly difference from the right ones.

So the router in general works fine (it has several gigabits of traffic 
in the IX) but sometimes it changes one or two bits in frame's 
destination MAC address.
My guess it is caused by a large ARP table on customer's router. The 
router may have some tricky lookup algorithm preceding constant 
calculating speed over accuracy.
I called their NOC, they said it is Juniper MX80 and also confirmed that 
it has more than 4k ARPs.

Have anybody encountered with that kind of issue?