Re: Multicasting

sandeepdwivedi1890 · ‎01-07-2020

Hi Team,

I have a question in reference to the multicast switching.

As we know that, for multicast switching, we need only IGMP protocol to take the forwarding decision.

For same broadcast domain, why we need to enable any multicast routing protocols (PIM-sparse and dense mode)?

I was testing IGMPv2 realised that without IGMP, I cannot test this protocol.

There should be some other way to test the IGMP without configuring PIM.

I used the below scenario to test this issue

R1<=======>H1

R1(config)#ip multicast-routing
R1(config)#interface f0/0
R1(config-if)#ip pim sparse-mode

H1(config-if)#ip igmp join-group 239.1.1.1

The above is the configuration used to test the IGMP.

The configurations of the switching and routing should be separated.

I tested this scenario in another vendor switches and routers. In another vendor, the multicast routing and multicast switching configuration are separated. We can test the IGMP without using the multicast routing protocol.

This features should be available in the Cisco devices as well.

Please let me know if you need any clarification.

Regards,

Sandeep Dwivedi

ngkin2010 · ‎01-07-2020

Hi,

You do not need to configure ip pim spread to enable R1 to ping 239.1.1.1.

However, in order to enable igmp on the Cisco's interface, you need to enable either 'ip pim sp' or 'ip igmp join 232.1.1.1' on that interface such that the IGMP will automatically enabled afterward.

Router(config)# do debug ip packet
*Jan 7 14:29:06.656: IP: s=192.168.0.2 (Ethernet0/0), d=239.1.1.1, len 32, input feature, packet consumed, MCI Check(108), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

Router(config)#do sh ip igmp int
Ethernet0/0 is up, line protocol is up
  Internet address is 192.168.0.1/24
  IGMP is disabled on interface
  Multicast routing is disabled on interface
  Multicast TTL threshold is 0
  No multicast groups joined by this system

Without that, you won't see the igmp groups even your have received IGMP membership report.

sandeepdwivedi1890 · ‎01-07-2020

Hi

As per your update, we need to enable ip pim sp' or 'ip igmp join 232.1.1.1.

p pim sp ----> This is multicast routing protocol

ip igmp join 232.1.1.1----> This is use to join the 232.1.1.1 group

My concern is why we need to enable the pim protocol for multicast switching?

ngkin2010 · ‎01-08-2020

Hi,

As I have mentioned in the last reply, you do not need to enable PIM protocol to allow R1 to ping 239.1.1.1.

If you want to check all the IGMP report received by R1 from the "show ip igmp groups", PIM protocol is not a must, while IGMP protocol is a must.

It's just a Cisco's implementation that you need to enable PIM protocol to trigger IGMP protocol to be enabled.

I think the reason behind is simple, because if you (the R1) are not the multicast router, how come you will want to listen any IGMP reports? R1 will simply ignore those IGMP reports, and that why you don't see information from "show ip igmp groups".

Please feel free to correct me... Thanks~

sandeepdwivedi1890 · ‎01-09-2020

Hi,

It's just a Cisco's implementation that you need to enable PIM protocol to trigger the IGMP protocol to be enabled.
--> This is my question. Why do we need to enable PIM protocol to trigger the IGMP protocol to be enabled?
--> If the multicast server and hosts are in the same broadcast domain, then we don't need routing protocol (PIM).
--> If the multicast server and hosts are in a different broadcast domain, Then we need to enable PIM.

There should be some IGMP configurations to trigger the IGMP packets for the same broadcast domain.
I think there is no IGMP configuration in the cisco devices, however, I can see these configurations is available in another vendor devices.

The Cisco should implement IGMP configuration.

When we are enabling the PIM protocol to trigger the IGMP packets then the router will trigger PIM and IGMP packets both. Unnecessarily, It will utilize the BW.

Thanks,

Sandeep

ngkin2010 · ‎01-09-2020

hi,

Understood your question... but I still think that it’s reasonable.

As said, if the router (R1 in your example) is not the multicast receiver (you didn’t have “ip igmp join 239.1.1.1” on interface), and also the router is not acting as multicast router (you didn’t run PIM), then what is purpose running IGMP on R1?

PIM is not needed in order to make the multicast communication work on a LAN, the switch(es) will handle it by either flooding (if IGMP snooping is not enabled) / replicating to dedicated multicast receivers (if IGMP snooping is enabled).

Generally, Cisco has enabled IGMP snooping by default. But without neither a IGMP querier nor multicast router within LAN, the multicast receivers will not periodic send out their IGMP report, and at a result, IGMP snooping will not working as expected.

You will want to configure "ip igmp snooping querier" on at least a switch to actively check if there is any multicast receivers within the LAN (by sending IGMP group membership query message) .

switch(config)# ip igmp snooping querier

And of coz, if you have enabled PIM on router, then your LAN will now have a multicast router to send out IGMP group membership query message. If that is the case, you don't need the "ip igmp snooping querier".

sandeepdwivedi1890 · ‎01-24-2020

Hi,

kindly consider the below topology

Multicast_Server<===>Switch<====>Clients

There are no IGMP and PIM configurations on the switch. As per your previous update, by default IGMP Snooping is enabled so let it be like this. We are not disabling the IGMP snooping on the switch.

Now, in the above scenario, how switch will generate the IGMP query packet after "Membership Report Group"?

And consider, if the switch is sending the query packet then this behaviour is not good for the security reason.

Thanks

ngkin2010 · ‎01-24-2020

Hi,

Although the igmp snooping is enabled by default in IOS, switch would not send out IGMP query until you have enabled IGMP querier by the following command.

switch(config)# ip igmp snooping querier

In your given topology, I would like to demonstrate (1) with IGMP querier configured and (2) without IGMP querier to let you know the different.

First, let simply enabled IGMP debug on switch

switch(config)# do debug ip igmp

Then, we join the group on Host:

host(config)#int vlan 1
host(config-if)#ip igmp join 239.1.1.1
host(config-if)#
*Jan 25 03:08:36.194: IGMP(0): WAVL Insert group: 239.1.1.1 interface: Vlan1Successful
*Jan 25 03:08:36.194: IGMP(0): Send v2 Report for 239.1.1.1 on Vlan1

And on the switch:

switch#
*Jan 25 03:09:49.948: IGMPSN: Received IGMPv2 Report for group 239.1.1.1 received on Vlan 1, port Et0/1
*Jan 25 03:09:49.948: IGMPSN: group: Received IGMPv2 report for group 239.1.1.1 from Client 192.168.1.2 received on Vlan 1, port Et0/1
*Jan 25 03:09:49.948: IGMPSN: group: Skip client info adding - ip 192.168.1.2, port_id Et0/1, on vlan 1
*Jan 25 03:09:49.948: IGMPSN: No mroute detected: Drop IGMPv2 report for group 239.1.1.1 from client 192.168.1.2 received on Vlan 1, port Et0/1
switch#

And now, we check the command "show ip igmp snooping group" is giving empty output.

switch#show ip igmp snooping group
Vlan      Group                    Version     Port List
---------------------------------------------------------

switch#

Anyway, If you now trying to ping from router to host's multicast address, it will success. IT's because switch will flood the multicast traffic even the IGMP snooping is not working.

router#ping 239.1.1.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 192.168.1.2, 20 ms
router#
router#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
router#

After you have enabled IGMP querier on switch, and rejoin the group on host (optional):

If you don't rejoin the group, you have to wait until next last-member-query generate by switch, which is by default 125 seconds. Also, that's the answer to your question - "how switch will generate the IGMP query packet".

switch# ip igmp snooping querier

switch#
IGMPSN: Received IGMPv2 Report for group 239.1.1.1 received on Vlan 1, port Et0/1
L2MM: Add member: gda:aabb.cc00.1a00, adding Et0/1
IGMPSN: mgt: added port Et0/1 on gce aabb.cc00.1a00, Vlan 1
IGMPSN: group: Created group 239.1.1.1
IGMPSN: group: Forwarding 239.1.1.1 report to router ports

And now, we check the command "show ip igmp snooping group" again.

switch#show ip igmp snooping group
Vlan      Group                    Version     Port List
---------------------------------------------------------
1         239.1.1.1                igmp        v2          Et0/1
switch#

Now, switch will no longer flooding the multicast traffic to 239.1.1.1, but instead replicate the frame to Et0/1.

router#ping 239.1.1.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 192.168.1.2, 20 ms
router#