Configuring Multicast Fabric VRFs

---

Note: Starting from NetVisor OS release 6.0.1, this feature is supported on NRU03 and NRU-S0301 platforms and on the Dell S4100 and S5200 Series.

Starting from NetVisor OS release 6.1.0, this feature is supported also on the following platforms:

• Dell Z9100-ON, S5048F
• Freedom F9532L-C/Edgecore AS7712-32X
• Freedom F9532-C/Edgecore AS7716-32X
• Freedom F9572L-V/Edgecore AS7312-54XS
• Freedom F9572-V/Edgecore AS7316-54XS
• Freedom F9532C-XL-R/Edgecore AS7716-32X

The CLI commands to configure and verify distributed multicast forwarding with Multicast Fabric VRFs are described below:

CLI (network-admin@switch) > vrf-multicast-show

enable: yes

CLI (network-admin@switch) > vrf-multicast-modify

Enabling or disabling Multicast Fabric VRFs takes effect only after a reboot. For example, this command disables the feature:

CLI (network-admin@switch) > vrf-multicast-modify disable

System must be REBOOTED for this setting to take effect

The above command is analogous to IGMP Snooping’s insofar as you can modify the feature’s state with a local or fabric scope.

With Multicast Fabric VRFs enabled, to optimize certain network designs, in more recent NetVisor OS releases BUM traffic is not flooded to tunnels by default. However, you can use the modify command below to enable/disable flooding of BUM traffic on tunnels to cater to your network design’s specific requirements. First check what is the current setting, and then modify it if needed:

CLI (network-admin@switch) > vrf-multicast-flood-show

enable: no

CLI (network-admin@switch) > vrf-multicast-flood-modify

scope   scope - fabric or local

disable disable flooding over tunnels in DM Forwarding

enable  enable flooding over tunnels in DM Forwarding

CLI (network-admin@switch) > vrf-multicast-flood-modify enable

The  vrf-mroute-show command, can be used to show the L3 entries dynamically created to implement L3 multicast forwarding:

CLI (network-admin@switch) > vrf-mroute-show

srcip    group   vxlan  vlan vrid hw-group-id send-vlan ports  flags

------- --------- ----  ---- ---- ----------- --------- ----- ------

0.0.0.0 224.1.1.1 10501  501  0    0x200098a    0        none  Active

0.0.0.0 224.1.1.1 10501  501  1    0x200098a    506      1     Active

This command can be used to check the list of multicast destination groups, incoming VLANs, outgoing ports and egress VLANs.

The above output shows (*, 224.1.1.1, 501) with port 1 as outgoing port and 506 as egress VLAN. Note that this kind of L3 entry will only contain routed ports in the egress VLAN(s) (instead, a separate L2 entry will bridge in the ingress VLAN).

The igmp-show command offers a high-level view of the dynamic behavior of the feature (in this example, port 15 is the  loopback port):

CLI (network-admin@switch) > igmp-show

group-ip  node-ip   vnet bd vlan port       source  node-type expires(s)

--------- --------- ---- -- ---- ---------- ------- --------- ----------

<snip>

225.1.1.1 ::                10   1275068416 0.0.0.0 host      0     

225.1.1.1 ::                10   15         0.0.0.0 host      0     

225.1.1.1 40.1.1.5          30   19         0.0.0.0 host      279   

The first line is a Layer 2 entry for group 225.1.1.1 that corresponds to a logical port (1275068416), namely, to a VXLAN tunnel to replicate the multicast traffic to (as it has at least a receiver in the same VNI-mapped VLAN). More than one tunnel may be listed in this position.

The second line is dynamically programmed by the software to send a copy of the multicast traffic for group 225.1.1.1 in VLAN 10 to a special  loopback port (see below)  so that a second (routing) pass after recirculation can be performed. This means that there is a source sending traffic to the group on the ingress VLAN, therefore a L3 lookup can happen for local routing.

The third line (in the show output above) shows IGMP membership on port 19 in egress VLAN 30 (which needs to be routed to).

The loopback port(s) used by Multicast Fabric VRFs are called mlb-loopback-trunk, which is an additional loopback trunk for L3 multicast traffic only. The vxlan-loopback-trunk instead continues to be used for unicast traffic. While vxlan-loopback-trunk is auto-created, mlb-loopback-trunk needs to be manually created by the user.

Furthermore, under certain circumstances it may be necessary to use the following commands to add, show or delete a static IGMP entry on a port/trunk:

CLI (network-admin@switch) > igmp-static-group-create group-ip 239.1.1.1 vlan 10 ports 14

CLI (network-admin@switch) > igmp-static-group-show

group-ip  bd vlan ports

--------- -- ---- -----

239.1.1.1    10   14

CLI (network-admin@switch) > igmp-static-group-delete group-ip 239.1.1.1 vlan 10

In this example, the commands are useful for interoperability purposes when you need to simulate an IGMP join on a certain port (in this case port 14, to which a multicast receiver is indirectly connected through a third-party network). Then, when the receiver no longer needs to receive the multicast traffic, the static IGMP entry can be deleted.