-
Notifications
You must be signed in to change notification settings - Fork 654
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support to configure interface virtual gateway #927
Conversation
fixes #919 |
Major YANG version changes in commit f704e13: |
Visualized YANG tree after change:
|
Compatibility Report for commit f704e13: |
I've always wondered, why does this have to be keyed under an ip address? At least for Arista, the VARP gateway address does not have to be under a physical address's subnet. |
Initially I shared the same thought, but I was particularly inclined towards the section in the documentation that mentions, "A virtual IP address may optionally be configured with a subnet." I also followed a similar approach to the implementation of VRRP. However, would be open to hear other suggestions as well. |
This is an IPv4 only feature: |
In the case of OC, I think it's precedent for this pattern. The OC pattern to configure an IP address related to an interface is to add it to a list under the /interfaces/interface/subinterfaces/subinterface/ipv[4,6]/addresses/address Other structures are possible but unless they have a functional difference that is not easily met using the existing pattern, then the existing pattern is preferred. Do you have a suggestion for another list or container to add the virtual-gateway IP addresses? @vsrx Is it helpful to specify which mac address should be used for the virtual gateway IP address? Do you need to include an option to configure the mac address too? Both referenced implementations have this as an option. |
Ah, thank you for the reference. The part where the documentation refers to configuring an IPv6 address - does this mean it gets nested to the prefix as opposed to the interface for IPv4?
|
No, the feature is only supported on IPv4 so IPv6 there would be no subnets available. So in general, a virtual IP with no subnet is just a host IP. e.g. |
Currently we baked the virtual gateway mac address into |
Yeah, as per my understanding - Arista only supports a single device level virtual mac address as opposed to interface level ones with Juniper. There is also a vrf level reference to the anycast-gateway-mac in |
With the proposed structure, it does not fully cover the existing implementation for Arista. VARP supports multiple virtual IP address on one interface and it is less restrictive as in the virtual IP not having to be under the physical subnet. One purpose of this feature being less restrictive is to save on IP address usage. My personal stance would be to place |
In some customer environments that are IPv4 constrained it is imperative to reduce IP address usage. |
IMO this is pretty close to VRRP feature and should follow similar structure. I understand the concern of IP conservation. Potentially we could have a compromise:
and have a bool to say virtual_address or something similar.
@rolandphung how does the flag virtual change the behavior of arista, I assume this lets switch tie ip address to virtual mac. Is the above tie equivalent of doing (arista doesn't seem to support override of mac or irb/vlan) or is there more to it than that?
|
I do agree that OC should support assigning a virtual-gateway address which is independent of whatever ip/subnet is currently configured. Here is one way which I think is what @vsattri is suggesting:
Regarding configuration of the mac address: One idea is OC could define a configuration per virtual IP, even if some implementations only support a single mac. An implementation could require the mac addresses to be the same for IP addresses with virtual-gateway set to true and return an error if different. While this isn't as explicit as having a leaf ref to a single instance of a "routing-mac" as proposed by Roland, it would allow a single model to exist which supports these two different behaviors. Example model:
I want to avoid having two OC modeled ways to configure the same feature in OC which are mutually exclusive across vendors. |
Just to visualize what OC would like in 2 cases: Notice proposing changing Arista as is with just virtual address no physical address would look like:
Juniper as is with physical + virtual would look like:
|
Small note,
This set of configuration is functionally different than the one describe above. I'm not too familiar with the underlying nuances of |
With this, it seems like we could go one step further to separate physical IPs from virtual-gateway IPs:
There doesn't seem like there is a need to have the VRRP configuration under the virtual address. (One can also argue that VRRP does not belong below the physical IP address with the way it's currently modeled. I think I'll raise a separate issue to discuss this) |
Agreed that "ip virtual-router address" and "ip address virtual" are two different features with their own use cases, unfortunately both of these do not fully support our use case. Our use case is quite simple (below is pseudoCLI):
interface should have unique ip address, and can respond with bia or system mac. |
@vsrx is going to fix the main issue text and scrap off |
Updated the initial comment. Will send a proposal to visualize the same. |
@vsrx Can you update the initial documentation link to https://www.arista.com/en/um-eos/eos-vxlan-configuration#xx1234730? |
Updated. Thank you! |
@rolandphung Are we good nesting the virtual gateway under the address as per the current proposal? Or do you have any other suggestions? |
Instead of a boolean of Also add Example tree:
Example config:
|
For IPv4, Arista has
This means that if we go this route there should be a The only thing I'm wary about when combining physical and virtual addresses in a modeling point of view is that it becomes much harder to provide additional configuration that is specific to one or the other. Also it means that all containers under physical addresses (like VRRP) will also be "configurable" for these virtual addresses which can be confusing. I think a separate container for virtual-gateway would be cleaner. |
Ah ok, if there are multiple attributes (>1) specific to virtual-gateway, then I am ok with adding a container for virtual-gateway if. Seems like there are possibly two so far: a virtual gw mac and the secondary attribute. Example model using a container with a list of virtual-gateway ip addresses:
|
Change Scope
Platform Implementations
Arista:
Juniper: