nhrp network-id is a locally significant. Think OSPF process ID. Much as you keep the OSPF process ID the same across a domain for sanity, Cisco recommends you keep the nhrp network-id the same on a single NHRP network(hub interface, and spokes) as a quick reference for what tunnel interface it terminates to on the hub.
So as you tested, you can use different network-id values on the spokes, as the network-id only matters locally. Or you can do crazy things, on the hub, like bind two GRE tunnels to the same NHRP network(dmvpn cloud). --Pete On Wed, Sep 8, 2010 at 9:13 PM, danger will <[email protected]> wrote: > Hi there > > i’ve been bashing my head around this problem for a few days please help > > ip nhrp network-id this is used to turn on nhrp on an interface and to > provide the logical membership to a certain DMVPN cloud, otherwise > stated each DMVPN cloud should have it’s unique network id, at least this > is what all the design guides recommend. > > What i did in my lab was to have each spoke and the hub in different > DMVPN clouds meaning spoke one had network-id 1 , spoke 2 had network-id > 2, hub had network-id 3 etc and it seemed to work just fine so i don't > understand the use of “ip nhrp network-id” and i can't seem to find a > document to explain this in greater detail > > Thanks > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
