Anycast gateway support and other extended IP addressing features

[jbemmel]

We've mentioned a potential 'gw' module before, but I'm thinking it may be easier to modify the addressing.py code and various initial scripts for platforms, without introducing a separate module (that users may forget to enable, requires separate scripts per platform, etc.)

• Add 'anycast_gateway' attribute to addressing pools - if True or int (offset), allocate an ipv4/ipv6 ip from each prefix and configure it as anycast gateway (on interfaces that enable it)
• Add anycast_ipv4 and anycast_ipv6 to vlans and interfaces (allow 'False' to disable picking up the gateway from an associated vlan and/or pool)
• Modify interface data structures:

interfaces:
- ifname: e1-1
  ip:
   v4:
   - address: 172.16.0.1/24  # Primary, anycast
     anycast: True
   - address: 10.0.0.1/24    # Secondary, same subnet or different
   v6: True  # LLA only

In other words, allow for multiple addresses per interface, one of which can be anycast. Platform support for this new addressing structure including anycast can be signaled through a device feature flag

Thoughts/objections? 1.4 feature candidate?

[ipspace]

Hard-coded anycast gateway is just one of the many ways of getting this job done, and even there different vendors use different tweaks. There's also VRRP/HSRP/GLBP... in active/standby or active/active configuration.

Then there's the question of where the gateway gets configured (all routers or some routers), whether it gets configured together with a node-specific IP address or not... I understand you're looking for a quick solution for your next use case, but this one isn't as easy as it looks ;)

However, I like the idea of potentially adding an attribute to the addressing pool so you don't have to configure it on every link.

[jbemmel]

Actually still part of my first use case - discovered that anycast gateways are required to make ARPs work on the destination IRB interface (likely has to do with the virtual gateway mac address not being defined).

I appreciate there are other ways of solving this problem, with variations between vendors (SR OS has 'passive VRRP' for example). I think those could be accommodated by the new ip data model as well, flagging individual addresses with various properties (in modules or core)

If you're not too opposed to it, I'd like to take a stab at it (possibly along with #455 if I find that carving out a gateway ip becomes too tedious)

[ipspace]

Anycast gateway implemented in #604. As for everything else: I'm not going to change the interface addressing structure. The time to have that discussion was a year ago ;)

I have no idea how to implement secondary IP addresses with the current data model, but I also don't care that much 🤷‍♂️