[f-nsp] Multicast is being switched by LP CPU on MLXe?

[Eldon Koyle]

I remember having a lot of trouble with multicast.  I don't have the docs
handy, but I think there are some multicast cpu-protection commands you
could try.

-- 
Eldon Koyle
On Mar 29, 2016 9:21 PM, "Eldon Koyle" <ekoyle at gmail.com> wrote:

> I remember having a lot of trouble with multicast.  I don't have the docs
> handy, but I think there are some multicast cpu-protection commands you
> could try.
>
> --
> Eldon Koyle
> On Mar 29, 2016 6:20 AM, "Alexander Shikoff" <minotaur at crete.org.ua>
> wrote:
>
>> Hello!
>>
>> I have some VLANs configured between certain ports on MLXe box (MLXe-16,
>> 5.7.0e).
>> All ports are in 'no route-only' mode. For example:
>>
>> telnet at lsr1-gdr.ki(config)#show vlan 720
>>
>> PORT-VLAN 720, Name V720, Priority Level 0, Priority Force 0, Creation
>> Type STATIC
>> Topo HW idx    : 65535    Topo SW idx: 257    Topo next vlan: 0
>> L2 protocols   : NONE
>> Statically tagged Ports    : ethe 7/1 ethe 9/5 ethe 10/6 ethe 11/6 ethe
>> 13/3
>> Associated Virtual Interface Id: NONE
>> ----------------------------------------------------------
>> Port  Type      Tag-Mode  Protocol  State
>> 7/1   TRUNK     TAGGED    NONE      FORWARDING
>> 9/5   TRUNK     TAGGED    NONE      FORWARDING
>> 10/6  TRUNK     TAGGED    NONE      FORWARDING
>> 11/6  TRUNK     TAGGED    NONE      FORWARDING
>> 13/3  PHYSICAL  TAGGED    NONE      FORWARDING
>> Arp Inspection: 0
>> DHCP Snooping: 0
>> IPv4 Multicast Snooping: Enabled - Passive
>> IPv6 Multicast Snooping: Disabled
>>
>> No Virtual Interfaces configured for this vlan
>>
>>
>>
>> As you may notice, passive multicast snooping is enabled on that VLAN.
>> The problem is that multicast traffic is being switched by LP CPU,
>> causing high CPU utilization and packet loss.
>>
>> It is clearly seen on rconsole:
>>
>> LP-11#debug packet capture rx include src-port me/6 vlan-id 720
>> dst-address 233.191.133.96
>> [...]
>> **********************************************************************
>> [ppcr_tx_packet] ACTION: Forward packet using fid 0xa06d
>> [ppcr_rx_packet]: Packet received
>> Time stamp : 56 day(s) 20h 48m 05s:,
>> TM Header: [ 0564 0aa3 0080 ]
>> Type: Fabric Unicast(0x00000000) Size: 1380 Class: 0 Src sys port: 2723
>> Dest Port: 0  Drop Prec: 2 Ing Q Sig: 0 Out mirr dis: 0x0 Excl src: 0 Sys
>> mc: 0
>> **********************************************************************
>> Packet size: 1374, XPP reason code: 0x000095cc
>> 00: 05f0 0003 5c50 02d0-7941 fffe 8000 0000  FID     = 0x05f0
>> 10: 0100 5e3f 85b0 e4d3-f17d a7c5 0800 4516  Offset  = 0x10
>> 20: 0540 0000 4000 7e11-f89f b060 df26 e9bf  VLAN    = 720(0x02d0)
>> 30: 85b0 04d2 04d2 052c-0000 4701 3717 8134  CAM     = 0x0ffff(R)
>> 40: 01d0 92de c56f 18f6-dc4f 8d00 1273 cdb3  SFLOW   = 0
>> 50: c3ff 3da8 2600 5a37-cfbe 993f dbfd c927  DBL TAG = 0
>> 60: 8000 8290 ef9b 7638-9089 9a50 5000 8611
>> 70: 2026 0079 8de2 a404-1013 dffd 04e0 1404
>> Pri CPU MON SRC   PType US BRD DAV SAV DPV SV ER TXA SAS Tag MVID
>> 0   0   0   11/6  3     0  1   0   1   1   1  0  0   0   1   0
>>
>> 176.96.223.38 -> 233.191.133.176 UDP [1234 -> 1234]
>> **********************************************************************
>>
>> As far as I understand documentation that should not happen.
>> The situation remains the same if I disable IGMP snooping.
>>
>> Any ideas/suggestions is kindly appreciated!
>>
>> Thanks in advance.
>>
>> --
>> MINO-RIPE
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp at puck.nether.net
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20160329/32d49187/attachment.html>