Some Avaya 5610 phones will not boot 1

[TierOneTech]

I have an Avaya phone system that is part of a network that I manage. I did not install it or manage it previously. That company is defunct.
It states that it is an IP Office 500. The software on the XP computer is identified as IP Office Manager 6.2.
Two weeks ago all 50+ phones worked fine. Then last week a staff member noticed that there were some phones that would not boot.
I found that there are 2 MAC addresses involved. They are 0007 and 001B.
All of the 0007 phones are up and operational.
None of the 001B phones will boot.
This would lead me to believe that the Manager program has lost the MAC info and no longer will accept the DHCP request from these phones because of their MAC.
Where in the Manager software are the accepted MAC addresses registered?
How does the software identify and find the phones?
How do I modify the acceptable MAC's?

Any and all help is GREATLY appreciated!

 

[janni78]

Would be interesting to know what error message the phones are showing.

Manager doesn't provide DHCP, that is usually done by your networks DHCP server or in some cases the IP500, manager is used to administer the IP500.

"Trying is the first step to failure..." - Homer

 

[TierOneTech]

When I set up the SonicWall, I left a range out of the scope per the Avaya company's request. All phones are supposed to receive a 192.168.2.XXX.
The working phones get an IP in that range. I have nothing in the firewall to facilitate this, no MAC lock, nothing. All of the none functional phones ARE receiving an IP from the firewall now, therefore the problem. There are no fixed IP settings in the phone. I have tried setting the phones to static, then they sit on discover IP of file server or call server. Static does not work.
OK, the IP 500 is the DHCP. I can accept that. It is obviously checking MAC's, but where and how? Why would it work and then not?

Thank you for your input janni78!

 

[TierOneTech]

If needed, there are 3 components, the IP400 System trunk box, the IP500 System Unit (I do not know how to tell V1 from V2) and an XP computer with the Office Manager 6.2 loaded.The IP 500 has one card installed.

 

[janni78]

Do you have different VLANs for the IP Phones and the regular network?
I never used the IPO as a DHCP server, only reason would be if there isn't a DHCP in place that the phones can use.

You could add option 242 and 176 in the DHCP sever containing a string "MCIPADD=ip-to-pbx,HTTP=ip-to-fileserver", that would probably make the work again if they get the IP from the firewall.
Don't know how that will affect the DHCP in the IPO, I would disable the IPOs DHCP and just use the sonicwall so everything is in the same place.

"Trying is the first step to failure..." - Homer

 

[tlpeter]

Could it be that you replaced a switch which users Mac addresses to allow devices?
I have seen this on HP switches (rebranded 3com)


BAZINGA!

I'm not insane, my mother had me tested!

 

[amriddle01]

The non working handsets are probably newer and that MAC range didn't exist for Avaya phones when 4.2 was released. When you tick Avaya IP phones only in the system DHCP scope I think it uses MACs to identify what to respond to...hence your issue

 

[TierOneTech]

Thank you all for your responses!

janni78 - no V-lans, I also am not sure I understand what you would have me add to my SonicWall.

intigrant - there have been no changes to the network as I am the only one that does them. I can see the 001B phones try to register - at the bottom of the manager interface it runs a message bar that says MAC # trying to register and fail, so I believe the issue is with the Avaya equipment

tipeter - I have not replaced any of the Netgear switches or made any other changes before the failure

amriddle01 - the only problem with that scenario is that the phones all worked 2 weeks ago and had been working for at least 3 years this way. They were actually installed in 09 or 10 but I do know that the computer with manager on it was replaced with the current version of manager on it. Either 3 or 4 years ago. All phones have been working for at least 3 years until 2 weeks ago.
That is why I am asking where the actual MAC verification happens. I see the scope in the manager and can turn it on or off. Is the DHCP service actually in the XP computer with manager installed or is it actually from the IP 500? My thought would be that whatever is the DHCP also has a file with the MAC address identifier as well. I have tried looking for a file with a name that might ring a bell but no luck, no MAC file.

Thank you all for your thoughts and continued assistance!

 

[amriddle01]

The system does DHCP not Manager, if they are trying to register then they have an address, something has changed for sure, I imagine it's programming. What do the phones say on the screen? You may well need a qualified tech to sort this anyway so a look for a local BP on Avaya's partner finder can't hurt

 

[janni78]

If he has Manager 6.2 he should have IPO 4.2 firmware, did that even support DHCP options for IP Phones?

56xx phones need a custom DHCP option 176 to get the settings if not entered manually.
I would put that in the Sonicwalls DHCP and disable the DHCP in IP Office so you just have one DCHP server on the network.

The question is what the phones say, that gives the information on what settings they are missing.

"Trying is the first step to failure..." - Homer

 

[mforrence]

All of the none functional phones ARE receiving an IP from the firewall now, therefore the problem. There are no fixed IP settings in the phone. I have tried setting the phones to static, then they sit on discover IP of file server or call server. Static does not work./quote]

Most firewalls won't provide call server address. Try configuring ALL of the pertinent info (address, server address,etc) statically in the phone - I suspect it will then work.

 

[teletechman]

go to monitor and see if you have an option for DHCP under the Status tab, it should show you if the IP Office is doing DHCP if it shows nothing then look at the working phones and see where they are looking for DHCP. You might find that something is over running the DHCP scope on the IP Office if it is handing them out. Try a reboot of the IP Office to clear the DHCP scope.
Mike

 

[TierOneTech]

janni78, exactly what is " custom DHCP option 176"?

mforrence, I did try to static the info, the phones would then stick on 'discovery' with the call server IP displayed.
That is why I am convinced that the issue is how the system is verifying that the MAC is a valid Avaya MAC.
This is what I am trying to discover - where is the list of approved MAC addresses stored?

intigrant - the phones are not getting their IP's from my Sonicwall. I do not know if it is actually the IP 500 or the XP box with with Manager installed that is supplying the IP to the phones based on MAC but it is one of those 2.

teletechman - The Avaya system is assigning IP's. There is a DHCP option in the Manager that is turned on. Its scope is where the working phones are getting their IP's from, ranges match, plenty of room left, scope is excluded from my Sonicwall. I have rebooted all components of all systems. I have attempted to verify the config file.

Thank you to all of you for your willingness to assist me with this very odd situation!

 

[pmcook]

As suggested, configure them statically. You need IP, SN, GW, call server and HTTP server addresses. The last two are your IPO.

 

[janni78]

You're over complicating things.

If the phones are stuck on Discover and shows the IP500s IP address it means that they can't reach it on the network.

"Trying is the first step to failure..." - Homer

 

[TierOneTech]

Hi Guys!

Like I said earlier, I tried to static address the phones. They will not connect to the Avaya. They do get an IP from my SonicWall. The other MAC addressed phones connect with no issues.
That is why I believe that the entire issue revolves around the list of approved MAC addresses in the IP500.
Both sets of phones worked 2 weeks ago and had been functional for at least 3 years.
Mow all phones with the MAC starting 0007 register, get a proper range IP and work.
All phones with the 001B MAC will not register with no changes or with me programming them statically. I have also tried resetting a 001B phone to factory. No success.
I can take a 0007 phone and swap it with a non-working 001B phone in that location and it will register, so it is not a network issue.
This is why I am trying to identify how and where the IP500 is doing the MAC comparison. What is the file that the list of verified MAC's is stored in or is it tied into the firmware somehow?
If so, how do I get a copy of the newest firmware for this system since I can't get access to anything on Avaya's website?
Also, how do I tell the difference between a version 1 and a version 2 IP500?

Thank you for your help!

 

[amriddle01]

You are barking up the wrong tree, this has nothing to do with MAC addresses if statically assigning all values doesn't work, but we don't know if you did that correctly or what actually happened when you did.

As I said, getting someone who knows the system well in will have this working in minutes, talking you though every thing to check and how to do each of those things will take an age.

 

[amriddle01]

Now after reading properly instead of skimming the thread I see they went to discover when you statically assigned, this means you 100% have a network related issue, absolutely nothing to do with the system looking at MACs or anything like that because it doesn't do any MAC filtering for registering handsets. If a load of phones all went off at once and couldn't get DHCP then that also indicates trouble on the network as their requests probably weren't reaching the server.

Plug a PC into the port one of those phones uses and give it an IP that you used when statically assigning the phones and try to ping the system

 

[pmcook]

He needs to check his Sonic config to be sure he has enough licenses. The SWs will not assign any address past its purchased license limit of nodes.

 

[mforrence]

If phone has ALL appropriate fields statically assigned, SonicWall does not come into play. I HIGHLY suspect that only the phone's IP address has been set, hence - it doesn't know where the call/file servers are located. Especially true if on a flat network.