Avaya Support Forums  

Go Back   Avaya Support Forums > IP Telephony and Convergence

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old 03-10-2014, 02:37 AM
rime rime is offline
Brainiac
 
Join Date: Dec 2011
Posts: 56
rime has 10 reputation points
Default timers for Survivable Core environment

In an Processor Ethernet architecture with a primary data center hosting Avaya Aura ACM main, a secondary data center hosting Avaya Aura ACM Survivable Core, is there a recommendation about how to set timers for remote Media Gateways?

The main data center goes down.
The Primary Search Timer is set to 1 minute for the Media Gateway at the Survivable Core site, so after 1 minute, the local Media Gateway at the Survivable Core site registers with the Survivable Core.

Question: How long does it take for the Survivable Core to be ready to accept registrations from all other sites?

This time is important because I need to set all other remote Media Gateways' PST timer to 1 minute higher than this time if I want all remote sites to register to the Survivable Core in the event of a main data center failure.

Of course, if the Survivable Core does not accept registration or is unreachable, remote site Media Gateways will then failover to the LSP.
Reply With Quote
  #2  
Old 03-11-2014, 03:26 AM
aa1 aa1 is offline
Guru
.
 
Join Date: Feb 2010
Location: Budapest - Hungary
Posts: 185
aa1 has 24 reputation pointsaa1 has 24 reputation points
Post timers for Survivable Core environment

Both the Survivable remote server (formerly called Local Survivable Processor [LSP]) and the Survivable core server (formerly called Enterprise Survivable Server [ESS]) are full functional state except they do not control anything. (let's say they are in dormant state). the survivable servers do not request the gateways to come to them for control and rather it's the opposite: i.e., the H.248 gateways and IPSI controlled gateways request the survivable servers to control them. The survivable server then accepts the control. the timers for each is set in their respective devices (i.e., in the case of the H.248 gateways, it's in the MG itself) and in the case of the IPSI, it's on the primary server. In the case of the IPSI controlled gateways, the environment could be segmented into several survivable configurations.

As for timers, I don't know if you have only H.248 media gateways or also IPSI controlled G650 gateways.

- Do you have only H.248 gateways (e.g., G450) or do you also have IPSI-controlled gateways (e.e.g, G650)?
- Do you have both a "Survivable remote server" and "Survivable core server" in the same remote location?

In the media gateway we have "Primary Search" and "Transition Point". When you set the "Primary Search" to 1 minute, then once the MG has detected the loss of the H.248 link to the primary controller (I suppose in your case the PE of the server in the main location), then the MG starts the timers. the MG will spent 1 minute looping around its mgc list of primary controllers (up to the transition point) and ask those controller to control it. During this time, should those controllers not be able to accept the MG's connection request, the the MG will continue looping through the IP addresses in its MGC list until the "Primary Search" timer expires (which is 1 minute). Then the MG will start sending requests to the secondary MGC list IP Addresses in which case it's normally the LSP/Backup servers.
Commands in the MG are: "show mgc list", "show recovery", "set reset-times primary-search/total-search/transition-point", "set mgc list"

The primary list on the MG would contain the main server's PE address. After a minute of link loss in the MG, the MG will then fall below the transition point and request services from the secondary server which would be your survivable core server's PE. the last IP address could be your Survivable remote server's IP. (this of course assumes you don't have any G650/IPSI/CLAN)

You would need to set the timers for the phones to be able to handle this as well. The phones have separate timers and alternative gatekeeper list.

Does this answer your question?
Arbi
Reply With Quote
  #3  
Old 03-11-2014, 03:27 AM
aa1 aa1 is offline
Guru
.
 
Join Date: Feb 2010
Location: Budapest - Hungary
Posts: 185
aa1 has 24 reputation pointsaa1 has 24 reputation points
Post additional documents

Here are some links to documents that could give you more info:


Avaya Aura® Communication Manager Survivability Options
03-603633 Issue 2 Release 6.2 July 2012
https://downloads.avaya.com/css/P8/documents/100156752


Administering Network Connectivity on Avaya Aura™ Communication Manager
555-233-504 Issue 14 May 2009
https://downloads.avaya.com/css/P8/documents/100048042


Avaya Aura® Solution Deployment
Release 6.1 03-603978 Issue 1 June 2011
https://downloads.avaya.com/css/P8/documents/100141104


The "Avaya Aura® Communication Manager Survivability Options" would be a good reference.

I hope these help!
Arbi
Reply With Quote
  #4  
Old 03-14-2014, 03:52 AM
rime rime is offline
Brainiac
 
Join Date: Dec 2011
Posts: 56
rime has 10 reputation points
Default timers for Survivable Core environment

Thank you for this. We have only H.248 Media Gateways, so the transition point is set to 1 at all sites and the MGC list of all Media Gateways at remote sites contains the Survivable Core's address before the LSP address:

IP address of main ACM
----------------------------------- <-- transition point (PST > 10 minutes at remote sites, 1 minute at Survivable Core site)
IP address of survivable Core
IP address of LSP

I was initially thinking that the Media Gateway at the Survivable Core site would need to register quickly with the Survivable Core (hence the 1 minute PST) so as to kick start the Survivable Core, because in my thinking the Survivable Core is not immediately ready to start call control. It would take something like 10 minutes (perhaps I am wrong there) for the Survivable Core to be able to handle call after the initial Media Gateway registration. So to be sure the Survivable Core is ready to take over call control, I set the PST at remote sites to a high value: more than 10 minutes. As I am conscious it is a long time for having all remote sites without call control, I am trying to optimize that value for faster recovery. Thanks in advance.
Reply With Quote
  #5  
Old 05-20-2014, 05:37 AM
rime rime is offline
Brainiac
 
Join Date: Dec 2011
Posts: 56
rime has 10 reputation points
Default timers for Survivable Core environment

Our design was proven with a disaster recovery test that showed almost all phones (except 3 of them) and all Media gateways registering at the survivable core within 8 minutes of deactivating the main ACM server pair.
Reply With Quote
  #6  
Old 09-10-2015, 06:12 AM
arahamanshar arahamanshar is offline
Whiz
.
 
Join Date: Jan 2015
Posts: 44
arahamanshar has 10 reputation points
Default

Hello,

Looks like you have arrived at a suitable value from your tests.
Feel free to respond with any further question you may have.

Thank you,

Abdul Rahaman Shariff
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 08:38 AM.

This Forum is provided solely for the use and convenience of Avaya customers and partners. Use of the Forum is subject to the Terms and Use and Privacy Statement found at www.avaya.com. No other use is permitted. The Forum including all content posted is “AS IS” and Avaya expressly disclaims all warranties and/or guarantees as to its accuracy, reliability, usefulness, quality or non-infringement of intellectual property. Avaya reserves the right to remove any content posted on the Forum at any time and for whatever reason.

Avaya will not be liable for any content posted on this Forum, including, without limitation, any errors or omissions or for any losses or damages of any kind incurred as a result of use or reliance on any content, regardless of its origin.

You expressly understand and agree that you assume all risks associated with use or reliance on this content.