benjojo on Nostr: Hmmmm. "cool" feature of some IX's combined with some IX participants. First, find a ...

Hmmmm. "cool" feature of some IX's combined with some IX participants.
First, find a IX address that is not in use:

root@linx-ns:~# ping 195.66.231.230
PING 195.66.231.230 (195.66.231.230) 56(84) bytes of data.
^C
--- 195.66.231.230 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Then hard set it's neighbour mac address to something that is not on the IXP

root@linx-ns:~# ip neigh replace 195.66.231.230 lladdr de:ad:ad:dd:dd:dd dev enp129s0f0.700

Then set a destination route to go via the mac-address-that-does-not-exist

root@linx-ns:~# ip route add 9.9.9.9/32 via 195.66.231.230

and then ping it

root@linx-ns:~# ping 9.9.9.9
PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.
From 195.66.226.119: icmp_seq=1 Redirect Host(New nexthop: 195.66.225.238)
64 bytes from 9.9.9.9: icmp_seq=1 ttl=63 time=0.720 ms
64 bytes from 9.9.9.9: icmp_seq=1 ttl=63 time=0.756 ms (DUP!)
64 bytes from 9.9.9.9: icmp_seq=1 ttl=63 time=1.47 ms (DUP!)
^C
--- 9.9.9.9 ping statistics ---
1 packets transmitted, 1 received, +2 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.720/0.981/1.468/0.344 ms

:wow-horse: Cool right??
What is happening here is nuts on many different levels. To start, the non existent MAC address forces this IX (LINX) to treat any packets send to as "BUM" traffic, LINX could have prevented this by using static MAC like quite a lot of the other big ones do.
That however does not explain why we got ping responses... It turns out some routers on the peering LAN don't check if the destination MAC address for a packet is their own before forwarding the traffic! in this case 3 different LINX member routers saw my unknown unicast packet and was like "sure, why not, I'll route that!", and the packet routed all the way through to 9.9.9.9, and a response came back to me.
Mental!