<div dir="ltr"><div>It's been a while, but I wouldn't think that pim snooping would not do a darn thing on l2, you would want igmp snooping.  That said, I don't think that would work without at least a local l3 interface to respond to the queries.  Otherwise, you might as well just use broadcast. (Not that I recommend that) <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 19, 2016 at 4:57 AM, Alexander Shikoff <span dir="ltr"><<a href="mailto:minotaur@crete.org.ua" target="_blank">minotaur@crete.org.ua</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span class=""><br>
On Sun, Dec 18, 2016 at 10:03:59AM -0700, Eldon Koyle wrote:<br>
>    What does your pim configuration look like?  Especially your rp  config.<br>
>    Making sure there is no rp-candidate for traffic you want to keep on a single l2 domain can<br>
>    help a lot (in fact, we only add rp entries for specific apps).  This is especially true<br>
>    for groups used by SSDP or mDNS.  It's been a while, but I remember having similar issues.<br>
>    I'll have to go dig through my configs and see if it reminds me of anything else.<br>
<br>
</span>There is no any L3 multicast routing.<br>
Configuration is clear L2.<br>
<br>
>    --<br>
>    Eldon Koyle<br>
<span class="">><br>
>    On Dec 13, 2016 08:29, "Alexander Shikoff" <[1]<a href="mailto:minotaur@crete.org.ua">minotaur@crete.org.ua</a>> wrote:<br>
><br>
>      Hi!<br>
>      Well, I'd like to bring this thread up again hoping to catch<br>
>      someone who has also hit this issue.<br>
>      Today I upgraded software to 05.9.00be, and situation is still<br>
>      the same: with enabled Multicast Traffic Reduction,<br>
>      multicast traffic is being switched by LP CPU.<br>
>      Current test VLAN configuration is:<br>
>      !<br>
>      vlan 450 name ITCons2DS_test<br>
>       tagged ethe 7/1 to 7/2 ethe 9/5 ethe 11/2 ethe 12/8 ethe 13/8<br>
>       multicast passive<br>
>       multicast pimsm-snooping<br>
>      !<br>
</span>>      [2]<a href="http://telnet@lsr1-gdr.ki#show" rel="noreferrer" target="_blank">telnet@lsr1-gdr.ki#show</a> vlan 450<br>
<span class="">>      PORT-VLAN 450, Name ITCons2DS_test, Priority Level 0, Priority Force 0, Creation Type<br>
>      STATIC<br>
>      Topo HW idx    : 65535    Topo SW idx: 257    Topo next vlan: 0<br>
>      L2 protocols   : NONE<br>
>      Statically tagged Ports    : ethe 7/1 to 7/2 ethe 9/5 ethe 11/2 ethe 12/8 ethe 13/8<br>
>      Associated Virtual Interface Id: NONE<br>
>      ------------------------------<wbr>----------------------------<br>
>      Port  Type      Tag-Mode  Protocol  State<br>
>      7/1   TRUNK     TAGGED    NONE      FORWARDING<br>
>      7/2   TRUNK     TAGGED    NONE      FORWARDING<br>
>      9/5   TRUNK     TAGGED    NONE      FORWARDING<br>
>      11/2  TRUNK     TAGGED    NONE      FORWARDING<br>
>      12/8  TRUNK     TAGGED    NONE      FORWARDING<br>
>      13/8  TRUNK     TAGGED    NONE      FORWARDING<br>
>      Arp Inspection: 0<br>
>      DHCP Snooping: 0<br>
>      IPv4 Multicast Snooping: Enabled - Passive<br>
>      IPv6 Multicast Snooping: Disabled<br>
>      No Virtual Interfaces configured for this vlan<br>
>      IGMP snooping works, I'm able to see In/Out interfaces and current<br>
>      active querier:<br>
</span>>      [3]<a href="http://telnet@lsr1-gdr.ki#show" rel="noreferrer" target="_blank">telnet@lsr1-gdr.ki#show</a> ip multicast vlan 450<br>
<span class="">>      ----------+-----+---------+---<wbr>------------+-----+-----+-----<wbr>-<br>
>      VLAN       State Mode      Active          Time (*, G)(S, G)<br>
>                                 Querier         Query Count Count<br>
>      ----------+-----+---------+---<wbr>------------+-----+-----+-----<wbr>-<br>
>      450        Ena   Passive   192.168.210.1   119   1     1<br>
>      ----------+-----+---------+---<wbr>------------+-----+-----+-----<wbr>-<br>
>      Router ports: 12/8 (11s)<br>
>      Flags-  R: Router Port,  V2|V3: IGMP Receiver,  P_G|P_SG: PIM Join<br>
>        1    (*, 239.32.4.130) 00:34:48       NumOIF: 1       profile: none<br>
>                Outgoing Interfaces:<br>
>                     e9/5 vlan 450 ( V2) 00:34:48/40s<br>
>        1    (91.238.195.1, 239.32.4.130) in e11/2 vlan 450 00:34:48          NumOIF: 1<br>
>      profile: none<br>
>                Outgoing Interfaces:<br>
>                     TR(e9/5,e7/1) vlan 450 ( V2) 00:34:48/0s<br>
>                FID: 0xa0a9     MVID: None<br>
>      Right after multicast stream start flooding from Eth11/2 out of TR(e9/5,e7/1),<br>
>      the CPU load on LP 11 increases:<br>
</span>>      [4]<a href="http://telnet@lsr1-gdr.ki#show" rel="noreferrer" target="_blank">telnet@lsr1-gdr.ki#show</a> cpu-utilization lp 11<br>
<div><div class="h5">>      17:25:10 GMT+02 Tue Dec 13 2016<br>
>      SLOT  #:               LP CPU UTILIZATION in  %:<br>
>                   in 1 second:  in 5 seconds:  in 60 seconds: in 300 seconds:<br>
>          11:        6             6              6               6<br>
>      And I see these packets processed by LP CPU:<br>
>      LP-11#debug packet capture include vlan-id 450<br>
>      [...]<br>
>      91.238.195.1 -> 239.32.4.130 UDP [2000 -> 2000]<br>
>      ******************************<wbr>******************************<wbr>**********<br>
>      [ppcr_tx_packet] ACTION: Forward packet using fid 0xa0a9<br>
>      [xpp10ge_cpu_forward_debug]: Forward LP packet<br>
>      Time stamp : 00 day(s) 11h 32m 49s:,<br>
>      TM Header: [ 1022 00a9 a0a9 ]<br>
>      Type: Multicast(0x00000000) Size: 34 Mcast ID: 0x9a0 Src Port: 2<br>
>      Drp Pri: 2 Snp: 2 Exclude Src: 0 Cls: 0x00000001<br>
>      ******************************<wbr>******************************<wbr>**********<br>
>      00: a0a9 0403 5e50 41c2-7840 0abc 4400 0000  FID     = 0xa0a9<br>
>      10: 0100 5e20 0482 f4cc-55e5 4600 0800 4588  Offset  = 0x10<br>
>      20: 0540 08df 0000 3d11-5cb4 5bee c301 ef20  VLAN    = 450(0x01c2)<br>
>      30: 0482 07d0 07d0 052c-0000 4701 e11a 8534  CAM     = 0x00055e<br>
>      40: 5a95 fb85 94ee 0b69-9938 967a c827 f571  SFLOW   = 0<br>
>      50: 73cc 8e72 98cc 82e0-436e 30f1 4414 f400  DBL TAG = 0<br>
>      60: 11fd 7b2b c8be d9ca-d0fa 44d0 45b5 53e5<br>
>      70: a386 ac24 cc0b 9698-c0a2 ff65 9f32 6b14<br>
>      Pri CPU MON SRC   PType US BRD DAV SAV DPV SV ER TXA SAS Tag MVID<br>
>      4   0   0   11/2  3     0  1   0   1   1   1  1  0   0   1   0<br>
>      91.238.195.1 -> 239.32.4.130 UDP [2000 -> 2000]<br>
>      ******************************<wbr>******************************<wbr>**********<br>
>      [ppcr_rx_packet]: Packet received<br>
>      Time stamp : 00 day(s) 11h 32m 49s:,<br>
>      TM Header: [ 0564 8a23 0040 ]<br>
>      Type: Fabric Unicast(0x00000000) Size: 1380 Class: 4 Src sys port: 2595<br>
>      Dest Port: 0  Drop Prec: 1 Ing Q Sig: 0 Out mirr dis: 0x0 Excl src: 0 Sys mc: 0<br>
>      ******************************<wbr>******************************<wbr>**********<br>
>      Packet size: 1374, XPP reason code: 0x00045286<br>
>      00: 05f0 0403 5c50 41c2-7841 fffe 4400 0000  FID     = 0x05f0<br>
>      10: 0100 5e20 0482 f4cc-55e5 4600 0800 4588  Offset  = 0x10<br>
>      20: 0540 08e0 0000 3d11-5cb3 5bee c301 ef20  VLAN    = 450(0x01c2)<br>
>      30: 0482 07d0 07d0 052c-0000 4701 e11f c052  CAM     = 0x00ffff(R)<br>
>      40: e9df e2fb 1f9d 0c1d-354a 7df5 f0df edab  SFLOW   = 0<br>
>      50: 1145 566c 4c59 2557-f7cf c708 a75e 5a29  DBL TAG = 0<br>
>      60: 1704 9f8b 151c b66b-957a 51eb ac99 772d<br>
>      70: 07e7 23d7 f84a 50ac-5864 452d 7f70 0495<br>
>      Pri CPU MON SRC   PType US BRD D<br>
>      4   0   0   11/2  3     0  1   0   1   1   1  0  0   0   1   0<br>
>      I have no ideas why it happens. "Multicast Guide" clearly tells<br>
>      that these packets should be processed in hardware.<br>
>      Please advice!<br>
>      Thanks!<br>
>      --<br>
>      MINO-RIPE<br>
>      ______________________________<wbr>_________________<br>
>      foundry-nsp mailing list<br>
</div></div>>      [5]<a href="mailto:foundry-nsp@puck.nether.net">foundry-nsp@puck.nether.net</a><br>
>      [6]<a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" rel="noreferrer" target="_blank">http://puck.nether.net/<wbr>mailman/listinfo/foundry-nsp</a><br>
><br>
> Посилання<br>
><br>
>    1. mailto:<a href="mailto:minotaur@crete.org.ua">minotaur@crete.org.ua</a><br>
>    2. <a href="http://telnet@lsr1-gdr.ki/#show" rel="noreferrer" target="_blank">http://telnet@lsr1-gdr.ki/#<wbr>show</a><br>
>    3. <a href="http://telnet@lsr1-gdr.ki/#show" rel="noreferrer" target="_blank">http://telnet@lsr1-gdr.ki/#<wbr>show</a><br>
>    4. <a href="http://telnet@lsr1-gdr.ki/#show" rel="noreferrer" target="_blank">http://telnet@lsr1-gdr.ki/#<wbr>show</a><br>
>    5. mailto:<a href="mailto:foundry-nsp@puck.nether.net">foundry-nsp@puck.<wbr>nether.net</a><br>
>    6. <a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" rel="noreferrer" target="_blank">http://puck.nether.net/<wbr>mailman/listinfo/foundry-nsp</a><br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
MINO-RIPE<br>
______________________________<wbr>_________________<br>
foundry-nsp mailing list<br>
<a href="mailto:foundry-nsp@puck.nether.net">foundry-nsp@puck.nether.net</a><br>
<a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" rel="noreferrer" target="_blank">http://puck.nether.net/<wbr>mailman/listinfo/foundry-nsp</a></div></div></blockquote></div><br></div>

<br>
<br>E-Mail to and from me, in connection with the transaction <br>of public business, is subject to the Wyoming Public Records <br>Act and may be disclosed to third parties.<br>