> If it's true L2 multicast, it shouldn't be hitting your RP from my
> understanding of L2 Multicast.
I didn't think so either. But when I turn down the SVI interfaces in those
VLANs, the CPU usage goes down to around 8-9%. Here's the output showing the
CPU usage:
6686588558665866686568555866585558955866685568667865986558656855686568
8371990985129424261948999640989895598405059945041409672886290689060905
100 * *
90 * * * * * * * ** * * ** * * * *
80 * ** * * * * * * ** * * * * ** * * * *
70 * * ** * * * * * * ** * * * * ** ** * * * *
60 **********************************************************************
50 ######################################################################
40 ######################################################################
30 ######################################################################
20 ######################################################################
10 ######################################################################
0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
0 5 0 5 0 5 0 5 0 5 0 5 0
CPU% per hour (last 72 hours)
* = maximum CPU% # = average CPU%
s01#sh proc cpu sort
CPU utilization for five seconds: 59%/48%; one minute: 61%; five minutes: 61%
PID TID 5secUtil 1minUtil 5minUtil
1 1 41.0% 39.3% 39.3%
16406 6 28.8% 28.4% 28.4%
16429 4 7.5% 4.8% 2.9%
16406 22 7.0% 3.4% 3.3%
16406 21 6.5% 3.7% 1.9%
16406 17 4.5% 5.9% 3.9%
s01#show proc cpu detail 16406
CPU utilization for five seconds: 61%/46%; one minute: 61%; five minutes: 61%
PID/TID 5Sec 1Min 5Min Process Prio STATE CPU
16406 51.9% 51.6% 51.4% ios-base 28d18h
1 0.0% 0.0% 0.0% 20 Condvar 0.000
2 1.7% 1.7% 1.6% 5 Ready 1d01h
3 9.2% 3.8% 4.1% 10 Reply 27m38s
4 0.0% 0.0% 0.9% 10 Receive 36m35s
5 0.0% 0.0% 0.0% 11 Nanosleep 2m21s
6 28.3% 28.5% 28.4% 21 Intr 17d05h
7 0.9% 1.8% 2.0% 22 Intr 1d05h
8 0.9% 0.9% 0.9% 23 Intr 12h23m
9 0.0% 0.0% 0.0% 25 Intr 0.000
10 0.0% 0.0% 0.1% 10 Receive 24m13s
11 0.0% 0.0% 0.0% 10 Receive 58m52s
12 0.0% 0.0% 0.0% 10 Condvar 0.001
13 0.0% 0.0% 0.0% 10 Receive 53m01s
According to the caps, it's all L2 mcast with an Ethertype of 8819. Which is
cobranet. If you want to know more about it, knock yourself out:
http://www.peaveyoxford.com/kc/Working%20with%20CobraNet.pdf
I tried to filter using VLAN ACL, but it stopped all communication in the VLAN
for Ethertype 8819.
On 2011-01-19, at 1:46 PM, Max Pierson wrote:
> Here's more info on VACL's ...
>
> http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/vacl.html
>
> Apply the VACL to only drop the traffic if its destination to your RP MAC. If
> it's true L2 multicast, it shouldn't be hitting your RP from my understanding
> of L2 Multicast. (Someone please correct me if i'm wrong).
>
> On Wed, Jan 19, 2011 at 2:40 PM, Devin Kinch <[email protected]> wrote:
>
> But then the traffic would also be filtered out as in enters the VLAN... I
> still need the traffic to pass through the trunk links to the edge
> aggregation switches at each site. I just need to keep it from hitting the
> RP.
>
> Unless I'm confused about where VACLs apply filtering...
>
> On 2011-01-19, at 12:23 PM, Max Pierson wrote:
>
>> VACL's should do the trick for you here. If you know the value of the
>> Ethertype frame, you should still be able to filter on it even though it's
>> proprietary. If you don't, time to break out the shark! I would start off by
>> trying to filter based on ethertype since that won't be common to any other
>> traffic on the wire.
>>
>> Max
>>
>> On Wed, Jan 19, 2011 at 1:54 PM, Devin Kinch <[email protected]> wrote:
>> I have a network running two 6509's with VSS in the core of the network.
>> Several of the attached VLANs are used by an application that transmits
>> audio with a non-IP based layer 2 multicast (016b.68xx.xxxx or something
>> like that) stream. It uses many different destination MAC addresses and the
>> frames have their own vendor proprietary Ethertype. We also need layer 3
>> routing in the same VLANs to manage these devices.
>>
>> The issue I have is that all these layer 2 multicasts are causing the CPU
>> usage on the Sup to hover at around 70-80%. It isn't causing any noticeable
>> impact to the network today, but it may impact future scalability. I've
>> tried using CoPP (which doesn't support L2 filtering)... is there an
>> obvious, elegant way of filtering this traffic from hitting the RP, while
>> still forwarding at layer 2? Perhaps static MAC entries?
>>
>>
>> Devin Kinch
>> _______________________________________________
>> cisco-nsp mailing list [email protected]
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>
>
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
