DHCP Best Practice

We have a Canopy network that consists of about 20 2.4 APs and 2 or 3 900 APs. Some are SW scheduled, some are HW scheduled. They are all on at least version 7.3.6 or higher.

Up to this point, we have statically assigned IP addresses to customers. If the customer has a router, we assign the public IP to the router. If they do not, we assign the public IP to the SM and set it up to NAT. I would say that half of our SMs are set up to NAT.

Obviously, it has become very cumbersum to continue assigning these IPs statically and maintaining up to date records. We would like to deploy a DHCP server and convert everything over to DHCP. We have played with this in the past and had poor results with people dropping offline intermittently after a short time of receiving their lease.

I am just curious what other people have done that has worked. How do you set up your SMs (NAT, no NAT, or a mix)? What DHCP server do you use (Windows, Linux, 3rd party)? Has it worked well? Is Prizm the way to go for this?

Any input would be appreciated!

Thanks

There are opensource IP management software tools like IPPlan. You can use this to manually track IP information.


For DHCP, I would route each tower site. The router on-site could provide DHCP to clients and you can poll the DHCP logs out of the router if needed.

For routers, many use Mikrotik. I am still working on redesigning our network to do DHCP on the tower site with routers but am looking towards a Cisco solution using 2621XM’s.

Until then I manually deal with IP addressing and some software we have written keeps track of everything.

We too assign static IP’s and track with IPPlan (easy PHP Scripts you can install on a LAMP server (Linux, Apache, MySQL, PHP).

Microsoft DHCP server was a let down. It would drop clients and not re-issue IP’s.

If we did residential, we would run a DHCP server and it would be on a Linux box.


If you are new to Linux, check out Ubuntu. Install it as a LAMP server (Linux, Apache, MySQL, PHP). You can enable/install various other application easily and it’s very very stable.

Our DHCP server is our primary router; a Cisco 2620. Works great, and is very stable. The only problem i’v ever had with this setup is in the rare instance that you need to restart the router, it will forget its leases and begin issueing duplicate IPs. This will cause you to get many calls untill the last of the old DHCP leases is up. Not a big deal, since you will almost never need a reboot. For good measure, I have reduced our lease time to 1 hour just in case tho… cuz last time really sucked waiting out a 24hr lease. I believe this problem will exist with any DHCP server you chose

Linux-based DHCP actually writes out a dhcpd.leases file, so the lease information survives the reboot.

We to have a routed network. So each tower has it’s own Router and the router hands out DHCP address’s to all clients on that tower.

We use SOEKRIS routers they work well. Sold state.

Frothingdog.ca wrote:
We to have a routed network. So each tower has it's own Router and the router hands out DHCP address's to all clients on that tower.

We use SOEKRIS routers they work well. Sold state.



Are you using a flavor of Linux or BSD on these boxes? We're actually looking to implement something similar and the Soekris boxes are what we've been looking at.

We run OpenBSD on all the routers.

We use mikrotik for our DHCP servers and it works great. For simplicity I give all my customers a static IP but I hand it out via DHCP.

Ideally we’ll be running all DHCP with static leases for customers requesting them. That seems to make more sense to me than wasting IPs to subnet out blocks of statics.

I have cisco 2621s doing DHCP to clients. Never had a problem.The routers have never handed out duplicate IPs and they suffer reboots quite often.

We have assigned static private IP to all our radios.
NAT is only enabled at Customers SM so that customers router or PC’s can get IP’s from the SM radio’s.
So far we haven’t found tough managing the radio but yes it requires proper management and documentation of IP’s.
If you want to access the radio’s from outside either u can do VPN or assign public or virtual public IP to the radio. VPN is the best way in terms of security.

If a client wants a static address we just reserve it in the DHCP pool and and assign it to the clients MAC address spectificly. That way that MAC get’s the same address all the time, again saves IP’s and having to route out a /30 for each client that wants a static.

We use routed blocks at all towers and DHCP hands out the actual static addresses to each customer from a central OpenBSD 3.1 box running DHCP.

The DHCP server was modified to recognise Hostnames before MAC addresses. Which makes it simple. The guys put the hostname into the cust. router and then there is a matching record in DHCP server that points to the DNS name for the static IP they are assigned.

Works great. need to protect your network from rogue DHCP servers (usually routers plugged in backwards and looped). The Moto radios can do that for the most part. Also, we have Mtik’s going in at most towers that can check for that as well.

The system works great! A lot of people do pppoe though…

Paul, PDMNet

paulchops wrote:
We use routed blocks at all towers and DHCP hands out the actual static addresses to each customer from a central OpenBSD 3.1 box running DHCP.

The DHCP server was modified to recognise Hostnames before MAC addresses. Which makes it simple. The guys put the hostname into the cust. router and then there is a matching record in DHCP server that points to the DNS name for the static IP they are assigned.

Works great. need to protect your network from rogue DHCP servers (usually routers plugged in backwards and looped). The Moto radios can do that for the most part. Also, we have Mtik's going in at most towers that can check for that as well.

The system works great! A lot of people do pppoe though...

Paul, PDMNet


This however would not work with Canopy NAT I assume?

works fine with NAT. Tell the Canopy (under NAT config) to use DHCP client.

In this case, since Canopy doesnt send hostnames in its DHCP client requests, our DHCP server uses the MAC address to identify the SM and give it the right IP

Paul