LAN Routing
1753894 Members
7459 Online
108809 Solutions
New Discussion ī„‚

Multi-Cast with PIM SPARSE

 
SOLVED
Go to solution
ABZ78
Advisor

Multi-Cast with PIM SPARSE

We currently have the following setup using PIM Dense mode:

1 - HPE 5412Zl2 configured as a router..............respectivley "R1"

2 - HPE 5412Zl2's configured as Layer 2 switches.............respectivley "SW1" and "SW2"

1 - Avercaster SE510 Lite which is configured to multicast Output URL:udp://@ 239.1.1.1:1234

The configs on all switches are shown here:

R1 Config :

ip routing

ip multicast-routing

Vlan 1: 

ip igmp
ip pim-dense
ip-addr any
exit

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

SW1 and SW2 configs:

Vlan 1

ip igmp

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

Users are experiancing audio and video lag.  I do no see snooping as an option on these switches. I am researching better ways to set up multicast.  Would PIM Sparse be a better option?

Do I need any further configuration to change from PIM Dense to PIM Sparse?  

 

 

 

 

 

 

 

 

 

3 REPLIES 3
Emil_G
HPE Pro

Re: Multi-Cast with PIM SPARSE

Hello,

There is no separate command for enabling IGMP snooping on this platform. The command "ip igmp" in VLAN context enables both. If the VLAN doesnt have IP address only IGMP snopping is enabled, if there is IP in the VLAN the switch can also act as L3 IGMP snooping quierier.

You have provided only the configuration of VLAN 1 on all 3 switches. Does it mean that your multicast streamer Avercaster SE510 Lite AND the multicast receivers are both connected to ports in the same VLAN 1? 


If this is the case then you actually don't need PIM at all. PIM is mutlicast routing protocol. If both multicast source and receivers are in the same VLAN no multicast routing is necessary even if the source and receivers are separated by multiple switches. IGMP should be sufficient for L2 multicast forwarding. PIM is necessary when sources and receivers are in different VLANs.

PIM dense mode has the advantage that is is much easier to configure. You just enable PIM al all interfaces which should forward the multicast. The disadventage is that a PIM dense router will flood the multicast to all its PIM neighbors by default until the neigbors indicate that they dont need it. But this shouldnt actually affect the performace of the multicast receivers. It would affect other devices in the network because they receive mutlicast they dont need.

PIM sparse will only forward multicasts to PIM neighbors which explicitly request it. So it is more efficient in environments with bandwidth restrictions. But PIM sparse has more complex configuration. You need to have RP which can be statically or dynamically configured. For dynamic RP allocation you also need to configure BSR routers. Troubleshooting is also a bit more complex.

There are a lot of differences in the configuration of PIM sparse and dense mode. You specify the mode as pim-sparse and pim-dense in the VLAN context. For PIM-sparse you need to have RPs. They can be statically configured on all PIM routers or you can use candidate RP and BSR routers. This is more something for complex environments.

You can find more details about the Multicast protocols in the Aruba Multicast and Routing guide.

https://www.hpe.com/psnow/doc/a00091313en_us

I am an HPE employee

Accept or Kudo


ABZ78
Advisor

Re: Multi-Cast with PIM SPARSE

Most of our devices our on Vlan 1 (including the Avercaster)

Other devices are on VLan 101 (wireless) and we have PIM configured the same on that vlan as vlan 1. 

In our secnario (1 router 2 layer 2 switches) if we were to set up pim sparse, I assume each vlan interface on the router would be the RP for that vlan?

Below is the output from sh ip igmp

The two multicast groups:  239.1.1.1 and 239.2.2.2 are our AverCasters (we have two)

I am not sure what all the other multicast IPs are from.

 

IGMP Service Protocol Info

Total VLANs with IGMP enabled : 2
Current count of multicast groups joined : 14

IGMP Filter Unknown Multicast: Disabled
IGMP Filter Unknown Multicast Status: Disabled

VLAN ID : 1
VLAN Name : DEFAULT_VLAN
IGMP version : 2
Querier Address [this switch] : 10.6.0.1
Querier Port :
Querier UpTime : 121d 8h 6m 11s
Querier Expiration Time : 0h 1m 11s

Active Group Addresses Type Expires Ports Reports Queries
---------------------- ---------- --------------- ---------- ------- -------
224.0.1.60 Filter 0h 3m 34s A23,E1,... 991481 0
224.0.6.151 Filter 0h 3m 33s A23,F9 167279 0
234.8.8.8 Filter 0h 3m 31s A23 73720 0
235.80.68.83 Filter 0h 3m 33s A23,F2,... 389025 0
239.1.1.1 Filter 0h 3m 25s A23 1056 0
239.2.2.2 Filter 0h 3m 31s A23 39828 0
239.83.100.109 Filter 0h 3m 33s A23,F2,... 413557 0
239.255.255.250 Filter 0h 3m 34s A23,E1,... 1279316 0
239.255.255.253 Filter 0h 3m 29s A23,F9 167340 0

 

 

Emil_G
HPE Pro
Solution

Re: Multi-Cast with PIM SPARSE

Hello,

If the multicast stream has to be forwarded to wireless users in VLAN 101 then you need PIM on the router indeed. To be honest I havenā€™t seen by now PIM sparse mode running on a single multicast routing switch. Dense mode should be sufficient here and the adventages of sparse mode are achieved in more complex environments.

The idea of having a RP address is that all the multicast routers in the network know the RP as a predefined root point of the multicast tree so that they can join the multicast tree as soon as they have receivers even if the source didnt start streaming yet. In your case probably it will be sufficient to define the IP of the router in VLAN 1 as RP for all groups. 

 

Yes, the end devices have sent joins for other multicast groups as well. 

224.0.1.60 is assigned to hp-device-disc  (this should be a group used by HP printers)

224.0.6.151 Canon-Device-Control (probably a group used by Canon devices).

239.255.255.250 SSDP (simple service discovery protocol, this is a zero configuration protocol similar to mDNS Bonjour)

239.255.255.253 ā€“ SLPv2 Discovery (Service Location Protocol v2)

Couldnt find information on the other groups. This may be traffic which is needed for the proper functioning of the devices. If you determine that some type of application is consuming too much bandwidth you can filter it using ACL. Here is an example on how to stop SSDP packets from getting into the switch.

https://community.arubanetworks.com/blogs/esupport1/2019/03/29/switch-configuration-to-prevent-ssdp-attacks-on-the-serversnas-connected-to-switch

Here is another example on how to block IGMP traffic. In this case it blocks every group but of course it can be adapter to block only certain groups.

https://community.arubanetworks.com/blogs/esupport1/2018/10/03/acl-to-block-igmp-traffic-on-2530

I am an HPE employee

Accept or Kudo