Open pmprado opened 6 months ago
To me it seems like a wrong input combination. If you only want an l2vlan, you should use that model instead. I think I would prefer the raise an error for SVIs without any IP/IPv6 addressing.
If you only want an l2vlan, you should use that model instead. Absolutely, but on this case I need the l2vlan on some switches and the svi on others. That's the use case that does not seem to be handled well on the filter. We can simply declare it unsupported then
This issue is stale because it has been open 90 days with no activity. The issue will be reviewed by a maintainer and may be closed
Enhancement summary
There are situations where a given switch is just serving as a transit for a VLAN that will have an SVI on another switch. When using
only_vlans_in_use: true
, AVD correctly handles L2 usage but assumes L3 is also used.This request is to have AVD understand when only the L2 part is being used and not create the L3 counterparts on those nodes.
Which component of AVD is impacted
eos_designs, eos_cli_config_gen
Use case example
please detail your use caseFor example, consider an endpoint that peers with the directly connected switch on SVI 120:
[Server 1.1.1.0/31]et1.120 === Et10[Switch SVI120 1.1.1.1/31]
Routing is being migrated before the server can be moved, so we have to extend the VLAN. The DCI connects to the Border Leaf, but the final switch where the server will be is ComputeLeaf01. Thus we extend it across the BL:
[Server 1.1.1.0/31]et1.120 === Et10[Switch VLAN120] === (DCI) === [Border Leaf VLAN120] === (EVPN) === [ComputeLeaf01 SVI120 1.1.1.1/31]
This works, but AVD sees VLAN120 on the BL and ends up creating SVI120 there as well. As there is no virtual address and no node-specific addresses, the SVI ends up being empty. Furthermore, the presence of the SVI brings the VRF up with all the route-maps and prefix-lists together.
Describe the solution you would like
To not have SVIs created without any applicable configuration - properly identifying when they were not called for To not have VRFs created without use To issue warnings and/or errors for those situations (L3 interface without L3 addresses detected/etc)
Describe alternatives you have considered
Tags is a good alternative that has been suggested by the AVD team, which I will validate. Still I believe the filter could be improved by this Feat request, potentially eliminating the simultaneous use of tags and the filter
Additional context
No response
Contributing Guide