Re: ARP and NHRP question

[Bryan Gleeson <[e-mail]>]

Tim

>Are you saying that an NHRP server and an ATMARP server should co-reside,
>perhaps even share a common database, but support two protocols for
>resolving IP addresses into ATM addresses?
>
>Or, should the "NHRP server be the ATMARP server" in the sense that
>the server and clients support only one protocol for resolving IP
>addresses into ATM addresses, namely the NHPR protocol?
>
>By the way, I prefer the latter solution: migrate to using the NHRP
>protocol (or any other other _single_ protocol that works, for that
>matter) for resolving both intra-LIS and inter-LIS IP addresses.
>

Yes I agree with this, and with Grenville's and other postings that have 
already agreed with this. We should allow clients to use _one_ address
resolution protocol, namely NHRP. We should require that NHRP servers
also implement ATMARP server functionality, so that a client can use
either ATMARP or NHRP. There should definitely not be a requirement
that a client must try ATMARP first, and then NHRP, or NHRP first
and then ATMARP. This is just the principle of pushing the complexity
into a small number of servers rather than a large number of clients.

I think it would be OK to require that these NHRP+ATMARP servers
only implement the ability to respond to ATMARP requests, and don't
have to bother with issuing InATMARP requests everytime a new VCC
is established, behaviour which I guess is obsoleted by 1577+. It 
depends on how far back you want to go in backwards compatibility.
I think most clients today actually register themselves rather than
just respond to InATMARPs issued by the ATMARP server. This is because
there is no other way for a client to know that it has actually registered
successfully.

It also brings up the applicability of the distributed ARP server
functionality in 1577+. It seems that we should be looking at having
one approach for both ATMARP servers and NHSs, and I agree with Andrew
that we need to start looking at server redundancy for NHRP soon if
it is going to be really useful.


Regards,
Bryan Gleeson
Adaptec.