The IP over ATM Mailing List Archive by date

[Curtis Villamizar <curtis@ans.net>]

In message <9501061955.AA01210@eng.adaptec.com>, Bryan Gleeson writes:
> 
> The problem with (2) is that it is complicated. Configuration
> is more complex as each client has two or more IP addresses.
> On an ARP server failure, a client needs to switch to another
> ARP server of course, but also ALL other communication with
> clients on the first LIS has to be terminated and restarted
> on the second LIS. Furthermore this cutover is visible to
> IP stack applications, as the destination IP addresses will
> be different. A ARP server failure affects all the "data"
> VCCs. This is certainly not a general solution.

This is simply not true.  The IP address of intermediate routes has
absolutely nothing to do with the IP address of the end points.  If
your mission critical application is on a host on both LIS, bind the
socket to the loopback and use IP routing so the change in next hop is
invisible to both ends.  BTW - we do this all the time!  The router
IDs of all our routers are tied to their loopback addresses.

If your going to tell me you don't have source to your mission
critical application to add the bind, then I'm going to wonder how it
could be so mission critical.  :-)

> It is also disingenuous to suggest that only having one
> ARP server is acceptable because the switch it is connected to
> is a single point of failure anyway. A switch is only a single 
> point of failure if the network is designed that way. It is 
> obviously possible to deploy a redundant switching fabric, 
> will all critcal machines connected to multiple switches.

There is always one switch immediately adjacent to the host ATM
interface.  Granted, there could be two interfaces on the host with
different IP addresses on the same LIS (BSD/Unix will currently barf,
but could be made to tolerate this).

> The small change to 1577 to allow redundant ARP servers is, 
> I think, more along the lines of tracking what people are 
> going to do anyway, rather than anything else.

What small change are you suggesting?  Pardon me, but I don't see it
as so obvious.

> Bryan Gleeson
> Adaptec.

Curtis