I tried to examine the ARP traffic on the tunnel directly using "tcpdump -i em2 -vv -l | grep ARP".

ARP packets are travelling both raw, and wrapped by GRE, occurring every couple of seconds. It's hard to correlate them with individual requests.

Observations:

 * raw ARP requests only originate from IPs actually used in the instance tunnel network. Responses only return MAC addresses of physical interfaces attached to that network.

 * GRE wrapped ARP requests originate from existing virtual interface IPs, and are answered with MAC addresses of Neutron ports only, as long as I trigger resolutions of the tunnel IP address of the VMs own compute hosts.

 * The bogus MAC address  0e:bf:04:b7:ed:52 is never shipped on  tunnel interface em2, neither raw nor GRE wrapped. Even after wiping this address from the VMs ARP cache and forcing a fresh resolution with ping, resulting in the known bogus address again.

 * When triggering a fresh resolution of the IP address used by tunnel interface em2 on the other compute node, the whole cascade of excess ARP responses does appear in GRE wrapped ARP responses:

    14:34:17.883714 IP (tos 0x0, ttl 64, id 9402, offset 0, flags [DF], proto GRE (47), length 70)
        192.168.1.14 > 192.168.1.13: GREv0, Flags [key present], key=0x1e, length 50
            ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.13 tell 192.168.1.15, length 28
    14:34:17.883722 IP (tos 0x0, ttl 64, id 62059, offset 0, flags [DF], proto GRE (47), length 70)
        192.168.1.14 > 192.168.1.2: GREv0, Flags [key present], key=0x1e, length 50
            ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.13 tell 192.168.1.15, length 28
    14:34:17.884301 IP (tos 0x0, ttl 64, id 50179, offset 0, flags [DF], proto GRE (47), length 70)
        192.168.1.13 > 192.168.1.14: GREv0, Flags [key present], key=0x1e, length 50
            ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.13 is-at a6:b2:dc:d8:39:c1 (oui Unknown), length 28
    14:34:17.884331 IP (tos 0x0, ttl 64, id 50180, offset 0, flags [DF], proto GRE (47), length 70)
        192.168.1.13 > 192.168.1.14: GREv0, Flags [key present], key=0x1e, length 50
            ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.13 is-at 7e:d6:9b:cd:9d:2a (oui Unknown), length 28
    14:34:17.884339 IP (tos 0x0, ttl 64, id 50181, offset 0, flags [DF], proto GRE (47), length 70)
        192.168.1.13 > 192.168.1.14: GREv0, Flags [key present], key=0x1e, length 50
            ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.13 is-at 56:b2:1c:f7:d2:88 (oui Unknown), length 28
    14:34:17.884347 IP (tos 0x0, ttl 64, id 50182, offset 0, flags [DF], proto GRE (47), length 70)
        192.168.1.13 > 192.168.1.14: GREv0, Flags [key present], key=0x1e, length 50
            ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.13 is-at 16:6c:37:19:3e:3d (oui Unknown), length 28
    14:34:17.884355 IP (tos 0x0, ttl 64, id 50183, offset 0, flags [DF], proto GRE (47), length 70)
        192.168.1.13 > 192.168.1.14: GREv0, Flags [key present], key=0x1e, length 50
            ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.13 is-at 9e:b4:03:8e:74:cb (oui Unknown), length 28
    14:34:17.884362 IP (tos 0x0, ttl 64, id 50184, offset 0, flags [DF], proto GRE (47), length 70)
        192.168.1.13 > 192.168.1.14: GREv0, Flags [key present], key=0x1e, length 50
            ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.13 is-at f2:25:e2:0a:dc:e3 (oui Unknown), length 28

So far traffic on the tunnel interface em2 looks plausible to me. I can't see see it interfering, just shipping the bad messages as GRE carrier.