Дерево страниц
Перейти к концу метаданных
Переход к началу метаданных

Initial diagnostics

  1. A DHCP server is started.
  2. Make sure that VLAN ID specified in SSID configuration is correct.
  3. Make sure that a user connects to an appropriate SSID on the AP under consideration.
  4. If encryption is implied for a SSID, make sure that a user has passed authorization successfully.
  5. Check if an address is received by another SSID of the same access point (AP).
  6. Check if an address is received by another device (smartphone/laptop).
  7. Select the mode "Get an address via DHCP" in network settings of a user's device.
  8. Specify a static IP address on a client, check if a gateway is accessible using ping (icmp).

If these settings are correct, move to checking configuration of the server and networking functions. To run diagnostics, it is necessary to know a MAC address of a client's device and have an opportunity to initiate providing a client with an address via DHCP.

Checking a DHCP server

To check DHCP server operation, analyse its logs.
The three main problems can be seen from logs:

  • Discover is absent.
  • Discover is present, Offer is absent.
  • Discover and offer are present, Request is absent.

 

1. Discover from a client's device is absent in logs.

Start tcpdump on an interface of a server to which Discover was supposed to get. Check the server for Discover.

  • If Discover is absent in a dump, check network settings, a DHCP-relay and its connections.
  • If Discover is present in a dump, but absent in logs, check the server configuration (paragraph 1.1).
1.1. Discover is present in a dump, but absent in logs.

Discover is ignored because it arrives on an interface that is not listened by the server. Determine the interface that Discover gets on and add this interface to DHCP server configuration.


In the file /etc/default/isc-dhcp-server all listened interfaces should be listed, for example:
INTERFACES="eth0 eth1"

 

2. Discover is present in DHCP server logs, but Offer is absent.

To determine the cause, check DHCP server logs. Common causes:

  • one of the subnetworks used is not specified
  • classes are specified incorrectly
  • pool vacant addresses exhaustion
  • failover problems

2.1 One of the subnetworks used is not specified

Subnetworks containing addresses of listened interfaces and a DHCP-relay (if used) should be specified in the file /etc/dhcp/dhcpd.conf. Even if addresses from these subnetworks are not allocated by the server, for example:

subnet 192.168.1.0 netmask 255.255.255.0 {}

2.2 Pool vacant addresses exhaustion

One of the common causes is a case when a server runs out of vacant addresses. To check it, use a guide: ISC DHCP server pool range usage monitoring


3 Discover and Offer are present in DHCP server logs, but Request is not.

Use tcpdump for the interface that Discover arrives on and check this dump for Offer.

  • If Offer is absent in a dump, a wrong route to a user subnetwork is specified on a server. Hence, Discover is sent to one interface, but Offer is sent to another one and does not reach a recipient. Check and reconfigure routing on the server.
  • If Offer is present in the dump, check a DHCP relay and a connection between DHCP server and DHCP relay.


4 Checking a connection between a DHCP server and a DHCP relay

Ping a DHCP relay from a server. Ping should be done from an appropriate interface.
 

Checking a DHCP relay

Debugging in the Scheme with GRE

1. Checking GRE tunnels status.

To check status of GRE tunnels,

  • Identify "primary" IP address of an AP via EMS management system. A primary address is specified in the tab "Access" of the main window and in the section "EMS Monitoring".
  • On ESR, check a list of the AP's GRE tunnels. Use the following command:

show tunnels status | include <XXX.XXX.XXX.XXX>
where XXX.XXX.XXX.XXX – AP primary IP


The command will return a list of tunnels built by this AP.

  • If there are no tunnels, check DHCP server configuration and IP connectivity between an AP and ESR. 
  • If there is one tunnel, check DHCP server configuration and ESR configuration.
  • If there are two tunnels, check if sub-tunnels with VLANs consistent with AP configuration are established for the second tunnel.


2. Creating a traffic dump on a SUB-GRE tunnel of an AP under consideration.

To get a dump, connect under the 'techsupport' user, enable 'su' mode and enter the command:


 tcpdump -i dygreХХХ.YYY -evn -c100

  where XXX is a GRE tunnel number found on the previous step, YYY isVLAN ID


In a dump received, perform a search for Discover from a client:

  • If there is no Discover in a dump, an AP has not probably been able to establish a tunnel correctly. Check DHCP server configuration (option 43, suboption 12) and AP configuration.
  • If Discover is present in the dump, but Offer is absent - move on to checking exchange with a DHCP server (paragraph 3).


3. Creating a traffic dump when exchanging packets with a DHCP server.

To get a dump, connect under the 'techsupport' user, enable 'su' mode and enter the command:


tcpdump -i te1_YYY.ZZZ -evn -c100
, where YYY– ESR port number, ZZZ – VLAN number.


  • If there is no Discover in the dump, something is wrong with ESR configuration.
  • If Discover is transmitted to a DHCP server, but Offer is absent – there is a problem with connection between a DHCP server and ESR.
  • If Discover and Offer are present, but Request does not participate in exchange, there is a problem with ESR configuration.


Debug in the Scheme without GRE

1. Creating a traffic dump on an interface directed to a client.

Find Discover from a client during the dump analysis.

  • If there is no Discover, check:
  1. Firewall configuration on a DHCP-relay.
  2. Network configuration for connection with an AP.
  3. AP configuration.
  • If Discover is present, but Offer is absent – move on to checking DHCP server exchange.


2. Creating a tcpdump of DHCP server exchange.

  • If there is no Discover in a dump – there is a problem with DHCP relay configuration. Check a firewall and routing configuration on a DHCP relay.
  • If Discover is transmitted to a DHCP server, but Offer is absent – there is a problem with connection between a DHCP server and a DHCP relay.
  • If Discover and Offer are present, but Request does not participate in exchange – there is a problem with firewall settings on a DHCP-relay.


Checking an access point

Configure an opened SSID without authorization in the same VLAN with the SSID considered. According to an instruction on creating a dump (pcap) of an access point, create dumps on a radio interface to which a user is connected and on eth interface. Results should be interpreted depending on a connection scheme used.

For any scheme:

  • If Discover from a user is absent in a dump with a radio interface, there is a problem with a client's device. Probably it has not connected to the network or does not require an address for some reasons.

For the scheme with GRE:

  • If Discover from a user is present on a radio interface but absent on eth, a GRE tunnel for user traffic has not been built because an access point received an incorrect suboption 12 when getting a primary address. Check DHCP server configuration (option 43, suboption 12).
  • If Discover is present in both dumps, packets are transmitted from an AP. Make sure that ESR receives packets.

For the scheme without GRE:

  • If Discover is present in dumps from the radio interface and eth, but absent on a DHCP-relay, a user VLAN is not either configured on the end device or forwarded to the DHCP-relay.


  • Нет меток