Table Of Contents
Designing a Messaging Network Controlled by Cisco UMG
Design a Messaging Network with Unique Location IDs
Guidelines for Assigning Location IDs
Designing an Address Scheme for Your Messaging Network
Guidelines for Choosing an Address Scheme
Designing a Cisco UMG Controlled Network with Network Optimization
Choosing Reasonable Timers on Cisco UMG Network
Choosing Cisco UMG Features Based on Network Resource Availability
Design a Secure Cisco UMG Network from Both Network and Application Levels
System and Remote Access
Local Access
Remote Access Using Telnet
Application Environment
Cisco UMG Access Control Guidelines
Application Level Security Protection
Secure Registration of Endpoints
System Distribution List and System Broadcast Message Endpoint Control
NAT Support on Cisco UMG
Designing the Fail Over Scheme in the Cisco UMG Network
Guidelines for Deploying Failover Support on the Cisco UMG Controlled Messaging Network
Designing the Backup and Restore on a Cisco UMG Controlled Network
Restrictions
Best Practices
Designing a Messaging Network Controlled by Cisco UMG
First Published: February 28, 2008
After completing chapter 3 and chapter 4, complete the following tasks:
•
Use the analysis of the network traffic distribution pattern based on regions or areas on the messaging network to:
–Decide which Cisco UMG deployment model to use.
–Finalize the locations to install the Cisco UMGs.
–Allocate the extra bandwidth for Cisco UMG to perform all required functions.
•Optionally extend or modify the network security and QoS mechanism on the current network for the new Cisco UMGs inserted into the network.
•Use the sizing and capability calculations for the Cisco UMG to select the correct hardware and licenses to purchase.
•Finalize which endpoint types and versions (Cisco Unity Express, Cisco Unity, and Avaya Interchange) to use
•Prepare the TFTP, FTP, NTP, and DNS servers for use in the Cisco UMG controlled messaging network
This chapter describes the following design guidelines based on the results from the above steps:
•Design a Cisco UMG network with unique location IDs for all entities including all endpoints and the Cisco UMGs.
•Design a Cisco UMG network with a consistent address scheme across all nodes in the network.
•Design reasonable timers and turn on/off features on the Cisco UMGs to optimize the network bandwidth.
•Design a secure Cisco UMG network from both network and application levels.
•Design the Cisco UMG failover scheme.
•Design the Cisco UMG back and restore options.
These guidelines are discussed in the following sections:
•Design a Messaging Network with Unique Location IDs
•Designing an Address Scheme for Your Messaging Network
•Designing a Cisco UMG Controlled Network with Network Optimization
•Choosing Reasonable Timers on Cisco UMG Network
•Choosing Cisco UMG Features Based on Network Resource Availability
•Design a Secure Cisco UMG Network from Both Network and Application Levels
•Designing the Fail Over Scheme in the Cisco UMG Network
•Designing the Backup and Restore on a Cisco UMG Controlled Network
Design a Messaging Network with Unique Location IDs
In a Cisco UMG controlled network, the location ID for the Cisco UMG, Cisco Unity Express, Cisco Unity, and Avaya Interchange is used as an identifier for the location. The location IDs of an autoregistered endpoint (Cisco Unity Express 3.1 and later versions), and also the primary and/or the secondary Cisco UMG location IDs are included in the registration messages. The location IDs for manually provisioned endpoints (Cisco Unity Express prior to 3.1, Cisco Unity, and Avaya Interchange) are configured on the Cisco UMG using CLI commands and are shared between the Cisco UMGs during directory exchanges.
Location IDs of endpoints and Cisco UMGs are saved on the Cisco UMG directory table and used for the message routing. You must ensure that all of the Cisco Unity Express, Cisco Unity, and Avaya Interchange location IDs are unique across the entire Cisco UMG network. Without careful planning, it is possible to assign Location IDs that prevent the Cisco UMG from finding a message recipient at another location.
Guidelines for Assigning Location IDs
The numbering plan for assigning location IDs can affect how easily the Cisco UMG matches the number that a subscriber enters when addressing a message. We recommend following these guidelines:
•Establish a fixed length for location IDs, and if possible, a fixed length for extensions.
•Assign unique Location IDs. A Location ID must not be the same as any other Location IDs, system distribution list numbers, or any extension assigned to a subscriber. For example, when assigning a SDL list with number 1100, do not assign a location ID as 110. This results in a conflict during the Cisco UMG search and failure to invoke SDL 1100.
•Assign a numbering range for location IDs that extensions do not use. For example, you can assign Location IDs with leading zeros (0001, 0002, and so on).
•Make sure that the Location IDs you assign for all entities are at least three digits because this is required by the Cisco Unity Dial ID parameter.
•Make sure that the Location IDs for all entities are not more than seven digits because this is the maximum number of digits supported by Cisco Unity Express location IDs.
•If using variable-length location IDs and extensions, the location IDs should be in a different numbering range than the range for extensions. For example, if there is a local extension 527123, do not assign a location the location ID of 527 if there is a possibility that this location will have the extension 123.
•If using variable-length location IDs, the first digits of each location ID must be unique with respect to other location IDs. For example, if you have a location with an ID of 527, do not assign another location the ID of 5277. In this example, during a blind address search, Cisco Unity and Cisco Unity Express would always match the blind address entered by the subscriber to location 527 and fail to find location 5277.
•Follow Cisco Unity and Cisco Unity Express Design Guide regarding Dial ID and Location ID recommendations.
•Make sure that the Location ID you assing are digits only. We do not recommend using * or # for Location IDs.
•We recommend that you configure prefixes the same as the location ID for easier management and a nicer user experience.
Without following these guidelines, subscribers may encounter the following problems when addressing a message:
•A delay while the Cisco UMG searches for a match remote location
•Multiple matches for the number entered by a user
•Failure to find the recipient at another location
Designing an Address Scheme for Your Messaging Network
A subscriber, also referred as a mailbox user, is addressed with the format specified in the VPIM protocol. It consists of a local part and a domain part. The local part is used for the username or mailbox identification; and the domain part is used for the machine identification or domain name. For example, a subscriber with address of 4085550101@xyz.com is in the xyz domain and the mailbox number is 4085550101.
The Cisco UMG supports the following three address schemes for a subscriber or mailbox identification
•E.164 format, a 10-digit unique telephone number for each subscriber (for example, 4085550101@cue-sj.xyz.com)
•Node with primary extension (for example, 1001@cue-sj.xyz.com, on which 1001 is the extension and cue-sj.xyz.com is the node identifier)
•Flexible string lengths which are unique across the network. The exact form depends on the Cisco UMG network dial plan. (for example, 23019@cue-sj.xyz.com where 23019 must be a unique digit across the entire messaging network). The maximum string length is 15 digits based on the E.164 standard.
Guidelines for Choosing an Address Scheme
It is important that you design a Cisco UMG network with a consistent address scheme across all mail systems in the network.
•Choose only one address scheme from the above three addressing schemes to uniquely identify all mailbox users in the Cisco UMG network. The Cisco UMG does not support routing of mixture addressing schemes. (For example, one Cisco Unity Express sending VPIM messages using an E.164 format and another Cisco Unity Express sending VPIM messages using the node + extension address scheme).
•Ensure each endpoint is properly configured.
•Endpoints such as Cisco Unity Express and Cisco Unity can compose a VPIM message using one of the above addressing schemes. If the network is deployed with any combination of Cisco Unity or Avaya Interchange, you must choose E.164 or a unique digit as the address scheme.
Designing a Cisco UMG Controlled Network with Network Optimization
By the very nature of the VPIM protocol over SMTP and remote voice message delivery in general, voice message are not required to be delivered in real time. A voice mail subscriber is accustomed to certain delays in terms of hours between the time the sender sends the voice mail and the time the receiver gets the voice mail on the remote systems, such that no Cisco UMG specific QoS parameters must be setup on an existing network.
However, under certain circumstances on the Cisco UMG deployment, the network bandwidth consumption may be increased. The system administrator should examine the network resource availability and modify the network configuration accordingly.
Choosing Reasonable Timers on Cisco UMG Network
Use the following guidelines when choosing reasonable timers:
•Endpoint Registration Expiration Timer on the Cisco UMG — Because there is no keepalive between the endpoints and the UMG, reregistration HTTP messages are exchanged between the endpoints and the Cisco UMGs when the timer expires. The registration timer is the system parameter that is applied to all the nodes that register with the hosting Cisco UMG. The network traffic may have a burst of traffic from bulk endpoints. The default timer setting is 24 hours. A setting that is too short timer will consume extra network bandwidth but a setting that is too long timer may cause an out-of-sync status between endpoints and its hosting Cisco UMG. We recommend that you set up reregistration events during off peak hours or after hours.
Note The Cisco UMG limits the amount of processing power it spends on registration requests to give priority to forwarding voice mail messages. When many registrations occur simultaneously, some fail and automatically retry.
•Directory Exchange Interval on Cisco Unity Express — When subscriber information is updated on Cisco Unity Express, Cisco Unity Express accumulates the changes that happened within the interval, then sends out directory exchange updates to its hosting Cisco UMG when the timer expires. The default interval is two minutes. When a Cisco Unity Express is doing major imports or exports for subscribers, change the timer accordingly.
•Delayed Delivery Receipt (DDR) timeout and NonDelivery Receipt (NDR) timeout on the Cisco UMGs — By default, the DDR timeout value is one hour and the NDR timeout value is six hours. We recommend that you use consistent DDR and NDR timer settings across all Cisco UMGs in the network.
Choosing Cisco UMG Features Based on Network Resource Availability
•Cisco Unity Express Remote Lookup — When this feature is turned on, Cisco Unity Express invokes remote lookup through HTTP to query location and user information from the Cisco UMG and stores the result in its local cache for future reference. However, the cache size on Cisco Unity Express is limited. Any query that cannot find a match in the local cache consumes network bandwidth and system resources. We recommend that you use blind addressing instead of remote lookup if there are a large number of queries during peak hours without adequate bandwidth.
Note The Cisco UMG limits the amount of processing power it spends on remote lookup to give priority to forwarding of voicemail messages. When many remote lookups occur simultaneously, some lookups may be rejected.
•Spoken Name Confirmation — The spoken name is carried within a vCard during directory exchanges and saved in the Cisco UMG database. A typical vCard without spoken name is about 180 bytes, with spoken name (averaging two to three seconds at exactly 32 Kbps), it can easily exceed 10 KB on a single vCard. In extreme cases, such as 1000 Cisco Unity Express nodes with 50 subscribers on each node, the single SMTP size during the directory exchange between the Cisco UMGs will be tens of megabytes. To be consistent with the Cisco Unity implementation, Cisco UMG limits the maximum SMTP message size to 1 MB during directory exchanges. Therefore, for every SMTP package, the network is able to handle an extra 1 MB in addition to other traffic. We recommend that you disable spoken name using the CLI if the network links between Cisco UMGs are slow.
•System Distribution List — SDLs are shared among Cisco UMGs and can be managed on any Cisco UMG in a network. When exiting from list-management mode on one Cisco UMG, all SDL changes are shared with all other Cisco UMGs in the network. Again, there is a burst of network traffic when SDL synchronization happens between Cisco UMGs. However, you can control the extra traffic load by performing SDL synchronization during off peak hours.
Design a Secure Cisco UMG Network from Both Network and Application Levels
When addressing the security of a Cisco UMG controlled network, you must have a network security strategy that prevents unauthorized access to any Cisco UMG, and must configure the Cisco UMG security features on each node to complement existing network security infrastructure.
To prevent any unauthorized access to the Cisco UMG, the following topics are discussed:
•System and Remote Access
•Local Access
•Remote Access Using Telnet
•Application Environment
•Cisco UMG Access Control Guidelines
•Application Level Security Protection
System and Remote Access
No external interfaces are on the Cisco UMG hardware (physically there is an FE interface port, but it is disabled in software and unusable). All access must pass through the host Cisco ISR router and across the backplane to the NME-UMG and NME-UMG-EC.
Local Access
The only local access to a Cisco UMG is through the host router's console interface by using the following command to open a session to the Cisco UMG:
service-module integrated-service x/y session
Entering this command requires enable mode on the router which is protected by the router's enable login and password settings. Although there is also an enable mode in the Cisco UMG CLI, Cisco UMG has no password capability. Any network administrator with access to enable mode on the router, also can access the Cisco UMG CLI. There is no user ID or password control on the Cisco UMG CLI. Access is controlled via the router, and if logging is required, you must set up the router with AAA/RADIUS monitoring of login access.
Remote Access Using Telnet
Direct Telnet access to the Cisco UMG IP address is disabled by default and an error message of "Unable to connect to remote host: Connection Refused" is returned when access is attempted. Therefore, remote CLI access to the Cisco UMG is only possible by Telneting to the hosting router and then using the session command to get access to the Cisco UMG CLI. That way, all the security protections that are built into Telnet access to your router automatically also protect access to Cisco UMGs.
Telneting to the router using the IP address followed by the explicit TTY port number that is allocated to Cisco UMG is not blocked and can provide undesirable "direct" access to the Cisco UMG.
To protect against this type of access, configure a login and password on the TTY port. In this example, the Cisco UMG module is in slot 1/0 on a Cisco 2811 and has a TTY port of 2066 leading to Cisco UMG, as shown in the following configuration example:
Note Cisco UMG itself does not support SSH. Because all communication between the hosting router and the Cisco UMG module is through the router backplane, Cisco UMG is not exposed to any external interface on IP segments. SSH access to the router is sufficient to protect Telnet access to the Cisco UMG.
Application Environment
The Cisco UMG is an IP application and therefore communicates with its environment using various TCP and UDP protocols and ports, as listed in Table 1.
Note You must ensure all the required ports listed in Table 1 are not blocked for various entities in the Cisco UMG controlled messaging network.
Table 1 Cisco UMG Protocols and Port Numbers
Protocol
|
Cisco UMG Destination Port
|
Cisco UMG Source Port
|
Remote Port
|
Remote Device
|
Notes
|
SSH
|
|
|
22
|
Secure Shell Client
|
Not supported by Cisco UMG. Use SSH to the host router
|
Telnet
|
|
23
|
|
Telnet Client
|
|
DNS
|
|
TCP/UDP 53
|
|
DNS servers
|
|
TFTP
|
|
UDP 69
|
|
TFTP server
|
To load RAM Kernel
|
FTP
|
|
TCP 20/21
|
|
FTP server
|
To install, backup, and restore
|
HTTP
|
|
TCP 80
|
|
Endpoints
|
Registration and remote lookup
|
NTP
|
|
UDP 123
|
|
NTP server
|
To Synchronize Date/Time
|
SMTP
|
|
TCP 25
|
|
Cisco UMG/ Cisco Unity Express
|
Directory Exchange
|
VPIM
|
|
TCP25
|
|
Cisco UMG/ Cisco Unity Express
|
Message Networking
|
Syslog
|
|
TCP 514
|
|
Syslog Server
|
|
SNMP
|
|
|
|
|
Cisco UMG itself does not support SNMP
|
Cisco UMG Access Control Guidelines
•Assign an enable password to the router hosting the Cisco UMG module.
•Restrict Telnet access to the hosting router.
•Enable login and password control on the router TTY port connecting to Cisco UMG.
•Configure an inactivity timeout on the router TTY port connecting to Cisco UMG.
•Enable SSH on the router to protect Telnet traffic; use only SSH-capable Telnet client software.
•Use Access Control Lists (ACLs) to close access to any ports that are not actively in use by Cisco UMG.
•Use ACLs to restrict traffic to and from Cisco UMG.
•Protect the FTP server that is used for software installation with a login/password control.
•Protect the FTP server that is used for backup and restore with login/password control.
Application Level Security Protection
This section discusses the following types of security that are supported on Cisco UMG:
•Security checks during endpoint registration
•End user validation during the messaging delivery
•SDL/SBM authorization
•NAT support
Secure Registration of Endpoints
The Cisco UMG supports the HTTP digest authentication mechanism with shared a registration username and password between the Cisco UMG and its endpoints. If the username or password does not match, the registration fails and gives the response "Unauthorized."
If the registration to the primary Cisco UMG failed with this response, the endpoint does not register with the secondary Cisco UMG sequentially. The endpoint should only continue registration with the secondary Cisco UMG, if it registered with primary Cisco UMG successfully or it cannot reach the primary Cisco UMG and received a timeout response.
The Cisco UMG can prevent nodes from registering by enabling the blocking of CLI commands associated with endpoint location IDs. During the registration message exchange, if the a matching Blocking Location ID is found, the Cisco UMG rejects the registration and gives the response "forbidden" to the endpoints.
The Cisco UMG accepts only VPIM messages sent from the registered endpoints.
Note Blocking an endpoint from autregistration will have no impact on whether you can manually configure an endpoint with the same location ID.
System Distribution List and System Broadcast Message Endpoint Control
The Cisco UMG controls SDL and SBM through subscriber authorization during SDL and SBM creation. By default all subscribers in the list have permission to receive only. Only certain numbers with explicitly granted privileges are able to send SDL or SBM.
In the case of a nested distribution list, if the subscriber has privileges to send to that particular list, the message addressed to that list must be sent to all the members under that list regardless of whether or not that subscriber has privileges to send to any specific member of the list.
For example, a Cisco UMG node has the following SDLs configured:
•SDL0010, which contains subscriber1 who has sending privileges
•SDL0020, which contains subscriber2 who has sending privileges
•SDL0030, which does not have sending privileges
In this example, the following behaviors occur:
•When subscriber1 addresses an SDL message by dialing 0010, it sends the message to all other individual subscribers under SDL0010, and all subscribers under SDL0020 and SDL0030.
•When subscriber2 addresses an SDL message, it can only send the message to all the subscribers in SDL 0020 by dialing 0020. It cannot send the message to the members under SDL0030 or any individual subscribers under SDL0010.
•When subscriber2 addresses an SDL message by dialing 0010, the Cisco UMG rejects it, resulting in an NDR to subscriber2.
•All subscribers under SDL0030 only have receiving permit. They cannot send SDL messages to any SDL list.
Note The total number of SDL members (subscriber or nested lists) in any SDL list within the entire Cisco UMG network cannot exceed 10000.
NAT Support on Cisco UMG
The Cisco UMG can be configured to use a NAT translation table to address NAT and firewall issues on the customer deployment environment. The NAT table consists of a list of internal IP address paired with the external IP address and ports. The Cisco UMG will look in this NAT table using the internal IP address to query the external IP address and port to determine the actual transport information.
In this section, the NAT examples use the Centralized Cisco UMG model and Distributed Cisco UMG model as reference to provide the recommendations.
Centralized Cisco UMG with NAT: Example
Figure 1 Centralized Cisco UMG Deployment with NAT
In this scenario, NAT blocks the following processes:
•Registration of the remote region Cisco Unity Express nodes on port 80
•Directory exchange between remote regions and the headquarters on port 25
•Message delivery to and from remote sites on port 25
To avoid these issues, we recommend that you:
•Configure the Firewall/NAT to statically open a pinhole on port 25 and port 80.
•Configure the Cisco Unity Express nodes on remote sites to register with the external IP address of the Cisco UMG on the headquarters NAT device. The NAT must be configured with a static mapping from the external IP address to the internal IP address of Cisco UMG.
•If multiple Cisco UMGs are behind the same NAT device (multiple Cisco UMGs may share the same external IP address), the endpoints on remote sites are able to communicate with Cisco UMGs using the different ports other than default 80/25. For example, the forwarding table on the headquarters NAT device may have a mapping table like this:
Forward 128.1.1.1:180 10.1.1.1:80 for UMG-1
Forward 128.1.1.1:181 10.1.1.2:80 for UMG-2
•On the remote site endpoint, the internal and external IP addresses must be configured on the Cisco UMG NAT table. The Cisco UMG looks in the NAT table to find the external IP address of the regional NAT device. The NAT device forwards it to the Cisco Unity Express after it maps the external IP address and the port to the internal IP and the port. For example, Cisco UMGs from the central site send VPIM message to remote region Cisco Unity Express with 128.1.1.3:126 instead of 10.1.1.3. The NAT table on the UMG might look like this:
Table 2 The NAT Table on the Cisco UMG at the Central Site
Peer
|
Internal IP Address
|
External IP Address
|
External HTTP Port
|
External SMTP Port
|
1001 (CUE-East-1)
|
10.1.1.3
|
128.1.1.3
|
1081
|
1026
|
1002 (CUE-East-2)
|
10.1.1.2
|
128.1.1.3
|
1082
|
1027
|
2001 (CUE-West-1)
|
10.1.1.1
|
128.1.2.3
|
1081
|
1026
|
2002 (CUE-West-2)
|
10.1.1.2
|
128.1.2.3
|
1082
|
1027
|
•If multiple Cisco Unity Express nodes sit behind the same NAT device, the Cisco UMG should be able to communicate with endpoints on different ports other than 25. Multiple endpoints can share the same external IP address. For example, the forwarding table on the region NAT device might have a mapping table like:
Forward 128.1.1.3:125 10.1.1.3:25 for CUE-1
Forward 128.1.1.3:126 10.1.1.4:25 for CUE-2
Distributed Cisco UMG Model with NAT: Example
Figure 2 Distributed Cisco UMG Deployment with NAT
In this example, NAT breaks both directory exchanges and message delivery because the routing table on the Cisco UMG will be built up with internal IP addresses which may not be reachable. The registration messages using HTTP port 80 are not blocked by the NAT devices in this scenario.
To avoid these issues, follow these guidelines:
•Configure the Firewall/NAT on both remote region and central sites to open a pinhole on port 25.
•Manually configure the NAT table on every Cisco UMG in the network to map the internal IP addresses to external IP addresses. The Cisco UMG will use the external IP addresses and the port numbers of its peer Cisco UMGs to exchange directory information and deliver the VPIM messages.
•If multiple Cisco UMGs are behind the same NAT device (multiple Cisco UMGs can share the same external IP Address), the Cisco UMG in other locations should be able to communicate with the Cisco UMGs on the different ports other than default 25. For example, the forwarding table on the headquarters NAT device might have the mapping table like this:
Forward 128.1.1.1:125 10.1.1.1:25 for UMG-1
Forward 128.1.1.1:126 10.1.1.2:25 for UMG-2
•The NAT on the headquarters Cisco UMG might have a mapping table like Table 3:
Table 3 The NAT Table on Central UMG
Peer
|
Internal IP
|
External IP
|
External SMTP Port
|
1101 (UMG-East-1)
|
10.1.1.10
|
128.1.1.3
|
1026
|
1102 (UMG-East-2)
|
10.1.1.11
|
128.1.1.3
|
1027
|
2101 (UMG-West-1)
|
10.1.1.10
|
128.1.2.3
|
1026
|
2102 (UMG-West-2)
|
10.1.1.10
|
128.1.2.3
|
1027
|
Designing the Fail Over Scheme in the Cisco UMG Network
As addressed earlier, the Cisco UMG supports a one-to-one active/standby fail over scheme. The secondary Cisco UMG does not have to be allocated in the same location as the primary Cisco UMG when the reliable IP connectivity is established between them.
The following points describe how Cisco UMG one-to-one failover support works:
•The failover can happen during endpoint registration, directory exchange, remote lookup, and message delivery. The Cisco UMGs must b e able to automatically detect and recover from a failover, including when the directory information is out-of-sync.
•For pairs of Cisco UMGs with one-to-one redundancy, the endpoints only send out directory updates to the primary Cisco UMG. The primary Cisco UMG publishes the information update to its all peer Cisco UMGs including its secondary Cisco UMG.
•If the endpoint cannot register with its primary Cisco UMG on the first attempt because of an unmatching username or password, it cannot register with its secondary Cisco UMG until the registration succeeds on its primary Cisco UMG.
•Because of the limitations of Avaya Interchange, only one Cisco UMG is allowed to send VPIM messages over it. Therefore, Avaya Interchange does not support failover on a Cisco UMG network.
•Because Cisco Unity does not support multiple VPIM endpoints pointing to the same remote user, or the multiple VPIM delivery locations pointing to the same remote location, the DNS must resolve IP addresses using the same hostnames that have different MX record priorities.
•For failover support on the older version Cisco Unity Express, the system administrator must manually provision it on the Cisco UMG endpoints.
Guidelines for Deploying Failover Support on the Cisco UMG Controlled Messaging Network
•Deploy dedicated primary and secondary Cisco UMGs; do NOT share the primary and secondary functionality on the any single Unit. For example, use UMG-1 as the primary Cisco UMG for the east region and UMG-2 as secondary. Do not use UMG-1 as secondary Cisco UMG for west region, and do not use UMG-2 as the primary Cisco MG for west region. Make sure you use the active/standby model, not the active/active load balancing model.
•Do not mix different Cisco UMG Hardware on the failover setup; always choose the same form of hardware for each Cisco UMG active/standby pair. For example if you use NME-UMG as the primary Cisco UMG, also use NME-UMG for the secondary. If you use NME-UMG-EC for the primary Cisco UMG, the secondary Cisco UMG must also use NME-UMG-EC to avoid causing the directory information to go out-of-sync because of a capacity mismatch.
•Because the Cisco UMG failover is transparent to the Cisco Unity, Cisco Unity must have DNS in order to resolve the primary and secondary Cisco UMG IP addresses from the single hostname into two MX records. We recommend that you set up MX records for both primary and secondary Cisco UMGs with different priorities.
•Ensure that endpoints can register with its primary Cisco UMG for the first time without any issues. Verify the IP connectivity and shared user name and password to avoid potential out-of-sync risk on directory information.
•We strongly recommend that you use the one-to-one full redundancy setup. Do not share the secondary Cisco UMG between different sets of endpoints. For example, set up UMG-1 as the primary Cisco UMG for the east region, and UMG-2 as the secondary Cisco UMG. Do not also use UMG-2 as secondary Cisco UMG for the west region. The west region should have its own primary and secondary pair of Cisco UMGs.
Designing the Backup and Restore on a Cisco UMG Controlled Network
A Cisco UMG uses the FTP server for backup and restore with two options:
•Configuration only backup and restore— Backs up all the system configuration including the peer gateways, manually configured endpoints (older version Cisco Unity Express, Cisco Unity, and Avaya Interchange), registration credentials, NAT configuration, default route, and other system configuration information as displayed by the show startup-config command.
•Configuration plus data backup and restore — In addition to backing up the entire system configuration, also backs up dynamic operational data that the Cisco UMG requires during runtime, such as auto-registered endpoint information, directory information from the local endpoints, and snapshots of the system distribution list and the system broadcast message.
Restrictions
•The directory and endpoint information advertised from the peer Cisco UMGs is not backed up.
•Backup and restore can only occur in offline mode.
Best Practices
The best practices with the Cisco UMG backup and restore are:
•We do not recommend performing data-only backups and restores. Performing data-only backup may introduce system inconsistencies because the conflicts the between existing configuration and the data being restored.
•Perform a copy running-configuration startup-config or write memory before the backup to ensure the system consistency across backup and restore.
•The snapshot information of the system distribution list and system broadcast message can be changed during backup and restore procedures. You should perform a manual synchronization of the SDL/SBM from/to the peer Cisco UMGs.
•Avoid security concerns by ensuring the appropriate secure tunnel is setup between the Cisco UMG host router and the FTP server.
•The storage of backup files is only as secure as the access to the FTP server. The files are not encrypted unless an offline utility is used to encrypt these files after Cisco UMG has completed its backup (and decrypt them again before attempting a restore operation).
