SR OS supports EVPN Layer-2 multicast as described in the EVPN IGMP/MLD Proxy specification draft-ietf-bess-evpn-igmp-mld-proxy. When this is enabled in a VPLS service with active IGMP or MLD snooping, IGMP or MLD messages are no longer sent to EVPN destinations. SMET routes (EVPN routes type 6) are advertised instead, so that the interest in a specific (S,G) can be signaled to the rest of the PEs attached to the same VPLS (also known as a Broadcast Domain (BD)). See Figure: SMET routes replace IGMP/MLD reports.
A VPLS service supporting EVPN-based proxy-IGMP/MLD functionality is configured as follows:
vpls 1 name "evi-1" customer 1 create
bgp
exit
bgp-evpn
evi 1
sel-mcast-advertisement
vxlan
shutdown
exit
mpls
auto-bind-tunnel
resolution any
exit
no shutdown
exit
exit
igmp/mld-snooping
evpn-proxy
no shutdown
exit
sap lag-1:101 create
igmp-snooping
send-queries
exit
no shutdown
exit
Where:
The sel-mcast-advertisement command allows the advertisement of SMET routes.
The received SMET routes are processed regardless of the command.
The evpn-proxy command in either the igmp-snooping or mld-snooping contexts:
triggers an IMET route update with the multicast flags EC and the proxy bits set. The multicast flags extended community carries a flag for IGMP proxy, that is set if igmp-snooping>evpn-proxy no shutdown is configured. Similarly, the MLD proxy flag is set if mld-snooping>evpn-proxy no shutdown is configured.
no longer turns EVPN MPLS into an mrouter port, when used in EVPN MPLS service
enables EVPN proxy (IGMP or MLD snooping must be shutdown)
When the VPLS service is configured as an EVPN proxy service, IGMP or MLD queries or reports are no longer forwarded to EVPN destinations of PEs that support EVPN proxy. The reports are also no longer processed when received from PEs that support EVPN proxy.
The IGMP or MLD snooping function works in the following manner when the evpn-proxy command is enabled:
IGMP or MLD works in proxy mode despite its configuration as IGMP or MLD snooping.
Received IGMP or MLD join or leave messages on SAP or SDP bindings are processed by the proxy database to summarize the IGMP or MLD state in the service based on the group joined (each join for a group lists all sources to join). The proxy database can be displayed as follows.
# show service id 4000 igmp-snooping proxy-db =============================================================================== IGMP Snooping Proxy-reporting DB for service 4000 =============================================================================== Group Address Mode Up Time Num Sources ------------------------------------------------------------------------------- 239.0.0.1 exclude 0d 00:53:00 0 239.0.0.2 include 0d 00:53:01 1 ------------------------------------------------------------------------------- Number of groups: 2 ===============================================================================When evpn-proxy is enabled, an additional EVPN proxy database is created to hand the version flags over to BGP and generate the SMET routes with the proper IGMP or MLD version flags. This EVPN proxy database is populated with local reports received on SAP or SDP binds but not with received SMET routes (the regular proxy database includes reports from SMETs too, without the version). The EVPN proxy database can be displayed as follows:
# show service id 4000 igmp-snooping evpn-proxy-db =============================================================================== IGMP Snooping Evpn-Proxy-reporting DB for service 4000 =============================================================================== Group Address Mode Up Time Num Sources V1 V2 V3 ------------------------------------------------------------------------------- 239.0.0.1 exclude 0d 00:53:55 0 V3 239.0.0.2 include 0d 00:53:55 1 V3 ------------------------------------------------------------------------------- Number of groups: 2 ===============================================================================The EVPN proxy database or proxy database process IGMP or MLD reports as follows:
The EVPN proxy database result is communicated to the EVPN layer so that the corresponding SMET routes and flags are sent to the BGP peers. If multiple versions exist on the EVPN proxy database, multiple flags are set in the SMET routes.
The regular proxy database result is conveyed to the local mrouter ports on SAP or SDP binds by IGMP or MLD reports and they are never sent to EVPN destinations of PEs with evpn-proxy configured.
IGMP or MLD messages received on local SAP or SDP bind mrouter ports (which have a default *.* entry) and queries are not processed by the proxy database. Instead, they are forwarded to local SAP or SDP binds but never to EVPN destinations of PEs with evpn-proxy configured (they are, however, still sent to non-EVPN proxy PEs).
IGMP or MLD reports or queries are not received from EVPN PEs with evpn-proxy configured, but they are received and processed from EVPN PEs with no evpn-proxy configured. A PE determines if a specified remote PE, in the same BD, supports EVPN proxy based on the received igmp-proxy and mld-proxy flags along with the IMET routes.
The Layer-2 MFIB OIF list for an (S,G) is built out of the local IGMP or MLD reports and remote SMET routes.
For backwards compatibility, PEs that advertise IMET routes without the multicast flags EC or with the EC but without the proxy bit set, are considered as mrouters. For example, its EVPN binds are added to all OIF lists and reports are sent to them.
Even if MLD snooping is shut down and only IGMP snooping is enabled, the MFIB shows the EVPN binds added to *,* for MAC scope. If MLD snooping is enabled, the EVPN binds are not added as mrouter ports for MAC scope.
When SMET routes are received for a specific (S,G), the corresponding reports are sent to local SAP or SDP binds connected to queriers. The report version is set based on the local version of the querier.
The IGMP or MLD EVPN proxy functionality is supported in VPLS services with EVPN-VXLAN or EVPN-MPLS, and along with ingress replication or mLDP provider-tunnel trees.
In addition, EVPN proxy VPLS services support EVPN multihoming with multicast state synchronization using EVPN routes type 7 and 8. No additional command is needed to trigger the advertisement and processing of the multicast synch routes. In VPLS services, BGP sync routes are advertised or processed whenever the evpn-proxy command is enabled and there is a local Ethernet segment in the service. See EVPN OISM and multihoming for more information about the EVPN multicast synchronization routes and state synchronization in Ethernet segments.