cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3992
Views
0
Helpful
4
Replies

DHCP_SNOOPING: invalid DHCP options - unable to parse

Bodo Bellut
Level 1
Level 1

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.

1 Accepted Solution

Accepted Solutions

Peter Paluch
Cisco Employee
Cisco Employee

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

View solution in original post

4 Replies 4

Peter Paluch
Cisco Employee
Cisco Employee

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

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.

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

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.

Review Cisco Networking for a $25 gift card