DMVPN after NHRP resolution

hi all


in this nice post:

I am qouting this part:

At this point, R2 receives the original data packet from R3 (ICMP echo) and tries to send a response back. The problem is that the destination IP address for the echo reply is “” and the next-hop is “”, which has “glean” CEF adjacency. Again, R2 replies back across the hub and send a Resolution Request packet: first, directly R3 – this attempt fails – then it sends the resolution request to the NHS.


the question is if NHRP was ARP-like protocol, then after R3 resolve the real IP address of of R2 and send first ping echo packet, R2 has to requets from the Hub the real IP of R3 (through NHRP resolution request), but is not this address included in the packet received from R3 (source address) !?

in ARP the sender put its MAC address as the L2 source, then the recived will use it as L2 destination.





  • Very nice question!

    It would be an improbable scenario in Ethernet, but what if an Ethernet NIC actually receives a frame destined to itself from an unknown source MAC address?

    Question: When receiving a frame with an unknown IP address and unknownsource MAC address, but the destination MAC and IP address are the NIC's addresses, will the NIC/OS install the IP-MAC mapping into the ARP cache?

    Normally, the ARP cache is only populated with the use of ARP replies, and updated with the use of ARP replies and requests. And sometimes static manual configuration. But i dont think it gets populated or updated by other IP packets arriving from the particular IP address. (must verify)

    In the DMVPN example's case, R2 received the first "ping echo" from the hub (not directly from R3). After the IOS generated the echo reply, it then had to create an IP packet and a GRE packet. When it couldnt find an entry in its NHRP cache, R2 generated an NHRP resolution request.

    The NHRP cache can only be populated by NHRP replies. (and/or static mappings) (again, must verify)

    Please post any answers you mind find about this nice question!

  • Great question!

    I presume that in Ethernet, it will be a very uncommon scenario that a NIC will receive a frame from an unknown MAC address.

    Normally a host (originator) would first broadcast an ARP request that the destination NIC will reply to, and thus the destination NIC will add the originator to its ARP cache.

    In the case that it receives a frame with an unknown MAC address and an unknown IP address, a host will not populate its ARP cache with the mapping. (must verify)
    The ARP cache is only populated by ARP requests when addressed to the NIC's IP address, by ARP replies that are answers to earlier ARP requests, and my manual configuration.
    Not by IP packets destined to the NIC (again, i found no reference claiming this particular point explicitly, so MUST verify)

    In similar fashion, NHRP will not populate the NHRP cache with any IP packet destined to the router. NHRP only uses NHRP Resolution Replies to polulate its cache and static bindings.
    Again, RFC 2332, Section 6.2.1 is not very clear about this, so MUST verify from another source.

    In Petr's example, R2 receives the First original data packet from R3 (ICMP echo), from R1 (the Hub). At exactly this point the IOS attempts to build the GRE packet to send the ICMP Reply to R3. Looking at its NHRP cache, there is no entry for R3. Remember, by this time only a single packet arrived from R3, and it arrived from R1's NBMA address.

    There are two reasons that R2 did not add an NHRP binding into the NHRP cache by this point:
    1. R2 has yet not received any packets from R3's NBMA address. The ICMP echo actually arrived from R1's NBMA address. Thus, R2 has no NBMA address information (for R3) available to create a binding.
    2. R2 cannot populate the NHRP cache with any mechanism other than:
      a.  an NHRP Resolution Repliy
      b.  a manual binding in configuration

    MUST verify point 2

    Please post any more info you get about this

  • thanks for your reply,


    hope one of INE experts reply to this.

Sign In or Register to comment.