Some experiments with IGMP snooping behavior of a couple of switches

Alan Crosswell

December, 2004

Copyright (c) 2004 The Trustees of Columbia University in the City of New York

Table of Contents

Introduction
What's not being tested
Some questions raised by the testing
Things to look for when selecting a switch
IGMP v3 ASM tests
IGMP v2 ASM tests
IGMP v3 SSM tests
Multicast source tests
More IGMP v3 tests
Miscellany
Tools
Hints & Kinks
Acknowledgements

Introduction

In an effort to better understand LAN multicast interactions with IGMP, a small test environment has been set up with the "switch under test" connected to three client hosts (Linux 2.6 machines that do IGMP v3). The uplink from the switch to the router is further bridged via a dumb hublet to another machine that snoops the traffic between the switch and router, in order to observe how IGMP snooping switches, variously pass, suppress, modify and snoop IGMP protocol messages and multicast traffic.

See the IETF MAGMA working group's Considerations for IGMP and MLD Snooping Switches (currently an Internet Draft with a copy salted away here just in case :-). This draft has been submitted for consideration as an informational RFC.

Right now, I have a loaner HP ProCurve 2626 from Internet2, a Cisco Catalyst 3750, and a Cisco Catalyst 4500 (Sup2+ and Sup2) to test with.

What's not being tested

I have no way of doing any kind of serious multicast performance testing with this setup. This is an important issue to follow through on if one is planning to do "Ethernet TV" for example where one might have several hundred channels and hundreds of simultaneous viewers on each switch. There are lots of potential limitations such as number of multicast groups the switch will accomodate, forwarding performance, and so on.

I'm also not testing having multiple routers in a LAN and all that querier election stuff that goes on. Nor am I testing having a downstream hub or switch below the switch under test to make sure that leaves do not happen prematurely when there are multiple hosts with group interest below the same switch port.

Some questions raised by the testing

See the testing details below for the basis of these questions:
  1. Will HP be making IGMP v3 snooping work correctly on the 2626? When?
  2. Does IGMP v3 snooping work correctly on other HP ProCurve models?
  3. Why do both the HP and Cisco (IOS) flood the group-specific query out all ports? Shouldn't this only go to the ports currently joined to the group? Does this matter?
  4. Why does the Cisco (IOS) pass along all v3 host membership reports instead of just the one needed to keep the router happy? Does this matter?
  5. Why does the Cisco (IOS) spoof an IGMP v2 Leave Group message toward the router when in IGMP v3 mode?

Things to look for when selecting a switch

Following are some items that have been problems for people when trying to use various switches for multicast. See Considerations for IGMP and MLD Snooping Switches, cited above as well.
  1. Support for various IGMP versions, especially v3.
  2. Maximum number of simultaneous multicast MAC addresses and what happens when this number is exceeded? Also, is the maximum a per-switch or per-VLAN number?
  3. Current or planned support of MLD snooping if you plan on running IPv6 during the useful lifetime of the switch.
  4. Are downstream hubs handled correctly (e.g. no premature leave)?
  5. Do you need features like immediate leave? Might be useful to prevent hosing your network with channel surfers (e.g. change channels once a second but it takes 5 seconds for the previous channel's traffic to be pruned.)
  6. ...

IGMP v3 ASM tests

Example 1: Single remote ASM source with single receiver
Example 2: Single remote ASM source with two receivers

These tests involve modern routers and hosts (Windows XP or later; Linux kernel 2.6 or later) in which IGMP v3 is implemented. We first test any source multicast (ASM) since it is by far the most common flavor out there. Since (*,G) joins in IGMP v3 look radically different from those in IGMP v2, I thought this would be a good starting point to find broken snooping switch behavior. I was right.

Example 1: IGMP v3 ASM: Single remote ASM source with single receiver

In this example, the ASM sender is elsewhere, there are three hosts on the switch and one of the three hosts joins (with IGMP v3 exclude mode), listens for a while and then leaves (with IGMP v3 include mode). We confirm that the multicast traffic only goes out the switch port that has the joining host attached and also observe the IGMP protocol messages to see what kind of spoofing is being done.

The router

The router is a Cisco Catalyst 6509 with MSFC2 running native IOS 12.1(22)E. The hublet in front of the switch is connected to a Fast Ethernet port:
interface FastEthernet7/37
 description test subnet
 ip address 128.59.7.1 255.255.255.0
 ip helper-address 128.59.59.25
 ip helper-address 128.59.31.79
 no ip redirects
 no ip unreachables
 ip pim sparse-mode
 ip igmp version 3
 speed 10
 duplex half
end

The source - 128.59.39.150

I used iperf for the multicast source:
iperf -u -c 224.5.6.7 -p 8910 -T 10 -b 1 -i 5 -t 1200

The receiver - 128.59.7.10

I could have used iperf as the receiver but already had rtpqual laying around so I used it:
rtpqual 224.5.6.7 8910

Methodology

To reproduce this example:
  1. Start iperf running on sender.
  2. Start tcpdump running on each receiver and snooper.
  3. Let simmer for about 2 minutes which will allow enough time for at least one IGMP router advertisement (general query) to be received by each machine, which will provide a "sync" packet to start time in the tcpdump traces.
  4. Start receiver rtpqual running and let it run for about 2 minutes.
  5. While rtpqual is running, do a couple "show ip igmp" commands on the switch and router and oberve proper IGMP state being maintained.
  6. Stop receiver rtpqual.
  7. During the next 4 minutes, do several "show ip igmp" commands on the switch and router and observe IGMP state being torn down (or not). Wait until the router has pruned the group.
  8. Let simmer another 2 minutes so the tcpdump traces will contain a couple more router advertisements.
  9. Stop all the tcpdumps and copy the traces up to the data collection and analysis point along with console logs from the switch and router.
(N.B. I didn't quite get this right in the traces for example 1a below so sync points were not properly established.)

Example 1a: HP ProCurve 2626 (H.07.31)

In this example, the switch, running out of date release H.07.31, supports IGMP v3 well enough to properly join a group but it doesn't correctly implement fast leave. This is further exacerbated by a soft state timer maintained by the switch that expires prior to the router IGMP soft state for the group. The result is that first, the host leaves the group and continues to be bombarded with the traffic for another two minutes or so, and then, even worse, after this state is pruned by the switch, the router is now sending the switch multicast traffic for which the switch has no state. So, the switch does what it's supposed to and floods this traffic to all ports. Imagine the impact of a channel surfer with 5 Mbps MPEG-2 multicast channels! Check your ProCurve switches! If you've never upgraded them since buying them they may very likely have this bug. Kudos to HP for making software updates available for free forever.

Example 1b: HP ProCurve 2626 (H.07.50)

This example shows that simply upgrading to the latest software release fixes the bug seen in Example 1a, above. IGMP leaves are now propogated through to the router which in turn sends two group-specific membership queries with a 1 second response time, and after no response is received the data flow is pruned. There is still a minor bug in that group-specific membership queries from the router are forwarded out all ports.

Example 1c: HP ProCurve 2626 (H.08.53), fast leave set, igmp delayed-flush 100

Let's just see if example 1b, which did the leave processsing correctly, still works! Yes, it does.

Example 1d: Cisco Catalyst 3750 (12.1(19)EA1c)

The Cisco appears to do a much better job of IGMP v3 support, including correctly implementing fast leave and not flooding incorrect multicast traffic or IGMP messages to non-participants. It does some wierd stuff with spoofing router IGMP group-specific queries and adds a gratuitous spoofed IGMP v2 leave message as well.

Example 1e: Cisco Catalyst 3750 (12.2(25)SE)

Just upgrade to the latest IOS and see if the behavior of example 1d changes at all. Looks almost the same, including the wierd IGMP v2 leave spoofed by the switch. The one new thing that happens is the group-specific query sent by the router is flooded out all ports. It's not clear to me why this is necessary but it looks like Cisco added it between IOS releases.

Example 1f: Cisco Catalyst 4500 w/Sup2+ (12.2(25)EW)

The most notable difference with the Cat 4500/Sup2+ is that it spoofs the IGMP v3 membership report with a source address of 0.0.0.0. The IP address of the host that joined is never sent up to the router.

Example 1g: Cisco Catalyst 4500 w/Sup2 (8.4(1)GLX)

This is a CGMP-speaking switch running CatOS. However, it seems to work just right in this simple case.

Example 2: IGMP v3 ASM: Single remote ASM source with two receivers

This example builds on Example 1 by adding a second receiver for the same group and then having the first receiver leave first. The goal is to see what the switch does with the joins and leaves. Does it pass them both through to the router or just one? Does it spoof the leave?

The source - 128.59.39.150

I used iperf for the multicast source:
iperf -u -c 224.5.6.7 -p 8910 -T 10 -b 1 -i 5 -t 1200

The first receiver - 128.59.7.10

I could have used iperf as the receiver but already had rtpqual laying around so I used it:
rtpqual 224.5.6.7 8910

The second receiver - 128.59.7.11

Same as the first:
rtpqual 224.5.6.7 8910

Methodology

To reproduce this example:
  1. Start iperf running on sender.
  2. Start tcpdump running on each receiver and snooper.
  3. Let simmer for about 2 minutes which will allow enough time for at least one IGMP router advertisement (general query) to be received by each machine, which will provide a "sync" packet to start time in the tcpdump traces.
  4. Start first receiver rtpqual running and let it run for about 3 minutes.
  5. Wait about a minute and then start second reciver.
  6. While rtpqual is running, do a couple "show ip igmp" commands on the switch and router and oberve proper IGMP state being maintained.
  7. Stop first receiver rtpqual.
  8. Wait 30 seconds and stop second receiver rtpqual.
  9. During the next 4 minutes, do several "show ip igmp" commands on the switch and router and observe IGMP state being torn down (or not). Wait until the router has pruned the group.
  10. Let simmer another 2 minutes so the tcpdump traces will contain a couple more router advertisements.
  11. Stop all the tcpdumps and copy the traces up to the data collection and analysis point along with console logs from the switch and router.

Example 2a: HP ProCurve 2626 (H.07.50)

Apparently H.07.50 is quite broken for this case and fails in a manner very similar to the way H.07.31 failed for example 1. I've just learned there's an H.08.53 release so I'm going to try that before wasting more time.

Example 2b: HP ProCurve 2626 (H.08.53)

Apparently H.07.50 had a mib-settable fast-leave option. This is now available in the configuration CLI with H.08.53, so maybe that's what was wrong, above. I'm going to test with and without setting the option and see how it differs....

Example 2c: HP ProCurve 2626 (H.08.53), fast leave set

It appears that H.08.53 is still incorrect. Traffic gets flooded after a while just like with the earlier releases.

Example 2d: HP ProCurve 2626 (H.08.53), fast leave set, igmp delayed-flush 100

The manual says to enable igmp delayed-flush when fast leave is set. This still doesn't fix the flooding problem. Perhaps I didn't set it long enough?

Example 2e: Cisco Catalyst 3750 (12.2(25)SE)

The Cisco seems to correctly implement IMGP v3 snooping for ASM. There are some unusual things that the switch does but they don't break anything. See the detailed analysis for more.

Example 2f: Cisco Catalyst 4500 w/Sup2+ (12.2(25)EW)

Again, the major difference is that the spoofing comes from 0.0.0.0.

Example 2g: Cisco Catalyst 4500 w/Sup2 (8.4(1)GLX)

This is where we see Cisco's CatOS CGMP/IGMPv3 implementation break down: Once a port joins it is never pruned until the last port leaves the group. (This is a documented "feature".) Also, unlike the IOS IGMP spoofing implementations seen previously, all IGMP membership reports are flooded to all ports on the switch. There's nothing really wrong with this as IGMP v3 specifies that the membership reports all go to 224.0.0.22 and there is no idle member as there is with IGMPv2. Also different from the IOS implementation is the fact that group-specific queries are supressed to ports that are not joined.

IGMP v2 ASM tests

Example 3: Single remote ASM source with one receiver
Example 4: Single remote ASM source with two receivers

IGMP v2 is still very common, so do some testing here for basic functionality and, if the switch you are stuck with is too old or broken, it may simply not work with IGMP v3 and you'll have to force v2 (and lose the ability to do SSM).

Example 3: Single remote ASM source with one receiver

This is a repeat of example 1, just forcing IGMP v2 instead of v3.

The router

The router is a Cisco Catalyst 6509 with MSFC2 running native IOS 12.1(22)E running IGMP version 2. The hublet in front of the switch is connected to a Fast Ethernet port:
interface FastEthernet7/37
 description test subnet
 ip address 128.59.7.1 255.255.255.0
 ip helper-address 128.59.59.25
 ip helper-address 128.59.31.79
 no ip redirects
 no ip unreachables
 ip pim sparse-mode
 speed 10
 duplex half
end

Example 3a: HP ProCurve 2626 (H.08.53), fast leave set, igmp delayed-flush 100

IGMP v2 support seems to be correct, with fast leave happening properly. There is some minor multicast leakage to all ports when the router sends the final two group-specific queries. Again, these shouldn't be sent to non-multicast joiners but they are. Since IGMP v2 sends the IGMP protocol messages to the data multicast address, the data also leaks through. This could cause a 2-second or so DoS for high bandwidth multicast, especially if there's a mix of fast and slow hosts on the same switch.

Example 3b: Cisco Catalyst 3750 (12.2(25)SE)

The Cisco seems to correctly implement IGMP v2 snooping. As with IGMP v3 with ASM, there are the same unusual things that the switch does but they don't break anything. Unlike the HP, no multicast data leaks are observed. See the detailed analysis for more.

Example 3c: Cisco Catalyst 4500 w/Sup2+ (12.2(25)EW)

Unlike example 2f, above, when running IGMP v2 the spoofed leave comes from host 10, not from the all zeroes address.

Example 3d: Cisco Catalyst 4500 w/Sup2 (8.4(1)GLX)

xxx

Example 4: Single remote ASM source with two receivers

Example 4a: HP ProCurve 2626 (H.08.53), fast leave set, igmp delayed-flush 100

With two receivers, snooping behavior works as well as in example 3a. The switch seems to suppress some of the host membership reports (rate limiting?) but passes others through, including host 11's membership reports and host 10's leave. There's still that annoying leakage to non-group member ports as in example 3a.

Example 4b: Cisco Catalyst 3750 (12.2(25)SE)

As it did for IGMP v3, the Cisco works correctly for IGMP v2. It is interesting to note that the switch spoofs a router-generated group-specific query when the final leave group is received. This query has a 5 second max reponse time. After the 5 seconds expire, the switch then forwards the leaving host's group leave up to the router which then sends two 1-second max response queries before pruning the interface.

Example 4c: Cisco Catalyst 4500 w/Sup2+ (12.2(25)EW)

Nothing surprising here.

Example 4d: Cisco Catalyst 4500 w/Sup2 (8.4(1)GLX)

xxx

IGMP v3 SSM tests

Example 5: Single remote SSM source with one receiver
Example 6: Two remote ASM sources for the same group with two receivers

In the SSM tests, we want to see a couple of things: First, see if SSM snooping works at all. Second, does it properly filter traffic to only come from the S in the (S,G) or does it just do a (*,G) which could lead to unwanted traffic being sent through to the host. Be pleasantly surprised if the switch does (S,G) filtering as this is hard given the switch is probably just setting entries in the MAC forwarding table.

Example 5: Single remote SSM source with one receiver

The topology of this example is just like that of example 1. iperf is used to send to an SSM group and a SSMified version of rtpqual is used as the receiver.

The source - 128.59.39.150

I used iperf for the multicast source:
iperf -u -c 232.5.6.7 -p 8910 -T 10 -b 1 -i 5 -t 1200

The receiver - 128.59.7.10

I didn't have a simple command line SSM receiver so I hacked SSM support into rtpqual (thanks to Stig Venaas).
rtpqual 128.59.39.150@232.5.6.7 8910

Methodology

To reproduce this example:
  1. Start iperf running on sender.
  2. Start tcpdump running on each receiver and snooper.
  3. Let simmer for about 2 minutes which will allow enough time for at least one IGMP router advertisement (general query) to be received by each machine, which will provide a "sync" packet to start time in the tcpdump traces.
  4. Start receiver rtpqual running and let it run for about 2 minutes.
  5. While rtpqual is running, do a couple "show ip igmp" commands on the switch and router and oberve proper IGMP state being maintained.
  6. Stop receiver rtpqual.
  7. During the next 4 minutes, do several "show ip igmp" commands on the switch and router and observe IGMP state being torn down (or not). Wait until the router has pruned the group.
  8. Let simmer another 2 minutes so the tcpdump traces will contain a couple more router advertisements.
  9. Stop all the tcpdumps and copy the traces up to the data collection and analysis point along with console logs from the switch and router.

Example 5a: HP ProCurve 2626 (H.08.53)

SSM joins works as well as ASM join with v3 -- which is not that well.

Example 5b: Cisco Catalyst 3750 (12.2(25)SE)

This looks just like the IGMP v3 for ASM example, warts and all.

Example 5c: Cisco Catalyst 4500 w/Sup2+ (12.2(25)EW)

In this example, we see that the 4500/Sup2+ spoofs new IGMP v3 membership reports rather than just passing them through like the 3750 did. Some host reports are suppressed, and some wholly new IGMP reports are spoofed by the switch. Group-specific router queries are passed through intact though. There is also no longer a spoofed IGMP v2 Leave.

Example 5d: Cisco Catalyst 4500 w/Sup2 (8.4(1)GLX)

xxx

Example 6: Two remote SSM sources for the same group with two receivers

This is just like example 5 with a second source sending to the same group and with host 10 receiving from one and host 11 receiving from the other.

The first source - 128.59.39.150

I used iperf for the multicast source:
iperf -u -c 232.5.6.7 -p 8910 -T 10 -b 1 -i 5 -t 1200

The second source - 128.59.36.67

Just like for source one:
iperf -u -c 232.5.6.7 -p 8910 -T 10 -b 1 -i 5 -t 1200

The first receiver - 128.59.7.10

I didn't have a simple command line SSM receiver so I hacked SSM support into rtpqual (thanks to Stig Venaas).
rtpqual 128.59.39.150@232.5.6.7 8910

The second receiver - 128.59.7.11

rtpqual 128.59.36.67@232.5.6.7 8910

Methodology

To reproduce this example:
  1. Start iperf running on both senders.
  2. Start tcpdump running on each receiver and snooper.
  3. Let simmer for about 2 minutes which will allow enough time for at least one IGMP router advertisement (general query) to be received by each machine, which will provide a "sync" packet to start time in the tcpdump traces.
  4. Start both receiver rtpquals running and let them run for about 2 minutes.
  5. While rtpqual is running, do a couple "show ip igmp" commands on the switch and router and oberve proper IGMP state being maintained.
  6. Stop receiver rtpqual.
  7. During the next 4 minutes, do several "show ip igmp" commands on the switch and router and observe IGMP state being torn down (or not). Wait until the router has pruned the group.
  8. Let simmer another 2 minutes so the tcpdump traces will contain a couple more router advertisements.
  9. Stop all the tcpdumps and copy the traces up to the data collection and analysis point along with console logs from the switch and router.

Example 6a: HP ProCurve 2626 (H.08.53)

Due to the HP IGMP v3 bugs we can't really do much more SSM testing.

Example 6b: Cisco Catalyst 3750 (12.2(25)SE)

IGMP snooping works correctly as previously determined. Data from both sources is seen by both receivers, demonstrating that this switch is likely just adding G's Ethernet multicast address to the switch's bridge table.

Example 6c: Cisco Catalyst 4500 w/Sup2+ (12.2(25)EW)

As expected, traffic from both sources is received on both receivers' ports as the multicast membership is done just by group. Also, we can again note 0.0.0.0 source address of spoofed IGMP v3 messages from the switch to the router.

Example 6d: Cisco Catalyst 4500 w/Sup2 (8.4(1)GLX)

xxx

Multicast Source Tests

Example 8: One ASM sender. No receivers.
Example 9: One ASM sender. One remote receiver.
Example 10: One ASM sender. One local receiver.

While the main focus of these tests so far has been on multicast receivers, there are also some multicast transmitter issues. The most important issue is whether flooding of a multicast orginated on a switch for a group that has no listeners can be prevented. (This is why some vendors like Vbrick have added a "join own multicast" option to their multicast appliances.)

Example 8: One ASM sender. No receivers.

The source - 128.59.7.10

I used iperf for the multicast source:
iperf -u -c 224.5.6.7 -p 8910 -T 10 -b 1 -i 5 -t 1200

Methodology

To reproduce this example:
  1. Start tcpdump running on each switch-connected host and snooper.
  2. Let simmer for about 2 minutes which will allow enough time for at least one IGMP router advertisement (general query) to be received by each machine, which will provide a "sync" packet to start time in the tcpdump traces.
  3. Start iperf sending on host 10 and let simmer for a few minutes.
  4. Check router and switch to see if there's any state for G.
  5. Stop iperf sending on host 10.
  6. Let simmer another 2 minutes so the tcpdump traces will contain a couple more router advertisements.
  7. Stop all the tcpdumps and copy the traces up to the data collection and analysis point along with console logs from the switch and router.

Example 8a: HP ProCurve 2626 (H.08.53)

As expected, the switch floods this traffic to all ports, since there were no IGMP messages sent to express interest in G. Of course, the expected behavior is also the kind that wreaks havoc on a subnet.

Example 8b: Cisco Catalyst 3750 (12.2(25)SE)

This switch seems to magically do just what we wanted. A multicast to G is not flooded out to the other ports on the switch. It only gets sent up to the router. (Ignore the 224.0.0.251 traces for host 13; I upgraded to FC3 and they added some zeroconf junk which I've now disabled).

Example 8c: Cisco Catalyst 4500 w/Sup2+ (12.2(25)EW)

As with the Cat 3750, the 4500/Sup2+ magically supresses flooding of the sourced multicast out the other host ports. It only goes to the router port.

Example 9: One ASM sender. One remote receiver.

The topology of this example is just like that of example 8. (Since the HP is known to be broken for IGMP v3, I've downgraded the router to v2 for this example.)

The remote receiver - 128.59.39.150

I used rtpqual for the receiver
rtpqual 224.5.6.7 8910

Methodology

To reproduce this example:
  1. Start tcpdump running on each switch-connected host and snooper.
  2. Let simmer for about 2 minutes which will allow enough time for at least one IGMP router advertisement (general query) to be received by each machine, which will provide a "sync" packet to start time in the tcpdump traces.
  3. Start iperf sending on host 10 and let simmer for a few minutes.
  4. Check router and switch to see if there's any state for G.
  5. Start rtpqual receiver on remote host and let it run for a while.
  6. Stop rtpqual receiver on remote host and let things simmer.
  7. Stop iperf sending on host 10.
  8. Let simmer another 2 minutes so the tcpdump traces will contain a couple more router advertisements.
  9. Stop all the tcpdumps and copy the traces up to the data collection and analysis point along with console logs from the switch and router.

Example 9a: HP ProCurve 2626 (H.08.53)

As in example 8a, the HP floods the traffic to all ports. Having a remote listener of course doesn't add any IGMP traffic to the switch so there's no change.

Example 9b: Cisco Catalyst 3750 (12.2(25)SE)

Just like in example 8b, the switch magically supresses multicast traffic to non-interested ports.

Example 9c: Cisco Catalyst 4500 w/Sup2+ (12.2(25)EW)

No surprises here.
Example 10: One ASM sender. One local receiver.

This is just example 9 with the receiver local to the same switch as the source to see what's different. Same methodology, just the receiver moves to host 11.

The local receiver - 128.59.7.11

rtpqual 224.5.6.7 8910

Example 10a: HP ProCurve 2626 (H.08.53)

In this example, we see that the multicast traffic sourced by host 10 is flooded to all ports on the switch until host 11 joins the group, at which point the traffic is no longer sent to the remaining non-interested port (host 12).

Example 10b: Cisco Catalyst 3750 (12.2(25)SE)

As with examples 8b and 9b, the Cisco supresses multicast traffic to disinterested ports from the get-go and properly does the join when it needs to.

Example 10c: Cisco Catalyst 4500 w/Sup2+ (12.2(25)EW)

No surprises here.

More IGMP v3 Tests

Example 11: Two ASM receivers on same host.
Test some more advanced features of IGMP v3. For example, whereas IGMP v2 can only report a single group membership in a host report, v3 can send several group records within a single IGMP message. See what the switch does with this.

Additional things to test might included more sophisticated include/exclude processing, trying to see what the threshold (if any) is for the switch to handle with respect to more complex IGMP messages. Example 11: Two ASM receivers on same host.

In this example, we run multiple listeners on the same host since the IGMP membership reports lump all the group records into a single report (at least they do for Linux kernel 2.6). How does the switch handle that?

The source - 128.59.39.150

I used iperf for the multicast sources:
iperf -u -c 224.5.6.7 -p 8910 -T 10 -b 1 -i 5 -t 1200 &
iperf -u -c 225.5.6.8 -p 8910 -T 10 -b 1 -i 5 -t 1200 &

The local receiver - 128.59.7.10

I used rtpqual for the receiver:
rtpqual 224.5.6.7 8910 &
rtpqual 224.5.6.8 8910 &

Methodology

To reproduce this example:
  1. Start tcpdump running on each switch-connected host and snooper.
  2. Let simmer for about 2 minutes which will allow enough time for at least one IGMP router advertisement (general query) to be received by each machine, which will provide a "sync" packet to start time in the tcpdump traces.
  3. Start two iperfs sending on remote source and let simmer for a few minutes.
  4. Check router and switch to see if there's any state for G.
  5. Start rtpqual receivers on host 10 and let it run for a while.
  6. Stop rtpqual receivers on remote host and let things simmer.
  7. Let simmer another 2 minutes so the tcpdump traces will contain a couple more router advertisements.
  8. Stop all the tcpdumps and copy the traces up to the data collection and analysis point along with console logs from the switch and router.

Example 11a: HP ProCurve 2626 (H.08.53)

xxx

Example 11b: Cisco Catalyst 3750 (12.2(25)SE)

The linux host combines the two group records into a single IGMP membership report that is sent in response to the router's general query. These are passed through unmolested to the router. As previsouly seen, when the host leaves each group, the switch supresses the first of the router's two 1-second group specific queries and spoofs it with a 5-second query. However, the second 1-second query is allowed through. There's also that pesky IGMP v2 leave that the switch spoofs.

Example 11c: Cisco Catalyst 4500 w/Sup2+ (12.2(25)EW)

Interesting. The host sends the initial Change to Exclude mode messages for G1 and G2 as separate messages. However, for all following membership reports sent in response to the 60-second general query from the router, the Linux kernel lumps these reports together into a single IGMP message. However, the switch then turns around and breaks these up into independent spoofed messages from the 0.0.0.0 address to the router, turning a single host report into two.

Miscellany

Example 7: Cisco Catalyst 3750 (12.2(25)SE) one SSM receiver, one SSM source; mixed IGMP v2/v3

Uggh. Somehow the router is advertising IGMP v2 and v3 and this has made a mess. I think what happened is I didn't wait long enough between switching the interface from v2 to v3.... This will be an interesting case for the interested reader to decipher:-)
xxx - also test overlapping IP/MAC addresses to see if the switch is filtering on IP or MAC address.

Tools

Iperf(Note iperf version 2 has a bug in which it says it is setting the multicast TTL but in fact the value is set to 1.
SSMified version of rtpqual
Vanilla (non-SSM) version of rtpqual
Windows vanilla (non-SSM) rtpqual.exe (Note: requires Cygwin1.dll - run Cygwin setup and install a minimal installation to get the DLL and then make sure it's in your PATH.)
Ethereal

Hints & Kinks

Danno's configuration notes for:
HP switches
Dell Switches

Paul Congdon's comments:
HP IGMP support for various models

Acknowledgements

My thanks to the members of the Internet2 Multicast Working Group and especially the Hands-on Multicast Workshop instructors and participants who prompted me to perform these experiments in order to better understand and teach the LAN multicast portion of the workshop. Special thanks to those who responded to my requests for LAN mulitcast war stories sent to the wg-multicast mailing list:
Charles Anderson, WPI
Bill Cerveny, Internet2
Matt Davy, Indiana University
Marshall Eubanks, Telesuite
Debbie Fligor, University of Illinois
Richard Mavrogeanes, Vbrick
Dave McGaugh, University of Washington
Joe Pautler, University at Buffalo
Dan Pritts, Internet2