For this discussion, imagine the topology: - Running Sparse-Mode on all the links - R5 is the BSR & RP for all groups 188.8.131.52/4 in this multicast domain - R4 is just another PIM-SM router which we will use to source multicast traffic later. - IGMP access group is configured on R8 Gi1/0.108 facing R10. ACL ONLY permit 239.1.10/24 - R10 gi1/0.108 acts like a host which joins the group 184.108.40.206 (note that this address is not permitted in the IGMP access group ACL) Scenario: When I configure igmp access-group on R8 interface, I can see that R8 is denying received IGMP Membership Report for 220.127.116.11 on it's Gi1/0.108 interface (which is expected because the ACL used in IGMP access-group does NOT permit this traffic). However, even though R8 denied the IGMP Member report, it STILL sends a PIM JOIN message for the group 18.104.22.168 to its upstream neighbor R5 (which is the RP) and was still able to build RPT tree (*,22.214.171.124) towards the RP. Question 1: I don't get why R8 still sends PIM JOIN message for 126.96.36.199 since it doesn't have any Connected host for this group, because the IGMP Access Group Filter denied the IGMP Membership Report coming from R10. When I check the IGMP groups on R8 by using #show ip igmp groups, 188.8.131.52 doesn't exist there (which i believe confirms that R8 doesn't see any host directly connected to it that is a member for the group 184.108.40.206) Question 2: When I send multicast traffic from R4 (ping 220.127.116.11 repeat 100), R10 Gi1/0.108 interface (which acts like a host) is able to respond to pings. My understanding is that the IGMP Access-Group filter on R8 Gi1/0.108 should prevent ANY host in this segment to be able to join multicast group that are not permitted in the ACL. In this case, 18.104.22.168 is not permitted in the ACL and so why does R10's interface was still able to join this multicast group? Hope that makes sense. Can anyone please enlighten me on this. Thanks.
... View more