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/

65 key things to remember for the Avaya SBC Exam

1. Remote worker cluster using a Real Server IP and Real Server Port will use HTTP and HTTPS for registration requests.
2. Domain Policy Administration configures Rules, Policies, and Endpoit Policy Groups.
3. Trunk Server and Call Server Server Flows are administered in SIP Trunking.
4. Trunk Server and Call Server media interfaces are administered in SIP Trunking.
5. When integrated with IP Office the SSL VPN connection for SBC remote access is always on unless the connection to the Avaya VPN Gateway is down.
6. IP address and transport protocols are configured in a Server Profile.
7. Remote Worker is typically intended for remote users, travelling employees, and remote offices.
8. Before configuring SIP trunking the SBC must be installed and commissioned.
9. Topology Hiding Profiles hide source and destination IP addresses.
10. The Received Interface (as defined in Call Server Flow Administration) is an internal interface that receives inbound traffic.
11. Server Profiles define the connection and transport parameters from the SBC to the service provider and to the call.
12. Two routing profiles are required for a SIP trunk.
13. Before implementing SBC Remote Worker the SBCE + Advanced Feature Set must be installed and commissioned.
14. Cluster Administration groups endpoints and applies similar attributes to them.
15. The SBC routing profile defines the next hop for SIP traffic.
16. A Server Profile applies to the trunk server and the call server.
17. The Supervisor account has the least system access.
18. To test the SBC configuration you should make internal-to-external and external-to-internal test calls.
19. When using an SBC with CM or CS1000 you should use SAL for remote access.
20. A SIP trunk requires a SIP Service Provider (ISTP), an SBC, and a Call Server.
21. With regards to application of Time of Day policies the packet is examined first, then the time of day is evaluated, after which the flow is determined and finally the policy is applied.
22. Best practice for SBC Remote Worker configuration is to fully encrypt both media and signalling.
23. Topology Hiding can be used to change SIP message parameters.
24. Media Interfaces define the IP addresses and ports for media.
25. To administer a signalling interface you must first add the signalling interface, then assign IP addresses and ports.
26. Session Manager can function as the Personal Profile Manager for a Remote Worker cluster.
27. Domain Policy Administration is where you would implement time of day restrictions.
28. Trunk Server and Call Server Signalling Interfaces are administered in SIP Trunking.
29. The Admin user has the highest privilege level to administer the SBC.
30. To verify a standalone installation you can log in to the SBCE GUI or log in the the SBC CLI.
31. Four networks and subnets are required to commission the SBC and SIP Trunking on an SBC located in a DMZ.
32. The Standalone SBC Software is the same as the SBC+EMS software.
33. A Standalone SBC requires the EMS+UC-Sec installation type.
34. HA Configurations always require a standalone EMS.
35. A Network Assessment is the only way to highlight a problem with inadequate bandwidth on the customer's network.
36. All SBC and EMS elements require Network Passphrase Authentication in a High Availability configuration.
37. HA installations are done using the installation type UC-Sec.
38. The EMS should be configured on M1 in a co-res (standalone) configuration.
39. A Site Survey will provide information on customer readiness.
40. In the EMS GUI you can identify the standby SBC by the SBC name.
41. The SBC is shipped with a serial cable or an RJ-45 to Serial cable to connect to the console port on the SBC for initial software installation.
42. In an HA SBC the M2 interfaces carry heartbeat information.
43. The SBC uses SSH port 222 for CLI access (Not port 22).
44. An SBC alarm will be triggered by System Level failures.
45. The SBC has a utility called Call Trace to monitor a single telephone.
46. The SBC Call Trace shows signalling level information for a specific URI (phone).
47. SBC incidents indicate a problem with the SBC software.
48. SBC Call Trace information can be viewed in the SBC GUI under Diagnostics\Protocol Tab.
49. A manually created backup can be called snapshot.zip.
50. You can look at System Incidents to find details of SBC operational problems.
51. SBC Alarm Descriptions can be found in the  Appendices of Administration Guide of the SBC documentation.
52. The Link status/activity LEDs, hard drive LEDs, and over-temperature LEDs can give you a visual alert of a problem with the SBC.
53. SBC backups can be stored both locally and remotely.
54. You can view SBC System Alarms in the SBC GUI.
55. An SBC will show up as Ophaned in the EMS if there is a mismatch between the SBC and EMS software levels.
56. When upgrading an HA system you first upgrade the EMS, then the backup SBC, then the primary SBC.
57. Denial of Service (DoS) is an availability attack.
58. The DMZ is a neutral demarcation point between the trusted and untrusted network in which the SBC can be deployed.
59. A High Availability SBC will require a standalone SBC.
60. The SBC can be deployed inside the enterprise core or in a DMZ.
61. Advanced Services adds the Mobile Workspace (AKA Remote Worker) functionality.
62. Eavesdropping is an example of a confidentiality attack.
63. An SBC provides secure enterprise communications.
64. Signalling Manipulation is using the SIP Trunk Integration Module scripting language.
65. Signalling manipulation can modify the domain part of the SIP packet.