806 and PIX 501 unable to negotion IP from ISP's DHCP

[scott]

I have an 806 Router with IOS 12.2.1 (XE) and a PIX 501 with IOS 6.1(1). Both have the same problem: They cannot obtain an IP address on the WAN interface from my ISP's DHCP server.

I have VDSL from Qwest (rare, I know -- but that's what it is) and it does not use PPoE. I am allowed a minimum of four IP address at a time with 7 day leases on this service. I've never actually been denied an address with multiple machines brought up for experiments.

Windows Millenium, 2000, and XP using a variety of NIC's with nothing but the default TCP/IP settings for obtaining IP automatically do negotiate an IP address. Essentially, you plug any TCP/IP client into a hub or switch coming from the "cable modem" and they work just as if they were clients on an Ethernet LAN.

Both a Linksys BEFSR41 and D-Link DI-704P broadband router with nothing but their default, out-of-box configuration, successfully negotiate an IP from the ISP.

In my home lab, the 806 and PIX do negotiate an IP from a Windows 2000 or Windows NT server with a default DHCP server configured.

I've used Fluke's Protocol Inspector to monitor the conversations. When the PIX or 806 are brought up they each send eight DHCP discover packets, none of which are ever acknowledged by the ISP's DHCP server. When all other devices mentioned above are connected to the ISP and brought online the DHCP process goes "textbook" perfect with DISCOVER, OFFER, etc., etc.

I'm not real strong on IP packet structures, but I've attempted to analyze the differences between the several DHCP discover packets. There's a fair variety but the only consistent difference I can spot is that both the 806 and the PIX have the DHCP Broadcast Flag set to "1". All the other devices mentioned have that DHCP field set to "0."

All the Microsoft clients advertise their class_identifier (MSFT 98 or MSFT 5.0). The D-Link router advertises its class_identifier as MSFT 98 class. The Linksys does not advertise a class_identifier. The 806 advertises its class_id as docsis1.0. The PIX does not advertise its class_id.

I have all the DHCP discover packets saved as text files if anyone has any expertise/ideas and is willing to look at them.

Thanks,

Scott Hauert

CCNA, MCSE

[ciscomoderator]

Since there has been no response to your post, it appears to be either too complex or too rare an issue for other forum members to assist you. If you don't get a suitable response to your post, you may wish to review our resources at the online Technical Assistance Center (http://www.cisco.com/tac) or speak with a TAC engineer. You can open a TAC case online at http://www.cisco.com/tac/caseopen

If anyone else in the forum has some advice, please reply to this thread.

Thank you for posting.

[mvanterve]

Hi,

I discovered the same problem with a 1605 router.

You need a special interim release from TAC.

Regards,

Mario

[scott]

Thanks, Mario.

I ended up opening a case with TAC and that is indeed what they ultimately suggested. I did obtain the interim release but it did not resolve the problem. They still believe it to be a issue with IOS and are still working to resolve it with the DEs.

Regards,

Scott

[reswaran]

Hi,

The DHCP Server might be supporting DHCP Option 12 i.e., they might expect a hostname from the DHCP Client. The command is "ip address dhcp hostname client-id eth1".

Or you can user the built in web-based tool CRWS in C806 to configure your router.

regards,

Ravikumar