morgan@JESSICA.STANFORD.EDU (07/22/89)
> 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
minshall@kinetics.UUCP (Greg Minshall) (07/27/89)
From article <928@wucs1.wustl.edu>, by kahn@wucs1.wustl.edu (Michael Kahn): > We've recently switched from a K-3 box running KIP to a K-4 box > running KSTAR ... > 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? Yes, it is a bug. It is also a bug that KIP only answered IPADDRESS. Both "should" answer everything they are - WHEN APPROPRIATE. Bob Morgan, in another follow-up to this message, indicated that neither KIP nor K-STAR should reply in certain circumstances which have to do with where the person doing the NBP lookup is sitting on the network (by the way Bob, =:=@* *should* return an xxx:IPADDRESS@* answer from localtalk - but that may be a second bug, sigh). The reason that two K-boxes replying IPGATEWAY makes the various MacIP programs die is that each K-box *also* replies to yyy:IPADDRESS@* queries where "yyy" is NOT one of the IP addresses assigned to the individual K-box. (This makes some MacIP programs work). Hope this is useful. Greg Minshall Kinetics/Excelan/Novell minshall@kinetics.com 1-415-947-0998