this krt queue problem is in the logical system.
ls:rpd: %DAEMON-3-RPD_KRT_Q_RETRIES: nexthop DELETE: Operation not permitted
show krt queueRouting table add queue: 0 queuedInterface add/delete/change queue: 0 queuedTop-priority deletion queue: 0 queuedTop-priority change queue: 0 queuedTop-priority add queue: 0 queuedhigh priority V4oV6 tcnh delete queue: 0 queuedhigh prioriy anchor gencfg delete queue: 0 queuedHigh-priority multicast add/change: 0 queuedIndirect next hop top priority add/change: 0 queuedIndirect next hop add/change: 0 queuedhigh prioriy anchor gencfg add-change queue: 0 queuedMPLS add queue: 0 queuedIndirect next hop delete: 1 queuedDELETE nhtype Router index 7769 (49590)error 'EPERM -- Jtree walk in progress'kqp '0xb8a1540'High-priority deletion queue: 0 queuedMPLS change queue: 0 queuedHigh-priority change queue: 0 queuedHigh-priority add queue: 0 queuedNormal-priority indirect next hop queue: 0 queuedNormal-priority deletion queue: 0 queuedNormal-priority composite next hop deletion queue: 0 queuedLow prioriy Statistics-id-group deletion queue: 0 queuedNormal-priority change queue: 0 queuedNormal-priority add queue: 0 queuedLeast-priority delete queue: 0 queuedLeast-priority change queue: 0 queuedLeast-priority add queue: 0 queuedNormal-priority pfe table nexthop queue: 0 queuedEVPN gencfg queue: 0 queuedNormal-priority gmp queue: 0 queuedRouting table delete queue: 0 queuedLow priority route retry queue: 0 queued
anyone can help me figure out the root cause? when I clear the arp, it can be fixed for a short time.
Next-hop type: Router Index: 7769 Address: 0xb64b4b0 Reference count 1 Kernel Table Id 5 Next hop: 18.104.22.168 via ae0.1456 Session Id: 0x349 Flags: explicit-add on-nhid-tree
when I clear this arp cache. the issue can be fixed for s short time.
Is this index part of any VRF ?
If not we may need to perform " restart routing " to clear it permanently
It's in logical system not vrf.
I restarted the routing process in the logical system. it got fixed. thanks so much
Thanks, good to know it worked ,kindly mark it as accepted solution .
Anish k t
This kind of issue is seen due to sequence of events. Is there load-balancing ECMP configured on this box?
Error EPERM means operation not permitted. There would be multiple reasons for the error which you are seeing, this could be a bug or PR.
I would suggest you to open a case with JTAC for further investigation.
Can you share below output?
show log messages | match jtree
'Please Mark My Solution Accepted if it Helped, Kudos are Appreciated too'
are you seeing any core generated along with this? krt queue getting stuck is not uncommon.
For most of KRT stuck issue, you may want to open a JTAC case to find out a bug/PR.
However, there're a few common things to look at:
1. If ARP is resolved for next-hop
2. If you have reachability to the protocol next-hop
3. In some static route configuration, you have used an invalid next-hop, for example, a broadcast address, like 192.168.1.255/24. You may want to check your configuration for the IP 22.214.171.124
it needs arp resolved, sometimes when I clear arp, it can be fixed by a short time.