Skip to content

pimd: MSDP-created (S, G) upstream on anycast RP stays NotJoined indefinitely when (*, G) OIL populates after SA arrival #22565

Description

@ashred-lnx

Description

In an anycast-RP with MSDP peering configuration, when an MSDP Source Active (SA) message arrives at an RP before that RP's (, G) OIL is populated by a downstream Join, the resulting (S, G) upstream on that RP remains in NotJoined state indefinitely — even after the downstream (, G) Join later arrives and the RP's (*, G) OIL becomes populated.


                    Anycast RP: 81.0.0.5
             MSDP mesh-group between spine-1 & spine-2

           spine-1                                 spine-2
        (6.0.0.26)              MSDP           (6.0.0.27)
             │                                     │
       ┌─────┴─────┐                         ┌─────┴─────┐
       │           │                         │           │
    leaf-11     leaf-12                   leaf-21     leaf-22
    (6.0.0.22) (6.0.0.23)                (6.0.0.24) (6.0.0.25)
       │           │                         │           │
    tor-11      tor-12                    tor-21      tor-22
    VTEP:       VTEP:                     VTEP:       VTEP:
    6.0.0.28    6.0.0.29                  6.0.0.30    6.0.0.31

Reproducing flow:
  - tor-11 (VTEP 6.0.0.28) sources multicast to 239.1.1.100.
  - Receiver behind tor-21 (VTEP 6.0.0.30) subscribes via IGMP.
  - leaf-11 hashed its (*, G) Join to spine-1; (*, G) OIL populated on spine-1.
  - leaf-21 hashed its (*, G) Join to spine-2; (*, G) OIL populated on spine-2
    AFTER the MSDP SA for the source arrived on spine-2 from spine-1.
  - Result: (6.0.0.28, 239.1.1.100) upstream on spine-2 stuck NotJoined.
! spine-1 (6.0.0.26)
router pim
 rp 81.0.0.5 224.0.0.0/4
 spt-switchover infinity-and-beyond
!
router msdp
 peer 6.0.0.27 source-ip 6.0.0.26
!
interface lo
 ip address 81.0.0.5/32          ! anycast RP address

! spine-2 (6.0.0.27)
router pim
 rp 81.0.0.5 224.0.0.0/4
 spt-switchover infinity-and-beyond
!
router msdp
 peer 6.0.0.26 source-ip 6.0.0.27
!
interface lo
 ip address 81.0.0.5/32          ! anycast RP address

Version

FRR 10.6.0

How to reproduce

Reproducing flow:

  • tor-11 (VTEP 6.0.0.28) sources multicast to 239.1.1.100.
  • Receiver behind tor-21 (VTEP 6.0.0.30) subscribes via IGMP.
  • leaf-11 hashed its (, G) Join to spine-1; (, G) OIL populated on spine-1.
  • leaf-21 hashed its (, G) Join to spine-2; (, G) OIL populated on spine-2
    AFTER the MSDP SA for the source arrived on spine-2 from spine-1.
  • Result: (6.0.0.28, 239.1.1.100) upstream on spine-2 stuck NotJoined.

Expected behavior

After the receiver's (, G) Join populates (, G) OIL on the RP, the (S, G) upstream should re-evaluate its inherited OIL, set drJoinDesired: true, transition to Joined, and send a PIM (S, G) Join toward the source.

Actual behavior

The (S, G) upstream stays in NotJoined state indefinitely. drJoinDesired remains false despite the inherited OIL being non-empty.

Additional context

`{
  "239.1.1.100": {
    "*": {
      "drJoinDesired":     true,
      "sourcePim":         true,
      "sourceMsdp":        false,
      "state":             "J",
      "joinState":         "Joined",
      "inboundInterface":  "lo",
      "rpfAddress":        "81.0.0.5",
      "upTime":            "00:24:25"
    },
    "6.0.0.28": {
      "drJoinDesired":     false,
      "sourceIgmp":        false,
      "sourcePim":         true,
      "sourceStream":      false,
      "sourceMsdp":        true,
      "sendSGRptPrune":    false,
      "firstHopRouter":    false,
      "lastHopRouter":     false,
      "inboundInterface":  "swp2",
      "rpfAddress":        "6.0.0.28",
      "source":            "6.0.0.28",
      "group":             "239.1.1.100",
      "state":             "NotJ",
      "joinState":         "NotJoined",
      "regState":          "RegNoInfo",
      "upTime":            "00:23:14",
      "joinTimer":         "00:00:19",
      "resetTimer":        "--:--:--",
      "keepaliveTimer":    "--:--:--",
      "msdpRegTimer":      "--:--:--",
      "refCount":          1,
      "sptBit":            0
    }
  }
}

Codes: J -> Pim Join, I -> IGMP Report, S -> Source, * -> Inherited from (*,G),
       V -> VxLAN, M -> Muted
Active Source           Group            RPT  IIF               OIL
1      6.0.0.28         239.1.1.100      n    swp2              swp3(   * )


 Interface  Source    Group        LostAssert  Joins  PimInclude  JoinDesired  EvalJD
 swp3       *         239.1.1.100  no          yes    no          yes          yes
 swp3       6.0.0.30  239.1.1.100  no          no     no          no           no
 swp3       6.0.0.31  239.1.1.100  no          no     no          no           no

Source     Group        RP        Local  SPT  Uptime
6.0.0.28   239.1.1.100  81.0.0.5  n      y    00:22:06
6.0.0.29   239.1.1.100  *         n      y    00:22:25
6.0.0.30   239.1.1.100  -         y      -    00:22:30
6.0.0.31   239.1.1.100  -         y      -    00:22:30

Peer      Local     State        Uptime    SaCnt  AS
6.0.0.26  6.0.0.27  established  00:32:32  2      -


tor-21 bridged out 47 packets, expected at least 975
`



Observed state on the healthy peer RP (spine-1) — control comparison
Same source, same MSDP infrastructure. The source-pod leaf (leaf-11) hashed its (*, G) Join to spine-1. When the MSDP SA arrived at spine-1, its (*, G) OIL was already populated. Result: (S, G) came up correctly Joined.

 Iif   Source    Group        State  Uptime    JoinTimer  RSTimer   KATimer   RefCnt
 lo    *         239.1.1.100  J      00:42:27  00:00:32   --:--:--  --:--:--  2
 swp2  6.0.0.28  239.1.1.100  J      00:29:16  00:00:12   --:--:--  00:02:49  1
The only structural difference between the two RPs is the event order at the moment the (S, G) upstream was created.

Checklist

  • I have searched the open issues for this bug.
  • I have not included sensitive information in this report.

Metadata

Metadata

Assignees

No one assigned

    Labels

    triageNeeds further investigation

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions