Cisco → [Config] Simple DHCP Server setup

Ok so i am trying to setup a simple DHCP setup connected to a POE switch and a few access points. I cannot get it to pass out addresses from the pool, but if i program them static i can communicate so i imagine something wrong with the DHCP setup but nothing sticks out to me. also i was able to ping addresses out of the cisco 2800 box and now the 1 AP i have attached to test stopped responding once i got kinda pissy and just started changing things i think i corrected them all but still wont work please take a look and any problems please address them for me :)

keep in mind both ports are trunked
0/0 is internet modem
0/1 is to the switch
And am trying to manage The APs external so i dont have to connect to the guest network to make changes

ip dhcp excluded-address 172.16.16.1 172.16.16.30
!
ip dhcp pool Guests
network 172.16.0.0 255.255.0.0
dns-server 8.8.8.8 8.8.4.4
default-router 172.16.16.1
lease 2
!
!
!

interface GigabitEthernet0/0
description Uplink to Internet SWT 0/23
no ip address
duplex full
speed 1000
!
interface GigabitEthernet0/0.2013
description WAN Connection
encapsulation dot1Q 2013
ip address 1.1.1.12 255.255.255.240
ip nat outside
ip virtual-reassembly in
traffic-shape rate 42000000 1050000 1050000 1000
!
interface GigabitEthernet0/1
no ip address
ip flow ingress
ip flow egress
duplex auto
speed auto
!
interface GigabitEthernet0/1.140
description Private scope to POE Switches/AP's
encapsulation dot1Q 140
ip dhcp relay information trusted
ip address 172.16.16.1 255.255.0.0
ip nat inside
ip virtual-reassembly in
traffic-shape rate 42000000 1050000 1050000 1000
!
interface GigabitEthernet0/2
no ip address
duplex auto
speed auto
!
ip forward-protocol nd
!
ip http server
no ip http secure-server
ip flow-export source GigabitEthernet0/1
ip flow-export version 5
!
ip dns view default
domain timeout 2
ip nat translation tcp-timeout 3600
ip nat translation udp-timeout 60
ip nat pool WAN 1.1.1.2 1.1.1.10 netmask 255.255.255.240
ip nat inside source list 5 pool WAN overload
ip nat inside source static tcp 172.16.16.4 80 1.1.1.11 6750 extendable
ip nat outside source static tcp 1.1.1.11 6750 172.16.16.4 80 extendable
ip default-network 0.0.0.0
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0.2013
ip route 172.16.0.0 255.255.0.0 GigabitEthernet0/1.140
!
access-list 5 permit 172.16.0.0 255.255.0.0
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
gatekeeper
shutdown
!
!
line con 0
line aux 0

!
scheduler allocate 20000 1000
end



I don't see anything obvious wrong with the config bits as post, for dhcp anyway. Unless there's bits you didn't post turning off routing or the dhcp server, that should work. "debug ip dhcp server packet" to see what's failing.

"ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0.2013" -- NEVER. DO. THIS. Aim your default route at an ip address, not a [censored] broadcast network. You've created a proxy-arp setup -- 'sho arp g0/0.2013' while people are using the internet for an idea of why this is stupid and wrong.

"ip route 172.16.0.0 255.255.0.0 GigabitEthernet0/1.140" -- WTF is this supposed to do? Think about it for a minute... if g0/1 is up, CONNECTED will override STATIC; when down, the routes attached to that interface won't be in the table. Maybe you want "ip route ... null0 254 perm"???

quote:

---

"ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0.2013" -- NEVER. DO. THIS. Aim your default route at an ip address, not a [censored] broadcast network.

---

Why? Plenty of DSL inetrfaces out there with default routes pointing at the dialer interface? RFC1483 bridged networks config a little differently but it would be nice to understand the reasoning.

My only issue with the config for me, aside from what Cramer has suggested, is the network is obviously a 24 bit network but you're using a 16 bit mask. It shouldn't matter, but if you're using the third octet for network addressing then I'd use a mask that goes down to the third octet as well.

Dialer interfaces aren't a multi-access broadcast medium. They're point-to-point, and thus, you know exactly where to send the packet -- that is, put it on the wire and the single thing on the other end will deal with it. And in almost all dialer cases, ppp replaces that route once the link is up. (the interface route is there to trigger the dialer -- in the dark days of dialup, DSL interfaces trigger the dialer as soon as they sync so the route in unnecessary.)

The part you didn't quote is the why... "proxy-arp". Ethernet is not like that. When you route to an ethernet (broadcast, multi-access) you are blindly asking "hey, who can get a packet to XXX" and trusting the first thing to answer. 30 years ago, that's the way things were done. The internet was tiny, and many networks weren't connected.

Doing that today is suicide. The insecurity of such a mechanism should be obvious. The practical limitation is one of arp cache lookups, as you will now have an arp entry for Each. And. Every. Internet. Address. You might not realize just how many hosts you talk to every day. I've seen far too many "my internet is slow" complaints from people who have done this. (I really shouldn't take it out them as they're pasting what some other moron post on the internet.)

What make / model is the switch connected on interface GigabitEthernet0/1.140? Is it also doing a trunk on
VLAN140 to the router? Other than the REALLY wierd config of a 172.16.0.0/16 for the pool versus 172.16.16.1/16
for the DG, I'm almost willing to bet something may be borked at layer 2 between the router and the swtich.

What's the output of "show ip dhcp pool" show, in addition to cramer's suggestion of debugging the dhcp?

Another option is plug a PC direct into the LAN interface and see if it gets a DHCP address or not. If it does,
I'd look closer between the router and the switch.

Regards

Nice answer. Despite being 40+, I am new (about 6 years) as a network engineer. I have been "lucky" to have worked in Cisco land almost all the time but I have moved on so my eyes are being widened. As a relative newbie I have no real grasp of how things "used to be done" which is both good and bad in equal measure. Your answer perfectly explains two key items that I see mentioned, but which I had not directly encountered before, so thanks

Yes, cramer knows his stuff, that's for sure