Network Services:When a specific node is assigned while creating an SVI (centralized gateway for a subset of services), other leaf switches generate empty SVIs, leading to routing issues.

[Spandanaarista]

Issue Summary

This is for our existing customer when they tried to create an SVI local to border leaf switches and specified nodes with physical IPs and also an ip-virtual_router_addresses: it created empty SVIs on all other leaf switches, which cause actual traffic issues because of it. Once, we removed the empty SVI with eloborate tags, then it wroked.

While talking to Carl & Nathaniel Musser, we thought may be its better to deal with a bug/ or nechancement to the logic of allocating SVI when nodes are specified.

vrf: 
  - name: test
    svis:
      - id: 111
        name: xxxxxxxxxxx
        enabled: true
        profile: svi_l3_defaults
        ip_virtual_router_addresses:
          - 10.x.x.1
        nodes:
          - node: BL-1
            ip_address: 10.x.x.2/24
          - node: BL-2
            ip_address: 10.x.x.3/24

Config on BL-1:

interface Vlan111
   no shutdown
   no autostate
   vrf test
   ip address 10.x.x.2/24
   ip virtual-router address 10.x.x.1

Config on BL-2

interface Vlan111
   no shutdown
   no autostate
   vrf test
   ip address 10.x.x.3/24
   ip virtual-router address 10.x.x.1

Config on Leaf switch:

interface Vlan111
   no shutdown
   no autostate
   vrf test

Which component(s) of AVD impacted

eos_designs

How do you run AVD ?

Ansible CLI (with virtual-env or native python)

Steps to reproduce

While creating SVIs, please specify one node and see how the empty SVIs are created in other leaf switches.

Relevant log output

Contributing Guide

• I agree to follow this project's Code of Conduct

[Spandanaarista]

@nathanmusser @carlbuchmann

[ClausHolbechArista]

That would be a very breaking behavioral change. We will figure out a good way to support centralized routing for a subset of services, but it will not be exactly like this. Can we change the request here to be more about the scenario we need to support instead of how?

[Spandanaarista]

Agreed! Don't know what was I thinking...I will change it.

[nathanmusser]

Adding some context, or perhaps restating the problem for clarification.

Leafs are either L3 or L2. L3 leafs will create SVIs for all vlans even if there isn't an IP configured for that vlan for this node. There might be an obscure use case for this but in our case it breaks the centralized routing model for the vlan because the creation of the svi means we now have the virtual mac gobbling up DHCP requests and all other traffic destined for the gateway before they reach the gateway.

We can filter out the vlan using tags but now the node is not getting the L2 config for that vlan. So we have to invert the tag structure and replicate the vlan configuration as L2.

During discussions we felt like there were 2 possible solutions here. One is that leafs creating empty SVIs is probably a bug, and that understanding it's a potentially breaking change there could be a flag added to switch the behavior from create SVIs for all vlans to only create SVIs on vlans where there is a relevant L3 interface for a node.

The other solution would be to add a filtering mechanism to the nodes model that could leverage the existing tag feature to declare vlans you want to be L2 only. Enabling fine tuned and explicit control over a hybrid deployment like we have.