Avaya SBCE Network Interface issues

 I was tasked with configuring a small Avaya SBC this week. I was sent a Dell 3240 system for this job. 

When I tried to power it on I was not able to get it to boot. I did some digging in the product manual and found a chart that showed what different LED sequences meant. I was getting three amber flashes and one white flash which meant that the CMOS battery was dead! Fortunately I keep a few batteries around and I was able to swap it out. The system powered on right away and I was able to load the SBC software.

You would think that would be it - off to the races, ready to go. Unfortunately there was one other problem. I was able to install the software and perform the CLI installation procedure without any hiccups. When I went to connect it to the lab network to perform the web config, though, I found that I was unable to reach the SBC and the SBC Was not able to reach my network. When I checked the interfaces it looked as if M1 was down! Not just that, but I also saw an A2 address that I thought was out of place. The additional network interface was my smoking gun - it was the built-in network interface. I went into the BIOS and disabled it, but that put me in worse shape - the M1 interface was now just missing entirely. I reloaded the software and everything worked out.

Here are some of the things I searched:

• Avaya SBC network interfaces wrong
• Avaya Dell 3240 bios
• M1 interface not responding
• Avaya SBC MAC Address wrong
• Avaya SBC M1 Down

Installing the Avaya SBCE on Proxmox

It has been a while since I've posted anything on this blog, and that is an issue. It's not that I've been slacking - I started a new blog about non-telecom stuff, after all. I just haven't had anything exciting to write about in a while.

All of that changed today. I made a decision: I'm going to do something that hasn't been documented before. So I decided to try to get an Avaya SBCE installed in an environment that is not officially supported - Proxmox.

I had to make two attempts. I wasn't able to get the system to boot when I used the qcow2 image that was available from Avaya, so I blew that machine away and created a new VM with no OS.  I'm not going to go into the failed install - I learned from my failures so that you can succeed on your first try.

I chose to do EMS+SBCE for my deployment rather than separate out the servers. I will document the differences that would be necessary to have a standalone EMS. A standalone SBCE has the same configuration.

First, I had to build the VM. In order to determine how to configure it, I looked at the Avaya documentation. I mostly went with the Small SBC because I'm just doing a Proof of Concept, and not a production system. I did opt to go with six network interfaces though. If I were deploying a true production system I would have created one SBC and one EMS. 

In Proxmox, I clicked on Create VM and started to build by virtual machine. On the General tab I selected my Proxmox node and entered the VM name. I accepted the VM ID that was automatically created.

The OS was loaded from an SBCE ISO that I had uploaded to the software library on my server. The OS is Linux, and I selected the 2.6 Kernel.

I didnt' make any changes to the graphics card, machine, or SCSI controller. I did ensure that I used a UEFI BIOS. I selected the appropriate storage pool.

I created a single 64GB disk. If I was planning on creating a production system I would consider expanding the disk to 160GB to support additional logs, as the Avaya documentation suggested.

I chose one socket, 2 cores, for a total of 2 cores. If this were a standalone SBC I would have set this to 4 cores. A standalone SBC Requires 3 cores. Proxmox doesn't do CPU reservation like VMWare, so there is a risk here. If I were creating a production system I would enable CPU affinity and lock the SBCE to specific cores. Maybe I'll write something up about that on my tech blog some day.

I gave this the 4GB o RAM that the small size requires. If I were deploying this as a standalone SBC or an EMS I would have set this to 8GB.

You can't configure more than one NIC during the initial setup of a virtual machine in Proxox, so I left the existing interface in place on my default bridge. 

I reviewed the configuration and made sure that I did not have Start after created checked - I need to add the additional network interfaces before I do that. 

I have configured VLAN 11 as my trusted network and VLAN 12 as my untrusted network. VLAN 11 is not able to reach the Internet, and VLAN 12 is only able to reach the Internet. I ran through the installation without knowing what order the interfaces were going to be in, so after I started up the machine I confirmed the interface order. Next time I'll assign the VLANs when I create the interfaces. Of course, it's important to confirm the MAC Addresses after the system comes up.

M1: net0    Management VLAN

M2: net1    Segregated network for HA

A1: net2    Inside network 1

B1: net3    Outside network 1

A2: net4    Inside network 2

B2: net5    Outside network 2

Once the network interfaces were added I started the virtual machine. It took a minute but the Linux installer began. I selected the default option: Install ASBCE with Redhat Enterprise Linux 8.10. In retrospect, I couldn't help but wonder if the proper choice should have been Install ASBCE RHEL8.10 using CDROM. If I do it again I will select the CDROM option. 

The installation script ran and created a bunch of different partitions and installed a lot of packages. After some time the SBC settled down and prompted me to enter Manual Configuration Mode.

I selected Option 1 to configure using Command Line Mode. I was prompted for the basic configuration.

I was prompted for information for the self-signed certificate that the SBC presents.

The time zone selection was next - first a region, then a country, and finally a time zone. 

I did not have a proper NTP server configured, so the system did kick back an error that I didn't capture - it was asking me to set a proper NTP server. I selected Option 3 - to skip NTP.

Now I'm able to reach the SBC web interface.

After agreeing to the EULA I am able to log in with the default credentials. I must immediately change the password and am logged out again. After logging in again I am now ready to configure the SBC.

Oh wow, you made it to the end of the post! As a reward, enjoy this link to my tech blog. https://blog.aarondydck.ca/

NRS Backup location

 Any time I've had to recover a signaling server the biggest concern is extracting the NRS database and recovering it. The NRS backup file can be pulled as long as there is access to the file system.

The file is located at /var/opt/nortel/sps/backup/nrsback.tar

Once the NRS file is in hand the rest is easy.

Voicemail Pro Automatic Service Restart

Today someone asked me if Voicemail Pro on Linux would attempt an automatic restart if the service failed, as it would in Windows. Unfortunately the answer is a resounding NO!

I've been using Linux for years and I didn't see any technical reason why this couldn't be done. I decided to do some digging, and I believe that by making the changes I outline below to the Voicemail Pro service you should be able to have it automatically restart in the event of an abnormal termination. 

DISLCLAIMER: I have not tested this in a production environment. This is not supported by Avaya. If you need this functionality you can implement this fix at your own risk. I suggest opening a GRIP Request with Avaya to have them add this functionality to a new release! 

First, you will need to log in to the Application Server as the root user. Once logged in the next step is to edit the Voicemail Pro service. Enter the following command:

nano /etc/systemd/system/vmpro.service

This will launch the GNU nano editor, allowing you to modify the service directly. The image shown here is the configuration before any changes are made.

Use the arrow keys to navigate to the Service section. In order to tell the service to automatically restart we need to add the following lines:

Restart=on-failure

RestartSec=30s

StartLimitIntervalSec=200

StartLimitBurst=5

This tells the service to restart on failure after waiting 30 seconds, to a maximum of five times. 

Once the changes have been made, use <CTRL>+O to write the file, then <CTRL>+X to exit nano.Once back at the command prompt the system needs to know that you've made changes. Enter the following command:

systemctl daemon-reload

Once this is done the Voicemail Pro service may need to be restarted (again, this is untested), so go ahead and restart the service. 

These instructions should work on any Linux-based IP Office release to date, however future releases may include an updated version of systemd, the process that controls Linux services. If Avaya includes a newer version of systemd these instructions will need to be modified. 

If you do try to implement this, please let me know how well it worked in the comments.