Cannot perform nh operation ADDANDGET nhop (null) type unilist index .* errno .*

This article describes the following syslog message:

rpd[91675]: Cannot perform nh operation ADDANDGET nhop (null) type unilist index .* errno .*

Note: This log message is harmless, and is for debugging purposes only.

This is a generic log message. It does not represent any error on the network.

Note: This log message is harmless, and is for debugging purposes only.

If a unilist (nexthop/route) deletion is followed by an add and returns BUSY when the kernel waits for PFE ACKs, this message is generated.

Note that in some condition this behavior is expected. The kernel routing table (krt) will retry and eventually succeed, so the message will be logged at a lower priority.

This message could occur or result from the following situations:

There is a misconfiguration on the router that attempts to insert an invalid next-hop destination into the PFE.
Link flaps, or because an interface is disabled or disconnected.
Routing protocol session flaps, addition and removal of routing protocols.
When several route changes occur within a short period of time.

Note: This log message is harmless, and is for debugging purposes only.

Perform these steps to determine the cause and resolve the problem (if any). Continue through each step until the problem is resolved.

1.Collect the show command output on the Routing Engine.

Capture the output to a file (in case you have to open a technical support case). To do this, configure each SSH client/terminal emulator to log your session.

show log messages | no-more
show log chassisd | no-more
show log interactive-commands | no-more
show krt queue
show krt state
show krt acknowledgement
show krt snooping queue
show krt snooping table
show multicast snooping next-hops
show krt queue fabric
show version
show route detail | no-more
show route forwarding-table | no-more
show interfaces extensive | no-more
show interface terse

If an FPC is referenced in any of these associated log messages, issue the following commands as well:

request pfe execute command "show ifl brief" target fpc#
request pfe execute command "show nvram" target fpc#
request pfe execute command "show syslog messages" target fpc#

Note: After the release of Junos OS 12.2R1, the severity of the above logs was changed to LOG_DEBUG.

2. Analyze the show command output.

a. Review the events that occurred at or just before the appearance of the message. Do these events help you identify the cause mentioned in the cause section of this document?

Yes – Make note of this expected behavior for future reference.
No – Continue to Step 2b.

b. Did the event message appear shortly after a commit command was executed?

Yes – Check to see if any configuration changes were made (for example, check for static route changes, forwarding changes, interface configuration changes, and more). Any one of these changes could cause the problem. Make note of this expected behavior for future reference.
No – Continue to Step 2c.

c. Did any link flaps or disconnects occur at or just before the appearance of the message?

Yes – The physical link itself may be compromised, or the network neighbor might have changed. Start an investigation into the root cause of this event.
No – Continue to Step 2d.

d. Did any route or protocol changes occur at or just before the appearance of the message?

Yes – The message is expected and can be ignored.
No – Continue to Step 2e.

e. Examine the krt queue output. Does it reveal any stuck routes for a long time if you run the commands several times?

Yes – open a case with your technical support representative to investigate the issue further.
No – Continue to Step 3.

3. Restart the routing process (rpd). Do this only during a maintenance window, as it will impact transit traffic.

Did the event message stop appearing in the syslog?

Yes – The error state in rpd has been cleared.
No – Continue to Step 4.

4. Reboot the router. Do this only during a maintenance window, as it will impact transit traffic.

Did the event message stop appearing in the syslog?

Yes – The error state in the kernel has been cleared.

Related