- The fabric underlay and overlay topology variables, define the elements related to build the L3 Leaf and Spine fabric.
- The following underlay routing protocols are supported:
- EBGP (default for l3ls-evpn)
- The following overlay routing protocols are supported:
- EBGP (default for l3ls-evpn)
- IBGP (only with OSPF or ISIS variants in underlay)
- Only summary network addresses need to be defined. IP addresses are then assigned to each node, based on its unique device id.
- To view IP address allocation and consumption, a summary is provided in the auto-generated fabric documentation in Markdown and CSV format.
*Only supported with core_interfaces data model.
** For use with design type “l2ls” or other designs where there is no requirement for a routing protocol for underlay and/or overlay on l3 devices.
Flagging a Device as Not Deployed¶
It is possible to provision configurations for a complete topology but flag devices as undeployed using the host level variable
- By default, this will have no impact within the
eos_designsrole. Configs will still be generated by the
eos_cli_config_genrole and will still be pushed by the
eos_config_deploy_eapidirectly to devices if used.
- However, if the
eos_config_deploy_cvprole is used to push configurations, CloudVision will ignore the devices flagged as
is_deployed: falseand not attempt to configure them.
- If the device is not present in the network due to CloudVision not configuring the device,
eos_validate_staterole will fail tests on peers of the undeployed device trying to verify that interfaces are up.
- To overcome this and shutdown interfaces towards undeployed peers, the variable
shutdown_interfaces_towards_undeployed_peerscan be used, satisfying the
eos_validate_staterole interface tests. Again, this is only an issue if
eos_config_deploy_cvpis used and the devices are not present in the network.
Variables and Options:¶
Note: The variables should be applied to all devices in the fabric.
# Shutdown interfaces on devices that face undeployed peers. See above for explanation and how this interacts with host level variable "is_deployed". shutdown_interfaces_towards_undeployed_peers: < true | false | default -> false > # Underlay routing protocol | Required. underlay_routing_protocol: < EBGP | OSPF | ISIS | ISIS-SR | ISIS-LDP | ISIS-SR-LDP | OSPF-LDP | none | default for l3ls-evpn -> EBGP > overlay_routing_protocol: < EBGP | IBGP | none | default for l3ls-evpn -> EBGP > # Point to Point Underlay with RFC 5549(eBGP), i.e. IPv6 Unnumbered. # Requires "underlay_routing_protocol: EBGP" underlay_rfc5549: < true | false | default -> false > # Enable RFC 5549(iBGP) i.e. IPv6 Unnumbered for MLAG iBGP connections. # Requires "underlay_rfc5549: true" overlay_mlag_rfc5549: < true | false | default -> false > # Enable IPv6 Address Family on underlay. # This feature allows IPv6 underlay routing protocol with RFC5549 addresses to be used along with IPv4 advertisements as VXLAN tunnel endpoints. # Requires "underlay_rfc5549: true" and "loopback_ipv6_pool" under the "Fabric Topology" underlay_ipv6: < true | false | default -> false > # Underlay OSFP | Required when < underlay_routing_protocol > == OSPF variants underlay_ospf_process_id: < process_id | default -> 100 > underlay_ospf_area: < ospf_area | default -> 0.0.0.0 > underlay_ospf_max_lsa: < lsa | default -> 12000 > underlay_ospf_bfd_enable: < true | false | default -> false > # Underlay ISIS | Required when < underlay_routing_protocol > == ISIS variants isis_area_id: < isis area | default -> "49.0001" > # Additional underlay ISIS parameters | Optional. isis_default_is_type: < level-1-2, | level-1 | level-2 | default -> level-2 > isis_advertise_passive_only: < true | false | default -> false > underlay_isis_instance_name: < name | default -> "EVPN_UNDERLAY" for l3ls, "CORE" for mpls > # ISIS TI-LFA parameters | Optional. isis_ti_lfa: enabled: < true | false | default -> false > protection: < link | node > local_convergence_delay: < local_convergence_delay_in_ms | default -> 10000 > # AS number to use to configure overlay when < overlay_routing_protocol > == IBGP bgp_as: < AS number > # Point to Point Links MTU | Required. p2p_uplinks_mtu: < 0-9216 | default -> 9000 > # IP Address used as Virtual VTEP. Will be configured as secondary IP on loopback1 | Optional # This is only needed for centralized routing designs vtep_vvtep_ip: < IPv4_address/Mask > # Customizable overlay loopback description | Optional overlay_loopback_description: < description > # Enable overlay EVPN peering with IPv6 addresses | Optional # This feature depends on underlay_ipv6 variable. As of today, only RFC5549 is capable to transport IPv6 in the underlay. overlay_routing_protocol_address_family: < ipv4 | ipv6 | default -> ipv4 > # BGP multi-path | Optional bgp_maximum_paths: < number_of_max_paths | default -> 4 > bgp_ecmp: < number_of_ecmp_paths | default -> 4 > # EVPN ebgp-multihop | Optional # Default of 3, the recommended value for a 3 stage spine and leaf topology. # Set to a higher value to allow for very large and complex topologies. evpn_ebgp_multihop: < ebgp_multihop | default -> 3 > # EVPN GW ebgp-multihop | Optional # Default of 15, considering a large value to avoid BGP reachability issues in very complex DCI networks. # Adapt the value for your specific topology. evpn_ebgp_gateway_multihop: < ebgp_multihop | default -> 15 > # BGP peer group names and encrypted password | Optional # Leverage an Arista EOS switch to generate the encrypted password using the correct peer group name. # Note that the name of the peer groups use '-' instead of '_' in EOS configuration. bgp_peer_groups: # Old mixed case key "IPv4_UNDERLAY_PEERS" is supported for backward-compatibility ipv4_underlay_peers: name: < name of peer group | default -> IPv4-UNDERLAY-PEERS > password: "< encrypted password >" # Custom structured config added under router_bgp.peer_groups.<name> for eos_cli_config_gen structured_config: < dictionary > # Old mixed case key "MLAG_IPv4_UNDERLAY_PEER" is supported for backward-compatibility mlag_ipv4_underlay_peer: name: < name of peer group | default -> MLAG-IPv4-UNDERLAY-PEER > password: "< encrypted password >" # Custom structured config added under router_bgp.peer_groups.<name> for eos_cli_config_gen structured_config: < dictionary > # Old upper case key "EVPN_OVERLAY_PEERS" is supported for backward-compatibility evpn_overlay_peers: name: < name of peer group | default -> EVPN-OVERLAY-PEERS > password: "< encrypted password >" # Custom structured config added under router_bgp.peer_groups.<name> for eos_cli_config_gen structured_config: < dictionary > evpn_overlay_core: name: < name of peer group | default -> EVPN-OVERLAY-CORE > password: "< encrypted password >" # Custom structured config added under router_bgp.peer_groups.<name> for eos_cli_config_gen structured_config: < dictionary > # Enable vlan aware bundles for EVPN MAC-VRF | Required. # Old variable name vxlan_vlan_aware_bundles, supported for backward-compatibility. evpn_vlan_aware_bundles: < boolean | default -> false > # BFD Multihop tuning | Required. bfd_multihop: interval: < | default -> 300 > min_rx: < | default -> 300 > multiplier: < | default -> 3 > ## EVPN Host Flapping Settings evpn_hostflap_detection: # If set to false it will disable EVPN host-flap detection enabled: < true | false | default -> true > # Minimum number of MAC moves that indicate a MAC duplication issue threshold: < number | default -> 5 > # Time (in seconds) to detect a MAC duplication issue window: < seconds | default -> 180 > # Time (in seconds) to purge a MAC duplication issue expiry_timeout: < integer > # Enable Route Target Membership Constraint Address Family on EVPN overlay BGP peerings (Min. EOS 4.25.1F) # Requires use eBGP as overlay protocol. evpn_overlay_bgp_rtc: < true | false | default -> false > # Enable VPN import pruning (Min. EOS 4.24.2F) # The Route Target extended communities carried by incoming VPN paths will # be examined. If none of those Route Targets have been configured for import, # the path will be immediately discarded evpn_import_pruning: < true | false | default -> false > # Configure route-map on eBGP sessions towards route-servers, where prefixes with the peer's ASN in the AS Path are filtered away. # This is very useful in very large scale networks, where convergence will be quicker by not having to return all updates received # from Route-server-1 to Router-server-2 just for Route-server-2 to throw them away because of AS Path loop detection. evpn_prevent_readvertise_to_server : < true | false | default -> false > # Configure prefix for "short_esi" values | Optional evpn_short_esi_prefix: < string | default -> "0000:0000:" > # Optional IP subnet assigned to Inband Management SVI on l2leafs in default VRF. # Parent l3leafs will have SVI with "ip virtual-router" and host-route injection based on ARP. This allows all l3leafs to reuse the same subnet # SVI IP address will be assigned as follows: # virtual-router: <subnet> + 1 # l3leaf A : <subnet> + 2 (same IP on all l3leaf A) # l3leaf B : <subnet> + 3 (same IP on all l3leaf B) # l2leafs : <subnet> + 3 + <l2leaf id> # GW on l2leafs : <subnet> + 1 # Assign range larger than total l2leafs + 5 inband_management_subnet: < IPv4_network/Mask > # VLAN number assigned to Inband Management SVI on l2leafs in default VRF. # Optional - default -> 4092 inband_management_vlan: < vlan_id > # QOS Profile assigned on all infrastructure links | Optional p2p_uplinks_qos_profile: < qos_profile_name > # Enable PTP on all infrastructure links | Optional uplink_ptp: enable: < boolean | default -> false > # Enable Multicast in the underlay on all p2p uplink interfaces and mlag l3 peer interface. # Specifically PIM Sparse-Mode will be configured on all routed underlay interfaces. # No other configuration is added, so the underlay will only support Source-Specific Multicast (SSM) # The configuration is intended to be used as multicast underlay for EVPN OISM overlay underlay_multicast: < boolean | default -> false > # Enable Fabric to support EVPN Multicast # General Configuration required for EVPN Multicast. "evpn_l2_multicast" must also be configured under the Network Services (tenants). # Requires "underlay_multicast: true" and IGMP snooping enabled globally (default). # For MLAG devices Route Distinguisher must be unique since this feature will create multi-vtep configuration. # Warning !!! For Trident3 based platforms i.e 7050X3, 7300X3, 720XP and 722XP # The Following default platform setting will be configured: "platform trident forwarding-table partition flexible exact-match 16384 l2-shared 98304 l3-shared 131072" # All forwarding agents will be restarted when this configuration is applied. # You can tune the settings by overridding the default variable: "platform_settings[platforms].trident_forwarding_table_partition:" # Please contact an Arista representative for help with determining the appropriate values for your environment. evpn_multicast: < boolean | default -> false > # Disable IGMP snooping at fabric level. # If set to false, overrides per vlan settings. default_igmp_snooping_enabled: < boolean | default -> true > # Enable Trunk Group support across eos_designs | Optional # Warning: Because of the nature of the EOS Trunk Group feature, enabling this is "all or nothing". # *All* vlans and *all* trunks towards connected endpoints must be using trunk groups as well. # If trunk groups are not assigned to a trunk, no vlans will be enabled on that trunk. # See "Details on enable_trunk_groups" below before enabling this feature enable_trunk_groups: < true | false | default -> false > # Only Configure VLAN Trunk Groups used by local endpoints | Optional # A vlan can have many trunk_groups assigned. To avoid unneeded configuration changes on all leaf # switches when a new trunk group is added, this feature will only configure the vlan trunk groups # matched with local connected_endpoints. # See "Details on only_local_vlan_trunk_groups" below. # Requires "enable_trunk_groups: true" only_local_vlan_trunk_groups: < true | false | default -> false >
Enabling the use of trunk groups will change the behavior of several components in AVD.
- Requires Trunk Groups to be defined on all trunks towards connected endpoints
MLAG Trunk Group will be configured on all vlans on MLAG switches
- Use Trunk Groups for uplinks to L2 switches instead of “switchport trunk allow vlan” lists.
- On the parent switch a Trunk Group with the name of the L2 switch will be assigned on all vlans
that are allowed towards the L2 switch.
- The port-channel towards the L2 switch will be assigned to this trunk group only
UPLINK Trunk Group to all vlans on the L2 Switch and assign this to the uplink port-channel
While it is recommented for consistency to set
enable_trunk_groups for all devices in the fabric,
it can also be set in group_vars or host_vars since trunk-groups are only local to a switch.
Because of the nature of the EOS Trunk Group feature, enabling this is “all or nothing”. All vlans and all trunks towards connected endpoints must be using trunk groups as well. If trunk groups are not assigned to a trunk, no vlans will be enabled on that trunk.
Enabling this feature will prevent unneeded trunk groups from being configured on vlans.
Using the figure under Details on
enable_trunk_groups as basis
enabling with feature would remove the unmatched trunk groups like this: