>We would need more info to determine why the node went down. One common
> >cause is that it is configured to get its address from a seed router that
> >doesn't exist or is not up. In any case, there is no need to reload the
> >router. A "clear apple interface" should restart the address acquisition
> >process again.
> I had done a "clear app int" and even a "clear int", but the interface
> would not come up. This node was not supposed to get it's address from a
> seed router. Also, the node had been working fine for quite some time and
> just suddenly went down. There are 10 remote sights connected through a
> Frame Relay & the sub-interfaces were all fine.
> Sorry I didn't include this info in the original post.
> Actually, after I reloaded the router, everything was fine. Also, a friend
> told me that Cisco routers do not forget the AppleTalk address until the
> router is reloaded. Sortta like sub-interfaces. Is this true?
> The point I was really confused about is that after I re-assigned the
> AppleTalk cable range, it came back as node 158. Then I got a console
> message that the AppleTalk interaface was up. But when I did a "sho app
> int", it claimed the interface was down. After I reloaded, it used node
> 158 again, and showed that the AppleTalk interface was up. Now why would
> it use the same node address - assuming the address was invalid 2 mintues
> prior? No nodes had been taken off or put onto the network, so the NBP
> database should have been static. (It was 2 AM, everyone was gone.)
> Nothing had changed, yet the interface was no longer "invalid". That's
> what I have a problem with.
> Does anyone have any idea of what happened?
> TTFN,
> patrick
> +----------------------------------------------------+
> | Patrick Gilmore, Network Engineering Supervisor |
> | Johnson Controls Network Integration Services, LA |
> | 800-526-4752 Voice + 213-621-2212 Fax |
> +----------------------------------------------------+
This is a strange one. I have to run appletalk and see the configuration.