morgan@JESSICA.STANFORD.EDU (07/21/89)
Ben Schmidt writes: > Assuming that duplicate net numbers might be involved here, can I get > some comments on techniques for tracking them down? My tool of choice for this and most other protocol problems is Network General's Sniffer. It includes AppleTalk decoding, for both the EtherTalk and IPTalk encapsulations, so it's pretty easy to see what's going on. It's easy to set it to capture RTMPs, and it breaks out the routing table for you. You can also see ZIPs, which often seem to fly around chaotically when there's routing instability, as routers try to match up zones with network numbers. Of course, it only works on Ethernet (for AppleTalk purposes) at the moment. Not cheap, though, at $15K or $20K or something. (Aside: Cmon, Mr. Free Enterprise System! Where's the MacII-based protocol analyzer that everyone craves and that would sell like hotcakes?) > For example at last count, there are 11 different types of > AppleTalk routers on my internet, each generating (hopefully valid) > routing broadcasts every 10 seconds! (KFP2, KFP4-Subnetting, KFP4- > KStar, Hayes InterBridge, Shiva TeleBridge, PacerLink, AlisaTalk, > Liason s/w, Apple Internet Router s/w, Cisco AppleTalk routing, > LANSTAR Bridge s/w.) Gee, and I thought things were bad here. I hope this doesn't start an AppleTalk Swamp-of-the-Month contest . . . *8^). We've avoided some of this pain by not having any Kboxes (or any other AppleTalk-speakers) on our backbone, but only on dependent IP subnets. KIP static routing is a more manageable base to start from than pure AppleTalk dynamism. > Finally are other large sites concerned about possible problems with > multiple implementations of AppleTalk routers on their nets - without > any compliance or certification that they meet the AppleTalk specs and > will interop? I think the fact that your net works at all shows that AppleTalk routing is pretty easy to implement from spec. My experience is that routing per se (DDP, RTMP) is not the problem, but all the other things that are required of the router: NBP handling, IP gatewaying (for Kboxes), management, zone maintenance, etc, etc. It's tempting to put every network fix-it function in the world into the router, but each item added makes it harder to get the whole mess right. - RL "Bob" Morgan Networking Systems Stanford
harry@ngc.UUCP (Harry Saal) (07/25/89)
In article <Added.8YlVM1q00UkTQLwk9w@andrew.cmu.edu>, morgan@JESSICA.STANFORD.EDU writes: > > My tool of choice for this and most other protocol problems is Network > General's Sniffer. It includes AppleTalk decoding, for both the > EtherTalk and IPTalk encapsulation ..... [cut...] > [cut....]..... Of course, it only works on > Ethernet (for AppleTalk purposes) at the moment. Actually, as of early June, Network General now supports, in addition: AppleTalk 2.0 protocol decodes TokenTalk (AppleTalk over TRN) LocalTalk (e.g. 230 Kbs HW, with AppleTalk protocols). These extensions were announced jointly during Apple's networking rollout. Unfortunately this seems to have been totally lost in the attention to Apple's new offerings!
amanda@intercon.uu.net (Amanda Walker) (08/15/89)
In article <Added.cYktlpO00Ui3AQ6E85@andrew.cmu.edu>, BSCHMIDT@bnr.ca (Ben Schmidt, B.T.) writes: > Hence while > they have only say 2 printers on their zone, they'll see a dozen or > more printers in the Chooser, constantly changing every 2 seconds. This looks suspiciously like a problem I saw at one point where not all of the bridges on an EtherTalk backbone had the same network number configured for the Ethernet segment. Thus, the Macs' idea of the Ethernet network's AppleTalk net number fluctuated with every RTMP packet that came by. Weird stuff, but fixing the misconfigured bridges solved the problem. -- Amanda Walker InterCon Systems Corporation -- amanda@intercon.uu.net | ...!uunet!intercon!amanda