Cisco 7970 phone DHCP problem with Avaya phone options in scope

Answered Question
Aug 26th, 2010

Hi, All the Mighty Brains,

We are helping customer to move their infrastructure from a legacy backbone to a new one. We recently started to migrate a new building where both Avaya and Cisco VoIP exists. There are floors mixed phones are ised. In the legacy environment, customer has both DHCP options for Avaya and Cisco phones in the same DHCP scope to support all phones from the same VLAN/IP subnet, meaning all option 150, 176, and 242 are set up in the DHCP scope, and is working fine.

We just migrated one floor to the new backbone where TDM phones are used, but we need to test the DHCP template to make sure it supports both Avaya and Cisco phones in the new environment. The Access Layer switch is an in-place migration where it was connected to the new Distribution Layer switches. All ports where set up with proper data VLAN and voice VLAN. After the migration, Avaya phone works fine, but the Cisco phone does not work at this floor. We tried multiple phones with no luck. We tried new phone just got out of the box, and existing phones from other floors.

In the sniffer trace, We noticed that the phones kept broadcasting DHCP Discover packets, and the DHCP server did come back with DHCP Offer with all three options (150, 176, and 242), but the phones didn't seem to take the offer and just kept broadcasting DHCP Discover. We also saw in the DHCP debug mode that the DHCP Discover kept hitting the server, and the server kept senting off the Offer, but the phones just won't take it.

Then we tried to hardcode the network settings on the phone to make sure it can reach the TFTP server and rule out routing problem, then the phone works perfectly. So we are sure it's not routing issue. Then we took out option 176 and 242 from the DHCP scope, then the Cisco phone works properly with DHCP enabled. So, symptom-wise, it seems that the 7970 does not like the options for Avaya phone presented in the DHCP Offer. But why it's working in customers legacy environment? The only thing we can think of is, QIP is used for IP Management in the new environment, but not in the legacy environment.

Can anybody shed some light with us what might be the root cause of the problem? Thanks in advance for any help and suggestions.

Regards,

Vincent

I have this problem too.
0 votes
Correct Answer by Steven Holl about 3 years 7 months ago

Vincent,

I'm taking it you are using an Avaya DHCP server?  The Avaya DHCP server violates RFC 2131, ignores the parameter request list and sends options above the max size.  As a result, extra large option fields are sent down to the phone.  It's really an issue on the Avaya side, but we've fixed it on our side such that the phone ignores those options:

CSCsr25661

DHCP options exceed phone limits causing DHCP offer to be ignored

Fixed in 8.3.5 and 8.4.2.

There is a separate fix commit for the 7937:

CSCtf65642

7937 should support maximum size DHCP offer header

-Steve

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (2 ratings)
mail2vc@gmail.com Thu, 08/26/2010 - 07:59

Hi, Felipe,

Thanks for the prompt response. The phones are running SCCP70.8-3-3SR2S. Thanks.

Regards,

Vincent

Felipe Garrido Thu, 08/26/2010 - 10:01

What values do you set on the DHCP server for option 176 and 242? I can throw this in the lab and test real quick with newer firmware.

-Felipe

mail2vc@gmail.com Thu, 08/26/2010 - 10:28

Hi, Felipe,

Here are the values for the options. Sorry that I have to mask the domain name.

176="DOMAIN=ipt.xxxx.com,MCIPADD=gk-pnn,gk-tel,gk-222,gk-wfd,gk-hew,gkap-hew,gk-wfb,gk-623,gk-95g,gk-hud,gk-jax,MCPORT=1719,TFTPDIR=/amrs/222/group1/,TFTPSRVR=ftp,L2QVLAN=730,L2QTEST=60,L2Q=1"

242="DOMAIN=ipt.xxxx.com,MCIPADD=gk-pnn,gk-tel,gk-222,gk-wfd,gk-hew,gkap-hew,gk-wfb,gk-623,gk-95g,gk-hud,MCPORT=1719,HTTPDIR=/amrs/222/group1/,HTTPSRVR=http.ipt.xxxx.com,L2QVLAN=730,L2QTEST=60,L2Q=1"

BTW, for the firmware version:

Load File=SCCP70.8.3.4SR1S

App Load ID=jar70sccp.8-3-3-17.sbn

JVM Load ID=cvm70sccp.8-3-3-17.sbn

OS Load ID=cnu70.8.3-3-3-17.sbn

Boot Load ID=7970_020706_cert.bin

DSP Load ID=dsp70.8-3-3-17.sbn

to be exact. Thanks.

Regards,

Vicnent

Felipe Garrido Thu, 08/26/2010 - 14:16

Vincent,

I just tried it with 7970s running SCCP70.8-3-5S  and they registered with no noticeable delay. Can you try upgrading the phones to SCCP70.8-3-5S  or higher?

-Felipe

mail2vc@gmail.com Thu, 08/26/2010 - 15:12

Hi, Felipe,

Thanks for the quick test result. The problem is, this is the customer production environment and we cannot make any changes without going through proper Change Management processes. Another thing is, we don't have a firm case to pursuade the customer to upgrade because the same settings are working in their legacy environment.

Question: does 7970 mind if it receive DHCP Offer with options that it doesn't care? Will it consider a bad offer and discard the offer? I don't think it will be the case, but can't think of something else. Do you have your DHCP Server set up so that it will hand out DHCP Offer the same way regardless what options are included in the DHCP Discover from clients such as option 43 and 50? Thanks.

Regards,

Vincent

Correct Answer
Steven Holl Fri, 08/27/2010 - 06:53

Vincent,

I'm taking it you are using an Avaya DHCP server?  The Avaya DHCP server violates RFC 2131, ignores the parameter request list and sends options above the max size.  As a result, extra large option fields are sent down to the phone.  It's really an issue on the Avaya side, but we've fixed it on our side such that the phone ignores those options:

CSCsr25661

DHCP options exceed phone limits causing DHCP offer to be ignored

Fixed in 8.3.5 and 8.4.2.

There is a separate fix commit for the 7937:

CSCtf65642

7937 should support maximum size DHCP offer header

-Steve

mail2vc@gmail.com Fri, 08/27/2010 - 07:02

Hi, Steve,

That's a great news. We will look into those notes. Even though customer is using QIP instead of Avaya for DHCP Server, there are still possibilities the same issue exists. Usually how do you address this kind of problem? Will you try to use option 55 in the DHCP Discover sent by the phone and configure the DHCP Server to send Offer with only requested options? Thanks.

Regards,

Vincent

Steven Holl Fri, 08/27/2010 - 07:07

QIP is actually the DHCP server where I've seen this experienced on.

Your options are (in my opinion, ranked from easiest to hardest):

* Upgrade the IP phone firmware to a version with the fix for that bug.

* Segment your Cisco IP phones onto a broadcast domain that uses a DHCP server other than QIP.

* Find out how to get QIP to either honor the Parameter Request List which the phone sends to it, or find a way for QIP to only hand out options 1, 3, 6, 15, 35, 66, 150 to Cisco phones.

* Find out how to get QIP to not violate the option header size.

-Steve

mail2vc@gmail.com Fri, 08/27/2010 - 07:19

Hi, Steve,

That might be exactly what we are looking for. Thank you very much and Felipe's efforts.

Regards,

Vincent

Actions

Login or Register to take actions

This Discussion

Posted August 26, 2010 at 6:46 AM
Stats:
Replies:10 Avg. Rating:5
Views:1510 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard

Rank Username Points
1 21,026
2 15,047
3 10,314
4 7,999
5 4,856
Rank Username Points
159
95
75
66
55