Avaya CM5.2 ESS Server Successfully Tested for both PN/H.248 Connected Networks!

Avaya Communication Manager 5.2 with S8730 IPSI Port Networks AND remote H.248 Gateways failover tested to S8510 ESS via Processor Ethernet (not PN). Now in customer production!

Support for Processor Ethernet and Port Networks on an ESS server.


NEW in Avaya Communication Manager Release 5.2 and later, the capabilities of ESS servers are enhanced to support connection of IP devices to the Processor Ethernet interface as well as to C-LAN interfaces located in G650 (port network) gateways.


An Enterprise Survivable Server (ESS) can use its Processor Ethernet interface to support IP devices such as H.248 Media Gateways, H.323 Media Gateways, IP Adjuncts, IP telephones, IP trunks, and SIP trunks. The ESS can optionally control port networks (G650 Media Gateways) through IPSI at the same time. When there are no port networks in the configuration, ESS may provide the equivalent benefit of an LSP. The ESS can be duplicated, providing additional redundancy to the survivability of the system.


For Processor Ethernet on duplex servers to work, you must assign the Processor Ethernet interface to the PE Active Server IP Address (IP-alias) and not the server unique address. The NIC assigned to the Processor Ethernet interface must be on a LAN connected to the main server.


- If the LSP or ESS registers to the C-LAN on the main server, the C-LAN must have IP connectivity to the LAN assigned to the NIC used for Processor Ethernet on the ESS.


- If the LSP or ESS registers to the Processor Ethernet on the main server, the Processor Ethernet on the main server must have IP connectivity to the LAN assigned to the NIC used for Processor Ethernet on the ESS.

Avaya Gratuitous ARP

In Avaya CM 5.2 the"Alias" IP Address (not Virtual MAC) for PE requires Gratuitous ARP to be ENABLED on your router.  

The way Avaya lets everything on the same subnet know (at a layer 2 level) of a change is by sending out a Gratuitous ARP so the new MAC address is known. Cisco by default disables Gratuitous ARP which causes a delay by waiting for the ARP cache in the router to expire on the subnet before the new packets can successfully travel.

Confirm Gratuitous ARP is enabled and accepted by your routers to avoid any issues.

The New Avaya S8800 Series and a New Common Server Strategy

With the upcoming releases of Avaya 5.2.1, Avaya is introducing the new S8800 Server which leverages the latest Intel Xeon E5500 series (Nehalem) processor technology and is available in both 1U and 2U form factors - pending expansion needs.  The S8800 server is already in early adoption release and will be generally available in November 2009.

The S8800 "common server" will be available for the following applications:

- Avaya Aura Communication Manager
- Avaya Aura midsize enterprise solution
- Avaya Aura Modular Messaging
- Avaya Aura Session Manager
- Avaya Aura SIP Enablement Services (SES)
- Avaya Aura System Manager
- Avaya Message Networking
- Avaya one-X Speech
- Avaya Proactive Contact
- Avaya Aura Application Enablement Services
- Avaya IQ
- Avaya Meeting Exchange
- Avaya one-X Mobile
- Avaya Voice Portal

Why using SSH/SCP is more secure than Telnet, FTP, or SNMP on Avaya Solutions

Connection protocols that send data (especially logins and passwords) in plain text, that is, unencrypted or "in the clear," can pose a serious security risk to a VoIP enterprise. Using protocols that send data encrypted, such as SSH and SFTP, avoids exposing critical data on the wire. Partly due to new legislation and stricter auditing requirements, Avaya has implemented more secure protocols in its secure connection design.

By default, Avaya disables TELNET and FTP since they are inherently insecure network services.

Avaya products ensure that authentication credentials and file transfers are protected when sent across the network by using:
* Secure Shell (SSH)
* Secure Copy (SCP) or SFTP
* SNMP with these stipulations:
   - SNMPv3 is the preferred version due to its built-in security mechanism.
   - SNMPv1 or v2c, while supported, provide only a limited security capability based on community names:
   - The community name for SNMPv1 and SNMPv2c is protected when accessing writable MIBs.
   - For read-only MIBs SNMPv1 and SNMPv2c community names are unprotected.

SNMP security secrets (for example, community strings) are customer-administrable.

* Other protocols protected using a TLS or IPSEC connection

Need more info?  Get it at www.packetbase.com/freeresearch.

It's all about UC.