Mitel Forums - The Unofficial Source
Mitel Forums => Mitel MiVoice Business/MCD/3300 => Topic started by: ccuster on January 10, 2013, 10:41:47 AM
-
I have 6 sets/DNs on a 3300ICP (running MCD 5.0) of around 70 phones. these same 6 sets inexplicably reset themselves then come back up asking for a PIN - user registers the phone; as well, if the user merely resets the phone again, it comes back up with there extension as though nothing was wrong and it is fine for a day or two.
It is always the same DNs! we have replaced the sets, removed and recreated the user profiles/DNs and switched the switch ports - all other phones on the 3300 are unaffected.
-
have you tried switching an affected DN to a non affected phone.....?(so do a swap between two sets; one thats ok and on ethat has the trouble)
-
Do you have a resilient controller programmed for them?
-
have you tried switching an affected DN to a non affected phone.....?(so do a swap between two sets; one thats ok and on ethat has the trouble)
we have replace with new sets but never w/ sets that are already in use
-
Do you have a resilient controller programmed for them?
none of the sets are resilient
-
I'm with Mattmayn on this one.
If you have a resilient controller in the network it could do this even if the phones are not programmed to be resilient.
Odds are pretty good that the phones are trying to go resilient and hitting another controller that the phones are programmed on. This will cause the phones to say "enter pin".
Check your DHCP options for those phones to see if you have more than one controller programmed.
Ralph
-
Sorry, something I neglected to mention. The system ran flawlessly for a year. Installed and added to cluster w/ 4.1 upgraded when 4.2 released and the problem started within days of 5.0 upgrade.
-
If you go into the config mode of the actual phone do they have an ICP 2 IP listed?
I had a phone in our office that did that once. It thought it was supposed to failover to a secondary controller even though ESM didn't show it. I didn't want to mess with it so I put a static entry into that phone for ICP 1 and went with it.
-
You mention a cluster so it sounds like their is another system that they could try to register with if they were resilient. What options are in your DHCP for Option 125 i.e are more then one RTC defined. It sounds like the phones lose connection to their MCD and reboot. At that point they can only find some other controller where they attempt to register. The hard reset allows them to find the primary again. Are you using the double fetch method of DHCP by any chance.
-
Are you using the double fetch method of DHCP by any chance.
LoopyLou,
Glad to see you jumping in. I know you bring a lot to the party. :)
What is a "double fetch" method?
Ralph
-
Double fetch is what I call it when the layer 2 switches are not using either LLDP or CDP to give the phones their VLAN info on boot. With double fetch the phones are seen as any other data device. They then go to the data VLAN DHCP server again like any other device. In the data VLAN DHCP server there are options setup that mean something to the phones ( Option 125 or the combination of older options like 130,132 etc ). Anyway the phone gets the options which give it the voice VLAN number and at this point the phone drops the data VLAN IP resets and issues another DHCP request on the voice VLAN.
The method I prefer is using CDP on Cisco L2 or LLDP on HP L2 switches to give the phone its voice VLAN number up front. Also I use the 3300 for phone DHCP. The set then only has to issue its DHCP request once because its directly on the voice VLAN and the 3300 can act as the DHCP server.
Either method works just fine.
-
We deliver DHCP from the 3300 and use HP L2 w/ LLDP
Tagged for voice untagged for date
-
These are the only sets on the layer 2?
-
You may have to wireshark that port as the phone boots.
Paste it here and we can take a look at it.
Ralph
-
I am just arranging to have a LT setup on the switch that these sets are connected to (system in another location). In the mean time however, i have had a developement. one of our techs at the site in question was registering a couple of new sets for me from his desk last week. he unplugged his phone, plugged the new ones in and registered them from his connection. he then plugged his phone back in.
ever since then, his phone too has been doing the same thing. reseting over the course of a night and comming back asking for PIN. if he reboots it a second time, it comes back with his extension as though nothing was wrong.
-
Is the system it's registered to rebooting over night?
Ralph
-
Just trying to gather some info and it's a long shot if you can't browse through the system to check default values, but is there something to be found in the 3300 logs as to what time they (I assume) drop out and ask for pin?
Are your general Cluster settings and ICP/PBX Networking settings correct under Trunks -> IP/XNET? e.g IP's matching the ICP number on all cluster nodes. I have once seen weird things happen due to the fact info was entered incorrect there during a migration to a cluster.
Dutch
-
What is in your Option 125?
What is the length of time before a set needs to renew its IP?
-
Is the system it's registered to rebooting over night?
Ralph
No. the system stays up overnight. and unfortunately the phones in question decided NOT to reset last night so we have no data from wireshark. we are going to leave wireshark running for the next couple of nights to try and catch one of the resets
-
So can you tell us what you have set in Option 125 please.
-
Problem resolved.
it was a conflicting (old voice vlan) VLANs on the same switches - I do not have the details as our network team resolved by retiring an old unused subnet and the old voice vlan associated w/ it.
???