frr
frr copied to clipboard
FRRouting
PIM4/v6- Prune not sent to FHR when restarting PIM6d on LHR
Issue - I have restarted PIM6d on LHR , on FHR observed (s,g) mroutes entries were still intact , no change on OIL Here looks like LHR is not sending prune to upstream router ( i.e RP) Setup
LHR-----RP-----FHR
(s,g) entries intact FHR and RP node after pim6d daemon restart
R4# do show ipv6 mroute
IP Multicast Routing Table
Flags: S - Sparse, C - Connected, P - Pruned
R - SGRpt Pruned, F - Register flag, T - SPT-bit set
Source Group Flags Proto Input Output TTL Uptime
* ff05::2 SC MLD ens192.4010 pim6reg 1 13:36:41
MLD ens225 1
MLD ens257 1
1020::10 ffaa::1 SFT PIM ens257 ens192.4010 1 13:36:41
1020::10 ffaa::2 SFT PIM ens257 ens192.4010 1 13:36:41
1020::10 ffaa::3 SFT PIM ens257 ens192.4010 1 13:36:41
1020::10 ffaa::4 SFT PIM ens257 ens192.4010 1 13:36:41
1020::10 ffaa::5 SFT PIM ens257 ens192.4010 1 13:36:41
R2# do show ipv6 mroute
IP Multicast Routing Table
Flags: S - Sparse, C - Connected, P - Pruned
R - SGRpt Pruned, F - Register flag, T - SPT-bit set
Source Group Flags Proto Input Output TTL Uptime
* ff05::2 S PIM lo ens192.4001 1 186:44:13
PIM ens224.4010 1
* ffaa::1 S PIM lo ens192.4001 1 14:06:24
1020::10 ffaa::1 ST STAR ens224.4010 ens192.4001 1 42:13:10
* ffaa::2 S PIM lo ens192.4001 1 14:06:24
1020::10 ffaa::2 ST STAR ens224.4010 ens192.4001 1 42:13:10
* ffaa::3 S PIM lo ens192.4001 1 14:06:24
1020::10 ffaa::3 ST STAR ens224.4010 ens192.4001 1 42:13:10
* ffaa::4 S PIM lo ens192.4001 1 14:06:24
1020::10 ffaa::4 ST STAR ens224.4010 ens192.4001 1 42:13:10
* ffaa::5 S PIM lo ens192.4001 1 14:06:24
1020::10 ffaa::5 ST STAR ens224.4010 ens192.4001 1 42:13:10
Attaching the logs for of FHR LHR and RP node
Build - frr_8.4-dev-PR11134-g5005e01-20220712.114328-1~ubuntu18.04.1_amd64.deb Ubuntu 18.04
There was an issue where pim6d was not restarted when FRR was restarted and it is fixed via 11751 PR.
I have checked this issue. This is what is happening.
PIM6d goes down in LHR, prune is sent towards RP. RP receives prune and then it goes to prune pending state and triggers the timer event. Now if PIM6d at LHR comes up immediately then it sends join towards the RP. Now if RP receives the join before prune pending timer pops, it cancels the sending of prune event towards FHR and do not send prune. If the join is received after the popping of prune pending timer then I can see that Prune is sent towards RP
This is as per RFC 7761.
When in Prune-Pending state, the following events may trigger a
transition:
Receive Join(S,G)
A Join(S,G) is received on interface I with its Upstream
Neighbor Address set to the router's primary IP address
on I.
The (S,G) downstream state machine on interface I
transitions to the Join state. The Prune-Pending Timer is
canceled (without triggering an expiry event). The
Expiry Timer (ET) is restarted and is then set to the
maximum of its current value and the HoldTime from the
triggering Join/Prune message.
Before PIM6D goes down at LHR, RP shows below count:
frr# do sh ipv6 pim interface traffic
Interface HELLO JOIN PRUNE REGISTER REGISTER-STOP ASSERT BSM
Rx/Tx Rx/Tx Rx/Tx Rx/Tx Rx/Tx Rx/Tx Rx/Tx
---------------------------------------------------------------------------------------------------------------
ens192 108/110 0/41 0/7 56/0 0/56 0/0 0/0
ens224 114/117 84/0 29/0 0/0 0/0 0/0 0/0
lo 0/0 0/0 0/0 0/0 0/0 0/0 0/0
pim6reg 0/0 0/0 0/0 0/0 0/0 0/0 0/0
frr#
Once PIM6d comes up after few seconds at LHR, RP shows that prune is sent.
frr# do sh ipv6 pim interface traffic
Interface HELLO JOIN PRUNE REGISTER REGISTER-STOP ASSERT BSM
Rx/Tx Rx/Tx Rx/Tx Rx/Tx Rx/Tx Rx/Tx Rx/Tx
---------------------------------------------------------------------------------------------------------------
ens192 109/111 0/43 0/8 57/0 0/57 0/0 0/0
ens224 117/118 86/0 31/0 0/0 0/0 0/0 0/0
lo 0/0 0/0 0/0 0/0 0/0 0/0 0/0
pim6reg 0/0 0/0 0/0 0/0 0/0 0/0 0/0
frr#
Session
So In my opinion it is not an issue and it is an expected behaviour.