01-13-2013 08:44 AM - edited 03-07-2019 11:04 AM
Hi,
I have configured DHCP snooping on a WS-3560G-48PS running IOS 12.2(58)SE2 ipservicesk9 variant.
When I enable DHCP snooping clients don't get IP addresses, when DHCP snooping is disabled, everything works fine.
In the debug output (client on g0/32, server on g0/48), I see
Jan 13 14:52:44.214: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/32 for pak. Was Vl1
Jan 13 14:52:44.214: DHCPSNOOP(hlfm_packet_filter_or_learn): packet with mac 00e0.1800.2e16 vlan 1 on interface Gi0/32 is not known by port security, dropped
Jan 13 14:52:48.216: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/32 for pak. Was Vl1
Jan 13 14:52:48.216: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Vl1 for pak. Was Gi0/32
Jan 13 14:52:48.216: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/32 for pak. Was Vl1
Jan 13 14:52:48.216: DHCP_SNOOPING: received new DHCP packet from input interface (GigabitEthernet0/32)
Jan 13 14:52:48.224: DHCP_SNOOPING: process new DHCP packet, message type: DHCPDISCOVER, input interface: Gi0/32, MAC da: ffff.ffff.ffff, MAC sa: 00e0.1800.2e16, 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: 00e0.1800.2e16
Jan 13 14:52:48.224: DHCP_SNOOPING: add relay information option.
Jan 13 14:52:48.224: DHCP_SNOOPING_SW: Encoding opt82 CID in vlan-mod-port format
Jan 13 14:52:48.224: DHCP_SNOOPING_SW: Encoding opt82 RID in MAC address format
Jan 13 14:52:48.224: DHCP_SNOOPING: binary dump of relay info option, length: 20 data:
0x52 0x12 0x1 0x6 0x0 0x4 0x0 0x1 0x1 0x20 0x2 0x8 0x0 0x6 0x2C 0x36 0xF8 0xCB 0x30 0x0
Jan 13 14:52:48.224: DHCP_SNOOPING_SW: bridge packet get invalid mat entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (1)
Jan 13 14:52:48.224: DHCP_SNOOPING_SW: bridge packet send packet to cpu port: Vlan1.
Jan 13 14:52:48.232: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/48 for pak. Was Vl1
Jan 13 14:52:48.232: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Vl1 for pak. Was Gi0/48
Jan 13 14:52:48.232: DHCPSNOOP(hlfm_set_if_input): Setting if_input to Gi0/48 for pak. Was Vl1
Jan 13 14:52:48.232: DHCP_SNOOPING: received new DHCP packet from input interface (GigabitEthernet0/48)
Jan 13 14:52:48.232: DHCP_SNOOPING: invalid DHCP options - unable to parse
After that it's just repeating over and over. Disabling option 82 as suggested in this thread https://supportforums.cisco.com/thread/2114301 does not help.
I have set up a SPAN port and run a capture (attached) on the traffic. Wireshark notes the Seconds elapsed field appeared to be encoded in little-endian but only on some packets. Apart from that, I can see nothing wrong with the DHCP Offer responses from my DHCP server.
Attachment config.txt contains the interesting parts of the configuration. Please note g0/32 has been set to ARP inspection trust as without working DHCP snooping it would require a static bind.
Is there any way of figuring out which option can't be parsed? Is there a way to force forwarding of unparsable DHCP packets while still running DHCP snooping?
Big thanks in advance.
Solved! Go to Solution.
01-13-2013 10:05 AM
Hello Bodo,
I see one irregularity in the captured DHCP Offer messages. In these responses from the DHCP server, there is the DHCP Option 47 present - NetBIOS over TCP/IP Scope - whose length is 0. Effectively, the body of this DHCP option is empty. However, RFC 2132 mandates that the minimum length of this option is 1. Perhaps this is what the DHCP Snooping balks at.
Can you check the configuration of your DHCP server for the Option 47 and perhaps correct it or remove it from assignment altogether? As I do not believe you are running NetBIOS over TCP/IP, this option is useless anyway.
And, oh - do not disable Option-82 unless strongly necessary. See the following two threads for more info:
https://supportforums.cisco.com/thread/2060498
https://supportforums.cisco.com/message/3825001#3825001
Best regards,
Peter
01-13-2013 10:05 AM
Hello Bodo,
I see one irregularity in the captured DHCP Offer messages. In these responses from the DHCP server, there is the DHCP Option 47 present - NetBIOS over TCP/IP Scope - whose length is 0. Effectively, the body of this DHCP option is empty. However, RFC 2132 mandates that the minimum length of this option is 1. Perhaps this is what the DHCP Snooping balks at.
Can you check the configuration of your DHCP server for the Option 47 and perhaps correct it or remove it from assignment altogether? As I do not believe you are running NetBIOS over TCP/IP, this option is useless anyway.
And, oh - do not disable Option-82 unless strongly necessary. See the following two threads for more info:
https://supportforums.cisco.com/thread/2060498
https://supportforums.cisco.com/message/3825001#3825001
Best regards,
Peter
01-13-2013 02:10 PM
Hi Peter,
that empty option escaped me. I believe this and the other NetBIOS options were needed by some Windows systems to be able to find a Samba server in a different subnet. It's probably not needed anymore.
I removed the empty option 47 and everything's working now:
cs1#sh ip dhcp snooping binding
MacAddress IpAddress Lease(sec) Type VLAN Interface
------------------ --------------- ---------- ------------- ---- --------------------
00:E0:18:00:2E:16 192.168.225.4 86082 dhcp-snooping 1 GigabitEthernet0/32
Total number of bindings: 1
Thanks.
01-13-2013 02:18 PM
Hi Bodo,
I am glad you were able to get the DHCP Snooping to work!
Regarding the Option 47, it particularly described a NetBIOS Scope - something, I believe, not really related to locating a Samba in a different subnet. In fact, if my memory serves, to find a server in a different subnet, you needed to use the WINS service. The WINS server was identified in a different option 44. I have run some Win95/98/XP-based networks that used Samba as their domain controller, and I never used the NetBIOS scoping (in fact, I do not even know exactly what that is).
Anyway, it's good to know you got it working!
Best regards,
Peter
06-05-2019 07:29 AM - edited 06-05-2019 11:59 AM
Question modified today.
Issue solved after reading the http://www.faqs.org/rfcs/rfc1533.html, removing the incorrect option 43 configured on DHCP and still able to provide individual Option 43 to each model of AP.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide