Configuring Multicast Fabric VRFs
Note: Starting from Netvisor ONE 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 ONE 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
CLI (network-admin@switch) > vrf-multicast-modify
Specify the scope - fabric or local
Specify to disable flooding over tunnels in DM Forwarding
Specify to enable flooding over tunnels in DM Forwarding
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 ONE 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
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 184.108.40.206 10501 501 0 0x200098a 0 none Active
0.0.0.0 220.127.116.11 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 (*, 18.104.22.168, 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)
--------- --------- ---- -- ---- ---------- ------- --------- ----------
22.214.171.124 :: 10 1275068416 0.0.0.0 host 0
126.96.36.199 :: 10 15 0.0.0.0 host 0
188.8.131.52 184.108.40.206 30 19 0.0.0.0 host 279
The first line is a Layer 2 entry for group 220.127.116.11 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 18.104.22.168 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 22.214.171.124 vlan 10 ports 14
CLI (network-admin@switch) > igmp-static-group-show
group-ip bd vlan ports
--------- -- ---- -----
126.96.36.199 10 14
CLI (network-admin@switch) > igmp-static-group-delete group-ip 188.8.131.52 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.