Reset Search
 

 

Article

Troubleshooting DHCP issues

« Go Back

Information

 
TitleTroubleshooting DHCP issues
Objective
This article will outline several common issues that may prevent clients from getting IP addresses via DHCP
Environment
  • EXOS All
  • DHCP
Procedure

Case 1: DHCP Server and DCHP Client are in the same VLAN

  1. Locate a client that is not working. Determine its MAC address.
    1. Find the port that this client is connected to, then run show fdb port <port#>
    2. Is the MAC address learned in the correct VLAN? If yes, skip to step 2. If not check the items below.
      1. Is the port active?
      2. Is the VLAN tagging correct on the port?
      3. Is the client directly connected, or is there something else in between?
  2. Configure the test client with a static IP address in the correct subnet. Is the test client able to ping the DHCP server? If not, there is a connectivity issue to the DHCP server. Repeat the troubleshooting from step 1 for the DHCP server. If this is correct on both ends, verify the VLAN configuration and tagging on all switches between the client and DHCP server.
  3. If the client is able to reach the DHCP server with a static IP address, take a packet capture on both the client and the DHCP server to determine where the DHCP process is breaking down. In Wireshark, a display filter can be applied to view just DHCP traffic for one specific client. The syntax of this filter is bootp.hw.mac_addr == <client_mac>.
    1. If the DHCP server sees the Request or Offer come in, but does not respond, ensure that the DHCP scope is configured correctly.
    2. If the client never sends a Request or Offer, ensure that DHCP is enabled on the client.

Case 2: DHCP Server and DHCP Client are in separate VLANs

  1. Locate a client that is not working. Determine its MAC address.
    1. Find the port that this client is connected to, then run show fdb port <port#>
    2. Is the MAC address learned in the correct VLAN? If yes, skip to step 2. If not check the items below.
      1. Is the port active?
      2. Is the VLAN tagging correct on the port?
      3. Is the client directly connected, or is there something else in between?
  2. Determine where routing is happening for the client's VLAN. On the router for the VLAN, check to see if bootprelay is enabled for both the client and server VLANs.
    1. show bootprelay
    2. show config nettools
  3. If bootprelay is not configured, configure it pointing to the DHCP server.
  4. If bootprelay is configured correctly, verify that IP forwarding is enabled on both the client and server VLANs. The output of show vlan should show an f flag for these VLANs.
    1. If this is not enabled, enable IP forwarding on both VLANs.
  5. If IP forwarding is enabled, verify that the DHCP server is reachable from the client VLAN. On the switch, you can specify the source address for a ping with the command ping <DHCP_server> from <IP_of_client_vlan>.
    1. If this is not successful, repeat the test from the server VLAN. If this fails, there is likely a layer 2 connectivity issue to the server. Verify the same information from step 1 for the DHCP server, as well as the VLAN configuration and tagging for the switches along the path to the server.
  6. In the router for the VLAN, confirm that the client's MAC address is present in the FDB with the command show fdb <client_mac>. If this is not present, there is likely a layer 1 or layer 2 issue between the edge switch and the router. Verify tagging for this VLAN along the downstream switches.
  7. Take a packet capture on both the client and the server to determine where the DHCP process is failing. In Wireshark, a display filter can be applied to view just DHCP traffic for one specific client. The syntax of this filter is bootp.hw.mac_addr == <client_mac>.​ The DHCP traffic seen on the server should be sent unicast, with the source address being the router's IP address in the client VLAN.
    1. If the DHCP server sees the Request or Offer come in, but does not respond, ensure that the DHCP scope is configured correctly.
    2. If the client never sends a Request or Offer, ensure that DHCP is enabled on the client.
Additional notes
show port <port#> info detail can be used to check the VLANs present on a port, and the tagging. An untagged VLAN will show "Internal Tag" in this output, while a tagged VLAN will show "802.1Q Tag". In the example below, VLAN Default is present untagged on this port, and VLAN voip is present with a tag of 100.
X460G2-24p-G4.5 # show port 1 info detail
Port:   1
        Virtual-router: VR-Default
        Type:           UTP
        Random Early drop:      Unsupported
        Admin state:    Enabled with  auto-speed sensing  auto-duplex
        Link State:     Ready
        Link Ups:       0        Last: --
        Link Downs:     0        Last: --

        VLAN cfg:
                 Name: Default, Internal Tag = 1, MAC-limit = No-limit, Virtual router:   VR-Default
                 Name: voip, 802.1Q Tag = 100, MAC-limit = No-limit, Virtual router:   VR-Default
                       Port-specific VLAN ID:  100


Related Articles:
DHCP server sending DHCPNAK packets
DHCP Clients sending DHCPDECLINE packets
How to apply a bootprelay dhcp server to a specific VLAN
How to configure bootprelay
How to configure the DHCP server on a VLAN in EXOS
 

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255