Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

PIM6:- Mroutes flush out time is more #13703

Closed
vijaykug opened this issue Jun 6, 2023 · 6 comments
Closed

PIM6:- Mroutes flush out time is more #13703

vijaykug opened this issue Jun 6, 2023 · 6 comments
Assignees
@patrasar
Labels
pim pimv6 triage Needs further investigation

Comments

@vijaykug
Copy link
Contributor

vijaykug commented Jun 6, 2023

Issue- Mroutes taking ~11min to flush out after multicast traffic stop ,

Setup :- R1(LHR) -------R2( RP)-------R3(FHR)

  1. After traffic stop from ixia , mroute flush from LHR took ~3.5 min
  2. After LHR , RP also took same time 3.5 , which is expected
  3. Once mroute flush out from RP node , FHR adding pim6reg OIL ( which is taking another 3.5 min) for mroute to timeout

I think issue here FHR adding pim6reg OIL , once its flush from RP FHR should delete the entires

CLI o/p from FHR:-

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    
 5101::10  ffaa::1  SFP    PIM    ens224.51  pim6reg  1    00:14:18  
 5101::10  ffaa::2  SFP    PIM    ens224.51  pim6reg  1    00:14:18  
 5101::10  ffaa::3  SFP    PIM    ens224.51  pim6reg  1    00:14:18  
 5101::10  ffaa::4  SFP    PIM    ens224.51  pim6reg  1    00:14:18  
 5101::10  ffaa::5  SFP    PIM    ens224.51  pim6reg  1    00:14:17  

R4# do show ipv6 pim upstream
 Iif        Source    Group    State      Uptime    JoinTimer  RSTimer   KATimer   RefCnt  
 ens224.51  5101::10  ffaa::1  NotJ,RegJ  00:01:16  --:--:--   --:--:--  00:02:21  2       
 ens224.51  5101::10  ffaa::2  NotJ,RegJ  00:00:45  --:--:--   --:--:--  00:02:47  2       
 ens224.51  5101::10  ffaa::3  NotJ,RegJ  00:00:59  --:--:--   --:--:--  00:02:36  2       
 ens224.51  5101::10  ffaa::4  NotJ,RegJ  00:01:11  --:--:--   --:--:--  00:02:48  2       
 ens224.51  5101::10  ffaa::5  NotJ,RegJ  00:00:41  --:--:--   --:--:--  00:02:57  2       

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    
 5101::10  ffaa::1  SFP    PIM    ens224.51  pim6reg  1    00:14:56  
 5101::10  ffaa::2  SFP    PIM    ens224.51  pim6reg  1    00:14:56  
 5101::10  ffaa::3  SFP    PIM    ens224.51  pim6reg  1    00:14:56  
 5101::10  ffaa::4  SFP    PIM    ens224.51  pim6reg  1    00:14:56  
 5101::10  ffaa::5  SFP    PIM    ens224.51  pim6reg  1    00:14:55  

R4# do show ipv6 pim upstream
 Iif        Source    Group    State      Uptime    JoinTimer  RSTimer   KATimer   RefCnt  
 ens224.51  5101::10  ffaa::1  NotJ,RegJ  00:01:52  --:--:--   --:--:--  00:01:45  2       
 ens224.51  5101::10  ffaa::2  NotJ,RegJ  00:01:21  --:--:--   --:--:--  00:02:11  2       
 ens224.51  5101::10  ffaa::3  NotJ,RegJ  00:01:35  --:--:--   --:--:--  00:02:00  2       
 ens224.51  5101::10  ffaa::4  NotJ,RegJ  00:01:47  --:--:--   --:--:--  00:02:12  2       
 ens224.51  5101::10  ffaa::5  NotJ,RegJ  00:01:17  --:--:--   --:--:--  00:02:21  2       

R4# do show ipv6 pim upstream
 Iif        Source    Group    State      Uptime    JoinTimer  RSTimer   KATimer   RefCnt  
 ens224.51  5101::10  ffaa::1  NotJ,RegJ  00:02:36  --:--:--   --:--:--  00:01:01  1       
 ens224.51  5101::10  ffaa::2  NotJ,RegJ  00:02:05  --:--:--   --:--:--  00:01:27  2       
 ens224.51  5101::10  ffaa::3  NotJ,RegJ  00:02:19  --:--:--   --:--:--  00:01:15  2       
 ens224.51  5101::10  ffaa::4  NotJ,RegJ  00:02:31  --:--:--   --:--:--  00:01:28  2       
 ens224.51  5101::10  ffaa::5  NotJ,RegJ  00:02:01  --:--:--   --:--:--  00:01:37  2       

R4# do show ipv6 pim upstream
 Iif        Source    Group    State      Uptime    JoinTimer  RSTimer   KATimer   RefCnt  
 ens224.51  5101::10  ffaa::5  NotJ,RegJ  00:03:35  --:--:--   --:--:--  00:00:03  1       

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

Ubuntu - 18-04
Kernel - 6.1.2-060102-generic
Build - frr9.0 latest

will attach logs for same
@vijaykug vijaykug added the triage Needs further investigation label Jun 6, 2023
@vijaykug
Copy link
Contributor Author

vijaykug commented Jun 6, 2023

Logs.zip

@mobash-rasool
Copy link
Contributor

This should be same as PIMv4. @vijaykug : Do you know how much time pimv4 is taking?

@vijaykug
Copy link
Contributor Author

vijaykug commented Jun 6, 2023 •
edited
Loading

This should be same as PIMv4. @vijaykug : Do you know how much time pimv4 is taking?

Hi Mobash ,
I dont have pimv4 setup , so did not verify for pimv4

@mobash-rasool
Copy link
Contributor

Adding the pim label since this issue is present in both pim and pimv6.
At FHR, pimreg is getting deleted and added due to which KAT gets restarted at FHR and therefore the time taken to clean up the mroute at FHR takes more time. Now we need to check whether the pimreg addition and deletion can be justified here, if not then we need to fix the issue.

routingrocks added a commit to routingrocks/frr that referenced this issue Jul 27, 2023
@routingrocks
pimd: Fix for FHR mroute taking longer to age out
f7c5ba2 
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO.  This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.

In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
 the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
 PPT to 0 (RFC 4601 sec 4.5.2).
 When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
 (S,G) entry only after ~10 minutes when there is no active traffic.

Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.

Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.

Ticket: FRRouting#13703

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
@routingrocks routingrocks mentioned this issue Jul 27, 2023
Merged
routingrocks added a commit to routingrocks/frr that referenced this issue Aug 1, 2023
@routingrocks
pimd: Fix for FHR mroute taking longer to age out
088e2b4 
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO.  This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.

In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
 the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
 PPT to 0 (RFC 4601 sec 4.5.2).
 When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
 (S,G) entry only after ~10 minutes when there is no active traffic.

Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.

Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.

Ticket: FRRouting#13703

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
routingrocks added a commit to routingrocks/frr that referenced this issue Aug 2, 2023
@routingrocks
pimd: Fix for FHR mroute taking longer to age out
e6b5553 
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO.  This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.

In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
 the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
 PPT to 0 (RFC 4601 sec 4.5.2).
 When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
 (S,G) entry only after ~10 minutes when there is no active traffic.

Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.

Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.

Ticket: FRRouting#13703

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
routingrocks added a commit to routingrocks/frr that referenced this issue Aug 2, 2023
@routingrocks
pimd: Fix for FHR mroute taking longer to age out
62d2ecc 
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO.  This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.

In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
 the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
 PPT to 0 (RFC 4601 sec 4.5.2).
 When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
 (S,G) entry only after ~10 minutes when there is no active traffic.

Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.

Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.

Ticket: FRRouting#13703

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
routingrocks added a commit to routingrocks/frr that referenced this issue Aug 2, 2023
@routingrocks
pimd: Fix for FHR mroute taking longer to age out
c887450 
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO.  This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.

In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
 the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
 PPT to 0 (RFC 4601 sec 4.5.2).
 When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
 (S,G) entry only after ~10 minutes when there is no active traffic.

Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.

Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.

Ticket: FRRouting#13703

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
routingrocks added a commit to routingrocks/frr that referenced this issue Aug 3, 2023
@routingrocks
pimd: Fix for FHR mroute taking longer to age out
0a89a6b 
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO.  This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.

In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
 the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
 PPT to 0 (RFC 4601 sec 4.5.2).
 When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
 (S,G) entry only after ~10 minutes when there is no active traffic.

Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.

Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.

Ticket: FRRouting#13703

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
routingrocks added a commit to routingrocks/frr that referenced this issue Aug 3, 2023
@routingrocks
pimd: Fix for FHR mroute taking longer to age out
c8df867 
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO.  This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.

In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
 the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
 PPT to 0 (RFC 4601 sec 4.5.2).
 When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
 (S,G) entry only after ~10 minutes when there is no active traffic.

Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.

Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.

Ticket: FRRouting#13703

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
@github-actions GitHub Actions
Copy link

This issue is stale because it has been open 180 days with no activity. Comment or remove the autoclose label in order to avoid having this issue closed.

@frrbot
Copy link

frrbot bot commented Dec 12, 2023

This issue will be automatically closed in the specified period unless there is further activity.

@frrbot frrbot bot closed this as completed Dec 19, 2023
@frrbot frrbot bot removed the autoclose label Dec 19, 2023
Jafaral pushed a commit to routingrocks/frr that referenced this issue Feb 6, 2025
@routingrocks @Jafaral
pimd: Fix for FHR mroute taking longer to age out
6cdb242 
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO.  This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.

In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
 the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
 PPT to 0 (RFC 4601 sec 4.5.2).
 When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
 (S,G) entry only after ~10 minutes when there is no active traffic.

Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.

Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.

Ticket: FRRouting#13703

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
Jafaral pushed a commit to routingrocks/frr that referenced this issue Feb 6, 2025
@routingrocks @Jafaral
pimd: Fix for FHR mroute taking longer to age out
55d93b1 
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO.  This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.

In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
 the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
 PPT to 0 (RFC 4601 sec 4.5.2).
 When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
 (S,G) entry only after ~10 minutes when there is no active traffic.

Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.

Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.

Ticket: FRRouting#13703

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
Jafaral pushed a commit to routingrocks/frr that referenced this issue Feb 6, 2025
@routingrocks @Jafaral
pimd: Fix for FHR mroute taking longer to age out
afed39e 
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO.  This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.

In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
 the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
 PPT to 0 (RFC 4601 sec 4.5.2).
 When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
 (S,G) entry only after ~10 minutes when there is no active traffic.

Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.

Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.

Ticket: FRRouting#13703

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
mergify bot pushed a commit that referenced this issue Feb 7, 2025
@routingrocks @mergify
pimd: Fix for FHR mroute taking longer to age out
b41ba2e 
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO.  This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.

In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
 the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
 PPT to 0 (RFC 4601 sec 4.5.2).
 When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
 (S,G) entry only after ~10 minutes when there is no active traffic.

Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.

Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.

Ticket: #13703

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
(cherry picked from commit afed39e)
@mergify mergify bot mentioned this issue Feb 7, 2025
Closed
mergify bot pushed a commit that referenced this issue Feb 7, 2025
@routingrocks @mergify
pimd: Fix for FHR mroute taking longer to age out
b48d040 
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO.  This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.

In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
 the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
 PPT to 0 (RFC 4601 sec 4.5.2).
 When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
 (S,G) entry only after ~10 minutes when there is no active traffic.

Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.

Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.

Ticket: #13703

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
(cherry picked from commit afed39e)
mergify bot pushed a commit that referenced this issue Feb 7, 2025
@routingrocks @mergify
pimd: Fix for FHR mroute taking longer to age out
709e6ff 
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO.  This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.

In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
 the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
 PPT to 0 (RFC 4601 sec 4.5.2).
 When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
 (S,G) entry only after ~10 minutes when there is no active traffic.

Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.

Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.

Ticket: #13703

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
(cherry picked from commit afed39e)
This was referenced Feb 7, 2025
Closed
Closed
mergify bot pushed a commit that referenced this issue Feb 7, 2025
@routingrocks @mergify
pimd: Fix for FHR mroute taking longer to age out
ccbe9f9 
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO.  This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.

In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
 the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
 PPT to 0 (RFC 4601 sec 4.5.2).
 When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
 (S,G) entry only after ~10 minutes when there is no active traffic.

Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.

Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.

Ticket: #13703

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
(cherry picked from commit afed39e)
@mergify mergify bot mentioned this issue Feb 7, 2025
Merged
mergify bot pushed a commit that referenced this issue Feb 7, 2025
@routingrocks @mergify
pimd: Fix for FHR mroute taking longer to age out
221fa07 
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO.  This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.

In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
 the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
 PPT to 0 (RFC 4601 sec 4.5.2).
 When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
 (S,G) entry only after ~10 minutes when there is no active traffic.

Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.

Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.

Ticket: #13703

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
(cherry picked from commit afed39e)
mergify bot pushed a commit that referenced this issue Feb 7, 2025
@routingrocks @mergify
pimd: Fix for FHR mroute taking longer to age out
8b60108 
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO.  This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.

In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
 the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
 PPT to 0 (RFC 4601 sec 4.5.2).
 When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
 (S,G) entry only after ~10 minutes when there is no active traffic.

Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.

Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.

Ticket: #13703

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
(cherry picked from commit afed39e)
This was referenced Feb 7, 2025
Merged
Merged
ton31337 pushed a commit that referenced this issue Feb 10, 2025
@routingrocks @ton31337
pimd: Fix for FHR mroute taking longer to age out
cdd4cac 
Issue:
When there is no traffic for a group, the LHR and RP take the default KAT+Join timer expiry of
a maximum of 480 seconds to clear the S,G . However, in the FHR, we update the state from JOINED
to NOT Joined, downstream state from PPto NOINFO.  This restarts the ET timer, causing S,G on FHR to
take more than 10 minutes to age out.

In other words,
Consider a case where (S,G) is in Join state. When the traffic stops and the KAT (210) expires,
 the Join expiry timer restarts. At this time, if we receive a prune, the expectation is to set
 PPT to 0 (RFC 4601 sec 4.5.2).
 When the PPT expires, we move to the noinfo state and restart the expiry timer one more time. We remove the
 (S,G) entry only after ~10 minutes when there is no active traffic.

Summary:
KAT Join ET 210 + PP ET 210 + NOINFO ET 210.

Solution:
Delete the ifchannel when in noinfo state, and KAT is not running.

Ticket: #13703

Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
(cherry picked from commit afed39e)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@patrasar patrasar

Labels
pim pimv6 triage Needs further investigation
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@patrasar @vijaykug @mobash-rasool