earle@mahendo.Jpl.Nasa.Gov (Greg Earle) (04/07/89)
In article <15134@bellcore.bellcore.com> karn@jupiter.bellcore.com (Phil R. Karn) writes: >>Well, for one thing, Phil's code associates an IP address with the *host*, >>not with each interface. (See? KA9Q isn't *perfect*... yet.) > >I consider that a feature, not a bug. :-) Seriously, I have always >considered the Internet approach of giving addresses to interfaces >rather than to hosts to have been a bad move, and my approach of "one IP >address per customer" was a deliberate design decision based on how I >wanted the amateur packet radio TCP/IP network to evolve. Until a few days ago, I had thought that any machine with more than one network interface *had* to have a separate IP address for each interface. Now it appears that this isn't necessarily so; I infer that both from Phil's posting, and I also just discovered an Encore Annex terminal server that gives the same IP address to it's Ethernet interface, and to a permanently- attached SLIP interface (which connects the Encore here at JPL to a Sun at a Rockwell site about 35 miles away). When I first did the netstat -i on the Encore and noticed that it spewed out the same IP address, my brain started to hurt and I almost blew my cookies (^: "Non sequitur!!" my brain howled. "How is this possible? Doesn't it break things left and right?" it asked. Can someone quote chapter and verse on where this is allowed? Is it not recommended? Does it break anything to do things this way? I'm confused ... As much as my brain dislikes the idea, in practice it has a highly desirable side effect (for me): the Ethernet interface on the Annex has an IP address which is directly on the JPL backbone network. By having the same IP address on it's SLIP link, the Sun at the other end can have an IP address on that interface which is also on the backbone. With a simple net route to the backbone net through it's SLIP interface, and a default route with the Encore as the gateway, the remote Sun has no routing problems whatsoever. On the other hand, I have a dialup SLIP link to a Sun which also sits on the JPL backbone; we are doing the conventional allocate-a-new-subnet- with-2-hosts-on-it method. So, not only is my IP address on a subnet instead of the backbone, but it appears that the gateway's `gated', seeing that the SLIP link to me is a point-to-point link, declares a host route to my machine and proceeds to propagate that to the world (instead of a net route to the SLIP subnet). From what we've seen, boxes like the Proteon p4200 don't seem to grok this advertised host route, so I cannot reach any machines that are behind such a gateway. The machine I'm typing this on is such a machine, and reaching it was one of the main raison d'etres for hooking up the SLIP link in the first place! *sigh* ... Thus, if I could have the remote SLIP gateway host declare it's SLIP interface to be the same IP address as it's address on the JPL backbone, then I could do the same thing as the Encore-Sun combo and gain a backbone IP address as well, and make these routing problems vanish (that is, if I could only fool `gated' ... or use a fixed static route to the backbone net address). Further enlightenment would be appreciated ... -- Greg Earle earle@Sun.COM Sun Microsystems earle@mahendo.JPL.NASA.GOV JPL on-site Software Support poseur!earle@elroy.JPL.NASA.GOV ...!{cit-vax,ames}!elroy!poseur!earle ...!sun!{poseur!}earle