Static Addressing Within a DHCP Structure | docsis.org

You are here

Static Addressing Within a DHCP Structure

### Was "Is Mac Cloning Required" ###

### A summary by kwesibrunee snipped from the original thread ###

Tue, 03/30/2010 - 12:31 — kwesibrunee

I think I am following you here is what I think will work for you.

First thing you need is a version of DHCPd that is option 82 compliant we use dhcpd-4.1.0-5 which we had to compile ourselves, but I am not sure exactly what version they added option 82 stuff in. Any newer version of dhcpd3.x or dhcp4.x should work but your mileage may vary.

Option 82 is more commonly know as DHCP Relay information Option, and quite likely will need to be turned "on" in your CMTS in Cisco CMTSes the command is

ip dhcp relay information option

What it does is forward the relay information along with the standard dhcp options, in a CMTS world this means the Modem's Mac address and on Cisco CMTSes the Interface the modem is connected to.

How can this help you in dhcp terms? You can create a class for the modem in question like so

class "Modem0001Client" {
match if (substring(option agent.remote-id,0,15) = "0:4:a0:eb:51:d8") and ((substring(option vendor-class-identifier,0,6) != "docsis");
spawn with option agent.remote-id;
lease limit 1;
}

What this does it classify incoming requests whose remote-id = "0:4:a0:eb:51:d8" (dhcpd uses this weird shorthand for mac addresses this is the mac address 0004a0eb51d8) as a Request from Modem0001Client, the spawn with command tells it to group all requests from behind this modem together and the lease-limit line prevents the dhcp server from handing more than 1 leases to clients behind that modem. The other substring command tells it to ignore modems and only match clients, because modem dhcp requests also have option 82 info on them with their own mac as the remote-id, at least on cisco CMTSes.

Ok, the first half of the battle is completed you have classified the clients your interested in now you have to configure your subnets to take advantage of it

This is the "one" DHCPd server version

class "Modems" {
match if (substring(option vendor-class-identifier,0,6) = "docsis"
spawn with hardware;
}
class "Modem0001Client" {
match if (substring(option agent.remote-id,0,15) = "0:4:a0:eb:51:d8") and ((substring(option vendor-class-identifier,0,6) != "docsis");
spawn with option agent.remote-id;
lease limit 1;
}
class "Modem0002Client" {
match if (substring(option agent.remote-id,0,15) = "0:3:a1:e3:51:d5") and ((substring(option vendor-class-identifier,0,6) != "docsis");
spawn with option agent.remote-id;
lease limit 1;
}

shared-network CableNetwork {
#Subnet for modems
subnet 10.0.0.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option routers 10.0.0.1;
#Rest of required modem options
pool {
range 10.0.0.2 10.0.0.254;
allow members of "Modems";
}
}
#Subnet for clients
subnet 192.168.0.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option routers 192.168.0.1;
option domain-name-servers 192.168.1.1;
#Pool for Modem0001Client
pool {
range 192.168.0.2 192.168.0.2;
allow members of "Modem0001Client";
}
#Pool for Modem0002Client
pool {
range 192.168.0.3 192.168.0.3;
allow members of "Modem0002Client";
}
}
}

You would repeat the class "ModemxxxxClient" and pool commands for each modem you need, a huge pain in the butt, but it works.

####################################################################################

A year late, but I'm finally giving this a shot as follows and would appreciate any comments or suggestions to streamline or tidy up the approach.

Also, what effect could this approach have on client devices which are already set up with the designated/assigned address as fixed in their TCP/IP config and not yet switched over to a DHCP setting? I have approximately 60 NAT boxes needing this conversion and I'd like to have everything pre-set in dhcpd.conf before sending techs out to re-config and re-boot them all.

TIA for any input as usual. BTW, I haven't tried this in the real world yet, but it didn't break my server either. Think it'll work?

Poge

#####################################################################

#CM Class
class "CM"{
match if (substring(option vendor-class-identifier,0,6)="docsis");
spawn with hardware;
}

#MTA Class
class "MTA"{
match if (substring(option vendor-class-identifier,0,4)="pktc");
spawn with hardware;
}

#CPE Class
class "CPE"{
match if ((substring(option vendor-class-identifier,0,6)!="docsis")
and(substring(option vendor-class-identifier,0,4)!="pktc"));
spawn with hardware;
}

#CM Clients Class Example for CM 00:04:bd:e2:23:6e

class "CM 038 Client"{
match if (substring(option agent.remote-id,0,15)="0:4:bd:e2:23:6e")
and((substring(option vendor-class-identifier,0,6)!="docsis"));
spawn with option agent.remote-id;
lease limit 1;
}

#####################################################################

shared-network OberlinNetwork {
# uBR Bundle 1 / Cable Modems
subnet 10.1.0.0 netmask 255.255.0.0 {
option routers 10.1.0.1;
authoritative;
ignore client-updates;
deny unknown-clients;
option time-offset -18000;
option ntp-servers 128.4.40.12;
option time-servers 10.10.1.1;
option log-servers 10.10.1.3;
next-server 10.10.1.3;
option tftp-server-name "10.10.1.3";
pool{
range 10.1.1.4 10.1.252.254;
allow members of "CM";

}
}
#Client Network CPE's
subnet 208.66.214.0 netmask 255.255.255.0 {
option routers 208.66.214.1;
authoritative;
ignore client-updates;
option domain-name "oberlin.net";
option domain-name-servers 208.66.208.2, 208.66.208.3;
option log-servers 10.10.1.3;
next-server 10.10.1.3;
pool{
range 208.66.214.50 208.66.214.254;
allow members of "CPE";
deny members of "CM";
}
}

#CM Fixed Client Network
subnet 132.162.193.0 netmask 255.255.255.0 {
option routers 132.162.193.1;
authoritative;
ignore client-updates;
option domain-name "oberlin.edu";
option domain-name-servers 132.162.1.31, 132.162.1.32;
option log-servers 10.10.1.3;
next-server 10.10.1.3;

#Fixed Clients

pool{
range 132.162.193.50 132.162.193.50;
deny members of "CPE";
deny members of "CM";
allow members of "CM 038 Client";
}
}

}
subnet 10.10.0.0 netmask 255.255.0.0 {
}

#######################################################

I predict you have the following two problems

Lease Times

you will likely want them to be very short i.e. <5 mins, because if you change clients behind the modems you want the lease to be free when the new client tries to dhcp or else it will not be given that ip because in dhcpd's mind it is given to another client. dhcpd keeps the ip in a non-free state for a period of time after the lease has expired, I believe it is half the lease time. So in this case your new client would need to wait ~10 mins before trying to hook up or he would not get the right IP

Preventing the clients from getting a different ip than you want
The other problem you will have especially doing it with one dhcp server is preventing the new client from getting an IP in your general pool,

you could do this with

deny members of "CM 038 Client";
deny members of "CM 039 Client";
deny members of "CM 040 Client";

in your general pool (208.66.214.0) but you would have to have an entry for each class you wish to deny. Goes back to the "pain in the Ass" part of it.

Thanks for the observations.

But won't such short lease times create excessive renewal activity? And if so, is there an easy way to mitigate it? Could you provide an example?

As for these particular clients getting an address from the wrong pool, that's sorta what led to this approach vs. just setting up static configs on the NAT boxes. Students were pulling our NAT's and replacing them with their own wireless boxes in DHCP mode, thereby using our internet bandwidth instead of the college's. I discovered this through a series of copyright infringement notices that weren't matching up with what should have been the hardware/address relationship.

Thanks again.

Poge

It didn't work.

Still pulled an address from the other pool like any other CPE. Haven't had time to investigate. Suggestions?

Poge

first though you may need to sprinkle your dhcp config with log lines to determine current issue

i.e.

log (info, concat("this device hit dhcp : ", option vendor-class-identifier, " its relay agent was ", option agent.remote-id ));

is it absolutely essential that each client pulls the same IP address regardless of what client connects? Or is it ok if it comes from a pool of IPs.

i.e.

Normal users get ip from pool 192.168.0.0/24
special users get ip from pool 192.168.1.0/24

if that is the case there is a easy and more reliable way to do such things with two dhcp servers and some creative CMTS config (assuming cisco)

First dhcp server modems

class "specialmodems"{
match pick-first-value (option dhcp-client-identifier, hardware);
}
#mac of a special modem
subclass "specialmodems" 1:0:0:0:0:0:1;

shared-network Modems {
# subnet for regular modems
subnet 10.0.0.0 netmask 255.255.255.0 {
pool {
deny members of "specialmodems";
range 10.0.0.2 10.0.0.254;
}
}
subnet 10.1.0.0 netmask 255.255.255.0 {
pool {
allow members of "specialmodems";
range 10.1.0.2 10.1.0.254;
}
}
}

#you could also do this even easier with fixed-addresses for the special modems in the same separate subnet but the subclass should work more reliably

on the client dhcp server

shared-network NormalClients {
subnet 10.0.0.0 netmask 255.255.255.0 {
# intentionally empty
}
subnet 192.168.0.0 netmask 255.255.255.0 {
#client pool and options here
}
}

shared-network SpecialClients {
subnet 10.1.0.0 netmask 255.255.255.0 {
# intentionally left blank
}
subnet 192.168.1.0 netmask 255.255.255.0 {
#special client pool and options here
}
}

Clients behind modems in the 10.0.0.0/24 network will get 192.168.0.0/24 ips
Clients behind modems in the 10.1.0.0/24 network will get 192.168.1.0/24 ips

What makes this work is the following setup on the CMTS

interface Bundle1
no ip address
!
interface Bundle1.1
ip address 192.168.0.1 255.255.255.0 secondary
ip address 10.0.0.1 255.255.255.0
cable helper-address [modem dhcp server ip] cable-modem
cable helper-address [client dhcp server ip] host
!
interface Bundle1.2
ip address 192.168.1.1 255.255.255.0 secondary
ip address 10.1.0.1 255.255.255.0
cable helper-address [modem dhcp server ip] cable-modem
cable helper-address [client dhcp server ip] host

When the modem requests an IP the request comes from 10.0.0.1 or 10.1.0.1 (usually 10.0.0.1 though in my experience, though it does not matter)

If it is a normal modem it gets a 10.0.0.x ip
if it is a special modem it gets a 10.1.0.x ip

be sure to set the appropriate gateways on each subnet

now when the client dhcps if it is behind a normal modem the request will come from 10.0.0.1
which only matches the normal clients shared-network

if it is behind a special modem the request will come from 10.1.0.1 which only matches the special clients shared-network

I know this works with cisco cmtses and likely works with others as well.

This works fine!

Thanks kwesibrunee.