La respuesta extensa, lenta, técnica y útil: 

Si has comenzado a usar equipos Albentia en tu red, habrás comprobado que son bastante intuitivos, ya que la estación base (BS) lo hace casi todo: colas, autenticación, control de usuarios, etc., y lo que no hace la BS, lo hace el CPE. Normalmente, todos los operadores que empiezan a usar nuestras BS, lo hacen usando una provisión local. Ésta consiste en dar de alta los terminales en la propia BS. Sin embargo, cuando el número de BS comienza a crecer, tener ‘desperdigada’ por la red la provisión de todos los clientes va generando problemas.

1. ¿En qué estación base tengo que dar las nuevas altas?
2. Si un cliente no navega, ¿en qué estación base debo darlo de alta.
3. Si un cliente deja de pagar, ¿dónde lo doy de baja?
4. Y, por supuesto, no olvidemos el backup de todos los ficheros de todas las estaciones base.

La problemas se irían sumando a esta lista hipotética a medida que nuestra red crece, pero hay una solución: la provisión de usuarios y la mejor opción para esta provisión centralizada es usar RADIUS.

Clientes y templates:

Antes de continuar, vamos a recordar dos conceptos básicos en la provisión de clientes: templates y users.

• Templates, también llamadas plantillas o productos: una template es la descripción de un producto que se le vende a un cliente. Es una descripción completa: si hay internet o internet y teléfono, capacidades de subida, de bajada, criterios de filtrado, etc. En una BS podemos crear tantos productos como necesitemos. Hemos visto operadores con 2 templates – producto básico y producto premium – y operadores con más de 20 templates – con todas las variantes de productos que venden, y algunos customizados para algún cliente -.
• Users, también llamados usuarios o clientes: un usuario es «un alta» de un cliente en la BS. Cuando damos de alta a un nuevo user, ponemos la MAC del terminal y lo asociamos a una template específica. Podemos dar de alta tantos users como necesitemos y podemos asociarlos a cualquiera de las plantillas que hayamos creado. Por supuesto, podemos modificar qué plantilla tiene un cliente asociada cuando queramos.

Por si no los conocíais, aquí tenéis una captura:

Dicho esto: en nuestra filosofía los templates siempre son locales en las BS. Esto significa, que las plantillas han de crearse en todas las BS que tenga tu red. Esto no significa que lo tengas que hacer a mano, puedes hacerlo cómodamente de dos formas:

1. Creas las plantillas en una BS y luego bajas el fichero de provisión y lo subes al resto de BSs de tu red.
2. Creas las plantillas en una BS y luego usas los scripts que incluiré al final del artículo para sincronizar todas las BS de la red.

 

Altas centralizadas con RADIUS.

Lo que se puede, y en mi opinión se debe, es centralizar las altas de los clientes. NO es obligatorio dar de alta cada uno de los clientes en las BS. Esta es la configuración:

 

¿Cómo funciona una BS de Albentia con RADIUS?

De manera muy simplificada: cuando un cliente se enciende, escanea la banda y busca a las BS que escucha. Una vez ha decidido a qué BS va a intentar entrar, le manda un mensaje de ranging pidiéndole acceso.

La BS tiene que tomar la decisión de dejarlo entrar (y después configurar todos los servicios, las interfaces de red, VLANs y lo que sea) o rechazarlo y que lo intente con otra BS o que se aburra. Si hemos configurado la BS para usar provisión local, simplemente consultará su tabla de usuarios provisionados y a correr.

Si hemos configurado la BS para usar RADIUS, entonces las cosas cambian y se ponen interesantes. Esto es lo que ocurre:

• Paso 1: llama al servidor RADIUS y le pide autorización para un usuario que tiene por username la dirección MAC del cliente (con :, _, o sin nada, lo podéis configurar).
• Paso 2: el servidor comprueba su base de datos, sus tablas o lo que sea que tenga el sistema RADIUS que estéis usando.
• Paso 3: el servidor RADIUS responde a la BS. Si no permite la entrada, simplemente la BS rechaza al cliente. Si permite la entrada, el servidor radius le debe indicar al menos una cosa: qué template hay que usar.
• Paso 4: la BS busca en su tabla de templates la template que le ha indicado el servidor RADIUS, y si la encuentra, deja entrar al terminal y le establece toda la configuración.
• Paso 5: felicidad.

 

Servidores Radius.

Un RADIUS no es más que un programa en un servidor que entiende las peticiones que le hace la BS y le devuelve respuestas permitiendo entrar clientes o no. En Albentia tenemos preparada una guía de integración para dos servidores RADIUS muy habituales en el mercado: Freeradius y Radius Manager.

En realidad cualquier sistema de gestión WISP/ISP moderno que os podáis encontrar en el mercado soporta (o debería hacerlo) RADIUS. Además de RADIUS tienen funcionalidad de gestión de clientes (CRM), de supervisión de red, de gestión de altas, facturación; un poco de todo.

En resumen: las ventajas.

Visto cómo funciona la provisión centralizada con RADIUS, algunas ventajas importantes yo creo que son estas:

• Las altas, bajas y modificaciones de tarifas se pueden hacer muy fáciles y no requieren de personal experto y nos elimina la necesidad de ir entrando por las BSs para hacerlas.
• Los backups de la red son mucho más sencillos, ya que solo hay que hacer un backup de la BBDD central.
• Es más fácil detectar problemas de clientes y provisiones.
• Puedes permitir cierto roaming o multicobertura de clientes.
• La red se vuelve mucho más escalable y se mantiene mejor. 

 

¿Usáis RADIUS? ¿Qué software/sistema de provisión centralizada tenéis montado? ¿Veis más ventajas? ¿Algún inconveniente?

 

Si este post te ha resultado interesante, también puedes consultar esta otra entrada sobre planificación de servicios.

 

---

 

Centralized provisioning with RADIUS, is it worth it?

Radius (Remote Access Dial In User Service) is a protocol for managing access credentials to a network resource. If you are an operator and have not yet heard about Radius, don’t despair. Very soon we’ll dedicate a complete series of posts to configure a Radius server and thus authorize and authenticate subscribers in a base station. If, on the other hand, you are one of the operators that already know Radius, but have not yet used it, we’ll explain if it’s worthwhile to carry out the centralized provision with this server.

The quick answer:

Yes, definitely. Although we don’t want to end this post here. Therefore, we are going to give you a second answer, more extensive, slow, technical and useful. Here we go:

The extensive, slow, technical and useful answer:

If you have started using Albentia equipment in your network, you’ll have verified that they are quite intuitive, since the base station (BS) does almost everything: queues, authentication, user control, etc., and what the BS doesn’t do, the CPE does it. Normally, all operators that start using our BS use a local provision. This consists in registering the terminals in the BS itself. However, when the number of BS begins to grow, having ‘scattered’ by the network the provision of all customers is generating problems.

1. Where do I register the new registrations?

2. If a costumer doesn’t browse, what base station do I register.

3. If a customer stops paying, where do I unsubscribe?

4. And, of course, let’s not forget the backup of all the files of all the base stations.

The problems would be added to this hypothetical list while our network grows, but there is a solution: the provision of users and the best option for this centralized provision is to use RADIUS.

Users and templates:

Before continuing, we will remember two basic concepts in the provision of clients: templates and users.

• Templates, also called products: a template is the description of a product that is sold to a customer. It’s a complete description: if there is internet or internet and telephone, upload, download, filter criteria, etc. In a BS we can create as many products as we need. We have seen operators with 2 templates – basic product and premium product – and operators with more than 20 templates – with all the variants of products they sell, and some customized for some customer -.

• Users, also called customer: a user is «a registration» of a client in the BS. When we register a new user, we put the MAC of the terminal and associate it with a specific template. We can register as many users as we need and we can associate them with any of the templates that we have created. Of course, we can modify which template has an associated client when we want.

In case you didn’t know them, here’s a screenshot:

That said: in our philosophy the templates are always local in the BS. This means, that the templates have to be created in all the BS that your network has. This doesn’t mean that you have to do it by hand, you can do it comfortably in two ways:

1. You create the templates in a BS and then download the provision file and upload it to the rest of the BSs in your network.

2. You create the templates in a BS and then you use the scripts that I’ll include at the end of the article to synchronize all the BS in the network.

 

Centralized registration with RADIUS:

We can, and in my opinion we must, centralize customer registrations. It is not mandatory to register each of the clients in the BS. This is the configuration:

 

How does a BS of Albentia with RADIUS work?

In a very simplified way: when a client turns on, Radius scans the band and looks for the BS that listens. Once Radius has decided which BS he is going to try to enter, he sends to BS a ranging message asking for access.

The BS has to make the decision to let it in (and then configure all services, network interfaces, VLANs and whatever) or reject it. If we have configured the BS to use local provision, it will simply consult its table of provisioned users and to run. 

If we have configured the BS to use RADIUS, then things change and become interesting. This is what happens:

• Step 1: Call the RADIUS server and ask for authorization for a user that has the client’s MAC address (with:, _, or nothing, you can configure).

• Step 2: the server checks your database, your tables or whatever RADIUS system you are using.

• Step 3: The RADIUS server responds to the BS. If it does not allow entry, simply the BS rejects the client. If you allow the entry, the radius server must indicate at least one thing: what template should be used.

• Step 4: the BS searches in its template table for the template that the RADIUS server has indicated, and if it finds it, it lets the terminal enter and establishes all the configuration.

• Step 5: happiness

 

Servers Radius.

A RADIUS is nothing more than a program on a server that understands the requests made by the BS and returns answers allowing clients to enter or not. In Albentia we have prepared an integration guide for two RADIUS servers very common in the market: Freeradius and Radius Manager.

In fact, any modern WISP / ISP management system that you can find on the market supports (or should do) RADIUS. In addition to RADIUS, they have client management (CRM), network monitoring, registration management, billing functionality; a bit of everything.

 

In summary: the advantages.

Given how the centralized provision works with RADIUS, some important advantages I think are these:

• The registrations, dicharges and modifications of rates can be made very easy and don’t require expert staff and eliminates the need to go through the BSs to do them.

• The backups of the network are much simpler, you only have to make a backup of the central DB.

• It is easier to detect customer problems and provisions.

• You can allow certain roaming or multi-coverage of clients.

• The network becomes much more scalable and stays better.

 

 

Do you use RADIUS ? What software / centralized supply system do you have assembled? Do you see more advantages? Any inconvenience?

 

If this post has been interesting for you, you can also check this other entry about service planning.