1

I recently troubleshooted a network where the switch had DHCP snooping turned on and even though the router which was acting as a DHCP server was connected to a trusted port, the client wasn't able to get an IP address.

Upon further packet analysis and debugging both the switch and the router, I found something peculiar:

On the switch:

sw1#debug ip dhcp snooping packet
DHCP Snooping Packet debugging is on
sw1#
*Jan  9 10:17:29.337: DHCP_SNOOPING: received new DHCP packet from input interface (GigabitEthernet0/0)
*Jan  9 10:17:29.340: DHCP_SNOOPING: process new DHCP packet, message type: DHCPDISCOVER, input interface: Gi0/0, MAC da: ffff.ffff.ffff, MAC sa: 0050.7966.6800, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 0050.7966.6800
*Jan  9 10:17:29.340: DHCP_SNOOPING: message type : DHCPDISCOVER DHCP ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP giaddr: 0.0.0.0, DHCP chaddr: 0050.7966.6800
*Jan  9 10:17:29.341: DHCP_SNOOPING: add relay information option.
*Jan  9 10:17:29.341: DHCP_SNOOPING_SW: encoding opt82 cid in vlan-mod-port format
*Jan  9 10:17:29.342: DHCP_SNOOPING_SW: Encoding opt82 RID in MAC address format
*Jan  9 10:17:29.342: DHCP_SNOOPING: binary dump of relay info option, length: 20 data:
*Jan  9 10:17:29.343: 0x52 
*Jan  9 10:17:29.343: 0x12 
*Jan  9 10:17:29.344: 0x1 
*Jan  9 10:17:29.344: 0x6 
*Jan  9 10:17:29.345: 0x0 
*Jan  9 10:17:29.345: 0x4 
*Jan  9 10:17:29.346: 0x0 
*Jan  9 10:17:29.346: 0x1 
*Jan  9 10:17:29.347: 0x0 
*Jan  9 10:17:29.347: 0x0 
*Jan  9 10:17:29.347: 0x2 
*Jan  9 10:17:29.348: 0x8 
*Jan  9 10:17:29.348: 0x0 
*Jan  9 10:17:29.349: 0x6 
*Jan  9 10:17:29.349: 0xC 
sw1#
*Jan  9 10:17:29.350: 0x27 
*Jan  9 10:17:29.350: 0xBB 
*Jan  9 10:17:29.351: 0x0 
*Jan  9 10:17:29.351: 0x9F 
*Jan  9 10:17:29.352: 0x0 
*Jan  9 10:17:29.353: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (1)
*Jan  9 10:17:29.353: DHCP_SNOOPING_SW: bridge packet send packet to port: GigabitEthernet0/1, vlan 1.

On the Router/DHCP Server:

DHCP#debug ip dhcp server packet
DHCP server packet debugging is on.
DHCP#
*Jan  9 10:17:50.919: DHCPD: inconsistent relay information.
*Jan  9 10:17:50.921: DHCPD: relay information option exists, but giaddr is zero.

After even more digging, I find out that:

Notice that by default Cisco IOS devices reject packets with zero “giaddr” and by default Cisco Catalyst switches use “giaddr” of zero when configured for DHCP snooping! (Source)

Now I don't know much about the giaddr field and understand that the DHCP server is supposed to send the offer to the giaddr address and not the address from which it receives the request.

So, my question is, why does Cisco's switches turn giaddr to all-zeroes when sending the packet to the DHCP server when DHCP snooping is enabled?

2
  • 1
    Please post the configuration of your switch.
    – user36472
    Commented Jan 9, 2019 at 11:02
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer.
    – Ron Maupin
    Commented Dec 14, 2019 at 18:17

2 Answers 2

4

It's not technically setting giaddr to anything. The original request had the field empty and the switch isn't changing it, because it isn't an actual dhcp-relay. The problem is the switch adding option 82, which the IOS dhcpd then doesn't like. Turn off option 82 [ no ip dhcp snooping information option ] and your problem should go away. IOS isn't doing anything with that information anyway.

(ip dhcp snooping glean would also be an option -- read only snooping)

0

I hope you're doing well. I wanted to share a great resource with you. Peter Paluch wrote an incredible post that has all the information you might need. It's really fantastic! Here's the link for you to check it out: https://community.cisco.com/t5/switching/dhcp-snooping/m-p/1622878#M164843

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.