First time relayed network

[Tuc at Beach House]

Hi,

Thanks. Actually solved it this morning after piecing together help from a
few people. Option 82 googling makes it FAR scarier than it needs to be. I
also then started debugging source to figure out the problem with the
"unknown network segment" to find out it was my misreading the correct
subnet 205 times.

Yes, it was actually as easy as adding a shared-network and putting the
correct subnet. I didn't need to mess with agent.link-selection or anything!

Thanks, Tuc




On Fri, Mar 24, 2017 at 9:41 PM, Patrick Trapp <ptrapp at nex-tech.com> wrote:

> When I see those in my logs, it is because the  request is coming from a
> network the DHCP server is not addressing and it does not know what pool to
> associate the request with. I create a shared-network statement including
> the intended pool and the mystery network. Since I'm not providing an
> address for the mystery network, the network statement (where i would
> normally define the network) is a pair of empty braces.
>
> I hope that makes sense - I can provide example configs later, but not at
> the moment. Hope it helps.
>
> Patrick
>
> > On Mar 24, 2017, at 7:51 PM, Tuc at Beach House <tuctboh at gmail.com>
> wrote:
> >
> > Hi,
> >
> >
> > I'm trying to figure out how to do relayed subnets within a datacenter
> > owners environment and our (sorry, old) 4.1.1-38.P1 ISC DHCP server.
> > Normally we allocated an interface to our machine for every subnet
> > that its on, but this new network is "remote" and they won't stretch
> > L2 to us.
> >
> > So the normal config isn't what I'm used to, but works :
> >
> >        subnet 10.14.14.0 netmask 255.255.255.0 {
> >
> >               interface eth0;
> >                authoritative;
> >                allow booting;
> >                option routers                  10.14.14.1;
> >                option subnet-mask              255.255.255.0;
> >                option domain-name              "cust19782.dc.example.com
> ";
> >                option domain-name-servers      10.14.2.1;
> >                option ntp-servers              10.14.2.1;
> >                next-server 10.14.14.11
> >                filename "pxelinux.0";
> >                pool {
> >                        option routers                  10.14.14.1;
> >                        option domain-name-servers 10.14.2.1;
> >                        max-lease-time 600;
> >                        range 10.14.14.200 10.14.14.254;
> >                        allow unknown-clients;
> >                }
> >        }
> >
> >
> > And the others all are the same, but with different "interface"
> > statements. It is not wrapped in any sort of "shared-network"
> > statement.
> >
> > I'm getting valid Option 82 information, so I did :
> >
> > class "EXTDHCP" {
> > match if option agent.link-selection  = "10.14.18.0";
> > }
> >
> > And then pretty much the same except removed the "interface"
> > statement, and added "allow members of "EXTDHCP";" into the pool
> > statement.
> >
> > However, all I keep seeing in my logs is :
> >
> > dhcpd: DHCPDISCOVER from 81:9c:de:3b:61:02 via 10.14.17.2: unknown
> > network segment
> >
> > 10.14.17.2 is the TOR switch IP thats handling the relay. I can't seem
> > to find any more in depth debug. Pointers to where I went wrong? (And
> > "Using DHCPD 4.1.1" if it can't do it is acceptable)
> >
> >
> > Thanks, Tuc
> > _______________________________________________
> > dhcp-users mailing list
> > dhcp-users at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/dhcp-users
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20170324/50cf8bdf/attachment-0001.html>