I200x phones disconnecting randomly 5

[BCMAdminMTT]

Hi to all,

Has anyone experienced random disconnect problems when using Nortel i200x (2001-2002-2004) IP sets ? We have a BCM400 running version 4.0.2.21d (Fully patched). The problem appeared after migrating from version 3.6 to 4.0.2.21d. The switches we use are Cisco 3560.
Here is an example of a port configuration:
interface FastEthernet0/14
description Port IPtelephony (Nortel I2004) + PC
switchport trunk native vlan 561
switchport trunk allowed vlan 561,569
switchport mode trunk
switchport voice vlan 569
mls qos trust cos
spanning-tree portfast

All phones are at firmware level: 0604DAX. Also jitter buffer and Codec set to default (info from BCM Element manager). All phones are programmed using Nortel's recommended defaults IE: Full DHCP, QoS enabled, no LLPDs, no XAS, separate VLANs for voice and data, Speed and duplex are set to "0" (Auto). My second question is: Does anyone have the default configuration for these sets (Please don't reply with "0" as seen in other posts). If any additionnal info is required, I'll be more than happy to supply it. Thanks for your help.

 

[gm85]

Hi BCMAdminMTT,

If you are finding your IP phones are randomly restarting, this usually is a result of signaling packets being dropped on the network.

-How are you switches connected together? are the switch trunk ports congested?
-Do you have any phones attached to the same switch the BCM is attached to? are they restarting? (this can be one telltale indication because having a phone and BCM on the same switch only utilizes the switch's backplane).
-Try issuing a ping test between a phone and the BCM. What is the response time? do you have any lost packets? It can also be handy if another device on the 569 VLAN issues pings as you can have it initiate 1000 or so and see if there is any loss.

If it is found that you have congestion, then usually the best option is to add QoS to the catalyst switches (but lets see if we can determine the initial problem first).

 

[BCMAdminMTT]

Hi gm85,

First of all, thanks for your reply, it is much appreciated.

To answer your first question, all switches are connected to our corporate backbone. Here is an example of the way we connect to the BCM: IP Phone--->Cisco 3560--->Cisco 3550--->15 km Milan Fibre optics transceiver--->optical fibre--->15 km Milan Fibre optics transceiver--->Cisco 3550--->Cisco 3560--->BCM--->T-1. I guess you will note that the Communications server (IE: BCM) is located in another building to which we are connected by optical fibre.

To answer the second question, we have had a Bell Tech do a network analysis (He is Cisco Certified - what level I don't know), but according to him bandwith or congestion was not the problem. Your third question is very interesting. The answer is no, but I'll give it a try. Same goes for pinging the BCM from a phone and another node on VLAN 569. Many many thanks, these ideas of yours are truly appreciated. I'll follow-up on this post on Thursday am (Aug 7th) to give results and (probably) post more questions. TIA -- BCMAdminMtt

 

[SupportDude]

Do only the sets at the remote building reset?
Do the sets co-located with the BCM reset?

-SD-

http://www.mysupportguy.net

 

[BCMAdminMTT]

Hi SupportDude,

Once more, thanks very much for your time, help and response.

To answer your question:
The sets that are at the same site where the BCM400 resides are all "digital" sets IE: Meridian M7208, M7310. Because the site where the BCM400 is located is a police station, Québec government rules say that no IP sets are allowed on that site (for security reasons). None of these sets are affected by the problem. The problem only affects IP sets which are all located in the city's other buildings.

After gm85's post, I have tried the following: ping the server from my IP set. To do this I press the "services" key twice on a Nortel i2004 phone and I choose the Network Diagnostic Tools. The ping utility reports that all packets have been transmitted correctly with a round trip time of "0" ms... Packet loss = 0%.

When I look at "Ethernet Statistics", here is what I find (and it worries me !) When I look at CRCErrors the amount is 117105 (Packets ?). When I look at FrameErrors, I find 281069... Are these numbers somthing to worry about ?
What could they be indicating to me ?

Actually something tells me its an IP set programming issue.
Why ?? Because on some other phones the same utility gives me no CRC errors or Frame Errors... Hmmmmmm. I'll get back to this post later with more info. But if you have more questions, send them over to me. They help me dig into the system and the underlying infrastructure. For sure we'll get to the bottom of this problem and really solve it once and for all. Thanks again.

 

[MagnaRGP]

I'd suspect a duplex mismatch. Check that the switch ports are indeed set to AutoNeg like the phones.

Also check that the Autoneg was in fact successful. I have seen a litany of issues with Cisco switches failing to autoneg properly.

Maybe try hard coding one suspect phone and switch-port to see if it goes away. Also might want to review all your uplink ports as well.

 

[SupportDude]

I would suggest a stare and compare between a set that has to frame and CRC errors and one that does.
Frame errors could definitely account for the resets.
Are all the sets running the same version of firmware?

-SD-

http://www.mysupportguy.net

 

[BCMAdminMTT]

Hi Guys (SupportDude and MagnaGRP)

Thanks for your responses. I'll have to get my Bell Tech to come in and check out the auto-negociation parms on the Cisco switches. That might take a bit of time... (Almost everyone is on vacation). I will also ask him to set up ports (hard - 100 Mb - Full Duplex) for phones that encounter the problem. The one thing I know, is that all ports (on the switches)are set to auto-negociation for now.

To answer SupportDude's question: Yes - All sets are running firmware version: 0604DAX. No exceptions.

I forgot to mention... Not only do the phones disconnect once in a while but in some cases, they just re-boot or hang. This can happen while the phone is being used. I've seen some posts on this subject but none have been of any help. Not all phones behave in this manner. I'll focus on the ones that have the problem.

Would any of you guys have the config for i200x phones that are full DHCP, no LLDP, no EAP, no XAS, separate voice and data VLANs. Here are some parameters for which I have no clue to what I should set them up to. For instance: PSK SRTP ? (Phase Shift Keying - Secure Real Time Protocol ??) Yes or no ?, GARP Ignore (Yes or No?) PCUntagAll (Yes or No)? One last question (for today): Should the Cisco switches be running a specific version of the IOS ?

I'll follow-up on both of your suggestions (ASAP that is !!)

 

[SupportDude]

The Cisco shouldn't need a particular version of IOS.

Many of the options available in the IP setup are related to specific network devices. This is truly a task to keep up with it too. Each firmware release has some new option available.
When in doubt ... select no.
The best document I've found to describe the various options in the ip phone configuration is called "IP Phone Fundamentals". It's available for download on the Nortel site.

-SD-

http://www.mysupportguy.net

 

[BCMAdminMTT]

Unfortunately I went to Nortel's site and either I don't have access to documentation (we are like end users) or I didn't go to the right place. Can you supply me with an URL so I can fetch the documentation ? (Please !).

 

[gwebster]

http://www.nortel.com/cs1000

and then click on "Technical Documentation" on the left. Registration is required to access the documentation but there is no restriction on registering - i.e. it is open to end users.

 

[BCMAdminMTT]

Thanks Guys (SupportDude, Gwebster, and all the others that have so far contributed - I'm learning quite a lot here). I downloaded the document. Question (Before I start to read this "Brick") Is there a difference in IP phone (IE: i2001-i2002-i2004)configuration on a CS1000 and a BCM400 ?

 

[SupportDude]

Not from the viewpoint of registration configuration.

-SD-

http://www.mysupportguy.net

 

[rj2506]

Hi,

Just thought I would put my penny's worth in!!

I had the same problem last month. It turned out to be the customer was logging into the BCM400 through the same LAN port that the IP Phones were registered through. Now we've changed it so they log into LAN2 for management it is working 100%!

 

[endlesswinter]

is it possible for admin to congest a port to the point that ip phones will fail?

 

[BCMAdminMTT]

Finally, Thanks for all those who replied. Here is the latest information I have:
From Bell's standpoint a patch must be applied (Software Update Name: BCM.R400.SU.System.013-200808). It seems that this "patch" (117 MB of .rpm files) is actually a full blown *new* version of the software running on the BCM. I'll give more news when done. The problem we are now experiencing is in the uploading of the patches to the BCM400. Element manager supplies an interface for installing software updates, but with this patch it seems that you need a later version than the one the BCM offers to local administrators. This new version for a reason or another is necessary in order to proceed with patch installation. I also noted that this software update is very large and adresses multiple issues including some that are similar to what we have been experiencing with release 4.0.2.21d. Here is a short description of the maintenance release (copied / pasted from the readme.txt).

Software Update Name: BCM.R400.SU.System.013-200808
Applicable H/W Platforms: BCM200, BCM400, BCM1000, SRG200 1.5, SRG400 1.5

Applicable S/W Platforms: BCM 4.0, SRG 1.5 based on BCM 4.0
Category: GEN

Installation Recommendations:
This update should be applied to all new installs of BCM 4.0 and SRG 1.5 based on BCM 4.0. Existing installations should have this update applied if they are experiencing
any of the issues that are corrected. There is no need to schedule specific maintenance to apply this upgrade if there are no reported issues. In those cases, systems should be updated at the next regular service opportunity.
The latest Desktop Smart Update should be applied with this update if the affected desktop applications are used.


NOTE:
If the current version of Element Manager you are currently using is not 2.05 or greater, you must first apply BCM.R400.SU.Desktop.005-200801 or later. Then, install the new EM from the BCM on your PC before you can install this [ BCM.R400.SU.System.013-200808 ] update or any other updates. If BCM.R400.SU.Desktop.005-200801 or later has already been applied to the BCM and your current version of EM is 2.05 or greater you can proceed with normal update application.

 

[gberger]

Allways patch to the latest, in your case apply the SU desktop 8 and SU system 13.When installing SU13 you'll see two patches, install the first one, reboot then install the second one. Good luck!

 

[SupportDude]

Agreed ... patch updates are a must nowadays.
The latest SU Desktop should include the latest version of Element Manager.
Install the SU Desktop first, then download and install Element Manager from the BCM, then proceed with the rest of the patches.

-SD-

http://www.mysupportguy.net