First-hop gateway module: data model

[ipspace]

@jbemmel wants to have "anycast gateway", as does Arista EOS (in EVPN/MPLS IRB environment), so let's get the ball rolling...

I'd like to have a generic first-hop gateway module that would deal with more than what we need for the next lab topology. It should support anycast gateways as well as VRRP, HSRP, GLBP...

First-hop gateways are obviously link-specific, so we'd mostly use link attributes with global- or node attribute specifying default behavior (like VRRP/HSRP priority).

You'd indicate that you want to have a non-trivial default gateway on a link with the gateway bool/dictionary specified on a link.

The gateway dictionary would have these attributes:

• protocol (global or link) -- anycast, vrrp, hsrp...
• id (global or link) -- the gateway IP address within the link prefix (integer, 1 = first address, -1 = last address)
• ipv4 (link) -- IPv4 address of the default gateway (usually calculated, but could be static)
• ipv6 (link) -- IPv6 address of the default gateway (no idea whether that works with anycast gateways, but we could have VRRPv3)
• stub (link) -- when present, indicates that the link is a stub link, disabling all routing protocols on the link (IGP as well as BGP). We need this to deal with anycast gateways that have no unicast address -- the attribute would be set automatically on links with gateway.protocol == 'anycast' and anycast.unicast not set to True.

For every supported FHRP the gateway dictionary could have additional protocol-specific attributes, for example:

• anycast.unicast (global or link, bool) -- configure unicast addresses together with anycast addresses. This would be resolved in the data model transformation phase -- without anycast.unicast, the IPv4/IPv6 addresses would be removed from nodes using the gateway module.

NOTE: we have to remove the IPv4/IPv6 addresses after the routing protocol configuration modules did their job, or the interfaces with first-hop gateways wouldn't be listed in the IGP as passive interfaces (and we'd get no subnets).

• anycast.mac (global or link) -- MAC address to use for anycast gateway. Some platforms support a single anycast MAC address, others might require a unique anycast MAC address per link. Based on my familiarity with Arista EOS, I will assume we will use global anycast MAC addresses, if that doesn't work for someone please let me know.

Anycast quirks

Some devices support anycast gateways only on EVPN-enabled VLANs. The only sane way to deal with this is to add the tests to device quirks.

Looking forward to your feedback @jbemmel @ssasso @petercrocker