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

Alexander Shikoff minotaur at crete.org.ua
Wed Mar 30 05:24:03 EDT 2016


Hi!

On Wed, Mar 30, 2016 at 08:34:43AM +0000, Jan Pedersen wrote:
>    Multicast cpu-protection and snooping is not possible at the same time.
> 
> 
>    Have you configured both multicast passive and multicast pimsm-snooping under the vlan
>    configuration for vlan 720?
Nope, there is no PIM in VLAN 720 et-all.
Customers are using IGMP v2 in order to access multicast streams.
Anyway, I've configured both multicast passive and multicast pimsm-snooping,
and that didn't help. Multicast packets are still forwarded by CPU.

The only thing which helped a bit is 'multicast-flooding' in VLAN 
configuration, but it seems that then IGMP packets does not pass that VLAN...
I'm debugging that right now.

> 
>    multicast passive
> 
>    multicast pimsm-snooping
> 
> 
>    /Jan
> 
> 
>    From: foundry-nsp [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Eldon Koyle
>    Sent: 30. marts 2016 06:33
>    Cc: foundry-nsp <foundry-nsp at puck.nether.net>
>    Subject: Re: [f-nsp] Multicast is being switched by LP CPU on MLXe?
> 
> 
>    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" <[1]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" <[2]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:
>      [3]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
>      [4]foundry-nsp at puck.nether.net
>      [5]http://puck.nether.net/mailman/listinfo/foundry-nsp
> 
> Посилання
> 
>    1. mailto:ekoyle at gmail.com
>    2. mailto:minotaur at crete.org.ua
>    3. mailto:telnet at lsr1-gdr.ki
>    4. mailto:foundry-nsp at puck.nether.net
>    5. http://puck.nether.net/mailman/listinfo/foundry-nsp

> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp


-- 
MINO-RIPE


More information about the foundry-nsp mailing list