dhcp-users Digest, Vol 76, Issue 25

Teva A-T tevaat at gmail.com
Sat Feb 21 02:03:35 UTC 2015


Thanks guys for your feedback, that's exactly what i'm trying to do Simon
indeed.

And no worries Niall, i've just changed the domain name server for the
example here.

I will try it and come back to you to confirm results asap.

2015-02-20 2:00 GMT-10:00 <dhcp-users-request at lists.isc.org>:

> Send dhcp-users mailing list submissions to
>         dhcp-users at lists.isc.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.isc.org/mailman/listinfo/dhcp-users
> or, via email, send a message with subject or body 'help' to
>         dhcp-users-request at lists.isc.org
>
> You can reach the person managing the list at
>         dhcp-users-owner at lists.isc.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dhcp-users digest..."
>
>
> Today's Topics:
>
>    1. Using Class to have ip address on unknown network segments
>       (Teva A-T)
>    2. Re: Using Class to have ip address on unknown network
>       segments (Simon Hobson)
>    3. Re: Using Class to have ip address on unknown network
>       segments (Niall O'Reilly)
>    4. Re: Using Class to have ip address on unknown network
>       segments (Niall O'Reilly)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 19 Feb 2015 16:39:39 -1000
> From: Teva A-T <tevaat at gmail.com>
> To: dhcp-users at lists.isc.org
> Subject: Using Class to have ip address on unknown network segments
> Message-ID:
>         <
> CAA+3+-ycjTxccj0YH-T50VBJ57XriUQ4Lpvj5YtHhpZgfikDqw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Greetings,
>
> I'm trying to use class to provide ip address to LTE customers which is on
> a network segment unknown by the dhcpd server.
>
> Here below what i can see when my LTE customers is sending its DHCP
> Discover :
>
> dhcpd: DHCPDISCOVER from 50:00:00:00:00:04 via 10.9.0.4: unknown network
> segment
>
> So indeed, 10.9.0.0 is not a network segment known by the dhcpd. 10.9.0.4
> is just a relay agent, and what i want is to provide to my LTE cust an ip
> in subnet 172.16.192.0/19. For that, i thought that i could use class, and
> then allow members of this class to get an ip, even if the network segment
> is unknown.
>
> Here below my dhcpd.conf:
>
>
> class "lte" {
> #       match if packet(24,4) = 10:09:00:04;
> #       match if (substring(hardware,0,1) = 01:50);
> #       match if (binary-to-ascii(16,8,":",substring(hardware, 0, 4)) =
> "1:5:0:0");
> #       match if (option dhcp-client-identifier =
> "(521020000000004:test1.mnc002.mcc521.gprs");
> #       match if (option dhcp-client-identifier =
>
> 3d:28:35:34:37:30:35:30:30:30:30:30:30:30:30:30:34:3a:74:65:73:74:31:2e:6d:6e:63:30:30:35:2e:6d:63:63:35:34:37:2e:67:70:72:73);
> #        match if (option
> agent.circuit-id="521020000000004:test1.mnc002.mcc521.gprs");
>             }
>
>
>
> shared-network lte-cust {
>
>     option domain-name-servers  1.1.1.1,2.2.2.2;
>     default-lease-time 360;
>     max-lease-time 360;
>
>          subnet 172.16.192.0 netmask 255.255.224.0 {
>                 option routers                  172.16.192.254;
>                 option subnet-mask              255.255.224.0;
>                 option broadcast-address        172.16.255.255;
>                 }
>
>
>
>          pool {
>                 allow members of "lte";
>                 range 172.16.192.1 172.16.192.255;
>
>              }
>
> }
>
> So i tried all match mentioned in the class "lte" in the comment (i've
> tried it one by one, uncommented one, restart service, test to get an ip,
> etc...).
>
> I tried all option tested below, but so far none of its worked.
>
> Can someone could tell me what's wrong in my class definition ? I'm still
> investigating about options i can use...
>
>
> thanks in advance all for your support :)
>
> Cheers,
>
> Teva
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.isc.org/pipermail/dhcp-users/attachments/20150219/f80b27d5/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 20 Feb 2015 10:06:14 +0000
> From: Simon Hobson <dhcp1 at thehobsons.co.uk>
> To: Users of ISC DHCP <dhcp-users at lists.isc.org>
> Subject: Re: Using Class to have ip address on unknown network
>         segments
> Message-ID: <B719570A-B764-437B-BB96-F859779D376B at thehobsons.co.uk>
> Content-Type: text/plain; charset=us-ascii
>
> Teva A-T <tevaat at gmail.com> wrote:
>
> > I'm trying to use class to provide ip address to LTE customers which is
> on a network segment unknown by the dhcpd server.
>
> That's stating how you are trying to solve the problem, not stating the
> problem you are trying to solve. So we have to reverse engineer the problem
> from your description of how you are trying to solve it.
>
> I believe your problem is :
> You have a relay agent which presents 10.9.0.4 as it's GI Addr, but you
> want to allocate client IPs from the 172.16.192.0/19 subnet. Is that
> correct, or is there more to it ?
>
> If that's all it is, then you just need a shared network - which I see you
> are half way to defining :
>
>
> shared-network lte-cust {
>
>     subnet 10.9.0.0 .... {
>     }
>
>     subnet 172.16.192.0 netmask 255.255.224.0 {
>       ....
>       pool ....
>       }
>     }
> }
>
> The trick here is to define the subnet containing the relay agent GI Addr,
> but make it a shared network with the client subnet. The DHCP server treats
> the subnets as "equivalent" in terms of what addresses it can give to which
> devices - but since your leave the first subnet empty, there are no
> addresses to allocate in it.
>
> However, this will *not* work if the same relay agent is forwarding from
> multiple client subnets using one GI Addr.
> If that were the case, then I'd suggest the relay agent is "broken". You'd
> have to work around that by putting all the client subnets into one big
> shared network - and then use classing (eg by using Option 82) to restrict
> each client to the pool/subnet to which it is actually connected.
>
>
> It would be better to "fix" the relay agent to use an IP address in the
> subnet it's relaying requests for !
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 20 Feb 2015 10:13:00 +0000
> From: "Niall O'Reilly" <niall.oreilly at ucd.ie>
> To: Users of ISC DHCP <dhcp-users at lists.isc.org>
> Subject: Re: Using Class to have ip address on unknown network
>         segments
> Message-ID: <m2twygvqkz.wl-Niall.oReilly at ucd.ie>
> Content-Type: text/plain; charset=US-ASCII
>
> At Thu, 19 Feb 2015 16:39:39 -1000,
> Teva A-T wrote:
> >
> > I'm trying to use class to provide ip address to LTE customers which
> > is on a network segment unknown by the dhcpd server.
>
>   Stop trying.  It can't work.
>
> > Here below what i can see when my LTE customers is sending its DHCP
> > Discover :
> >
> > dhcpd: DHCPDISCOVER from 50:00:00:00:00:04 via 10.9.0.4: unknown
> > network segment
> >
> > So indeed, 10.9.0.0 is not a network segment known by the dhcpd.
> > 10.9.0.4 is just a relay agent,
>
>   It's rather more than "just a relay agent". This is the GIADDR field
>   of the DHCP message, set by the relay agent to identify the network
>   segment where the client is connected.
>
>   In other words, the relayed request means, "please give an address
>   for a client on THIS network."
>
>   Part of the DHCP server configuration ('shared-network' and 'subnet'
>   sections) models the network topology.  The server uses GIADDR to
>   identify which part of this model is the one from which an address
>   for the client must be assigned.
>
> > and what i want is to provide to my
> > LTE cust an ip in subnet 172.16.192.0/19. For that, i thought that i
> > could use class, and then allow members of this class to get an ip,
> > even if the network segment is unknown.
>
>   You can use class to select the subnet, but you need a different
>   approach.
>
>   The GIADDR value presented by the relay must belong to a known
>   subnet. This may be either the same subnet as is intended for
>   clients, or another one on the same shared network.
>
>   It seems you will need to add a subnet to the shared-network
>   definition you alrady have, so:
>
> shared-network lte-cust {
>
> option domain-name-servers 1.1.1.1,2.2.2.2;
> default-lease-time 360;
> max-lease-time 360;
>
> subnet 172.16.192.0 netmask 255.255.224.0 {
> option routers 172.16.192.254;
> option subnet-mask 255.255.224.0;
> option broadcast-address 172.16.255.255;
> }
>
> subnet 10.9.0.4 netmask 255.255.255.255 {
>     # minimal (/32) subnet for relay
>     # you may need a shorter prefix
> }
>
> pool {
> allow members of "lte";
> range 172.16.192.1 172.16.192.255;
> }
>
> }
>
>   I've just seen that Simon Hobson got to press 'Send' while I was
>   still typing.  As usual, his advice is excellent. Since there are
>   one or two differences in both detail emphasis between his advice
>   and mine, I may as well send anyway ...
>
>   Best regards,
>   Niall O'Reilly
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 20 Feb 2015 10:21:35 +0000
> From: "Niall O'Reilly" <niall.oreilly at ucd.ie>
> To: Users of ISC DHCP <dhcp-users at lists.isc.org>
> Subject: Re: Using Class to have ip address on unknown network
>         segments
> Message-ID: <m2sie0vq6o.wl-Niall.oReilly at ucd.ie>
> Content-Type: text/plain; charset=US-ASCII
>
> At Thu, 19 Feb 2015 16:39:39 -1000,
> Teva A-T wrote:
> >
> > option domain-name-servers 1.1.1.1,2.2.2.2;
>
>   I hope you're not just hi-jacking those addresses, as they
>   are assigned respectively to APNIC and Orange.
>
>   Best regards,
>   Niall O'Reilly
>
>
>
> ------------------------------
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
> End of dhcp-users Digest, Vol 76, Issue 25
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20150220/ea36e827/attachment-0001.html>


More information about the dhcp-users mailing list