>
> ------------------------------
>
> Message: 3
> Date: Wed, 15 Jul 2015 10:55:56 -0600
> From: Jason Bailey <
[hidden email]>
> To: Users of ISC DHCP <
[hidden email]>
> Subject: Re: No Option 43 in DHCP ACK
> Message-ID: <
[hidden email]>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> Calix ONTs, actually. I'm trying to get only certain ONTs to pick up
> certain option 43 configuration directives.
>
> Their documentation says:
>
> Configure the default global DHCP options at the DHCP server as follows:
> option space CALIX-ONT-SERVER;
> option CALIX-ONT-SERVER.cms-address code 1 = ip-address;
> option CALIX-ONT-SERVER.second-tftp-address code 2 = ip-address;
> option CALIX-ONT-SERVER.syslog-address code 4 = ip-address;
> option CALIX-ONT-SERVER.firmware1 code 101 = text;
> option CALIX-ONT-SERVER.firmware2 code 102 = text;
> option CALIX-ONT-SERVER.firmware3 code 103 = text;
>
> Configure specific values for DHCP options within a subnet declaration,
> as shown in the following example:
>
> # AE-ONT Management Network
> subnet xxx.xxx.xxx.x netmask xxx.xxx.xxx.x{
> vendor-option-space CALIX-ONT-SERVER;
> option CALIX-ONT-SERVER.cms-address xxx.xxx.xxx.xxx;
> option CALIX-ONT-SERVER.syslog-address xxx.xxx.xxx.xxx;
> option CALIX-ONT-SERVER.firmware1 "blah";
>
> The problem is, that doesn't work (I couldn't get to work, anyhow). If
> you use class matching, the DHCP server will send option 43 information,
> but unfortunately (as far as I see it, anyway), only if those classes
> are declared globally. The problem with that is that the matching ends
> up being all encompassing and ONTs end up getting options that they
> shouldn't. In short, it creates severe issues on the network.
>
> If I could do class matching per subnet (i.e. at the subnet level), that
> would fix my problems. I just don't see how to do that.
>
> Jason
>
>
> On 07/14/2015 01:56 AM, Maarten Carels wrote:
>>> On 13 Jul 2015, at 20:42 , Jason Bailey <
[hidden email]> wrote:
>>>
>>> Hi all,
>>>
>>> I'm trying to troubleshoot a problem with DHCP option 43. I've defined the vendor option space and declared the vendor specific options per the vendor's documentation, but I'm not getting any results.
>>>
>>> The device (DHCP client) is sending options 53 (request), 60 (vendor class ident), 61 (client identifier), 43 (vendor specific info) , 55 (parameter request list), among a few others. Option 55 includes 43 (vendor specific info) in addition to the usual items (like subnet mask, router, etc). The server is sending an ACK, but it doesn't include any of the option 43 items I've defined.
>>>
>>> In my DHCP server config, I've defined "option space XYZ" and "option XYZ.item code 1 = ip address". I've also configured defined "vendor-option-space XYZ" and "option XYZ.item 1.2.3.4" inside the subnet declaration (the entire subnet has been created entirely for the same type of devices, so there's no need to match only a certain type of devices (i.e. device class))
>>>
>>> dhcpd -t doesn't complain about any issues in my config file, and there are no issues in the log (I'm using 'log-facility local7').
>>>
>>> I'm at a loss at the moment, so any help is greatly appreciated. I'm running ISC DHCP 4.1.1 on CentOS 6.6.
>> I guess this is for the cisco wireless stuff.
>> I use this:
>> option space Cisco_LWAPP_AP;
>> option Cisco_LWAPP_AP.server-address code 241 = array of ip-address;
>>
>>
>> subnet 192.168.31.96 netmask 255.255.255.224 {
>> option routers 192.168.31.97;
>> vendor-option-space Cisco_LWAPP_AP;
>> option Cisco_LWAPP_AP.server-address 192.168.31.250;
>>
>> pool {
>> failover peer "kantoor-draadloos";
>>
>> # most fixed
>> range 192.168.31.118 192.168.31.119;
>> }
>> }
>>
>> Works for me (Internet Systems Consortium DHCP Server 4.3.1 on Debian 7.8)
>>
>> ?maarten
>>
>>
>> _______________________________________________
>> dhcp-users mailing list
>>
[hidden email]
>>
https://lists.isc.org/mailman/listinfo/dhcp-users>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
https://lists.isc.org/pipermail/dhcp-users/attachments/20150715/e6764f34/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 15 Jul 2015 12:23:55 -0500
> From: Chris Buechler <
[hidden email]>
> To: Users of ISC DHCP <
[hidden email]>
> Subject: Re: PD broken in v4.3.2? prefix6 start prefix is outside the
> subnet
> Message-ID:
> <
[hidden email]>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Jul 15, 2015 at 3:59 AM, Christian Kratzer <
[hidden email]> wrote:
>>
>> a couple of quick points on this:
>>
>> 1. this would require one to enlargeng the access network to emcompass
>> the whole pool of prefixes one wishes to delegate. This would definetely
>> be considered a broken design.
>>
>
> Yes, especially considering there's no reason the PD subnet needs to
> be even close to the interface's subnet. As things stand now after
> that change, in some circumstances you'd need a subnet6 2000::/3 or
> close to it for PD to work.
>
>
>> 2. Just having the network large enough would still only route towards
>> the net. This would not help with getting the ultimate next hop for the
>> assigned prefix resolved.
>>
>> 3. ipv6 relay agents on routers that support PD sniff the traffic and
>> transparently add the route to the delegated prefix to the correct next hop.
>>
>> Such a change would definetely be broken and would have to be backed out.
>>
>
> Yes, agree.
>
>
> On Wed, Jul 15, 2015 at 12:17 AM, Shawn Routhier <
[hidden email]> wrote:
>>
>> However I do think you are confused about the configuration file
>> showing class support from the KB article. I have tried the three
>> configuration files in that kb article and all of them seem to work
>> correctly for me with the prefixes being within the subnet.
>>
>
> Correct, the issue is where they're outside the subnet, sorry I wasn't
> clear on that part.
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 15 Jul 2015 14:28:40 -0300
> From: Leandro <
[hidden email]>
> To: Users of ISC DHCP <
[hidden email]>
> Subject: dhcpd-pools / other leses management tool
> Message-ID: <
[hidden email]>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Hi dhcp users list.
> Im looking for some tool to list the provided leases and its status.
> So far I can list range usage per defined network using dhcpd-tools as
> follows:
>
> [root@centos-dns1 etc]# dhcpd-pools -L11 -c /etc/dhcp/dhcpd.conf -l
> /var/lib/dhcpd/dhcpd.leases
> Ranges:
> shared net name first ip last ip max cur
> percent touch t+c t+c perc bu bu perc
> Relay1 192.168.88.2 - 192.168.88.126 125 0
> 0.000 40 40 32.000 50 40.000
> Relay2 192.168.88.130 - 192.168.88.254 125 0
> 0.000 1 1 0.800 0 0.000
> Relay1 192.168.89.2 - 192.168.89.126 125 0
> 0.000 66 66 52.800 59 47.200
> Relay2 192.168.89.130 - 192.168.89.254 125 0
> 0.000 1 1 0.800 2 1.600
>
> This is very usefull , but I wonder if is there other way to list all
> leases and its status, for example pfsense provides the following list:
> P address <
https://10.0.0.251/status_dhcp_leases.php#> MAC address
> <
https://10.0.0.251/status_dhcp_leases.php#> Hostname
> <
https://10.0.0.251/status_dhcp_leases.php#> Start
> <
https://10.0.0.251/status_dhcp_leases.php#> End
> <
https://10.0.0.251/status_dhcp_leases.php#> Online
> <
https://10.0.0.251/status_dhcp_leases.php#> Lease Type
> <
https://10.0.0.251/status_dhcp_leases.php#>
> 192.168.88.130 08:00:27:95:d9:62
> <
https://10.0.0.251/services_wol.php?if=opt2&mac=08:00:27:95:d9:62>
> 2015/07/15 14:21:06 2015/07/15 16:21:06 offline active
>
>
> Thanks
> Leandro.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
https://lists.isc.org/pipermail/dhcp-users/attachments/20150715/42ab7406/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> dhcp-users mailing list
>
[hidden email]
>
https://lists.isc.org/mailman/listinfo/dhcp-users>
> End of dhcp-users Digest, Vol 81, Issue 15
> ******************************************
Locked
signature.asc (859 bytes)