I choose to buy a SRW224G4P with this documentation:
On this documentation, the switch is able to use IGMP v3 and IGMP querier:
p99: IGMP Version
Sets the protocol version for compatibility with other devices on the network. All systems on the subnet must support the same version. Also note that some attributes are only enabled for IGMPv2 and/or v3, including Act as IGMP Querier, IGMP Report Delay and IGMP Query Timeout. (Range: 1-3; Default: 2)
The switch that I receive is note able to do this.
The version of the firmware describe in this documentation is:
p32: Firmware Version 1.2.4 Aug 27 2008
And my switch has the version 1.0.2 which is the only available on the Cisco website at
Where can I find this new firmware?
I bought this switch for a VOD network, and I really need this features.
Thanks for your help
I have confirmed your observations on our documentation and firmware availability. We are looking into this.
In the meantime, could you provide more information on your project implementation? Routers and switches, what models, topology, design goals etc.
This is just for a demo system.
In this system, we have a server witch send some unicast channel for the VOD and some multicast channel for the Pay TV feature.
We will receive also a TV gateway which will send in multicast all channel that we are able to receive by satellites.
The Set-Up Box (just 2 for now in this demo) have just a 100Mbps interface.
That's why I need the IGMP v2 feature with fast-leave or IGMP v3 and IGMP querier to be able to send just the channel which is currently displayed on the Set-Up Box. Without that, the Set-Up Box will not leave the multicast group.
I am sorry to ask you again, but have you found this firmware?
I have some clients who will comme during the next week, and that's would be better if I need not to ask them to don't browse more than 5 channels.
Thanks for your help,
We have not been able to locate the firmware shown in the documentation as of yet. We are still trying. Even if we can find it, It is unlikely that it will be made available for public download. When I find out, I will let you know what the deal is.
Thank you for your patients,
Thanks for the new firmware available.
I found the features that I need on this one (v1.3.1), but...
- The switch seems to have some difficulties with the IGMP v3 (some freeze and reboot), there's no big deal in my case, the switch is also able to do the IGMP v2 with fast leave (remove the port from the Multicast group immediately when receive the IGMP leave message).
- The switch is not able to receive some multicast group on more than one port:
If I send 3 multicast video from my server and 3 other from my TV gateway, the Set-Top Box have some glitch on any of this 6 channels (which probably means that some packet are lost).
If I send 88 multicast video from my TV gateway or 13 from the server, all of them are displayed without trouble.
If I use a basic gigabit switch (SD2008) (which broadcast the multicast) to put the server and the TV gateway on only one port of the SRW224G4P, I can send the 88 multicast video from the TV gateway and the 13 from the server, and display them on the Set-Top Box without trouble.
I try to change some parameters by enable/disable the flow control, the storm control, the multicast static router ports but without success.
I must say that I am really disappointed by this switch, that's the first time that I use a Cisco switch for this system, commonly we use the HP ProCurve switch, with which we have no trouble to use the multicast.
Got a few questions regarding your posting.
I am using RFC 4541 as a reference.
Section 2.1.1 : IGMP forwarding rules mentions ;
A snooping switch should forward IGMP Membership Reports only to those ports where multicast routers are attached.
This statement brings up a interesting point as to what is your Layer 3 querier or router in this test network, and I guess
you must have a router in the mix of equipment?
On My network, I have my SRW2008P connected to my UC520 (only 8 user
SKU). My Layer 3 UC520 is my IGMP router and querier.
My concern here is understanding which streams have registered via sending a
join with group membership with a Layer 3 Querier, your router.
If a set top box has sent a membership report or join to a particular group then other switch ports on the SRW224G4P
will not receive the flood of that multicast stream.
But if no one has joined the stream that is flooded into that switch , as the RFC suggests on page 6 section 3 "
“A switch may default to forwarding unregistered packets on all ports."
So having pasted that for your reference, I checked out the behavior in my test network.
I had setup four streams from my Multicast IP TV server.
These four streams just blasted into the switch with no membership query or joins from my set top box
and a result they were flooded to my ethereal PC on a separate switch port.
This is expected behaviour.
My set top box joined a 4th stream, at that point my SRW2008P switch stopped the flow of that stream to my ethereal PC.
Or in other words my SRW2008P igmp snooping module made that intelligent decision to
stop the flow of that 4th stream to my PC. This PC being on a separate switch port compared to my set top box.
To better understand what is going on I need to know more about your test environment, but this behaviour follows the RFC mentioned..
But does this default behavior sound familiar, i just don;t have enough information to check what might be happening on your system.
That's would be easier with a schema...
The STB, the server, and the TV gateway use the IGMP v2 and send the join/leaves messages.
I do not use any other equipment; I use the SRW224G4P like you use your UC520.
I use the SD2008 switch only to insert the multicast stream of the TV gateway and the server on the same port of the SRW224G4P, which seems to be not able to work properly otherwise.
The TV gateway and the servers both send join/leaves message and also answer to the IGMP querier which register all multicast IP, and avoid what is suggested by the RFC on page 6 section 3.
That's work properly, and the switch react quickly to the join/leaves messages if the multicast are send on only one port, and if there is not so much multicast channel send in the same times. Indeed, after some other tests, if I stream all the channels that receive the TV gateway (more than80), the switch is lost and do not listen all the messages. In this case, all the multicast IP are already listed on the switch management interface, but no ports are attached to it (neither the Source).
I can understand that the switch has some limits and 80 multicast groups are too much for this switch. But how could you explain that I need to use the SD2008?
Thank-you for the diagram, it helped me better visualize what is happening in your test bed.
The SD2008 works in your environment because it will flood multicasts to all switch ports, that's the way it works. And with over 80 video streams , each one maybe about 4 to 5 Mb/sec the SD2008 with it's 1000MB/sec switch ports will cope with the video load per port,l which I guest-imate is about 300-600Mb/sec. (not sure if you have HDIPTV or not HD TV)
The SD2008 is also invisible to VLANs, so VLAN tags will pass through the SD2008 without being dropped..
So lets look at the RFC again, and take note of the bold blue section;
According to the details stated previously in RFC 4541 under section 2.1.2 entitled "Data Forwarding Rules"
3) An unregistered packet is defined as an IPv4 multicast packet with
a destination address which does not match any of the groups
announced in earlier IGMP Membership Reports.
If a switch receives an unregistered packet, it must forward that
packet on all ports to which an IGMP router is attached. A switch
may default to forwarding unregistered packets on all ports.
So basically the SRW224G4P defaults to forwarding all unregistered packets on all switch ports in conformance to the RFC.
So your SRW224G4P, when you join a group, that group is now only going to that STB, but the other 80 or so Multicast groups that are unregistered will try to egress out each switch port. When your STB leaves that multicast group, about 10 seconds later, that multicast stream will be added so that 81 multicast streams will try to egress out all switch ports. The 100TX switch ports will start to tail drop IPTV packets when the load reaches 100MB/sec.
So the reason why the SRW224G4P is not working in your environment is that this switch has 24x 100MB/sec ports.
You should be using a gigabit switch like the SRW2008P or SRW2024P (for poe) in your test bed and not the SRW224G4P.
The contents streamed on the 80 channels are some SD contents or radio contents, for a total of 133Mb/s. Most of them are crypt, so I removed them (while I have not the conax card), and now I have just 3 channels which use 11.3Mbps.
I have also 13 channels send from the server in multicast witch make almost 90Mbps.
If I connect this two sources on the SRW224G4P (with the 3 channels from the TV gateway and just 1 from the server) there is some glitch on the STB, but with wireshark, I can say that this is not a problem due to the bandwidth, the STB receive just his multicast channel.
But as I explain earlier, I can send more multicast channel if they are send from the same port on the SRW224G4P that’s why I use the SD2008. As you said, the SD2008 just flood all the multicasts channels on all his port, so when I plug the server, the TV gateway, and a gigabit port of the SRW224G4P on it, the multicast channels are send on all the ports and the SRW224G4P receive all this channels.
We choose the SRW224G4P because the STB have just a 100Mpbs interface, and there is just the server and the TV gateway which have a gigabit interface. With 24 ports at 100Mbps, 4ports at 1000Mbps, and the IGMP support, the SRW224G4P seemed to be fully qualified for this…
I am not in the case describing into the RFC 4541 under section 2.1.2, all my addresses are registered.
I have 2 different problems with the SRW224G4P, the first is the need to receive the multicast only on one port, which could be solved just by using the SD2008; and the second is the limit of multicast group managed with success by the switch, which I can accept for know.
When this second problem occur, the switch do not listen all the IGMP message which mean that some IP are not register, and their content are broadcasted (but less than 35Mbps). The switch do not listen neither the join message of the STB, nor the message of the TV gateway (answer to the Querier). In this case the TV gateway is not any more into the multicast group, but the address is already registered. In this case if a STB succeed to join the group, the switch has no content to deliver (if the TV gateway is not in the multicast group, the packet of this multicast group are just droped).
I am sorry to be not able to explain it better than this
thanks for your help
Excuse the delay in getting back to you, and the following english term, but there has been some "horse trading" in the delay since we last corresponded, with the Irvine California development folks. I personally didn't like the way the multicast flooded, even though it did conform to the RFC. I saw more opportunities to sell the SRW product for IPTV applications if the behaviour was altered.
My development team will have this behaviour altered in the next version of code, so that unregistered groups will not flood down ports that are not connected to a multicast L3 router, when igmp snooping is enabled. I expect that this software will be available soon, so i was told, but it is going through the cisco software approval process shortly.
As I said, the problem is not the multicast flood, but the fact that this switch is not able to receive the multicast packets on more than one port.
But I agree with you, the way the multicast is flooded in the RFC is not the best choice if there is more multicast channel as what the STB interface can handel, which is the case when the STB could access to many channel with just a 100Mbps interface. That's why the HP ProCurve (I'm sorry that's an other brand) let the choice to the administrator on what to do whith the unregistered multicast packets.
That's seems that cisco is not anymore at the top.