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" <[email protected]> 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" <[email protected]> > 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: >> >> [email protected](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 >> [email protected] >> http://puck.nether.net/mailman/listinfo/foundry-nsp >> >
_______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
