Interesting week (EEM Applets, DHCP and IP SLA)

I had a rather interesting week and this is probably the only place I can vent about it where people would understand.

We've been having this month long debate about DHCP at my workplace. We basically have an MPLS network that connects all our centers back to our data center and the internet circuit is in the data center. Our former network architect always had me put the DHCP scope on the server but we have some old school folks who have always put it on the router and have never wanted to learn how to use the DHCP server (Anyone who's ever opened that MMC can attest to how easy it is to create a scope). They have literally never used a DHCP server in their life and they have no idea how to use it or how easy it is. The debate basically amounted to this: Management and architecture is going towards full AD integration and security so they want it on the DHCP server; old school network engineers want the ease to troubleshoot on the router and if the router gets disconnected from the WAN, the end-users can still print locally since their local print server has a static IP.

So it boiled to a head in a staff meeting this Monday where the old school was arguing about single points of failure and so on so I spoke up and was like "Why don't we just stick IP SLA on the routers to ping the DHCP server once every 15 minutes or so and if the router loses connectivity with the DHCP server for an hour or something, an EEM script is run that creates a local DHCP scope for users to connect to local resources and as soon as the IP SLA tracking object is back up, an EEM script is run that erases the config."

After I said that, you could hear a pin drop in the meeting. Ever have that feeling where you are absolutely sure that no one has the faintest idea of what you're talking about? Yeah.. Our senior network engineer (the strongest advocate for router DHCP) was like "Ummm... what's EEM? Is that something new in the latest IOS version? If so, it's not really something we should be putting into production since it's bound to be buggy."

After much insistence that it's been around for some time, my boss basically says that if I could prove it works, the argument is over.

So I went back to my desk and wrote this very simplified script which toned down the timers so I could test it quickly:

ip sla 1
icmp-echo <DHCP-server-IP> source-interface loopback0
frequency 5
ip sla schedule 1 life forever start-time now

track 1 rtr 1 reachability
delay down 10 up 60

event manager applet DHCP -DOWN
event track 1 state down
action 1.0 cli command "enable"
action 1.1 cli command "conf t"
action 1.2 cli command "ip dhcp pool DATA-TEMP"
action 1.3 cli command "network 10.0.0.0 255.255.255.0"
action 1.4 cli command "default-router 10.0.0.1"
action 1.5 cli command "dns-server 8.8.8.8"
action 1.6 cli command "domain-name our.company.com"
action 1.7 cli command "ip dhcp excluded-address 10.0.0.1 10.0.0.255"
action 1.8 cli command "do write mem"
action 1.9 syslog msg "AUTO-DHCP CONFIGURED"

event manager applet DHCP-UP
event track 1 state up
action 1.0 cli command "enable"
action 1.1 cli command "conf t"
action 1.2 cli command "no ip dhcp pool DATA-TEMP"
action 1.3 cli command "no ip dhcp excluded-address 10.0.0.1 10.0.0.255"
action 1.4 cli command "do write mem"
action 1.5 syslog msg "AUTO-DHCP REMOVED"

I test it on GNS3, my home lab (pair of 2821's and a DHCP VM), and with a pair of 2951s at work. It works beautifully and pretty easy to standardize. Basically cookie-cutter script where you fill in the blanks and the only blanks you have is the network range and the default gateway. Sent screenshots to everyone and the first e-mail I get back is from the Sr engineer along the lines of "That looks complicated. We should just keep DHCP on the router."

In the end, DHCP on the server wins but fighting against people scared of learning something new or trying things differently because they've done things a certain way for 10+ years is exhausting

Find more posts tagged with

Comments

networker050184

I wonder how well duplicate address detection would work in this scenario. I know it relies on ping an GARP to avoide duplicates, but there may be some scenarios where that may not work properly.

TechGuy215

I've ran into this issue as well. Once someone gets stuck in their ways you need a fork lift to budge them! As far as single point of failure regarding the DHCP servers, do you have a virtual environment? You could easily create a fail-over cluster with VMWare that would be more than enough to meet FT and HA requirements.

However, you're solution was pretty neat. Failing-over to the DHCP on the router, honestly I never would've thought to do it that way.

Iristheangel

networker050184 wrote: »

I wonder how well duplicate address detection would work in this scenario. I know it relies on ping an GARP to avoide duplicates, but there may be some scenarios where that may not work properly.

That's very plausible too but for the most part it work and it's only on the off-chance that the DHCP server loses connectivity with the router long enough for the script to be run AND the client's DHCP runs out during that time. These centers only have about 10-15 people in their management offices so it's not so much of an issue. I could also create an exclusion for the first 200 IPs on the router and the last 50 on the server. Then let the last 50 or so get handed out in the event of a DHCP failure over the WAN.

Iristheangel

@TechGuy - Yes. We have redundant servers and split scope DHCP but when you're trying to explain that to someone who doesn't want to even understand how to use DHCP, it's pretty much technology-voodoo-magic to them

Iristheangel

@Phoeneous - Me either. That's why I'm not for router DHCP. It's nice for small simple companies but for an enterprise with over 100+ locations world-wide, it doesn't make a lot of sense. Especially when you want DHCP, DNS and AD integration.