|
[Config] Simple DHCP Server setupOk 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
|
|
cramer Premium Member join:2007-04-10 Raleigh, NC Westell 6100 Cisco PIX 501
|
cramer
Premium Member
2013-Feb-28 5:08 pm
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. |
|
cramer Premium Member join:2007-04-10 Raleigh, NC Westell 6100 Cisco PIX 501
|
cramer
Premium Member
2013-Feb-28 7:42 pm
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.) |
|
|
to FreeMatt
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 |
|
|
to cramer
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 |
|