Tuesday, January 10, 2017

DevOps and Radiator, part 1

With the first release of the Radiator VNF coming this year, it is a good time to take a quick look at the DevOps model, how we have embraced it, and how it will be on the center of the stage in Radiator VNF.

This post tells you a bit about DevOps in general and an example of a Chef cookbook follows after it. Radiator VNF's configuration management will be discussed in later blog posts.

What is DevOps?

You get multiple different answers when searching for clues behind the portmanteau: DevOps. Sure, it's a merging of development and operations. Possibly, it's also a bunch of different tools. Or, you might describe it as a change in the processes of an organisation.

Combining all these, DevOps can be described as a cultural change in the organisation. It's not something you purchase from the store and sprinkle on top of your employees.

DevOps emphasises communication between different parts of the organisation and pushes the processes to be more automated and agile. Changes to the software or configuration are planned, made, tested, deployed, and monitored in a continuous, automated way.

DevOps toolchain by Kharnagy, CC BY-SA 4.0, original
Compared to the old way of divided silos and huge, rarely-made releases with massive change logs, this model encourages making smaller changes, testing them swiftly, and deploying often. Stronger collaboration between developers and operators and a faster, automated cycle improve reliability.

Especially in a flexible and distributed cloud environment, this new approach is needed. Otherwise, it is very difficult for a single operator to manually handle thousands of nodes. The tools grant you the possibility of easily having identical environments with slightly different parameters. With automation, there's no more forgetting to run that command and changing those addresses when manually moving from testing to QA to production.

For us, the shift to a DevOps culture in the customer base means that we also support the DevOps tooling and make it easier for our customers to deploy Radiator with automated configuration management systems. In the Radiator VNF, the whole infrastructure is managed automatically.

Chef, tool for DevOps

Chef is a set of tools developed by a company with the same name. There are several similar tools available, such as AnsiblePuppet and SaltStack among others, so you will find suitable a DevOps-tool for your particular use case.

Chef uses Ruby to describe the infrastructure as code. This means that the configuration of the infrastructure, from the operating system level to the running software services, and their configuration, can be written as Ruby code and then tested like any piece of software.

In Chef terms, the user writes cookbooks which consist of recipes. For example, a cookbook describes a software with different recipes for installation, configuration, and starting the services. The power lies in the community that has written thousands of cookbooks for various tasks. For example, you don't have to write your own cookbooks to install nginx and configure a website. Just download ready-made cookbooks like chef_nginx and configure them to suite your needs.

By using cookbooks, you can describe your whole infrastructure. The cookbooks can be unit tested, integration tested, and after deployment you can ensure compliance with rules of your organisation.

Short Chef example

As an example and sneak peek for the next post on this theme, here is a quick introduction on Chef cookbooks. These snippets are not complete, but show some features that are used to describe installing Radiator, creating some necessary directories, and starting the service.

If you want a longer introduction on Chef attributes, recipes, and resources, have a look at the tutorials.

name 'radiator'
maintainer 'Arch Red Oy'
version '0.6.2'

depends 'perl', '~> 4.0.0'
depends 'poise-service', '~> 1.4.1'

supports 'ubuntu', '= 16.04'
supports 'centos', '= 7.2'

default['radiator']['install']['version'] = '4.17'
default['radiator']['install']['method'] = 'archive'
default['radiator']['install']['directory'] = '/opt/radiator'

install_method = node['radiator']['install']['method']

poise_service_user 'radiator' do
  group 'radiator'
  home node['radiator']['user_home'] unless node['radiator']['user_home'].nil?
  shell node['radiator']['user_shell'] unless node['radiator']['user_shell'].nil?

%w(/var/run/radiator /var/log/radiator).each do |dir|
  directory dir do
    owner 'radiator'
    group 'radiator'

unless install_method.nil? || install_method == 'skip'
  include_recipe "radiator::install_#{install_method}"

case install_method
when 'package'
  radiusd_bin = '/usr/bin/radiusd'
  dictionary_files << '/etc/radiator/dictionary'
when 'archive', 'evaluation'
  radiusd_bin = '/usr/local/bin/radiusd'
  radiusd_includes << node['radiator']['install']['directory']
  dictionary_files << node['radiator']['install']['directory'] + '/dictionary'

unless node['radiator']['options']['dictionary_source'].empty?
  dictionary_files << '/etc/radiator/' + node['radiator']['options']['dictionary_file']

radiusd_params = ['-foreground', '-config_file /etc/radiator/' + node['radiator']['options']['config_file'],
                  '-dictionary ' + dictionary_files.flatten.join(','),

radiusd_includes = [node['radiator']['options']['radiusd_includes'], radiusd_includes].flatten.map { |inc| "-I #{inc}" }

perl_bin = '/usr/bin/env perl'
radiusd_command = [perl_bin, radiusd_includes, radiusd_bin, radiusd_params].flatten.join(' ')

poise_service 'radiator' do
  command radiusd_command
  user 'radiator'
  directory '/etc/radiator'
  subscribes :restart, "template[/etc/radiator/#{node['radiator']['options']['config_file']}]"

Wednesday, December 21, 2016

Coming up: Radiator VNF 2017 release

During 2016 we have been developing Radiator VNF together with our partners and customers in order implement a true unified vAAA solution. As year is closing to end, we are happy to tell a bit about the Radiator VNF and Radiator VNF Manager and the Radiator VNF 2017 release.

What is Radiator VNF?

Radiator VNF is a true NFV solution: it handles the virtualisation process automatically. The VNF manager scales and configures the virtual servers without human interaction. The scaling is based on KPIs (Key Performance Indicators), which the Radiator VNF system produces. Scaling does not compromise service reliability, there are no interruptions in service when scaling the system. Radiator VNF Manager configures automatically all the new instances.

Radiator VNF is a hardware-independent solution. This provides easy integration for Radiator VNF and makes it truly portable into different environments. The Radiator VNF 2017 release is provided for Openstack API.

Performance and scaling

Implementing the AAA system in a virtualised environment provides good scaling possibilities and high performance with lesser resources. Virtualisation allows better utilisation of the hardware layer and improves the application availability. Scaling and better performance is achieved without adding more hardware resources. The scaling process in Radiator VNF is modular, each VNF component is scaled separately according to the traffic needs.

This approach provides possibilities to optimise the scaling and resource usage for each component.

Additional key features

In addition to all the benefits of true NFV approach of Radiator VNF, we have listed some additional key features for Radiator VNF 2017 release:

  • Fault management 
    • If some kind of an error situation occurs, VNF components try to recover from it automatically.
  • Data analysing and visualisation tools
    • Radiator VNF provides interfaces for log graphical tools, which analyse the log data and create diagrams about system usage
  • Testing tools 
    • Radiator VNF package contains ready templates for testing tools - available when needed. 
  • Manual scaling 
    • Radiator VNF provides a possibility to scale the system also manually.

Do you want to know more?

Radiator VNF release 2017 will be commercially available during Q2/2017. In case you are interested in Radiator VNF solutions, please contact info@open.com.au . We are happy to tell you more about Radiator VNF, and assist you with your NFV and AAA project with Radiator solutions.

Thursday, September 29, 2016

Make your Radiator log data searchable, part 2

This is the second part of blog series that helps you to use the log data that Radiator generates.

In the first part of blog series, we configured Radiator to export data in JSON format. This part shows some basic examples about utilising that data.

The setup introduced in blog series part 1 is running and it produces log data in JSON format. The JSON data is forwarded to an analysis tool. In this case, we use Elastic Stack and its visualisation tool Kibana for analysing the sample data. For more information about Elastic Stack, see The Elastic Stack website. Configuring the data forwarding depends on the chosen tool and it is not discussed in this blog post.

This image shows how the log data is processed when using Elastic Stack for analysing:

radpwtst tool, which is included in Radiator distribution, is used as a RADIUS client. Thus, it authenticates via RADIUS and Radiator logs authentication attempts as entries to authlog.json file. Here is a sample of one authentication entry as shown in the JSON file:


The name-value pairs are not ordered in any way so they are hard to read as such. To get a better idea of the data, it must be parsed. One option is to use configuration variable for the plaintext output, it is feasible to use, at least in the testing phase. This helps to verify that the data is correctly interpreted by Elastic Stack.

Visualising log data with Kibana

Elastic Stack parses the data so we can explore the contents in Kibana. Part of our sample data looks like this in Kibana:

By clicking each entry open, we can verify that all name-value pairs are distinguished. By default, each name-value pair is indexed and searchable, and if you add new fields to the JSON data, Elastic Stack indexes them automatically. They are parsed and usable in your searches without need for other modifications. This enables searching of wide variety of name-value pairs and their combinations.

Kibana shows the amount of entries in each time window. By filtering everything else but authentication-related entries, we see trends in amount of authentication attempts.

Similarly, we can create visualisation of access/reject rate within a certain time frame.

Do you want to know more?

There will be examples of more detailed JSON use cases in the blog. If you have questions, contact Radiator team at info@open.com.au – we are happy to help you to have more benefits of your log data.

Monday, September 12, 2016

Utilising Radiator when evolving to 4G/LTE

One of the Radiator use cases is evolving your infrastructure for 4G/LTE features. Some of our customers already provide prepaid data plans in 3G/CDMA network but now they need to provide also 4G/LTE features for their subscribers. At the same time, being able to use the parts of the current infrastructure saves network operator’s money and time.

Radiator’s flexibility has a lot to offer for this kind of use case. You can choose any vendor for your LTE core network and Radiator will work seamlessly with it, thanks to Radiator’s multi-vendor support.

With Radiator, the same functionalities that have been implemented in 3G/CDMA network with RADIUS interfaces before, can now be implemented in 4G/LTE network with Diameter interfaces. You only need to replace your current RADIUS server with Radiator Telco Pack that provides all the needed features.

Radiator makes it also possible to use the existing customer data plans and business logic when updating for example from CDMA to LTE. For this integration, Radiator communicates with the original billing system using SQL or LDAP interfaces, among others. At the same time, Radiator uses Diameter interfaces, such as Gy, for integrating with LTE network infrastructure. See the picture below for basic layout.

Do you want to know more?

If you are interested in this kind of solution for your network, please do not hesitate to contact our sales team info@open.com.au. We and our worldwide partner network are happy to provide you assistance in your project.

Tuesday, August 2, 2016

Secure your network and services with Radiator two-factor authentication

Modern services all around the Internet offer different two-factor authentication solutions. They provide stronger security than using only username and password. Two-factor authentication requires a combination of something the user knows and something the user possesses. One common combination is the username and PIN or password with a physical token, such as a specific device, smart card, or mobile phone. The two-factor secured service may range from a web service to a network device to a remote VPN (Virtual Private Network) access – wherever stronger security is needed.

Figure 1: Radiator based two-factor authentication and authorisation architecture

Radiator AAA Server Software provides flexible, interoperable, and scalable two-factor AAA (Authentication, Accounting, and Authorisation) service for any device or service, which can use RADIUS, TACACS, or TACACS+ interface for AAA. The VPN devices can authenticate remote employees, the network devices can authorise administrators, and the web services can identify the users with secure two-factor authentication. All you need is Radiator-based two-factor AAA service and a free mobile phone app, such as Google Authenticator, Microsoft Authenticator, or some other OTP/TOTP/HOTP app. The authenticator app is paired with Radiator two-factor AAA service and particular user credentials, and two-factor authentication are ready to be used.

Another major benefit of using Radiator is its legendary interoperability. Radiator can combine complementary AAA information and functions from Active Directory, LDAP, and even 3rd party two-factor services, such as RSA SecurID, YubiKey, Duo Security, and Vasco Digipass. It can check existence and validity of a user from Active Directory, retrieve a proper VPN group, perform two-factor authentication using TOTP (Time-based One-time Password Algorithm), and then combine the results to a RADIUS authentication and authorisation response, which is sent back to a Cisco ASA VPN device.

Radiator can also extend the functionalities of 3rd party two-factor authentication services by translating and complementing AAA interactions between services and devices. For example, Radiator combines fine-grained TACACS(+)- or RADIUS-based network device configuration authorisation with existing user directories and two-factor authentication. The two-factor authentication data may be retrieved from Radiator itself or some 3rd party service. With the help of Radiator’s extendable two-factor modules, Radiator also supports SMS transfer of one-time-passwords, when using tokens or authenticator app is not feasible.

Radiator and its two-factor authentication functionalities have already been deployed in several different environments such as:
  • Fortune 250 company uses Radiator for two-factor authentication of their global VPN network.
  • IT departments of world’s two top universities provide VPN service for their employees, partners, and students utilising Radiator’s capability to combine Duo Security two-factor authentication service to additional LDAP directory checks.
  • Nordic operator provides multi-function (RSA SecurID, SMS) two-factor authentication service to their enterprise customers.

Would you like to know more?

Contact our team at info@open.com.au to set up a meeting, where we can discuss how Radiator could help you in securing access to your services or network with two-factor authentication.

Monday, July 18, 2016

Flexible M2M/IoT service with Radiator and Private APN

M2M (Machine to Machine) communications, IoT (Internet of Things), and Industrial Internet are constantly bringing new connected devices, things, to the Internet. Operators and other companies already use Radiator AAA Server Software to create M2M, IoT, and Industrial Internet services to customers. Using Radiator with Private APN (access point name) is an important use case.

Figure 1: Radiator RADIUS server and Private APN service architecture

Most mobile operators provide, in addition to their own APNs, also a Private APN service for companies interested of separating their data traffic from operators’ generic subscriptions. The Private APN service utilises operator’s SIM cards for radio network access, but separates the data traffic in operator’s GGSN (gateway GPRS support node) by the access point name (e.g. internet.company instead of operator’s own access point name). These separate private access points may have their own parameters for authentication, accounting, IP networks, IP address allocation, connection parameters, traffic accounting, priorities, and other functionalities. Depending on the GGSN capabilities, it is possible to move some of these functionalities and information to a separate RADIUS service, which is provided either by the operator or company utilising the Private APN.

With the Private APN and Radiator AAA Server Software as a RADIUS service, our customers have successfully deployed M2M, IoT, and Industrial Internet solutions. Some examples are:
  • Fixed IPv4 and IPv6 address allocation for mobile operator M2M/IoT service based on MSISDN (phone number) with the option of returning any GGSN-supported subscription parameters from RADIUS to GGSN
  • Ensuring that the Australian state-wide network of water measurement devices are active and sending measurement data, and working as AAA service for VPN connection authentication for devices
  • Tracking truck locations, and authenticating, accounting, and authorising GPS tracking devices for fleet tracking service operating across several operators and European countries

Would you like to know more?

This use case is one of the many, where Radiator can be used to provide additional and complementary functionality to mobile network and Internet of Things/Industrial Internet solutions. Contact our team at info@open.com.au to set up a meeting, where we can discuss how Radiator could help you in building and deploying mobile network or IoT/Industrial Internet services and solutions.

Friday, June 17, 2016

Radiator SIM Pack, Carrier Pack and Telco Pack releases

We are happy to announce we have now new releases of Radiator SIM Pack and Telco Pack  and also the first release (v. 1.0) of Radiator Carrier Pack, which is designed to address the needs of carriers.

Radiator Carrier Pack is targeted especially for carriers: it provides the interoperability, flexibility, and performance of Radiator, and it also includes Radiator Carrier Module. This module consists of advanced Radiator Diameter server software and Diameter relay software. These provide the platform for other Radiator carrier products: Radiator SIM Pack, Radiator Telco Pack and Radiator GBA/BSF Pack.

Initial release of Radiator Carrier Pack includes following features (and more can be found from revision history):

  • The existing and new modules are reorganised. Base components from Radiator Telco Module are now included in Radiator Carrier Module.
  • DiameterTelcoConnection now calls DiaPeer's send_reply() instead of calling send() directly. This is preferred to keep the peer state machine up to date.
  • OriginHost and OriginRealm in DiaPeerDef support special formatting.
  • Diameter initiator connections are now activated after the configuration has been loaded instead of during configuration loading.

Do you want to know more?

If you like to know more about Radiator Carrier Pack and other Radiator carrier products, please do not hesitate to contact our sales team at info@open.com.au