Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

Error message seen on the EX series Switch: "Resolve request came for an address matching on Wrong nh nh:680, type:Hold...?"

0

0

Article ID: KB15306 KB Last Updated: 03 Mar 2017Version: 2.0
Summary:
The following log message is being logged on the EX series Switch.  

"Resolve request came for an address matching on Wrong nh nh:680, type:Hold...?"

Why are these messages generated and what do they mean?

Symptoms:
The following log message is being logged on the EX series Switch.

"Resolve request came for an address matching on Wrong nh nh:680, type:Hold...?"

These messages are sometimes seen in large numbers.  Why are they generated and what do they mean?

Solution:
Consider the case of a packet being L3 routed via an EX Switch, where the destination IP of the packet is located in directly connected subnet of the router.  Assume ARP for that destination IP is still not resolved on the EX Switch.

Terms:
PFE     Packet Forwarding Engine
SFI       Software Forwarding Infrastructure
RE       Routing Engine
LC       Linecard

Scenario:
- Packet being L3 routed via EX Switch
- Destination IP of the packet is located in directly connected subnet of the router
- Assume ARP for that destination IP is still not resolved on the EX Switch

1) Destination IP of packet is looked up, which matches subnet prefix "P", for which resolve_nh is programmed in the PFE. The packet gets trapped to the CPU or linecard CPU in case of the 8200 series Switch.

2) This packet is queued into SFI, which subsequently sends “resolve request” to PFEM process. PFEM upon receiving resolve request from SFI, sends “resolve request message” towards RE (via LC CPU in case of a 8200 linecard).

3) RE initiates ARP resolution for the nexthop IP. At the same time RE sends messages to PFE to program “hold nexthop” for this dest IP.

4) PFEM upon receiving “hold nh" msg, programs PFE to drop all packets for dest IP until arp is resolved.

5) After arp for “dest IP” is resolved, RE sends NH_CHANGE to PFE to convert “hold nh” to “unicast nh”

6) PFEM upon receiving this msg, installs unicast next-hop for dest-IP. L3 routing for dest-IP works fine after this step.

Summary:
When the PFEM sends the initial packet to CPU / SFI and the hold_nh entry has not been programmed yet any further packets coming in for the same destination will cause these messages to be logged.
- PFEM sends the initial packets to CPU / SFI
- hold_nh entry has NOT been programmed yet
- All packets coming in for the same destination (until hold_nh is programmed) will cause these messages to be logged.

These messages are not harmful. However, seeing too many of these messages for different next-hops could indicate some kind of IP scanner or virus sending packets to lot of non-existent IP addresses. 
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search