Topic: IWATSU phones are resetting daily...

[jrpfahl]

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.

The POE switches have all checked out. Im at a  loss!

[Keighlar]

That's a weird one, and I don't know if I can be of much help since this really does "feel" like there's a networking issue here, and that's not my particular strong suit.  Did you make sure that the DHCP server is off in the ECS (System --> Harware --> DHCP Server)?  I know you said there are 130 phones, so I'm not sure how possible it is, but have you tried to statically set them?  Maybe just set a test group of phones with static address and network info.  See if they stay up while the others reset. 

[jrpfahl]

Thanks for the reply. The DHCP server seems to be in order.  There is no other DHCP on the network and it is off in the ICON Program.  I had read somewhere that there was a deeper level setting that may hold an ip address that is not seen from the program. Does that mean anything to you?  What would cause the Phone switch to serve an Ip address scheme that is not in the mbu settings? The phones are just randomly resetting...well if you think of something i would appreciate it. thanks

[Keighlar]

I have been working with the ECS for 8 years now and I have never seen it serve an unknown IP address.  I would still try statically addressing a few phones to see if they survive the reset.  Many, many times I have alleviated connectivity issues in IP phones by statically setting them.

I wish I could be of more assistance, but I'm not sure about that deeper level setting.

[jrpfahl]

WOW that would be a lot of phones to reset! Our vendor has a client with an identical setup and cant figure out why ours is delivering this 10.0.7 network to the phones when DHCP is sending out 10.77.80.

[Marc Haycook]

Only way I know for a different address to get pulled is a rogue DHCP server. I'd run a scan on the network and look for something that shouldn't be there. I've seen employees bring a router from home and plug it into a network because they needed more ports in their office.

[jrpfahl]

I have checked the network for dhcp servers. We unfortunately have apple access points throughout. They all show that dhcp is enabled. That however seems only when i am checking. Does the iwatsu system have a way of pushing static addresses or do they have to be manually set?Whats interesting about this is that it happens every morning from 8-10. The phones reset 4-5 times during 8-10 and the rest of the day they are fine. During that reset they some how pull the 10.0 address range. Which we are not provisioning.

[Keighlar]

You would have to manually set the IP addresses.  It's fast and painless per phone, but having to set over 100 would still take a good amount of time.  You shouldn't HAVE to do this.  There is obviously something interfering on the network.  Setting the phone as static is a work-around if you can't find the culprit elsewhere.