PowerConnect 3324 and IGMP Snooping and Multicast Filtering

Question

I have Enabled IGMP Snooping and Bridge Multicast Filtering on a PC3324 connected in a network as below. I see the IGMP queries and reports, and can see Groups being identified with ports on the 3324. But, the multi-cast traffic never stops flooding the other ports on the 3324. I thought it would only go out the port connected to the subnet with m-cast srvr and client and to the port connected to the m-cast router. I also have snooping enabled on the powerconnect 3024, and the m-cast traffic does only go out the right ports (to the 3324 to get to the m-cast router, and the srvr and client).

3324 versions:

Software Boot Hardware

1.2.0.6 1.0.0.13 00.00.03

           Other ports seeing m-cast traffic
            _|_|_|
           |      |--
           |PC3324|-- Other ports seeing m-cast traffic
           |______|--
              | |
              | |
              | +------------+
            __|___    _______|_________
           |      | |                 |
           |PC3024| |Multi-cast router|
           |______| |_________________|
              | |
              | |
              | +-------------+
              |               |
            __|___    _______|__
           |       |  |          |
           | Mcast | | Mcast    |

| Srvr | | Client |
|______ | |__________|

DELL-Cuong N. · Answer

I wrote up a very long explanation on this awhile ago on this thread: http://forums.us.dell.com/supportforums/board/message?board.id=pc_managed&message.id=4194#M4194   Basically, until the m-cast client sends a join the L2 switch will continue to flood.  If you want to make it work correctly you should connect the multicast server to the multicast router instead of to the L2 switch.  Or you have to make sure the multicast server does not send out multicast stream until at least one multicast client has joined.   BTW, I also posted some links to other information in the above thread.  I hope this helps.   Cuong.

tela2kmr · Answer

Thanks.  I had read your long explanation before posting; however, on re-reading it and your post, I have a clarifying question.   Your long explanation states that the L2 switch looks for JOINs -- does the L2 not use igmp report packets, only join packets?   Looking at traffic, the client is sending report packets in response to router queries, and the client sends an igmp leave when it's stopped.  But not a join.   If reports are not used on the 3324 switch, only joins, the client may need changing to send out the join as well as the reports.

DELL-Cuong N. · Answer

Actually, the IGMP report message is the same as the Join message. The report is sent by a host wishing to join a multicast group or to remain connected to a multicast group.

Let me ask you a few questions:

Which version of IGMP are you running on the multicast router and on client & server?
Can you post your configuration on 3024 and 3324?
You said you "can see Groups being identified with ports on the 3324" - can you do a show and post it here too? Same with membership of 3024.
When you said you still see m-cast packets flooded to other ports, do you mean all the packets streamed from the m-cast server are flooded? Or are you referring IGMP messages such as the query message from the m-cast router which is sent periodically are flooded?
Have you tried just connecting the m-cast server & client directly to the 3324? Does that work any better? Just trying to see if it makes any difference.

Cuong.

tela2kmr · Answer

Thanks. I've responded to your bullet points (with clarifying questions) below.

First, while I want to stop the flooding in general, an immediate need is to keep the streams from "blowing up" some devices (like wireless access points) on the network. What is the correct way--if any--to stop all m-cast packets on a specific port? That way I can isolate those ports from any m-cast and worry about the flooding issue separately.

In addition to the config, are there any other "well, duh" things to check? Does it not work on the default VLAN 1? Are there m-cast addresses that the switch floods no matter what such as 224.0.0.XXX? The 3324 is seeing the igmp reports (it's forwarding the igmp report packets) but not creating the groups. Maybe server needs to use a different group? et cetera.

1. I'll check on the m-cast router version of igmp -- the packets for query/report dump'd from tcpdump are igmp v2

2. what's the best command(s) to print out the config you want to see?

3. Here are the groups on the 3324 (how do I print similar on the 3024?). Note that these are not the multi-cast IP addresses used by the m-cast server and client. The 3324 is defining these other m-cast groups, but not the server client groups.

show ip igmp snooping groups vlan 1

Vlan   IP Address               Querier Ports
------ ------------------------ ------- -----------------------------------
1      224-239.255|127.255.250 Yes     1/e(1,3-5,8-9,11,13,20),1/g2
1      224-239.255|127.255.253 Yes     1/g2
1      224-239.255|127.255.254 Yes     1/e13

show ip igmp snooping interface 1

IGMP Snooping is globaly enabled
IGMP Snooping is enabled on VLAN 1
IGMP host timeout is 260 sec
IGMP Immediate leave is disabled. IGMP leave timeout is 10 sec
IGMP mrouter timeout is 300 sec
Automatic learning of multicast router ports is enabled

show ip igmp snooping mrouter

VLAN              Ports
-------           ----------------------------------------
1                 1/g1

4. All the packets, not just igmp packets. Question: should the 3324 immediatly start filtering when it snoops the first igmp report for a group? Or does it take some time?

5. I have other server/client pairs on the network directly on the 3324 and I see the same behavior (not filtering)

Thanks again ...

tela2kmr · Answer

Here's an example of the igmp queries/reports the 3324 is seeing:

12:52:15.029378 IP m-cast-router > ALL-SYSTEMS.MCAST.NET: igmp query v2
12:52:16.572383 IP a-system > 239.255.255.250: igmp v2 report 239.255.255.250
12:52:18.460783 IP m-cast-client > 224.0.0.242: igmp v2 report 224.0.0.242
12:52:20.211319 IP m-cast-client > 224.0.0.241: igmp v2 report 224.0.0.241

Note that the 239.255.255.250 shows up in the 3324's groups; the 224.0.0.241 and .242 do not:

Vlan   IP Address               Querier Ports
------ ------------------------ ------- -----------------------------------
1      224-239.255|127.255.250 Yes     1/e(1,3-5,8-9,11,13,15,20),1/g2
1      224-239.255|127.255.253 Yes     1/g2
1      224-239.255|127.255.254 Yes     1/e13

GregG1 · Answer

Please note the following information from the IANA ( http://www.iana.org/assignments/multicast-addresses):

The range of addresses between 224.0.0.0 and 224.0.0.255, inclusive,
is reserved for the use of routing protocols and other low-level
topology discovery or maintenance protocols, such as gateway discovery
and group membership reporting. Multicast routers should not forward
any multicast datagram with destination addresses in this range,
regardless of its TTL.

Addresses in this range should not be used for multicast streaming, therefore, it is unlikely that addresses in this range will participate in IGMP.

tela2kmr · Answer

This just shows how a little knowledge can be dangerous ...

I had thought of that and tried using other addresses. Specifically, 239.0.0.253 and then 237.0.0.253, and the 3324 switch was still not creating the group and filtering the traffic. Thus, I assumed (incorrectly) that it was not related to the IP multicast group I was using.

Well, something about the other addresses I choose were also special, I guess.

FINALLY, I took a stab at getting away from 224-239.0.0 and used 239.0.1.253 and 239.0.1.254 and it WORKS!

I know that the original intent in using the link local 224.0.0.0 addresses was to keep to the local segment by using the defined link local addresses. 239.0.0.0 through 239.255.255.255 are also limited scope addresses; hopefully, they will work for us. I suspect 239.0.0.253 not working has something to do with the non uniqueness of IP to MAC group address mapping. If anyone knows exactly why, you could save me some reading!

Thanks for your help!

tela2kmr · Answer

FYI, another way to crack this nut.   If I statically define the multicast address 224.0.0.252, for example, I get the desired effect.  With a static group defined, multicast traffic to that address only gets forwarded to a port that has had a join.  IGMP protocol packets (like queries, reports ...) are still forwwarded around ... but the UDP stream packets are not.  This is a satisfactory workaround until we reconfigure our m-cast groups to another range.   BTW, the 3024 switches do snoop the group 224.0.0.xxx joins/reports and stop flooding, but the 3324's need the static groups to filter 224.0.0.xxx.

Networking General

PowerConnect 3324 and IGMP Snooping and Multicast Filtering

Was this post helpful?