Multiple subnets with classes - 'option routers' issue

[Glenn Satchell]

Please post your dhcpd.conf so we can see what is wrong. The wrong
router bug was fixed many years ago, I know as I had that problem at
the time.

regards,
-glenn

>Subject: Re: Multiple subnets with classes - 'option routers' issue
>From: Gundares <vanchik at yandex.ru>
>To: dhcp-users at isc.org
>Date: Mon, 09 Jun 2008 19:48:36 +0400
>
>I'm very sorry, 
>
>but it is still not working.
>
>now dhcpd is answering with the _last_ (max(IP)) router address -
>172.17.192.1
>
>I think the problem is similar to the 3.0.1 version (see changelog named
>'since 3.0.1rc9' "A fix for shared-networks that sometimes give clients
>options for the wrong subnets (in particular, 'option routers') was
>applied, thanks to Ted Lemon for the patch.") - I've dealt with it while
>was using standard dhcpd.RPM from RHEL4. In addition, all the MTAs are
>reserved with host{} declaration. It takes proper IP-address, but
>netmask and router are wrong. All other options (name-, log- and time-
>servers, time-offset and domainname) are the same across different
>subnets.
>
>÷ ÐÎ, 09/06/2008 × 11:36 +0400, Gundares ÐÉÛÅÔ:
>> Hi, Glenn and dhcp-users,
>> 
>> ÷ ×Ó, 08/06/2008 × 23:02 +1000, Glenn Satchell ÐÉÛÅÔ:
>> > Hi Ivan
>> > 
>> > Your classes are defined within the 172.16.0.0 subnet definition, so the 
class 
>> > membership inherits from the subnet and thus gets that default router.
>> > 
>> > The simplest solution is to move the class definitions into the global 
scope 
>> > andonly have options router and the pool definitions within the subnet.
>> > 
>> > Within pools mixing allow and deny is not recommendeded due to the way 
these are 
>> > parsed. Including an allow implicitly denies everything else, likewise, 
denying 
>> > a class implicitly allows everything else.
>> 
>> thank you, now it is working, but one moment is still unclear for me:
>> what if I need set some options for my cable modems inside subnet
>> declaration, but my classes are defined globally now? How can I
>> determine is the dhcp-client cable modem (or MTA) or not? I think, class
>> matching based on giaddr field of packet will be very useful in this
>> case, won't it? Is there another way to define (unique) classes inside
>> different subnets for the same cable modems?
>> 
>
>