Multicast group capacity: Extreme comes out on top

Multicast join/leave delay: Arista and Dell are swell

Because many data center applications today make use of IP multicast, scalability is naturally a concern. For layer-2 switched environments, the main measure of IP multicast scalability is group capacity, or the number of Internet group membership protocol (IGMP) snooping entries a switch can keep track of.

Switches snoop or listen for IGMP group membership reports and then should forward traffic only to those ports where hosts have subscribed to specific groups.

Extreme's Summit x650 was the clear leader in multicast group capacity, successfully forwarding traffic to 6,000 groups. The Arista and HP switches were next, each forwarding traffic to 2,047 groups. Cisco's Nexus was a little behind them with 2,000 groups, while the Blade and Dell switches each supported 1,024 groups.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

Because many data center applications today make use of IP multicast, scalability is naturally a concern. For layer-2 switched environments, the main measure of IP multicast scalability is group capacity, or the number of Internet group membership protocol (IGMP) snooping entries a switch can keep track of.

Switches snoop or listen for IGMP group membership reports and then should forward traffic only to those ports where hosts have subscribed to specific groups.

Extreme's Summit x650 was the clear leader in multicast group capacity, successfully forwarding traffic to 6,000 groups. The Arista and HP switches were next, each forwarding traffic to 2,047 groups. Cisco's Nexus was a little behind them with 2,000 groups, while the Blade and Dell switches each supported 1,024 groups.

Multicast join/leave delay: Arista and Dell are swell

There can be real money tied to the speed at which a switch processes requests to join or leave multicast groups. Financial services companies depend on getting quotes quickly; search engine clusters need to keep synchronized for their companies to realize ad revenue; and ISPs with IPTV offerings use multicast to add and remove subscribers. For all these applications and many more, the speed of multicast group join and leave processing is a key consideration.

As with the multicast throughput and latency tests, we used 989 groups and had hosts on all receive ports join all groups. This time, however, we set aside one port as a monitor port that should neither transmit nor receive multicast traffic. This extra port was a check against flooding.

Click to see: Graphic of multicast join/leave

Dell's PowerConnect 8024F had the lowest average join and leave times, followed closely by the Arista and Blade switches. However, Arista's 7124S was more consistent across the board, with the least variation between average and maximum join and leave times. This is largely a function of control-plane processing power, and reflects Arista's use of a dual-core 1.8-GHz x86 CPU, a powerful processor for a top-of-rack switch.

The HP and Cisco switches had much higher join and leave delays than other devices. In the worst case, Cisco's switch took nearly 23 seconds to process a leave message for one group and averaged about 10 seconds to process each leave message. The Nexus join times were much lower, in the low hundreds of milliseconds.

Even if one assumes that leave delays are less important than join delays, there's also another issue with the Nexus switch: It leaks multicast traffic when its control plane is busy. We noticed that whenever the switch was processing responses to IGMP queries, it flooded multicast traffic to that last port – the one with no multicast subscribers, the one that never should have received multicast traffic.

Cisco says this is working-as-designed behavior. It appears that when the switch's CPU is very busy (as it is when processing responses to IGMP queries), the switch will flood multicast traffic to all ports, even those with no subscribers attached. This may be intentional, but at the same time we saw no flooding when running the same test on two Cisco Catalyst switches.