This is a problem similar to many I have seen, but I'm pulling my hair out because none of the solutions seem to quite work.

Situation -- we recently got our office phones "upgraded" to a VOIP "solution" (clearly a euphemism for "problem" in this case"). The VOIP phones (Mitel) need to access a DHCP server periodically. Because we needed to share the building networking between the VOIP phones and the computers, we have effectively two subnets (172.16 and 10.0) superimposed on the same wiring. But the VOIP phones need to access one DHCP server (10.0), and the computers need another (172.16).

What happens is that the dhcpd on the computer side (Linux) is MUCH faster than the one on the phone side, so the phones always get their answer from the wrong server, unless that server is switched off. None of the solutions I've tried to get it to ignore the phone have worked.

1. host mitel1 {hardware ethernet 08:00:0f:xx:yy:zz; deny booting; }

As far as I can tell, this isn't doing anything. TCPDUMP still shows the incoming broadcast DHCP request, and a reply from both DHCP servers. Also, it's not ideal because I don't have a way to find all the phone MAC addresses a-priori. I might be able to make some dhcp-eval based class solution, but I need the basic blocking to work first.

2. iptables blocking based on MAC address

From what I understand, this approach is known to not work, because dhcpd bypasses iptables and reads the raw packets.

Anyone encountered anything like this before? I thought it would be simple to just block the phones based on MAC, since they're all from one manufacturer!

Thanks,
Greg

Two things spring to mind:

• Make use of VLAN tags, I'm sure your phones support them.
• Assign static IPs to the individual phones.

And the third (much more involved!) option.

• Split the wiring and set your phones up on different switches to your PCs.

Okay, embarrassingly after posting this I managed to find an apparently working solution with another half hour of searching. Let me post it here for others who may need this! This relies on the fact that the OUI (first half of the MAC) is assigned to a manufacturer. In this case, Mitel's OUI is 08:00:0f, so all the phones are going to show up as this. Practically speaking, I wasn't able to test the MAC matching portion of this because the phones power back up requesting their previous IP address, and unless the Linux DHCP server gets in the way, the other server accepts this and it works. Presumably there are cases such as first-time boot where this would be more critical, but I can't readily recreate that situation.

shared-network ournet {
subnet 10.0.0.0 netmask 255.0.0.0 {
option subnet-mask 255.0.0.0;
option broadcast-address 10.255.255.255;
range 10.0.0.1 10.0.0.100;
deny booting;
}

subnet 172.16.0.0 netmask 255.255.0.0 {
option subnet-mask 255.255.0.0;
option broadcast-address 172.16.255.255;
option routers 172.16.x.y;
option domain-name-servers x,y,z;

class "mitel-phones" {
match if binary-to-ascii (16, 8, ":", substring (hardware, 1, 3)) = "8:0:f";
ignore booting;
}

# remainder of host declarations for the "real" internal network
}
}

Additional useful hints:

* The "shared-network" portion was the critical part that was missing before. DHCP needs to know that the two logical nets are superimposed on a single physical net; otherwise it assumes something bad is happening.

* The following will log the first 3 bytes of the MAC (OUI) so you can tell who is making DHCP requests. I put this out in the main body of the DHCP configuration and it worked nicely to verify that I was seeing the right address pattern.

log(info, binary-to-ascii (16, 8, ":", substring (hardware, 1, 3)));