Add frr gateway support

[jbemmel]

There are still some issues to be solved:

/ # arping -I eth1 172.16.0.1 # VRRP VIP
ARPING 172.16.0.1 from 172.16.0.5 eth1
Unicast reply from 172.16.0.1 [aa:c1:ab:95:31:67] 0.022ms
Unicast reply from 172.16.0.1 [aa:c1:ab:69:50:ee] 0.030ms
Unicast reply from 172.16.0.1 [00:00:5e:00:01:01] 0.034ms
Unicast reply from 172.16.0.1 [00:00:5e:00:01:01] 0.012ms
Unicast reply from 172.16.0.1 [00:00:5e:00:01:01] 0.011ms
^CSent 3 probe(s) (1 broadcast(s))
Received 5 response(s) (0 request(s), 0 broadcast(s))
/ # arping -I eth1 172.16.0.3 # interface IP
ARPING 172.16.0.3 from 172.16.0.5 eth1
Unicast reply from 172.16.0.3 [aa:c1:ab:95:31:67] 0.006ms
Unicast reply from 172.16.0.3 [aa:c1:ab:95:31:67] 0.009ms
Unicast reply from 172.16.0.3 [aa:c1:ab:95:31:67] 0.010ms
^CSent 3 probe(s) (1 broadcast(s))

The above is the vrrp case, 3 different interfaces respond to ARP. For anycast I was able to remove 1 response, but ARP requests are still sourced from the wrong MAC

The PR creates a macvtap device on top of the Linux bridge for a vlan, in bridge mode. It could be that this model needs to be changed (the example at https://docs.frrouting.org/en/latest/vrrp.html uses a physical interface)

[ipspace]

Does "There are still some issues to be solved" mean "this should be a draft PR, wait with merging till I sort them out"?

[jbemmel]

Does "There are still some issues to be solved" mean "this should be a draft PR, wait with merging till I sort them out"?

I am sharing what I have in the hope that others could look at it and chime in. I've been pushing it forward, but it may very well be that there are better ways to do this