migrate from remotely located to central servers

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

migrate from remotely located to central servers

Jason Brooks
Hello,

I am having trouble relocating and upgrading a number of dhcp servers.  I am upgrading from solaris running dhcpd 3.0.4 to centos 7's dhcp 4.2.5-77.  

The problem: when I test the config on the new dhcp servers, I get the following error: "No free leases".

As I am still testing, I have not copied the leases thus it is not clear why there would be no free leases. 

As I have no lab equipment to test against,  I am generating similar queries using the dhtest tool.  I started with a packet capture on the live dhcp servers and constructed a dhcp discovery packet based on it.  I have also started small, with the smallest configuration possible that should still work. 

The queries originate from DSL customer premises equipment (CPE), and are forwarded by a dsl shelf manager.  The relevant fields in the forwarded queries are as follows:
giaddr: <management ip of dsl shelf>  (Please note this is NOT the ip address facing the CPE)
chaddr: <mac of CPE>
option 82.1: circuit id
option 82.2: remote id
option 60: vendor class identifier (only on boot and management classes)

The current live system is running 8 pairs of dhcp servers in different regions.  They have been successfully running for more than 8 years.  At last count there are about 440,000 active leases.  

I am attempting to build a pair of centrally located servers.  I am not trying to do HA yet.

I am including a sanitized dhcpd.conf file for you to look at.

Thank you all for your time!

--jason

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

sanitized-dhcpd.conf (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: migrate from remotely located to central servers

Bill Shirley-2

So, the DISCOVER is not matching any of your classes.  Define another pool to issue
leases from that doesn't match any class:
     pool {
        deny members of "RegionX-RGMGMT-CPE-MODELx";
        deny members of "RegionX-BOOT-CPE-MODELx";
        deny members of "RegionX-INET";

        deny dynamic bootp clients;
        authoritative;
        range 192.168.xxx.2 192.168.xxx.15;
    }

This should issue a lease and trigger your 'on commit' log statement.

Bill

On 7/29/2020 12:35 PM, Jason Brooks wrote:
Hello,

I am having trouble relocating and upgrading a number of dhcp servers.  I am upgrading from solaris running dhcpd 3.0.4 to centos 7's dhcp 4.2.5-77.  

The problem: when I test the config on the new dhcp servers, I get the following error: "No free leases".

As I am still testing, I have not copied the leases thus it is not clear why there would be no free leases. 

As I have no lab equipment to test against,  I am generating similar queries using the dhtest tool.  I started with a packet capture on the live dhcp servers and constructed a dhcp discovery packet based on it.  I have also started small, with the smallest configuration possible that should still work. 

The queries originate from DSL customer premises equipment (CPE), and are forwarded by a dsl shelf manager.  The relevant fields in the forwarded queries are as follows:
giaddr: <management ip of dsl shelf>  (Please note this is NOT the ip address facing the CPE)
chaddr: <mac of CPE>
option 82.1: circuit id
option 82.2: remote id
option 60: vendor class identifier (only on boot and management classes)

The current live system is running 8 pairs of dhcp servers in different regions.  They have been successfully running for more than 8 years.  At last count there are about 440,000 active leases.  

I am attempting to build a pair of centrally located servers.  I am not trying to do HA yet.

I am including a sanitized dhcpd.conf file for you to look at.

Thank you all for your time!

--jason

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: migrate from remotely located to central servers

Jason Brooks
Hello Bill, 

At first I didn't understand, but now I do. Once I defined the pool denying class members, I was able to get ip addresses in the 192.168.188.range. Thanks!

I began to run "dhcpd -d" and playing with the log output to see if my substring statements were even making sense. 

So with the circuit id substring statements, I wasn't comparing correctly.  It's not clear why 3.0.4 worked this way.  I needed the two bytes on the far right side of the circuit id...thus

the lines: 
     "and ( substring (option agent.circuit-id,2,2)="\x01\x2C" )"
became:
     "and ( suffix ( option agent.circuit-id, 4) ="012C" )"

note the use of suffix rather than substring and the lack of "\x" inside the double quotes.

So my next issue here is in the RegionX-BOOT-CPE-MODELx class declaration, tftp-server-name is not being returned.  Whereas the boot filename is.  Why not? Based on what I found 'tftp-server-name" should correspond to dhcp option 66: defined in rfc2132.

I have noticed that it's hard to figure out which isc dhcpd options map to those defined in the rfcs.  I found THIS table, which helps.  Is there a cross-reference like this in the isc dhcpd docs somewhere?

Enclosed is my updated, sanitized dhcpd.conf file with your suggested alterations and a few more of my own.

Thank you thus far for your time!

--jason

On Wed, Jul 29, 2020 at 11:51 AM Bill Shirley <[hidden email]> wrote:

So, the DISCOVER is not matching any of your classes.  Define another pool to issue
leases from that doesn't match any class:
     pool {
        deny members of "RegionX-RGMGMT-CPE-MODELx";
        deny members of "RegionX-BOOT-CPE-MODELx";
        deny members of "RegionX-INET";

        deny dynamic bootp clients;
        authoritative;
        range 192.168.xxx.2 192.168.xxx.15;
    }

This should issue a lease and trigger your 'on commit' log statement.

Bill




_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

sanitized-dhcpd.conf (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: migrate from remotely located to central servers

Simon Hobson
Jason Brooks <[hidden email]> wrote:

> So my next issue here is in the RegionX-BOOT-CPE-MODELx class declaration, tftp-server-name is not being returned.  Whereas the boot filename is.  Why not?

Have you checked the option request list sent by the client ? By default, the server will only return options the client asks for.

Simon

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: migrate from remotely located to central servers

Bill Shirley-2
In reply to this post by Jason Brooks

ISC documentation: https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcp-options

Looks like your domain-name-servers option is incorrect:
option domain-name-servers 8.8.8.8, 8.8.4.4;

Add this to your log statement to see the options requested:
    "  ReqOpt:", pick-first-value(binary-to-ascii(10, 8, ",", option dhcp-parameter-request-list), "(none)"),
Make sure the client is requesting option 66.  BTW, if the dhcpd encounters a null
in the log text, it will truncate the rest of the line.  That's why I use 'pick-first-value' a lot.

If it's not requesting option 66, you might try forcing the option.  I've never used this:
if exists dhcp-parameter-request-list {
# Always send the local-pac-server (252) option (specified in hexadecimal, ie: 252 = 0xfc)
    option dhcp-parameter-request-list = concat(option dhcp-parameter-request-list, fc);
}

I have used this to replace the entire requested option list:
option dhcp-parameter-request-list = 01: 03: 06: 0c: 0f: 1c: 2a;

Bill

On 7/29/2020 7:45 PM, Jason Brooks wrote:
Hello Bill, 

At first I didn't understand, but now I do. Once I defined the pool denying class members, I was able to get ip addresses in the 192.168.188.range. Thanks!

I began to run "dhcpd -d" and playing with the log output to see if my substring statements were even making sense. 

So with the circuit id substring statements, I wasn't comparing correctly.  It's not clear why 3.0.4 worked this way.  I needed the two bytes on the far right side of the circuit id...thus

the lines: 
     "and ( substring (option agent.circuit-id,2,2)="\x01\x2C" )"
became:
     "and ( suffix ( option agent.circuit-id, 4) ="012C" )"

note the use of suffix rather than substring and the lack of "\x" inside the double quotes.

So my next issue here is in the RegionX-BOOT-CPE-MODELx class declaration, tftp-server-name is not being returned.  Whereas the boot filename is.  Why not? Based on what I found 'tftp-server-name" should correspond to dhcp option 66: defined in rfc2132.

I have noticed that it's hard to figure out which isc dhcpd options map to those defined in the rfcs.  I found THIS table, which helps.  Is there a cross-reference like this in the isc dhcpd docs somewhere?

Enclosed is my updated, sanitized dhcpd.conf file with your suggested alterations and a few more of my own.

Thank you thus far for your time!

--jason

On Wed, Jul 29, 2020 at 11:51 AM Bill Shirley <[hidden email]> wrote:

So, the DISCOVER is not matching any of your classes.  Define another pool to issue
leases from that doesn't match any class:
     pool {
        deny members of "RegionX-RGMGMT-CPE-MODELx";
        deny members of "RegionX-BOOT-CPE-MODELx";
        deny members of "RegionX-INET";

        deny dynamic bootp clients;
        authoritative;
        range 192.168.xxx.2 192.168.xxx.15;
    }

This should issue a lease and trigger your 'on commit' log statement.

Bill




_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: migrate from remotely located to central servers

Jason Brooks
In reply to this post by Simon Hobson
Hello Simon,

Funny you should ask.  As I am constructing a test query, I didn't include it in the request list.  I didn't know that about dhcpd.  

I have been basing my test queries on captured queries at my live servers, but there haven't been any boot requests coming in, so there you have it...

Thanks!

--jason

On Thu, Jul 30, 2020 at 12:31 AM Simon Hobson <[hidden email]> wrote:
Jason Brooks <[hidden email]> wrote:

> So my next issue here is in the RegionX-BOOT-CPE-MODELx class declaration, tftp-server-name is not being returned.  Whereas the boot filename is.  Why not?

Have you checked the option request list sent by the client ? By default, the server will only return options the client asks for.

Simon

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: migrate from remotely located to central servers

Jason Brooks
In reply to this post by Bill Shirley-2
Hi Bill,

I will sit down and re-read the man pages: thank you for the reminder.

good to know about the dns servers.

and thanks or the log statement suggestions.

A note from Simon Hobson had me understand that the client must ask for the information, so I am going to re-construct my test query to see if the tftp information comes back.  But thanks for the suggestions to force options.

--jason

On Thu, Jul 30, 2020 at 6:51 AM Bill Shirley <[hidden email]> wrote:

ISC documentation: https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcp-options

Looks like your domain-name-servers option is incorrect:
option domain-name-servers 8.8.8.8, 8.8.4.4;

Add this to your log statement to see the options requested:
    "  ReqOpt:", pick-first-value(binary-to-ascii(10, 8, ",", option dhcp-parameter-request-list), "(none)"),
Make sure the client is requesting option 66.  BTW, if the dhcpd encounters a null
in the log text, it will truncate the rest of the line.  That's why I use 'pick-first-value' a lot.

If it's not requesting option 66, you might try forcing the option.  I've never used this:
if exists dhcp-parameter-request-list {
# Always send the local-pac-server (252) option (specified in hexadecimal, ie: 252 = 0xfc)
    option dhcp-parameter-request-list = concat(option dhcp-parameter-request-list, fc);
}

I have used this to replace the entire requested option list:
option dhcp-parameter-request-list = 01: 03: 06: 0c: 0f: 1c: 2a;

Bill

On 7/29/2020 7:45 PM, Jason Brooks wrote:
Hello Bill, 

At first I didn't understand, but now I do. Once I defined the pool denying class members, I was able to get ip addresses in the 192.168.188.range. Thanks!

I began to run "dhcpd -d" and playing with the log output to see if my substring statements were even making sense. 

So with the circuit id substring statements, I wasn't comparing correctly.  It's not clear why 3.0.4 worked this way.  I needed the two bytes on the far right side of the circuit id...thus

the lines: 
     "and ( substring (option agent.circuit-id,2,2)="\x01\x2C" )"
became:
     "and ( suffix ( option agent.circuit-id, 4) ="012C" )"

note the use of suffix rather than substring and the lack of "\x" inside the double quotes.

So my next issue here is in the RegionX-BOOT-CPE-MODELx class declaration, tftp-server-name is not being returned.  Whereas the boot filename is.  Why not? Based on what I found 'tftp-server-name" should correspond to dhcp option 66: defined in rfc2132.

I have noticed that it's hard to figure out which isc dhcpd options map to those defined in the rfcs.  I found THIS table, which helps.  Is there a cross-reference like this in the isc dhcpd docs somewhere?

Enclosed is my updated, sanitized dhcpd.conf file with your suggested alterations and a few more of my own.

Thank you thus far for your time!

--jason

On Wed, Jul 29, 2020 at 11:51 AM Bill Shirley <[hidden email]> wrote:

So, the DISCOVER is not matching any of your classes.  Define another pool to issue
leases from that doesn't match any class:
     pool {
        deny members of "RegionX-RGMGMT-CPE-MODELx";
        deny members of "RegionX-BOOT-CPE-MODELx";
        deny members of "RegionX-INET";

        deny dynamic bootp clients;
        authoritative;
        range 192.168.xxx.2 192.168.xxx.15;
    }

This should issue a lease and trigger your 'on commit' log statement.

Bill




_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users