Wireless Access

last person joined: 11 hours ago 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

how to view internal DHCP server debug logging

This thread has been viewed 25 times
  • 1.  how to view internal DHCP server debug logging

    Posted Sep 25, 2016 01:15 PM

    Good day.

     

    We are using the internal DHCP server to hand out private addresses for users on our guest network. Regular users are served addresses via our campus DHCP server. We are currently trying to troubleshoot an issue and would like to be able to view DHCP debug logging for the guest devices.

     

    We issued these commands:

    config t
    logging level debugging network process dhcpd
    logging level debugging network subcat dhcp

     

    The problem is that nothing seems to be captured for the controller-provided addresses. We're only able to see debug information on addresses obtained from our external DHCP server.

     

    Is there a way to view debug logging for the internal DHCP server on the local controller?



  • 2.  RE: how to view internal DHCP server debug logging

    EMPLOYEE
    Posted Sep 25, 2016 01:52 PM

    Did you type "show log network 50"?



  • 3.  RE: how to view internal DHCP server debug logging

    Posted Sep 25, 2016 03:31 PM
    Yes, in a fashion. We tried that, using "| include" to search for a particular IP and MAC to no effect. We also tried searching the entire log, not just the most recent messages.

    There do not appear to be any messages relating to addresses being handed out by the controller DHCP server.


  • 4.  RE: how to view internal DHCP server debug logging

    EMPLOYEE
    Posted Sep 25, 2016 05:16 PM

    - What version of ArubaOS are you running?

    - Do you have the DHCP server enabled?

    - Is there an ip address on the controller in the same subnet as the dhcp server?

     

    type "show ip dhcp statistics" and "show ip dhcp binding" to see if there is any activity

     



  • 5.  RE: how to view internal DHCP server debug logging

    Posted Sep 25, 2016 10:50 PM

    version 6.4.3.4

    DHCP server is enabled. We've been using it for a few weeks to hand out addresses for our guest network. We ran both commands you suggested earlier today. There are active leases and detailed information in the bindings database.

    The controller does have an IP address in the same subnet as the DHCP scope. The address for that subnet is the default router in the DHCP config.

     

    I am now suspicious that something else is going on or that I'm misunderstanding something. We were troubleshooting issues earlier today where it appeared that devices were "slow" to get an IP address on the guest network. This was witnessed after the device had already been associated to and authenticated on the guest network but it was now waking up or the the user was trying to reconnect. The device would appear to have the same IP as before, but then it would seemingly lose its address and try to get another one. This part is what was "slow". An iPhone would keep trying and eventually get back on the network. An Android phone could not get back on the network. It was as if the device gave up.

     

    We enabled DHCP debug logging, as described before, to try and troubleshoot the issue. But we could not find the MAC addresses of the problem devices using the "| include" feature. We also had difficulty locating other devices with addresses from the controller DHCP scope. It is difficult to scan through the log output, so we came to the conclusion that DHCP activity from the controller was not being recorded.

     

    But now I see that there are addresses from the controller DHCP server. The "| include" is not consistent. It does not always return the same results. (Unless I've been staring at this too long and I'm seeing things.) See the output below. It is in sequence and was copied directly from the CLI. The first command returns nothing, twice. Then I modified it with a period and it returned entries. Then I removed the period and it returned entries again. Do you have any thoughts?

     

    (aruba7240-green-1) #show log network all | include 172.30.126

    (aruba7240-green-1) #show log network all | include 172.30.126

    (aruba7240-green-1) #show log network all | include 172.30.126.
    Sep 25 22:44:31 :202546:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan2003: OFFER b8:ae:6e:fd:ff:7f Transaction ID:0xf8769cf5 clientIP=172.30.126.4
    Sep 25 22:44:33 :202546:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan2003: OFFER b8:ae:6e:fd:ff:7f Transaction ID:0xf8769cf5 clientIP=172.30.126.4

    (aruba7240-green-1) #show log network all | include 172.30.126
    Sep 25 22:44:31 :202546:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan2003: OFFER b8:ae:6e:fd:ff:7f Transaction ID:0xf8769cf5 clientIP=172.30.126.4
    Sep 25 22:44:33 :202546:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan2003: OFFER b8:ae:6e:fd:ff:7f Transaction ID:0xf8769cf5 clientIP=172.30.126.4
    Sep 25 22:44:35 :202546:  <DBUG> |dhcpdwrap| |dhcp| Datapath vlan2003: OFFER b8:ae:6e:fd:ff:7f Transaction ID:0xf8769cf5 clientIP=172.30.126.4

    (aruba7240-green-1) #



  • 6.  RE: how to view internal DHCP server debug logging
    Best Answer

    Posted Sep 27, 2016 08:00 AM

    We figured out the problem. It appears that the internal DHCP server messages weren't showing up in the DHCP debugging log because we inadvertently left out the acl allowing DHCP traffic in the custom guest authenticated role we are using.

     

    This was also causing the problem we were trying to troubleshoot. Users on the guest network were able to get an IP address initially and communicate on the network without issue. However, once the device tried to renew the DHCP lease, either after waking up or at the half-way mark for the lease, the DHCP reply messages were blocked from the DHCP server.

     

    any any svc-dhcp permit

     

    The above was not included in any policy we had applied to the authenticated role. Through a packet capture, we witnessed this exchange. iOS and OSX devices would eventually tell the DHCP server an address they were choosing via an ARP request. This traffic was permitted, thereby finally obtaining a response from the DHCP server. Android devices just seemed to give up, never being able to obtain an address.

     

    See also this post that discusses the problem: https://community.arubanetworks.com/t5/Wireless-Access/2nd-attempts-for-DHCP-from-mobile-and-handheld-devices/m-p/48328#M4699

     

    The reason for intermittent "| include" search results in the log is still not clear.