What is SAL?
SAL is Avaya’s Secure Access Link. It is a multipart solution that provides remote connectivity to customer environments for alarm purposes and Remote Access for maintenance or project work. A SAL solution consists of Managed Elements (identified by their SEID), a SAL Gateway (located on the customer Premise), and a SAL Concentrator (located one the “provider’s” network – ie either Avaya or a Business Partner).
What is a SEID?
The System Element Identifier (SEID) is a number that is assigned to each “managed element” of a solution. This identifier is assigned by Avaya and ultimately associates a component of Aura with the maintenance services offered by either Avaya or a business partner (or both). At a very high level, think of this as any product that might need to be accessed remotely or that might generate alarms. Each would be assigned a SEID and would be associated with a SAL gateway located on the customer’s prem. The reality is that each product may actually have several SEIDs.
What’s the time sensitive issue related to SAL?
Avaya, like most software companies, are eliminating support for older, less secure communication methods. Security techniques must always be improving simply because hackers’ hardware and expertise in cracking ciphers, is constantly improving. What was VERY secure 5 years ago, is no longer now. Older Avaya solutions were using SHA-1 based security certificates, which been identified as no longer secure. Avaya has been supporting SHA-2 (Also known as SHA-256), which is the current standard, but Avaya will be removing support for SHA-1 towards the end of the year. Every customer must ensure that their SAL gateway has been upgraded to a release that also supports SHA-2. If they don’t, their older SHA-1 based SAL Gateway, will no longer be able to communicate to the provider’s SHA-2 based Concentrator. This means that the provider will NOT be able to remotely access the customer’s system and the customer’s system will not be able to communicate any type of alarm to the provider.
If I ignore this PSN and do not upgrade my SAL Gateways, will it be service impacting to my users?
Short answer is no, the core applications (voice, messaging, etc) will currently continue to function if the SAL gateway is not upgraded. But your maintenance provider will NOT be able to receive maintenance alarms that could have generated due to a service affecting issue. That provider may also not be able to access the system to perform any service remediation or project work. Note that there is also an effort to upgrade other Security Certificates (for the same reasons of better security) related to media/signaling encryption, but those efforts are a completely different topic and independent from this SAL issue.
Can you make this upgrade yourself?
Yes, Avaya declares this to be customer installable. The reality is that there MAY be some complex tasks here that an average customer just doesn’t have experience with. Older embedded SALs require an upgrade of several things. They require the upgrade of the SAL itself, the System Platform that the SAL is installed on, and the Solution Template that is also installed on that System Platform. Most will want to seek the support of our teams.
How do you know if you need to upgrade your SAL?
It’s really all about the version. For embedded SALs, they must be at least version 18.104.22.168.1. For stand alone, they must be at least 22.214.171.124.6.
If I upgrade to a current release of Aura, can I avoid the conversation about the need for this SAL upgrade?
Definitely. Obviously, the SAL needs to get upgraded regardless, but focusing attention to doing a dot release upgrade (i.e. 6.1 to 6.3) or a major upgrade (from 6.x to 7.0) puts the value on the enhancements of the application, where it should be. Just remember that you still MUST get the SAL upgrade by the end of the year. So, a project that ends in 2017 will be too late, and cause serviceability issues.
SAL Server Specifics
What’s the difference between a stand-alone SAL and an Embedded SAL?
Basically a Stand Alone SAL is a physical or virtual Server that is dedicated to running one application known as the SAL Gateway. An Embedded SAL is one that is actually part of a collection of co-resident applications that run within Avaya’s Appliance-based virtualization platform called “System Platform.” A Stand Alone SAL has the capability to manage as many as 500 SEIDs. An Embedded SAL can only manage 15 SEIDs.
Standalone SALs seem to be the better way to go (less dependencies on other things), why are there so many embedded SALs?
When SAL was first introduced with Aura 6.0, open VMware-based virtualization wasn’t supported. Deploying a standalone SAL meant deploying a separate physical server. Granted, this could be customer provided (where the customer provided both the hardware and the Linux operating system) or Avaya provided (with system platform and a sole SAL Server.) Most did not want to do this. So, they chose to use the embedded SAL that could run co-resident with the solution template itself. There was also a thought that providing a SAL that would run locally at a remote site (where a Remote LSP might be located), would provide better resiliency in the event of a WAN outage. The reality is that most customers don’t provide local internet access at those remote locations. They require all internet traffic to go back to the main site. So, even though they had a local SAL, it had no way to get out of the remote site because internet access was lost. The reality is that if the system is programmed correctly, there’s no need for the access into the remote site. The main site will alarm once it loses registration from the LSP/gateway, the LSP gateway will take over exactly as it should, and once the WAN is back up, it will re-register back to the main system automatically.
What are the advantages and disadvantages of using a standalone SAL?
The biggest advantage is that there are very few limitations on the inter-dependencies between SAL and the managed elements that it supports. The disadvantage is that it requires an additional server. However, that disadvantage is mostly eliminated with the ability to virtualize the SAL in VMware.
Can I virtualize the stand-alone SAL?
Absolutely. Technically, it can ONLY be virtualized, it is either virtualized within Avaya’s appliance model with System Platform (which is XEN based) or in VMware. Both are appliance based and delivered as OVA’s (meaning that the installable “package” contains everything needed; the Linux OS, the application, the management software, etc).
When we say “embedded” what does that actually mean?
Embedded actually means that it is installed “co-resident” with something else on some platform. That “something” is usually your application such as Communication Manager, Aura Messaging, System Manager, etc. and that “platform” is usually the XEN-based hypervisor that Avaya calls System Platform. The biggest problem is that all three of these things are very interdependent on each other. One version of application, requires a specific version of System Platform, which requires a specific version of SAL.
What are the advantages and disadvantages of using an embedded SAL?
The biggest advantage is that it doesn’t require a separate physical or virtual server. It is installed on the same “System Platform” where the Solution Template (Communication Manager, Aura Messaging, System Manager, etc.) is installed. The biggest disadvantage is that all three of these things are very inter-dependent on each other. One version of application requires a specific version of System Platform, which requires a specific version of SAL. This can cause a lot of additional effort (i.e. cost) to upgrade everything, when only one of the items actually needs the upgrade.
For embedded SAL, what version of SAL is included with the various versions of System Platform?
Embedded SAL version 1.8 came on System Platform 6.0. Embedded SAL 2.1 came on System Platform 6.2. Embedded SAL 2.2 came on System Platform 6.3.
I have a lot of embedded SALs—do I have to upgrade all of them?
Short answer is yes, if you want to keep using the embedded SAL. Another option is to create a new centralized standalone SAL and redirect all of the managed elements to the new single SAL. We would then decommission the use of the existing embedded SAL’s
I like using multiple embedded SALs for redundancy purposes. Is there a better option?
Absolutely. In fact, having multiple embedded SALs doesn’t give you any redundancy as each managed element was registered to only one embedded SAL. You could certainly say that you “Don’t have all of your eggs in a single basket,” but this is not redundancy. A better option is to use TWO Standalone SALs and configure the managed elements to report to register to both in a true redundant, high availability model.