web statisticsweb stats Business Phone Systems Tech Talk Forum - VOIP & Cloud Phone Help

Business Phone Systems

Previous Thread
Next Thread
Print Thread
Rate Thread
Page 1 of 3 1 2 3
#560360 10/24/13 11:42 PM
Joined: Oct 2013
Posts: 30
JPfahl Offline OP
Member
OP Offline
Member
Joined: Oct 2013
Posts: 30
I have an IWATSu ICON phone system. 130 phones in a k-12 environment. Phones are in vlan 5 in the 10.77.80.0/23 network and data in the default vlan in the 10.77.64.0/23 network. DHCP is controlled/provided at the State level. They have option 43 on the root scope to tell the phones to go to vlan 5 and 10.77.80.5 as the gateway to the Phone Switch. I have changed the mbu, the csu and one other card I dont remember the name of to no avail. PROBLEM: Every morning the phones reset 5 times each between 8am-10am. The rest of the day they are fine. Nothing outrageous on the error log other than the resets.

The wireshark on the mbu however indicates IP addresses from the 10.0.7.0 network. The mac addresses for the 10.0.7.0 in the wireshark are associated with an IWATSU phone. The mac addresses do not show up however in any of my switches. It seems that the phones are holding the 10.77.80.x address and it seems that the phone system is pushing the 10.0.7.0 addresses as well. Is this causing the confusion?

Is there somewhere that the phone switch can hold on to a previous IP scheme and it is mixing it up with my new scheme? Where is the 10.0.7.0 coming from? I have poured over the icon program and cannot find the 10.0.7.0 in the program.

Atcom VoIP Phones
VoIP Demo

Best VoIP Phones Canada


Visit Atcom to get started with your new business VoIP phone system ASAP
Turn up is quick, painless, and can often be done same day.
Let us show you how to do VoIP right, resulting in crystal clear call quality and easy-to-use features that make everyone happy!
Proudly serving Canada from coast to coast.

JPfahl #560406 10/25/13 06:01 PM
Joined: Aug 2006
Posts: 1,795
Likes: 10
Moderator-Iwatsu
*****
Offline
Moderator-Iwatsu
*****
Joined: Aug 2006
Posts: 1,795
Likes: 10
I had the very same issue in a school environment. It was a network issue, but it wasn't set up with a VLAN. The phone system resided on its own subnet. In cases where the phone had to operate as a Layer 2 switch, a VLAN was created that the phone was tagged for, but not the rest of the system, and it works fine. Do you have VLAN tagging set up in MBU programming?

In the ICON programmer, under Communications, go to error logs and select all in the pop-up window. When it completes save the file somewhere you can easily find it. Go to Tools>IPKT reboot diagnostics, use the error log file you just downloaded for a list of all sets that have rebooted. You may get a clue as to why it's happening.

Also under Tools, if you're onsite, disconnect from the system and close your system data base. Click on SNMP diagnostics, check the LAN2 IP address and the window will populate with buttons for the ARP table, IPKT ports and other info showing connected IP addresses and more clues as to what is going on. The IPKT ports button will show every IP phone you have connected with IP and MAC. You have to select eacj IPKT for more fill-in info. It takes a few minutes to fully load , but it is well worth it. You can merge your system data base with this list to match extension/name with an IP and MAC, then export the file so you have a full listing of extsion,name, IP and MAC. Handy to have.

My similar issue was a network issue that the customer's IT department ultimately fixed. You may have to assign static IPs to all your phones to avoid using an IP address from the other VLAN. The IPKT port tables will show you how each phone is connected, the IP address it's using,whether it is static or DHCP and other configuration info that may help you out. The network guys are going to suggest firmware upgrades for the KSU, firmware upgrades for the phones and all manner of things not in their network, but the sticking point is absolutely a network issue.

Good luck with this, let us know how you make out.


Sometimes the thoughts in my head get so bored, they go for a stroll through my mouth. This is rarely a good thing.
JPfahl #560411 10/25/13 07:58 PM
Joined: Oct 2013
Posts: 30
JPfahl Offline OP
Member
OP Offline
Member
Joined: Oct 2013
Posts: 30
Is it that realistic though that 130 phones have to be statically set? That is a lot of phones to set. I will follow your suggestions and see how we make out. Do you think that setting to default and reloading the database could clear the issue? The MBU settings say no tagging and to vlan identified. The phone port however in the switch is untagged for vlan 5. We added the tagging and vlan 5 on the mbu and made the same adjustment on the switch port where the phone plugs in and that cut the tcp link. So we switched it back. Having marked as no tagging and no vlan is how our vendor sets up all his clients, so i am curious how this will pan out.

JPfahl #560421 10/26/13 11:29 AM
Joined: Aug 2006
Posts: 1,795
Likes: 10
Moderator-Iwatsu
*****
Offline
Moderator-Iwatsu
*****
Joined: Aug 2006
Posts: 1,795
Likes: 10
I would think the switch port that the phone system is connected to should also be tagged for the VLAN. Consider: The phone system LAN2 address is used to control the operation of the IP phone using port 50000. This is what keeps the phone connected to the system. A loss of that connection will force a phone to reboot to reacquire that connection. Also, look at the time frame when this is occurring. From 8 to 10 AM is when everyone is getting to school, firing up their computers to check email, get lesson plans, etc. Lots of network traffic to impede the phone connections to the KSU.

I have another school using nearly 100 IP phones with a VLAN. The phone system LAN2, MBU and all phones are tagged in programming for the VLAN, and the VLAN is based on Iwatsu MAC numbers to disallow other devices- this issues doesn't occur at all.

You can use Tools>IP Configurator to program each IP phone if you know the IP address of the phone, or , you can open a browser at the phone IP and configure it that way. Using static IPs will remove the problem of someone plugging in something they shouldn't and 'stealing' an IP address that belongs to a phone. You have a K-12 environment, so it's a good bet this kind of thing has been going on for a while.


Sometimes the thoughts in my head get so bored, they go for a stroll through my mouth. This is rarely a good thing.
Joined: Aug 2006
Posts: 1,795
Likes: 10
Moderator-Iwatsu
*****
Offline
Moderator-Iwatsu
*****
Joined: Aug 2006
Posts: 1,795
Likes: 10
What is the IP address/subnet/gateway for:

LAN2

MBU

Stations>IP Staion Settings> Public IP address (address only)

I ask only because 10.0.7.0 sounds alot like a default IP address somewhere.

What sort of voice mail system do you have , if any?


Sometimes the thoughts in my head get so bored, they go for a stroll through my mouth. This is rarely a good thing.
Joined: Oct 2013
Posts: 30
JPfahl Offline OP
Member
OP Offline
Member
Joined: Oct 2013
Posts: 30
MBU is 10.77.80.5. That is on a vlan coming from the state. CCSU is on 80.6. It seems according to the wireshark that the phones are passing the 10.0 network around to eachother. THe router is not passing the 10.0 network traffic at all. We just defaulted the system and reuploaded the database. Now the omega voicemail is answering as busy. We also lost our voice light on the adtran and are not able to call in or out. Internal calls go unanswered. So now it seems that the default changed something and stopped everything from working. 10.0 is not on our network that i can tell.

JPfahl #560445 10/27/13 10:43 AM
Joined: Aug 2006
Posts: 1,795
Likes: 10
Moderator-Iwatsu
*****
Offline
Moderator-Iwatsu
*****
Joined: Aug 2006
Posts: 1,795
Likes: 10
Are the phones on the 80.xx subnet?

When you defaulted and reloaded, did you reinstall licenses?

Is remote access set up for this system?

Have you always had this reboot issue, or is it something that has happened recently?

Ask the state what they've done to the network lately in the way of patches, updates, etc. This is a network/routing issue, something needs to properly configured.


Last edited by JBean3329; 10/27/13 10:46 AM.

Sometimes the thoughts in my head get so bored, they go for a stroll through my mouth. This is rarely a good thing.
Joined: Oct 2013
Posts: 30
JPfahl Offline OP
Member
OP Offline
Member
Joined: Oct 2013
Posts: 30
The "State" always comes back and says that they have not changed anything. They have two servers that provide addressing for every state entity. having said that... the mac address was mistyped for the mbu. So the system is up and running. So our last change was default the system, reload database and installed original hardware. PROBBLEM: phones reset every morning from 8-10. Been happening for over a year and half. It started at install and never stopped. The phones are on the 80.0 network and the data is not the 64.0 network. I have placed a select 25 phones as static to see which change, (default system or static) might resolve the issue. Will no something monday morning. The state says the 10.0 range i see between the phones is not actually passing through our edge router. They believe that it is generated from the phone system.

JPfahl #560483 10/28/13 06:08 PM
Joined: Aug 2006
Posts: 1,795
Likes: 10
Moderator-Iwatsu
*****
Offline
Moderator-Iwatsu
*****
Joined: Aug 2006
Posts: 1,795
Likes: 10
Do you have the DHCP server in the phone system activated?

If your network already has one, the phone system side server needs to be disabled. Other than that, the phone system doesn't assign any IP numbers to anything- it merely looks for connections. The 10.0 is coming from somewhere in the network if the phone side DHCP server is diabled.

Are the phones using PoE or power cubes? Maybe your network switches are having a problem with power/loading.


Sometimes the thoughts in my head get so bored, they go for a stroll through my mouth. This is rarely a good thing.
JPfahl #560810 11/04/13 03:02 PM
Joined: Oct 2013
Posts: 30
JPfahl Offline OP
Member
OP Offline
Member
Joined: Oct 2013
Posts: 30
Well i have done extensive testing to isolate the issue. I eliminated the external DHCP server. I set up an internal DHCP off the MBU. I had the entire network offline. There was no traffic except the phone switch, two phones and the internal DHCP server. The wireshark capture shows that immediately upon a phone reboot the phone gets a 10.0.7.117 address. Again, there is nothing on the network except 2 phones a dumb switch, tried a hub too, the phone switch, and the new internal DHCP server. When I reboot a phone it goes through broadcasting this 10.0 until it finds the dhcp server and resets with the right address.

So is it possible that the CCSU is doing this? Is it possible, though the dhcp server in the phone system is off, it is still broadcasting, is their a phone system config file that is doing this.

I had a network guy say that it appears that the phone is saying hello to thephone switch 3-4 times and it is not getting a response back. FInally the phone restarts and tries again until the phone switch says im here.... Ideas?

JPfahl #560816 11/04/13 04:01 PM
Joined: Jun 2004
Posts: 1,367
Member
*****
Offline
Member
*****
Joined: Jun 2004
Posts: 1,367
wireshark at the phone switch port? are the reg request getting that far?

Is there a way of clearing the cache of the phone? If so, does the broadcast IP still show up?


[Linked Image from i26.servimg.com]
TouchPoint Networks.

Serving the Northwest Since 1991
NEC Shoretel Zultys T3 Tadiran
Joined: Oct 2013
Posts: 30
JPfahl Offline OP
Member
OP Offline
Member
Joined: Oct 2013
Posts: 30
I defaulted a phone that I would assume would clear it out. Still pulling that forge in address. Wireshark at the phone switch port still shows that addresses. THey are not in our network.

JPfahl #560824 11/04/13 06:46 PM
Joined: Aug 2006
Posts: 1,795
Likes: 10
Moderator-Iwatsu
*****
Offline
Moderator-Iwatsu
*****
Joined: Aug 2006
Posts: 1,795
Likes: 10
If the phone is getting an address of 10.0.7.whatever, it is being provided to it, if the phone is set for DHCP discovery. Te phone system won't hand out an address unless the DHCP server is enabled.

Test a phone like this, assuming you have a power brick for the phone. Remove the network connection from the MBU. Plug a phone, set for DHCP into the bottom 8P8C jack on the MBU. If you have the internal DHCP server disabled, the phone shouldn't boot up. Then set the phone for static IP, set an address in the phone system's subnet and see if it connects. Do your wireshark traps looking for the 10.0.7 addresses. You shouldn't see any.

Can I get a copy of your data base?


Sometimes the thoughts in my head get so bored, they go for a stroll through my mouth. This is rarely a good thing.
Joined: Oct 2013
Posts: 30
JPfahl Offline OP
Member
OP Offline
Member
Joined: Oct 2013
Posts: 30
I will do the test and double check the settings... thanks for checking in. I tried to send the db but the max file size is smaller the the db. Thoughts?

JPfahl #560833 11/04/13 10:11 PM
Joined: Oct 2013
Posts: 30
JPfahl Offline OP
Member
OP Offline
Member
Joined: Oct 2013
Posts: 30
I performed the afrorementioned test: removed network connection from the mbu. INternal and all dhcp servers disabled. Phone did not connect to the system. However, upon switching it to static and [NOT] yet setting an IP address the system assigned it a 10.0.0.10 address. So where did it get that from. This test was just the phone and phone system. Nothing connected and dhcp i thought disabled. By that i mean in the programmer all of the DHCP fields have a zero in them. Is there actually a disable enable switch i should be looking for?

JPfahl #560866 11/05/13 01:35 PM
Joined: Apr 2005
Posts: 2,498
Likes: 2
Member
*****
Offline
Member
*****
Joined: Apr 2005
Posts: 2,498
Likes: 2
Some manufactures require the system to be rebooted after certain changes, could this be the case with your internal DHCP server?


We get old too soon, smart too late
JPfahl #560884 11/05/13 07:39 PM
Joined: Aug 2006
Posts: 1,795
Likes: 10
Moderator-Iwatsu
*****
Offline
Moderator-Iwatsu
*****
Joined: Aug 2006
Posts: 1,795
Likes: 10
Any time you make any kind of IP address change, reboot the phone system.

The 10.0.0.10 address is the default-out-of-the-box IP address on the phone IIRC. Reboot the phone switch, configure the phone with an IP address of 80. whatever and try the test again.


Run the SNMP diagnostic report so you can see what IP addresses phones are using. Pay particular attention to subnet and gateway. I'm thinking you have a route issue back to the phone system. Phone reboots are usually caused by 1) Losing the TCP connection to the switch; 2) Losing power to the phone. If you're using PoE switches, that could indicate a failing switch or bad ports.

Where have you told things about VLAN tagging? It needs to be either 'tagged' to a VLAN number everywhere, or not tagged at all. The best filtering method for a VLAN with this equipment is to make it related to Iwatsu MAC addresses to keep unwanted aquipment out of the way.

PM sent regarding data base.


Sometimes the thoughts in my head get so bored, they go for a stroll through my mouth. This is rarely a good thing.
JPfahl #562796 12/13/13 09:35 AM
Joined: Jan 2007
Posts: 202
Member
Offline
Member
Joined: Jan 2007
Posts: 202
Would love an update on this. Did you ever find the problem?


James Berman
Business Telephone Systems
770-638-5000
Mitel - Premise and Cloud Solutions
Iwatsu
| Business Telephone Systems Atlanta |
JPfahl #562869 12/15/13 10:15 AM
Joined: Oct 2013
Posts: 30
JPfahl Offline OP
Member
OP Offline
Member
Joined: Oct 2013
Posts: 30
Thank you to all who have offered knowledge to this case. We have yet to determine the cause. IWATSU and the phone vendor insist that the issue lies with the network but have thus far failed to pinpoint the exact cause. Myself and other experts indicate that the network has been eliminated base on the 7 layer OSI model and insist that it is the phone system. So, no resolution yet! Thank you. We are going to redesign the IP network this month and see if that puts it in order. Short of that and physically separating the phone and network we have no answers.

JPfahl #602896 08/04/16 01:35 PM
Joined: Aug 2016
Posts: 1
Member
Offline
Member
Joined: Aug 2016
Posts: 1
I registered here just so I could chime in and say "me too" I know this is an old thread, but it did help us so I wanted to contribute my 2¢ too.

We have IWATSU IP phones hanging off our main phone system and started seeing the same "wonky" behavior when they were moved to another building. We had a couple in service that worked fine for years on a /16 subnet (255.255.0.0) getting addresses from DHCP in the old building.

Once we moved the phones to a new building (different subnet, same network, no firewalls only routers in between so no traffic gets blocked) they starting having issues.

For us the phones would get an IP address from DHCP but could not contact the phone system. You could ping the phone from anywhere (same building, building with the phone system, etc) but they just wouldn't talk to the phone system!! After looking at this post (and talking to Iwatsu support) setting the phones to a static IP address fixed them right up! Even if we gave them the same address they were getting from DHCP! I think something is busted in the IWATSU phone's network stack but that's nothing we could fix.

Another odd coicidence was that the subnet at the new building was also a /23 subnet (just like the original poster). Maybe these phones break when getting a non-class A,B,C subnet from a DHCP server??

I think it's rubbish that we have to statically assign IP addresses, but at least we have a work around.

--Andrew Duey
Network Engineer

Last edited by Andrew Duey; 08/04/16 01:35 PM.
JPfahl #605191 11/01/16 05:13 PM
Joined: Oct 2013
Posts: 30
JPfahl Offline OP
Member
OP Offline
Member
Joined: Oct 2013
Posts: 30
We did resolve this issue. The phones do reboot sometimes, but that could be something else on the network. The main resolution that fixed this for us was VLANning. We were in on large broadcast domain. While we cant technically confirm this was the issue as I had network experts indicating that the phones should be able to handle this, they could not. We split the entire network up into 12 different vlans and have the phones in one of their own. The phones have not acted as before since 2013. They are stable. Let me know if you have any questions.

JPfahl #611517 07/26/17 11:49 AM
Joined: Jan 2017
Posts: 1
Member
Offline
Member
Joined: Jan 2017
Posts: 1
This is an old thread, but I'll throw my 2 cents in just in case someone else has an Iwatsu reboot issue..

We had a big reboot problem after upgrading to Ver 12 to get the receptionist console capabilities.

After going through and tearing out every network monitoring device i had (SNMP apparently makes these things reboot), we installed VLANS for network endpoints, workstations, phones, cameras etc. (apparently, excessive broadcasts make these things reboot). We ran new cat6 to each desk for a dedicated phone connection (apparently too much traffic from a tethered workstation will make these things reboot).

Long story short, I went through the network and took care of all of the things that the Iwatsu engineers said would make these things reboot,

Our problem ended up being some strange network issue that was solved by a switch reboot and a full phone system reboot. All of the IWATSU phones were flapping ports on a cisco switch trunk in one of the connected buildings. After a reboot, they got their act together and we've had no more phone reboots.


Page 1 of 3 1 2 3

Moderated by  JBean3329 

Link Copied to Clipboard
Forum Statistics
Forums84
Topics94,262
Posts638,697
Members49,757
Most Online5,661
May 23rd, 2018
Popular Topics(Views)
211,112 Shoretel
187,717 CTX100 install
186,810 1a2 system
Newest Members
BPopilek, Rich F, LewisR, TDKs79, Buttinset
49,757 Registered Users
Top Posters(30 Days)
dexman 18
Toner 11
TDKs79 7
pvj 4
Who's Online Now
2 members (justbill, Curlycord), 55 guests, and 432 robots.
Key: Admin, Global Mod, Mod
Contact Us | Sponsored by Atcom: One of the best VoIP Phone Canada Suppliers for your business telephone system!| Terms of Service

Sundance Communications is not affiliated with any of the above manufacturers. Sundance Phone System Forums - VOIP & Cloud Phone Help
©Copyright Sundance Communications 1998-2024
Powered by UBB.threads™ PHP Forum Software 7.7.5