phone boot up problem

[rvincent]

Hi

I'm doing a new phone deployment with call mgr 4.0. I have a bunch a phones that will not boot up. After trying to load the sep file for some 5 minutes, they stop and the display says "protocol application invalid".

Has anyone seen this ? Could these be sip phones?

thanks

Rob

[lfulgenzi]

A search on the Cisco website shows:

http://www.cisco.com/en/US/products/sw/voicesw/ps4967/products_upgrade_guides09186a008022a968.html

Cisco 7940 and 7960 IP Phones Firmware Upgrade Matrix

http://www.cisco.com/en/US/products/sw/voicesw/ps4967/products_upgrade_guides09186a008022a968.html#wp1054408

Common Error Messages

Protocol Application Invalid

This error message means that the application image cannot be loaded into flash memory or that the image does not exist in flash memory. This can happen for the following reasons:

•The zip package was not unzipped in the root TFTP directory.

•Files were copied to the TFTP server instead of using the zip package.

•The universal application loader was unable to load a new application image into flash memory (image authentication failure, nonexistent image, TFTP errors, and so forth).

Another hit showed similar results:

http://www.cisco.com/en/US/tech/tk652/tk701/technologies_tech_note09186a0080094584.shtml#issue3a

[rvincent]

Problem turns out to be some sort of bug with the phone tftp'g its config through the trunk port. The phone ports were configured with aux vlan 80 and could not load the config.

workaround is to remove the aux vlan and put the port into vlan 80. After the phone gets its config file, put the port back into aux vlan 80. Once the phone has its config it works normally in the aux vlan.

TAC did not mention any bug when they tried to resolve this so I'm not sure if its documented. I've sent this to my TAC engineer.

[jgentsch]

Here is the bug ID CSCef75275. However, I do not see it as fixed in version 7.1.1.

[rvincent]

our bug turned out to be the 6548 module - bug CSCeb67650.

Packets destined out the WS-X6548-GE-TX or the WS-X6148-GE-TX that are less than 64 bytes will be dropped. This can occur when a device forwards a packet that is 60 bytes and the 4 byte dot1q tag is to added to create a valid 64 byte packet. When the tag is removed the packet is 60 bytes. If the destination is out a port on the WS-X6548-GE-TX or the WS-X6148-GE-TX it will be dropped by the linecard.

Additionally, if packets are received on an interface that does not have a minimum MTU of 64 bytes (e.g. ATM,POS) and are destined out the WS-X6548-GE-TX or the WS-X6148-GE-TX it will be dropped by the linecard.

needed to swap the module with a newer rev module

Rob

[Erick Bergquist]

Rob,

Why did you have to swap the module and not use newer software with fixes?

I am having this problem at customer with 6148-GE-TX on 8.1(2) code which is 1 rev newer then bugfix was resolved mayybe from reading the bug release.

The hardware rev of the 6148 is 2.0 and firmware rev is 7.2(1). The MSFC is also at a earlier IOS release then bug fix but do we need MSFC on newer for this?

Thanks for posting this info. This may be the magic bullet I need to convince them to upgrade their switches/MSFCs. But wondering why you needed a newer revision module...

thanks.

[rvincent]

the bug was fixed in a later firmware version and so I had to replace the module with the later version to fix the problem

Rob

[Erick Bergquist]

That was for the 6548. Hmm.

Did TAC know the buggy firmware versions? Debating on upgrading first and see what happens or see what TAC has to say.

Our problem is that phoneload TFTP upgrades to newer/other versions fail when port is configured as dot1q trunk or has aux vlan set. If it is a plain access port in voice vlan the upgrade/downgrade to other image works.

Besides the TFTP issue, all other traffic appears to work fine.

[rvincent]

check bug CSCeb67650 on cisco's web site. It will describe the details

[Erick Bergquist]

I have checked the bug. The versions fixed in don't state if it is CatOS or actually hardware firmware versions which would need replacement of module.

Thats what I was trying to clarify with you, since you swapped out the module. The bug notes don't mention replacing hardware at all.

[rvincent]

this is the link to the field notice:

http://www.cisco.com/en/US/customer/products/hw/switches/ps700/products_field_notice09186a0080228f16.shtml

[Erick Bergquist]

Thank you! We have serial #s in that range.

[Chris Drew]

The is happening to me too. I havnet figured how to correct it. If you find out please let me know.

Chris

[milay]

CSCef75275 is resolved in the 7.1.1 load however it has been defered. You should load the 7.1.2 and it resolves the deferd issues in 7.1.1.

Also you may need to do the work around of setting the access v-lan to the voice vlan and removing trunking one last time. But the problem should be gone after that.

Mike

[adignan]

Adding option 66 to the voice vlan dhcp scope and putting in the tftp address for the string value fixes this as well.