Michael G
asked on
Cannot upgrade Norten i2002 firmware via MPLS WAN
Hello.
We are currently expanding our VoIP to a new site, and we are having an issue with firmware upgrading the Nortel IP phones model i2002 (the only model being used).
Our setup contains the following:
Site 1: Main VoIP site with a CS1000
Site 2: Branch Office also with a CS1000
Site 3: Branch Office but without any servers
Site 4 (the new site): Branch Office but without any servers
Site 1 and 2 uses a Dell PowerConnect 6024 as CORE switch and runs data and VoIP traffic in a separate VLAN. Site 3 doesn't have a Layer3 switch, so both data and VoIP uses the same VLAN. Site 4 uses a Dell PowerConnect 6224 as CORE switch, and data and VoIP traffic is in a separate VLAN.
All sites are connected via a switched MPLS without any restrictions or internal firewalls to block any traffic. MTU is set to 1800bytes which is higher than the size of the packets when upgrading the firmware (checked via Ethereal sniff)
DHCP is used on all sites to give out IPs for both PCs and IP phones in their respective scopes (except Site 3 where they use the same scope). On Site 1 and 2, the VoIP server and the IP phone are on the same subnet.
IP phones on Site 4 are connecting to the CS1000 on Site 1. As long as the IP phone is using the latest firmware from the CS1000, then everything is working as it should. The problem occurs when the i2002 firmware needs to be updated e.g. from 0604DAD to 0604DBN. The phone is able to detect that it needs to upgrade its firmware. The phone then reboots to download the new firmware, but it's unsuccessful. The phone hangs at a message I unfortunately can't remember, but it's "Waiting for BOOTP mode" or something like that. After that, the message "Firmware download" is shown very shortly and then the phone reboots again. Due to the unsuccessful firmware upgrade, the phone is now in an endless loop because the server keeps telling the phone to upgrade its firmware, but the phone is unable to do so.
By looking at an Ethereal sniff of a successful firmware upgrade (from one of the other sites) and comparing it to a sniff of the unsuccessful firmware upgrade, I can see that the unsuccessful upgrade seems to be stopping where the upgrade process is supposed to perform "UFTP Signaling" on port 5105.
There are 2 major differences between the setup on Site 1 + 2 and Site 4.
* On Site 4, the IP phones are not on the same subnet as the VoIP server because there aren't any VoIP servers on that site.
Due to this, I'm wondering if any UDP / IP Helper addresses should be configured on the CORE switches and MPLS network to allow broadcasts to flow between the subnets!?
* Site 4 uses a newer Layer3 switch, Dell PowerConnect 6224. Site 1 + 2 uses a Dell PowerConnect 6024.
The new switch on Site 4 also gave us some initial problems with the communication, but that was solved by enabling the "VLAN Filter" option on the i2002 phone, so I know for a fact that the 2 switches don't work exactly the same way.
Any suggestions to the cause of this firmware upgrade issue, is greatly appreciated.
Thanks in advance.
We are currently expanding our VoIP to a new site, and we are having an issue with firmware upgrading the Nortel IP phones model i2002 (the only model being used).
Our setup contains the following:
Site 1: Main VoIP site with a CS1000
Site 2: Branch Office also with a CS1000
Site 3: Branch Office but without any servers
Site 4 (the new site): Branch Office but without any servers
Site 1 and 2 uses a Dell PowerConnect 6024 as CORE switch and runs data and VoIP traffic in a separate VLAN. Site 3 doesn't have a Layer3 switch, so both data and VoIP uses the same VLAN. Site 4 uses a Dell PowerConnect 6224 as CORE switch, and data and VoIP traffic is in a separate VLAN.
All sites are connected via a switched MPLS without any restrictions or internal firewalls to block any traffic. MTU is set to 1800bytes which is higher than the size of the packets when upgrading the firmware (checked via Ethereal sniff)
DHCP is used on all sites to give out IPs for both PCs and IP phones in their respective scopes (except Site 3 where they use the same scope). On Site 1 and 2, the VoIP server and the IP phone are on the same subnet.
IP phones on Site 4 are connecting to the CS1000 on Site 1. As long as the IP phone is using the latest firmware from the CS1000, then everything is working as it should. The problem occurs when the i2002 firmware needs to be updated e.g. from 0604DAD to 0604DBN. The phone is able to detect that it needs to upgrade its firmware. The phone then reboots to download the new firmware, but it's unsuccessful. The phone hangs at a message I unfortunately can't remember, but it's "Waiting for BOOTP mode" or something like that. After that, the message "Firmware download" is shown very shortly and then the phone reboots again. Due to the unsuccessful firmware upgrade, the phone is now in an endless loop because the server keeps telling the phone to upgrade its firmware, but the phone is unable to do so.
By looking at an Ethereal sniff of a successful firmware upgrade (from one of the other sites) and comparing it to a sniff of the unsuccessful firmware upgrade, I can see that the unsuccessful upgrade seems to be stopping where the upgrade process is supposed to perform "UFTP Signaling" on port 5105.
There are 2 major differences between the setup on Site 1 + 2 and Site 4.
* On Site 4, the IP phones are not on the same subnet as the VoIP server because there aren't any VoIP servers on that site.
Due to this, I'm wondering if any UDP / IP Helper addresses should be configured on the CORE switches and MPLS network to allow broadcasts to flow between the subnets!?
* Site 4 uses a newer Layer3 switch, Dell PowerConnect 6224. Site 1 + 2 uses a Dell PowerConnect 6024.
The new switch on Site 4 also gave us some initial problems with the communication, but that was solved by enabling the "VLAN Filter" option on the i2002 phone, so I know for a fact that the 2 switches don't work exactly the same way.
Any suggestions to the cause of this firmware upgrade issue, is greatly appreciated.
Thanks in advance.
ASKER
I'm aware of that. As I wrote in my question:
"Due to this, I'm wondering if any UDP / IP Helper addresses should be configured on the CORE switches and MPLS network to allow broadcasts to flow between the subnets!?"
I don't want to just enable all broadcasts across tha WAN, but I haven't found anyone (not even our supplier) that can tell me which "helpers" I should add!?
"Due to this, I'm wondering if any UDP / IP Helper addresses should be configured on the CORE switches and MPLS network to allow broadcasts to flow between the subnets!?"
I don't want to just enable all broadcasts across tha WAN, but I haven't found anyone (not even our supplier) that can tell me which "helpers" I should add!?
If it is strictly bootp request you can use ip helper-addresses, however, with uftp it uses multicast so you may need to enable multicast over the WAN.
harbor235 ;}
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You are using UFTP, are your networks devices multicast enabled? What must you do to use UFTP over a WAN? Local should be no problem, however, if you are not multicast enabled on the WAN as well I can see why this would not work.
harbor235 ;}