DHCP, DHCP relay & DHCP snooping

-

Regular DHCP packets

1. PC sends DHCP Discover as broadcast, contains the IP assigned previously
    we see two discover packets here, note the previous assigned IP 192.168.2.205


























2. DHCP server responses with DHCP offer, also is broadcast



























3. PC sends DHCP Request, also is broadcast.
     it has DHCP server IP in order to confirm that PC will take its assignment.























4. DHCP server acknowledge the DHCP request.
























5. PC sends ARP probe to verify no duplicate IP on the network.


















6. If  PC gets ARP response which indicates duplicated IP exists on the network, PC will sends DHCP Decline, then restart DHCP discover
    note there is no previous assigned IP in the new DHCP Discover message


















































7. PC may send DHCP Inform to obtain other info such as default gateway and DNS.

























================================================================

Issue when "Device tracking" is enabled on access switch

Symptoms:
DHCP server has lots IPs marked as BAD-ADDRESS when assigning IPs.

Cause:
access switch with device tracking enabled sends Cisco ARP Probe
the highlight packet is from access switch with source IP 0.0.0.0. PC doesn't really understand it, it thinks this indicates a duplicate IP, so send DHCP Decline to DHCP server.



















Solution:
Adjust access switch ARP probe configuration to delay switch ARP probe 10 seconds.

ip device tracking probe delay 10



========================




1. DHCP relay is enabled on switch L3 interface with command: ip helper-address x.x.x.x

2. DHCP relay on WLC is enabled when enable DHCP proxy and configure the primary DHCP server IP. If DHCP proxy is disable, this DHCP IP will be ignored.
When DHCP relay is disabled, DHCP discovery and request will be bridged to switch L3 interface, so use switch DHCP relay setting.

3. The DHCP discover packet is sent from relay agent to DHCP server has Relay agent IP address is set, this packet will be dropped by switch DHCP snooping with error:
  %DHCP_SNOOPING-5-DHCP_SNOOPING_NONZERO_GIADDR: DHCP_SNOOPING drop message with non-zero giaddr or option82 value on untrusted port, message type: DHCPDISCOVER, MAC sa: 000c.290a.fd76
One option to fix this is to set the relay agent (like WLC) switch port to DHCP snooping trust.
 
4.Option 82 basically attach switch ID and switch port ID to the DHCP discover and request, DHCP Offer returns from DHCP server has the same info attached, so the switch knows where to send the DHCP offer, with DHCP snooping, this literally turns DHCP from broadcast to unicast.

Reference:
https://nexp.com.ua/technologies/rns/dhcp-snooping-and-option-82/



Comments

Post a Comment

Popular posts from this blog

ASA IKEv1 VPN troubleshooting Steps and Tips

-
  1. Phase I proposal mismatch  Run show crypto isakmp sa  Initiator: MM_WAIT_MSG2 Responder: No info  Most likely this is phase1 proposal mismatch, verify IKEv1 policy, other symptoms:   Initiator log: Information Exchange processing failed All configured IKE versions failed to establish the tunnel Initiator debug: Received an un-encrypted NO_PROPOSAL_CHOSEN notify message, dropping Responder log: Error processing payload: Payload ID Responder debug:  All SA proposals found unacceptable 2. IKE version mismatch:  Run  show crypto isakmp sa  no info at both initiator and responder Initiator log: Removing peer from correlator table failed, no match! Reason: User Requested  All configured IKE versions failed to establish the tunnel Initiator debug: Oakley begin quick mode PHASE 1 COMPLETED IKE Initiator sending 1st QM pkt Removing peer from correlator table failed, no match! Session is being torn down. Reason: User Requested Responder log: Tunnel Rejected: Conflicting protocols specified
Read more

Firepower 2100/1100 FTD/ASA initial setup, reimage, upgrade.

-
  Chassis FXOS and FTD share same management IP (default 192.168.45.45) Chassis FXOS (192.168.45.45) and ASA ()use different management IP although on same physical interface. SSH to FXOS/FTD are on FTD CLI prompt, go to FXOS using the  connect fxos  command Console to Chassis is on FXOS CLI prompt, go to FTD using the  connect ftd  command The Firepower 1100 does not support the FXOS Firepower Chassis Manager; only a limited CLI is supported for troubleshooting purposes. The Firepower 2100 runs an underlying operating system called the Firepower eXtensible Operating System (FXOS).  If you run ASA on Firepower 2100, ASA can be in the following modes: Appliance mode (the default after ASA 9.13)—Appliance mode lets you configure all settings in the ASA. Only advanced troubleshooting commands are available from the FXOS CLI. See the  FXOS troubleshooting guide  for more information. Firepower Chassis Manager is not supported . ciscoasa# connect fxos [admin] Connecting to fxos. Connected
Read more

Firepower FMC and FTD troubleshooting

-
 1. Display real time log on FMC or FTD: pigtail for example: pigtail | grep 192.168.2.20                      pigtail | grep sftunnel 2. Restart communication channel manage_procs.pl run it from  the sensor only, run it from FMC will reset all sensors' channel. This scripts are nice to be used when the FMC and FTD have communication problems like heartbeats are not received, policy deployment is failing or events are not received > expert ************************************************************** NOTICE - Shell access will be deprecated in future releases          and will be replaced with a separate expert mode CLI. ************************************************************** admin@FTD:~$ sudo su Password: root@FTD:/home/admin# manage_procs.pl ****************  Configuration Utility  **************  1   Reconfigure Correlator  2   Reconfigure and flush Correlator  3    Restart Comm. channel  4   Update routes  5   Reset all routes  6   Validate Network  0   Exit *****
Read more