What is the distinction between VARP and the existing VIP role?

a VIP is a 'floating' ip, active on one device of a cluster, and mainly referred to for load balancers.

a VARP is an IP that is active on multiple devices at the same time. There are no node-ips like with VRRP, only the VARP ip on the devices.
https://arista.my.site.com/AristaCommunity/s/article/active-active-router-redundancy-using-varp

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

I can write the PR is needed

Thanks @PieterL75 !

Thank you for the proposal. I have some reservations about adding a VARP role. It seems that VARP is an Arista-specific term for what is essentially an anycast gateway, as noted in the linked reference. Since we already have an “Anycast” IP role, it might be more consistent to stick with the existing, vendor-neutral nomenclature. While we could consider adding an “Anycast Gateway” role if needed, I believe it’s best to avoid vendor-specific names to prevent potential confusion.

@PieterL75 what do you think about changing this to be a more vendor-agnostic name like the "Anycast" suggested?

I checked 3 vendors on how they name the EVPN distributed router gateway intefaces:

• Cisco : Anycast gateway or Bridge Virtual Interface (BVI)
• Arista: Virtual-ARP (VARP)
• Juniper: IRB virtual gateway IP address (anycast)

I would like to keep the difference clear between a BGP Anycast IP (one IP living on multiple locations, announced over BGP)
and an ARP/VirtualMAC based EVPN Gateway.

What about EVPN VirtualIP, as this will be mainly seen in EVPN deployments

I can't recall ever hearing the term "anycast" used with regard to local segment first-hop routing; as suggested, I'd avoid using it here.

I agree that it might be a good idea to differentiate between the “classical” anycast IP address and the first-hop IP address in a BGP EVPN VXLAN fabric. However, the more common term—even though no standard has been established—is "distributed IP anycast gateway." Keep in mind that in a layer 3/routed underlay, the first-hop IP address is distributed via BGP (in the case of a BGP EVPN VXLAN fabric). In fact, even the link provided by the author refers to an "anycast gateway." A quick search for "anycast gateway" reveals multiple discussions regarding BGP EVPN VXLAN fabrics, reinforcing that this term is widely used in practice.

Personally, I would suggest going with "Anycast Gateway" for clarity and consistency.

Of course, as the lead maintainer does have the final say, this perspective should be considered alongside the broader community's usage.

There are IETF documents that reference this concept:
https://datatracker.ietf.org/doc/rfc9135/
https://datatracker.ietf.org/doc/draft-malhotra-bess-evpn-centralized-anycast-gw/

I'd like to highlight why the term "Anycast Gateway" makes complete sense. Consider a BGP EVPN VXLAN fabric, which often features a typical spine-leaf architecture in a data center. In this design, where a Layer 2 segment is extended over a Layer 3 underlay and multiple nodes share the same gateway IP address, it is very useful to route traffic at the nearest node holding that gateway IP address. This is exactly the kind of scenario that an anycast IP address is meant to address.

I disagree that the IP is distributed over BGP in an EVPN fabric and then used as a destination IP for the endhost.
The IP is made available to the endhosts via ARP and not BGP. That said...

I don't see this as an Anycast system, but rather a distributed ARP/layer2/IP

I would go for a less confusing EVPN VirtualIP or EVPN Virtual Gateway

But I think we do agree on the key aspect here: the same IP address exists multiple times within the same Layer 2 segment, distributed across multiple nodes. And only the node nearest to the source responds to the ARP request and routes the traffic.

To me, this behavior matches very well with the fundamental concept of an anycast IP.

That’s why I still feel Anycast Gateway is a fitting and commonly understood term for this scenario.

I’d like to correct myself regarding my earlier statement about there being "no standard" term for this concept.

RFC 9135 (Integrated Routing and Bridging in Ethernet VPN (EVPN)) actually refers to this as "anycast default gateway IP" (Section 4.1).

“All the PEs for a given tenant subnet use the same anycast default gateway IP and MAC addresses.”

This matches exactly the use case we’re discussing here: multiple nodes (PEs) within the same EVPN fabric using the same gateway IP address — effectively providing an anycast gateway for the connected hosts.

Reference: https://datatracker.ietf.org/doc/html/rfc9135#section-4.1

This further reinforces my opinion that Anycast Gateway (or Anycast Default Gateway) is an established and technically correct term in the context of EVPN.

Hope this helps clarify my position!

I do follow the reasoning that this is a gateway that is 'multiplied' and resembles the logic of Anycast.
But as Anycast is commonly known and used for BGP announced IP's on global scale, it could confuse when a Layer2 local gateway is also referred to as 'Anycast gateway'

let's add EVPN then..
EVPN Anycast Gateway
(Dont add Default, as you don't know if that IP is the default for a subnet or just 'a' gateway)

Thank you, @PieterL75, for taking the time to engage in this constructive discussion with me — I really appreciate the exchange of perspectives.

I absolutely understand where you’re coming from. While anycast is indeed often associated with globally routed IPs, I think it's great to see these concepts and technologies making their way into local fabrics as well.

Personally, I’m perfectly fine with EVPN Anycast Gateway and agree that leaving out Default makes sense here.

Looking forward to the final decision from the maintainers!

@pheus indeed, always nice to see different angles and perspectives to the same tech.

The only 'issue' I still have is the lengthy name, it will take up a lot of space in a table view
Should we short it to "EVPN AGW" ?

I thought about this, and I agree that the full name can get a bit lengthy in table views. While an abbreviation like AGW might work well for compact displays, it is not a common name, so users won't immediately know what it means. It would be ideal to retain the full name in the selection during the creation or editing of the IP role field.

Achieving this might require a change to the ChoiceSet implementation, which may not be something the maintainers are looking to address at this time. Perhaps a better approach would be to allow configuration of the ChoiceSet via configuration.py.

I see four possible options:

1. Name it EVPN Anycast Gateway.
2. Abbreviate it to something like EVPN AGW or EVPN Anycast GW for table views.
3. Allow user-defined roles through configuration.py.
4. (Probably not) Extend the ChoiceSet to support both a short and a verbose name.

A combination of options 2 and 3 is also possible, providing both a concise display in tables and the ability to adopt the full name where needed.

Question, for all those involved, based on the fact that the chosen standard would follow the RFC and be "Anycast Gateway"

Why is the current "Anycast" role insufficient?

Question, for all those involved, based on the fact that the chosen standard would follow the RFC and be "Anycast Gateway"

Why is the current "Anycast" role insufficient?

To differentiate between a BGP announced Anycast ip (which is a true layer 3 system) and an EVPN distributed/centralized gateway ip (which is a layer 2 solution)

To differentiate between a BGP announced Anycast ip (which is a true layer 3 system) and an EVPN distributed/centralized gateway ip (which is a layer 2 solution)

Not sure how I feel about this.

Presumable, your IP will be part of a prefix and that prefix will have a role denoting it as a BGP role, in which case you wouldn't need it. On the flip side, an IP will be assigned to a VLAN normally (or interface but interface wouldn't be as clear cut as a VLAN) where you would know that the role with "Anycast" means "Anycast Gateway" and not "Anycast BGP"

Not saying I am 100% against this, but I am also not sure if we want to add a new IP role just to cover this. Would like to hear some more thoughts on this.

Why is the current "Anycast" role insufficient?

Personally, I think "Anycast" would generally be sufficient, as I don't expect many NetBox users to use both classical (BGP-based) Anycast and EVPN Anycast Gateway functionality within the same environment - at least not to the extent that it would cause confusion.

That said, as I mentioned earlier, I do see the value in having an explicit "Anycast Gateway" role. As more network engineers begin adopting EVPN fabrics, this distinction becomes more relevant, and being explicit could help improve clarity and reduce ambiguity for future users.

Would something like "Anycast GW" strike a good balance? It keeps things concise for table views, while still being more descriptive than just "Anycast."

Alternatively (or additionally), maybe we should consider allowing configuration of the ChoiceSet - just as we do with other customizable options? That could offer both flexibility and clarity.