Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!aramis.rutgers.edu!qbranch.rutgers.edu!rapatel From: rapatel@qbranch.rutgers.edu (Rocky) Newsgroups: comp.protocols.appletalk Subject: Re: UDPTalk as a backbone Message-ID: Date: 7 Sep 89 02:02:23 GMT References: <1989Sep4.202733.6326@caen.engin.umich.edu> <1435@intercon.UUCP> <1989Sep5.193002.15583@caen.engin.umich.edu> <4727*kenw@noah.arc.cdn> <1989Sep6.173858.24519@caen.engin.umich.edu> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 40 >All networks and routes must be supplied by the >administrative host (atalkad) if you have IP subnetting. Additional routes >will not propagate, since RTMP (which is updated with new routes) broadcasts >from boxes with additional (non-supplied) routes will not be received from >across IP gateways. Just one note, we use Hayes Interbridges (as both local bridges and remote bridges) with our KIP based Kboxes and I do not configure their routes/zones in atalkatab. The routes are updated within a few minutes (1 or 2) to all our kboxes. This includes the zone entry for a remote bridge. This zone entry normally only shows up when the modems are working. This implies that the kboxes use at least some routing update mechanism - RTMP or otherwise. By the way, I am forced NOT to make entries for the interbridges. This is because our interbridges decide to ignore the kboxes if the kboxes already advertise the route. Because of this and some other problem with the interbridges, sometimes an interbridge resets some how and ignores the kbox (since the kbox already thinks it knows how to route for the network the interbridge is bridging to, the interbridge believes the kbox is sending bogus routing info). The way to get around it is to shut down the interbridges on the localtalk and power cycle the kbox. The kbox just comes up with the pre-configured routes and the interbridges then believe its info. We also had PacerLink/PacerShare show up properly (Pacer runs a virtual bridge to run PacerShare<->ethertalk) using the ethertalk support from KIP. The Ethertalk support from KIP is buggy however, so the dept. is running the Kinetics ethertalk gateway code instead (until they can replace the KFPS-2 with a KFPS-4 running K*). So every entry does NOT need to be added into atalkatab - at least not for bridges. Rakesh Patel.