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]

I think it's time you get a tech onsite who can look at it, he/she should be able to solve it quicker than the time spent on this thread already.

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

 

[meyer1y2k]

While all of the dialogue is accurate, there is one possibly simple way to show whether the IP Office is the problem or not. Properly assign static network settings to a non-working phone. Don't forget to define the Call Server address. Prepare an Ethernet crossover cable. During an off time, disconnect the LAN cable from the network and, using the crossover cable, connect the phone directly to the LAN port and power up (hopefully you have a power brick). If the phone comes up then it has to be the network.

If you don't have a power brick then you could use a POE switch and make sure only the IP Office server and the phone are connected but the cleanest test would be to directly connect to the IP Office if possible.

Sometime we have to resort to this to prove to IT staff that it is not the system when the phone comes up. Then we find the bridge loop or whatever is the cause.

 

[intrigrant]

@meyer1y2k if you have read all replies here and in the avaya.support forum then you''l find this has already bein suggested.
But either there is no need for a solution or the questioneer is just a stalker having fun to keep us busy.
I give up and let him do with his problem, in this case I believe he is his own problem

 

[TierOneTech]

Wow, I am a stalker. Really?
I have answered this before. I DID statically assign 4 of the 001B phones, with ALL of the information. I did two with the seperate IP's for the call center and the file server.
I did the other 2 phones with the call center IP in both.
Neither way worked.
I can see the MAC being seen by the Avaya call manager.
It shows BOOTP, the MAC and failure to verify in the lower left corner of the manager interface.
Why do I see the 0007 MAC's register and the 001B MAC's fail? This is the AVAYA doing this. I am seeing this in the manager program.
If it were a network issue, the why do the 0007 MAC's boot with no issue on the SAME cable used on a 001B that will not boot?
By the way, I have been doing networking since token ring, so I am tired of all of you that attempt to denigrate myself and my knowledge.
I have said at least three times that I inherited this situation. It is not how I would have done it.
I also have said that all of the phones worked 3 weeks ago and I had made no changes to the network.

That is why I asked this question - there is a check box on the Avaya DHCP screen that states DHCP for Avaya phones only. How does the system know which IP requests are Avaya phones? Kindly do not respond with the firewall option because that is not where the IP is being handed out. Yes it is a communication port, for simplicity, but there has to be more to the verification process. That is why I suspect an issue with a MAC table.

Any rate, I appreciate those of you that actually tried to assist me. Thank you.
To the rest of you, try actually READING what is posted and the questions asked before you criticize.

Thank you.



.

 

[pmcook]

That is why I asked this question - there is a check box on the Avaya DHCP screen that states DHCP for Avaya phones only. How does the system know which IP requests are Avaya phones?"

LLDP and or OUI of the MAC.

Maybe do this: take the IPO off the network, plug it into a switch and then plug the troublesome phones into the switch too. At least then you will know if it is the IPO or your network. If it still doesn't work then hook up a laptop with Wireshark on it and remove the phones except for one then power cycle it while doing a capture. Be sure to set your capture filter for LLDP, BOOTP, DHCP and HTTP. With just two hosts you should be able to see clearly what is going on.

You need to do some sloothing here and it seems to me you're just making guesses. You need to isolate the source as your first step. Once you have eliminated the IPO or the network you will be in a much better place to determine the issue.

My hunch your problem lies in an ARP table or a spanning tree in one of your switches. Your Sonicwall could be blocking internal traffic using the OUI. If somebody else is managing your switches perhaps they added a rule that you are not aware of? Managed switches can be a bear to troubleshoot. That si why you have packet analyzers like Wireshark.

If you go back to TR then surely you have done this before?

 

[tlpeter]

This is lasting for two weeks now, seriously listen and do as told.
Create VLANS and put the phones in it inclusing the IPOffice.
All you now need to do is to set the IPOffice in to a untagged port and the phones in a tagged port.
Be sure that these phones get there VLAN id by lldp or a dhcp server.
This is a network issue for sure as there is too much coincidence.
That those phones worked for three weeks all has to do with DHCP lease timers ( i do a wild guess)


BAZINGA!

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

 

[mattKnight]

I type a long reply andlost it - apologies

I'm going to stick my neck out a little bit here. I agree that one way that the IPO DHCP server can identify that the DHCP request is from an Avaya phone is by inspecting the MAC OUI. It is, in theory, plausible that the IPO firmware being old does not recognise the MAC OUI of the second set of handsets. Bearing in mind that the 5610 series of handsets are also quite old now I'd be very wary of saying more than that. All that being said I know of no way to update the IPO to tell it the new OUI.

We are now at the stage where the standard investment disclaimer applies; "Past performance is not a guide to future gains". In other words, it worked, now it doesn't and by the laws of logic - something has changed, but neither you nor us know precisely what that is; it could be as simple as a spanning-tree reconvergence.

This is place is full of people who have all the skills and expeience to help you fix that, but you have to at least engage. The desire to return the status quo ante is now bordering on the stubborn and is not helping you at all.

As you are a network engineer of some experience, I don't think I need to explain the benefits of network segmentation; however I think you may need to explain your reluctance to implement it. From the point of view of IP office, it is more conventional to use seperate VLANS so the original installer cut some corners

As a final point, using Manager uses bootp under special circumstances to issue firmware to base units; that you are seeing bootp failures in that window is normal and doesn't progress you in any direction.

I truely hope this offers some assistance

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[derfloh]

As suggested before I would take a look into system monitor with DHCP filters enabled. You will see the requests and the answers given by the IPO. If IPO decides not to answer - as you think because of an unknown MAC or something else - you will get a hint about the reason for that behavior there.

I'm not sure based on what information IPO decides if an Avaya phone requests a new DHCP release or someone else. It could be the MAC address or LLDP info but it could also be the DHCP fingerprint. Avaya switches use that fingerprint to authenticate phones without having to use the inbuilt EAP supplicant of the phone.

 

[joe2938]

I would try this (not sure if it was already suggested) unplug a working ip phone, plug in a phone that would not come up, then if it now works this proves you have some sort of network issue or with the data switch itself