aristanetworks / avd

Arista Validated Designs
https://avd.arista.com
Apache License 2.0
290 stars 210 forks source link

Multicast EVPN IRB/OISM Support #2031

Closed perimore closed 1 year ago

perimore commented 2 years ago

Enhancement summary

Support for EVPN Optimized Inter-Subnet Multicast Forwarding and Multicast EVPN Transit

Which component of AVD is impacted

eos_designs

Use case example

This enhancement will extend EVPN Multicast to support inter-subnet routing of multicast traffic within a tenant VRF, otherwise known as OISM.

OISM functionality and configuration is described in the document below:

https://www.arista.com/en/support/toi/eos-4-25-1f/14670-multicast-evpn-irb

Plus simple knob to enable transit as described below:

https://www.arista.com/en/support/toi/eos-4-26-2f/14832-multicast-evpn-transit

Describe the solution you would like

Providing the following are true at the fabric level:

underlay_multicast: true
evpn_multicast: true

The following can be enabled at the tenant level. But can imagine we will want control per VRF and/or per SVI as multicast is not always enabled on every VRF and VLAN.

tenants:
  Tenant_A:
    evpn_l3_multicast:
      enabled: < true | false >
      underlay_l3_multicast_group_ipv4_pool: < IPv4_address/Mask >
      underlay_l3_multicast_group_ipv4_pool_offset: < int >
      transit: <true | false --> default = False >

Assuming the below tenant config:

    vrfs:
      Tenant_A_OP_Zone:
        vrf_vni: 10
        vtep_diagnostic:
          loopback: 100
        svis:
          20:
            enabled: true
            ip_address_virtual: 192.168.20.0/24
          30:
            enabled: true
            ip_address_virtual: 192.168.30.0/24

The following config will be built:

interface Vlan20
   ip igmp  <-- enable IGMP
   pim ipv4 local-interface loopback100 <-- Loopback within the VRF, required if "ip address virtual" is used
!
!
interface Vlan30  <-- non VARP SVI
   ip igmp
!
!
interface Vxlan1
   vxlan vrf Tenant_A_OP_Zone multicast group 232.0.0.10 <-- derived from <underlay_l3_multicast_group_ipv4_pool + vrf_vni + underlay_l3_multicast_group_ipv4_pool_offset>
!
router multicast
   vrf Tenant_A_OP_Zone
      ipv4
         routing  <-- enable routing within the VRF
!
router bgp 65001
   vrf Tenant_A_OP_Zone
      evpn multicast  <-- enable EVPN OISM
         address-family ipv4
            transit <-- configure if transit = true

Describe alternatives you have considered

Control at the VRF or VNI level could be achieved with:

tenants:
  Tenant_A:
    evpn_l3_multicast:
      enabled: < true | false - Default -- False > Enable True if desired on every VRF and SVI in the Tenant. Otherwise enable per VRF or VLAN. See below.
      underlay_l3_multicast_group_ipv4_pool: < IPv4_address/Mask >
      underlay_l3_multicast_group_ipv4_pool_offset: < int >
    vrfs:
      Tenant_A_OP_Zone:
        evpn_l3_multicast: < true | false - Default --> False >  - Enable for all VLANs in the VRF
        vrf_vni: 10
        vtep_diagnostic:
          loopback: 100
        svis:
          20:
            enabled: true
            evpn_l3_multicast: < true | false - Default --> False >  - Enable/Disable only for the VLAN.
            ip_address_virtual: 192.168.20.0/24
          30:
            enabled: true
            ip_address_virtual: 192.168.30.0/24

Additional context

No response

Contributing Guide

ClausHolbechArista commented 2 years ago

@perimore the flood group is technically a separate feature right? So we can implement the two areas (IRB and flood group) seperately? I mean for all networks the flood group can be useful, even when not using IRB/OISM. Thanks.

perimore commented 2 years ago

@perimore the flood group is technically a separate feature right? So we can implement the two areas (IRB and flood group) seperately? I mean for all networks the flood group can be useful, even when not using IRB/OISM. Thanks.

Sure, separate feature below:

https://github.com/aristanetworks/ansible-avd/issues/2033