Configuration Changes

We are moving away from hand editing SMG configuration files, and moving toward using the smgcfgXX.py tool. XX is the version. We are currently using 01 and working on 02 now.

The tool uses a .csv file as input and the output are the wanpipe, ss7box, and ss7boost conf files. The .csv file comes from the export function in any spreadsheet program.

We support googledocs spreadsheets:
http://spreadsheets.google.com/ccc?key=rzeNA2SoiXKhaKX7Y9t2keg&hl=en

The smgcfgXX.py program is a Python script and is included with each SMG release.

We are working on an improvement where the smgcfg.py script will read the revision number in the .csv file and use the corresponding smgcfgXX.py script to continue processing.

ss7box Redundancy Explained

Two ss7box are better than one as is usually the case in SS7 networking. If one fails or needs to be worked on, the other carries the load and there's no interruption in operations. The next question is, "How will that work?"

The first thing that's needed is a two-link linkset as shown in Figure 1 below. The links need to be in two separate E1/T1 spans. Each span is connected to Sangoma wanpipe port on a separate Linux box. Each Linux box is running an instance of ss7box. This is the F-Link setup most often found in ITU networks.

Figure 1

In Figure 2 the left hand SSP from Figure 1 is shown as an Sangoma SMG implementation using redundant ss7box. ss7box and SMG communicate using SCTP/IP. SMG communicates with Asterisk using TCP/IP and UDP/IP. SMG can receive from either ss7box at any time. SMG sends to the pair of ss7box using a load balancing scheme. If one of the links to an ss7box is lost, or if an ss7box is lost or is under maintenance, then the full signaling load is handled by the remaining ss7box. When the second ss7box returns to service, load is automatically balanced between both ss7box.

Figure 2

ANSI networks and some ITU networks use redundant signal transfer points (STPs) to interconnect signaling terminations like signal switching points (SSPs) as shown in Figure 3. In this type of network there will be a combined linkset between an SSP and a mated pair of STPs. A combined linkset, in its simplest form, is a pair of single-link linksets. The SSP connects to both linksets. Each STP in the mated pair connects to one of the two linksets. The same rules

Figure 3

In Figure 4 the SSP from Figure 3 is shown as an Sangoma SMG implementation. The same rules regarding load balance, fail-over, and fail-back listed for the F-link configuration above also apply to this A-link (or combined linkset) configuration.

Figure 4

Redundant ss7box; GRS and Configuration Improvements

ss7box redundancy is the next big feature in the works. Now that SMG clustering is in the field and working, some larger systems are being designed. As predicted, those system designers quickly spot a single ss7box as a single point of failure. The solution is to deploy two ss7box acting as a single entity - so called redundancy. If one ss7box is lost then operations continue without interruption.

A redundant ss7box configuration minimizes interruptions during upgrades because one ss7box can serve on-going operations while the other is off-line and being updated. Then the updated ss7box serves operations and other ss7box is updated. Finally, both updated ss7box are put online and normal redundant operations resume.

We found a flaw in GRS processing in the past two weeks. The fix required enhancing GRS processing so that each trunk group has its own GRS queue. The ehancement is used if GRS processing gets stuck in ss7boost and the remote end keeps repeating requests for GRS. In this scenario, GRS requests are queued and after N queued GRS, the GRS queue overflows. When this happens, the GRS queue is cleared, all circuits in the trunk group associated with the GRS queue are put into quarantine, and subsequent GRS for the trunk group are ignored until all circuits in the trunk group have exited quarantine. The persistent nature of the GRS protocol ensures that a GRS will arrive after the GRS queue clearing protocol has completed. As ss7boost matures, more of these complex, self-healing protocols are being implemented which make SMG more robust and reliable. I makes SMG easier to use and maintain for users and support staff.

The smgcfg.py script is helping users and support staff create, update, and maintain SMG configurations. With the introduction of SMG clustering it became evident that hand editing text configuration files was unwieldy. With smgcfg.py the entire configuration for a node is entered in a single spreadsheet tab. We are using Googledoc spreadsheets to enable editable sharing of SMG configuration spreadsheets on a worldwide basis.

Check out the Twitter feed on this blog. Small increments of progress are reported in that media stream