Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

CS1000 r6 loadware won't Transfer to MGC when Secure Transfer Enabled 1

Status
Not open for further replies.

bobertb

Vendor
Jan 20, 2010
186
0
0
US
Was having trouble transfering loadware to CS1000 r6 MGC cards during an upgrade.
Opened an Avaya ticket.
Here is how they recommend the process.

1. Add the MGC with Secure Transfer disabled.
2. Then once the latest load ware gets pushed to the MGC.
3. Reboot the MGC
3. Turn Secure Transfer back on, and add it onto the domain using "Register UCM System". "
 
I have never experienced this problem adding Media Gateways to any of my R6 switches.

Here are the steps I usually follow:

1. Create a zone for the Media Gateway in LD 117.
2. Define the Media Gateway in LD 97.
3. Cable the Media Gateway network connections.
4. Power up the Media Gateway and perform the initial configuration.
5. Wait for the new gateway to download all required new loadware (this is usually automatic) and reboot.
6. Configure the Media Gateway in Element Manager.
7. Wait for Media Gateway to Reboot (Manually reboot if required).
8. Join the Media Gateway to the Security Domain - 1st choice using 'reg ucm sys' in LD 117, 2nd choice using 'joinSecDomain' from 'oam' prompt on Media Gateway Controller.
9. Make sure Media Gateway reboots on its own after joining the security domain, else rejoin domain until it does reboot on its own.
 
Thanks allenmac for your detailed steps!!!

Any chance you could dissertate a little on the how's and why's of zones? Each MGC in it's own zone? Thanks in advance.
 
The zones are for bandwidth management (if you choose to configure and use correctly).

I usually create a new zone for each Media Gateway, and give it a number based on the loop number of the MG.

The DSPs for each MG are assigned to the same zone that you define for the MG.

If you take the time to configure your zones correctly, you can manage how each zone behaves under different conditions. I use Proactive Voice Quality Management (PVQM) which will adjust the bandwidth available for new calls in a zone as call quality either improves or degrades.

If call quality in a zone is so bad that there is no available bandwidth in that zone, the system will try to use resources in another zone if possible to complete calls. It is basically designed to prevent using resources in a zone that is saturated to the point that call quality is being affected.
 
So allenmac...if all your MGC's were physically right next to each other you still put them in their own zone?
 
Yes.

But maybe I'm just stubborn.

Actually, I was told by an ETAS engineer that this was the preferred configuration.
 
Hi, this is a known issue on Rls6 we are currently having it on two different sites with different customers. It seems that this has only become apparent since the last SU and Deplist update on Jan 18 2011.

This is Avaya's response....

Problem : Suppose file "mgcdb.xml" is somehow lost from the CS side
(in /u/ipmg/mgc/<supl>/). Now, during boot up of the MGC, it tries
to retrieve the XML file from the CS side. But won't find it, since
it is absent in CS. So MGC keeps on trying to retrieve XML file
from CS side. Hence, we can see the message "LOG0004 tMgcVgwAppStartRetry:
DSP DBs are present, waiting for mgcdb.xml from Primary Call Server"
continuously on the TTY after every 15 second interval.
Similarly, if the ftp task is down (or unresponsive) on the call server, the
mgc will still continually try to retrieve the pertinent file unsuccessfully,
resulting in the aforementioned log (along with "LOG0003 tMgcVgwAppStartRetry:
mgcNfcFileGet: nfcCopyFile returned E_FAIL.").

Solution: If the mgc retains a local copy of mgcdb.xml (in /u/db), then it
will proceed to use the local copy (after a few retries, in the case of the
ftp task failure, to ensure its not merely a momentary failure) rather than
continuing to wait for the file to be transferred from the CS.

If it happens again I suggest you raise another SR, and get them to send you the two patches that sort this out. BTW this issue has been rectified in Rls 7/7.5.......apparently!
 
Is the difrent VLAN's in the network routed? No routing between the E/T lan's in rel6 allways causes issue with security domain and MGC cards..
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top