DHCP problem after reload/power down

[DarrenB_UK]

Hi all,

Have a problem that has had me scratching my head.

Using a 1941 ISR at home as my internet router which is configured as a DHCP server.  This connects via a /30 point-to-point L3 link to a routed port on a 3560.  SVIs are created on the 3560 with ip helpers configured pointing to the IP address of the router's /30 link.  Devices then sit in their respective VLANs as configured on the 3560.

Everything works as expected until the router is reloaded or loses power (thanks cleaner!!).  Once power is restored (or after reload), all devices configured with a static IP have full connectivity, however, any device configured via DHCP lose connectivity and have problems renewing addresses. 

The ONLY way to restore connectivity is power down the clients and trigger a DHCPDISCOVER.  

Obviously, the 1941 loses DHCP bindings though it appears that the client devices keep their addresses (as assigned prior to the reload) but lose all network reachability.

Any ideas?

I've configured DHCP debugging on both the switch and router whilst everything is working and confirm DHCP and relay working as expected.

Many thanks

[Peter Paluch]

Hi Darren,

Well, this is strange - and interesting!

Let me first ask, though: Assuming the 1941 is reloaded while the DHCP clients are not, the clients will obviously retain their dynamically obtained IP configuration until the lease time expires. Till then, after the 1941 reboots, are the clients able to access internet? Under normal circumstances, they should be able to access internet just fine.

In addition, when you did the debugs on the 1941 and saw the clients send DHCPREQUEST messages to refresh their existing leases, what did the debug say? Did the 1941 respond?

Best regards,
Peter

[DarrenB_UK]

Hi Peter,

That's the weird thing!  DHCP assigned clients lost internet connectivity whilst statically assigned clients were fine after the router reload.  Clients were in the same VLAN.

I've just performed a debug on the 1941 ( debug ip dhcp server packet detail ) using my iPhone to request a renew (via Airport Extreme in bridge mode, in VLAN 10 and connected to the 3560 )  Bearing in mind, all is working as expected right now - router has been up since Friday (previously had been up for months without a power out/reload)

Aug  4 19:59:36.395: DHCPD: client's VPN is .
Aug  4 19:59:36.395: DHCPD: No option 125
Aug  4 19:59:36.395: DHCPD: DHCPREQUEST received from client xxxx.xxxx.xxxx.
Aug  4 19:59:36.395: DHCPD: Appending system default domain
Aug  4 19:59:36.395: DHCPD: Using hostname 'xxxxxx.net.local.' for dynamic update (from hostname option)
Aug  4 19:59:36.395: DHCPD: Sending DHCPACK to client xxxxxx.xxx.b1 (10.0.10.111).
Aug  4 19:59:36.395: DHCPD: no option 125
Aug  4 19:59:36.395: DHCPD: unicasting BOOTREPLY for client xxxx.xxxx to relay 10.0.10.254.

Mac addresses removed to protect the innocent!

Cheers,

Darren

[Peter Paluch]

Darren,

Would you mind posting a sanitized copy of your 1941 running-config?

Best regards,
Peter

[DarrenB_UK]

Here you go Peter!

Current configuration : 4577 bytes
!
! Last configuration change at 21:06:18 BST Mon Aug 4 2014 by admin
! NVRAM config last updated at 21:06:34 BST Mon Aug 4 2014 by admin
! NVRAM config last updated at 21:06:34 BST Mon Aug 4 2014 by admin
version 15.2
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
service password-encryption
!
hostname C1941-ISR
!
boot-start-marker
boot-end-marker
!
!
logging buffered 32768
enable secret 4 XXXXXX
!
no aaa new-model
clock summer-time BST recurring last Sun Mar 2:00 last Sun Oct 2:00
!
ip cef
!
!
!
no ip dhcp conflict logging
ip dhcp excluded-address 10.0.2.250 10.0.2.255
ip dhcp excluded-address 10.0.10.1 10.0.10.100
ip dhcp excluded-address 10.0.10.250 10.0.10.255
!
ip dhcp pool subnet:10.0.2.0
 network 10.0.2.0 255.255.255.0
 dns-server 8.8.8.8 8.8.4.4 
 default-router 10.0.2.254 
!
ip dhcp pool subnet:10.0.10.0
 network 10.0.10.0 255.255.255.0
 default-router 10.0.10.254 
 dns-server 8.8.8.8 8.8.4.4 
!
!
!
ip domain name xxxxx.local
ip name-server 8.8.8.8
no ipv6 cef
multilink bundle-name authenticated
!
!
crypto pki trustpoint TP-self-signed-4027390488
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-4027390488
 revocation-check none
 rsakeypair TP-self-signed-4027390488
!
!
crypto pki certificate chain TP-self-signed-4027390488
 certificate self-signed 01
  BLAH BLAH BLAH!
  
      quit
license udi pid CISCO1941/K9 sn XXXXXX
!
!
username xxxxxxx password 7 xxxxxxx
!
!
!
!
!
!
interface Loopback1
 ip address 10.255.255.255 255.255.255.255
!
interface Embedded-Service-Engine0/0
 no ip address
 shutdown
!
interface GigabitEthernet0/0
 description WAN Interface
 no ip address
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 duplex auto
 speed auto
 pppoe enable group global
 pppoe-client dial-pool-number 1
 no cdp enable
!
interface GigabitEthernet0/1
 description LAN Interface
 ip address 10.255.255.1 255.255.255.252
 ip nat inside
 ip virtual-reassembly in
 duplex auto
 speed auto
!
interface Dialer1
 description WAN Dialer
 ip address negotiated
 no ip unreachables
 ip mtu 1492
 ip nat outside
 ip virtual-reassembly in
 encapsulation ppp
 ip tcp adjust-mss 1452
 dialer pool 1
 dialer-group 1
 ppp authentication chap callin
 ppp chap hostname xxxxx
 ppp chap password xxxxx
 no cdp enable
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
ip nat inside source list PERMIT-NAT interface Dialer1 overload
ip route 0.0.0.0 0.0.0.0 Dialer1
ip route 10.0.0.0 255.0.0.0 10.255.255.2
!
ip access-list standard PERMIT-NAT
 permit 10.0.0.0 0.255.255.255
ip access-list standard VTY-ACCESS
 permit 10.0.0.0 0.255.255.255
!
dialer-list 1 protocol ip permit
!
!
!
control-plane
!
!
!
line con 0
 exec-timeout 15 0
 logging synchronous
line aux 0
line 2
 no activation-character
 no exec
 transport preferred none
 transport output pad telnet rlogin lapb-ta mop udptn v120 ssh
 stopbits 1
line vty 0 4
 access-class VTY-ACCESS in
 exec-timeout 15 0
 login local
 transport input telnet ssh
line vty 5 15
 access-class VTY-ACCESS in
 exec-timeout 15 0
 login local
 transport input telnet ssh
!
scheduler allocate 20000 1000
ntp source Dialer1
ntp server 212.126.60.133
!
end

[Peter Paluch]

Darren,

I do not see any obvious problems with the configuration - apart from some formulaic commands that are often shown in documentation but aren't really necessary, I see nothing at all that could be the cause of your problems.

Still, I wonder - if you restarted your router, would your DHCP clients be at least able to traceroute or ping to an explicitly specified IP address? Sometimes, DNS issues can manifest themselves in this way. Would you be willing to do an experiment, reload the router, and then try tracerouting, say, 158.193.152.2?

Best regards,
Peter

[DarrenB_UK]

Hi Peter,

Thanks so much for your time on this.  Yes, it's definitely got me scratching my head!

I will get back to you in the near future once I have opportunity to perform this test - the wife's happily watching streamed content and I'm ready for sleep!

Thanks again and kind regards,

Darren

[Peter Paluch]

Darren,

You're very much welcome! Sure, don't break things now

I am looking forward to hear from you when you have the opportunity to do the intrusive testing.

Best regards,
Peter

[DarrenB_UK]

I've finally had time to return to this so thought I'd update with my findings.

A few weeks ago, the steam iron had a fault and caused the RCD to cut power which resulted in all network devices and clients to cold boot,  DHCP then worked as normal.

As part of some routine maintenance, I upgraded the switch IOS to version 15.2(2).  Today, our ISP had a fault with the DSLAM but until this was confirmed, I had rebooted the 1941 as part of my troubleshooting .  Hey presto, no problems with DHCP!

How strange - perhaps a minor bug in the previous switch IOS (15.1)?

So many thanks Peter for your response - sorry it's taken so long to report back but all seems to work as expected now.

[Peter Paluch]

Hi Darren,

Thanks for keeping me updated :) Glad it's running after all!

I wonder, do you happen to run anything like DHCP Snooping on the switch?

Best regards,
Peter

[DarrenB_UK]

Hi Peter,

Not on the layer 3 switch but recently I have run DHCP Snooping with IP Source Guard and Port Security on another switch that connects my AV equipment, PS4 and a Mac Mini.  Came in handy for helping me pass CCNP Switch :)

The original issue occurred before these features were configured though and other devices were affected that connected directly to the 3560.

All the best,

Darren