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:
- Will HP be making IGMP v3 snooping work correctly on the 2626? When?
- Does IGMP v3 snooping work correctly on other HP ProCurve models?
- 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?
- 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?
- 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.
- Support for various IGMP versions, especially v3.
- 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?
- Current or planned support of MLD snooping if you plan on running IPv6 during the useful lifetime
of the switch.
- Are downstream hubs handled correctly (e.g. no premature leave)?
- 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.)
- ...
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:
- Start iperf running on sender.
- Start tcpdump running on each receiver and snooper.
- 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.
- Start receiver rtpqual running and let it run for about 2 minutes.
- While rtpqual is running, do a couple "show ip igmp" commands on the
switch and router and oberve proper IGMP state being maintained.
- Stop receiver rtpqual.
- 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.
- Let simmer another 2 minutes so the tcpdump traces will contain a
couple more router advertisements.
- 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:
- Start iperf running on sender.
- Start tcpdump running on each receiver and snooper.
- 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.
- Start first receiver rtpqual running and let it run for about 3 minutes.
- Wait about a minute and then start second reciver.
- While rtpqual is running, do a couple "show ip igmp" commands on the
switch and router and oberve proper IGMP state being maintained.
- Stop first receiver rtpqual.
- Wait 30 seconds and stop second receiver rtpqual.
- 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.
- Let simmer another 2 minutes so the tcpdump traces will contain a
couple more router advertisements.
- 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:
- Start iperf running on sender.
- Start tcpdump running on each receiver and snooper.
- 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.
- Start receiver rtpqual running and let it run for about 2 minutes.
- While rtpqual is running, do a couple "show ip igmp" commands on the
switch and router and oberve proper IGMP state being maintained.
- Stop receiver rtpqual.
- 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.
- Let simmer another 2 minutes so the tcpdump traces will contain a
couple more router advertisements.
- 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:
- Start iperf running on both senders.
- Start tcpdump running on each receiver and snooper.
- 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.
- Start both receiver rtpquals running and let them run for about 2 minutes.
- While rtpqual is running, do a couple "show ip igmp" commands on the
switch and router and oberve proper IGMP state being maintained.
- Stop receiver rtpqual.
- 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.
- Let simmer another 2 minutes so the tcpdump traces will contain a
couple more router advertisements.
- 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:
- Start tcpdump running on each switch-connected host and snooper.
- 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.
- Start iperf sending on host 10 and let simmer for a few minutes.
- Check router and switch to see if there's any state for G.
- Stop iperf sending on host 10.
- Let simmer another 2 minutes so the tcpdump traces will contain a
couple more router advertisements.
- 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:
- Start tcpdump running on each switch-connected host and snooper.
- 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.
- Start iperf sending on host 10 and let simmer for a few minutes.
- Check router and switch to see if there's any state for G.
- Start rtpqual receiver on remote host and let it run for a while.
- Stop rtpqual receiver on remote host and let things simmer.
- Stop iperf sending on host 10.
- Let simmer another 2 minutes so the tcpdump traces will contain a
couple more router advertisements.
- 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:
- Start tcpdump running on each switch-connected host and snooper.
- 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.
- Start two iperfs sending on remote source and let simmer for a few minutes.
- Check router and switch to see if there's any state for G.
- Start rtpqual receivers on host 10 and let it run for a while.
- Stop rtpqual receivers on remote host and let things simmer.
- Let simmer another 2 minutes so the tcpdump traces will contain a
couple more router advertisements.
- 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