Thanks for the clarification. Is DHCP Proxy via Ethernet EVER going to
be supported? Every WAN I install could use it and although I would HATE
to switch equipment, if it's never going to be part of ComOS, then it's
time for me to find another router since the amount of effort learning
new communications equipment is much less than configuring the IP, DNS
and WINS addresses of thousands of PCs.
Thanks
Rod
> -----Original Message-----
> From: MegaZone [SMTP:megazone@livingston.com]
> Sent: Thursday, February 05, 1998 2:44 AM
> To: portmaster-users@livingston.com
> Subject: (PM) DHCP
>
> Ok, all this DHCP stuff got me to stay late (arg, and I have to do
> another
> training class in the morning) and I looked at the other customers I
> knew
> of, what was being attempted here, and what we do. I was lucky enough
> to
> catch one of the other engineers on it too.
>
> Short answer - WE WILL NOT PROXY DHCP COMING IN FROM THE ETHERNET.
>
> The way the proxy was implemented it was in response to server
> requests
> we had to handle DHCP requests coming in over the external links. So
> the code only handles proxy requests that come in over a
> Point-To-Point
> interface.
>
> Part of the misunderstanding is my fault. I worked with people using
> PMs at remote sites handling DHCP over a WAN link back to a server.
> But
> the clients making the requests were NOT on the ether, but on the
> serial
> ports. When I saw the latest request in my mind's eye I
> mis-remembered
> what had worked as what was being tried. Which is why I couldn't
> understand why it wasn't working in this case.
>
> Being able to handle proxy requests from the ethernet is a more
> complex
> propisition. We talked about it and looked at the code, and to be
> safe
> we need to do some kind of 'split-horizon'. So that we don't resend a
> request out of the same interface we got it in on.
>
> We'd have to get the request, determine which interface it came in on,
> find our route to the proxy host, and then resend it only if the route
> wasn't on the same interface. If it was the same we'd have to drop
> it.
>
> None of that intelligence is there now, we just get it and pass it on
> since a PTP link isn't a broadcast medium like ether, where it would
> be
> likely to have a server on the ether in many cases.
>
> So the answer is - I'm sorry, I half-remembered what was being done.
> What you are trying to do with two units and proxying requests from
> the
> ethernet will NOT work today. And it won't be a short term fix, so I
> can't promise that it will be in 3.8. In fact, as 3.8 is well along,
> most likely it will not be in that release.
>
> But we are doing further DHCP work in relation to the NAT code, and we
> may be able to tag this on to that project.
>
> Sorry for the confusion and frustration.
>
> -MZ
> --
> Lucent Remote Access Division - Chair, Department of Interstitial
> Affairs
> Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110
> megazone@livingston.com
> For support requests: support@livingston.com
> <http://www.livingston.com/>
> Snail mail: 4464 Willow Road, Pleasanton, CA 94588
> -
> To unsubscribe, email 'majordomo@livingston.com' with
> 'unsubscribe portmaster-users' in the body of the message.
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.