cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4135
Views
7
Helpful
7
Replies

Cisco IP Phone CP-7937G not responding to DHCP offer

amm.jwalker
Level 1
Level 1

I've got a 7937G that worked beautifully with a Cisco IOS DHCP server and a Brocade/Foundry DHCP server, but has not responded to the first DHCP offer since moving to an ISC DHCP server.

Details:

  • all other phones (mix of 7911, 7941, 7961, 7962, etc.) on the same vlan are obtaining leases and working properly.
  • multiple physical connections have been attempted to include different ports and cables
  • phones are directly connected to a Brocade/Foundry FastIron SuperX (FSX) using dual-mode ports and LLDP-MED for voice vlan configuration
  • port connected to the 7937G is in "forwarding" state, negotiated at 100Mbit-FD, and there are no interface errors
  • routing interface on voice vlan (ip 10.1.150.1/24) is relaying DHCP to 2 DHCP servers (10.1.40.11, 10.1.40.12)
  • attempted a factory reset on the 7937G - no change
  • removed old lease attempts, restarted DHCPd multiple times - no change
  • ran "tcpdump" on both DHCP servers to watch traffic (excerpt below)
  • added "arp-cache-timeout" option (set to 60 seconds) after investigating traffic to make sure all requested DHCP options are provided - no change

tcpdump output:

13:01:10.017531 IP (tos 0x0, ttl 64, id 49197, offset 0, flags [none], proto UDP (17), length 352)

    10.1.40.1.0 > 10.1.40.12.bootps: [udp sum ok] BOOTP/DHCP, Request from 00:04:f2:e6:22:6a (oui Unknown), length 324, hops 1, xid 0x4582af64, secs 59662, Flags [Broadcast] (0x8000)

  Gateway-IP 10.1.150.1

  Client-Ethernet-Address 00:04:f2:e6:22:6a (oui Unknown)

  Vendor-rfc1048 Extensions

    Magic Cookie 0x63825363

    DHCP-Message Option 53, length 1: Discover

    Lease-Time Option 51, length 4: 4294967295

    Hostname Option 12, length 15: "SEP0004f2e6226a"

    Vendor-Class Option 60, length 37: "Cisco Systems, Inc. IP Phone CP-7937G"

    Client-ID Option 61, length 7: ether 00:04:f2:e6:22:6a

    Parameter-Request Option 55, length 7:

      Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name

      AT, TFTP, Option 150

    END Option 255, length 0

13:01:10.018031 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 352)

    10.1.40.12.bootps > 10.1.150.1.bootps: [bad udp cksum 0xd36c -> 0x872c!] BOOTP/DHCP, Reply, length 324, hops 1, xid 0x4582af64, secs 59662, Flags [Broadcast] (0x8000)

  Your-IP 10.1.150.135

  Server-IP 192.168.18.10

  Gateway-IP 10.1.150.1

  Client-Ethernet-Address 00:04:f2:e6:22:6a (oui Unknown)

  Vendor-rfc1048 Extensions

    Magic Cookie 0x63825363

    DHCP-Message Option 53, length 1: Offer

    Server-ID Option 54, length 4: 10.1.40.12

    Lease-Time Option 51, length 4: 3600

    Subnet-Mask Option 1, length 4: 255.255.255.0

    Default-Gateway Option 3, length 4: 10.1.150.1

    Domain-Name-Server Option 6, length 8: 10.1.40.5,10.1.40.6

    Domain-Name Option 15, length 23: "****************"

    TFTP Option 66, length 13: "192.168.18.10"

    T150 Option 150, length 4: 3232240138

    END Option 255, length 0

The offer is never "requested", and the phone continues to repeat the "discover" process. Any ideas?

7 Replies 7

Your DHCP server is receiving the request (Discover) and responding to it. You need to check whats happening at your router or switch levels.

"please rate useful posts"

amm.jwalker
Level 1
Level 1

Thanks for the replies. I did monitor udp traffic at the L3 switch and watched the traffic being relayed in both directions.

Also the udp checksum is just due to offloading - it's not actually bad. I verified this by monitoring other udp traffic at both end points.

Sent from Cisco Technical Support iPhone App

paolo bevilacqua
Hall of Fame
Hall of Fame

Seeing the low rating that my post (correct and made with the will to help) has received here, I have removed it. Thank you and good luck.

My apologies - I did not intend to offend or reflect on the accuracy of your post. I merely indicated whether the checksum issue had already been investigated so as to not mislead others. Sorry you feel that way.

Rob Huffman
Hall of Fame
Hall of Fame

Hi Jonathan,

Maybe you are seeing this "7937" bug;

CSCtf65642            Bug Details

7937 should support maximum size DHCP offer header
Symptom:
Cisco 7937 phone will ignore a DHCP Offer if it is above 576 bytes.

Conditions:
This  is typically seen on environments where the DHCP server violates RFC  2131 and goes over the DHCP options size, as well as does not honor the  Parameter Request List that the phone sends in the DHCP Discover.

Workaround:
Migrate  to a DHCP server that supports the Parameter Request List from the DHCP  Discover, or disable all options other than what Cisco IP phones  request in the PRL (1, 3, 6, 15, 35, 66, 150).
Status Status
Open             

Severity Severity
6 - enhancement

Last Modified Last Modified
In Last Year        

Product Product
Cisco Unified IP Phone 6900 Series

Cheers!

Rob

"Why not help one another on the way" - Bob Marley

Interesting! I'll dig into to this more thoroughly this evening. Thanks!

Rob Huffman
Hall of Fame
Hall of Fame

Hi Jonathan,

Please let us know how you make out with this.

Cheers!

Rob

"Why not help one another on the way" - Bob Marley