From: SIMON HART (simon.hart@btinternet.com)
Date: Thu Apr 14 2005 - 10:10:49 GMT-3
Hi,
I think you need to try and think what is going on here.
You have R3 and R4 as PIM neighbors. Your CAT will designate the ports they are on as MROUTER ports. Why? because it will need to pass mcast traffic from one to the other so that traffic may flow freely across the mcast domain. How? by snooping on PIM/DVMRP packets.
I guess that from your mail you have igmp join on the R3 interface as well. This will not stop pings from R3 when you have the igmp filter. I shall try and explain.
You generate a ping to 239.2.2.2 on R4. The default action will be that R4 will send out an icmp packet to 239.2.2.2 on all of its up interfaces - remember R4 is acting as a source.
If the icmp packet hits an mcast router the mcast router will send to it's PIM neighbor (dense mode) or send a register to its RP (sparse mode).
Now R3 is a PIM neighbor to R4, so it will recieve the ping - as I said earlier the CAT knows that it has an mcast router on it's R3 port, so will forward the mcast traffic out of the R3 port (and any other mrouter port on that vlan). Once the ping gets to R3, R3 (via the join statement you have put on R3's interface) will recognise itself as a recipient for group 239.2.2.2 and respond unicast to R4.
In this situation IGMP has had no involvement in the process apart from the point of view of R3 recognising itself as a recipient to group 239.2.2.2
Now you have a IGMP filter for this group on R3's port and a join statement on R3, R3 will send an IGMP report to R4, but the report will not get through. However if you run through the above R3 will still respond to the ping, irrespective of the CAT's treatment of IGMP joins.
As Bob quite succinctly put it, if you wish to test IGMP filtering you will have to change the configuration. No PIM on R3.
HTH
Simon
Gajewski Mariusz <Mariusz.Gajewski@telekomunikacja.pl> wrote:
Hi ,
I just did gladston's config , with pim neighborship and mcast
routing disabled on both routers , tried pim sparse/sparse-dense/dense , the
effect is the same - ping is still going.
That makes me scratch my head ...
Per doc-cd :
"...IGMP filtering controls only group specific query and membership
reports, including join and leave reports. It does not control general IGMP
queries. IGMP filtering has no relationship with the function that directs
the forwarding of IP multicast traffic.."
So, no mcast routing , no pim neighborship and it's still working. Any
ideas ?
Mariusz
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Bob
Sinclair
Sent: Thursday, April 14, 2005 1:18 AM
To: gladston@br.ibm.com; ccielab@groupstudy.com
Subject: Re: Multicast filter does not avoid reply
Gladston,
If you want to test the join filter, then do not make R3 a PIM neighbor.
Just do a join-group on the FastEthernet interface of R3. No PIM, no
multicast-routing.
HTH,
Bob Sinclair
CCIE #10427, CCSI 30427, CISSP
www.netmasterclass.net
----- Original Message -----
From: gladston@br.ibm.com
To: ccielab@groupstudy.com
Sent: Wednesday, April 13, 2005 5:33 PM
Subject: Multicast filter does not avoid reply
Although 3550 is configured with igmp filter, and show commands shows it
is working, R3 reply to ping from R4.
R3-----(fa0/2)CAT2(fa0/3)-----R4
R3 and R4 are configured as PIM sparse-dense-mode. There is no RP. The
goal is to test IGMP filtering.
nmcr4>ena
nmcr4#p
Protocol [ip]:
Target IP address: 239.2.2.2
Repeat count [1]: 99999
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 99999, 100-byte ICMP Echos to 239.2.2.2, timeout is 2 seconds:
Reply to request 0 from 172.16.34.3, 4 ms
Reply to request 1 from 172.16.34.3, 4 ms
Group 239.2.2.2 does not appear on 3550:
CAT2#sh mac-address-table multicast vlan 34
Vlan Mac Address Type Ports
---- ----------- ---- -----
34 0100.5e00.0128 IGMP Fa0/1, Fa0/2
34 0100.5e01.0101 IGMP Fa0/1, Fa0/2
CAT configuration:
ip igmp profile 5
range 239.2.2.2 239.2.2.2
!
vlan 34
!
interface FastEthernet0/2
switchport access vlan 34
switchport mode access
no ip address
spanning-tree portfast
ip igmp filter 5
Isn't is strange? or may I missing something.
R3 is the IGMP query. I was wondering if it would cause this:
(as R3 is a router, 3550 forwards any multicast to the router, causing
this; well, it would happens even if R3 was not the querier)
CAT2#sh ip igmp snooping querier v 34
Vlan IP Address IGMP Version Port
---------------------------------------------------
34 172.16.34.3 v2 Fa0/2
This archive was generated by hypermail 2.1.4 : Tue May 03 2005 - 07:54:57 GMT-3