From owner-freebsd-hackers Sat Feb 13 18:47:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA06793 for freebsd-hackers-outgoing; Sat, 13 Feb 1999 18:47:54 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA06771 for ; Sat, 13 Feb 1999 18:47:51 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id QAA27637; Sat, 13 Feb 1999 16:05:10 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp02.primenet.com, id smtpd027609; Sat Feb 13 16:05:02 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id QAA01117; Sat, 13 Feb 1999 16:04:56 -0700 (MST) From: Terry Lambert Message-Id: <199902132304.QAA01117@usr02.primenet.com> Subject: Re: ppp server side startup commands To: chuckr@mat.net (Chuck Robey) Date: Sat, 13 Feb 1999 23:04:54 +0000 (GMT) Cc: tlambert@primenet.com, phoenix@calldei.com, netmonger@genesis.ispace.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Chuck Robey" at Feb 12, 99 10:16:27 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-options-05.txt > > > > The PPP server should obtain IP addresses via DHCP. > > Terry, these are static IPs (like I said). Why would I want to get IP > numbers that I already know of? I have to experiment with Brian's > solution (which bothers me much more, because it doesn't seem to give me > a chance to tell ppp what the additional IP number is). I haven't yet > tested Brian's answer, but I was under the impression that DHCP was used > to ID machines; wny would I want to ID a machine I already know of? Well, this is how the cable modem addresses are assigned. They have a static address in the A block, and they use DHCP to ask what the static address is. The point of this is that DHCP supports information other than the IP address alone. It does netmask, domain name, DNS server, gateway, etc.. > Just in case you forgot, the idea was, ON THE SERVER SIDE ONLY, to take > and allow for an extra static IP on the client side. This meant one > more arp and one more route command one the server. I can handle the > client side fine now. I sent a draft off to the ISC people with regard to what I call a "blind secondary DNS server". The gist of the draft is that you have a dialup machine that needs more DNS information than you can get via a single DHCP request. The client machine runs a standard split horizon DNS, one on the dialup interface, and one on the internal ethernet. The client acts as the gateway, router, or NAT device to the LAN. The DNS on the dialup port is a true secondary for the domain. The DNS on the LAN believes it is primary for the lan, and designates the dialup interface as its forwarder. The point of a "blind secondary" is that, not only can the ISP, who controls the true primary for the domain, relocate resources that the dialup gateway/router/NAT may need to know about (e.g. secondary MX's, www server, and ftp server, etc.), the ISP can relocate the primary while the secondary is offline. In this case, the secondary can't know the primary has moved via notification, since that would require the ISP bring up the line to the dialup device. To resolve this, when a TTL expires, resulting in a need for the secondary to perform a zone transfer, the secondary attempts to contact the primary to satisfy the transfer. To do this, it goes to the root server, and asks for the primary, as if it were some other (unrelated) DNS trying to resolve an address in the domain. Once the primary is identified this way, a zone transfer is initiated. The semantics of this are: secondary Berkeley.EDU * ucbhosts.bak In other words, instead of the IP address of the primary, an asterisk is used to indicate "I don't know; find the thing". Now, how can this solve your problem? This can solve your problem by setting up DNS information that knows about the other machine on the server. You can use this information to establish explicit routing. Even without "blindness" (since you're the server), this can do the job, though you risk losing sync with the primary while the client is offline. Alternately, you can subnet the line, and assign both addresses in the subnet. Alternately, you can use BGP/EGP on one client to thell the server about the other client. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message