Description

Multicast streams received on an unintended or non-rpf interfaces are causing dlu.ucode.ip_mc_iif_mismatch trap stats on the PFEs, leading to dropped multicast traffic on these interfaces.

Symptoms

Example (S,G) –  (172.16.54.57, 239.0.0.46) : The RPF interface is AE20, with the PIM join distributed via both AE20 and AE10. The multicast cache selected AE20 as the upstream interface, leading to IIF mismatches when the multicast stream comes in over AE10.


labuser@labrouter> clear pfe statistics traffic 
Traffic statistics cleared.

labuser@labrouter> show pfe statistics traffic fpc 6 | match "input drops"    
    Hardware input drops               :            32118434

labuser@labrouter> show pfe statistics traffic fpc 6 | match "input drops"    
    Hardware input drops               :            37035510   


FPC6(labrouter vty)# show pechip trapstats    
DEV       TRAPCODE                                          count                rate
=========================================================================================
 0 ( 17) dlu.ucode.ip_mc_iif_mismatch                 356569470642              110289    
 1 ( 17) dlu.ucode.ip_mc_iif_mismatch                 336150092531              102302    
 2 ( 17) dlu.ucode.ip_mc_iif_mismatch                 317319854780               94243    
 3 ( 17) dlu.ucode.ip_mc_iif_mismatch                 276486992344               95055  


labuser@labrouter> show route forwarding-table destination 172.16.54.57
Mar 12 08:47:17
Routing table: default.inet
Internet:
Enabled protocols: Bridging, 
Destination        Type RtRef Next hop           Type Index    NhRef Netif
172.16.54.56/31    user     0                    indr  2099936    17
                                                 ulst  2101383     3
                              10.34.13.231      Push 13036     7784     2 ae10.0
                              10.34.15.21       Push 25870    10847     2 ae20.0
 
 
labuser@labrouter> show multicast rpf 172.16.54.57
Mar 12 08:58:23
Multicast RPF table: inet.0 , 1081547 entries
 
172.16.54.56/31
    Protocol: BGP
    Interface: ae20.0
 
 
labuser@labrouter> show pim join 239.0.0.46 source 172.16.54.57 extensive
Mar 12 09:01:42
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
 
Group: 239.0.0.46
    Source: 172.16.54.57
    Flags: sparse,spt
    Upstream interface: ae20.0                
    Upstream neighbor: 10.34.15.21
    Upstream state: Join to Source
    Keepalive timeout: 274
    Uptime: 39w6d 22:20:36 
    Downstream neighbors:
        Interface: ae5.0                  
            10.34.15.19 State: Join Flags: S Timeout: 178
            Uptime: 39w6d 22:20:36 Time since last Join: 00:00:32
    Number of downstream interfaces: 1
    Number of downstream neighbors: 1
 
 
labuser@labrouter> show multicast route group 239.0.0.46 source-prefix 172.16.54.57 extensive 
Mar 12 09:07:05
Instance: master Family: INET
 
Group: 239.0.0.46
    Source: 172.16.54.57/32
    Upstream interface: ae20.0
    Downstream interface list: 
        ae5.0
    Number of outgoing interfaces: 1
    Session description: Organisational Local Scope
    Statistics: 479 kBps, 356 pps, 8614895978 packets
    Next-hop ID: 2097716
    Upstream protocol: PIM
    Route state: Active
    Forwarding state: Forwarding
    Cache lifetime/timeout: forever
    Wrong incoming interface notifications: 156956
    Uptime: 39w6d 22:25:59
 
 
labuser@labrouter> monitor traffic interface ae10 no-resolve matching pim extensive size 9000
Mar 12 09:45:36
Address resolution is OFF.
Listening on ae10, capture size 9000 bytes
...
09:45:54.337145 Out 
        Juniper PCAP Flags [Ext], PCAP Extension(s) total length 16
          Device Media Type Extension TLV #3, length 1, value: Ethernet (1)
          Logical Interface Encapsulation Extension TLV #6, length 1, value: Ethernet (14)
          Device Interface Index Extension TLV #1, length 2, value: 133
          Logical Interface Index Extension TLV #4, length 4, value: 67
        -----original packet-----
        10:10:10:95:62:85 > 01:00:5e:00:00:0d, ethertype IPv4 (0x0800), length 5956: (tos 0xc0, ttl   1, id 39574, offset 0, flags [none], proto: PIM (103), length: 5942) 10.34.13.230 > 224.0.0.13: 10.34.13.230 > 224.0.0.13:PIMv2, length 5922
        Join / Prune, cksum 0x9d59 (correct), upstream-neighbor: 10.34.13.231
          255 group(s), holdtime: 3m30s
          ...
            group #112: 239.0.0.46, joined sources: 1, pruned sources: 0
              joined source #1: 172.16.54.57(S)
 
 
labuser@labrouter> monitor traffic interface ae20 no-resolve matching pim extensive size 9000    
Address resolution is OFF.
Listening on ae20, capture size 9000 bytes
...
09:47:13.617351 Out 
        Juniper PCAP Flags [Ext], PCAP Extension(s) total length 16
          Device Media Type Extension TLV #3, length 1, value: Ethernet (1)
          Logical Interface Encapsulation Extension TLV #6, length 1, value: Ethernet (14)
          Device Interface Index Extension TLV #1, length 2, value: 135
          Logical Interface Index Extension TLV #4, length 4, value: 72
        -----original packet-----
        10:10:10:95:62:87 > 01:00:5e:00:00:0d, ethertype IPv4 (0x0800), length 7484: (tos 0xc0, ttl   1, id 53836, offset 0, flags [none], proto: PIM (103), length: 7470) 10.34.15.20 > 224.0.0.13: 10.34.15.20 > 224.0.0.13:PIMv2, length 7450
        Join / Prune, cksum 0xbd5a (correct), upstream-neighbor: 10.34.15.21
          255 group(s), holdtime: 3m30s
          ...
            group #141: 239.0.0.46, joined sources: 2, pruned sources: 0
              joined source #1: 172.26.54.65(S)
              joined source #2: 172.16.54.57(S)

Solution

The issue is due to the PIM Join-load-balance feature. When the router has multiple ECMP paths to reach the multicast source and is configured for PIM Join-load-balance, Load balancing of Join will be done creating an active upstream path and a standby upstream path. When multicast streams are received on the standby upstream path, an IIF_MISMATCH is generated, consequently Standby path gets converted into Active path & PIM Prune will be sent on old active path and periodic joins will be cancelled on old Active path. However, in this case, protocol PIM prematurely removes the old active path without sending a prune on that path and removing the periodic old active joins.

There can be another scenario where there is transition from one standby path to another standby path. In that case also old standby path needs to be pruned and periodic joins needs to be cancelled.

 

One of the below steps can be attempted to clear the issue. However, the issue may re-appear due to the triggers mentioned

1] Deactivate/Activate protocol PIM on Interface where duplicate Joins are sent 

2] Deactivate/Activate protocol PIM

3] Restart RPD process 

 

Modification History

2025-03-18 : Article Created