Add &#39;VARP&#39; as IP Role #10943

@PieterL75 commented on GitHub (Apr 8, 2025):

I can write the PR is needed

@PieterL75 commented on GitHub (Apr 8, 2025): I can write the PR is needed

adam commented

@bctiemann commented on GitHub (Apr 8, 2025):

Thanks @PieterL75 !

@bctiemann commented on GitHub (Apr 8, 2025): Thanks @PieterL75 !

adam commented

@pheus commented on GitHub (Apr 8, 2025):

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.

@pheus commented on GitHub (Apr 8, 2025): 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.

adam commented

@bctiemann commented on GitHub (Apr 8, 2025):

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

@bctiemann commented on GitHub (Apr 8, 2025): @PieterL75 what do you think about changing this to be a more vendor-agnostic name like the "Anycast" suggested?

adam commented

@PieterL75 commented on GitHub (Apr 8, 2025):

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

@PieterL75 commented on GitHub (Apr 8, 2025): 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

adam commented

@jeremystretch commented on GitHub (Apr 8, 2025):

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.

@jeremystretch commented on GitHub (Apr 8, 2025): 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.

adam commented

@pheus commented on GitHub (Apr 8, 2025):

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/

@pheus commented on GitHub (Apr 8, 2025): 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/

adam commented

@pheus commented on GitHub (Apr 8, 2025):

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.

@pheus commented on GitHub (Apr 8, 2025): 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.

adam commented

@PieterL75 commented on GitHub (Apr 8, 2025):

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

@PieterL75 commented on GitHub (Apr 8, 2025): 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**

adam commented

@pheus commented on GitHub (Apr 8, 2025):

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.

@pheus commented on GitHub (Apr 8, 2025): 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.

adam commented

@pheus commented on GitHub (Apr 9, 2025):

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!

@pheus commented on GitHub (Apr 9, 2025): I’d like to correct myself regarding my earlier statement about there being *"no standard"* term for this concept. [RFC 9135](https://datatracker.ietf.org/doc/html/rfc9135) (*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!

adam commented

@PieterL75 commented on GitHub (Apr 10, 2025):

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)

@PieterL75 commented on GitHub (Apr 10, 2025): 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)

adam commented

2025-12-29 21:38:07 +01:00

@pheus commented on GitHub (Apr 10, 2025):

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 commented on GitHub (Apr 10, 2025): 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!

adam commented

@PieterL75 commented on GitHub (Apr 13, 2025):

@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" ?

@PieterL75 commented on GitHub (Apr 13, 2025): @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" ?

adam commented

2025-12-29 21:38:07 +01:00

@pheus commented on GitHub (Apr 14, 2025):

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:

Name it EVPN Anycast Gateway.
Abbreviate it to something like EVPN AGW or EVPN Anycast GW for table views.
Allow user-defined roles through configuration.py.
(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.

@pheus commented on GitHub (Apr 14, 2025): 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.

adam commented

2025-12-29 21:38:07 +01:00

@DanSheps commented on GitHub (Apr 16, 2025):

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?

@DanSheps commented on GitHub (Apr 16, 2025): 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?

adam commented

2025-12-29 21:38:08 +01:00

@PieterL75 commented on GitHub (Apr 16, 2025):

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)

@PieterL75 commented on GitHub (Apr 16, 2025): > 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)

adam commented

2025-12-29 21:38:08 +01:00

@DanSheps commented on GitHub (Apr 17, 2025):

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.

@DanSheps commented on GitHub (Apr 17, 2025): > 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.

adam commented

@pheus commented on GitHub (Apr 24, 2025):

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.

@pheus commented on GitHub (Apr 24, 2025): > 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.

adam commented

@PieterL75 commented on GitHub (May 9, 2025):

I'll settle for "Anycast GW" in addition to the existing "Anycast" Role

@PieterL75 commented on GitHub (May 9, 2025): I'll settle for "Anycast GW" in addition to the existing "Anycast" Role

adam commented

@lodpp commented on GitHub (Jul 29, 2025):

Hello 😄

I wanted to follow up on this feature request.

From the comments on that particular issue, I see that VARP from Arista is discussed here as part of an EVPN fabric and so the more generic term of anycast GW can make sense.

However, VARP is not used only in an EVPN context. The most basic usage of VARP is to be used as a FHRP like glbp/hsrp/vrrp, just way simpler to implement in configuration.

I would even argue that most of the deployment of VARP I've seen were not related to EVPN at all.

All this to say:
Creating an IP role VARP makes sense, like the other FHRP entries.

Thanks !

@lodpp commented on GitHub (Jul 29, 2025): Hello 😄 I wanted to follow up on this feature request. From the comments on that particular issue, I see that VARP from Arista is discussed here as part of an EVPN fabric and so the more generic term of `anycast GW` can make sense. However, VARP is not used *only* in an EVPN context. The most basic usage of VARP is to be used as a FHRP like glbp/hsrp/vrrp, just way simpler to implement in configuration. I would even argue that most of the deployment of VARP I've seen were not related to EVPN at all. All this to say: Creating an IP role VARP makes sense, like the other FHRP entries. Thanks !

adam commented