technology, networking and IP telephony
Posts tagged VOIP
SRG50 – Applying Software Patches
0February 13, 2009
We have a number of Survivable Remote Gateways (SRG) across our network providing local PSTN and E-911 access for our smaller IP telephony deployments. We recently went about applying a number of cumulative updates and ran into a few different problems.
Thankfully both of the issues we experienced had already been documented by Nortel as a known issue.
We had an SRG50 that had been upgraded from 1.0 to 3.0 and had the December 2008 Desktop update (BCM050.R300.SU.Desktop-140.200812-1.zip) applied but when we would try to apply the December 2008 System update (BCM050.R300.SU.System-139.200812-1.zip) through Nortel’s Business Element Manager the software would tell us that the update we were trying to apply was obsolete (see figure below). In the past Nortel would release dozens of different patches for the different components in the SRG/BCM platform. Thankfully they started releasing cumulative updates which greatly simplifies the management and patching of the SRGs and BCMs.
Thankfully this problem had been documented by Nortel and was listed in a support document entitled Business Communication Manager (BCM) / Survivable Remote Gateway (SRG) /BCM50 / BCM450 Top Issues. Here’s an excerpt of the document that concerns this specific problem;
ISSUE: Inability to apply any update numbered over 1xx, shows Obsolete. Issue will manifest on BCM50 R3 systems with any of the following SU System Updates applied as last update:
- BCM050.R300.SU.System-21.200801
- BCM050.R300.SU.System-25.200802
- BCM050.R300.SU.System-28.200802
RELEASE: BCM50 R3 or any BCM50 hardware loaded with R3 software (6.x)
CR: NONE
SYMPTOMS: Inability to apply any update numbered over 1xx, shows Obsolete.
WORKAROUND: Apply required update BCM050.R300.SOFTWARE-MANAGEMENT-63 or greater.
STATUS: Update BCM050.R300.SOFTWARE-MANAGEMENT-63 is now bound into BCM50 R3 System SU 200901 for application. Details regarding this dependency are imbedded into SU Update Release Notes. BCM050.R300.SOFTWARE-MANAGEMENT-63 is also generally available and can be downloaded as a stand alone update from Nortel.com.
RECOMMENDATIONS: Apply required update BCM050.R300.SOFTWARE-MANAGEMENT-63 or greater to any systems that match this particular profile. **
Once we loaded BCM050.R300.SOFTWARE-MANAGEMENT-63 into the SRG50 we were able to load and apply the cumulative system update for December 2008.
We also had a second problem where a brand new SRG50 that wouldn’t accept any new software updates after we installed the December 2008 System update (BCM050.R300.SU.System-139.200812-1.zip). Nothing would happen when you clicked on the “Get New Updates” button within Business Element Manager. We tried running Nortel’s Business Element Manager from multiple desktops and laptops but got the same symptom which left us stumped. Again thankfully this problem already been documented by Nortel.
ISSUE: Unable to apply further patches after applying BCM050.R300.SU.System-139.2008012. This is found on new
BCM50 R3 installations and might not surface if there are patches already installed on the system.
RELEASE: BCM50 R3
CR: Q01975339
SYMPTOMS: Unable to apply any more patches.
WORKAROUND: Download the latest Element Manager from www.nortel.com and install.
STATUS: Design is discussing best option to resolve/avoid this issue on future SUs .
RECOMMENDATIONS: Please install the BCM50 R3 SUs just released in January:
BCM050.R300.SU.Desktop-152.200901
BCM050.R300.SU.System-151.200901
We downloaded Business Element Manager v2.0.300-0 from Nortel’s website and upgraded our current installation after which we were able to apply the remaining patches. I’m not sure how the version numbers work with Element Manager but after installing v2.0.300-0 the Help -> About screen showed it was v1.05.0.
Cheers!
Upgrading the i2002 Phone Firmware
0February 7, 2009
We’re preparing to deploying 300+ i2002/i2004 IP telephones over the next few weeks. In preparation for this deployment we decided to upgrade the current IP phone firmware from 0604DBG to 0604DCG. The site has a Nortel Succession 1000M Call Server with 3 Succession Remote Gateway (SRG) 50s providing local PSTN and E-911 services at three remote facilities. We have done this dozens of times in multiple locations and never really had an issue (except when ‘filter-unregistered-frames‘ was left enabled on the switch ports). This time, however, we came across a problem that caused all 12 i2002 IP phones at one remote site to get stuck in a continual loop trying to upgrade. It took us quite sometime to isolate the problem and come up with a solution although a little background is necessary to understand the problem.
It would now appear that my assumption was totally wrong.
The remote site that had the problem never had the ADAC MAC address table updated beyond what is in the default configuration. When the phone booted into BOOTC mode to perform the upgrade it wasn’t sending the necessary LLDP information to the switch so the switch wasn’t adding the voice VLAN to the port. The only problem was that the phone was using the voice VLAN tag and original IP address so while it’s requests made it to the server the phone never recieved an answer because the voice VLAN was not a member of the port that the phone was connected to. Once we added all the MAC addresses to the ADAC table everything starting working properly. Now when the IP phone booted into BOOTC mode ADAC immediately recognized the MAC address and applied the voice VLAN to the switch port allowing the IP phone to communicate with the SRG50 and the Succession 1000M Signaling Server.
no adac mac-range-table adac mac-range-table low-end 00:0a:e4:75:00:00 high-end 00:0a:e4:75:ff:ff adac mac-range-table low-end 00:13:65:00:00:00 high-end 00:13:65:ff:ff:ff adac mac-range-table low-end 00:14:c2:00:00:00 high-end 00:14:c2:ff:ff:ff adac mac-range-table low-end 00:16:ca:00:00:00 high-end 00:16:ca:ff:ff:ff adac mac-range-table low-end 00:17:65:00:00:00 high-end 00:17:65:ff:ff:ff adac mac-range-table low-end 00:18:b0:00:00:00 high-end 00:18:b0:ff:ff:ff adac mac-range-table low-end 00:19:69:00:00:00 high-end 00:19:69:ff:ff:ff adac mac-range-table low-end 00:19:e1:00:00:00 high-end 00:19:e1:ff:ff:ff adac mac-range-table low-end 00:1b:ba:00:00:00 high-end 00:1b:ba:ff:ff:ff adac mac-range-table low-end 00:1e:ca:00:00:00 high-end 00:1e:ca:ff:ff:ff adac mac-range-table low-end 00:22:67:00:00:00 high-end 00:22:67:ff:ff:ff
The short story here is that you need to maintain the ADAC MAC address table if you want to avoid any IP phone firmware upgrade issues.
As a side note you also need to make sure that you disable filter-unregistered-frames on all switch ports.
I’ve inquired with Nortel about this problem but I’m still waiting for a response. It’s quite possible that this issue has already been “discovered” and will be resolved in a future release (or even resolved in this release).
Cheers!
ADAC and VLAN Configurations (Part 2)
0February 2, 2009
In a previous post titled ADAC and VLAN Configurations I described some issues we were having with some of our switches where VLAN memberships were mysteriously changing. We suspected ADAC and we were right on with our suspicions.
We performed some exhaustive testing with ADAC over the past few weeks and can confirm, as Roberto alluded too, that ADAC will dynamically reconfigure any switch port that has ADAC enabled to the VLAN membership and PVID setting that was set when ADAC was first enabled on the switch port. In our tests we configured an edge port as a member of VLAN 10 and then enabled ADAC on that port. We then added the edge port to VLAN 11, removing it from VLAN 10. When the port went into an oper-down state ADAC added the edge port back to VLAN 10 and removed it from VLAN 11. We confirmed the same behavior with respect to the PVID changing.
In short if you need to make a VLAN membership or PVID change to an ADAC enabled port you MUST disable ADAC on the port before making the change and then re-enable ADAC when you have completed your change. As a side note any Nortel IP phone that is connected to the port will most likely timeout and reboot itself when you disable ADAC.
While I don’t necessarily disagree with the behavior it would be nice for either the CLI of Device Manager to alert someone if they tried to change the VLAN membership of a port that had ADAC enabled. (hint hint Nortel)
Cheers!
