[c-nsp] Sup720, multicast bothers the CPU

[Matthew Huff]

Anything in the 224.0.0.0/24 subnet is equivalent to a broadcast address in the local subnet and will be punted to the CPU.

http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml


I've seen some software that has used 224.0.0.1 for the multicast destination address and will hose your network. Nothing other than control protocols should use 224.0.0.0-224.0.0.255.



The 224.0.1.40 is for Cisco RP discovery and is normal
The 239.255.255.250 is SSDP and is a Microsoft Thing and is normal
The 239.255.255.253 is SLP and is normal



----
Matthew Huff             | 1 Manhattanville Rd
Director of Operations   | Purchase, NY 10577
OTA Management LLC       | Phone: 914-460-4039
aim: matthewbhuff        | Fax:   914-460-4139

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Rathlev
Sent: Friday, March 25, 2011 6:00 AM
To: John Neiberger
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Sup720, multicast bothers the CPU

On Wed, 2011-03-23 at 20:55 +0100, Peter Rathlev wrote:
> Thanks. We'll try just adding "ip igmp snooping querier" to the specific
> SVI to see if this in itself would be enough. Next up we try "ip pim
> sparse-mode" on the SVI and "ip multicast-routing" in global.
> 
> I'll keep the list updated on how it went. :-)

We now tried both adding an IGMP Querier and enabling multicast-routing
and PIM. None of these things stopped the multicast traffic from hitting
the CPU.

I'm a little puzzled that we actually saw _some_ sources:

xxx#sh ip igmp membership 
[...]
 *,239.255.255.253              10.26.46.78     00:02:41 02:46 2A     Vl46
 *,239.255.255.250              10.26.46.77     00:02:43 02:46 2A     Vl46
 *,224.0.1.40                   10.26.46.254    00:02:43 02:53 2LA    Vl46
xxx#

Just not from the "interesting" groups. We tried restarting both a
receiver and a source to see if anything changed, and we never saw joins
or "*,<something>".

So a few questions more:

 1) Could "offset != 0" somehow mean that the flows cannot be hardware
    switched at all? Every single packet has offset != 0, i.e. no packet
    observed with offset == 0. We were looking at both an RP SPAN
    session and a SPAN session covering the VLAN in question.

 2) Could 224.0.0.0/24, which they use for this purpose though that's
    wrong, somehow be treated specially by a Sup720? Any chance it would
    help using 239.255.255.0/24 instead?

Thanks in advance.

-- 
Peter



_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/