Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!JESSICA.STANFORD.EDU!morgan From: morgan@JESSICA.STANFORD.EDU Newsgroups: comp.protocols.appletalk Subject: Re: IPADDRESS vs IPGATEWAY Message-ID: Date: 21 Jul 89 18:46:50 GMT References: <928@wucs1.wustl.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 50 > Since making this change, atlook now views the K-4 box as an > IPADDRESS, whereas previously atlook recognized the K-3 box as an > IPGATEWAY (the "correct" answer). Is this a bug? If so, is there a > solution? More importantly, is this a big deal? All of our services, > such as NCSA Telnet and CAP work fine with the box as an IPADDRESS, > but is this hurting us in some subtle way? Here's what my experiments show, with KSTAR: If you sit at a Mac on a LocalTalk and generate NBPLookups (using CheckNET from Farallon or any other fine product), if you look up =:=@* (any device of any type in this zone), then Mac/IP|NCSATelnet users show up as IPADDRESS, other KSTAR-Kboxes in the zone show up as IPADDRESS (two or three times, one for each of LocalTalk, IPTalk, and EtherTalk), but one's own KSTAR-Kbox shows up not at all. Looking up =:IPGATEWAY@* will produce the appropriate response from the local KSTAR-Kbox (my.ip.address:IPGATEWAY@*), but none from others in the zone (this lookup is how Mac/IP and NCSATelnet find the gateway when they first start up). If you sit at an Ethernet-attached Mac and generate lookups, or use atlook from CAP, you see the IPADDRESS responses just the same to a =:=@* lookup, but no response at all to a =:IPGATEWAY@* lookup. With KIP (as I recall, we've converted all the local boxes to KSTAR here), Kboxes will respond to =:=:@ lookups as IPGATEWAY no matter what, but will not respond to =:IPGATEWAY@* lookups when they come in via Ethernet. I think these are just two different strategies to dealing with the problem that a LocalTalk-attached Mac wants to find *only* its local IPGATEWAY when it does a =:IPGATEWAY@* lookup. Both of them slightly violate AppleTalk good rules of conduct, but perhaps KSTAR's behavior is a little more confusing. KSTAR has a configuration option (option 7) that isn't documented in anything I have, that will cause the Kbox to respond to IPGATEWAY lookups coming in from the Ethernet. This could be set if you wanted to get dynamic IP assignment for an EtherTalked Mac (though this can be done other ways with MacTCP), or if you wanted to have one Kbox be the IP gateway for multiple LocalTalks/Ethernets (as somebody was asking a few messages ago). Beware, though, that if SU-Mac/IP (and probably NCSATelnet, too) hears from multiple IPGATEWAYs in response to a lookup (ie if they're in the same zone), it refuses to operate since it doesn't know which one to talk to. - RL "Bob" Morgan Networking Systems Stanford