Pool selection based on Giaddr of different subnet
Dario Aguilar
daguilar at arnet.net.ar
Tue Mar 17 16:41:28 UTC 2009
Hi, Glenn, our architecture is basically for the purpose of allocating
address to Wimax client, it´s a new service for us. WAC has a public ip
address (relay agent) and Wimax CPE´s need a public IP from a different
subnet than the WAC. I´ve found this on RFC 2131 that says that is not
necessary that the GIAddr belongs to the same subnet as the client:
http://www.ietf.org/rfc/rfc2131.txt
4.3.1 DHCPDISCOVER message
When a server receives a DHCPDISCOVER message from a client, the
server chooses a network address for the requesting client. If no
address is available, the server may choose to report the problem to
the system administrator. If an address is available, the new address
SHOULD be chosen as follows:
.........
.....
o A new address allocated from the server's pool of available
addresses; the address is selected based on the subnet from which
the message was received (if 'giaddr' is 0) or on the address of
the relay agent that forwarded the message ('giaddr' when not 0).
--------------
Up to now I´m agree with you....
-------------
As described in section 4.2, a server MAY, for administrative
reasons, assign an address other than the one requested, or may
refuse to allocate an address to a particular client even though free
addresses are available.
---------------
But here it´s saying another thing...
---------------
Note that, in some network architectures (e.g., internets with more
than one IP subnet assigned to a physical network segment), it may be
the case that the DHCP client should be assigned an address from a
different subnet than the address recorded in 'giaddr'. Thus, DHCP
does not require that the client be assigned as address from the
subnet in 'giaddr'. A server is free to choose some other subnet,
and it is beyond the scope of the DHCP specification to describe ways
in which the assigned IP address might be chosen.
.....
Thanks,
Dario Aguilar
-----Mensaje original-----
De: dhcp-users-bounces at lists.isc.org
[mailto:dhcp-users-bounces at lists.isc.org] En nombre de Glenn Satchell
Enviado el: Martes, 17 de Marzo de 2009 11:37 a.m.
Para: dhcp-users at lists.isc.org
Asunto: RE: Pool selection based on Giaddr of different subnet
Hi Dario
I'm not sure I understand how your network is set up. If you can
describe your network layout then we may be able to offer a solution.
Can you describe a valid network configuration where the relay's giaddr
(address of the interface where the request came in) is in a different
subnet to that of the client and not be a shared network?
This is the fundamental design of not only the ISC dhcpd, but of the RFC
that defines how dhcp whould work.
When a client sends out a broadcast to find a dhcp server or relay,
that packet can only stay within the defined subnet. There is no valid
way for it to be routed to a different subnet and for your relay on
that other subnet to receive it.
regards,
-glenn
>From: "Dario Aguilar" <daguilar at arnet.net.ar>
>To: "'Users of ISC DHCP'" <dhcp-users at lists.isc.org>
>Subject: RE: Pool selection based on Giaddr of different subnet
>Date: Tue, 17 Mar 2009 10:36:37 -0300
>
>Dario Aguilar wrote:
>
>>Hi there, I´m trying to configure a pool
>>selection based on Giaddr but the problem is
>>that Relay Agent IP (Giaddr) doesn't belongs to
>>same subnet as the client pool so I guess I need
>>to define a class that matches this criteria
>>(maybe of sure that I difined in a wrong way).
>>This is not working because it´s saying that
>>network segment is unknown.
>
>>>OK, two ways to deal with this :
>
>>>1) Fix the relay agent !
>
>Why you assume that the relay agent is broken, wrong or something?. Relay
>agent should be a DSLAM, WAC or simply a router that has an address on
>different subnet than the clients. I think that if the subnets are
correctly
>routed this should not me a problem for the relay agent or the clients.
>(Private IP´s are just examples, we are using public´s IP addresses in
>fact).
>
>>>2) Assuming the GIAddr of the relay agent is
>>>unique to the clients subnet, then simply put an
>>>extra subnet in a shared-network delcaration like
>>>this :
>
>>>shared-network broken_relay_agent {
>>> subnet 192.168.0.0 netmask 255.255.255.0 { }
>>>
>>> subnet 172.17.2.0 netmask 255.255.255.0 {
>>> range ...
>>> ...
>>> }
>>>}
>
>>>What this does is tell the DHCP server that the
>>>two subnets are on the same wire, and so
>>>addresses in each subnet are interchangeable as
>>>far as allocating leases to clients in concerned.
>>>The server will match the GIAddr to one subnet,
>>>find no available leases, but see that leases are
>>>available in the other subnet and allocate from
>>>there.
>
>>>This will NOT work if the same relay agent serves
>>>other subnets using the same (wrong) GIAddr.
>
>>>Without the shared-network, you will NOT get the
>>>server to allocate a lease to any client in the
>>>subnet as the server believes that the client is
>>>on a different network.
>
>>class "WAC" {
>> match if (binary-to-ascii(10,8, ".", packet(24,4)) =
>"192.168.0.1");
>>}
>
>>>You don't need the binary to ascii stuff, you can
>>>just use hex something like this :
>>>match if (packet(24,4)) = c0:a8:00:01);
>
>As you recommended, I could resolve this by putting just the relay agent
>host into the same shared-network as the client pool, but I don´t know if
>this is the only or best solution for this because now I need to add a new
>shared-network for each new relay agent. Is there any possibility to
>allocate leases using classes as I was trying to do it with "match if
>(packet(24,4)) = GiAddr);" and then "allow members of" on the subnet ?.
>
>Actual configuration:
>
>shared-network broken_relay_agent {
> subnet 192.168.0.1 netmask 255.255.255.255 { }
> subnet 172.17.2.0 netmask 255.255.255.0 {
> range ...
> ...
> }
>}
>Thanks
>
>Dario Aguilar.
>
>
>--
>Simon Hobson
>
_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.0.237 / Virus Database: 270.11.15/2004 - Release Date: 03/17/09
07:23:00
More information about the dhcp-users
mailing list