Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!corwin From: corwin@Apple.COM (Paul Frommeyer) Newsgroups: comp.protocols.appletalk Subject: Re: Need help with Telneting across Zones with Fastpath (long) Message-ID: <46753@apple.Apple.COM> Date: 21 Nov 90 18:45:45 GMT References: Organization: Apple Computer, Inc. Lines: 71 jhh1@ra.MsState.Edu (Jim Harfst) writes: >Help! I am trying to telnet from a Mac IIcx in one zone through a Fastpath 4 >in another zone and I can't find any zones on the Ethernet backbone. Here >The Mac IIcx can't seem to find the host. I am using Stanfords MacIP 4.0 >with MacTCP. I have the Fastpath set up for static addressing and everything >is Phase II. Any machine *between* the Netbridge and the Fastpath has no >problem telneting or FTPing, etc. >I am beginning to get desperate. Help! Assuming you're using KSTAR 8.0, here's the deal: As you may know, there are two kinds of AppleTalk DDP packets, short and long. Long packets are designed to be used on an extended network (one with routers), and contain lots of good stuff about the network numbers of the source and destination networks. Short DDP packets do not contain the network number fields. Now. The FastPath and MacTCP (for reasons unknown to me) like to use short DDP packets for NBP BrRq (name lookup). So, any router adhering to the letter of Inside AppleTalk specs and not forwarding short DDP packets, will cause the IPGATEWAY lookup from MacTCP to appear to "blackhole" with no response. This gets amusing when using dynamic KIP, because the Mac will get its address (MacTCP uses long DDP packets for that), but then the gateway lookup breaks... I think this all came about because originally no one seems to have ever intended KIP to work across networks and zones. But I digress. We use Apple Internet Router software (suprise, suprise), and luckily for our FastPath users this will forward short DDP packets. Just how the router software is able to sort this out isn't entirely clear to me (I don't write any of this stuff, I just have to use it). In any event, it sounds to me like the NetBridge, though a fine product, isn't passing on short DDP packets. All of this assumes that your MacTCP setup is in order. You must have encapsulation (IP-IN-DDP KIP) selected (but then you're not on Ethernet anyway), and you must have correctly configured your network numbers, network mask, and subnet value (very important) so that they _agree across the board_ with the FastPath's idea of what these should be. As another poster pointed out, the FastPath will only provide encapsulation service for hosts within its address range. If any one of these is out of sync, you'll be S.O.L. You must have the zone in MacTCP set to that *of the FastPath*, NOT the Macintosh. If you are subnetting your LocalTalk (I never understood the need for that...), you are in for some additional headaches in configuring the FastPath. Your best bet is to do some network analysis and see just what dialogue, if any, is occuring between the FastPath and your Macintosh. I've found the Watch network analysis application (available from the Info-Mac archives at sumex-aim.stanford.edu) to be pretty good at debugging KIP service problems, though it's riddled with bugs and idiosyncrasies. This is really the best way to go; no two networks are alike, and no amount of advice is as good as a thorough site-specific analysis given the unique nature of network problems. Hope this was of some help to you and other net.readers wrestling with KIP service. It'd be nice if we heard from Shiva on this, since they make the NetBridge and (now) the FastPath... Cheers, Paul >Jim Harfst >Mississippi State University -- Paul "Corwin" Frommeyer "The whole damn world's gone to hell since Network Sorcerer and Telecomm Hacker David Lee Roth left AT&T" Apple Computer Incorporated Internet: corwin@apple.com UUCP: apple!corwin printf("Disclaimer:%s\n",common&&sense?"My opinion, not Apple's":"No comment");