romanell@brahms.udel.edu (Richard Romanelli) (09/24/90)
We are trying to set up a policy for the restart and reload of Proteon Routers on our 80Mb ring. All 10 of the P4200s are running 8.2 software with the new ROMs. The main idea is to maintain connections through the routers when doing restarts and reloads or not notify eveyone affected of our intention to restart/reload. Through experimentation we have found that restarts do not affect connections. Is this always the case and should we feel free to restart a router without notification, knowing connections will not be dropped? For the most part, reloads, even with the new ROMs, do no affect connections. Some connections have dropped in the past, however, when we reload a router. Certainly the network software being run on individual hosts will affect the robust-ness of the connection. When does a P4200 determine that a host/net is unreachable? Should we reload only after everyone on the net has been notified? Rich Romanelli University of Delaware
ron@brahms.udel.edu (Ron Reisor) (09/25/90)
In article <13982@brahms.udel.edu> romanell@brahms.udel.edu (Richard Romanelli) writes: > >For the most part, reloads, even with the new ROMs, do no affect connections. >Some connections have dropped in the past, however, when we reload a >router. Certainly the network software being run on individual hosts will >affect the robust-ness of the connection. When does a P4200 determine that >a host/net is unreachable? Should we reload only after everyone on the >net has been notified? > It's not clear that reloads do not affect tcp connections. Certainly if there's a problem that shows up during the reload, and minutes instead of seconds of router down time is experienced, then tcp connections are likely to be broken. I have noticed tcp connections die for no apparent reason--this tends to happen only when the connections go off subnet 13. You will build more confidence in the network if you notify everyone, at lease through this news group, whenever you restart or reload a router. That way, if there are no problems caused, people read the notification and think "it really doesn't cause any problems". But, if the restart does cause problems we would at least have a chance of relating the problem to the restart. I think it's too much to notify everyone before the reload, but you should document, at least in this news group, every reload. Ron
swb@DAINICHI.TN.CORNELL.EDU (Scott Brim) (09/25/90)
I think it's too much to notify everyone before the reload, but you should document, at least in this news group, every reload. Ron Yipe! If you're going to do that, please keep the announcement local to UDel. Thanks ... Scott
louie@SAYSHELL.UMD.EDU ("Louis A. Mamakos") (09/25/90)
The problem is caused by traffic through the router just after restart/reload, when the router doesn't have a route to the destination. It sends a Destination Unreachable ICMP advisory to the source of the traffic. Most BSD based TCP implementations and applications tend to give up when such an ICMP message arrives. You could try to configure a default route to handle this interval after you restart/reload the router, but before it has got routing information via RIP, EGP, OSFP, etc. This is sort of ugly. But I suppose, so is restarting the router to give it a new configuration. I once suggested to Proteon that they inhibit generation of ICMP messages for some interval after the router starts up to avoid this problem. louie
ron@brahms.udel.edu (Ron Reisor) (09/25/90)
Duh... Sorry folks! Rich Romanelli and I are talk about routers at UDel and not outside of UDel. I thought I was replying to our local "udel.networks" list, but my message leaked into comp.sys.proteon. I just sent a follow up message and didn't watch what I was doing. On the other hand: thanks Louie for reconfirming what I believed was happening when routers were restarted, and thanks Scott for pointing out how silly it would be to notify this news group when a router was restarted at UDel. cheers, Ron