We have an issue with a MItel phone system and using DHCP relay on our Cisco WAN routers. We are using a Windows DHCP server to populate option 125 that the phone uses to get configuration information. Our old setup uses a Cisco 2811 on 12.4 code and it passes the information fine between the Windows DHCP server at our main location and the remote office LAN by using the ip-helper commands. The 2901 on the other hand is messing with the reply from the DHCP server. Debug presents us with this little nugget.
DHCPD: Invalid option 125 information. Dropping DHCP message
The 2901 is running 15.1 code. Does anyone have any idea why the 2901 would be messing with the DHCP messages? It appears to forward the DHCPDiscover just fine but when the server replies the router thinks it needs to insert itself in there and mess with the reply messages. Thus the phones do not work.
I'm at a bit of a loss. I found a couple posts on google but they were in German and Google Translate failed to make enough sense of the posts for me to extract any useful information.
Thank you in advance!
I have seen the same error message on a Cisco 887VA I was preparing for a customer 10 days ago, but I didn't investigate further because it was not of interest for me.
If you like you can post the relevant configuration and the error log messages.
It is a valuable information to know that this something related to new code in 15,1
Hope to help
My coworker Arrie discovered this document that led to the resolution. Evidently it appears that ios prior to version 15 doesn't do any format enforcement so an improperly formated option was passed. As long as the dhcp client could figure it out noone was the wiser. IOS version 15 seems to be doing format checking on dhcp relay and strips the options if they do not adhere.
In addition to the Mitel 125 DHCP Helper tool, there is one caveat with it. I tried using the exact hex string that it produced in 2 separate DHCP servers (Windows and Infoblox) and still received the "Invalid option 125 information. Dropping DHCP message". After working with Cisco TAC, the HEX byte that appears after the vendor ID "00 00 04 03" should be a calculation of the remaining bytes, but the tool provides an incorrect value.
For example, the following text string
converts to hex as follows:
00 00 04 03 5C 69 64 3A 69 70 70 68 6F 6E 65 2E
6D 69 74 65 6C 2E 63 6F 6D 3B 73 77 5F 74 66 74
70 3D 31 39 32 2E 31 36 38 2E 31 2E 35 3B 63 61
6C 6C 5F 73 72 76 3D 31 39 32 2E 31 36 38 2E 31
2E 35 3B 64 73 63 70 3D 34 36 3B 69 70 61 5F 73
72 76 3D 31 39 32 2E 31 36 38 2E 31 2E 35
As you can see, the value 5C was produced. The true value should be 59. If you count all the characters in the text string, there are 89 characters (or 59 in HEX). That is the value that Cisco is identifying as invalid. Once I corrected the string, I was able to pass DHCP replies through the router.