EVPN for multicast
This chapter describes EVPN for multicast on SR Linux.
IGMP/MLD snooping
IGMP snooping is enabled by configuring igmp-snooping admin-state enable under network-instance.protocols. The feature is supported on MAC-VRF network-instances with bridged subinterfaces and no IRBs.
The igmp-snooping model allows configuration of IGMP parameters at the
MAC-VRF network-instance level and specific configuration for individual interfaces. The
programming of the MFIB for the network-instance is enabled by the configuration of
network-instance.protocols.igmp-snooping.
IGMP snooping support in SR Linux includes the following:
- IGMP versions 1, 2, and 3 are supported.
- IGMP snooping is supported on network-instances of type mac-vrf.
- The following features are supported:
- Querier support, including timers and relevant parameters
- Trace options
- Mcast router support
- State for group memberships, queriers, and mcast routers
- Static membership groups configured under interfaces
- Statistics
- As soon as IGMP snooping is enabled on the MAC-VRF, the node starts snooping IGMP
messages on the interfaces added under
protocols.igmp-snooping, and starts programming the MFIB and proxying IGMP reports.The interfaces not configured under
protocols.igmp-snoopingbut that exist in the network-instance are considered mrouter ports by the IGMP snooping application. The state model shows the learned queriers, multicast routers, and proxy-membership-groups. - IGMP settings can be customized at the interface level. The state model shows the learned membership-groups on the interface, as well as the statistics.
- When originating reports from CPM, the system MAC is used.
MLD snooping is modeled after IGMP snooping (both are managed by IGMP manager), with MLD versions 1 and 2 supported. Similar to IGMP snooping, MLD snooping is enabled with the command mld-snooping admin-state enable.
IGMP/MLD snooping are supported on 7220 IXR-D series platforms.
EVPN multicast for Layer 2
This section describes EVPN multicast for Layer 2 on SR Linux.
IGMP/MLD proxies for EVPN (RFC 9251)
SR Linux supports IGMP/MLD proxies for EVPN networks, as described in RFC 9251.
When IGMP snooping and, or MLD snooping are enabled on a MAC-VRF, a multicast forwarding information base (MFIB) is created with entries for each (*,G) or (S,G) state that is snooped out of received IGMP/MLD reports. The result of that MFIB is advertised in EVPN Selective Multicast Ethernet Tag (SMET) routes, one route per (*,G)/(S,G) entry, as long as EVPN is enabled in the MAC-VRF.
The following summarizes what happens when both igmp/mld-snooping
and bgp-evpn are enabled:
- The router sends updates of the IMET routes for the MAC-VRF with the multicast flags EC signaling support for IGMP/MLD-proxy.
- The router collects information about the remote EVPN destinations that support iIGMP/MLD-proxy (based on the received IMET flags) and stops flooding IGMP reports to those destinations.
- The router also creates an EVPN proxy DB and sends the result in SMET routes.
- The router adds EVPN destinations as OIF (outgoing interfaces) in the MFIB based on the received SMET routes.
The SMET route (or EVPN route type 6) is described in RFC 9251 and conveys the
information about the multicast source and the multicast group IP addresses (for
IPv4 or IPv6) along with some flags. The flags indicate whether the proxy entry in
the MFIB was created using IGMP/MLDv2 or IGMPv3; in case of IGMPv3/MLDv2, the
Exclude flag (when set to 1) indicates if the source is
excluded.
On reception of an SMET route, IGMP/MLD reports are generated and sent to mrouter subinterfaces based on the IGMP/MLD version that is locally valid.
Integration of EVPN proxy and non-proxy routers
SR Linux supports the integration of EVPN multicast proxy-enabled and non-proxy routers in the same EVPN broadcast domain. As described in RFC 9251, each router where IGMP/MLD snooping is enabled advertises an IMET route along with the Multicast Flags EC. This EC is used by the router to indicate that it has enabled IGMP/MLD snooping for that MAC-VRF.
Upon reception of the IMET route, a PE considers that the originating PE supports the EVPN proxy behavior if and only if, the Multicast Flags EC is present and the proxy bit value is 1, else the originating PE is not considered as an EVPN proxy PE. This information is used for backwards compatibility with non-supporting proxy or non-upgraded PEs. The following considerations apply:
- On the egress PE (connected to receivers):
- If an egress PE supports EVPN multicast proxy, but does not have any interest in a given (x, G) (with x meaning source S or *), it advertises its IGMP proxy capability using this EC, but does not advertise any SMET route for that (x, G).
- On the ingress PE (connected to sources):
- When the PE receives an IMET advertisement with proxy support from the egress PE, it does not replicate the multicast traffic to that PE until a SMET route is received from it.
- When the PE receives an IMET route with no proxy support from an egress PE, multicast traffic is replicated to that egress PE, even if the egress PE has no receivers for the stream. The egress PE is in this case added as an OIF for (*,*); that is, multicast is sent to it for any sources and groups.
- Reports and queries are still forwarded to non-proxy PEs and processed on reception from non-proxy PEs.
To summarize, an EVPN multicast proxy PE never sends IGMP/MLD reports to EVPN destinations created from IMET routes with EVPN multicast proxy support, but it does send reports to EVPN destinations created from IMET routes without the proxy indication. This behavior allows the interworking between EVPN multicast proxy and non-proxy PEs.
EVPN multihoming and multicast synchronization
As described in RFC 9251, on EVPN multicast proxy-enabled PEs, multicast states must be synchronized across all the PEs attached to the same ES. This is illustrated in the following figure:
The left side of the figure shows how it is possible for CE1 to send Join messages for a (S,G) to PE1 or PE3, while PE2 is the DF and therefore the only PE that can send multicast traffic to the CE. The multicast traffic would not be delivered to the CE1 unless the DF, PE2, creates a state for the (S,G).
The right side of the figure shows a similar issue for the Leave process. CE1 may send a Leave message to PE3, which replies back with a LMQ (Last Member Query). CE1 then may send a Join message to a different PE as a result of a different hashing; for example, PE1. Therefore, PE3 would think the CE has left the group and would remove the state.
These two issues are solved by synchronizing the multicast states in all the PEs attached to the same ES. This feature introduces two new EVPN route types described in RFC 9251 to synchronize the multicast states in EVPN MAC-VRFs:
-
Route type 7, or Multicast Join Synch Route (synchronizes the join state in all the PEs of the ES).
-
Route type 8, or Multicast Leave Synch Route (synchronizes the leave state in all the PEs of the ES).
Note that this feature is needed along with all-active and single-active multi-homing. In single-active multi-homing, the synchronization helps speed up convergence.
Operation of EVPN multicast and multihoming
EVPN multicast synchronization in multi-homed PEs does not require any specific configuration command. Configuration of igmp/mld-snooping admin-state enable and the existence of multicast state received in a bridged subinterface attached to an ES is the trigger for the router to advertise the EVPN multicast synchronization routes.
The following considerations apply:
- Reception of IGMP/MLD Join and Leave messages on a local ES triggers the
advertisement of EVPN multicast Join/Leave synchronization routes respectively
and the associated procedures in RFC 9251.
These routes are advertised only if ES bridged subinterfaces with multicast state exist.
The routes are always advertised with the ESI-import route-target (which ensures the routes are only imported by the PEs attached to the ES) and the EVI route target EC (which guarantees the routes are only imported in the correct MAC-VRF).
- Reception of multicast Join/Leave synchronization routes trigger the synchronization of states and the associated procedures described in RFC 9251.
- About the Leave synchronization routes:
- Leave synchronization routes synchronize the LMQ (Last Member Query) procedures in the ES peers.
- The node triggering the route encodes (Last Member Query Interval * robust count) in the Maximum Response Time field of the NLRI, but applies an extra delta before expiring the max response time locally. This delta time is configurable with system.network-instance.protocols.evpn.multicast.leave-sync-propagation <number>, with a 0-to-300 second range and default value of 5 seconds.
- This delta is a configured value, ideally configured the same on all the
ES peers and long enough to account for the BGP propagation time between
the ES peers.
For example, suppose there is a max response time of 5 seconds (50 deciseconds), advertised by A and a delay of 4 seconds in BGP propagation to B. In this case, the timer could already expire on A while B is still in LMQ time and can still receive Joins (which would recreate state in A after a Join synchronization route from B).
By adding an extra delta on A, it minimizes the potential churn of A removing and recreating the state.
- The advertised maximum response time value in the multicast Leave
synchronization route is the configured
robust-count * query-last-member-interval, by default 2 seconds. Therobust-countis taken from theigmpcontext (the value is defined by the querier), and thequery-last-member-intervalis taken from the ES interfaceigmp-snoopingconfiguration. - Fast Leave is supported along with the EVPN Leave synchronization routes. In this case, the EVPN Leave synchronization route is advertised with a Max Response Time of 0 seconds.
Configuring EVPN multicast for Layer 2
To configure EVPN multicast for Layer 2, igmp/mld-snooping must be enabled on the MAC-VRF.
The following example illustrates how EVPN multicast for Layer 2 is configured.
Where:
- GW1 and GW2 are two data center gateways (DC GWs).
- LEAF1 through LEAF4 are four SR Linux nodes. LEAF3 and LEAF4 are multi-homed to Client 2, a source that generates traffic for group 239.0.0.20.
- The four leaf nodes and the two DC GW nodes are attached to the same EVPN BD.
- SWITCH1 and SWITCH2 are two SR Linux systems that are not EVPN-enabled, but have IGMP snooping enables so they can generate IGMP reports on behalf of the clients. The two switches are dual-homed to LEAF1 and LEAF2, using all-active Ethernet Segments.
The configuration of the MAC-VRF in LEAF1 and its Ethernet Segments is as follows. The other leaf nodes are configured in a similar way.
--{ * candidate shared default }--[ ]--
# info network-instance "MAC-VRF 1"
network-instance "MAC-VRF 1" {
type mac-vrf
interface ethernet-1/1.1 {
}
interface ethernet-1/2.1 {
}
vxlan-interface vxlan0.1 {
}
protocols {
bgp-evpn {
bgp-instance 1 {
admin-state enable
vxlan-interface vxlan0.1
evi 1
ecmp 2
}
}
bgp-vpn {
bgp-instance 1 {
route-distinguisher {
rd 1:11
}
route-target {
export-rt target:65011:1
import-rt target:65011:1
}
}
}
igmp-snooping { // this is the configuration required for EVPN multicast or evpn-proxy in SRL
admin-state enable
trace-options {
trace {
packet {
modifier egress-ingress-and-dropped
}
}
}
interface ethernet-1/1.1 {
version 2
send-queries true // queries are generated locally since queries are not propagated in EVPN
}
interface ethernet-1/2.1 {
version 2
send-queries true
}
}
}
}--{ * candidate shared default }--[ ]--
# info system network-instance
system {
network-instance {
protocols {
evpn {
ethernet-segments {
bgp-instance 1 {
ethernet-segment ES-SROS-Client1 {
admin-state enable
esi 01:01:01:01:01:01:01:01:01:01
multi-homing-mode all-active
interface ethernet-1/1 {
}
}
ethernet-segment ES-SROS-Client3 {
admin-state enable
esi 03:03:03:03:03:03:03:03:03:03
multi-homing-mode all-active
interface ethernet-1/2 {
}
}
}
}
}
bgp-vpn {
bgp-instance 1 {
}
}
}
}
}Note that send-queries true must be configured on the interfaces of the MAC-VRF. This is because of the leaf routers not flooding the queries from the multicast routers. By enabling send-queries on all the interfaces, the EVPN BD becomes a virtual multicast router to the receivers. This is as described in RFC 9251.
Also note that trace-options are enabled to facilitate troubleshooting for the multicast messages.
Configuration of SWITCH1 and SWITCH2 is simpler:
--{ * candidate shared default }--[ ]--
# info network-instance "MAC-VRF 1"
network-instance "MAC-VRF 1" {
type mac-vrf
interface ethernet-1/1.1 {
}
interface lag1.1 {
}
protocols {
igmp-snooping {
admin-state enable
trace-options {
trace {
packet {
modifier egress-ingress-and-dropped
}
}
}
interface ethernet-1/1.1 {
static-membership-groups {
group 239.0.0.20 {
starg
}
group 239.0.0.31 {
source 192.168.1.31 {
}
}
}
}
interface lag1.1 {
}
}
}
}Displaying EVPN multicast for Layer 2 information
The examples in this section display multicast information for the LEAF routers in the example configuration in EVPN multicast for Layer 2 .
The following example shows the MFIB table in MAC-VRF 1:
--{ running }--[ ]--
# info from state network-instance "MAC-VRF 1" multicast-forwarding-information-base multicast-route 0.0.0.0 group 239.0.0.20
network-instance "MAC-VRF 1" {
multicast-forwarding-information-base {
multicast-route 0.0.0.0 group 239.0.0.20 {
last-update "2024-01-11T02:52:39.241Z (4 days ago)"
outgoing-next-hop-group 203145816567 {
forward true
}
outgoing-next-hop-group 203145816569 {
forward true
}
outgoing-next-hop-group 203145816575 {
forward true
}
}
}
}
You can also use the show network-instance multicast-forwarding-information-base command to display the MFIB; for example:
--{ candidate shared default }--[ network-instance "MAC-VRF 1" ]--
A:leaf1# show multicast-forwarding-information-base
----------------------------------------------------------------------------------
IPv4 multicast FIB of network instance MAC-VRF 1
----------------------------------------------------------------------------------
+---------+------------+-------------------+---------+-------------+-------------+
| Source | Group | OIF list | Forward | Line card | Last Update |
| | | | | Replication | |
| | | | | Index | |
+=========+============+===================+=========+=============+=============+
| 0.0.0.0 | 0.0.0.0 | | | 1 | 5h52m8s ago |
| 0.0.0.0 | 239.0.0.20 | ethernet-1/1.1 | True | 2 | 5h52m6s ago |
| | | ethernet-1/2.1 | True | | |
| | | vxlan:10.0.0.12:1 | True | | |
| | | | | | |
| 0.0.0.0 | 239.0.0.31 | ethernet-1/1.1 | True | 3 | 5h52m4s ago |
| | | ethernet-1/2.1 | True | | |
| | | vxlan:10.0.0.12:1 | True | | |
| | | | | | |
+---------+------------+-------------------+---------+-------------+-------------+
----------------------------------------------------------------------------------
IPv4 routes total : 3
IPv6 routes total : 0
----------------------------------------------------------------------------------The following command shows that all remote VTEPs support the EVPN multicast proxy features:
--{ candidate shared default }--[ ]--
A:leaf3# show network-instance "MAC-VRF 1" protocols igmp-snooping vxlan-destination
==============================================-=======================
Net-Inst "MAC-VRF 1" IGMP SNOOPING vxlan destinations
======================================================================
+-----------+-----+--------------+------------+---------------+--------+--------+
| Vtep | Vni | NHG Id | Is MRouter | Is Evpn Proxy | Is SBD | Groups |
+===========+=====+==============+============+===============+========+========+
| 10.0.0.11 | 1 | 203145816567 | false | true | false | 2 |
| 10.0.0.12 | 1 | 203145816569 | false | true | false | 2 |
| 10.0.0.14 | 1 | 203145816565 | false | true | false | 0 |
| 10.0.0.31 | 1 | 203145816575 | false | true | false | 1 |
| 10.0.0.32 | 1 | 203145816573 | false | true | false | 0 |
+-----------+-----+--------------+------------+---------------+--------+--------+
---------------------------------------------------------------------------------
No. of destinations: 5
=================================================================================The IGMP snooping state on LEAF1 is as follows:
--{ candidate shared default }--[ ]--
A:leaf1# info from state network-instance "MAC-VRF 1" protocols igmp-snooping
network-instance "MAC-VRF 1" {
protocols {
igmp-snooping {
admin-state enable
query-interval 125
robust-count 2
oper-state up
transmitted-bgp-smet-routes 22
proxy-membership-group-count 2
proxy-evpn-membership-group-count 2
trace-options {
trace {
packet {
modifier egress-ingress-and-dropped
}
}
}
proxy-membership-groups { // --> proxy DB
group 239.0.0.20 {
filter-mode exclude
up-time "2024-01-11T02:52:38.000Z (4 days ago)"
}
group 239.0.0.31 {
filter-mode exclude
up-time "2024-01-11T02:52:39.000Z (4 days ago)"
}
}
proxy-evpn-membership-groups { // --> proxy-evpn DB used to propagate the reports with the proper flags
group 239.0.0.20 {
filter-mode exclude
up-time "2024-01-11T02:52:38.000Z (4 days ago)"
v1-support false
v2-support true
v3-support false
}
group 239.0.0.31 {
filter-mode exclude
up-time "2024-01-11T02:52:39.000Z (4 days ago)"
v1-support false
v2-support true
v3-support false
}
}
interface ethernet-1/1.1 {
router-alert-check true
version 2
maximum-number-groups 0
maximum-number-sources 0
maximum-number-group-sources 0
query-interval 125
query-last-member-interval 1
query-response-interval 10
robust-count 2
fast-leave false
mrouter-port false
send-queries true
membership-group-count 2
is-mrouter-port false
membership-groups {
group 239.0.0.20 {
group-type dynamic // --> type is dynamic because the report from SWITCH1 is hashed to LEAF1. On LEAF2, it shows as "group-type bgp-sync"
filter-mode exclude
expiry-time 245
up-time "2024-01-11T02:52:38.000Z (4 days ago)"
v1-host-timer 0
v2-host-timer 245
igmp-compatibility-mode 2
}
group 239.0.0.31 {
group-type dynamic
filter-mode exclude
expiry-time 242
up-time "2024-01-11T02:52:39.000Z (4 days ago)"
v1-host-timer 0
v2-host-timer 242
igmp-compatibility-mode 2
}
}
statistics {
received {
general-queries 0
group-queries 0
group-source-queries 0
v1-reports 0
v2-reports 5860
v3-reports 6
leave-messages 3
discarded-packets 2
bgp-join-sync 4
bgp-leave-sync 0
}
transmitted {
general-queries 2
group-queries 11
group-source-queries 0
v1-reports 0
v2-reports 0
v3-reports 0
leave-messages 0
error-packets 0
bgp-join-sync 6
bgp-leave-sync 6
}
forwarded {
general-queries 0
group-queries 0
group-source-queries 0
v1-reports 0
v2-reports 0
v3-reports 0
leave-messages 0
unknown-type 0
error-packets 0
}
error {
bad-length 0
unknown-type 0
wrong-version 0
missing-router-alert 0
bad-encoding 0
local-scope 0
reached-maximum-number-groups 0
reached-maximum-number-group-sources 0
reached-maximum-number-sources 0
out-of-memory-discarded-packets 0
bad-igmp-checksum 0
zero-source-ip-address 0
send-query-configured-discarded-packets 0
discarded-bgp-join-sync 0
discarded-bgp-leave-sync 0
}
multicast-states {
star-group-entries 2
source-group-entries 0
}
}
}
interface ethernet-1/2.1 {
router-alert-check true
version 2
maximum-number-groups 0
maximum-number-sources 0
maximum-number-group-sources 0
query-interval 125
query-last-member-interval 1
query-response-interval 10
robust-count 2
fast-leave false
mrouter-port false
send-queries true
membership-group-count 2
is-mrouter-port false
membership-groups {
group 239.0.0.20 {
group-type dynamic
filter-mode exclude
expiry-time 246
up-time "2024-01-11T02:54:43.000Z (4 days ago)"
v1-host-timer 0
v2-host-timer 246
igmp-compatibility-mode 2
}
group 239.0.0.31 {
group-type dynamic
filter-mode exclude
expiry-time 249
up-time "2024-01-11T02:54:44.000Z (4 days ago)"
v1-host-timer 0
v2-host-timer 249
igmp-compatibility-mode 2
}
}
statistics {
received {
general-queries 0
group-queries 0
group-source-queries 0
v1-reports 0
v2-reports 5858
v3-reports 0
leave-messages 0
discarded-packets 0
bgp-join-sync 0
bgp-leave-sync 0
}
transmitted {
general-queries 2
group-queries 0
group-source-queries 0
v1-reports 0
v2-reports 0
v3-reports 0
leave-messages 0
error-packets 0
bgp-join-sync 2
bgp-leave-sync 0
}
forwarded {
general-queries 0
group-queries 0
group-source-queries 0
v1-reports 0
v2-reports 0
v3-reports 0
leave-messages 0
unknown-type 0
error-packets 0
}
error {
bad-length 0
unknown-type 0
wrong-version 0
missing-router-alert 0
bad-encoding 0
local-scope 0
reached-maximum-number-groups 0
reached-maximum-number-group-sources 0
reached-maximum-number-sources 0
out-of-memory-discarded-packets 0
bad-igmp-checksum 0
zero-source-ip-address 0
send-query-configured-discarded-packets 0
discarded-bgp-join-sync 0
discarded-bgp-leave-sync 0
}
multicast-states {
star-group-entries 2
source-group-entries 0
}
}
}
vxlan-destination 10.0.0.12 vni 1 {
index 203145159966
is-mrouter-port false
is-evpn-proxy true
is-sbd false
membership-group-count 2
membership-groups {
group 239.0.0.20 {
group-type bgp-smet // --> created out of an SMET route
filter-mode exclude
expiry-time 2147483647
up-time "2024-01-11T02:52:40.000Z (4 days ago)"
v1-host-timer 0
v2-host-timer 0
igmp-compatibility-mode 2
}
group 239.0.0.31 {
group-type bgp-smet
filter-mode exclude
expiry-time 2147483647
up-time "2024-01-11T02:52:41.000Z (4 days ago)"
v1-host-timer 0
v2-host-timer 0
igmp-compatibility-mode 2
}
}
statistics {
received-smet 10
discarded-smet 0
}
}
vxlan-destination 10.0.0.13 vni 1 {
index 203145159969
is-mrouter-port false
is-evpn-proxy true
is-sbd false
membership-group-count 0
statistics {
received-smet 0
discarded-smet 0
}
}
vxlan-destination 10.0.0.14 vni 1 {
index 203145159964
is-mrouter-port false
is-evpn-proxy true
is-sbd false
membership-group-count 0
statistics {
received-smet 0
discarded-smet 0
}
}
vxlan-destination 10.0.0.31 vni 1 {
index 203145159974
is-mrouter-port false
is-evpn-proxy true
is-sbd false
membership-group-count 1
membership-groups {
group 239.0.0.20 {
group-type bgp-smet
filter-mode exclude
expiry-time 2147483647
up-time "2024-01-11T07:52:24.000Z (4 days ago)"
v1-host-timer 0
v2-host-timer 0
igmp-compatibility-mode 2
}
}
statistics {
received-smet 4
discarded-smet 0
}
}
vxlan-destination 10.0.0.32 vni 1 {
index 203145159972
is-mrouter-port false
is-evpn-proxy true
is-sbd false
membership-group-count 0
statistics {
received-smet 0
discarded-smet 0
}
}
}
}
}
Configuring the trace-options command allows you to obtain detailed logs. For example:
2024-01-15T08:40:59.875930+00:00 leaf1 local6|DEBU sr_igmp_mgr: igmp|2532|2733|11802|D: VR 10240 IGMP RX packet on network-instance "MAC-VRF 1":
SrcMac : 1a:61:0c:ff:00:00
Interface : ethernet-1/2.1
SrcIp : 0.0.0.0
DstIp : 239.0.0.31
Type : V2 REPORT
GroupAddr : 239.0.0.31
2024-01-15T08:41:19.798150+00:00 leaf1 local6|INFO sr_cli: debug|29762|29762|00024|I: common |root|1007|srl candidate shared default / | bash viewlog -e igmp -t
2024-01-15T08:42:48.828291+00:00 leaf1 local6|DEBU sr_igmp_mgr: igmp|2532|2733|11803|D: VR 10240 IGMP RX packet on network-instance "MAC-VRF 1":
SrcMac : 1a:9a:0b:ff:00:00
Interface : ethernet-1/1.1
SrcIp : 0.0.0.0
DstIp : 224.0.0.2
Type : V2 LEAVE
GroupAddr : 239.0.0.20
2024-01-15T08:42:48.829266+00:00 leaf1 local6|DEBU sr_igmp_mgr: igmp|2532|2733|11804|D: VR 10240 IGMP TX packet on network-instance "MAC-VRF 1":
DstMac : 01:00:5e:00:00:14
Interface : ethernet-1/1.1
SrcIp : 10.0.0.11
DstIp : 239.0.0.20
Type : QUERY
MaxRespCode : 10 (0xa)
GroupAddr : 239.0.0.20
2024-01-15T08:42:48.829737+00:00 leaf1 local6|DEBU sr_igmp_mgr: igmp|2532|2733|11805|D: VR 10240 IGMP TX BGP MCAST_LEAVE_SYNCH Route on network-instance "MAC-VRF 1": from local port 1/1/1
ADD (*,239.0.0.20) V2 maxRespTime 20
2024-01-15T08:42:49.812651+00:00 leaf1 local6|DEBU sr_igmp_mgr: igmp|2532|2733|11806|D: VR 10240 IGMP TX packet on network-instance "MAC-VRF 1":
DstMac : 01:00:5e:00:00:14
Interface : ethernet-1/1.1
SrcIp : 10.0.0.11
DstIp : 239.0.0.20
Type : QUERY
MaxRespCode : 10 (0xa)
GroupAddr : 239.0.0.20
2024-01-15T08:42:55.825134+00:00 leaf1 local6|DEBU sr_igmp_mgr: igmp|2532|2733|11807|D: VR 10240 IGMP TX BGP MCAST_LEAVE_SYNCH Route on network-instance "MAC-VRF 1": from local port 1/1/1
DEL (*,239.0.0.20) maxRespTime 0
2024-01-15T08:42:55.825283+00:00 leaf1 local6|DEBU sr_igmp_mgr: igmp|2532|2733|11808|D: VR 10240 IGMP TX BGP MCAST_JOIN_SYNCH Route on network-instance "MAC-VRF 1": from local port 1/1/1
DEL (*,239.0.0.20)
2024-01-15T08:43:00.044934+00:00 leaf1 local6|DEBU sr_igmp_mgr: igmp|2532|2733|11809|D: VR 10240 IGMP RX packet on network-instance "MAC-VRF 1":
SrcMac : 1a:9a:0b:ff:00:00
Interface : ethernet-1/1.1
SrcIp : 0.0.0.0
DstIp : 239.0.0.31
Type : V2 REPORT
GroupAddr : 239.0.0.31
2024-01-15T08:43:00.492810+00:00 leaf1 local6|DEBU sr_igmp_mgr: igmp|2532|2733|11810|D: VR 10240 IGMP RX packet on network-instance "MAC-VRF 1":
SrcMac : 1a:61:0c:ff:00:00
Interface : ethernet-1/2.1
SrcIp : 0.0.0.0
DstIp : 239.0.0.20
Type : V2 REPORT
GroupAddr : 239.0.0.20
2024-01-15T08:43:03.196847+00:00 leaf1 local6|DEBU sr_igmp_mgr: igmp|2532|2733|11811|D: VR 10240 IGMP RX packet on network-instance "MAC-VRF 1":
SrcMac : 1a:61:0c:ff:00:00
Interface : ethernet-1/2.1
SrcIp : 0.0.0.0
DstIp : 239.0.0.31
Type : V2 REPORT
GroupAddr : 239.0.0.31