Skip to content

Network Services

Introduction

Network Services provide an abstracted model to define VRFs, VLANs, SVIs, and L2/L3 services across your AVD fabric. Services are organized by tenants, allowing you to logically group network resources by organization, department, or application. AVD then generates the complete switch configuration including VLANs, VRFs, SVIs, VXLAN mappings, and BGP EVPN route targets.

This guide explains how to define tenants, VRFs, SVIs, L2 VLANs, and leverage filtering to control which services are deployed to specific devices.

When to Use Network Services

Network services define what gets transported across your fabric:

  • VRFs: Layer 3 routing domains
  • SVIs: Layer 3 interfaces for VLAN gateways
  • L2 VLANs: Pure Layer 2 VLANs
  • L3 Interfaces: Routed interfaces within VRFs

Concepts

tenants: A logical grouping of network services. Tenants provide abstraction above VRFs and VLANs, enabling multi-tenancy and service filtering.

vrfs: Virtual Routing and Forwarding instances within a tenant. Each VRF has its own routing table and can contain multiple SVIs and L3 interfaces.

svis: Switched Virtual Interfaces that provide Layer 3 gateway functionality for VLANs within a VRF.

l2vlans: Pure Layer 2 VLANs that are bridged across the VXLAN fabric without an SVI.

filter: Node-level settings that control which tenants, VRFs, and tags are deployed to specific devices.

svi_profiles: Reusable templates for common SVI settings.

Basic Network Services

The example shows a network services configuration which defines a tenant with VRFs and SVIs:

Network Services
---
tenants:
  - name: TENANT1 # (1)!
    mac_vrf_vni_base: 10000 # (2)!
    vrfs:
      - name: VRF_PRODUCTION
        vrf_vni: 100 # (3)!
        vtep_diagnostic: # (4)!
          loopback: 10
          loopback_ip_range: 10.255.10.0/27
        svis:
          - id: 100
            name: Production_App1
            ip_address_virtual: 10.100.100.1/24 # (5)!
            profile: HIGH_MTU # (6)!
            tags: [production, app_servers] # (7)!
          - id: 101
            name: Production_DB
            ip_address_virtual: 10.100.101.1/24
            profile: HIGH_MTU
            tags: [production, app_servers]

      - name: VRF_DEVELOPMENT
        vrf_vni: 200
        svis:
          - id: 200
            name: Dev_App1
            enabled: true
            ip_address_virtual: 10.200.100.1/24
            tags: [development]

    l2vlans: # (8)!
      - id: 3401
        name: L2_VLAN3401
      - id: 3402
        name: L2_VLAN3402
  1. Tenant name used for grouping and filtering
  2. Base VNI for MAC-VRFs - VLAN ID is added to this value (VLAN 100 = VNI 10100)
  3. VRF VNI used for L3 VNI in EVPN Type-5 routes
  4. VTEP diagnostic creates a loopback for troubleshooting connectivity
  5. Virtual IP address shared across all leaf switches (anycast gateway)
  6. SVI profile applied to services that share common settings (enabled, mtu, etc.)
  7. Tags can be assigned to network services to control which devices receive the configuration.
  8. L2 VLANs are bridged across VXLAN without an SVI

SVI Profiles

Use SVI profiles to share common settings across multiple SVIs, reducing duplication and ensuring consistency.

SVI Profiles
---
svi_profiles: # (1)!
  - profile: STANDARD_SVI
    enabled: true

  - profile: HIGH_MTU
    parent_profile: STANDARD_SVI # (2)!
    mtu: 9000
  1. Define reusable SVI configurations
  2. Profiles can inherit from parent profiles for layered configuration

Note

We see the HIGH_MTU profile applied to the SVIs in the generated configuration above.

Generated Configuration

AVD generates the complete configuration including VLANs, VRFs, and SVIs:

VLAN, VRF, and SVI Configuration
vlan 100
   name Production_App1
!
vlan 101
   name Production_DB
!
vlan 200
   name Dev_App1
!
vlan 3401
   name L2_VLAN3401
!
vlan 3402
   name L2_VLAN3402
!
vrf instance VRF_PRODUCTION
!
vrf instance VRF_DEVELOPMENT
!
interface Vlan100
   description Production_App1
   no shutdown
   mtu 9000
   vrf VRF_PRODUCTION
   ip address virtual 10.100.100.1/24
!
interface Vlan101
   description Production_DB
   no shutdown
   mtu 9000
   vrf VRF_PRODUCTION
   ip address virtual 10.100.101.1/24
!
interface Vlan200
   description Dev_App1
   no shutdown
   vrf VRF_DEVELOPMENT
   ip address virtual 10.200.100.1/24
!

Filtering Network Services

Control which services are deployed to specific devices using the filter settings.

Note

By default, if no filter is defined, all network services are deployed to the device. You can use filter at different levels: node_types, node_groups, nodes, device_profiles and devices.

Filter Options Reference

Option Description Default
tenants Limit configured Network Services to those defined under these tenants. Also limits tenants included by always_include_vrfs_in_tenants. ['all']
tags Limit configured VLANs/SVIs to those matching the given tags. Tags are matched against the tags list on SVIs and L2VLANs. ['all']
allow_vrfs Limit configured Network Services to those defined under these VRFs. Also limits VRFs included by always_include_vrfs_in_tenants. ['all']
deny_vrfs Prevent configuration of Network Services defined under these VRFs. Takes precedence over all other filters. []
always_include_vrfs_in_tenants List of tenants where VRFs will be configured even if VLANs are not included in tags. Useful for L3 “border” leafs. []
only_vlans_in_use Only configure VLANs, SVIs, VRFs in use by connected endpoints or downstream L2 switches. false

Filter Precedence

deny_vrfs takes precedence over all other filters including allow_vrfs and always_include_vrfs_in_tenants. If a VRF is listed in deny_vrfs, it will never be configured on the device.

Dynamic Filtering with only_vlans_in_use

The only_vlans_in_use filter dynamically limits VLANs, SVIs, and VRFs to only those actually in use by connected endpoints or downstream L2 switches. This is useful for keeping switch configurations minimal and avoiding unused VLANs.

only_vlans_in_use Example
---
type: l2leaf

l2leaf:
  defaults:
    platform: vEOS-lab
    spanning_tree_mode: mstp
    spanning_tree_priority: 16384

  nodes:
    - name: htns-l2-leaf1
      id: 1
      mgmt_ip: 172.16.1.251/24
      uplink_switches: [htns-l3-leaf1]
      uplink_switch_interfaces: [ Ethernet8 ]
      uplink_interfaces: [Ethernet1]
      filter:
        only_vlans_in_use: true  # (1)!

servers:  # (2)!
  - name: webserver1
    adapters:
      - switches: [htns-l2-leaf1]
        switch_ports: [Ethernet2]
        endpoint_ports: [NIC1 ]
        vlans: 100-101
        mode: trunk
  1. Enable only_vlans_in_use to filter VLANs based on actual endpoint usage
  2. The server uses VLANs 100-101 on its trunk port - only these VLANs will be configured on htns-l2-leaf1

With this configuration, only VLANs that are actually in use by connected endpoints will be configured on the L2 leaf. Any VLANs defined in tenants but not used by endpoints will be excluded from the device configuration.

htns-leaf2 configuration
!
no enable password
no aaa root
!
username admin privilege 15 role network-admin nopassword
username arista privilege 15 role network-admin secret sha512 $6$Enl0WfE32FthwyiJ$yTyGaEJ2uPKLU.F7314YtB7J1jrzrMi7ogXIRTEHQfLdLgKWWmr1UvNlZLN6AyuxET7G5aH3AI9OYRzxVTkB1.
!
daemon TerminAttr
   exec /usr/bin/TerminAttr -cvaddr=192.168.1.12:9910 -cvauth=token,/tmp/token -cvvrf=MGMT -disableaaa -smashexcludes=ale,flexCounter,hardware,kni,pulse,strata -taillogs -cvsourceintf=Management1
   no shutdown
!
vlan internal order ascending range 1006 1199
!
transceiver qsfp default-mode 4x10G
!
service routing protocols model multi-agent
!
hostname htns-l2-leaf1
ip domain lookup vrf MGMT source-interface Management1
ip name-server vrf MGMT 192.168.1.1
!
spanning-tree mode mstp
spanning-tree mst 0 priority 16384
!
vlan 100
   name Production_App1
!
vlan 101
   name Production_DB
!
vrf instance MGMT
!
interface Port-Channel1
   description L2_HTNS_L3_LEAFS_Port-Channel8
   no shutdown
   switchport trunk allowed vlan 100-101
   switchport mode trunk
   switchport
!
interface Ethernet1
   description L2_htns-l3-leaf1_Ethernet8
   no shutdown
   channel-group 1 mode active
!
interface Ethernet2
   description SERVER_webserver1_NIC1
   no shutdown
   switchport trunk allowed vlan 100-101
   switchport mode trunk
   switchport
!
interface Management1
   description OOB_MANAGEMENT
   no shutdown
   vrf MGMT
   ip address 172.16.1.251/24
no ip routing vrf MGMT
!
ntp local-interface vrf MGMT Management1
ntp server vrf MGMT 0.pool.ntp.org prefer
!
end

Note

The only_vlans_in_use filter only considers configuration managed by eos_designs. It does not account for structured_config, custom_structured_configuration_, raw_eos_cli, eos_cli, custom templates, or configlets.

Filter with Tags

Filtering at the node level
---
type: l3leaf

l3leaf:
  defaults:
    platform: vEOS-lab
    loopback_ipv4_pool: 10.255.0.0/27
    loopback_ipv4_offset: 2
    vtep_loopback_ipv4_pool: 10.255.1.0/27
    mlag_peer_ipv4_pool: 10.255.1.64/27
    mlag_peer_l3_ipv4_pool: 10.255.1.96/27
    virtual_router_mac_address: 00:1c:73:00:00:99
    spanning_tree_priority: 4096
    spanning_tree_mode: mstp

  node_groups:
    - group: HTNS_L3_LEAFS
      bgp_as: 65101
      nodes:
        - name: htns-l3-leaf1
          id: 1
          mgmt_ip: 172.16.1.101/24
        - name: htns-l3-leaf2
          id: 2
          mgmt_ip: 172.16.1.102/24
          filter: # (1)!
            tenants: [TENANT1] # (2)!
            tags: [development] # (3)!
            allow_vrfs: [all] # (4)!
  1. Filter settings control which network services are deployed
  2. Limit to specific tenants, by default all tenants are included
  3. Filter SVIs and L2 VLANs by tags, by default all tags are included
  4. Filter which VRFs are deployed (use deny_vrfs to exclude specific VRFs), by default all VRFs are included

Using Tags for Granular Control

Earlier we saw SVI 200 is tagged with development, and the htns-l3-leaf2 is filtering on the development tag. Therefore, the htns-l3-leaf2 will only receive the VRF_DEVELOPMENT VRF and the SVI 200.

Services on htns-l3-leaf2
vlan 200
   name Dev_App1
!
vrf instance VRF_DEVELOPMENT
!
interface Vlan200
   description Dev_App1
   no shutdown
   vrf VRF_DEVELOPMENT
   ip address virtual 10.200.100.1/24
!

Since htns-l3-leaf1 is not filtering on tags, it receives all services defined for the TENANT1 tenant.

Services on htns-l3-leaf1
vlan 100
   name Production_App1
!
vlan 101
   name Production_DB
!
vlan 200
   name Dev_App1
!
vlan 3401
   name L2_VLAN3401
!
vlan 3402
   name L2_VLAN3402
!
vrf instance VRF_PRODUCTION
!
vrf instance VRF_DEVELOPMENT
!
interface Vlan100
   description Production_App1
   no shutdown
   mtu 9000
   vrf VRF_PRODUCTION
   ip address virtual 10.100.100.1/24
!
interface Vlan101
   description Production_DB
   no shutdown
   mtu 9000
   vrf VRF_PRODUCTION
   ip address virtual 10.100.101.1/24
!
interface Vlan200
   description Dev_App1
   no shutdown
   vrf VRF_DEVELOPMENT
   ip address virtual 10.200.100.1/24
!

Best Practices

  1. Organize by tenant: Group related services under logical tenants for easier management and filtering.

  2. Use SVI profiles: Define common settings once and apply to multiple SVIs for consistency.

  3. Leverage tags: Use tags to control service deployment at a granular level without creating complex tenant structures.

  4. Plan VNI allocation: Establish a consistent mac_vrf_vni_base strategy across tenants to avoid VNI conflicts.

  5. Use VTEP diagnostics: Enable vtep_diagnostic on VRFs for troubleshooting VXLAN connectivity.

  6. Document your tenants: Clearly document the purpose and scope of each tenant in your organization.

Troubleshooting

VLAN not appearing on device

Issue: A VLAN defined in network services is not configured on the device.

Solution:

  • Verify the tenant is included in filter.tenants on the node
  • Check that the SVI/L2VLAN tags match filter.tags on the node
  • Ensure the VRF is not excluded by filter.deny_vrfs

VRF not created

Issue: VRF is defined but not appearing in configuration.

Solution:

  • VRFs are only created if they have at least one SVI, L3 interface, or loopback on the device
  • Check that SVIs within the VRF pass the tag and tenant filters
  • Verify the node type has network_services.l3: true enabled

Duplicate VNI error

Issue: Error about duplicate or conflicting VNIs.

Solution:

  • Review mac_vrf_vni_base values across tenants to ensure VLANs don’t result in the same VNI
  • Check for vni_override settings that may conflict
  • Verify vrf_vni values are unique across all VRFs

SVI not getting virtual IP

Issue: SVI is created but missing the virtual IP address.

Solution:

  • Verify ip_virtual_router_mac_address is set at the fabric level
  • Check that ip_address_virtual is correctly specified on the SVI
  • Ensure the node type supports L3 network services (network_services.l3: true)

Reference

For complete details on all available properties, see: