Descargar versión PDF - Grupo de Telecomunicaciones Rurales

WiLD
WiFi Based Long Distance
Primera Edición
Grupo de Telecomunicaciones Rurales
Pontificia Universidad Católica del Perú
Publicación financiada por FINCYT
Lima, Agosto 2009
WiLD
WiFi Based Long Distance
Pontificia Universidad Católica del Perú
Grupo de Telecomunicaciones Rurales
GTR-PUCP, http://gtr.telecom.pucp.edu.pe
Edición: Daniel Carbajal, Jeffry Cornejo, José Luis Vargas, Luis Camacho, Aldo Duarte, Renzo
Navarro, Yuri Pacheco.
c
⃝2009,
GTR-PUCP
Primera edición: Agosto 2009
Hecho el Depósito Legal en la Biblioteca Nacional del Perú 𝑁 𝑜 2009-09928
ISBN: 978-9972-659-93-5
Autores: Luis Camacho, River Quispe, César Córdova, Leopoldo Liñán, David Chávez.
Esta publicación ha sido elaborada gracias al financiamiento del Programa de Ciencia y Tecnología
FINCYT.
Los autores de este libro no se responsabilizan de los incidentes o daños que pudiera ocasionar la
utilización de la información contenida en él.
Este libro está publicado bajo la licencia Reconocimiento-Uso no Comercial-Compartir por Igual,
versión 2.5, de Creative Commons Perú.
http://creativecommons.org/licenses/by-nc-sa/2.5/pe/legalcode
Índice general
Índice general
1
Introducción
7
1. Redes WiFi para largas distancias
1.1. Estándares WiFi . . . . . . . . . . . . . . . . . . .
1.2. Problemática del uso de WiFi para largas distancias
1.2.1. Capa física . . . . . . . . . . . . . . . . . . .
1.2.2. Capa MAC . . . . . . . . . . . . . . . . . . .
1.3. Uso de telefonía IP . . . . . . . . . . . . . . . . .
1.4. Arquitectura de redes WiFi para larga distancia . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2. Hardware y software apropiados para la construcción de routers WiFi de larga distancia
2.1. Placa SBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1. Tipo de procesador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2. Descripción de SBCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2.1. RouterBOARD 532A . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2.2. RouterBOARD 333 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2.3. Alix2C0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2.4. Pronghorn SBC-250 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2.5. Pronghorn Metro SBC Quad-Radio Wireless . . . . . . . . . . . . . . . .
2.1.3. Comparación de SBCs para aplicación de redes inalámbricas . . . . . . . . . .
2.2. Tarjetas de red inalámbrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1. Comparación de tarjetas de red inalámbricas . . . . . . . . . . . . . . . . . . .
2.2.2. Pigtails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3. Antenas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3. Sistema Operativo Linux Voyage . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1. Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4. Driver MadWifi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1. HAL y OpenHAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
13
14
15
15
16
18
19
25
27
27
28
28
29
29
29
30
32
33
33
36
37
38
38
39
39
2.4.2. Ath5k y Ath9k .
2.4.3. Características .
2.4.4. Requerimientos
2.5. Quagga . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
40
42
42
3. Software PBX Asterisk
3.1. VoIP . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2. Asterisk . . . . . . . . . . . . . . . . . . . . . . . .
3.3. Protocolos VoIP . . . . . . . . . . . . . . . . . . . .
3.3.1. IAX (Inter Asterisk eXchange) . . . . . . . . .
3.3.2. SIP (Session Initiation Protocol) . . . . . . . . .
3.3.2.1. Elementos del SIP . . . . . . . . . . . . . .
3.3.2.2. Flujo de establecimiento de una sesión SIP
3.3.3. Protocolo de Descripción de Sesión SDP . . . .
3.3.4. Protocolos RTP/RTCP . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
45
45
46
50
50
50
52
55
56
57
4. Enrutamiento Dinámico
4.1. Tipos de Enrutamiento . . . . . . . . . . . . . . . . . . . . . .
4.1.1. Tabla de Enrutamiento . . . . . . . . . . . . . . . . . . . .
4.1.2. Enrutamiento Estático . . . . . . . . . . . . . . . . . . . .
4.1.3. Enrutamiento Dinámico . . . . . . . . . . . . . . . . . . .
4.2. Enrutamiento Dinámico . . . . . . . . . . . . . . . . . . . . . .
4.2.1. Tipos de Protocolos de Enrutamiento Dinámico: . . . . . .
4.2.2. Características de los Protocolos de Enrutamiento Dinámico
4.2.2.1. Algoritmo de enrutamiento Vector Distancia . . . . . .
4.2.2.2. Algoritmo de enrutamiento de Estado Enlace . . . . .
4.2.2.3. Enrutamiento con clase y sin clase . . . . . . . . . . .
4.2.2.4. Convergencia . . . . . . . . . . . . . . . . . . . . . .
4.2.2.5. Balance de Carga . . . . . . . . . . . . . . . . . . . .
4.2.3. Métrica y distancia administrativa . . . . . . . . . . . . . .
4.3. OSPF, Open Shortest Path First . . . . . . . . . . . . . . . . . .
4.3.1. Áreas y clases de routers . . . . . . . . . . . . . . . . . .
4.3.2. Costo en OSPF . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2.1. Árbol de la ruta más corta . . . . . . . . . . . . . . .
4.3.2.2. Tipo de Interfaces de redes . . . . . . . . . . . . . . .
4.3.2.3. Rutas externas de tipo1 y tipo2 . . . . . . . . . . . . .
4.4. Funcionamiento de OSPF . . . . . . . . . . . . . . . . . . . . .
4.4.1. Encapsulamiento de paquetes en OSPF . . . . . . . . . .
4.4.2. Tipos de LSA (Link State Advertisement) . . . . . . . . .
4.4.3. Estados OSPF . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
59
59
59
60
61
61
61
62
62
63
63
64
64
64
65
66
68
68
68
69
69
70
72
73
.
.
.
.
77
77
78
79
79
5. Voyage GTR
5.1. Identificación de las aplicaciones a implementar . . . . . . . . . . . . . . . . . .
5.2. Configuración rápida mediante archivos de las interfaces de red (Ethernet y WiFi)
5.3. Configuración rápida de enrutamiento estático . . . . . . . . . . . . . . . . . . .
5.4. Seguridad WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
5.5.
5.6.
5.7.
5.8.
Enrutamiento dinámico . . . . . . . . . . . . . . . . . .
Telefonía IP . . . . . . . . . . . . . . . . . . . . . . . .
Configuración vía web . . . . . . . . . . . . . . . . . .
Adaptación de Voyage para el trabajo en entornos rurales
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6. Configuración e Instalación de Voyage GTR
6.1. Comandos generales en Linux . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1. Comando ls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2. Comando mkdir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.3. Comando rm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.4. Comando fdisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.5. Comando dmesg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.6. Comando lspci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.7. Comando ps aux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.8. Comando kill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.9. Comando hostname . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.10. Comando tail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.11. Comando ifconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.12. Comando ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.13. Comando ssh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.14. Comando route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2. Instalación de Voyage GTR . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3. Acceso inicial por puerto serial o por Ethernet . . . . . . . . . . . . . . . . .
6.4. Edición de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5. Estructura de archivos de Voyage GTR . . . . . . . . . . . . . . . . . . . . .
6.6. Guardar archivos o carpetas de /rw . . . . . . . . . . . . . . . . . . . . . . .
6.7. Configuración previa a cualquier aplicación en Voyage GTR . . . . . . . . .
6.8. Obtención de respaldo de la configuración de las aplicaciones en Voyage GTR
6.9. Verificación del estado de Voyage GTR . . . . . . . . . . . . . . . . . . . .
6.9.1. Espacio ocupado y disponible . . . . . . . . . . . . . . . . . . . . . . .
6.9.2. RAM libre y CPU desocupado en un instante . . . . . . . . . . . . . . .
6.9.3. Fecha del sistema y último reinicio . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7. Configuración de Redes con Voyage GTR
7.1. Interfaces de Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2. Configuración de las interfaces de red . . . . . . . . . . . . . . . . . . . . . .
7.2.1. Configuración de Ethernet y de Bridge Ethernet . . . . . . . . . . . . . .
7.2.2. Configuración de las interfaces WiFi . . . . . . . . . . . . . . . . . . . .
7.3. Configuración del enrutamiento estático, gateway y NAT . . . . . . . . . . . .
7.4. Configuración del enrutamiento dinámico con OSPF . . . . . . . . . . . . . .
7.5. Configuración del DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6. Configuración de interfaces WiFi y de parámetros TCP/IP mediante comandos .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
80
81
82
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
85
85
85
85
85
86
86
86
87
87
88
88
88
88
89
89
89
91
91
92
93
94
95
95
95
96
96
.
.
.
.
.
.
.
.
99
99
100
100
101
103
103
105
106
8. Verificación del Estado de la Red de Datos
8.1. Conectividad en enlaces AP-STA . . . . . . . . . . . . . . . . .
8.1.1. Nivel de señal del enlace y relación de la calidad del enlace
8.1.2. Cantidad de clientes conectados al AP . . . . . . . . . . .
8.1.3. Corrección del alineamiento de las antenas . . . . . . . . .
8.1.4. Ping normal entre las interfaces del enlace . . . . . . . . .
8.1.5. Ping con mayor tamaño entre las interfaces del enlace . . .
8.1.6. Medición en el rendimiento de un enlace . . . . . . . . . .
8.1.7. Verificación de la tabla de rutas y la ruta de salida . . . . .
8.1.8. Ping a todas las interfaces de red . . . . . . . . . . . . . .
8.2. Conectividad en una red troncal . . . . . . . . . . . . . . . . .
8.2.1. Ping a todas las interfaces de red . . . . . . . . . . . . . .
8.2.2. Medición del rendimiento de la troncal . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
9. Configuración de una red de Telefonía IP con Asterisk
9.1. Configuración inicial . . . . . . . . . . . . . . . . . . . . . . . .
9.2. Configuración básica de Asterisk . . . . . . . . . . . . . . . . . .
9.2.1. Configuración de los clientes SIP . . . . . . . . . . . . . . .
9.2.2. Programación de las llamadas telefónicas . . . . . . . . . . .
9.2.3. Identificación de direcciones IP de los servidores Asterisk . .
9.2.4. Grabación de archivos de sonido . . . . . . . . . . . . . . .
9.2.5. Configuración de IVR básico . . . . . . . . . . . . . . . . .
9.2.6. Comunicación con otros servidores Asterisk . . . . . . . . .
9.3. Registro de los clientes SIP . . . . . . . . . . . . . . . . . . . . .
9.4. Verificación del estado de telefonía IP con Asterisk . . . . . . . .
9.4.1. Estado del registro de clientes y tono en los teléfonos . . . . .
9.4.2. Llamada de prueba al servidor de telefonía IP . . . . . . . . .
9.4.3. Llamada de prueba a un cliente local . . . . . . . . . . . . .
9.4.4. Llamada de prueba al resto de servidores de telefonía IP . . .
9.4.5. Llamada de prueba a un cliente administrado por otro servidor
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
109
109
109
112
112
115
117
117
118
119
119
119
120
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
121
121
122
122
123
124
125
125
125
126
128
128
128
128
129
129
10. Caso de Estudio: Red Napo Sur
10.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2. Descripción General de la Red de Comunicaciones . . . . . . . . . . . . . . . . . .
10.3. Descripción de la Red de Telecomunicaciones . . . . . . . . . . . . . . . . . . . . .
10.3.1. Enlaces Troncales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.2. Características de los Equipos Instalados . . . . . . . . . . . . . . . . . . . . .
10.3.2.1. Equipos empleados en los enlaces troncales de 2.4GHz – 802.11b/g . . . .
10.3.2.2. Equipos empleados en los enlaces troncales de 5.8GHz – 802.11a . . . . .
10.3.2.3. Equipos empleados en los enlaces de distribución de 2.4GHz – 802.11g . .
10.3.3. Distribución de los equipos en los repetidores y estaciones clientes . . . . . . .
10.3.3.1. Distribución en los repetidores de Tacsha Curaray, Negro Urco, Tuta Pishco
y Huamán Urco (enlaces en 2.4GHz) . . . . . . . . . . . . . . . . . . . . .
10.3.3.2. Distribución en el repetidor de Mazán (enlaces en 2.4GHz y 5.8GHz) . . .
10.3.3.3. Distribución en el repetidor de PetroPerú (enlaces en 2.4GHz y 5.8GHz) . .
131
131
132
135
135
144
144
147
148
149
149
150
151
5
10.3.3.4. Distribución en el repetidor del Hospital Regional de Loreto (enlaces
2.4GHz y 5.8GHz) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.3.5. Distribución en las estaciones clientes (enlaces de distribución) . . . . .
10.3.4. Sistema de Energía y Protección Eléctrica . . . . . . . . . . . . . . . . . . .
en
. . 151
. . 152
. . 153
Bibliografía
157
Glosario
161
6
Introducción
Este libro es una nueva iniciativa del Grupo de Telecomunicaciones Rurales de la Pontificia Universidad Católica del Perú (GTR-PUCP) para contribuir a la ampliación y difusión del conocimiento
existente sobre tecnologías apropiadas para el acceso a la información y comunicación en zonas rurales.
En tal sentido, este libro tiene varios propósitos:
Compartir el conocimiento generado y/o utilizado por GTR-PUCP.
Incrementar la bibliografía en castellano sobre tecnologías apropiadas para zonas rurales.
Servir de partida para futuras actualizaciones conforme aumente la información disponible.
La mayor parte de los contenidos de este libro han sido gestados gracias al aporte financiero de
FINCyT, el Fondo de Inversión en Ciencia y Tecnología, http://www.fincyt.gob.pe; una iniciativa del Estado Peruano para contribuir al incremento de la competitividad del país, fortaleciendo
las capacidades de investigación e innovación tecnológica y promoviendo la articulación de la Empresa, Universidad y Estado.
El libro es llamado WiLD, WiFi based Long Distance, citando un término probablemente acuñado
por TIER, Technology and Infraestructure for Emerging Regions, un grupo de investigación de la
Universidad de California en Berkeley. El término hace referencia al conjunto de soluciones para la
transmisión inalámbrica de voz y datos basados en el protocolo 802.11, y cuya virtud más notable, es
alcanzar enlaces de muy larga distancia (entre 50 y 100 km), mucho mayores que las distancias para
las que originalmente fue diseñado el protocolo 802.11.
El título es apropiado pues este libro trata sobre Voyage GTR, un sistema operativo basado en la
distribución Linux Voyage, a la cual se han añadido aplicaciones hasta obtener un sistema operativo
específico (un firmware si se quiere). Este software desarrollado instalado sobre un hardware apropiado, convierte al conjunto, en un router WiFi de largo alcance, como puede verse en la siguiente figura:
7
8
Figura 1: Router Inalámbrico Integrado
¿Por qué es importante que exista un equipo de largo alcance?
La gran cobertura es una de las varias características que hace que los routers Voyage GTR sean
apropiados para la creación de redes en zonas rurales.
Estructura del Libro:
En el primer capítulo se narra la problemática del uso del protocolo 802.11 para la transmisión
de voz y datos en enlaces de larga distancia, tomando en cuenta que este protocolo nació como una
solución para redes LAN.
En el segundo capítulo se describen y explican el hardware y software empleados para la construcción de routers Voyage GTR. Todas estas herramientas están enmarcadas en el mundo del software y
hardware libres.
En los capítulos tres y cuatro se narran aspectos teóricos de dos de las características más importantes dentro de Voyage GTR: Telefonía IP y Encaminamiento Dinámico OSPF. Estas dos propiedades
se implementan a través de los programas Asterisk y Quagga.
En el quinto capítulo se describe Voyage GTR y todas las modificaciones y aplicaciones aãdidas
a Linux Voyage para conseguir el producto final.
En los capítulos seis, siete y ocho se detalla los aspectos técnicos del uso de Voyage GTR: la
instalación y configuración básica, configuración de redes cableadas e inalámbricas y la verificación
del estado de una red instalada.
En el noveno capítulo se detalla los aspectos técnicos de la instalación de un sistema de telefonía
9
IP utilizando Asterisk.
Finalmente en el décimo capítulo se presenta un caso de estudio, la red Napo Sur (provincia de
Maynas, región Loreto en Perú), perteneciente a la Dirección Regional de Salud de Loreto, Perú; montada con routers Voyage GTR. Esta red sumada a la parte Norte (también instalada con los mismos
equipos) forman en conjunto probablemente la red en servicio WiFi multisalto más larga del planeta.
Zonas rurales en países en vías de desarrollo
Las zonas rurales aisladas de países en vías de desarrollo son el contexto vital de más de la mitad
de la población mundial, pese a lo cual es generalizada su casi total carencia de infraestructuras de
comunicación y acceso a la información. La pretensión de dotar a estas zonas de conectividad a redes
de voz y datos ha sido en los últimos años una preocupación del mayor orden de los agentes internacionales multilaterales de desarrollo, ya que en algunos casos se puede considerar un servicio básico,
y en todos es un sustrato de gran importancia para el desarrollo y la promoción humana. No obstante,
todos los esfuerzos por generalizar el acceso a redes de comunicación en zonas aisladas de países en
desarrollo suelen topar desde los primeros pasos con la ausencia de soluciones tecnológicas realmente
apropiadas, realistas y sostenibles, debido en gran parte a las siguientes características específicas de
estos contextos:
No sólo se carece de infraestructuras de telecomunicación; también suele ser prácticamente
inexistente o de mala calidad la infraestructura de electrificación y, en muchos casos las vías
de acceso. La necesidad de dotar a los sistemas de telecomunicación de alimentación eléctrica
autónoma para garantizar su funcionamiento continuo y su durabilidad los encarece y dificulta
su mantenimiento, y la ausencia de vías de acceso también encarece y dificulta tanto el despliegue de redes como su mantenimiento.
El personal técnico cualificado necesario para el mantenimiento y operación de estas tecnologías suele encontrarse en las ciudades, y resulta caro y difícil contar con él en estas zonas.
La población es pobre y dispersa, por lo que no puede soportar los costes de infraestructuras
caras de instalar, mantener y operar. Tampoco los estados de los países en vías de desarrollo
están en condiciones de poder subvencionar la instalación de redes de comunicaciones rurales
en pro de la cobertura total, tanto por su falta de recursos como por la enorme proporción que
las poblaciones rurales no contributivas representan en el total.
10
Características de las soluciones tecnológicas para este contexto
Este contexto no sólo explica la causa de esa práctica incomunicación de la mitad del mundo
habitado, sino que también determina las especificaciones de cualquier solución tecnológica que se
pretenda aplicar de manera sostenible en entornos rurales de países en desarrollo:
Tiene que ser robusta y sencilla de usar, ya que los usuarios van a ser poco cualificados y no
van a contar con el apoyo continuo de asesores preparados.
Tiene que requerir poco o ningún mantenimiento de técnicos especializados, ya que éstos van
a estar lejos y va a resultar caro y difícil atraerlos para la resolución de los problemas. Con más
razón debe ser mínima la necesidad de administración de las redes, ya que ésta genera costes
fijos considerables.
Debe ser de bajo consumo, ya que frecuentemente tendrá que depender de instalaciones de
energías fotovoltaicas o eólicas que encarecen las instalaciones y aumentan las necesidades y
costes de mantenimiento.
Debe tener costes de despliegue y de operación muy bajos. Ésto excluye las redes cableadas, las
de telefonía móvil y las redes satélite como soluciones únicas. En ocasiones se puede plantear
el acceso al mundo de toda una red por estos medios, pero la distribución del acceso se tendrá
que hacer con una tecnología complementaria más barata. Este criterio también desaconseja en
muchos casos las redes radio en bandas de frecuencia licenciadas.
Con estos condicionantes, el GTR-PUCP ha trabajado desde 1999 en varias líneas de investigación
que persiguen determinar cuales son las tecnologías inalámbricas más apropiadas a zonas rurales
aisladas de países en desarrollo, mejorarlas y aplicarlas de forma óptima. En [6] se describen distintas
tecnologías propuestas para la instalación de redes de telecomunicaciones en este contexto. Todas
ellas son inalámbricas, ya que dadas las características descritas anteriormente, una red cableada sería
muy costosa de instalar y mantener. En el presente libro se profundizará sobre el uso de la alternativa
tecnológica basada en WiFi.
1
Redes WiFi para largas distancias
Desde el 2001, una de las tecnologías que se ha tomado en consideración muy seriamente para
las comunicaciones de largas distancias es la IEEE802.11, popularmente llamada WiFi; si bien este
estándar no se concibió para redes extensas, sus indudables ventajas de costo, uso de frecuencias libres de licencia y gran ancho de banda, han despertado el interés de diversos agentes tecnológicos de
países en desarrollo. Incluso en los núcleos urbanos de muchos países se han dado experiencias de
aplicación de WiFi para distribuir el acceso a Internet con la mayor cobertura posible en exteriores.
Además, el enorme éxito de WiFi en todos los ámbitos ha dado lugar a una gran cantidad de productos
en el mercado, casi todos ellos de bajo consumo, a precios bajos y mucha flexibilidad de uso, especialmente en combinación con desarrollos de software abierto. Respecto al uso de frecuencias en los
casos en que no hay un vacío legal, la mayor parte de los estados adoptan las restricciones de la FCC
en el uso de las banda ISM 2.4GHz y 5.8GHz usadas por esta tecnología. Como se puede apreciar en
el Cuadro 1.1, estas normas son mucho más permisivas que las europeas y permiten realizar en las
zonas rurales enlaces tanto punto a punto (PtP) como punto a multipunto (PtMP) de varias decenas
de kilómetros.
Máxima potencia
transmisible
1000mW
100mW
10 mW
Dominio legal
Normativa
USA y muchos países en
desarrollo
Europa
Japón
FCC 15.247
ETS 300-328
MTP Ordenance for Regulating
Radio Equipment, Article 49-20
Cuadro 1.1: Máxima potencia transmisible en 2.4 GHz por regiones.
Las ventajas e inconvenientes que presenta el uso de esta tecnología se indican a continuación:
11
12
CAPÍTULO 1. REDES WIFI PARA LARGAS DISTANCIAS
Ventajas:
Uso de frecuencias sin licencia de las bandas ISM 2.4 / 5.8 GHz con ciertas limitaciones de
potencia.
Velocidades desde 1 hasta 54 Mbps, siempre teniendo en cuenta que el throughput neto obtenido
está alrededor de un 50-70 % de esos valores.
Tecnología con estándar ampliamente conocido y fácil de configurar, lo que favorece los bajos
costes de los equipos.
Bajo consumo de potencia, menor a 10 W por enrutador.
Flexibilidad: un nodo puede adherirse a la red si puede ver a uno de los nodos vecinos (las
zonas rurales aisladas normalmente no siguen una distribución geométrica ordenada alrededor
de un punto central).
Hardware fácilmente integrable en un sistema impermeable que soporte condiciones meteorológicas adversas.
Inconvenientes:
Requiere línea de vista directa (esto podría elevar, en algunos casos, el número de repetidores
necesarios aumentando demasiado el costo).
Al ser una tecnología creada para redes de corto alcance, hay que solventar ciertos problemas
relacionadas con su utilización para distancias de decenas de Km.
El número de colisiones aumenta en relación con el número de usuarios.
Tiene un número limitado de canales no interferentes, 3 en 2.4 GHz y 8 en 5.8 GHz.
1.1.
Estándares WiFi
La familia de estándares IEEE 802.11 (802.11a, 802.11b y 802.1g), más conocida como WiFi,
tiene asignadas las bandas ISM (Industrial, Scientific and Medical) 902-928 MHz, 2.400-2.4835 GHz,
5.725-5.850 GHz para uso en las redes inalámbricas basadas en espectro ensanchado con objeto de
lograr redes de área local inalámbricas (WLAN).
WiFi comparte la mayoría de su funcionamiento interno con Ethernet, sin embargo difiere en
la especificación de la capa física (PHY) utilizando señales radio en lugar cable y en su capa de
control de acceso al medio (MAC), ya que para controlar el acceso al medio Ethernet usa CSMA/CD,
mientras que WiFi usa CSMA/CA. El gran ancho de banda (entre 1 y 11 Mbps para 802.11b y hasta
54Mbps para 802.11a/g) a un precio reducido, lo presenta como una de las mejores opciones para la
transmisión de datos y redes de telefonía empleando VoIP(voz sobre IP).
Existe una gran diferencia entre los distintos estándares WiFi. Es por ello que a continuación se
realiza una presentación teórica más detallada de cada uno de ellos.
El estándar 802.11 fue aprobado por el IEEE en 1997, permitiendo trabajar con velocidades de
transmisión de 1Mbps y 2Mbps. El estándar IEEE802.11b primero, y luego los estándares IEEE802.11a
1.2 Problemática del uso de WiFi para largas distancias
13
y IEEE802.11g, añadieron nuevas técnicas de modulación en la capa física logrando mayores velocidades de transmisión y una mayor robustez en la conectividad.
El estándar IEEE802.11a trabaja en la banda de frecuencia de los 5GHz utilizando la técnica de
transmisión OFDM. Da soporte a velocidades de transmisión de 6Mbps a 54Mbps y ocho canales
no interferentes de 20MHz. Esta banda de frecuencia está menos saturada que la de 2.4GHz, lo cual
es una ventaja, ya que la banda de 2.4GHz también es utilizada por algunos teléfonos inalámbricos, hornos microondas y equipos Bluetooth. El gran inconveniente de este estándar es el de no ser
compatible con el IEEE802.11b, mucho más difundido.
El estándar IEEE802.11b trabaja en la banda de frecuencia de 2.4GHz utilizando el sistema de
transmisión HR/DSSS. Mediante el uso de la modulación CCK se da soporte a las velocidades de
transmisión de 5.5Mbps y 11Mbps. Se cuenta con catorce canales (que pueden estar limitados a once
o trece según el país) de 22MHz, de los cuales se pueden utilizar simultaneamente hasta tres de forma
no interferente.
El estándar IEEE802.11g fue desarrollado a raíz del importante problema de incompatibilidad
entre los equipos de IEEE802.11a y IEEE802.11b. Además, la creación de este estándar atendía al
interés en incrementar la capacidad de los equipos y redes WiFi. IEEE802.11g trabaja en la banda de
frecuencia de 2.4GHz, manteniendo además los mismos canales y modulaciones de IEEE802.11b, y
añade el sistema OFDM mediante el cual se soportan velocidades de transmisión de hasta 54Mbps.
1.2.
Problemática del uso de WiFi para largas distancias
Dado que la que la tecnología WiFi fue en su inicio diseñada para redes locales, la mayor dificultad
reside en su aplicación para largas distancias.
1.2.1.
Capa física
Sin embargo, una cuidadosa revisión del estándar no deja entrever ningún elemento de la capa
física que limite el alcance de las comunicaciones WiFi en términos de distancia si no es el balance de
enlace. Los límites físicos de distancia alcanzable con WiFi dependerán, por lo tanto, de los siguientes
parámetros:
La máxima potencia que podamos transmitir (PIRE).
Las pérdidas de propagación.
La sensibilidad de recepción.
La mínima relación señal a ruido que estemos dispuestos a aceptar como suficiente.
El propio estándar determina que los límites de potencia que se puede transmitir dependen de la
legislación que atañe a la banda de frecuencias ISM para cada región geográfica, éstas se mostraron
en la Cuadro 1.1.
Además, hay algunos aspectos de la capa física que deben ser tenidos en cuenta para obtener una
mayor estabilidad en el enlace:
Velocidad. El protocolo IEEE802.11 recoge distintas velocidades según el modo de funcionamiento: 1, 2, 5.5 y 11 Mbps para 802.11b; 6, 9, 12, 18, 24, 36, 48 y 54 Mbps para 802.11a, y el
14
CAPÍTULO 1. REDES WIFI PARA LARGAS DISTANCIAS
conjunto de todas las anteriores para el modo 802.11g. Estos modos usan diferentes tipos de
modulación y codificación, de forma que cuanto mayor sea la velocidad, mayor es la potencia necesaria en recepción para mantener un enlace con una BER baja. Esta potencia, llamada
sensibilidad, obliga a usar velocidades bajas si se quiere lograr enlaces de larga distancia con
una cierta estabilidad. La diferencia en la sensibilidad de recepción entre 1 y 11Mbps, aunque
depende de equipos, suele ser de más de 10 dB, lo cual equivale prácticamente a cuadruplicar
con 1Mbps el alcance que se tiene con 11Mbps. Si además se tiene en cuenta que la banda ISM
2.4 GHz impone limitaciones en cuanto al nivel de potencia que es legal transmitir, es fácil
comprobar que para enlaces muy largos normalmente deben usarse las velocidades más bajas
de 802.11b para tener estabilidad y buena calidad. La aparición de tarjetas con mejores sensibilidades o la tecnología 802.11g pueden ayudar a lograr velocidades mayores. Así, por ejemplo
en el modelo de tarjeta Ubiquiti SR2 802.11b/g de 400mW, la diferencia de sensibilidad entre
el modo b en 1 Mbps y el modo g en 6 Mbps es de sólo 3dB.
Añadir también que en términos de estabilidad y prestaciones resulta mejor configurar la velocidad del canal a un valor fijo. La experiencia recomienda ser conservadores para soportar una
cierta pérdida de prestaciones que sin duda se va a dar con el tiempo por pérdida de alineación
de las antenas, cambios climáticos y otros factores.
Fenómenos meteorológicos. En las zonas rurales es frecuente encontrar condiciones meteorológicas adversas. Aunque tradicionalmente se suele decir que las lluvias influyen “de forma
sensible” a partir de los 10GHz, cuando los enlaces son muy largos una pequeña atenuación en
dB/Km acaba siendo importante. Los estudios consultados no parecen conceder mucho peso a
la atenuación de nubes y nieblas, pero todo depende de la distancia.
Polarización. El mejor comportamiento se da con polarización vertical, pero las condiciones
atmosféricas y el terreno pueden producir una cierta despolarización, con lo que la recepción
de la señal empeora y su atenuación aumenta.
Interferencias. Si bien en las zonas rurales aisladas esto no suele suceder, los enlaces que
conectan zonas aisladas con zonas urbanas se pueden ver afectados por este problema.
1.2.2.
Capa MAC
Asimismo, a parte de las restricciones que impone el balance de enlace, es patente que existen
restricciones explícitas de distancia ya que los resultados lo demuestran y, además, porque la capa
MAC tiene multitud de tiempos constantes definidos que tienen diferente efecto en función de la
distancia que haya entre estaciones. Estos tiempos se pueden apreciar en la Figura 1.1. Tras una
revisión cuidadosa [5] del estándar base IEEE 802.11, se pueden extraer tres tipos de limitaciones:
el temporizador de espera de los ACKs, la definición de tiempos relacionados con el Slottime, y el
cálculo del vector que se encarga de controlar el tiempo que se debe esperar cuando el canal está
reservado para la detección de portadora virtual (NAV).
1.2 Problemática del uso de WiFi para largas distancias
15
Figura 1.1: Esquema temporal de funcionamiento en el nivel MAC.
ACKtimeout: Este parámetro se define en el texto del estándar como el tiempo en que la estación
transmisora espera la llegada del ACK una vez que ha terminado la transmisión de un paquete.
Así pues, para que una comunicación WiFi funcione a una determinada distancia se tiene que
cumplir que el ACKtimeout sea mayor que el tiempo de propagación de ida y vuelta más el
SIFS, un tiempo fijo que define la separación entre la recepción del paquete de la transmisión
de su ACK en el receptor. No obstante, el estándar no da un valor claro a este parámetro, y
los equipos WiFi del mercado varían mucho en su implementación del ACKtimeout; algunos
sistemas tienen un valor por defecto de aproximadamente DIFS+SIFS pero que se puede modificar, y otras tienen valores no modificables pero más grandes. DIFS es el tiempo que cada
estación espera una vez que detecta que el canal ha quedado libre. Cuando una estación intenta
enviar un paquete a otra que está demasiado distante como para recibir de ella el ACK antes
de que transcurra el ACKtimeout, se interpretará que la transmisión falló y se retransmitirá; como lo mismo le sucede a cada retransmisión, cada paquete se retransmitirá el máximo número
de retransmisiones antes de descartarse y dejar paso al siguiente. La capa WiFi de la estación
transmisora “creerá” que no logró mandar el paquete, pero de hecho lo probable es que hayan
llegado correctamente varias copias de éste, de las que la primera se pasará a la capa superior
en el receptor. El resultado es que el enlace funciona, pero con un rendimiento ínfimo debido a
que todo se retransmite varias veces, por defecto 7.
Slottime. Los valores de Slottime, SIFS y DIFS imponen restricciones al funcionamiento del
MAC de WiFi a partir de ciertas distancias. El estándar prevé que las estaciones que transmiten
son oídas por las otras dentro del mismo slot en que se ha producido la transmisión, lo cual
impone un límite de unos 3 Km. Más allá de esa distancia, las prestaciones de los enlaces
empeoran con la distancia, aunque aún resultan utilizables si el número de nodos activos es
suficientemente bajo.
La vulnerabilidad con nodos ocultos. Se considera como “nodo oculto” a la situación donde
no todas las estaciones pueden escucharse, en IEEE 802.11 se emplea el mecanismo RTS/CTS
para evitar colisiones entre nodos ocultos; no obstante, ese mecanismo funciona si el cómputo
del NAV se corresponde con el tiempo que verdaderamente el canal va a permanecer ocupado;
puesto que el NAV no se calcula teniendo en cuenta el tiempo de propagación, a medida que
la distancia aumenta, su efectividad empeora; en enlaces PtMP con distancias del orden de
kilómetros, el RTS/CTS es prácticamente inservible, y no hay un mecanismo alternativo.
Como consecuencia de lo anterior, y dependiendo del tipo de enlace que define la arquitectura de
red 802.11, se pueden sacar las siguientes conclusiones:
16
CAPÍTULO 1. REDES WIFI PARA LARGAS DISTANCIAS
PtP. Cuando la distancia es mayor de 3 Km, se incrementa proporcionalmente con la distancia,
en saltos de 3 Km, el número de slots en que una estación puede empezar a transmitir y colisionar con un paquete cuya transmisión se inició en un slot determinado; esto tiene relativamente
poco impacto cuando la carga ofrecida es baja, pero es importante cuando el enlace está próximo a la saturación, ya que en ese caso casi siempre hay un paquete listo para ser transmitido tan
pronto como se considere libre el canal, y para ventanas de contención pequeñas la probabilidad
de colisión será significativa. También será necesario cuidar el ajuste del ACKTimeout fijándolo
a un valor ligeramente superior a dos veces el tiempo de propagación.
PtMP. Además de darse las mismas anomalías de comportamiento del MAC entre la estación
transmisora y receptora de un paquete que se han comentado para PtP, las otras estaciones que
observan pasivamente el canal esperando que se desocupe tomarán decisiones equivocadas al
considerar el canal libre cuando no lo está. Por ejemplo, si la distancia hace que los ACK se
reciban más tarde que DIFS, la estación transmisora todavía podrá esperar por el ACK si el
ACKTimeout es lo suficientemente grande, pero las otras estaciones cercanas a ésta que esperan
a que el canal se libere optarán a ocupar el canal de inmediato, pudiendo colisionar con cierta
probabilidad con el ACK que está en camino. Por lo que hay que fijar el ACKtimeout para el
enlace más largo que conforme ese PtMP.
En definitiva, WiFi puede servir, aunque con cierta pérdida de prestaciones, para enlaces PtP de
larga distancia si los equipos terminales permiten configurar el ACKtimeout y el Slottime; en cambio,
para PtMP, aún modificando esos parámetros, el funcionamiento es notablemente peor a menos que
la carga ofrecida y el número de nodos sean muy bajos.
1.3.
Uso de telefonía IP
Se puede utilizar la infraestructura de la red de datos WiFi para el transporte del tráfico, aplicando
protocolos de VoIP para el envío de tramas y señalización. Mediante el uso de este protocolo, la red
permite el acceso a servicios de telefonía local (entre establecimientos de la misma zona) de forma
gratuita en las redes WiFi, y conexión con la RTPC con ciertas restricciones de llamadas salientes (las
llamadas entrantes no tendrán ningún límite). Además, tiene la capacidad de habilitar servicios adicionales como buzón de voz, llamada a tres y más, transferencia de llamadas, etc., sin coste adicional.
VoIP es una tecnología de gestión y enrutamiento de comunicaciones de voz a través de redes de
datos (LAN, WAN) basadas en protocolos TCP/IP. El objetivo de utilizar las redes de datos para la
transmisión de voz es reducir los costos de contratación en líneas telefónicas locales convencionales.
Mediante este servicio los usuarios podrán establecer comunicaciones de voz con los establecimientos que forman parte de la red y con cualquier abonado de la RTPC. En el primer caso las
llamadas no tienen costo y la marcación es similar al caso de anexos en una empresa privada, mientras que para evitar problemas institucionales con temas de facturación por llamadas a números telefónicos de la RTPC y para evitar también problemas legales de competencia a operadoras de telecomunicación, se ha decidido que las centralitas telefónicas instaladas permitan únicamente llamadas
salientes a números de tarjetas prepago.
1.4 Arquitectura de redes WiFi para larga distancia
1.4.
17
Arquitectura de redes WiFi para larga distancia
Tradicionalmente la topología de red IEEE802.11 más usada ha sido en modo infraestructura. En
ella todas las estaciones que forman parte de la red se comunican entre sí a través de un punto de
acceso. El punto de acceso puede además proporcionar acceso a redes exteriores.
Sin embargo, la topología más básica de una red WiFi es aquella en la que un conjunto de estaciones (mínimo dos), se conectan entre sí de forma directa. Dicha topología suele recibir el nombre
de red Ad-Hoc. En este tipo de redes las estaciones se comunican de forma directa a través del medio
inalámbrico sin que medie ninguna otra. Debido a las limitaciones inherentes en el alcance de las
transmisiones puede que no todas las estaciones sean capaces de establecer comunicación entre sí,
puesto que deberán estar dentro del rango del alcance una de otra.
A partir del concepto de red Ad-Hoc en WiFi se contempla el establecimiento de redes Mesh. En
una red con topología Mesh una estación que desee transmitir a otra estación fuera de su alcance,
comprobará en su tabla de encaminamiento a qué estación dentro de su alcance debe transmitir la
información. Dicha estación recibirá el paquete y lo reenviará siguiendo el mismo procedimiento y
así sucesivamente hasta alcanzar la estación destino. Esto implica que todos los nodos de la red van a
gestionar los paquetes a nivel IP. Esto introduce algo más de retardo, pero éste, así como el ancho de
banda, se puede gestionar de forma muy avanzada.
Las redes Mesh además de incrementar sustancialmente el área de cobertura que puede alcanzar
una red (de límite indefinido si la distribución y densidad de las estación es adecuada) tienen la ventaja
de ser tolerantes a fallos, pues la caída de un nodo no implicará necesariamente la caída de la red (se
podrán seguir enviando los mensajes a través de otras rutas).
Otra topología posible es una cadena multisalto donde cada eslabón de la cadena está compuesto
por un enlace punto a punto en modo infraestructura. Ver figura 1.2:
Figura 1.2: Arquitectura de red cadena multisalto
18
CAPÍTULO 1. REDES WIFI PARA LARGAS DISTANCIAS
En muchos casos, esta topología es la única posible para enlazar comunidades rurales establecidas a lo largo de ríos amazónicos o en valles interandinos longitudinales; por ello, es la topología
más estudiada por GTR-PUCP. Al igual que una red Mesh, esta topología también permite extender
notablemente la cobertura; a diferencia de ella, en una cadena multisalto el camino físico está plenamente establecido, la comunicación iniciada en un nodo intermedio necesariamente debe pasar por
el nodo que lo antecede o que lo precede para llegar a su destino. Tiene el obvio inconveniente que
la “rotura” de algún enlace interrumpe la comunicación entre extremos, por ello es deseable que la
cadena tenga más de un punto de contacto con el exterior. Eventualmente la cadena puede cerrarse y
volverse un anillo.
Figura 1.3: Red cadena multisalto ramificada
1.4 Arquitectura de redes WiFi para larga distancia
19
Esta red puede ramificarse como se ve en la figura 1.3. Aunque cada nodo puede estar compuesto
del mismo equipamiento hardware, podemos establecer una diferenciación funcional de tres tipos de
nodos:
Estación pasarela: es una estación dotada de conectividad final a Internet y a la RTPC, permitiendo al resto de estaciones de la red inalámbrica acceder a través de ella a esas redes externas.
Puede haber una o varias de estas estaciones en una red inalámbrica, pero lo más frecuente es
que no se disponga más que de una. El uso de más de una implica el uso de encaminamiento dinámico. Estas estaciones frecuentemente tendrán que desempeñar funciones como NAT o
cortafuegos.
Repetidor: los distintos repetidores se unen formando la red troncal que se encarga de conmutar
las comunicaciones con otras estaciones.
Estación cliente: se encuentra en los puntos de servicio a usuarios. Suele tener conectado una
computadora y un teléfono IP.
Además es importante distinguir entre enlaces troncales y enlaces de distribución. Los enlaces
troncales constituyen la columna vertebral de la red, interconectan a todos los nodos repetidores y a
la estación pasarela, transportan el tráfico combinado de varios clientes. Los enlaces de distribución
permiten el acceso de los clientes a la red.
Figura 1.4: Encadenamiento de enlaces punto a punto en modo infraestructura
Como ya se mencionó, cada enlace punto a punto se realiza en modo infraestructura, lo que implica que un extremo de este enlace es un router que tiene una interfaz inalámbrica de red que se
comporta como STA estación “final” (sin importar que en esta topología el enlace podría estar en
medio de la cadena) y en el otro extremo hay otro router con una interfaz que se comporta como
punto de acceso AP. Para lograr la comunicación a lo largo de toda la cadena, el router usado en cada
nodo debe poseer por lo menos dos, y típicamente tres interfaces de red inalámbrica, lo que es equivalente a tener igual número de radios. En la figura 1.4 puede verse como cada una de estas interfaces
se puede configurar independientemente como STA ó como AP. También es posible que en cada nodo
20
CAPÍTULO 1. REDES WIFI PARA LARGAS DISTANCIAS
exista más de un router, unidos por enlaces cableados Ethernet. A fin de minimizar la interferencia,
cada par de enlaces contiguos se realiza en canales diferentes. 802.11b/g tiene 11 canales, 3 de ellos
no interferentes; por su parte 802.11a tiene 16 canales y 12 de ellos no solapados entre sí (4 de los 12,
señalados para enlaces punto a punto). Un equipo de estas características puede verse en la fig 1.5 en
la que se distinguen todos sus componentes, nótese que posee dos radios, de 400 y 80 mW.
1. Placa Alix
2. Caja de exterior metálica impermeable
3. Memoria CF de 512MB
4. Tarjeta inalámbrica SR2 (400mW)
5. Tarjeta inalámbrica CM9 (80mW)
6. Pigtail uFL-N macho
7. Pigtail uFL-N macho
8. Cable de energía
9. Cable de red cruzado
10. Prensa estopa
11. Prensa estopa
Figura 1.5: Elementos del router inalámbrico.
Debido a que debe existir línea de vista entre las antenas que establecerán un enlace, estas se
montan en la cima de torres elevadas. Cada antena se conecta con una interfaz de red inalámbrica de
un router. En microondas, las pérdidas de señal en los cables coaxiales de conexión son muy elevadas,
por ello el router debe colocarse a pocos metros de las antenas, es decir que también se monta en la
torre y para energizarlo es común que además se instale un sistema eléctrico autónomo en la torre [6].
1.4 Arquitectura de redes WiFi para larga distancia
Figura 1.6: Esquema de una estación repetidora.
21
22
CAPÍTULO 1. REDES WIFI PARA LARGAS DISTANCIAS
2
Hardware y software apropiados para la construcción de
routers WiFi de larga distancia
Un router inalámbrico es un dispositivo usado para la interconexión de redes inalámbricas con
otras redes, de cualquier tipo. En el mercado actual existen muchas soluciones y formas de equipamiento para un router inalámbrico WiFi. La mayoría de ellas son soluciones propietarias diseñadas para
enlaces interiores ó para enlaces exteriores de distancia media (alrededor de 30 km). En una solución
propietaria, el fabricante guarda reserva sobre el hardware y software del equipo, solo brinda la información suficiente para la configuración de los mismos.
Por otro lado, ninguno de los modelos propietarios disponibles en el mercado posee todos los requisitos necesarios para su uso en zonas rurales, tales como:
Bajo consumo. El dimensionado de los paneles solares es proporcional al consumo energético
de los diferentes componentes que conforman el router. En este sentido es importante que el
hardware usado tenga un consumo reducido.
Bajo coste. No se pueden implementar soluciones de un alto costo que no sean sostenibles en
el medio y largo plazo por las comunidades objetivo de estas redes.
Reducido tamaño. De esta forma se asegura que el diseño final del router sea lo más compacto
posible.
Robusto ante condiciones meteorológicas adversas. Ya que el router se suele instalar en zonas
de selva y alta montaña es necesario que tenga cierta robustez en cuanto a condiciones extremas
de temperatura y humedad.
Tipo de procesador. El router debe contar con un procesador lo suficientemente potente para
poder realizar las diferentes tareas que se le exijan.
Número mínimo y tipos de interfaces inalámbricas. Debido a que el router actúa como repetidor
en diversos escenarios es recomendable que al menos cuente con 3 interfaces inalámbricas.
Además, es necesario que estas interfaces sean de un tipo determinado (PCMCIA, CardBus,
mini-PCI) como se detalla en un apartado posterior.
Resto de interfaces. Además de las interfaces inalámbricas es necesario considerar otro tipo
de interfaces. Entre otras las dos más importantes son: una interfaz serie a través de la cual
23
CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN
24
DE ROUTERS WIFI DE LARGA DISTANCIA
poder acceder al router para labores de configuración y mantenimiento, y al menos una interfaz Ethernet para conectar otros dispositivos de red (por ejemplo un teléfono IP). También es
recomendable la existencia de una interfaz USB que permita extensiones o conexiones futuras.
Rangos y tipos de alimentación. Por razones de flexibilidad es recomendable que el router
cuente con un rango variable de alimentación. Valores alrededor de 12V resultan ser muy útiles,
ya que de esta forma se pueden alimentar de forma directa con el sistema de energía solar.
También será más que recomendable que la placa seleccionada tenga la opción de poder ser
alimentada a través de PoE (Power over Ethernet).
Disponibilidad de watchdog. Se recomienda la existencia de un watchdog hardware que permita
reiniciar la placa cuando ésta se bloquee.
Disponibilidad de compra en el medio/largo plazo. Este requisito resulta especialmente importante, ya que es necesario asegurar de alguna manera que el hardware seleccionado va a
seguir siendo distribuido en el medio y largo plazo. Son más que recomendable tener posibles
alternativas localizadas en caso de que sea necesario llegar a usarlas.
Los equipos comerciales propietarios que más se han acercado [14], [16], [22], [23], a cumplir
todos los requisitos técnicos finalmente han fallado en poseer una adecuada relación costo/beneficio.
Otra consideración en contra de los equipos comerciales es que no son completamente compatibles
con equipos de otros fabricantes, debido a que realizan modificaciones en el acceso al medio previsto en el protocolo 802.11. Finalmente nada desdeñables son los problemas que pueden surgir al
seleccionar una solución comercial propietaria tales como: dependencia tecnológica de un proveedor,
descontinuidad de los productos y costos de licenciamiento futuro.
Usando equipamiento genérico que soporta estándares abiertos y software libre, se pueden evitar
esos riesgos. Por ello, en paralelo al surgimiento de las iniciativas para realizar enlaces WiFi de larga
distancia, aparecieron en el mercado hardware, tales como placas SBC, tarjetas de red inalámbrica y
otros insumos con los cuales se podía armar un router WiFi por un precio generalmente menor ó mucho menor que el de un equipo propietario comercial. La aparición del mencionado hardware motivó
el desarrollo de herramientas de software libre tales como: versiones del sistema operativo Linux “a
medida” (instalable en poco espacio de disco, para hardware específico) y drivers para tarjetas de red
inalámbrica; y con ello finalmente la creación de routers WiFi apropiados se hizo posible.
Existen muchas maneras de armar un router inalámbrico, ya que se cuenta con muchos modelos
de tarjetas de red inalámbrica, placas SBC y accesorios. Por supuesto, también se puede armar routers
para uso en ambientes externos y muy agrestes, lo cuál depende de contar con una adecuada caja de
intemperie.
2.1 Placa SBC
25
Figura 2.1: Router inalámbrico alojado en caja de intemperie
Antes de pasar a describir las herramientas hardware y software mencionadas no se puede dejar
de mencionar que hay soluciones propietarias como [20] y [27] que se encuentran en un punto medio,
que poseen varias virtudes de los mundos propietario y libre.
2.1.
Placa SBC
Single board computers (SBCs) son computadoras completas construidas en una sola tarjeta de
circuito impreso (PCB, printed circuit board). Ellas incluyen microprocesador, memoria RAM, puertos de entrada y salida. No suelen incluir puertos para teclado y monitor, pues su fin no es trabajar
como computadora de escritorio, sino servir para un propósito específico como puede ser un dispositivo de telemetría o un router. Por este motivo también son llamadas “computadoras empotradas” ó
“embedded systems”. Algunas incorporan un sistema operativo y otras poseen ranuras para insertar
discos duros de estado sólido en formato SD (Secure Digital) o CF (Compact Flash).
2.1.1.
Tipo de procesador
En el mercado abundan las placas madres para desarrollar dispositivos de redes de datos con
procesadores sin FPU (http://en.wikipedia.org/wiki/Floating_point_unit, oating
point unit) y a la vez son de distintos tipos, lo que depende del fabricante; pero estos procesadores
están optimizados para manejar todo los procesos referentes a redes de datos (manejo de números enteros) como el Intel IXP425 Network Processor; aunque existen métodos para que estos procesadores
sin FPU manejen procesos de punto flotante (por ejemplo la ejecución de procesos de servidores Asterisk) los tiempos de operación son mucho más lentos comparados con los procesadores que poseen
FPU. Como existen distintos tipos de estos procesadores existen también muchos sistemas operativos
optimizados para cada tipo; por lo que los fabricantes de hardware además desarrollan también el
sistema operativo para sus placas y algunos de ellos son propietarios; pero existen sistemas operativos
libres (especialmente desarrollados en base a Linux) que manejen una familia específica de estos
procesadores.
CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN
26
DE ROUTERS WIFI DE LARGA DISTANCIA
Los procesadores que sí poseen FPU como el AMD Geode LX700, mantienen compatibilidad
con la arquitectura x86; específicamente este procesador es del tipo genérico, y no está optimizado para las redes de datos sino que puede manejar este tipo de procesos y otros como si fuera un
procesador x86 para equipos de escritorio o servidores; pero sólo limitado por la velocidad de procesamiento. En este caso existen muchos sistemas operativos libres (en base a Linux, FreeBSD, NetBSD, OpenBSD) y propietarios que manejen arquitecturas compatibles con x86; y a la vez son sistemas
genéricos; la gran ventaja con usar sistemas libres es que se puede adicionar o quitar aplicaciones que
sean convenientes a nuestro trabajo. Al tener FPU se puede trabajar aplicaciones de alto nivel como
por ejemplo el servidor Asterisk (http://www.asterisk.org/) que es una PBX software para
implementar redes de VoIP.
2.1.2.
Descripción de SBCs
2.1.2.1.
RouterBOARD 532A
http://www.routerboard.com/rb500.html
Es una de las placas que se basa en el procesador Freescale MPC8321 por lo que no tiene FPU.
Posee la gran ventaja de manejar hasta 4 y 6 interfaces inalámbricas miniPCI (por medio de tarjetas
adicionales) pero con el inconveniente que a más interfaces menos potencia administrada a cada uno.
Además viene con un sistema operativo propietario instalado llamado RouterOS, esto es un inconveniente por que no se podrá adicionar o cambiar aplicaciones particulares; pero existe la posibilidad de
instalar otro sistema operativo no propietario no sólo en su memoria integrada sino que al poseer una
ranura par CF se puede instalar otro sistema operativo sin perder el sistema propietario.
Figura 2.2: RouterBOARD 532A
2.1 Placa SBC
2.1.2.2.
27
RouterBOARD 333
http://www.routerboard.com/pdf/rb333b.pdf
Es una de las placas muy utilizadas por los desarrollares de redes inalámbricas. Se basa en el
procesador Freescale MPC8321 por lo que no tiene FPU (unidad de punto flotante). Posee la gran
ventaja de manejar tres interfaces inalámbricas miniPCI de alta potencia, además, al igual que la
placa anterior viene con el sistema operativo RouterOS instalado.
Figura 2.3: RouterBOARD 333
2.1.2.3.
Alix2C0
http://www.pcengines.ch/alix2c0.htm
Es una placa que se basa en el procesador AMD Geode LX700, es un x86 y posee FPU. No viene
con ningún sistema operativo, posee ranura para CF para instalar uno. Posee dos ranuras miniPCI que
con modificaciones soportará interfaces inalámbricas de alta potencia. Al ser un sistema x86 se tiene
la gran facilidad de trabajar con las distintas aplicaciones de redes conocidas de alto nivel.
Figura 2.4: Alix2C0
CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN
28
DE ROUTERS WIFI DE LARGA DISTANCIA
2.1.2.4.
Pronghorn SBC-250
http://www.adiengineering.com/php-bin/ecomm4/productDisplay.php?
category_id=30&product_id=79
Es una placa que se basa en un procesador Intel IXP425, 533 Mhz, por lo que no posee FPU.
Posee dos ranuras miniPCI que soportan interfaces inalámbricas de alta potencia. No trae un sistema
operativo pero se le puede instalar el que ofrece el mismo fabricante u otro porque posee una ranura
para CF. Es una placa que suministra más corriente a las interfaces miniPCI comparados con las otras
de la tabla.
Figura 2.5: Pronghorn SBC-250
2.1.2.5.
Pronghorn Metro SBC Quad-Radio Wireless
http://www.adiengineering.com/php-bin/ecomm4/productDisplay.php?
product_id=85
Esta placa consume mucha potencia en comparación a las anteriores porque maneja 4 interfaces
inalámbricas miniPCi de alta potencia, sin embargo justamente esta última característica hace deseable la prueba de esta placa. Sus características son similares al Pronghorn SBC-250; pero además
posee herramientas para manejar tarjetas WiMax.
Figura 2.6: Pronghorn Metro SBC Quad-Radio Wireless
Intel XScale,
IXP425, 533
Mhz, no FPU
Intel IXP425
533Mhz, no
FPU
Pronghorn
SBC-250
MIPs32 4Kc,
400MHz, no
FPU
Freescale
MPC8321,
266.333 MHz,
no FPU
Freescale
MPC8343E,
266,400,533,
Mhz, no FPU
AMD Geode
LX700, 433
Mhz, posee
FPU
AMD Geode
SC1100, 233
Mhz, posee
FPU
AMD
ElanSC520,
133Mhz,
posee FPU
Procesador
Pronghorn
Metro SBC
Quad-Radio
Wireless
RouterBOARD
532A
net4526-30
600
net4826-48
600
Alix2C0
600
RouterBOARD
600
RouterBOARD
333
Equipo
2.1.3.
64MB
64MB
64MB
64MB
128MB
128MB
64MB
64MB
Ram del
sistema
16MB soldado y
1 ranura CF
16MB soldado y
1 ranura CF
128MB integrada y
1 ranura CF
256MB de
CompactFLASH
integrada
256MB de
CompactFLASH
integrada
1 ranura CF
64MB integrada y 2
ranuras de CF
64MB integrada
Tipo de
almacenamiento
2
2
3
1
1
2
3, soporta
1000Mbps
3
Puertos
Ethernets
2, no menciona
alta potencia, pero
se hace cambios
para alta potencia
2, no menciona
4 tipo |||A, no pero
menciona alta
potencia
2, no menciona
4 tipo |||A, no pero
menciona alta
potencia
2 tipo |||A/|||B más
el daughterboards
RB502 ($) se
tiene 2 más, para
alta potencia
4, menciona para
alta potencia,
cada uno ofrece
6.5W, soporta
WiMax
2, menciona para
alta potencia,
cada uno ofrece
6.5W
4 tipo |||A/|||B,
para alta potencia
3 tipo |||A/|||B,
para alta potencia
Puertos miniPCI
5VDC
48VDC (SBC48) o 24VDC
(SBC-24)
6 a 22V o 25 a
56V DC (por
jumper), fuente
de 24W
6 a 20V DC,
fuente de 10W
6 a 28V DC,
fuente de 15W
7 hasta 20V,
fuente de 15W
10 a 56V DC,
fuente de 35W
12 a 28V DC,
fuente de 25W
Alimentación
190
300
200
150
200
116
245
habilitado
en mayo
180
Precio
aprox. ($)
Comparación de SBCs para aplicación de redes inalámbricas
AD|LinuxDistribution
StarOS, Linux 2.6,
OpenWRT, IkarusOS
AD|LinuxDistribution
StarOS, Linux 2.6,
OpenWRT, IkarusOS
MikroTik Router OS
Voyage Linux
Voyage Linux
iMedia ALIX Linux
Voyage Linux
MikroTik Router OS
MikroTik Router OS
MikroTik Router OS
Referencia del
sistema operativo
2.1 Placa SBC
29
CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN
30
DE ROUTERS WIFI DE LARGA DISTANCIA
2.2.
Tarjetas de red inalámbrica
La elección de tarjetas WiFi se basa en parámetros tales como la potencia de transmisión, sensibilidad de recepción, temperatura y humedad soportadas en operación, así como chipset incorporado.
Esta última condición es importante, ya que es necesario disponer de soporte para un S.O. GNU/Linux
para todos los modos (Master, Managed, Ad-hoc, Monitor) para poder construir puntos de acceso,
puentes, repetidores y encaminadores. Se ha trabajado con tarjetas de dos chipsets diferentes (Intersil
Prism 2.5 y Atheros), con modelos que transmiten desde 80mW hasta 600mW. Se recomienda usar
como controladores de las interfaces inalámbricas el driver Hostap para el caso de tarjetas con chipset
Intersil Prism 2.5 y MadWifi para tarjetas con chipset Atheros.
Mientras que el driver Madwifi permite modificar el valor de ACKtimeout, CTSTimeout y SlotTime,
comentados anteriormente y por lo tanto un mejor control de las prestaciones del sistema, el Hostap
no permite modificar los valores anteriores, sin embargo, las tarjetas con este driver tienen un valor
mayor ACKtimeout, de manera que pueden ser usadas con prestaciones aceptables en enlaces largos
de hasta 30km. No obstante, mientras que estas últimas sólo pueden ser configuradas en modo b,
distintos modelos con chipset Atheros soportan los estándares 802.11 a,b o g.
En conclusión las características deseables son:
Tarjetas de alta potencia en los estándares 802.11a/b/g.
Que tengan Chipset Atheros.
Consumo de corriente apropiada para la placa a utilizar.
Debe ser de factor de forma miniPCI.
2.2.1.
Comparación de tarjetas de red inalámbricas
Interfaces
Estándar
Potencia máx
en g en dbm
Potencia máx
en a en dbm
Conector antena
Sensibilidad
Corriente
SR2
g
26 @ 1-24Mbps
-
1 U.FL y 1 MMCX
1.1
R52H
SR5
ag
a
26 @ 6Mbps
-
26 @ 6Mbps
26 @ 6-24Mbps
2 U.FL
1 U.FL y 1 MMCX
XR2
g
28 @ 1-24Mbps
-
1 U.FL y 1 MMCX
XR5
a
-
28 @ 6-24Mbps
1 U.FL y 1 MMCX
EMP
-8602+S
WLM54A
-26dbm
WLM54G
-6B-30
ag
27 @ 6-24Mbps
22 @ 6-24Mbps
2 U.FL
a
-
26 @ 6-24Mbps
1 U.FL y 1 MMCX
6 Mbps -94 dBm
12 Mbps -91 dBm
6 Mbps -90dBm ag
6 Mbps -94 dBm
12 Mbps -91 dBm
6 Mbps -94 dBm
12 Mbps -91 dBm
6 Mbps -94 dBm
12 Mbps -91 dBm
6 Mbps -90 dBm a
6 Mbps -92 dBm g
6 Mbps -90 dBm a
g
30 @ 6-24Mbps
-
1 U.FL y 1 MCX
6 Mbps -90 dBm g
1.5
Cuadro 2.1: Comparación de tarjetas inalámbricas para WiFi de larga distancia.
0.8
1.3
1.3
1.8
1
1.5
2.2 Tarjetas de red inalámbrica
31
SR2 de Ubiquiti Networks
Figura 2.7: SR2
R52H de Mikrotik
Figura 2.8: R52H
SR5 de Ubiquiti Networks
Figura 2.9: SR5
CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN
32
DE ROUTERS WIFI DE LARGA DISTANCIA
XR2 de Ubiquiti Networks
Figura 2.10: XR2
XR5 de Ubiquiti Networks
Figura 2.11: XR5
EMP-8602+S de EnGenius Technologies
Figura 2.12: EMP-8602+S
2.2 Tarjetas de red inalámbrica
33
WLM54A-26dbm de Compex Systems
Figura 2.13: WLM54A
2.2.2.
Pigtails
Los pigtails son cables coaxiales con conectores adecuados para las tarjetas de red inalámbricas.
Estos se tratan, típicamente, de conectores UFL y MMCX, mostrados en la Figura 2.14. En el otro
extremo los pigtails tienen conectores N hembra o macho. Dado que los conectores UFL y MMCX
son sumamente pequeños, los pigtails están fabricados con cables coaxiales muy delgados de mucha
atenuación motivo por el cual deben ser lo más cortos posible (típicamente de 30 cm).
(a) Pigtail MMCX.
(b) Pigtail UFL.
Figura 2.14: Conectores Pigtail.
2.2.3.
Antenas
Las antenas son dispositivos pasivos que convierten la señal de radio frecuencia enviada por los
cables coaxiales en ondas electromagnéticas que se propagan en el espacio y viceversa.
Dada la diversidad de situaciones en las que las que se necesitan las antenas, tales como: PtP,
PtMP, con distancia entre los puntos variable, entre centenas de metros y decenas de kilómetros, y
con distintas características ambientales de los lugares donde se han instalado, se utilizan multitud de
modelos de antenas en función de estos requerimientos.
CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN
34
DE ROUTERS WIFI DE LARGA DISTANCIA
En GTR-PUCP siempre se ha confiado para la adquisición de estos equipos en la marca Hyperlink,
ya que es una marca ampliamente disponible y su relación calidad precio es una de las mejores del
mercado. Dentro de esta marca y dado que las antenas siempre se instalan a la intemperie, se eligen los
modelos específicos para exteriores. A partir de aquí la elección de la antena depende de la ganancia
necesaria de la misma para poder realizar el enlace y de la frecuencia en la que se va a realizar. Estos
datos se obtienen durante la etapa de diseño de la red. Es importante resaltar que los precios de las
antenas aumentan con su ganacia, por lo que un ajuste fino, en lo que a ganancia se refiere, puede
suponer grandes reducciones en el costo.
(a) HG5829D.
(b) HG2424G.
(c) HG5819P.
(d) HG2414SP-090.
Figura 2.15: Modelos de antena Hyperlink utilizados.
En la banda de 2.4 GHz algunos de los modelos utilizados son: la antena de grilla HG2424G de 24
dBi (Figura 2.15(b)), la antena de panel HG2418P de 14dBi, y las sectoriales HG2414SP-120 y la HG
2414SP-090 (Figura 2.15(d)) de 14 dBi de ganancia cada una y de 120 y 90o de haz, respectivamente.
En la de 5.8 GHz se han utilizado la antena de plato HG5829D de 29 dBi dada su gran ganancia y la
posibilidad de instalarle un radome, que la dota de mayor aerodinamicidad, fundamental en lugares
muy ventosos (Figura 2.15(a)), la antena de grilla HG5827G de 27 dBi y la de panel HG5819P de 19
dBi (Figura 2.15(c)).
NOTA: Las antenas de grilla tanto de 2.4 GHz como de 5.8 GHz tienen unas abrazaderas un tanto
débiles, por lo que en zonas de mucho viento se recomienda emplear un método de sujeción adicional.
2.3.
Sistema Operativo Linux Voyage
Linux Voyage es una distribución derivada de Debian que está optimizada para plataformas x86 de
propósito específico tales como las placas de PC Engines ALIX/WRAP o las de Soekris 45xx/48xx.
La instalación típica requiere un espacio en disco de 128MB, aunque una mayor capacidad de almacenamiento permite que se puedan instalar otros paquetes adicionales. Linux Voyage es muy pequeño,
por lo cuál es adecuado para ejecutarlo con características como firewall, access point inalámbrico,
gateway de VoIP, etc.
2.3.1.
Características
Las características más resaltantes de Linux Voyage son:
Su construcción está basada en la distribución Debian Sarge r3.1/Etch r4.0/Lenny r5.0 tomando
solo las aplicaciones necesarias para requerir un espacio de 128MB.
2.4 Driver MadWifi
35
La capacidad del sistema se puede incrementar de acuerdo a las necesidades por medio del
manejo de la aplicación apt
Kernel Linux 2.6
Total soporte para placas PC Engines ALIX/WRAP
Soporte WiFi
Soporte para diversos drivers de redes inalámbricas como madwifi, hostap, prism54, etc.
Soporte WPA vía hostapd y wpa_supplicant.
Soporte WDS vía drivers hostap y madwifi.
2.4.
Driver MadWifi
El proyecto Madwifi (Multiband Atheros Driver for Wireless Fidelity) es una iniciativa de software
libre cuyo objetivo es diseñar drivers para dispositivos de redes inalámbricas que posean chipset
Atheros. El proyecto tiene 3 líneas de trabajo: Madwifi, Ath5k y Ath9k. Madwifi es estable y funciona
correctamente. Los drivers Ath5k y Ath9k que también están siendo desarrollados por el proyecto
Madwifi no dependerán del HAL de Atheros, sin embargo, por el momento se debe preferir Madwifi
si se requiere una red inalámbrica estable. Madwifi posee licencia BSD/GPL, sin embargo el HAL se
distribuye bajo licencia del fabricante, en binario y como código cerrado. En el proyecto Madwifi se
han seguido las siguientes etapas:
Madwifi-old: El término “old” se refiere al driver madwifi liberado en Noviembre del 2005. Este
driver fue dado de baja en Junio del 2006.
Madwifi-ng: El término “ng” se refiere a “next generation”. Fue el código base entre Noviembre del
2005 y junio del 2006 y en ese tiempo fué llamado así (Madwifi-ng).
Madwifi: Abreviación de Madwifi-ng desde Junio del 2006.
2.4.1.
HAL y OpenHAL
El HAL (Hardware Abstraction Layer)se refiere a un software que da acceso a las características
del hardware, en nuestro caso da acceso a las características del chipset Atheros. Los requerimientos
de control de frecuencias y nivel de potencia han sido señaladas cómo requerimiento indispensable
para dispositivos inalámbricos en la FCC (Federal Communications Commission), y además estos
mecanismos no deban ser fácilmente vulnerables. Sin embargo, a pesar de todas estas consideraciones Atheros liberó su HAL bajo la licencia ISC (Internet Systems Consortium) lo cuál permite
su uso en cualquier proyecto de software libre. Los chipset Atheros pueden ser usados en un amplio
rango de frecuencias (frecuencias licenciadas y frecuencias no licenciadas). Por ese motivo el HAL
es distribuido solo en forma de binario para que usuarios no autorizados no puedan modificarlo tan
fácilmente y sin embargo la comunidad de software libre pueda interactuar mediante él de un modo
permitido. Una de las características más resaltantes del HAL Atheros es que se puede adecuar a las
características regulatorias de cada país mediante el código de ciudad (country code).
OpenHAL es un software que cumple las mismas funciones que el HAL Atheros y tiene como
objetivo reemplazarlo. Está basado en ar5k. Más información acerca de OpenHAL en http://
CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN
36
DE ROUTERS WIFI DE LARGA DISTANCIA
madwifi-project.org/wiki/About/OpenHAL
Ar5k es parte del driver Ath de OpenBSD para tarjetas inalámbricas Atheros. Ar5k es el componente
del driver que se comunica directamente con el hardware.
2.4.2.
Ath5k y Ath9k
El driver Ath5k aún está en desarrollo pero ya se encuentra disponible para uso público, puesto
que se encuentra incorporado en el kernel linux (2.6.25 y posteriores). También trabaja con tarjetas
de red inalámbricas Atheros, está basado en Madwifi y OpenHAL, por lo tanto no requiere del HAL
de Atheros. Se encuentra alojado en el repositorio wireless-2.6. Por el momento trabaja en modo Adhoc, Cliente y Mesh Point. Debido a que no depende del HAL de Atheros está proyectado que a largo
plazo reemplace a Madwifi y supere sus características.
El driver Ath9k fué inicialmente desarrollado por Atheros. Atheros después liberó su código para
que la comunidad de software libre continúe su desarrollo. Soporta las características disponibles en
802.11n. Está disponible en el kernel linux desde la distribución 2.6.27.
2.4.3.
Características
Madwifi Posee las siguientes características:
-Dispositivos compatibles:
Madwifi soporta dispositivos PCI, MiniPCI y Cardbus. Por el momento no hay soporte para USB.
-Modos de operación:
Son soportados los siguientes modos de operación:
Sta (Station). También conocido como cliente o managed. Es el modo que se cargará por defecto
si es que no se elige algún modo de trabajo. El dispositivo actuará como una estación cliente de
una red inalámbrica.
Ap (Access point). También conocido como master. El dispositivo trabaja como un punto de
acceso común para que otros clientes se cuelguen a su red de trabajo.
Ahdoc. La interfaz trabaja como un nodo de una red ad-hoc.
Monitor.
WDS (wireless distribution system). Permite la comunicación inalámbrica directa entre APs.
-Encriptación:
WEP (Wired Equivalent Privacy). Soportado en modos: ap, sta y adhoc.
WPA (WiFi Protected Access). Soportado en modos: sta (mediante: wpa_supplicant) y ap (mediante: hostapd)
2.4 Driver MadWifi
37
WPA2/IEEE 802.11i (WiFi Protected Access 2). Soportado en modos: sta (mediante: wpa_supplicant)
y ap (mediante: hostapd)
-Multi-BSSID:
Una de las características más interesantes de Madwifi es la creación de interfaces virtuales. Esto
significa que una sola interfaz física puede funcionar de distintos modos (sta, ap, repetidor, etc). Sin
embargo tiene limitaciones (como el uso de un canal común).
-Atheros Super A/G:
Colección de características propias de los chipset Atheros. Las cuáles fueron desarrolladas para
incrementar el ancho de banda y distancias de alcance de los dispositivos Atheros. Se pueden citar las
siguientes:
Bursting: Característica compatible con cualquier AP. Permite enviar varias tramas en simultáneo, en vez de enviarlas en cola. De este modo se toma menos tiempo para enviar gran cantidad
de datos incrementando el ancho de banda.
Fast Frame: Característica no soportada por todos los AP. Permite enviar mayor información en
cada trama, reduciendo tiempos de transmisión y aumentando el ancho de banda.
Compression: Los datos son comprimidos en cada trama que se envía, esto se realiza mediante el algoritmo de Lempel Ziv. Una vez que la característica es habilitada, la compresión y
descompresión se ejecuta dentro del chipset Atheros.
Turbo Mode: Característica no soportada por todos los AP. Permite que se transmita por 2
canales, ofreciéndose así un doble ancho de banda. Es beneficioso solo si todas las estaciones
de la red lo soportan. Se distinguen 2 modos Turbo.
Static: Se mantiene este modo de trabajo hasta que se apague.
Dinamic: La red decide en que momento se puede usar y en que momento no se puede el modo
turbo, según se detecte el tráfico de los canales adyacentes.
Adaptive Radio (AR): La característica de elegir cuando se puede usar y cuando no el modo
turbo mediante el sondeo de la banda de radio es llamada comúnmente AR.
Extended Range (XR): Característica propia de los clientes provee alcances más largos por
incremento de la sensibilidad del receptor de hasta -105dBm. Adicionalmente se agregan nuevas
tasas de transmisión: 3, 2, 1, 0.5, y 0.25MBits/s.
-4-address header:
Soporte para juntar segmentos ethernet e inalámbricos en una sola dirección o manejar 4 direcciones independientes.
CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN
38
DE ROUTERS WIFI DE LARGA DISTANCIA
- Roaming:
Escoge el mejor enlace que tiene en sistemas de distribución.
- Dynamic Frequency Selection (DFS):
Automáticamente evita canales usados por radar u otras aplicaciones similares.
- Background scanning:
Permite escanear otros canales sin perder datos.
2.4.4.
Requerimientos
-Hardware:
Tarjetas inalámbricas PCI, miniPCI o Cardbus con chipset Atheros. La lista de equipos compatibles es amplia, para revisar una lista completa visitar http://madwifi-project.org/wiki/
Compatibility
-Arquitectura:
Las arquitecturas soportadas por Madwifi son las siguientes: Alpha, ARM9, ARMv4, i386, MIPS,
MIPS ISA32, PowerPC (32 bits), SH4, Sparc (32 bits), Sparc64, X86_64 y XScale.
-Software:
*Kernel linux 2.6.x o superiores.
*Privilegios de root del dispositivo en la cuál se desea instalar Madwifi.
*Para Debian, Ubuntu y distribuciones afines ejecutar: apt-get install build-essential perl.
*Para Red Hat, Fedora y distribuciones afines ejecutar: yum install gcc make perl.
*Bajar última versión estable de Madwifi de http://madwifi-project.org/
*Aplicaciones para compilar e instalar gcc, libc headers, make y perl.
*Comandos de paquete wireless-tools (iwconfig, iwllist, etc.).
*Paquete wpa_supplicant para acceder a redes con encriptación WPA.
2.5.
Quagga
Quagga es un conjunto de programas de código abierto, para el control de protocolos de enrutamiento para sistemas Unix como NetBSD, FreeBSD, Solaris y Linux. Quagga esta bajo la licencia de GNU/General Public License (GPL). Actualmente proporciona versiones de código libre de
los protocolos OSPF, RIP y BGP.
2.5 Quagga
39
La arquitectura de quagga consiste de un demonio (programa que siempre esta corriendo) central
llamado Zebra. Zebra es el corazón de Quagga y funciona como el administrador del enrutamiento IP;
sirve como un capa de abstracción para el kernel y proporciona un API para los clientes Quagga (Zerv.
clients). Estos clientes implementan los protocolos de enrutamiento y envían las actualizaciones del
enrutamiento al demonio Zebra. Los Zerv. clients son:
ospfd: Implementación del OSPFv2
ripd: Implementación RIP v1 and V2
ospf6d: Implementación OSPFv3 (IPv6)
ripngd: Implementación RIPng (IPv6)
bgpd: Implementación BGPv4+ (incluye soporte para multicast y IPv6)
Además la arquitectura de Quagga también incluye bibliotecas para el desarrollo e implementación
de más protocolos, clientes y demonios.
Figura 2.16: Arquitectura de Quagga
CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN
40
DE ROUTERS WIFI DE LARGA DISTANCIA
3
Software PBX Asterisk
3.1.
VoIP
Voz sobre IP (Voice over IP) es un grupo de recursos que hacen posible que la señal de voz viaje
a través de redes TCP/IP. Esto significa que se envía la señal de voz en forma digital en paquetes en
lugar de enviarla (en forma digital o analógica) a través de circuitos utilizables sólo para telefonía
como una compañía telefónica convencional (PSTN: Public Switched Telephone Network).
Los Protocolos que son usados para llevar las señales de voz sobre la red IP son comúnmente
referidos como protocolos de Voz sobre IP. El tráfico de Voz sobre IP puede circular por cualquier red
TCP/IP, incluyendo aquellas conectadas a Internet.
VoIP es el conjunto de normas, dispositivos, protocolos, en definitiva la tecnología que permite la
transmisión de la voz sobre el protocolo IP. Telefonía sobre IP es el conjunto de nuevas funcionalidades de la telefonía, tradicional debido a los servicios que se pueden ofrecer gracias a poder enviar
la voz sobre el protocolo IP en redes de datos TCP/IP.
La voz ha de codificarse para poder ser transmitida por la red IP. Para ello se hace uso de Codecs
que garanticen la codificación y compresión del audio o del video para su posterior decodificación y
descompresión antes de poder generar un sonido o imagen utilizable. Según el Codec utilizado en la
transmisión, se utilizará más o menos ancho de banda y recursos del sistema de cómputo. La cantidad
de ancho de banda suele ser directamente proporcional a la calidad de los datos transmitidos. Entre los
Codecs utilizados en VoIP encontramos los G.711, G.723.1 y el G.729 (especificados por la ITU-T).
Entre los codecs más comunes se encuentran:
G.711: Estándar para la compresión de audio para telefonía. Representa las señales de audio
mediante muestras comprimidas en una señal digital con tasa de muestreo de 8000 muestras
por segundo con un flujo de datos de 64 Kbps. Existen dos tipos:
∙ 𝜇-law: Usado sobre todo en Norte América y Japón. Codifica cada 14 muestras
en palabras de 8 bits.
∙ a-law: Usado en Europa y en el resto del mundo. Codifica cada 13 muestras en
palabras de 8 bits.
G.723: Estándar que puede operar a 6.3 Kbps o 5.3 kbps.
41
42
CAPÍTULO 3. SOFTWARE PBX ASTERISK
G.726: Estándar basado en ADPCM (Adaptative Differential Pulse Code Modulation). Permite
trabajar con velocidades de 16, 24, 32 y 40 Kbps. Este codec proporciona una disminución
considerable del ancho de banda sin aumentar en gran medida la carga computacional.
G.729: Se usa sobre todo en aplicaciones de Voz sobre IP por los bajos requerimientos en ancho
de banda. Opera con tasas de 8 Kbps pero existen extensiones para tasas de 6.4 y 11.8 Kbps
para peor o mejor calidad de voz respectivamente.
GSM (Global System Mobile): Estándar que opera a 13 Kbps con una carga de CPU aceptable.
Inicialmente fue desarrollado para la telefonía móvil.
iLBC (Internet Low Bit rate Codec): Algoritmo complejo desarrollado por Global IP Sound
(GIPS) que ofrece una buena relación ancho de banda/calidad de voz a cambio de una mayor
carga computacional. Opera a 13.3 Kbps y 15.2 Kbps.
Speex: Implementa un algoritmo capaz de variar la velocidad de transmisión dependiendo de
las condiciones actuales de la red (VBR: Variable Bit Rate). El ancho de banda puede variar
desde 2.15 a 22.4 Kbps.
Actualmente no es posible garantizar la calidad de servicio sobre Internet y en cierto grado en
redes LAN; por eso, se presentan diversos problemas. No es aceptable latencias (tiempo transcurrido
desde el instante en que se genera un paquete hasta que se recibe) superiores a 300 ms ida y vuelta
(150 ms en una dirección). La calidad de este servicio se está logrando bajo los siguientes criterios:
La supresión de silencios, otorga más eficiencia a la hora de realizar una transmisión de voz, ya
que se aprovecha mejor el ancho de banda al transmitir menos información.
Compresión de cabeceras aplicando los estándares RTP/RTCP.
Priorizar los paquetes que requieran menor latencia.
3.2.
Asterisk
Asterisk es una aplicación de software libre (bajo licencia GPL) que proporciona funcionalidades
de una central telefónica (PBX). Como cualquier PBX, se puede conectar un número determinado
de teléfonos para hacer llamadas entre sí e incluso conectar a proveedores de VoIP y de telefonía
convencional tanto analógica como digital. Originalmente desarrollado para el sistema operativo
GNU/Linux, Asterisk actualmente también se distribuye en versiones para los sistemas operativos
BSD, MacOSX, Solaris y Microsoft Windows, aunque la plataforma nativa (GNU/Linux) es la mejor
soportada de todas.
Asterisk incluye muchas características como buzón de voz, conferencias, IVR, distribución automática de llamadas, y otras muchas más tal como PBX comerciales. Los usuarios pueden crear
nuevas funcionalidades por medio de lenguaje script de Asterisk o añadiendo módulos escritos en
cualquier lenguaje de programación soportado por Linux.
Las versiones estables de Asterisk están compuestas por los módulos siguientes:
Asterisk: Archivos base del proyecto.
3.2 Asterisk
43
Zaptel: Soporte para hardware Digium. Drivers de tarjetas.
Addons: Complementos y añadidos del paquete Asterisk.
Libpri: Soporte para conexiones digitales.
Sounds: Aporta sonidos y frases en diferentes idiomas.
Cada uno de estos módulos cuenta con una versión estable y una versión de desarrollo. Hasta
ahora; las versiones desarrolladas son la 1.6 y la 1.4. Las versiones 1.2 y 1.0 se consideran paralizadas
y ya no se continuarán manteniendo. Actualmente la rama 1.4 es la aconsejada para sistemas en
producción.
Figura 3.1: Arquitectura Asterisk.
La arquitectura de Asterisk está basada en 4 API:
API de Canales Asterisk: controla el tipo de conexión por el cual el cliente está llegando (bien
sea una conexión SIP, H323, BRI, etc).
API de Aplicaciones Asterisk: permite a varios módulos de tareas, cumplir varias funciones
(conferencias, buzones de voz, etc).
44
CAPÍTULO 3. SOFTWARE PBX ASTERISK
API de Traducción de Codecs: carga módulos, codecs, para apoyar varios tipos de audio, codificando y decodificando formatos tales como G711, G729, GSM11, etc.
API de formato de ficheros Asterisk: controla la lectura y escritura de varios formatos de
archivos para el almacenaje de datos en el sistema de archivos.
Usando estas API Asterisk alcanza una completa abstracción entre sus funciones básicas y las
diferentes tecnologías y aplicaciones relacionadas.
Asterisk permite implementar los mismos servicios que una central clásica, entre ellas:
Transferencia de llamadas, internas y externas.
Desvío de llamadas si está ocupado o no contesta.
Opción No molestar (Do Not Disturb).
Parking de llamadas (Call Parking).
Llamada en espera (Hold).
Grupos de llamada (Ring groups).
Identificador de llamante (CallerID).
Operadora Digital (menús interactivos y guiados).
Música en espera y en transferencia (ficheros MP3 actualizables por el usuario).
Captura de llamadas de forma remota (remote pickup).
Buzones de voz (general, individuales, por grupos) protegidos por contraseña.
Gestión de listas negras (números telefónicos con acceso prohibido).
Salas de conferencia (2 o más terminales simultáneamente).
Registro y listados de llamadas entrantes y salientes, con gráficas de consumo.
Detección automática de entrada de faxes.
Recepción de fax desde el propio sistema y posterior envío por e-mail.
Gestión de colas de llamadas entrantes.
Grabación de llamadas entrantes y salientes.
Monitorización de llamadas en curso.
Soporta videoconferencia con protocolos SIP e IAX2.
3.3 Protocolos VoIP
45
Asterisk tiene soporte para casi todos los codecs de audio como: G.711, G.723.1, G.726, G.729,
GSM, ilbc14, linear, lpc-1015, speex. Quizá lo más interesante de Asterisk es que soporta muchos
protocolos VoIP como pueden ser SIP, H.323, IAX y MGCP.
Asterisk permite integrar una red de telefonía IP con redes telefónicas tradicionales por medio de
interfaces analógicos y digitales. Para la conexión con líneas analógicas se hace a través de dispositivos FXO y FXS. Para la conexión con líneas digitales RDSI se logra por medio de interfaces del
tipo BRI (2 canales de voz de + 1 de señalización) y PRI (30 canales de voz + 1 de señalización).
Las interfaces de telefonía analógica se encuentran en múltiples dispositivos de redes (routers,
centrales de telefonía IP, etc.) que operan como acceso hacia los servicios de voz convencionales
como la telefonía pública. Para la conexión con estas líneas analógicas se hace por medio de interfaces
FXS y FXO.
FXS Foreign eXchange Station: También denominada interfaz de abonado. Es el que envía
la línea analógica hacia el abonado. Se trata de interfaces que permiten conectar dispositivos
terminales, como un teléfono analógico convencional a un router o central de telefonía IP. Una
interfaz FXS proporciona alimentación eléctrica, señalización de llamada y tono al dispositivo
terminal.
FXO Foreign eXchange Office: Es un puerto que recibe la línea analógica. Es la interfaz que
permite conectar un dispositivo terminal a un servicio de telefonía como el servicio de telefonía
pública (PSTN) o una PBX. Envía al sistema telefónico una señal de colgado o descolgado.
FXS y FXO son siempre pares que se corresponden mutuamente; una interfaz FXS se conecta
en el otro extremo de la línea a una interfaz FXO. Cuando se instala una central telefónica (PBX),
la línea telefónica se conecta al puerto FXO de la PBX, la cual provee múltiples puertos FXS para
conectar los teléfonos o aparatos de fax. Un adaptador telefónico o ATA actúa como un FXS.
Figura 3.2: Interfaces FXS y FXO.
3.3.
Protocolos VoIP
El objetivo de VoIP es dividir en paquetes los flujos de audio para transportarlos sobre redes
basadas en IP. Los protocolos de redes IP originalmente no fueron diseñados para el transporte en
tiempo real de audio o cualquier otro tipo de flujo de audio/video; por lo que se han creado protocolos para VoIP, cuyo mecanismo de conexión abarca una serie de transacciones de señalización entre
terminales que cargan flujos de audio para cada dirección de la conversación.
46
3.3.1.
CAPÍTULO 3. SOFTWARE PBX ASTERISK
IAX (Inter Asterisk eXchange)
IAX es uno de los protocolos utilizado por Asterisk; es utilizado para manejar conexiones VoIP
entre servidores Asterisk, y entre servidores y clientes que también utilizan protocolo IAX. El protocolo IAX ahora se refiere generalmente al IAX2, la segunda versión del protocolo IAX.
IAX es robusto, lleno de novedades y muy simple en comparación con otros protocolos. Permite
manejar una gran cantidad de codecs y un gran número de flujo audio/video, lo que significa que
puede ser utilizado para transportar virtualmente cualquier tipo de dato. Esta capacidad lo hace muy
útil para realizar videoconferencias o realizar presentaciones remotas.
IAX utiliza un único puerto UDP, generalmente el 4569, para comunicaciones entre puntos finales
para señalización y datos. El tráfico de voz es transmitido in-band (se refiere a las comunicaciones que
tienen lugar dentro de un método de comunicación previamente establecido), lo que hace a IAX2 un
protocolo casi transparente a los cortafuegos y realmente eficaz para trabajar dentro de redes internas.
En esto se diferencia de SIP, que utiliza una cadena RTP out-of-band (se refiere a las comunicaciones
que tienen lugar fuera de un método de comunicación previamente establecido) para entregar la información.
IAX soporta Trunking (red), donde un simple enlace permite enviar datos y señalización por
múltiples canales. Cuando se realiza Trunking, los datos de múltiples llamadas son manejados en un
único conjunto de paquetes, lo que significa que un datagrama IP puede entregar información para
más llamadas sin crear latencia adicional. Esto es una gran ventaja para los usuarios de VoIP, donde
las cabeceras IP son un gran porcentaje del ancho de banda utilizado; en contraparte se consumirá
mayores recursos del equipo de cómputo.
El principal objetivo de IAX ha sido minimizar el ancho de banda utilizado en la transmisión de
voz y vídeo a través de la red IP, con particular atención al control y a las llamadas de voz y proveyendo
un soporte nativo para ser transparente a NAT. La estructura básica de IAX se fundamenta en la
multiplexación de la señalización y del flujo de datos sobre un simple puerto UDP entre dos sistemas.
3.3.2.
SIP (Session Initiation Protocol)
SIP (Session Initiation Protocol); fué desarrollado por el IETF MMUSIC (Multiparty Multimedia
Session Control)) Working Group; con la intención de ser el estándar para la iniciación, moderación
y la finalización de sesiones multimedia de dos pares (unicast) o multipares (multicast). SIP es un
protocolo genérico, es un estándar y su RFC es la 3261. SIP ofrece flexibilidad para controlar sesiones
multimedia como llamadas de voz y video, videoconferencia, mensajería instantánea; juegos online y
telefonía IP. Una sesión puede ser una simple llamada telefónica de doble vía o puede ser una sesión
de conferencia multimedia con muchas personas participando.
SIP es un protocolo de señalización orientado a conexiones end-to-end; esto quiere decir que toda
la lógica se encuentra almacenada en los dispositivos finales (salvo el enrutamiento de mensajes SIP).
La ventaja es la estabilidad que se obtiene pues los servidores no son saturados con mensajes SIP; la
desventaja de esto es que los encabezados son mucho mayores.
SIP esta basado en arquitectura cliente-servidor similar al HTTP y el SMTP. Esta similitud es
natural ya que SIP fue diseñado para que la telefonía se vuelva un servicio más en la Internet.
SIP es un protocolo de la capa de Aplicaciones de la familia TCP/IP. Está relacionado estrechamente
con el Protocolo SDP y coexiste junto con otros protocolos del mismo nivel y funciones, como el
H323.
3.3 Protocolos VoIP
47
SIP no es protocolo de propósito general; su objetivo es ayudar a establecer y finalizar la comunicación. SIP se apoya de otros protocolos para lograr una llamada telefónica, una sesión de video
conferencia o mensajería instantánea; etc. Los protocolos que apoyan comúnmente son: RTSP (RealTime Streaming Protocol) para el control de flujos y sesión, SDP (Session DescriptionProtocol) para
describir los flujos, RTP/RTCP (Real Time Protocol / Real Time Control Protocol) para el transporte
de datos en tiempo real y RSVP (Resource Reservation Setup Protocol) junto a DiffServ (Differentiated Services) para la calidad del servicio y la reserva de recursos.
Figura 3.3: SIP (Session Initiation Protocol)
En las redes TCP/IP, las conversaciones (flujo audio/video) que usan señalización del tipo SIP
hacen uso del RTP. El protocolo RTP es el encargado de llevar las conversaciones (flujo audio/video)
de un lado a otro. De la misma forma que en una conversación existen dos flujos de voz, en una conversación en una red TCP/IP se tiene dos flujos de paquetes RTP.
Figura 3.4: La señalización SIP y las conversaciones de voz (RTP) viajan por caminos distintos.
Los Network Address Translators (NATs) son los problemas del RTP. El efecto de un NAT en voz
sobre TCP/IP es que no se pueden recibir conexiones iniciadas desde el exterior; el que inicia la llamada desde dentro del NAT no puede escuchar a la otra parte. Si los dos comunicantes se encuentran
dentro de NAT ningún flujo de audio originado detrás de los NAT llegará a su destino final. Para este
problema ya existen soluciones implementadas en Asterisk.
48
3.3.2.1.
CAPÍTULO 3. SOFTWARE PBX ASTERISK
Elementos del SIP
La configuración más simple para establecer una sesión SIP es utilizando sólo dos agentes de
usuario (UA) conectados uno a otro. Los elementos básicos de un sistema son los UA y los servidores;
estos últimos pueden ser de diferentes tipos: Proxy, de Registro y de Redirección.
El protocolo SIP permite el establecimiento de sesiones multimedia entre dos o más usuarios. Para
hacerlo se vale del intercambio de mensajes entre las partes que quieren comunicarse.
User agents (UA): Los Agentes de usuario son los puntos extremos del protocolo SIP, es decir son
los que emiten y procesan los mensajes del protocolo SIP. Un videoteléfono, un teléfono, un cliente
de software y cualquier otro dispositivo similar es un agente de usuario para SIP. El protocolo SIP no
se ocupa de la interfaz de estos dispositivos con el usuario final, sólo se interesa por los mensajes que
estos generan y cómo se comportan al recibir determinados mensajes.
Los agentes de usuario se comportan como clientes (UAC: User Agent Clients) y como servidores
(UAS: User Agent Servers). Un agente de usuario se comporta en UAC cuando realizan una petición
y son UAS cuando la reciben y responden a la misma. Por esto los agentes de usuario deben implementar un UAC y un UAS.
Servidores de Registro: El protocolo SIP permite establecer la ubicación física de un usuario determinado, esto es en qué punto de la red está conectado. Para ello se vale del mecanismo de registro.
Cada usuario tiene una dirección lógica que es invariable respecto de la ubicación física del usuario.
Una dirección lógica del protocolo SIP es de la forma usuario@dominio. La dirección física es dependiente del lugar en donde el usuario está conectado (su dirección IP). Cuando un usuario inicializa
su terminal (p. e. conectando su teléfono o abriendo su software de telefonía SIP) el agente de usuario
SIP que reside en dicho terminal envía una petición con el método REGISTER a un Servidor de Registro, informando a qué dirección física debe asociarse la dirección lógica del usuario. El Servidor de
Registro realiza entonces dicha asociación; esta asociación tiene un período de vigencia; termina si
no es renovada; también mediante un desregistro.
Un Servidor de Registro es comúnmente sólo una entidad lógica y la mayoría de las veces se localiza
junto con el Servidor Proxy.
Servidores Proxy y de Redirección: Para encaminar un mensaje entre un agente de usuario
cliente y un agente de usuario servidor normalmente se recurre a los servidores.
El Proxy, se encarga de encaminar las invitaciones de la sesión para llevarlos hasta el UA llamado.
Como Redirección, genera una respuesta que indica al que origina la comunicación la dirección del
destino o de otro servidor que lo acerque al destino. Este tipo de servidor sólo escucha peticiones y
regresa respuesta que contiene la localización actual de un usuario en particular u otro servidor.
La principal diferencia es que el servidor Proxy queda formando parte del camino entre el UAC y el
(o los) UAS, mientras que el servidor de Redirección una vez que indica al UAC cómo encaminar
el mensaje ya no interviene más. Un mismo servidor puede actuar como Redirección o como Proxy
dependiendo de la situación.
Un agente de usuario normalmente encamina todos sus pedidos hacia un servidor de su propio dominio. Es este quien determina (por sus propios medios o valiéndose de otros servidores) las ubicaciones de los usuarios que son llamados por el agente de usuario en cuestión.
Un conjunto de usuarios que pertenecen a una compañía o proveedor de servicios de comunicaciones,
conforman un dominio. Este dominio, que se indica en una dirección SIP después del caracter “@” es
3.3 Protocolos VoIP
49
normalmente atendido por un servidor o más de uno. Este servidor recibe las peticiones de sus usuarios. Este servidor será el encargado de determinar la dirección física del usuario llamado. Un servidor
que recibe las peticiones destinadas a un dominio específico es denominado servidor entrante (Inbound Server). Es habitual también, que exista un servidor que reciba las peticiones originadas por
los usuarios de un dominio hacia otros dominios. Este recibe el nombre de Servidor Saliente (Outbound Server).
Mensajes SIP: Existen dos tipos básicos de mensajes SIP, peticiones y respuestas. Las solicitudes
y las respuestas emplean el formato de mensaje genérico, que consiste en una línea inicial (Star – Line
o Request – Line) seguida de un o más campos de cabecera (Message Header), una línea vacía que
indica el final de las cabeceras, y por último, el cuerpo del mensaje (Message Body) que es opcional.
La línea inicial contiene la versión del protocolo; el método y direcciones involucradas en la sesión
para las peticiones; mientras que el estado de la sesión para el caso de las respuestas. El encabezado
contiene información relacionado con la llamada en forma de texto; por ejemplo el origen y destino
de la petición, el identificador de la llamada, etc. El cuerpo del mensaje o carga útil (payload) lleva la
información (comúnmente SDP o ISUP en caso de una troncal hacia la PSTN).
Las peticiones (Request Line) se emplean para iniciar alguna acción o para información; incluyen
el nombre del método al que invocan, el identificador del destinatario, el protocolo SIP que se esta
utilizando; para esto utiliza métodos y son:
Invite: Utilizado para invitar un usuario para participar en una sesión o para modificar parámetros.
Ack: Confirma el establecimiento de una sesión.
Option: Solicita información sobre las capacidades de un servidor.
Bye: Indica la finalización de una sesión.
Cancel: Cancela una petición pendiente.
Register: Registra un UA.
Las peticiones no contienen por lo general un cuerpo de mensaje; porque no lo requiere.
Las respuestas (Status Line) se generan como retorno de una petición, devolviendo un código de
estado; la línea llevará el SIP utilizado, código de respuesta y una pequeña descripción de ese código.
Podemos recibir estas respuestas según el rango:
1xx: Mensaje provisional. La petición fue recibida pero se desconoce aun el resultado del procesamiento. El emisor detiene el envío de retransmisión después de recibir una petición de este
tipo. Un ejemplo es el código 180=ringing o el 100=trying.
2xx: Éxito. Son respuestas finales positivas. La petición fue recibida y procesada exitosamente.
Por ejemplo 200=OK significa que el extremo llamado acepto la invitación a la sesión.
3xx: Redirección: Son usados para redireccionar las llamadas. Dan información acerca de la
nueva localización de un usuario o sobre un Proxy alterno que puede resolver satisfactoriamente
alguna petición . El emisor del mensaje de petición debe reenviar su petición a otro para que su
petición sea atendida.
50
CAPÍTULO 3. SOFTWARE PBX ASTERISK
4xx: Fallo de método. Son respuestas finales negativas. Falla del lado del emisor, mala sintaxis
del mensaje, etc.
5xx: Fallos de servidor. Falla del lado del servidor. Aparentemente la petición es válida pero el
Proxy es incapaz de procesarla. El emisor debe reintentar después.
6xx: Fallos globales. La petición no puede ser atendida en ningún Proxy.
Transacciones SIP: Una transacción SIP es una secuencia de mensajes entre dos elementos de
Red. Una transacción corresponde a una petición y todas las respuestas a esa petición. Esto quiere
decir que una transacción incluirá cero o más respuestas provisionales y una o más respuestas finales;
en el caso de un mensaje INVITE puede ser dividido por un Proxy y por lo tanto tendrá múltiples
respuestas finales. Las entidades SIP que almacenan el estado de las transacciones son denominadas
Stateful; lo que hace por medio del registro de cada transacción.
Diálogos SIP: Un dialogo SIP es una conversación peer-to-peer entre dos UA. Los diálogos
son identificados usando los campos Call-ID, From y To. Los mensajes con estos campos iguales
pertenecen al mismo dialogo. El campo CSEQ es utilizado para ordenar los mensajes en un dialogo. De hecho el CSEQ representa el número de transacción. De forma simple se puede decir que un
diálogo es una secuencia de transacción.
3.3.2.2.
Flujo de establecimiento de una sesión SIP
En una sesión SIP común se encuentra etapas como:
Registro: Para que un usuario pueda ser llamado por otro, este debe registrarse primero ante el Proxy.
El registro consiste en el envío de un mensaje REGISTER seguido de su correspondiente respuesta
200 (OK). En caso de que el usuario no haya dado credenciales validas recibirá por respuesta un
mensaje 407, con lo cual tendrá que reenviar el mensaje de Registro hasta que tenga éxito.
Invitación a una sesión: Una invitación inicia con el mensaje INVITE dirigido comúnmente al
Proxy. Este responde con TRYING (100) para detener las retransmisiones y reenvía las peticiones
hacia el usuario llamado. Todas las respuestas provisionales generadas por el usuario llamado son
regresados al usuario origen. Por ejemplo RINGING (180) que es un mensaje que se envía cuando el
usuario es contactado y comienza a timbrar. Una respuesta 200 (OK) es generada en cuanto el usuario
llamado descuelga el auricular.
Terminación de sesión: Una sesión es finalizada cuando uno de los usuarios envía el mensaje
BYE al otro extremo. El otro usuario confirma el final de la conversación enviando por respuesta un
mensaje 200 (OK). La transacción para finalizar la sesión se realizará de un extremo a otro sin pasar
por el Proxy a menos que en el mismo se haya establecido un proceso de Registro de ruta.
Existen situaciones en las que el Proxy requiere estar en la ruta de todos los mensajes con fines de
control del tráfico o por ejemplo, cuando existe un NAT. El Proxy o los Proxy logran esto por medio
de la inserción del campo RECORD ROUTE en los encabezados de los mensajes SIP.
3.3.3.
Protocolo de Descripción de Sesión SDP
Session Description Protocol (SDP); es un formato para describir parámetros de inicialización de
flujo audiovisual. SDP esta diseñado para transportar información de la sesión hacia los destinatarios,
3.3 Protocolos VoIP
51
Figura 3.5: Registro SIP
así como información de los flujos audiovisuales referentes a la misma. Este permite además asociar
más de un flujo audiovisual a una misma sesión; por ejemplo en una misma sesión puede existir un
flujo para audio y uno más para video o transferencia de documentos.
SDP es exclusivamente para propósito de descripción y negociación de los parámetros de sesión.
No transporta el flujo audiovisual en sí. Fue pensado para trabajar en conjunto con otros protocolos
como SIP, Megaco o HTTP. El transporte de información acerca de los flujos audiovisuales permite
a los destinatarios participar en la sesión si ellos soportan dichos flujo. Además SDP permite la negociación de los parámetros de flujo tales como la tasa de muestreo de la señal, el tamaño de los
paquetes, etc.
La información que SDP incluye en sus paquetes de forma general es la siguiente:
La versión del protocolo
El nombre de la sesión y su propósito
El tiempo que la sesión esta activa.
Los medios relacionados con la sesión (video, audio, formatos para video, audio, etc.)
Las direcciones IP y los puertos pertinentes para el establecimiento de la sesión.
Los atributos específicos a la sesión o a los medio dentro de ella
52
CAPÍTULO 3. SOFTWARE PBX ASTERISK
Figura 3.6: Inicio de una sesión SIP
Figura 3.7: Fin de una sesión SIP
3.3.4.
Protocolos RTP/RTCP
Son los protocolos usados para transportar flujo de audio/video en Telefonía IP. RTP es utilizado
para transportar flujos en tiempo real (Real Media Streaming) y RTCP para monitorear la calidad del
servicio, así como para transportar información acerca de los participantes en la sesión. Sus funciones
son:
3.3 Protocolos VoIP
53
Identificación del tipo de carga útil transportada (codecs de audio/video)
Verificar la entrega de los paquetes en orden (marca de tiempo) y si resulta necesario recordar
los bloques fuera de orden.
Transportar información de sincronización para la codificación y decodificación.
Monitoreo de la entrega de la información.
RTP utiliza UDP para el transporte de la información y aprovecha la suma de verificación del
mismo (Checksum) para verificar integridad de los datos. RTP no posee ningún método para garantizar la calidad de servicio ni la entrega ordenada de paquetes. RTCP también utiliza UDP para enviar
paquetes de control hacia todos los participantes de una sesión. Los servicios que provee RTCP son
los siguientes:
Dar seguimiento a la calidad en la distribución de los datos, así como mantener el control de los
codecs activos.
Transportar un identificador constante para la fuente RTP.
Anunciar el número de participantes por sesión con el fin de ajustar la tasa de transmisión de
datos.
54
CAPÍTULO 3. SOFTWARE PBX ASTERISK
4
Enrutamiento Dinámico
El router es un componente importante en una red de datos; se encarga de conectar múltiples
redes entre si, por tanto, es responsable de entregar paquetes entre estas distintas redes. Los routers
son computadoras que poseen CPU, memoria y un sistema operativo; y posee varias interfaces, cada
una perteneciente a una red IP distinta.
La principal tarea del router es determinar la mejor ruta hacia una red para enviar los paquetes;
para esto utiliza protocolos de enrutamiento estático y dinámico para construir su tabla de enrutamiento.
4.1.
Tipos de Enrutamiento
4.1.1.
Tabla de Enrutamiento
Cuando se muestra una tabla de enrutamiento se observa las redes conectadas directamente, las
rutas estáticas o rutas provenientes de protocolos de enrutamiento dinámico; la dirección y la máscara
de la red remota o conectada directamente y la interfaz de salida y/o la dirección IP del router del
siguiente salto para llegar a esta red; además se incluye información adicional, como la métrica de
enrutamiento y la distancia administrativa. A continuación puede verse una tabla de enrutamiento:
root@hrradiofonia-30c1: # route -n
Kernel IP routing table
Destination
Gateway
Genmask
10.13.30.0
0.0.0.0
255.255.255.240
200.37.75.16 0.0.0.0
255.255.255.240
10.14.30.0
0.0.0.0
255.255.255.240
10.11.0.0
10.13.30.1
255.255.240.0
10.11.16.0
10.13.30.1
255.255.240.0
10.14.0.0
10.13.30.1
255.255.240.0
10.12.16.0
10.13.30.1
255.255.240.0
10.13.16.0
10.13.30.1
255.255.240.0
10.12.0.0
10.13.30.1
255.255.240.0
10.13.0.0
10.13.30.1
255.255.240.0
10.14.16.0
10.13.30.1
255.255.240.0
0.0.0.0
200.37.75.17 0.0.0.0
root@hrradiofonia-30c1: #
55
Flags
U
U
U
UG
UG
UG
UG
UG
UG
UG
UG
UG
Metric
0
0
0
0
0
0
0
0
0
0
0
0
Ref
0
0
0
0
0
0
0
0
0
0
0
0
Use
0
0
0
0
0
0
0
0
0
0
0
0
Iface
eth1
vlan1
br0
eth1
eth1
eth1
eth1
eth1
eth1
eth1
eth1
vlan1
56
CAPÍTULO 4. ENRUTAMIENTO DINÁMICO
Cuando un router recibe un paquete, usa su tabla de enrutamiento para determinar la mejor ruta
para poder enviar el paquete; en este caso puede ocurrir una de tres situaciones.
Redes conectadas directamente: Si la dirección IP de destino del paquete pertenece a un dispositivo en una red que está directamente conectado a una de las interfaces del router; el paquete
se enviará a este dispositivo.
Redes remotas: Si la dirección IP de destino del paquete pertenece a una red remota, entonces
el paquete se enviará a otro router.
Sin determinación de ruta: si la dirección IP de destino del paquete no pertenece ya sea a una
red conectada o remota, y si además el router no posee una ruta por defecto, entonces el paquete
será descartado. El router enviará un mensaje ICMP de destino inalcanzable a la dirección IP
de origen del paquete.
Existen varias formas de agregar rutas:
1.- Por medio de redes directamente conectadas.
2.- Por medio de rutas estáticas
3.- Por medio de rutas aprendidas mediante un protocolo de enrutamiento dinámico.
Antes de configurar cualquier enrutamiento estático o dinámico en un router, éste solo conoce a las
redes conectadas directamente; éstas son las únicas redes que se muestran en la tabla de enrutamiento
hasta que se configure el enrutamiento estático o dinámico. Las rutas estáticas y dinámicas no pueden
existir en la tabla de enrutamiento sin las redes conectadas directamente.
El router desencapsula el paquete de capa 3 de la trama de capa 2, examina la dirección IP de
destino del paquete IP para encontrar la mejor ruta en la tabla de enrutamiento y encapsula el paquete
de capa 3 en una nueva trama de capa 2 y envía la trama desde la interfaz de salida; a esta función
se le conoce como conmutación. Cada router toma su decisión en forma independiente, según la
información de su propia tabla de enrutamiento. En este proceso es posible que el router haya recibido
el paquete encapsulado en un tipo de trama de enlace de datos, como una trama Ethernet, y ahora al
momento de enviar el paquete, el router lo encapsulará en otro tipo de trama de enlace de datos de
tecnología LAN como Ethernet o WAN como T1 que usa PPP, Frame Relay o ATM.
El hecho de que un router tenga cierta información en su tabla de enrutamiento no significa que
los otros routers tengan la misma información. La información de enrutamiento sobre una ruta desde
una red a otra no suministra información de enrutamiento sobre la ruta inversa o de regreso. Dado
que los routers no necesariamente tienen la misma información en sus tablas de enrutamiento, los
paquetes pueden recorrer la red en un sentido, utilizando una ruta, y regresar por otra ruta. Esto se
denomina enrutamiento asimétrico. El enrutamiento asimétrico es más común en Internet, que usa el
protocolo de enrutamiento BGP, que en la mayoría de las redes internas.
4.1.2.
Enrutamiento Estático
El enrutamiento estático es creado manualmente a diferencia de los protocolos dinámicos, que
intercambian las tablas de enrutamiento mediante actualizaciones periódicas. El enrutamiento estático
es una solución muy conveniente cuando la cantidad de nodos no es tan amplia. Las rutas estáticas
deben usarse cuando:
4.2 Enrutamiento Dinámico
57
Si una red está compuesta por unos pocos routers.
Si una red se conecta a Internet solamente a través de un único ISP (Internet Service Provider).
Si una red extensa está configurada con una topología hub-and-spoke.
4.1.3.
Enrutamiento Dinámico
El uso de protocolos de enrutamiento dinámico hace que los routers aprendan automáticamente
las rutas hacia las redes remotas y mantienen actualizada su tabla de enrutamiento; compensando de
esta manera los cambios en la topología de la red. Un protocolo de enrutamiento dinámico requiere
menos sobrecarga administrativa, pero en cambio consumirá parte de los recursos del router, como
tiempo del CPU y ancho de banda de los enlaces. A menudo se encontrará una combinación de ambos
tipos de enrutamiento.
Un protocolo de enrutamiento debe estar diseñado para:
Describir el costo de la mejor ruta haciendo uso de una métrica de encaminamiento.
Contemplar la existencia de múltiples rutas activas entre dos redes.
Propagar la información de encaminamiento con precisión evitando crear rutas incorrectas.
Minimizar el tráfico de la red debido al propio protocolo de enrutamiento.
Minimizar la carga de los routers que no desarrollan funciones de encaminamiento.
Evitar repentinos picos de tráfico en la red después del cambio de una ruta.
Escalar bien a redes más grandes.
Converger rápidamente en una topología aceptada por todos los routers después de un cambio
de rutas.
Evitar propagar fallos de encaminamiento a largas distancias.
Tener aspectos de seguridad que prevengan falsas notificaciones.
4.2.
Enrutamiento Dinámico
4.2.1.
Tipos de Protocolos de Enrutamiento Dinámico:
Existen multitud de protocolos de enrutamiento diferentes, unos basados en el algoritmo del vector
distancia (vector distance) y otros en estado del enlace (link state).
Para determinar políticas de intercambio de tráfico en una red se ha creado el concepto de Sistema
Autónomo (AS, Autonomous System). Un AS es la subred que es administrada o gestionada por una
autoridad común, que tiene un protocolo de enrutamiento homogéneo mediante el cual intercambia
información en toda la subred, y que posee una política común para el intercambio de tráfico con otras
redes o AS. Normalmente cada ISP (Internet Service Provider) o empresa constituye un AS.
58
CAPÍTULO 4. ENRUTAMIENTO DINÁMICO
En Internet se dan dos niveles jerárquicos de enrutamiento, el que se realiza dentro de un AS y
el que se efectúa entre ASs. Al primero se le denomina enrutamiento interno; y al otro enrutamiento
externo. Dado que los requerimientos en uno y otro caso son muy diferentes, se utilizan protocolos de
enrutamiento distintos. Los protocolos de enrutamiento dentro de un AS se denominan IGP (Interior
Gateway Protocol), mientras que los utilizados entre AS diferentes se llaman EGP (Exterior Gateway
Protocol).
IGP describe una necesidad y no el nombre de un protocolo definido. La mayoría de las redes corporativas operan como sistemas autónomos, aunque no estén conectados a Internet, por lo que los IGP
son utilizados con abundancia. Los protocolos IGP nunca aparecen en Internet, sino que permanecen
restringidos al ámbito de un Sistema Autónomo. Entre los IGP se tiene a: RIP, IGRP, EIGRP, OSPF,
IS-IS y BGP.
Diferencia entre Enrutamiento Estático y Dinámico:
Enrutamiento estático
Ventajas
Desventajas
Poco procesamiento
del CPU.
Fácil de comprender y
mantener en redes
pequeñas.
Fácil de configurar.
Se usa para
enrutamiento desde y
hacia redes de
conexión única.
Uso de ruta por
defecto, cuando no
hay una mejor
coincidencia en la
tabla de enrutamiento.
Configuración y
mantenimiento
prolongados
Propenso a errores en
redes extensas.
Requiere de
intervención del
administrador para
mantenimiento.
No es adecuado para
redes en crecimiento
rápido.
Requiere de
conocimiento de toda
la red para su
implementación.
Enrutamiento dinámico
Ventajas
Desventajas
Menos trabajo para
agregar o quitar redes.
Ajuste automático
ante cambios en la
topología.
Menos propenso a
errores de
configuración.
Escalable; el
crecimiento de la red
usualmente no es un
problema
Requiere recursos del
router (CPU y ancho
de banda del enlace).
Requiere de más
conocimientos para la
configuración y
solución de
problemas.
Cuadro 4.1: Enrutamiento estático Versus enrutamiento dinámico.
4.2.2.
Características de los Protocolos de Enrutamiento Dinámico
4.2.2.1.
Algoritmo de enrutamiento Vector Distancia
El algoritmo de vector distancia se basa en calcular la dirección y la distancia hasta cualquier
enlace en la red. La distancia se define en términos de una métrica como el conteo de saltos y la
dirección es simplemente el router del siguiente salto o la interfaz de salida. RIP cuenta los saltos
efectuados hasta llegar al destino mientras que IGRP además utiliza otra información como el retardo
y el ancho de banda.
4.2 Enrutamiento Dinámico
59
El encaminamiento de un protocolo basado en vector de distancias requiere que un router informe
a sus vecinos de los cambios en la topología periódicamente y en algunos casos cuando se detecta
un cambio en la topología de la red. Los cambios son detectados periódicamente ya que la tabla
de encaminamiento de cada router se envía a todos los vecinos que usan el mismo protocolo. Una
vez que el router tiene toda la información; actualiza su propia tabla reflejando los cambios y luego
informando a sus vecinos de los mismos.
Abajo se muestra a que tipo pertenece los protocolos conocidos:
Protocolos IGP: De vector distancia:
RIP y RIPv2: Routing Information Protocol
IGRP: Interior Gateway Routing Protocol
EIGRP: Enhanced IGRP
Protocolos IGP: De estado del enlace:
IS-IS: Intermediate System to Intermediate System
OSPF: Open Shortest Path First
Protocolos EGP: De vector distancia:
BGP: Border Gateway Protocol
4.2.2.2.
Algoritmo de enrutamiento de Estado Enlace
Un protocolo de estado del enlace es un protocolo que envía información sobre los enlaces entre
los routers; y están pensados para mantener las tablas de enrutamiento precisas y libres de bucles.
Enlace se refiere a la conexión entre los routers (conexión física).
Los routers usan la información del estado de los enlaces recopilados de otros routers en una base
de datos para crear el mapa de la red; seleccionar la mejor ruta y mantener una imagen de la red
completa. De esta manera, un algoritmo SPF (Shortest Path First) como el algoritmo Dijkstra calcula
la mejor ruta como el camino más corto a todos los nodos basado en la velocidad del enlace.
A diferencia de los protocolos de vector distancia, los protocolos de estado de enlace, no envían actualizaciones periódicas de la información de enrutamiento; éstos sólo envían actualizaciones
cuando se produce un cambio en la topología de forma incremental.
4.2.2.3.
Enrutamiento con clase y sin clase
Los protocolos de enrutamiento con clase no pueden usarse en redes que se subdividen usando
más de una máscara de subred. Un ejemplo de este tipo es RIP v1, que no envía información de la
máscara de subred en las actualizaciones de enrutamiento.
En los protocolos sin clase, se envía la máscara de subred, junto con la dirección de red, como
parte de las actualizaciones de enrutamiento. La mayoría de las redes modernas requieren protocolos
sin clase por que utilizan VLSM (variable length subnet mask) y redes no contiguas.
60
CAPÍTULO 4. ENRUTAMIENTO DINÁMICO
4.2.2.4.
Convergencia
La convergencia se da cuando todas las tablas de enrutamiento de una red están en un estado de
uniformidad. El tiempo de convergencia es el tiempo que tardan los routers en compartir información,
calcular las mejores rutas y actualizar su tabla de enrutamiento. Por lo general, RIP e IGRP tienen
convergencia lenta, mientras que EIGRP y OSPF tienen una convergencia más rápida.
4.2.2.5.
Balance de Carga
Cuando dos o más rutas que llevan al mismo destino, resultan con la misma métrica, el router
realizará un balance de carga del enlace, de manera que utiliza todos los enlaces que tienen el mismo
costo (métrica) para ese destino. Se sabe que el balance de carga esta en uso, por que al mostrar la tabla
de enrutamiento dos o mas rutas se asociarán con el mismo destino. Esta característica dependerá de
la aplicación que hace uso del protocolo de enrutamiento.
4.2.3.
Métrica y distancia administrativa
Una métrica es un valor cuantitativo que se usa para medir la distancia hacia una ruta determinada;
es una forma de evaluar cual ruta es la más conveniente basándose en el conteo de saltos, ancho de
banda, carga en el tráfico de la red, confiabilidad u otro valor establecido por el administrador para
indicar la preferencia de una ruta. La mejor ruta se determina por la métrica más baja.
Cada protocolo tiene una forma distinta de medir la calidad de un camino hacia una red remota, y
unos son más precisos que otros porque evalúa mayor cantidad de variables al momento de elegir.
RIP: conteo de saltos, menor es mejor.
IGRP e EIGRP: evalúa ancho de banda, retardo, confiabilidad y carga, se elige como mejor ruta
la que se evalué con el resultado más bajo.
IS-IS y OSPF: Evalúa el ancho de banda y obtiene el costo, la mejor ruta es la del costo más
bajo.
Si un router tiene dos caminos hacia la misma red, sólo se pondrá en la tabla de enrutamiento a
aquella que tenga mejor métrica; la única excepción es cuando los dos caminos tienen exactamente
la misma métrica; en ese caso se agregarán ambos caminos a la tabla de enrutamiento; este comportamiento se denomina frecuentemente ECMP (Equal Cost MultiPath). La cantidad de rutas de misma
métrica que un router permite agregar a la tabla dependerá de la configuración del equipo.
Las distancias administrativas son una forma de dar prioridad cuando existe información sobre
una red proveniente de más de un origen de enrutamiento (protocolo); para seleccionar la mejor ruta.
A cada origen se le asigna un orden de preferencia, incluidas rutas estáticas y redes directamente
conectadas. La siguiente tabla muestra las distancias administrativas.
El protocolo de origen de la ruta que tenga menor distancia administrativa va a ser el que termine
llenando la tabla de enrutamiento. Cuando en una red todos los routers ejecutan varios protocolos
de enrutamiento dinámico a la vez; por ejemplo RIP y EIGRP; todas las métricas de RIP serían
significativamente menores a las de EIGRP, por lo que equivocadamente se podría pensar que el
router va a optar por los caminos RIP dada la métrica más baja. Otro ejemplo; si se tiene que RIP y
4.3 OSPF, Open Shortest Path First
Origen de la Ruta
61
Distancia Administrativa
Directamente Conectada
0
Estática
1
Ruta EIGRP resumen
5
BGP Externa
20
EIGRP Interna
90
IGRP
100
OSPF
110
IS-IS
115
RIP
120
EGP
140
ODR
160
EIGRP Externo
170
BGP Interno
200
Desconocido
255
Cuadro 4.2: Tabla de distancias administrativas por defecto.
OSPF conocen como llegar a la red 200.0.0.0/24; dado que OSPF tiene menor distancia administrativa
(110 < 120), OSPF va a ser el que escriba la ruta en la tabla de enrutamiento.
Si se configura una ruta estática con interfaz de salida, esta aparecerá como directamente conectada en la tabla de enrutamiento, y por defecto su distancia administrativa será 1. Las redes conectadas
directamente siempre tienen un valor de distancia administrativa de 0 puesto que no existe una mejor
ruta que tener directamente conectada una red a una de sus interfaces.
4.3.
OSPF, Open Shortest Path First
La respuesta del IETF a los problemas de RIP fue OSPF (Open Shortest Path First); OSPF es un
protocolo de enrutamiento basado en el estado del enlace. OSPF provee una rápida convergencia y
soporta máscaras de subred de longitud variable. Su complejidad es notablemente superior respecto
al RIP. Fue desarrollado por el OSPF Working Group del IETF.
Entre las características más notables de OSPF podemos destacar las siguientes:
Es un algoritmo dinámico autoadaptivo, que reacciona a los cambios de manera automática y
rápida.
Soporta una diversidad de parámetros para el cálculo de la métrica.
Soporta el parámetro de tipo de servicio (Tos) de la cabecera del datagrama IP.
Realiza balance de carga si existe más de una ruta con la misma distancia hacia un destino dado;
dependerá de la aplicación y su configuración.
Puede operar con seguridad usando MD5 para autentificar a sus puntos antes de realizar nuevas
rutas y antes de aceptar avisos de enlace-estado.
62
CAPÍTULO 4. ENRUTAMIENTO DINÁMICO
Soporta rutas de red, de subred y de host.
Acepta CIDR (Classless Inter-Domain Routing).
OSPF está diseñado para trabajar tanto en redes punto a punto como de múltiples accesos, como
de difusión (Ethernet o Token Ring) o de no-difusión (X.25).
En OSPF no existe un intercambio de rutas directamente, lo que los routers transmiten mutuamente es el estado del enlace. En los protocolos de estado enlace cada router dentro de la misma área
OSPF transmite a sus vecinos paquetes LSA (Link State Advertisement) que contienen la descripción de cada una de las redes conectadas directamente a ese router. Con esta información el router
construye su tabla de enrutamiento con la mejor ruta.
Una vez que un router recibe los LSA de sus vecinos, estos son almacenados en una base de datos
local llamada Link State Database (LSDB). Los routers llegan a estar sincronizados cuando todos los
routers dentro de la misma área cuentan con exactamente la misma base de datos de estado enlace;
en este punto todos los routers conocen sobre todos los destinos posibles en esa área; pero los LSA
hasta este punto no son consideradas como rutas; para calcular las rutas hacia cada destino el router
usa un algoritmo conocido como SPF (Shortest Path First) también se conocido con el nombre de su
creador, Dijkstra, para calcular la ruta más corta a cada destino.
OSPF utiliza un algoritmo de enlace-estado, a fin de construir y calcular el camino más corto para
todos los destinos. El algoritmo de por sí es bastante complicado. A continuación una descripción
simple de las distintas etapas del algoritmo:
Tras la inicialización o debido a cualquier cambio en la información de enrutamiento, un router
se podrá generar un anuncio estado enlace.
Todos los routers intercambiarán los anuncios d estado enlace por medio de inundaciones
( ooding). Cada router que recibe una actualización del estado enlace debe guardar una copia
en su base de datos de estado enlace y propagar la actualización a otros routers.
Después de que la base de datos de cada router se ha completado; el router calculará una ruta de
acceso más corta para todos los destinos. El router utiliza el algoritmo de Dijkstra para calcular
el camino más corto. Los puntos de destino, el costo asociado y el próximo salto para llegar a
esos destinos formarán la tabla de enrutamiento IP.
En caso de que no se produzcan cambios en la red OSPF, como el cambio del costo de un enlace
o una red añadida o suprimida, OSPF debe estar estático. Las modificaciones que se produzcan
se comunicarán a través de paquetes estado enlace; y el algoritmo de Dijkstra vuelve a calcular
para encontrar el camino más corto.
4.3.1.
Áreas y clases de routers
OSPF divide al sistema autónomo (AS) en áreas, de forma que un router sólo necesita conocer la
topología e información de enrutamiento correspondiente a su área. Los algoritmos de enrutamiento
se aplican dentro de cada área. En todo AS hay al menos un área, el área 0 denominada backbone.
Un router puede pertenecer simultáneamente a dos o más áreas, en cuyo caso debe disponer de la
información de enrutamiento y ejecutar los cálculos correspondientes a todas ellas. Al menos un
router de cada área debe estar además en el backbone, para conectar dicha área con el resto del AS.
4.3 OSPF, Open Shortest Path First
63
Dos áreas sólo pueden hablar entre sí a través del backbone. Las rutas entre diferentes áreas
circulan siempre por el backbone, por lo tanto todas las áreas deben conectar con el backbone. Si no
es posible hacer una conexión directa con el backbone, se puede hacer un enlace virtual entre redes.
Las áreas ponen un límite en el anuncio de las actualizaciones del estado enlace. Las inundaciones
y el cálculo del algoritmo de Dijkstra, en un router se limitan a cambios dentro de la zona. Todos los
routers dentro de un espacio tienen exactamente la misma base de datos del estado enlace.
En OSPF se contemplan cuatro clases de routers:
Routers backbone: Los que se encuentran en el área backbone.
Routers internos: Los que pertenecen únicamente a un área.
Routers periféricos de área: Son los que están en mas de un área, y por tanto las interconectan
(una de las áreas siempre es necesariamente el backbone).
Routers periféricos de AS: Los que intercambian tráfico con routers de otros ASes. Estos routers
pueden estar en el backbone o en cualquier otra área.
Standard Area: Este tipo de área se conecta a la de backbone. Todos los routers del área conocen
los demás routers del área y tiene la misma base de datos topológica. Sin embargo cada router tiene
su propia tabla de enrutamiento.
Backbone Area: El backbone, también denominado área cero, forma el núcleo de una red OSPF.
Es la única área que debe estar presente en cualquier red OSPF, y mantiene conexión, física o lógica,
con todas las demás áreas en que esté dividida la red. La conexión entre un área y el backbone se
realiza mediante los ABR (Area Border Router). OSPF espera que todas las áreas inyecten la información de encaminamiento en el backbone y este inyectará aquella información en otras áreas.
Stub Area: Un área Stub es aquella que no recibe rutas externas (LSA tipo 5). Por lo tanto, los
rouerts necesitan normalmente apoyarse en las rutas predeterminadas para poder enviar tráfico a rutas
fuera del segmento Stub.
Área Totally Stub: Es idéntica al Stub Area (no acepta LSA tipo 5); pero además no acepta rutas
hacia redes de otras áreas y no conoce las rutas hacia routers ASBR (LSA tipos 3 y 4). La única forma
de salir del área es mediante una ruta por defecto. Este tipo de área es muy útil para sitios remotos
con pocas redes y conectividad limitada con el resto de la empresa. Esta es una solución propietaria
de Cisco Systems.
Not-so-Stubby Area: También conocidas como NSSA, constituyen un tipo de área Stub. No aceptan LSA de tipo 4 y 5 pero puede importar rutas externas hacia el domino OSPF como rutas externas
NSSA (LSA tipo 7). En estas áreas se crean los LSA de tipo 7 que son transformados a LSA de tipo
5 por el ABR del NSSA, de esta forma se puede propagar al resto del dominio OSPF.
Los routers que pertenecen a múltiples áreas, y conectan estas áreas con el área backbone son llamados routers de borde de area (ABR, Area Border Router). Los ABR deben mantener la información
que describe el backbone y las de las otras áreas adjuntas. Un router que tiene todos sus interfaces
64
CAPÍTULO 4. ENRUTAMIENTO DINÁMICO
1y2
3
4
5
7
Backbone
Area Type
Si
Si
Si
Si
No
Non-Backbone, Non-Stub
Si
Si
Si
Si
No
Stub
Si
Si
No
No
No
Totally Stubby
Si
No
No
No
No
Not-so-Stubby
Si
Si
Si
No
Si
Cuadro 4.3: Áreas OSPF.
dentro de una misma área es llamado un router interno (IR, Internal Router). Routers que actúan como gateway entre OSPF y otros protocolo de enrutamiento (IGRP,EIGRP, IS-IS, RIP, BGP, Static) u
otros casos de enrutamiento OSPF son llamados routers de frontera de un sistema autónomo (ASBR,
Autonomous System Boundary Router). Un router puede ser un ABR o un ASBR; un router puede ser
un router interno o un router de borde del área y al mismo tiempo ser un ASBR.
4.3.2.
Costo en OSPF
El costo (también llamado métrica) de una interfaz en OSPF es una un indicativo del gasto necesarios para enviar los paquetes a través de esta interfaz. El costo de una interfaz es inversamente
proporcional al ancho de banda de la interfaz. Un gran ancho de banda indica un bajo costo. Hay más
gasto y retardo en un enlace de 56Kbps serial que en un 10Mbps Ethernet. La fórmula usada para
calcular el costo es:
costo= 10000 0000/bandwith in bps
Por defecto el costo de una interfaz es calculado y basado en el ancho de banda; pero se puede
forzar el costo de una interfaz por medio de comandos.
4.3.2.1.
Árbol de la ruta más corta
La ruta más corta es calculada por el algoritmo Dijkstra. El algoritmo coloca cada router en la raíz
de un árbol y calcula la ruta más corta para cada destino basado sobre el costo acumulativo requerido
para llegar a ese destino. Cada router tiene su propia visión de la topología, aunque todos los routers
construirán un árbol de camino más corto usando la misma base de datos de enlace estado. Abajo se
muestra la construcción de la ruta más corta de cada destino del router RTA.
4.3.2.2.
Tipo de Interfaces de redes
Los routers de una red basada en OSPF se conectan a ella a través de una o varias interfaces con
las que se conectan a otros routers de la red. El tipo de enlace define la configuración que asume la
interfaz correspondiente. OSPF soporta redes broadcast, redes No broadcast y redes punto a punto. El
tipo de red en la que esté trabajando OSPF determinará el funcionamiento del protocolo, y este a su
vez puede ser optimizado por el administrador de la red.
4.4 Funcionamiento de OSPF
65
Figura 4.1: Árbol de la ruta más corta
4.3.2.3.
Rutas externas de tipo1 y tipo2
Las rutas externas se enmarcan en dos categorías; externa de tipo 1 y externa de tipo 2. La diferencia entre ambos está en la forma en que el costo de la ruta se calcula. El costo de una ruta de tipo 2 es
siempre el costo externo, independientemente de su costo en el interior para llegar a esa ruta. El costo
de tipo 1, es la adición de los costos externos y el costo interno utilizado para llegar hasta esa ruta.
Una ruta de tipo 1 es siempre preferible a una ruta de tipo 2 para el mismo destino. Esto se ilustra en
el diagrama siguiente:
Figura 4.2: Rutas externas de tipo1 y tipo2
4.4.
Funcionamiento de OSPF
Cuando un router arranca, primero inicializa las estructuras de datos necesarias y espera las indicaciones de los protocolos de bajo nivel para indicar que sus interfaces estén operativas. El router
utiliza el protocolo Hello para descubrir sus vecinos; el router envía paquetes Hello y espera a que le
sean devueltos. En redes punto a punto y broadcast se detectan los vecinos dinámicamente enviando
paquetes de saludo multicast. En las redes en la que no es posible usar broadcast será necesaria cierta
información de configuración para descubrir vecinos.
66
CAPÍTULO 4. ENRUTAMIENTO DINÁMICO
En este punto por medio del protocolo Hello también se elegirá DR (Designated Router) y BRD
(Backup Designated Router) para la red, si es necesario (en redes broadcast). El router intentará
formar adyacencias (adjacencies) con algunos de sus nuevos vecinos recién descubiertos en base a
estos routers. Una adyacencia es una relación formada entre dos routers vecinos determinados con el
fin de intercambiar información de enrutamiento. No todos los pares de vecinos son adyacencias. Las
bases de datos de estado enlace se sincronizan entre pares de routers adyacentes. Cuando hay un router
DR es este el que decide que routers son adyacentes. Las adyacencias controlan la distribución de la
información de enrutamiento ya que las actualizaciones sólo se envían entre los routers adyacentes.
Las adyacencias de los routers se reflejan en los contenidos de sus LSA; esto permite al protocolo
detectar routers caídos de forma oportuna.
Los LSA inundan el área; asegurándose que todos los routers en un área tienen la misma base
de datos de estado enlace. Esta base de datos consiste en una colección de LSA originados por cada
router perteneciente al área. De esta base de datos cada router calcula el árbol de la primera ruta más
corta (SPF, Shortest Path First) consigo mismo como raíz. Cada vez que se recibe un LSA se calcula
el árbol SPF mediante el algoritmo de Dijkstra y se genera una tabla de enrutamiento.
4.4.1.
Encapsulamiento de paquetes en OSPF
Los paquetes OSPF se encapsulan en IP con tipo de protocolo de transporte número 89. En la
cabecera OSPF existe un campo que indica el tipo de paquete. Todos los paquetes OSPF comparten
una común cabecera. Cada paquete OSPF empieza con una cabecera de 24 bytes. Esta cabecera contiene toda la información necesaria para determinar si los paquetes deben ser aceptados para futuros
procesos. Abajo se muestra el encapsulamiento del OSPF y su cabecera.
Figura 4.3: Encapsulamiento de paquetes OSPF
4.4 Funcionamiento de OSPF
67
Figura 4.4: Longitud del campo en bytes
Version number: identifica la versión del OSPF usada.
Type: Identifica el tipo del paquete del OSPF. Los routers OSPF cuentan con 5 tipos de paquetes
para identificar a sus vecinos y para actualizar la información de enrutamiento.
Tipo
Nombre
1
Hello
2
Database Descriptor (DBD)
3
Link State Request (LSR)
4
5
Link State Update (LSU)
Link State Ack (LSAck)
-
Link-State Advertisement
(LSA)
Función
Descubrir y mantener los vecinos
Resumen del contenido de la base de datos. Describe el
contenido de la base de datos topológica. Se intercambian
estos mensajes cuando se inicializa una adyacencia.
Petición de una descripción la base de datos. Este tipo de
mensajes se intercambian cuando un router descubre
que cierta información de su base de datos está obsoleta.
Actualización de la base de datos; es la respuesta al LSR.
Reconocimiento de los LSU.
Describen el estado local de un router o red, para un
router incluye el estado de las interfaces y sus adyacencias. Van empaquetados en DBD, LSU, LSR o LSAck.
Cuadro 4.4: Tipos de paquetes OSPF
Packet length: Especifica la longitud del paquete, incluyendo el encabezado OSPF, en bytes.
Router ID: Identifica el origen del paquete.
Area ID: Identifica el área a la que pertenece el paquete. Todos los paquetes OSPF están asociados a
una sola área.
Checksum: Verifica el contenido total del paquete por si ha sufrido algún daño durante su tránsito.
Authentication type: Contiene el tipo de autentificación. El tipo de autentificación se configura en cada
área.
Authentication: Contiene la información de autentificación.
Data: Contiene información encapsulada de las capas superiores.
68
4.4.2.
CAPÍTULO 4. ENRUTAMIENTO DINÁMICO
Tipos de LSA (Link State Advertisement)
Los LSAs describen el estado de una red o de un router. Esta descripción cubre el estado de todos
los interfaces de los routers y sus adyacencias.
Tipo
Nombre
1
Router-LSA
2
Network-LSA
3,4
Summary-LSA
5
AS-External-LSA
6
Group
Membership LSA
7
Routers in a Notso-stubby-area
(NSSA)
Descripción
Se originan en todos los routers. Describe un conjunto de estados y el
costo de interfaces de routers para un área; cada router puede generar un Router LSA para todos sus interfaces. Sólo se propagan en un área.
Se originan en los routers DR sobre un segmento. Esta información
es una indicación de todos los routers conectados sobre un particular
segmento multiacceso como un Ethernet, Token Ring y FDDI (broadcast)
multiaccess); además contiene una lista de los routers conectados a
ún area determinada. Se envían sólo dentro de un área.
Describen las redes en el AS pero externas a un área. Se originan en los
Routers de borde área(ABR); cada uno describe una ruta hacia un
destino fuera del área, aunque todavía dentro del AS. Normalmente los
Summary LSA son difundidos dentro del backbone y del backbone podrá
pasar a otras áreas por medio de los ABR. El tipo 3 describe rutas hacia
redes a través del AS y el tipo 4 describe rutas hacia routers ASBR.
Originados por un ASBR. Cada uno describe una ruta con destino a otro
sistema autónomo. Estas redes son difundidas vía redistribución. Los ASBR
tiene la tarea de difundir estas rutas dentro de un AS. Estos LSAs van por
las áreas estándar y backbone.
Este es una extensión Multicast OSPF (MOSPF); un protocolo de
enrutamiento multicast que no es de uso general.
Routers NNSA no reciben External LSA de una ABR; pero permiten
enviar información de enrutamiento externo por redistribución. Estos
routers usan LSA de tipo 7 para informarles a los ABR acerca de
estas rutas externas las cuales transformarán a tipo 5 (LSA External)
para ser inundados en el resto de la red OSPF.
Cuadro 4.5: Tipos de LSA
Rutas que son generadas dentro de un área son llamados rutas Intra-Area; rutas que se originan de
otras áreas son llamados rutas Inter-Area; rutas que se originan de otros protocolos de enrutamiento
y que son inyectados dentro del AS vía redistribución son llamados rutas External. Múltiples rutas al
mismo destino son preferidas en el orden siguiente: Intra-Area, Inter-Area, External type 1, External
type 2.
4.4 Funcionamiento de OSPF
69
Figura 4.5: Rutas originadas en una determinada área
4.4.3.
Estados OSPF
Para una comprensión mas profunda de OSPF es necesario comprender las relaciones o estados
que tienen entre sí los routers que utilizan OSPF.
Estado desactivado (Down): En el estado desactivado, el proceso OSPF del router no ha intercambiado información con ningún vecino. OSPF se encuentra a la espera de pasar al siguiente
estado (etapa de inicialización).
Estado de inicialización (Init): Los routers envían paquetes de tipo 1 (Hello) en intervalos
regulares (por defecto 10 segundos en Quagga y en Cisco) para establecer relación con sus
routers vecinos, cuando una interfaz recibe su primer paquete Hello entonces decimos que el
router ha entrado en estado Init y está preparado para entrar en el siguiente estado.
Estado bidireccional (Two-Way): Utilizando paquetes Hello, cada router OSPF intenta establecer una comunicación bidireccional con cada router vecino que está ubicado en la misma
red IP. Un router entra en estado two-way en el momento que se ve en una de las actualizaciones
de uno de sus vecinos. El estado two-way es la relación más básica que pueden tener los routers
OSPF, pero la información de enrutamiento no se intercambia en este estado. Para aprender
sobre enlaces de otros routers el router tiene que tener al menos una adyacencia completa.
Estado de ExStart: Técnicamente, cuando un router y su vecino entran en estado ExStart, su
conversación se caracteriza por una adyacencia, pero los routers todavía no tienen una adyacencia completa. El estado ExStart se establece utilizando paquetes de tipo 2. Entre los dos routers
se utilizan paquetes Hello para determinar cual de los dos es el maestro y cual es el esclavo en
su relación y se intercambian paquetes de tipo 2.
Estado de Intercambio (Exchange): En el estado exchange se utilizan paquetes de tipo 2 para
enviar información de estado del enlace. En otras palabras, un router describen sus bases de
datos de estado del enlace a otro router. Si alguna de las rutas no está en la base de datos del
enlace del router receptor de la información, este solicita una actualización completa, la cual se
realiza en el estado Loading.
70
CAPÍTULO 4. ENRUTAMIENTO DINÁMICO
Estado cargando (Loading): Después de que todas las bases de datos han sido descritas a cada
router, se tiene que solicitar una información que es más completa utilizando paquetes de tipo
3. Cuando un router recibe un paquete de tipo 3, este responde con una actualización mediante
un paquete de tipo 4. Los paquetes de tipo 4 describen la información de estado del enlace que
es el corazón de los protocolos de enrutamiento de estado del enlace. Los paquetes de tipo 4
son respondidos con paquetes de tipo 5.
Estado de adyacencia completa (Full adjacency): Cuando termina el estado Loading, los
routers están en una adyacencia completa. Cada router mantiene una lista de sus vecinos adyacentes, llamada base de datos de adyacencia.
5
Voyage GTR
El Grupo de Telecomunicaciones Rurales de la PUCP ha adaptado Voyage 0.5.2 para la implementación de enlaces inalámbricos WiFi de larga distancia; a esta Voyage, más sus aplicaciones adaptadas se le llama Voyage GTR que puede descargarse desde http://gtr.telecom.pucp.edu.
pe/webfm_send/987
5.1.
Identificación de las aplicaciones a implementar
Voyage (http://www.voyage.hk/) es un sistema operativo basado en Linux, derivado de la
distribución Debian; Voyage es un sistema genérico que no contiene todas las aplicaciones para implementar redes de datos; contiene sólo lo básico; como los controladores para el manejo de las
interfaces Ethernet y para el manejo de las interfaces inalámbricas en base a chipset Atheros.
Voyage se instala en plataformas x86; y está optimizado para equipos embebidos (también llamados (Single Board Computer), SBC) como las WRAP, ALIX de PC Engines (http://www.
pcengines.ch) y las Soekris 45xx/48xx de Soekris Engineering (http://www.soekris.com)
que son placas dedicadas para implementar enlaces inalámbricos de larga distancia.
Un router de larga distancia debe contener ciertas aplicaciones para poder implementar redes WiFi
de larga distancia; a Voyage original le faltan aplicaciones para cumplir con esta tarea; haciendo una
relación entre las características comunes de los equipos comerciales, a Voyage le faltaría implementar:
1.
2.
3.
4.
5.
6.
Configuración rápida y cómoda de las interfaces de red,
Enrutamiento estático, NAT y DHCP
Implementar seguridad WPA-PSK
Enrutamiento dinámico
Telefonía IP
Configuración vía web
Estas características se ha implementado en Voyage GTR, pero además se ha tenido cuidado
en que todas estas aplicaciones trabajen conjuntamente y que Voyage GTR tenga las herramientas
necesarias para su trabajo en entornos rurales. Estas herramientas son:
71
72
CAPÍTULO 5. VOYAGE GTR
1.
2.
3.
4.
5.2.
Administración de la memoria y del espacio de disco
Conservación y borrado de registros de sistema (logs)
Creación de archivos de respaldo
Apagado, reinicio y conservación de fecha
Configuración rápida mediante archivos de las interfaces de
red (Ethernet y WiFi)
Todas las configuraciones de las interfaces de red se realizan por medio de comandos; para no
perder esta configuración se debe crear un script que contenga estos comandos y poder ser ejecutados
en el arranque del sistema. Existen archivos para realizar una configuración rápida y ordenada como
/etc/network/interfaces; pero por defecto no contiene herramientas para configurar interfaces
WiFi en base a los controladores madwifi.
Existe una aplicación llamada mad wifi-ifupdown que incorpora en /etc/network/interfaces
variables para poder configurar enlaces WiFi; pero esta aplicación advierte que no está garantizado
su funcionamiento; aunque su uso hace cómodo la configuración. Por tanto se corrigió y se adicionó
variables en esta aplicación para ser usado en Voyage GTR.
Al instalar mad wifi-ifupdown se tuvo que crear carpetas adicionales para ser adaptado a la
estructura de Voyage.
Se creó una plantilla en /etc/network/interfaces; para configurar las interfaces de red; esta
plantilla es sólo útil para dispositivos WiFi que hacen uso del madwifi, se puede usar sólo WEP y
WPA2-PSK, y está dedicado sólo para el modo infraestructura; además se puede configurar bridging
(una misma dirección para varias interfaces) entre interfaces Ethernet.
Para lograr esta plantilla:
1. en /etc/network/if-pre-up.d/madwifi se adicionó la configuración de:
1. La velocidad de transmisión.
2. La distancia.
3. La diversidad.
4. Se corrigió la activación de la interfaz al elegir WEP.
2. en /etc/network/if-up.d/madwifi se adicionó la creación del archivo PID de seguridad
WPA-PSK en la sección del archivo mencionado, correspondiente a hostapd; y se anuló la
opción de VAP en las interfaces de red.
3. en /etc/network/if-down.d/madwifi se corrigió la deshabilitación incorrecta de WPAPSK en la sección del archivo correspondiente a hostapd.
4. se modificó /etc/init.d/networking para hacer más efectiva la deshabilitación del WPAPSK en las secciones correspondiente a hostapd y a wpa_ supplicant.
5.3 Configuración rápida de enrutamiento estático
5.3.
73
Configuración rápida de enrutamiento estático
Para configurar las rutas estáticas se utiliza comandos pero para que la configuración quede o se
active después de un reinicio se necesita de un script que se ejecute en el arranque del sistema. Esto no
es práctico por lo cual se ha creado un archivo de configuración apoyado de un script para configurar
las rutas estáticas.
El archivo de configuración /etc/network/nat-static-routes será el archivo para la configuración de las rutas estáticas, además permitirá la configuración de la ruta por defecto y del NAT,
todo esto a través de variables. En este archivo se ha creado un plantilla para esta configuración.
Se ha creado el script /etc/init.d/mgnat-static-routes que permita coger la configuración de /etc/network/nat-static-routes y ejecutarlo.
Además se ha modificado /etc/init.d/networking para que la configuración hecha en
/etc/network/nat-static-routes sea cargada cada vez que se ejecute
/etc/init.d/networking restart a través de /etc/network/nat-static-routes. Además
se implementó un servidor DHCP, para esto se utilizó la aplicación dnmasq que ya viene con Voyage;
pero se creó una plantilla en /etc/dnsmasq.conf que servirá como ejemplo de una configuración
básica.
5.4.
Seguridad WiFi
Actualmente la seguridad WEP no es muy confiable en redes WiFi; por lo cual se debe usar WPA
que requiere una conectividad sin intermitencias; pero como se va a trabajar en enlaces largos que
podrían tener repentinas desconexiones, WPA sería inadecuado. Por tanto en estas redes se usará una
variante de WPA que es WPA-PSK, que no necesita servidores de autenticación y que soporta mejor
las desconexiones y que además es más seguro que el WEP.
Voyage incluye el servicio de seguridad WiFi a través de las aplicaciones hostapd y wpa_
supplicant pero son versiones antiguas; por ello se hizo uso de las versiones actuales y se desarrolló plantillas para que la configuración sea ordenada y rápida. Al instalarlas se tuvo que crear
carpetas adicionales para ser adaptado a la estructura de Voyage.
Se creó archivos de configuración para hasta tres interfaces WiFi, tanto para hostapd como para
wpa_ supplicant.
Los archivos creados son:
/etc/hostapd/hostapd-ath0.conf
/etc/wpa_ supplicant/wpasupplicant-ath0.conf
La elección del uso de este tipo de seguridad se ha hecho en /etc/network/interfaces; para
ser activados por /etc/init.d/networking.
El hostapd instalado hacía que el MTU de las interfaces WiFi sea de 2400, cambiando el valor
de 1500 que se usa por defecto; esto traía problemas al implementar OSPF en estas interfaces; porque
no aceptaban un valor alto en el MTU; para esto se compiló de nuevo el hostapd modificando el
cambio forzado del MTU en hostapd.h.
5.5.
Enrutamiento dinámico
Voyage no trae ninguna aplicación para este caso; quagga es el software que posee las aplicaciones para configurar enrutamiento dinámico con protocolos como RIP y OSPF. En este caso se
74
CAPÍTULO 5. VOYAGE GTR
implementó OSPF; para lo cual se creó plantillas para que la configuración sea ordenada y rápida.
Al instalar quagga se tuvo que crear carpetas adicionales para ser adaptado a la estructura de
Voyage.
Se realizó muchas pruebas en laboratorio y campo para llegar a establecer una plantilla del OSPF
para ser usado como ejemplo de una configuración básica; los archivos involucrados en esta plantilla
son:
voyage: # cat /etc/quagga/ospfd.conf
voyage: # cat /etc/quagga/zebra.conf
5.6.
Telefonía IP
Aunque un servidor de Telefonía IP normalmente necesita un equipo de mayor potencia que una
placa ALIX; Asterisk, un servidor de Telefonía IP de código abierto, puede ser instalado en estas
placas para que realice tareas mínimas como comunicación entre usuarios telefónicos y comunicación
entre usuarios administrados por otros Asterisk. La placa ALIX al tener un CPU y RAM reducidos
estará limitado a administrar hasta unas 5 llamadas simultaneas con clientes SIP administrados por
otros servidores Asterisk.
En un punto de la red que pertenezca a una zona rural no es necesario implementar servidores de
gran capacidad por que los usuarios son pocos (menos de 10 clientes SIP).
Voyage no trae Asterisk, se instaló la versión 1.4, la más actual en estos momentos. Para instalarla
se necesitó de sus dependencias y más que nada de los módulos zaptel. Al instalar Asterisk se tuvo
que crear carpetas adicionales para ser adaptado a la estructura de Voyage.
Por defecto, al instalar Asterisk no se crea su archivo logrotate, dado que es necesario se creó
/etc/logrotate.d/asterisk para controlar los log del Asterisk. Además se ha creado el script
/etc/init.d/asterisk que permita la carga programada del Asterisk cada vez que el sistema
inicie.
Se ha establecido una plantilla para ser usada como ejemplo de una configuración básica. La
placa ALIX está limitado en recursos por lo que el Asterisk no puede usar todos sus módulos, se
ha limitado y se ha adaptado a Voyage (/etc/asterisk/modules). Además se ha instalado los
archivos de sonido en español y se ha creado algunos archivos de sonido adicionales para el uso de la
plantilla.
La plantilla desarrollada es para realizar la comunicación entre clientes SIP de un mismo Asterisk
y con clientes SIP administrados por otros Asterisk y además de permitir la comunicación con la red
de telefonía pública; la plantilla contempla a los archivos:
/etc/asterisk/extensions.conf
/etc/asterisk/sip.conf
/etc/asterisk/iax.conf
Se tuvo problemas cuando el equipo que contenía al Asterisk no tenía una ruta por defecto; en
este caso el Asterisk no trabaja correctamente; para esto se encontró una solución que es la de poner
el nombre del equipo en /etc/hosts.
5.7 Configuración vía web
5.7.
75
Configuración vía web
Para el uso común de los usuarios tener una interfaz web facilita la configuración de las interfaces
de red; por tanto se decidió incluir una en Voyage GTR.
Se estudió los proyectos pertinentes de interfaces Web que existen hasta la fecha, tales como:
1. WiFiAdmin, http://wifiadmin.sourceforge.net
2. TierConf (http://tier.cs.berkeley.edu/wiki/SBC:TierConf), del grupo TIER. Está basado en m0n0wall (http://m0n0.ch/wall/), que a su vez usa PHP.
3. Pyramid Linux de la empresa Metrix http://metrix.net/page.html?chapter=0&id=3
Antiguamente el tamaño de las CF suponía una limitación relativa para elegir un interfaz Web
(por ejemplo se buscaban servidores http ligeros, que ocuparan poco espacio). Hoy, con las CF de
gran capacidad a muy bajo precio, esa limitación prácticamente ha desaparecido, pero sí sigue siendo
importante que la aplicación requiera poco recurso de procesamiento.
Se decidió realizar una interfaz propia, debido a que las opciones evaluadas no poseían opción
para configuración de enrutamiento dinámico o la opción no era apropiada. A la interfaz web de
Voyage GTR se le ha llamado Uya.
Uya se ha liberado con licencia GPLv3 y puede descargarse desde http://code.google.com/
p/uya/
La interfaz web Uya ha sido construida mediante el lenguaje de programación Python, básicamente se usó
2 paquetes python: configmod y configmod-web.
Configmod. Posibilita las siguientes tareas:
*Leer archivos: Configmod lee archivos de configuración y crea uno solo.
*Escribir archivos: Configmod actualiza archivos usando un solo archivo de configuración.
Config-web. Es una máscara web para configmod que usa la aplicación cherrypy como servidor web.
También se puede usar Uya desde linea de comandos. Para crear o actualizar el archivo de configuración principal de Uya se ejecuta el siguiente comando:
uya - - read-config
Ahora se puede modificar el archivo /etc/uya/uya.conf con un editor se texto y luego de la edición se
ejecuta la escritura mediante la ejecución del siguiente comando:
uya - - write-config
Scripts de escritura/lectura
La máscara web de Uya (frontend) usa las opciones de lectura/escritura de Uya, pero el modo en que
estas opciones son invocadas es configurable (revisar /etc/uya/scripts). Si se usa una distribución que
normalmente está en modo lectura (read-only) se necesitará ejecutar unos scripts que permitan realizar los cambios pertinentes hacia el modo escritura. Para Voyage se ha desarrollado el script que se muestra a continuación:
76
CAPÍTULO 5. VOYAGE GTR
#!/bin/sh
# /etc/uya/scripts/write.sh
#
# Example write script for Voyage Linux
#
if test $# -ne 2; then
echo “Usage: $(basename $0) CONFIGFILE TEMPLATEFILE”
exit 1
fi
STATE=$(mount ∣ grep “ROOT_FS on / type” ∣ cut -d”(” -f2 ∣ head -c2)
test “$STATE ” = ”ro” && remountrw
uya -write-config -f “$1 ” -t “$2 ”
RETVAL=$?
test “$STATE ” = “ro” && remountro
exit $RETVAL
Archivos modificados
Uya modifica los siguientes archivos de configuración:
*General:
-Hostname: /etc/hostname y /etc/hosts
-Dns: /etc/resolv.conf
-Ntpdate: /etc/default/ntpdate (variable NTPSERVERS)
*Interfaces: /etc/network/interfaces
Ethernet(ethX interfaces)
Wireless (athX madwifi interfaces). WPA2-PSK crea archivos de autenticación
/etc/wpa_supplicant/wpasupplicant-INTERFACE.conf y
/etc/hostapd/hostapd-INTERFACE.conf files.
Routing(brX interfaces)
*Enrutamiento
Estático: /etc/quagga/daemons (deshabilitados zebra y ospfd).
Dynamic routing: /etc/quagga/daemons (habilitados zebra y ospfd).
Gateway y NAT: /etc/network/statics-routes-nat
Static routes: /etc/network/statics-routes-nat (ROUTESX entries)
Por defecto: /etc/quagga/zebra.conf y /etc/quagga/ospfd.conf
5.8.
Adaptación de Voyage para el trabajo en entornos rurales
Voyage GTR se usará en zonas rurales; por tanto su administración estará limitada; quizás se deje de vigilar
por mucho tiempo (cada 6 meses debe existir revisiones) según las condiciones de acceso. Por ello se debe
asegurar que las funciones de los servicios implementados trabajen correctamente por buen tiempo con el
mínimo de mantenimiento.
Voyage es un sistema que ocupa unos 100MB en la Compact Flash (CF); por lo que la CF debe ser al menos
de 256MB. Pero Voyage GTR con todas las aplicaciones instaladas, puede llegar a ocupar unos 400MB por
5.8 Adaptación de Voyage para el trabajo en entornos rurales
77
tanto la CF debe ser de al menos 1GB; este tamaño aún sigue siendo muy bajo comparado con las computadoras
estándares.
Voyage es un sistema que se carga en modo lectura; pero un sistema operativo por más que se cargue en
modo lectura necesita crear archivos temporales y reescribir o crear archivos. La partición donde está instalada
Voyage pertenece a la CF y se carga en modo lectura; pero existe una carpeta, la /rw, que está contenida en la
RAM del sistema en un espacio delimitado (originalmente a 8MB); por tanto está en modo escritura; en este
espacio se podrá manipular archivos o carpetas que se encuentren aquí; pero al estar en RAM se perderá la
información después de un reinicio. En /rw están ubicados especialmente los log del sistema y archivos que
necesitan ser modificados por las aplicaciones en cualquier tiempo.
Los log aumentan de tamaño mientras funcione el sistema; en Voyage GTR pueden crecer a razón de
0.5MB por día; este tamaño no es crítico; pero puede existir momentos en que los log crezcan rápidamente y
los 8MB dedicados para /rw puede resultar poco; por tanto se aumenta hasta 32MB. Este aumento de espacio
no quiere decir que se está quitando 32MB a los 128MB de la RAM; sino que mientras se necesite espacio se
puede usar hasta un límite de 32MB. La modificación se hace en /etc/fstab.
La aplicación logrotate que ya viene con Voyage será la encargada de borrar los log antiguos. Para
evitar que los log crezcan muy rápido antes de que actúe logrotate, se desarrolló el script /etc/
cron.hourly/cleanrw como tarea cron, para que cada hora evalúe el espacio en /rw, si es menor a
5MB deberá eliminar el exceso de log.
Toda lo modificado en /rw se pierde después de un reinicio; pero se modificó el script /etc/init.d/
voyage-util que permite guardar todo lo que se modifique en /rw para recuperarlo despues de un reinicio.
Para indicar que carpeta o archivo de /rw se desea conservar se indicará en /etc/voyage.conf.
Los equipos con Linux pueden permanecer encendidos por mucho tiempo y trabajan correctamente; pero
es recomendable realizar reinicios periódicamente. Para esto se crea la tarea cron para programar reinicios
/etc/cron.d/reboot-board.
La placa ALIX no posee batería para conservar la fecha del sistema mientras esté sin energía (apagado); si
se desea tener la fecha sincronizada se deberá usar ntpdate. Se implementó scripts para conservar el tiempo
mientras se reinicia el sistema.
Si el sistema reinicia, la fecha del sistema se conserva pero si se apaga el equipo (se quita la energía) la
fecha actual se pierde y al encender de nuevo, la fecha es antigua, alrededor de 1980. Existe aplicaciones que
van creando archivos o carpetas mientras el sistema arranca pero como las fuentes fueron instaladas posteriores
a 1980, en la creación de estos archivos o carpetas puede existir advertencias o quizás errores. Para evitar esto
se desarrolló los script /etc/init.d/a-before y /etc/init.d/z-after para conservar la fecha
después de un reinicio (sin quitar la energía de la placa) y si el equipo se apaga (se quita la energía del sistema)
se configura la fecha del sistema a una fecha aproximada al momento del grabado de Voyage GTR en la CF.
Se activó el watchdog para que reinicie al equipo si se está consumiendo demasiados recursos en un
momento. Si el promedio de uso del CPU en un minuto es más de 24 %, o en 5 minutos es más de 18 %, o en
15 minutos es más de 12 % el sistema reiniciará; además si el sistema sólo cuenta con 1MB de RAM libre el
sistema reiniciará.
Para tener un buen mantenimiento del sistema es necesario tener un respaldo, para esto se ha creado scripts
que permitan generar un respaldo de la configuración de las distintas aplicaciones; pero sin crear copia de todo
el sistema. El archivo /etc/backup.list es donde se indica las carpetas y archivos a respaldar; el script
/usr/local/sbin/mgbackup se encargará de generar el respaldo en un archivo comprimido.
Como ya se ha mencionado, se ha generado una distribución con varias aplicaciones a la que se llama
Voyage GTR y para poder instalarla se puede usar los script de Voyage original; pero en este caso se desarrolló
un script que permite una instalación más específica y además que permite coger el respaldo obtenido y copiar
a una Voyage GTR y así obtener una copia particular de la configuración de equipos.
Además en Voyage se instaló utilitarios para ser usados por medio de comandos, como: vim, telnet,
mutt, jnettop, lsof, cu, lynk, nmap y killall.
78
CAPÍTULO 5. VOYAGE GTR
6
Con guración e Instalación de Voyage GTR
6.1.
Comandos generales en Linux
Para un correcto entendimiento de la configuración e instalación de Voyage GTR, es necesario un repaso
de algunos comandos linux.
6.1.1.
Comando ls
Muestra la lista de carpetas y archivos que contiene una carpeta.
gtr-v106:/var# ls
backups cache lib local lock log mail opt run spool tmp
gtr-v106:/var#
Gtr-v106: # ls-la
drwxr-xr-x 4 root
drwxr-xr-x 8 root
-rw------- 1 root
-rw-r-r--- 1 root
-rw-r-r--- 1 root
drwx------ 2 root
drwxr-xr-x 2 root
-rw-r-r--- 1 root
gtr-v106:#
6.1.2.
root
root
root
root
root
root
root
root
160
180
21
432
110
60
40
0
Apr 8 10:22 .
Dec 31 1999 ..
Apr 7 07:28 .bash_ history
Jul 15 2008 .bashrc
Nov 10 2004 .profile
Apr 6 07:40 .ssh
Apr 8 10:21 backup
Apr 8 10:22 configuracion.sh
Comando mkdir
Sirve para crear directorios.
Gtr-v106: # mkdir backup
6.1.3.
Comando rm
Sirve para borrar archivos o carpetas.
Gtr-v106: # rm -r carpeta
gtr-v106: # rm archivo.txt
79
80
CAPÍTULO 6. CONFIGURACIÓN E INSTALACIÓN DE VOYAGE GTR
6.1.4.
Comando fdisk
Muestra y manipula la tabla de particiones. Con al opción -l se muestra la lista de todas las particiones
encontradas en el equipo.
root@gtrdesktop: # fdisk -l
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x31b931b9
Device
Boot Start
/dev/sda1
1
*
/dev/sda2
3648
/dev/sda5
3648
/dev/sda6
7295
/dev/sda7
10942
/dev/sda8
14589
/dev/sda9
14711
/dev/sda10
17143
End
3647
19457
7294
10941
14588
14710
17142
19457
Blocks
29294496
126993825
29294496
29294496
29294496
979933+
19535008+
18595206
Id
7
5
b
83
83
82
83
83
System
HPFS/NTFS
Extended
W95 FAT32
Linux
Linux
Linux swap / Solaris
Linux
Linux
Disk /dev/sdb: 519 MB, 519192576 bytes
16 heads, 63 sectors/track, 1006 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Disk identifier: 0x88a4f2af
Device
Boot Start
/dev/sdb1
1
*
root@gtrdesktop: #
6.1.5.
End
1006
Blocks
506992+
Id
83
System
Linux
Comando dmesg
Muestra un mensaje de diagnóstico que contiene eventos generados en el arranque del sistema y durante la
depuración de aplicaciones.
gtr-v106: # dmesg
Linux version 2.6.23-486-voyage (2.6.23-2) (root@punknix-uml) (gcc version
4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 PREEMPT Wed May 21
15:31:49 GMT 2008
...
6.1.6.
Comando lspci
Se usa para listar todos los dispositivos PCI reconocidos en el equipo.
6.1 Comandos generales en Linux
81
voyage: # lspci 00:00.0 Host bridge: Cyrix Corporation PCI Master
00:0d.0 Ethernet controller: Atheros Communications, Inc. AR5006X 802.11abg NIC
(rev 01)
00:0e.0 Ethernet controller: National Semiconductor Corporation DP83815
(MacPhyter) Ethernet Controller
00:11.0 Ethernet controller: Atheros Communications, Inc. AR5006X 802.11abg NIC
(rev 01)
00:12.0 ISA bridge: National Semiconductor Corporation SC1100 Bridge
00:12.1 Bridge: National Semiconductor Corporation SC1100 SMI
0:12.2 IDE interface: National Semiconductor Corporation SCx200 IDE (rev 01)
00:12.3 Multimedia audio controller: National Semiconductor Corporation SCx200
Audio
00:12.5 Bridge: National Semiconductor Corporation SC1100 XBus
voyage: #
6.1.7.
Comando ps aux
Comando que muestra información acerca de los procesos que se ejecutan en el equipo.
voyage: # ps aux
USER
PID %CPU %MEM VSZ RSS TTY
STAT START TIME COMMAND
...
root
1801 0.0 0.4 2172 580 ?
S<s Apr02 0:02 udevd -daemon
root
2937 0.0 0.4 1752 612 ?
Ss
Apr02 2:16 /sbin/wpa_ supplicant
-B -P /var/run/wpa_ supplicant.ath0.p
daemon 3020 0.0 0.2 1680 352 ?
Ss
Apr02 0:00 /sbin/portmap
root
3109 0.0 0.4 1624 612 ?
Ss
Apr02 0:03 /sbin/syslogd
root
3115 0.0 0.2 1576 376 ?
Ss
Apr02 0:00 /sbin/klogd -x
root
3247 0.0 1.2 4720 1620 ?
Ss
Apr02 0:22 /usr/lib/postfix/master
postfix 3255 0.0 1.3 4764 1704 ?
S
Apr02 0:01 qmgr -l -t fifo -u
root
3256 0.0 0.4 1736 556 ?
Ss
Apr02 0:00 /usr/sbin/pptpd
quagga 3275 0.0 0.7 2636 944 ?
Ss
Apr02 0:01 /usr/lib/quagga/zebra
-daemon -A 127.0.0.1
quagga 3279 0.0 1.0 3268 1368 ?
Ss
Apr02 7:54 /usr/lib/quagga/ospfd
-daemon -A 127.0.0.1
root
3287 0.0 0.8 4852 1080 ?
Ss
Apr02 0:00 /usr/sbin/sshd
root
3325 0.0 0.6 2192 884 ?
Ss
Apr02 0:03 /usr/sbin/cron
root
3333 0.0 0.3 1620 440 ?
Ss
Apr02 0:59 /usr/sbin/watchdog
asterisk3356 0.1 4.6 13876 5848 ?
Ssl Apr02 8:59 /usr/sbin/asterisk -p
-U asterisk
root
3397 0.0 0.3 1572 496 ttyS0 Ss+ Apr02 0:00 /sbin/getty -L ttyS0
38400
root
9697 0.7 1.8 7624 2320 ?
Ss
10:45 0:00 sshd: root@pts/0
root
9701 6.2 2.0 3664 2540 pts/0 Ss
10:46 0:02 -bash
root
9719 0.0 0.7 2216 888 pts/0 R+
10:46 0:00 ps aux
voyage: #
6.1.8.
Comando kill
Sirve para cancelar procesos que se están ejecutando en el sistema.
voyage: # kill 3356
82
CAPÍTULO 6. CONFIGURACIÓN E INSTALACIÓN DE VOYAGE GTR
6.1.9.
Comando hostname
Muestra y modifica el nombre del sistema.
voyage: # hostname
voyage
voyage: #
6.1.10.
Comando tail
Muestra la última parte de archivos. Con la opción -f se puede ver como cambia el contenido de los archivos.
voyage: # tail -f /var/log/syslog
Apr 8 08:55:08 voyage - MARK Apr 8 09:15:01 voyage /USR/SBIN/CRON[9286]: (root) CMD ( cd / && run-parts
-report /etc/cron.hourly)
Apr 8 09:35:08 voyage - MARK Apr 8 09:55:08 voyage - MARK Apr 8 10:15:01 voyage /USR/SBIN/CRON[9550]: (root) CMD ( cd / && run-parts
-report /etc/cron.hourly)
Apr 8 10:35:09 voyage - MARK Apr 8 10:45:36 voyage kernel: eth0: Autonegotiation advertising 0x5e1
partner 0x00.
Apr 8 10:45:36 voyage kernel: eth0: link down.
Apr 8 10:45:46 voyage kernel: eth0: Autonegotiation advertising 0x5e1
partner 0x45e1.
Apr 8 10:45:46 voyage kernel: eth0: link up.
voyage: #
6.1.11.
Comando ifconfig
Muestra las condiciones en la cual se encuentra una interfaz de red y también sirve para configurar los
parámetros de red.
voyage: # ifconfig eth0
eth0
Link encap:Ethernet HWaddr 00:0D:B9:07:E9:C0
inet addr:20.20.20.210 Bcast:20.20.20.255 Mask:255.255.255.0
inet6 addr: fe80::20d:b9ff:fe07:e9c0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:485434 errors:0 dropped:0 overruns:0 frame:0
TX packets:52531 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:30162474 (28.7 MiB) TX bytes:4139442 (3.9 MiB)
Interrupt:10 Base address:0x8000
voyage: #
6.1.12.
Comando ping
Manda una mensaje de prueba a un dispositivo de red y espera una respuesta mostrando el tiempo de respuesta de cada paquete que envía; si no recibiera respuesta esto significaría que no hay conexión con ese
dispositivo.
6.2 Instalación de Voyage GTR
83
voyage: # ping 20.20.20.1 -c 5
PING 20.20.20.1 (20.20.20.1) 56(84) bytes of
64 bytes from 20.20.20.1: icmp_ seq=1 ttl=64
64 bytes from 20.20.20.1: icmp_ seq=2 ttl=64
64 bytes from 20.20.20.1: icmp_ seq=3 ttl=64
64 bytes from 20.20.20.1: icmp_ seq=4 ttl=64
64 bytes from 20.20.20.1: icmp_ seq=5 ttl=64
data.
time=0.723
time=0.639
time=0.641
time=0.700
time=0.641
ms
ms
ms
ms
ms
-- 20.20.20.1 ping statistics -5 packets transmitted, 5 received, 0 % packet loss, time 3998ms
rtt min/avg/max/mdev = 0.639/0.668/0.723/0.048 ms
voyage: #
6.1.13.
Comando ssh
Mediante la ejecución de este comando se puede ingresar remotamente a otros equipos conectados a la red.
voyage: # ssh 20.20.20.1
The authenticity of host '20.20.20.1 (20.20.20.1)'can't be established.
RSA key fingerprint is 44:d6:51:d7:3c:eb:3b:20:30:3e:79:50:57:6f:02:a4.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '20.20.20.1'(RSA) to the list of known hosts.
[email protected]'s password:
gtr-v106: #
En el ejemplo anterior se ingresa a la placa ALIX que tiene como IP la 20.20.20.68 desde una PC.
6.1.14.
Comando route
Muestra y manipula la tabla de rutas IP.
@gtrdesktop: # route -n
Kernel IP routing table
Destination
Gateway
20.20.20.0
0.0.0.0
169.254.0.0
0.0.0.0
0.0.0.0
20.20.20.1
root@gtrdesktop: #
6.2.
Genmask
255.255.255.0
255.255.0.0
0.0.0.0
Flags
U
U
UG
Metric
0
1000
0
Ref
0
0
0
Use
0
0
0
Iface
eth1
eth1
eth1
Instalación de Voyage GTR
Para instalar Voyage GTR en una Compact Flash (CF) se introduce la memoria CF en el lector/grabadora
de memorias USB y se conecta a una PC con Linux y se ejecuta el script de instalación. Para la instalación se
recomienda trabajar como usuario root en la PC; se debe obtener la versión de Voyage GTR junto al script que
permite su grabado; ambos se podrían guardar en la carpeta /root/. Ahora se ejecuta el script que permite el
grabado de Voyage GTR.
84
CAPÍTULO 6. CONFIGURACIÓN E INSTALACIÓN DE VOYAGE GTR
root@gtrdesktop: # ls
grabar-voyage-gtr voyage-gtr-0.5.tar.gz
root@gtrdesktop: # bash grabar-voyage-gtr
####################################################################
Grabado de la voyage gtr
* Fuentes del voyage: /root/voyage-gtr-0.5.tar.gz
* Elija si es para alix(2c0/3c1) soekris(4511/4521) wrap(2E/1E): alix
* Archivos de configuracion:
- - - - - - - Dispositivos encontrados en la PC
Disk /dev/sda: 80.0 GB, 80026361856 bytes
Disk /dev/sdb: 1008 MB, 1008730112 bytes
Disk /dev/sdc: 1039 MB, 1039417344 bytes
- - - - - - - !!! cuidado con lo elegido !!!
* Seleccione CF, dispositivo (sdx): sdc
* Se desea chequear la CF (si|no):si
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Resumen:
Fuente: voyage-gtr-0.5.tar.gz
Archivos conf:
Hardware: alix
Dispositivo CF: sdc
Chequeo CF: si
continuar(si/no)?: si
####################################################################
... buscando particiones montadas
... dispositivo /dev/sdc posee particion /dev/sdc1 montada
... particion /dev/sdc1 fue desmontada
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ... se encontro 15860 cilindros en /dev/sdc
... creando la particion /dev/sdc1
... formateando /dev/sdc1
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ... montando /dev/sdc1 en /mnt/tmp-voyage
... copiando voyage-gtr-0.3.tar.gz a /mnt/tmp-voyage
...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ... instalando GRUB
...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ... desmontando directorio /mnt/tmp-voyage
... chequeando integridad de la particion
ROOT_ FS: clean, 15075/63488 files, 74024/253756 blocks
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ... grabacion finalizada
####################################################################
root@gtrdesktop: #
Si no se muestra ningún tipo de error o advertencia se puede dar por finalizada la grabación y se puede
extraer la CF y desconectar la lectora/grabadora del puerto USB.
6.3 Acceso inicial por puerto serial o por Ethernet
6.3.
85
Acceso inicial por puerto serial o por Ethernet
Una vez instalado Voyage en la CF, ésta se coloca en la placa ALIX y se procede al acceso; para esto se
usará una PC con Linux y un cable serial nulo; quizás sea necesario un adaptador serial-USB si la PC carece
de puerto serial sin encender la placa ALIX, se procede a conectar el cable serial a la PC y a la placa ALIX; en
un terminal, como administrador, se ejecuta los siguientes comandos:
Con puerto serial:
# chmod 777 /dev/ttyS0
# cu -l /dev/ttyS0 -s 38400
Con puerto serial y adaptador serial-USB:
# chmod 777 /dev/ttyUSB0
# cu -l /dev/ttyUSB0 -s 38400
Al energizar la placa ALIX, en el terminal se podrá observar como se carga Voyage Linux hasta que se pida
el ingreso del usuario y la contraseña; por defecto el usuario es root y la contraseña es voyage. El uso del
puerto serial es muy importante porque nos permite ingresar a los equipos sin usar sus interfaces de red y en
caso de fallas para observar los problemas en el equipo
El puerto Ethernet eth0 de la placa esta configurado por defecto con la IP 11.11.11.1/24; por lo cual en un
inicio se puede ingresar por este puerto con ssh. Para ingresar se usará un cable cruzado y una vez que la placa
este encendida y cargado el sistema operativo (alrededor de un minuto) se puede hacer:
# ssh [email protected]
Después de esto se pedirá el ingreso de la clave, en éste caso inicial será voyage.
6.4.
Edición de archivos
La partición donde se instala Voyage GTR inicialmente carga en modo lectura.
voyage: # mount
rootfs on / type rootfs (rw)
none on /sys type sysfs (rw)
none on /proc type proc (rw)
udev on /dev type tmpfs (rw)
/dev/disk/by-label/ROOT_ FS on / type ext2 (ro,noatime)
/dev/disk/by-label/ROOT_ FS on /dev/.static/dev type ext2 (rw)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec)
tmpfs on /rw type tmpfs (rw)
voyage: #
Para editar los archivos y carpetas se debe pasar el sistema al modo escritura; cuando acabe se debe regresar
el sistema al modo escritura.
voyage: # remountrw
...
...editar archivos
...
voyage: # remountro
86
CAPÍTULO 6. CONFIGURACIÓN E INSTALACIÓN DE VOYAGE GTR
6.5.
Estructura de archivos de Voyage GTR
Un sistema operativo por más que se cargue en modo lectura necesita crear archivos temporales y rescribir
o crear archivos; la partición donde está instalada Voyage GTR pertenece a la CF y es la se que carga en modo
lectura.
Voyage:/# ls -l
total 101
-rwxr-xr-x 1 root root 9743 Jun 29
-rwxr-xr-x 1 root root 20711 Jun 22
drwxr-xr-x 2 root root 2048 Jul 22
drwxr-xr-x 3 root root 1024 Jul 15
drwxr-xr-x 13 root root 12860 Apr 24
drwxr-xr-x 65 root root 3072 Apr 24
drwxr-xr-x 3 root root 1024 Jul 22
drwxr-xr-x 2 root root 1024 Jun 28
lrwxrwxrwx 1 root root
33 May 8
-2.6.23-486-voyage
lrwxrwxrwx 1 root root
33 May 8
->boot/initrd.img-2.6.23-486-voyage
drwxr-xr-x 12 root root 3072 Jul 15
drwx------ 2 root root 12288 Jul 15
drwxr-xr-x 2 root root 1024 Jun 28
drwxr-xr-x 2 root root 1024 Oct 28
drwxr-xr-x 4 root root 1024 Jul 22
dr-xr-xr-x 44 root root
0 Dec 31
drwxr-xr-x 8 root root 1024 Apr 24
lrwxrwxrwx 1 root root
8 May 8
drwxr-xr-x 8 root root
160 Apr 24
drwxr-xr-x 2 root root 3072 Jul 22
drwxr-xr-x 2 root root 1024 Jun 28
drwxr-xr-x 10 root root
0 Dec 31
-rw-r-r--- 1 root root
352 Jul 11
lrwxrwxrwx 1 root root
7 May 8
drwxr-xr-x 10 root root 1024 Apr 24
drwxr-xr-x 7 root root 1024 Jul 1
lrwxrwxrwx 1 root root
30 May 8
-2.6.23-486-voyage
lrwxrwxrwx 1 root root
30 May 8
->boot/vmlinuz-2.6.23-486-voyage
-rw-r-r--- 1 root root 11213 Jun 29
-rw-r-r--- 1 root root 17239 Jun 29
-rw-r-r--- 1 root root 3165 Jun 29
-rw-r-r--- 1 root root
96 Apr 24
-rw-r-r--- 1 root root
54 Apr 24
voyage:/#
2008
2008
2008
2008
16:06
17:17
2008
2008
2009
CHANGELOG
README
bin
boot
dev
etc
home
initrd
initrd.img ->boot/initrd.img
2009 initrd.img-2.6.23-486-voyage
2008
2008
2008
2006
2008
1999
14:58
2009
14:58
2008
2008
1999
2008
2009
14:53
2008
2009
lib
lost+found
media
mnt
opt
proc
ro
root ->/rw/root
rw
sbin
srv
sys
test.conf
tmp ->/rw/tmp
usr
var
vmlinuz ->boot/vmlinuz
2009 vmlinuz-2.6.23-486-voyage
2008
2008
2008
16:06
20:27
voyage.depends.list
voyage.dpkg-l
voyage.dpkg.list
voyage.gtr.variables
voyage.gtr.version
Pero la carpeta /rw está contenida en un espacio delimitado (hasta 32MB) de la RAM del sistema, por
tanto está en modo escritura; por lo que en este espacio se podrá editar los archivos que se encuentren aquí y
también crear o eliminar archivos; pero al estar en RAM se perderá la información después de un reinicio.
6.6 Guardar archivos o carpetas de /rw
voyage:/var# ls -l
total 5
drwxr-xr-x 2 root
drwxr-xr-x 6 root
drwxr-xr-x 16 root
drwxrwsr-x 2 root
lrwxrwxrwx 1 root
lrwxrwxrwx 1 root
lrwxrwxrwx 1 root
drwxr-xr-x 2 root
lrwxrwxrwx 1 root
lrwxrwxrwx 1 root
lrwxrwxrwx 1 root
voyage:/var#
root
root
root
staff
root
root
root
root
root
root
root
1024
1024
1024
1024
12
11
12
1024
11
13
11
87
Apr
Jul
Apr
Oct
May
May
May
Jun
May
May
May
24 18:00 backups
15 2008 cache
24 11:40 lib
28 2006 local
8 2009 lock ->/rw/var/lock
8 2009 log ->/rw/var/log
8 2009 mail ->/rw/var/mail
28 2008 opt
8 2009 run ->/rw/var/run
8 2009 spool ->/rw/var/spool
8 2009 tmp ->/rw/var/tmp
Por ejemplo /root, /var/log, /var/spool están ubicados físicamente en /rw pero que es sí son
/rw/root, /rw/var/log, /rw/var/spool respectivamente; por tanto /root,
/var/log, /var/spool son enlaces a estas carpetas. Cuando el sistema reinicia se perderá
/rw/root, /rw/var/log, /rw/var/spool y todo lo modificado o creado en estas carpetas; entonces
para crear de nuevo estas carpetas, se tiene a /ro; todo lo que está en /ro se copiará a /rw, por tanto una
vez que el sistema levante los enlaces /root, /var/log, /var/spool estarán apuntando de nuevo a
/rw/root, /rw/var/log, /rw/var/spool; lo creado o modificado en éstas carpetas antes del reinicio se perderá en /ro no se guarda directamente los cambios hechos en estas carpetas; por tanto lo que se copie
de /ro a /rw sólo será la estructura inicial.
voyage:/rw# ls -l
total 0
drwxr-xr-x 2 root
drwxr-xr-x 4 root
drwxr-xr-x 2 root
drwxrwxrwt 2 root
drwxr-xr-x 2 root
drwxr-xr-x 9 root
voyage:/rw#
voyage: # cd /ro/
voyage:/ro# ls -l
total 6
drwxr-xr-x 2 root
drwxr-xr-x 4 root
drwxr-xr-x 2 root
drwxrwxrwt 2 root
drwxr-xr-x 2 root
drwxr-xr-x 9 root
voyage:/ro#
6.6.
root 40 Jun 29 2008 dev
root 140 Apr 24 16:28 etc
root 140 Apr 24 22:40 root
root 40 Dec 31 1999 tmp
root 40 Jun 29 2008 usr
root 180 Jun 29 2008 var
root
root
root
root
root
root
1024
1024
1024
1024
1024
1024
Jun
Apr
Jul
Jun
Jun
Jun
29 2008 dev
24 16:28 etc
23 2008 root
29 2008 tmp
29 2008 usr
29 2008 var
Guardar archivos o carpetas de /rw
Todo lo modificado o creado en /rw se perderá después de un reinicio; pero existe la posibilidad de
guardar estas modificaciones; en el archivo /etc/voyage.conf, específicamente en la variable VOYAGE_
SYSTEM_ SYNCDIRS se indica que carpeta o carpetas (por ende su contenido) se desea guardar; en la variable VOYAGE_ SYSTEM_ SYNCFILES se indica que archivo o archivos se desea guardar. Debe descomentar
88
CAPÍTULO 6. CONFIGURACIÓN E INSTALACIÓN DE VOYAGE GTR
estas variables si se van a usar.
Una vez que reinicia el equipo todo el contenido de las carpetas o archivos seleccionados para guardar se
guardarán, incluyendo su contenido, en /ro; cuando el sistema cargue después del reinicio, en /rw estará lo
guardado.
voyage: # cat /etc/voyage.conf
#
# This file generated automatically by copyfiles.sh
# on Tue Jul 15 15:40:18 PET 2008
#
VOYAGE_ PROFILE=ALIX
VOYAGE_ SYSTEM_ CONSOLE=serial
# VOYAGE_ SYSTEM_ SYNCDIRS=/var/log"
# VOYAGE_ SYSTEM_ SYNCFILES=/var/log/syslog /var/log/kern.log"
VOYAGE_ SYSTEM_ SERIAL=38400
VOYAGE_ SYSTEM_ PCMCIA=no
VOYAGE_ SYSTEM_ MODULES=”lm90; w83627hf; scx200_ acb base=0x810,0x820;
geodewdt; led-class; leds-alix; ledtrig-heartbeat; ledtrig-timer"
SYSTEM_ BOOTSTRAP=grub
Voyage: #
Si ya no se desea seguir guardando se comenta de nuevo las variables.
6.7.
Configuración previa a cualquier aplicación en Voyage GTR
Dar nombre al equipo, editar /etc/hostname; el nombre del equipo no debe contener puntos ni espacios en blanco o caracteres extraños.
voyage: # cat /etc/hostname
voyage
voyage: #
Dar una clave al sistema
voyage: # passwd
Si el equipo no va a ser un servidor de tiempo, se puede indicar un servidor o servidores NTP editando la
variable NTPSERVERS.
voyage: # cat /etc/default/ntpdate
...
# NTPSERVERS=”0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian
.pool.ntp.org 3.debian.pool.ntp.org"
NTPSERVERS=”200.16.6.80"
...
Configurar el reinicio del equipo; editar el archivo /etc/cron.d/reboot-board y descomentar la
opción de reinicio aleatorio de entre las 4 y 4:30 horas cada sábado o reinicio a las 4 horas todos los días.
También se puede configurar uno particular.
6.8 Obtención de respaldo de la configuración de las aplicaciones en Voyage GTR
89
voyage: # cat /etc/cron.d/reboot-board
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# min hour dom month dow user command
#0
4
6 root (sleep `echo $(( $RANDOM / 20 ))` ; reboot)
*
*
#0
4
*
*
* root reboot
voyage: #
6.8.
Obtención de respaldo de la configuración de las aplicaciones
en Voyage GTR
Para sacar un respaldo de la configuración hecha en Voyage GTR se debe indicar que archivo o carpeta se
debe respaldar; esto se indica en el archivo de configuración /etc/backup.list; originalmente éste archivo contiene una lista de los archivos y/o carpetas que deberían ser respaldados; si en esta lista no se encuentra
una carpeta o archivo en particular se adiciona línea por línea. Después se ejecuta el script mgbackup con la
opción backup:
red-sur: # mgbackup backup
...
32: guardando /etc/default/snmpd
33: guardando /etc/snmp
34: guardando /etc/quagga/daemons
35: guardando /etc/quagga/ospfd.conf
36: guardando /etc/quagga/zebra.conf
37: guardando /etc/uya/passwd
... finalizado respaldo
... solo guarde el /opt/backup-conf-red-sur.tar.gz
red-sur: #
Si no se muestra error en la creación del respaldo, se creará en /opt un archivo comprimido con el nombre
del equipo. Después de la creación del respaldo, el sistema regresar al modo lectura.
La opción Archivos de configuración mostrada al ejecutar el script que permite el grabado de
Voyage GTR en la CF, se utilizará para indicar el archivo de respaldo (obtenido antes) que se copiará en esta
grabación de Voyage GTR; es decir Voyage GTR que se obtendrá aquí será idéntica en configuración de Voyage
GTR de donde se sacó el respaldo.
6.9.
Verificación del estado de Voyage GTR
6.9.1.
Espacio ocupado y disponible
Dependiendo del tipo de router se debe observar el espacio disponible en el disco total y en las particiones
críticas. Normalmente es necesario que se tenga al menos la mitad de espacio disponible en cada partición, si
se tiene ocupando más de la mitad, se debe eliminar archivos innecesarios y vigilar. Anotar:
Espacio ocupado y disponible de las particiones críticas del equipo.
En el router GTR se tiene dos particiones críticas que son la /ro y /rw.
90
CAPÍTULO 6. CONFIGURACIÓN E INSTALACIÓN DE VOYAGE GTR
voyage: # df -l
Filesystem
1K-blocks
Used Available Use % Mounted on
rootfs
998808 272816
675256 29 % /
udev
10240
20
10220
1 % /dev
/dev/disk/by-label/ROOT_ FS
998808 272816
675256 29 % /
/dev/disk/by-label/ROOT_ FS
998808 272816
675256 29 % /dev/.static/dev
tmpfs
63384
0
63384
0 % /lib/init/rw
tmpfs
63384
0
63384
0 % /dev/shm
tmpfs
32768
664
32104
3 % /rw
voyage: #
6.9.2.
RAM libre y CPU desocupado en un instante
Esto dará una idea de cuanta RAM o CPU se está usando en el equipo para prevenir un uso excesivo de
los recursos del sistema. Si se tiene un uso alto se debe seguir vigilando para asegurarse que quizás sólo sea
un instante donde muchas aplicaciones estén con mucho trabajo. En un diseño no puede estar contemplado una
carga alta y constante por mucho tiempo, si esto sucede se debe buscar las aplicaciones que causan el excesivo
consumo o quizás reiniciar el equipo para regresar al estado normal. El uso excesivo se da generalmente en
pocos instantes y con poca duración, en este instante se puede llegar a más de 60 % de RAM y casi 100 % de
CPU; pero en el resto del tiempo generalmente se debe tener un consumo de alrededor de 20 % de RAM; y el
CPU debe estar casi en 90 % si uso. Anotar:
RAM libre en un instante de trabajo normal.
CPU desocupado en un instante de trabajo normal.
gtr-v106: # free
total
used
free
Mem:
126768 47564 79204
-/+ buffers/cache: 19812 106956
Swap:
0
0
0
gtr-v106: #
shared
0
buffers
2604
cached
25148
gtr-v106: # top
top - 15:01:42 up 10:43, 1 user, load average: 0.01, 0.02, 0.00
Tasks: 34 total, 1 running, 33 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.3 %us, 1.0 %sy, 0.0 %ni, 95.4 %id, 0.0 %wa, 0.3 %hi, 2.0 %si, 0.0 %st
Mem: 126768k total, 68964k used, 57804k free,
2800k buffers
Swap:
0k total,
0k used,
0k free, 45956k cached
...
6.9.3.
Fecha del sistema y último reinicio
Tomar la fecha del sistema para saber si está sincronizando o no con el servidor de tiempo. Se recomienda
que esté sincronizado; si no lo está por motivos de red se podría fijar la fecha manualmente. Además se debe
evaluar el correcto reinicio programado del router, se puede evaluar observando el último reinicio del equipo.
Anotar:
Fecha del sistema.
Fecha del último reinicio del sistema.
6.9 Verificación del estado de Voyage GTR
gtr-v106: # date
Fri May 8 15:05:18 PET 2009
gtr-v106: #
gtr-v106: # date -set "05/11/09 14:51"
voyage: # uptime
14:29:10 up 10:10, 1 user, load average: 0.00, 0.00, 0.00
voyage: #
91
92
CAPÍTULO 6. CONFIGURACIÓN E INSTALACIÓN DE VOYAGE GTR
7
Con guración de Redes con Voyage GTR
7.1.
Interfaces de Red
Para empezar a configurar las interfaces de red se debe asegurar que el sistema reconozca los dispositivos;
para esto se puede hacer:
voyage: # lspci
00:01.0 Host bridge: Advanced Micro Devices [AMD] Unknown device 2080 (rev 33)
00:01.2 Entertainment encryption device: Advanced Micro Devices [AMD] Geode LX
AES Security Block
00:09.0 Ethernet controller: VIA Technologies, Inc. VT6105M [Rhine-III] (rev 96)
00:0b.0 Ethernet controller: VIA Technologies, Inc. VT6105M [Rhine-III] (rev 96)
00:0c.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC
(rev 01)
00:0f.0 ISA bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA
(rev 03)
00:0f.2 IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion]
IDE (rev 01)
00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion]
OHC (rev 02)
00:0f.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion]
EHC (rev 02)
voyage: #
Además se debe asegurar que el sistema disponga de los controladores para estos dispositivos, aunque esto
ya se ha hecho al implementar Voyage Gtr; se puede observar en /var/log/syslog una vez que el sistema
este cargado.
93
94
CAPÍTULO 7. CONFIGURACIÓN DE REDES CON VOYAGE GTR
voyage: #
voyage: # cat /var/log/syslog |grep wifi
May 20 15:40:16 voyage kernel: wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
May 20 15:40:16 voyage kernel: wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
May 20 15:40:16 voyage kernel: wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps
36Mbps 48Mbps 54Mbps
May 20 15:40:16 voyage kernel: wifi0: H/W encryption support:
WEP AES AES_CCM TKIP
May 20 15:40:16 voyage kernel: wifi0: mac 5.9 phy 4.3 radio 4.6
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 1 for WME_AC_BE traffic
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 0 for WME_AC_BK traffic
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 2 for WME_AC_VI traffic
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 3 for WME_AC_VO traffic
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 8 for CAB traffic
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 9 for beacons
May 20 15:40:16 voyage kernel: wifi0: Atheros 5212: mem=0xe0080000, irq=9
voyage: #
voyage: # cat /var/log/syslog |grep eth
May 20 15:40:16 voyage kernel: eth0: VIA Rhine III (Management Adapter) at
0xe0000000, 00:0d:b9:16:e7:9c, IRQ 10.
May 20 15:40:16 voyage kernel: eth0: MII PHY found at address 1, status 0x786d
advertising 05e1 Link 45e1.
May 20 15:40:16 voyage kernel: eth1: VIA Rhine III (Management Adapter) at
0xe0040000, 00:0d:b9:16:e7:9d, IRQ 12.
May 20 15:40:16 voyage kernel: eth1: MII PHY found at address 1, status 0x7849
advertising 05e1 Link 0000.
May 20 15:40:16 voyage kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
May 20 15:40:28 voyage kernel: eth0: no IPv6 routers present
voyage: #
7.2.
Configuración de las interfaces de red
Los archivos de configuración están editados con una plantilla que se puede modificar o adicionar rápidamente. En el archivo /etc/network/interfaces se especifica la configuración de las interfaces de red.
En este archivo no se pone la ruta por defecto, eso se hará en /etc/network/natstatic-routes.
7.2.1.
Configuración de Ethernet y de Bridge Ethernet
Para configurar las interfaces Ethernet se descomenta las líneas correspondientes y se cambiará la IP/Máscara
de red si es necesario.
auto eth0
iface eth0 inet static
address 10.10.10.1
netmask 255.255.255.240
#auto eth1
#iface eth1 inet static
#address 11.11.11.1
#netmask 255.255.255.0
7.2 Configuración de las interfaces de red
95
Si se desea crear bridge, sólo se podrá hacer entre las Ethernet; se debe descomentar el bloque del bridge y
poner la IP/Máscara de red; además la configuración de las interfaces involucradas deben ser comentadas.
auto br0
iface br0 inet static
address 11.11.10.1
netmask 255.255.255.0
bridge_ports eth0 eth1
bridge_stp off
bridge_maxwait 5
7.2.2.
Configuración de las interfaces WiFi
La configuración implica los siguientes pasos:
Elección si es AP ó STA.
Configuración parámetros WiFi
Establecer seguridad
Configuración de la IP/MASK
Si es AP se descomenta las líneas:
#--ap
ath_parent wifi0
ath_vaptype ap
Si es STA se descomenta las líneas:
#--cliente
ath_parent wifi0
ath_vaptype sta
#ath_vapopts nosbeacon
Sólo en el caso de que en una placa se mezclen AP y STA la línea #ath_vapopts nosbeacon del
STA deberá ser descomentada.
Algunos parámetros WiFi son obligatorios, se cambiará de valor según sea necesario.
#--otros parametros wifi
ath_distance 19800 está en metros, cada interfaz de un mismo enlace debe estar
configurado con la misma distancia; si se tiene varios STA
se coloca la distancia más larga que existe entre el AP
y el STA (NOB)
ath_diversity 0
puede ser 1 habilitado o 0 deshabilitado) (NOB)
ath_txantenna 1
puede ser 1 o 2; se refiere al conector de la tarjeta
inalámbrica donde será conectado la antena para transmitir;
si ath_diversity es 1 no interesa su valor
ath_rxantenna 1
puede ser 1 o 2; si ath_diversity es 1 no interesa su valor
ath_txpower 23
está dado dBm, si se pone debe ser un valor valido, puede ser
de 0 a 30, se debe conocer antes según la tarjeta
inalámbrica (NOB)
96
CAPÍTULO 7. CONFIGURACIÓN DE REDES CON VOYAGE GTR
ath_wirelessmode 11g puede ser 11a o 11g (OB)
ath_ssid EHAS1
nombre de la red (OB)
ath_channel 11
puede ser 1 al 11 en 2.4GHz o 36 al 160 en 5.8GHz (OB si es AP)
ath_rate 9M
puede ser 6M, 9M, 12M ... 54M (NOB)
(NOB: no obligatorio, OB: obligatorio)
Para la seguridad; se puede elegir si se usa WEP o WPA-PSK; si se usa WEP aquí se pone la clave que
debe ser en hexadecimal; si se usa WPA2-PSK se descomenta el bloque respectivo si es STA o AP; y se debe
editar el archivo mencionado donde se cambiara el nombre de la red y la clave WPA2-PSK.
Si se usa WEP; se habilita y además se configura la clave; se elige 10 números hexadecimales (WEP de
64b) o 26 (WEP de 128b).
#--seguridad wep
ath_security wep
ath_wep_key1 12345ABCDE
Si se usa WPA2-PSK en una AP se habilita:
#--seguridad wpa-psk ap
ath_security wpa2
ath_wpa_cfgfile /etc/hostapd/hostapd-ath0.conf
Si se usa WPA2-PSK en una STA se habilita:
#--seguridad wpa-psk sta
wpa_driver madwifi
wpa_conf /etc/wpa_supplicant/wpasupplicant-ath0.conf
Por último se configura la IP y la Máscara de red de la interfaz.
#--ip y netmask
address 10.10.1.2
netmask 255.255.255.240
Si se ha elegido seguridad WPA2-PSK además de habilitar las opciones se debe editar los archivos adicionales; donde sólo se cambiará el nombre de la red y la clave WPA2-PSK (en caracteres y debe ser desde 8
a 63 caracteres). Existe un archivo plantilla para cada interfaz dependiendo si es STA o AP. Si se está configurando un cliente que es ath0 entonces se edita
/etc/wpa_supplicant/wpasupplicant-ath0.conf y se cambia el ESSID y la clave WPA2-PSK.
...
ssid="LOCAL0"
scan_ssid=1
...
priority=10
psk="gtrcaswifi"
#psk=70df87c28aee0e42b49f55450df0f822200933ff3968406176fbcd41eb9a8a72
Si se esta configurando un AP que es ath2 entonces se edita /etc/hostapd/hostapd-ath2.conf
y se cambia el ESSID y la clave WPA2-PSK.
...
ssid=LOCAL2
...
wpa_passphrase=gtrcaswifi
7.3 Configuración del enrutamiento estático, gateway y NAT
97
Para activar los cambios realizados se ejecuta /etc/init.d/networking restart además se actualiza la configuración hecha /etc/network/statics-routes-nat.
7.3.
Configuración del enrutamiento estático, gateway y NAT
Para poner en la ruta por defecto, NAT o rutas estáticas se usa el archivo
/etc/network/nat-static-routes, donde se encuentran variables que serán habilitadas según el uso.
Si el equipo debe tener una ruta por defecto se habilita la variable DEFAULT_GW, y se pone la dirección IP de
la ruta por defecto (gateway).
DEFAULT_GW="10.13.1.2"
Si se desea adicionar rutas estático se habilitando la variable ROUTEX (donde X es 1,2,3...100) y en cada
una se pone la red, la máscara de red y la salida por donde se accederá a esta red; además se pone la métrica.
ROUTE1="10.14.1.0/28
10.13.1.2 1"
Si se adiciona otra ruta se van adicionando variables numeradas. Esta limitado hasta 100 variables.
ROUTE2="10.15.1.0/28
ROUTE3="10.15.1.0/28
ROUTE4="10.15.1.0/28
....
10.13.1.2
10.13.2.2
10.13.3.2
1"
1"
1"
Para NAT sólo se optara por habilitar o no habilitar; si se habilita se descomenta la variable DEFAULT_NAT
y se elige la interfaz que hará de NAT en el equipo.
DEFAULT_NAT= “eth1”
Al ejecutar /etc/init.d/networking restart se actualiza la configuración hecha en
/etc/network/interfaces y en /etc/network/statics-routes-nat.
Si se va a usar OSPF, se recomienda configurar las rutas estáticas en zebra.conf y no hacerlo en este archivo.
7.4.
Configuración del enrutamiento dinámico con OSPF
Para la enrutamiento con OSPF los archivos usados son:
curco-2n2:/etc/quagga# ls
daemons
ospfd.conf
zebra.conf ....
Para los comentarios en zebra.conf y ospfd.conf se usa el símbolo !
En /etc/quagga/daemons se pone en yes si se desea usar OSPF.
98
CAPÍTULO 7. CONFIGURACIÓN DE REDES CON VOYAGE GTR
.....
zebra=yes
bgpd=no
ospfd=yes
ospf6d=no
ripd=no
ripngd=no
isisd=no
En zebra.conf; antes de todo se pone un nombre que podría ser el mismo que en ospfd.conf.
Hostname ospf-voyage
Se habilita las interfaces involucradas en el enrutamiento; se descomenta el bloque respectivo. Además se
puede cambiar el ancho de banda, por defecto esta en 10MB.
interface ath0
bandwidth 10000000
ipv6 nd suppress-ra
Si este equipo pertenece a una red OSPF y está conectado a un equipo vecino que no pertenece a una red
OSPF y además existe redes detrás de este equipo vecino; entonces si se quiere que la red OSPF acceda a éstas
redes; entonces en éste archivo de debe especificar la ruta para llegar a esa red indicando por donde se llegaría
y además de la distancia. En resumen se está adicionadas rutas estáticas en una red OSPF.
ip
route
10.14.1.0/28
10.13.1.2
1
Si hay más redes se debe adicionar más líneas de estas
ip
ip
route
route
10.14.2.0/28
10.14.3.0/28
10.15.1.2
10.15.1.2
1
1
Aquí también se puede poner la ruta por defecto del equipo; pero será mejor hacerlo en /etc/network
/nat-static-routes.
Para la configuración en si del OSPF se edita el archivo /etc/quagga/ospfd.conf.
Se pone un nombre.
hostname ospf-voyage
Se debe habilitar las interfaces involucradas descomentando los bloques respectivos; además se debe poner
un costo (valor entero), para que no se use el ancho de banda configurado en zebra.conf.
interface ath2
ip ospf cost 10
Ahora se debe especificar el identificador del equipo en la red OSPF, es importante este valor y debe ser
distinto en la red OSPF (al menos en una misma área).
ospf router-id 0.0.1.2
Ahora se debe poner las redes locales involucradas en la red OSPF; indicando Red/Máscara y el área al
cual pertenece.
7.5 Configuración del DHCP
network
network
network
network
10.10.1.0/28
10.10.2.0/28
10.11.1.0/28
10.21.1.0/28
99
area
area
area
area
0.0.0.0
0.0.0.0
0.0.0.1
0.0.0.2
Si este equipo es el límite entre áreas OSPF se debe indicar las redes que están el área que no sea el cero.
area
area
area
area
0.0.0.1
0.0.0.1
0.0.0.2
0.0.0.2
range
range
range
range
10.11.0.0/16
10.12.0.0/16
10.21.0.0/16
10.22.0.0/16
Si al equipo se le ha adicionado rutas estáticas (zebra.conf); entonces se debe especificar como se debe
publicar estas rutas a la red OSPF; para esto se descomenta la siguiente línea especificando la métrica y el tipo;
si no se desea publicar estas rutas estáticas se deja comentada la línea.
redistribute static metric 10 metric-type 1
Si se ha configurado una puerta de salida equipo (/etc/network/nat-static-routes); entonces
se debe especificar como se debe publicar en la red OSPF. Para esto se descomenta una de las siguientes líneas:
default-information originate metric 10 metric-type 1
! default-information originate always metric 10 metric-type 1
La diferencia está en always; con éste los routers tendrán una ruta por defecto este configurado o no en
el router que lo publica; sin always los routers tendrán una ruta por defecto mientras este configurado en el
router que lo publica.
Al ejecutar /etc/init.d/quagga stop y /etc/init.d/quagga start se actualiza los cambios del enrutamiento. Si una vez que OSPF ya está trabajando se hace /ect/init.d/networking
restart lo del OSPF se perderá, para activar de nuevo se debe ejecutar /etc/init.d/quagga restart.
7.5.
Configuración del DHCP
Para habilitar el servicio en el arranque; se debe poner yes en la variable RUNDNSMASQ en el archivo
/etc/default/dnsmasq. El archivo de configuración es /etc/dnsmasq.conf; en este archivo se especifica:
a) La interfaz por donde se brindará este servicio.
interface=br0
b) El rango de IP (inicio-final) y la Máscara de red; además del tiempo de asignación de la IP.
dhcp-range=192.168.114.7,192.168.114.14,255.255.255.240,24h
c) La ruta por defecto de los equipos clientes.
dhcp-option=3,192.168.114.1
100
CAPÍTULO 7. CONFIGURACIÓN DE REDES CON VOYAGE GTR
Para completar se debe especificar los DNS que usará este servicio; para esto se descomenta los DNS en
/etc/resolv.conf los que se necesite.
Para activar el servicio se ejecuta /etc/init.d/dnsmasq restart.
7.6.
Configuración de interfaces WiFi y de parámetros TCP/IP
mediante comandos
Crear la interfaz ath0 como AP
nodo-a: # wlanconfig ath0 create wlandev wifi0 wlanmode ap
Crear la interfaz ath0 como STA
nodo-a: # wlanconfig ath0 create wlandev wifi0 wlanmode sta
Activar la interfaz ath0
nodo-a: # ifconfig ath0 up
Configurar al modo 802.11g a ath0 (3 → g; 1 → a, 2 → b)
nodo-a: # iwpriv ath0 mode 3
Desactivar la diversidad y activar la RX y TX por el conector principal; para la ath0 (wifi0)
nodo-a: # echo 0 >/proc/sys/dev/wifi0/diversity
nodo-a: # echo 1 >/proc/sys/dev/wifi0/txantenna
nodo-a: # echo 1 >/proc/sys/dev/wifi0/rxantenna
Configurar el ESSID, canal, velocidad de TX, clave WEP de 64bits y limitar la potencia de TX
nodo-a: # iwconfig ath0 essid PUCP channel 11 rate 12M key
aabbccddee txpower 10
Configurar la distancia (en metros) del enlace
nodo-a: # athctrl -i wifi0 -d 1000
Configurar la IP/MASK de la interfaz ath0
nodo-a: # ifconfig ath0 12.12.12.1 netmask 255.255.255.0
Configurar la IP/MASK de la interfaz eth0
nodo-a: # ifconfig eth0 10.10.1.1 netmask 255.255.255.0
Configurar la IP/MASK de la interfaz eth1
7.6 Configuración de interfaces WiFi y de parámetros TCP/IP mediante comandos
101
nodo-a: # ifconfig eth1 192.168.1.2 netmask 255.255.255.0
Configurar una puerta de salida
nodo-a: # route add default gw 192.168.1.1
Configurar una ruta
nodo-a: # route add -net 10.10.2.0/24 gw 12.12.12.2 metric 10
Configurar NAT sobre eth1
nodo-b: # iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
Si se desea configurar DNS se debe indicar en /etc/resolv.conf.
Si una interfaz está como STA y se desea pasar a modo AP (o al revés), antes se debe deshabilitar la interfaz
lógica creada, así:
nodo-a: # wlanconfig ath0 destroy
y después se creará la interfaz lógica:
nodo-a: # wlanconfig ath0 create wlandev wifi0 wlanmode ...
Para eliminar rutas no deseadas se puede hacer:
nodo: # route del -net 192.168.20.0/24 gw 10.10.1.2
Para anular toda entrada de la tabla NAT se hace:
nodo: # iptables -t nat -F
Se debe recordar que se está trabajando con comandos; después de un reinicio se perderá la configuración.
102
CAPÍTULO 7. CONFIGURACIÓN DE REDES CON VOYAGE GTR
8
Veri cación del Estado de la Red de Datos
Como se ha comentado ampliamente en 1.4, con la tecnología WiLD se puede llega a construir grandes
redes de datos. Estas se encuentran compuestas de redes troncales y de distribución. Una red troncal consiste
tradicionalmente en líneas relativamente largas que recogen y reparten el tráfico a las zonas de distribución
situadas en pequeñas poblaciones.
En la figura 8.1 se puede apreciar la red troncal de color negro y la red de distribución de color rojo. Tomando
como base el escenario presentado, a continuación se detalla las medidas de verificación de buen estado, que
debe realizarse en una red instalada con routers con sistema operativo Voyage GTR.
Figura 8.1: Redes Troncal y de Distribución
103
104
CAPÍTULO 8. VERIFICACIÓN DEL ESTADO DE LA RED DE DATOS
8.1.
Conectividad en enlaces AP-STA
Se debe de tener en cuenta que en una conexión a realizar puede llegar a existir uno o varios AP (Master) ó
STA (Managed o Cliente), sin importar si este enlace pertenece a la red troncal o de distribución. Este tipo de
configuración lo realiza el Router Inalámbrico.
Figura 8.2: Enlace AP-STA
8.1.1.
Nivel de señal del enlace y relación de la calidad del enlace
Para analizar un enlace se debe saber que interfaces están involucradas y quien es Master (AP) y Managed
(STA); podemos comprobar el enlace directamente usando el comando iwconfig; pero si se tiene una interfaz
Managed entonces se puede escanear los AP (Master) de sus alrededores y observar el AP al que debería conectarse. En el cuadro de abajo se observa que la red PUCP está activa, posee seguridad (probablemente WEP),
está trabajando en el canal 11 y se tiene una buena señal de recepción que es alrededor de 72dBm (con link
Quality 23/94).
nodo-b: # iwlist ath0 scan
ath0
Scan completed :
Cell 01 - Address: 00:0C:42:18:F7:74
ESSID:“PUCP”
Mode:Master
Frequency:2.462 GHz (channel 11)
Quality=23/94 Signal level=-72 dBm Noise level=-95 dBm
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
48 Mb/s; 54 Mb/s
Extra:bcn_int=100
Extra:wme_ie=dd180050f2020101830002a3400027a4000042435e
Extra:ath_ie=dd0900037f010100240000
Estos parámetros representan la calidad del enlace. En largas distancias se puede asumir que se debe lograr
un nivel de entre -65dBm y -75dBm con una calidad (Link Quality) de unos 20dB; si se tiene un nivel por
debajo de -75dBm hasta -80dBm el enlace estará muy inestable y tendrá un rendimiento bajo. Tomar nota por
cada router del enlace:
Nivel de señal del enlace
8.1 Conectividad en enlaces AP-STA
105
Calidad del enlace
nodo-b: # iwconfig ath0
ath0
IEEE 802.11g ESSID:"PUCP"Nickname:
Mode:Managed Frequency:2.462 GHz Access Point:00:0C:42:18:F7:74
Bit Rate=12 Mb/s Tx-Power=10 dBm Sensitivity=0/3
Retry:off RTS thr:off Fragment thr:off
Encryption key:AABB-CCDD-EE Security mode:restricted
Power Management:off
Link Quality=22/94 Signal level=-73 dBm Noise level=-95 dBm
Rx invalid nwid:241 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
nodo-a: # iwconfig ath1
ath1
Link encap:Ethernet HWaddr 00:0C:42:18:F7:74
Mode:Master Frequency:2.462 GHz Access Point:00:0C:42:18:F7:74
Bit Rate=12 Mb/s Tx-Power=10 dBm Sensitivity=0/3
Retry:off RTS thr:off Fragment thr:off
Encryption key:AABB-CCDD-EE Security mode:restricted
Power Management:off
Link Quality=26/94 Signal level=-70 dBm Noise level=-96 dBm
Rx invalid nwid:84237 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
En los nodos Managed se observa la MAC del AP, con esto se puede asegurar que existe enlace entre el
STA y el AP; además se observa nivel aceptable de 70dBm (con un link quality de 25/94 aprox.). Además con
el resultado de ésta información se debe verificar el nombre la red WiFi, el canal, la potencia configurada, la
velocidad máxima, y la seguridad apoyada de otros archivos.
Con el siguiente comando se observará las potencias configurables en las tarjetas inalámbricas; por ejemplo
este resultado corresponde a una SR2 de Ubiquiti (posee un offset de 10dBm).
nodo-b: # iwlist ath0 txpower
ath0
8 available transmit-powers :
0 dBm
(1 mW)
4 dBm
(2 mW)
6 dBm
(3 mW)
8 dBm
(6 mW)
10 dBm
(10 mW)
12 dBm
(15 mW)
14 dBm
(25 mW)
16 dBm
(39 mW)
Current Tx-Power:10 dBm (10 mW)
Si se ha anulado la diversidad en una interfaz y se ha configurada el conector principal (Main) para transmitir y
recibir, se debe observar:
nodo-b:
0
nodo-b:
1
nodo-b:
1
nodo-b:
# cat /proc/sys/dev/wifi0/diversity
# cat /proc/sys/dev/wifi0/txantenna
# cat /proc/sys/dev/wifi0/rxantenna
#
106
CAPÍTULO 8. VERIFICACIÓN DEL ESTADO DE LA RED DE DATOS
8.1.2.
Cantidad de clientes conectados al AP
Según el diseño se debe comprobar que todos los clientes estén conectados al AP.
Anotar la cantidad de clientes conectados al AP.
voyage: # cat /proc/net/Madwifi/ath0/associated_sta
8.1.3.
Corrección del alineamiento de las antenas
En un enlace de larga distancia (punto a punto o punto a multipunto) uno de los objetivos grandes a cumplir
es dejar las antenas alineadas lo mejor posible.
En enlaces punto a punto es probable que se usen antenas directivas. En enlaces punto multipunto lo más
probable es que se use antenas sectoriales; en este caso se puede empezar apuntando la antena sectorial a la
bisectriz del arco formado por el conjunto de antenas con el que se desea establecer enlace.
Para alinear las antenas se necesita inicialmente conocer el ángulo de elevación y el azimut y encontrar la
mejor posición apoyados por medio de un alineador de antenas externo; pero para lograr mayor precisión se
puede usar las herramientas de los equipos a instalar; en este caso; se puede usar el comando iwconfig para
poder corregir el alineamiento de las antenas de un enlace.
Si por ejemplo; en un enlace punto a punto de unos 40Km con tarjetas de 400mW y antenas directivas de
24dBi en ambos puntos; se obtiene un nivel de señal de -91dBm (que es muy cerca al nivel de ruido de -94dBm)
y una calidad del enlace de 3; no se podrá establecer ningún enlace; se tendría que corregir el alineamiento de
las antenas.
nodo-c: # iwconfig ath0
ath0
IEEE 802.11g ESSID:ÇUSCO2"Nickname:
Mode:Managed Frequency:2.417 GHz Access Point:Not-Associated
Bit Rate=6 Mb/s Tx-Power=off Sensitivity=0/3
Retry:off RTS thr:off Fragment thr:off
Encryption key:6375-7363-6F Security mode:restricted
Power Management:off
Link Quality=3/94 Signal level=-91 dBm Noise level=-94 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Si al mejorar el alineamiento se tiene un nivel de alrededor -84dBm con una calidad de 12 se logrará tener
enlace; pero al tener un nivel muy bajo será muy inestable. Abajo se muestra que existe demasiada pérdida de
paquetes y un rendimiento bajo.
nodo-c: # iwconfig ath0
ath0
IEEE 802.11g ESSID:ÇUSCO2"Nickname:
Mode:Managed Frequency:2.412 GHz Access Point:00:0C:42:18:F7:74
Bit Rate=6 Mb/s Tx-Power=off Sensitivity=0/3
Retry:off RTS thr:off Fragment thr:off
Encryption key:6375-7363-6F Security mode:restricted
Power Management:off
Link Quality=12/94 Signal level=-84 dBm Noise level=-96 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
8.1 Conectividad en enlaces AP-STA
107
nodo-c: # ping 10.1.2.1 -c 10
PING 10.1.2.1 (10.1.2.1) 56(84) bytes of data.
64 bytes from 10.1.2.1: icmp_seq=2 ttl=64 time=0.624 ms
64 bytes from 10.1.2.1: icmp_seq=4 ttl=64 time=0.588 ms
64 bytes from 10.1.2.1: icmp_seq=5 ttl=64 time=0.596 ms
...
-- 10.1.2.1 ping statistics -0 packets transmitted, 4 received, 60 % packet loss, time 9007ms
rtt min/avg/max/mdev = 0.588/0.605/0.624/0.028 ms
nodo-c: # iperf -c 10.1.2.1 -i 5 -t 15
---------------------------------------Client connecting to 10.1.2.1, TCP port 5001
TCP window size: 16.0 KByte (default)
---------------------------------------[ 3] local 10.1.2.2 port 3962 connected with 10.1.2.1 port 5001
[ 3] 0.0- 5.0 sec 104 KBytes 170 Kbits/sec
[ 3] 5.0-10.0 sec 56.0 KBytes 91.8 Kbits/sec
[ 3] 10.0-15.0 sec 104 KBytes 170 Kbits/sec
[ 3] 0.0-15.6 sec 272 KBytes 143 Kbits/sec
nodo-c: #
Si se logra tener un nivel de -71dBm y una calidad de 22; el rendimiento mejorará, y no existirá pérdida de
paquetes, al menos en el mayor tiempo.
nodo-c: # iwconfig ath0
ath0
IEEE 802.11g ESSID:ÇUSCO2"Nickname:
Mode:Managed Frequency:2.412 GHz Access Point:00:0C:42:18:F7:74
Bit Rate=6 Mb/s Tx-Power=off Sensitivity=0/3
Retry:off RTS thr:off Fragment thr:off
Encryption key:6375-7363-6F Security mode:restricted
Power Management:off
Link Quality=22/94 Signal level=-71 dBm Noise level=-93 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
nodo-c: # ping 10.1.2.1 -c 10
PING 10.1.2.1 (10.1.2.1) 56(84) bytes of data.
64 bytes from 10.1.2.1: icmp_seq=1 ttl=64 time=1.34 ms
64 bytes from 10.1.2.1: icmp_seq=2 ttl=64 time=0.624 ms
64 bytes from 10.1.2.1: icmp_seq=3 ttl=64 time=0.599 ms
...
-- 10.1.2.1 ping statistics -10 packets transmitted, 10 received, 0 % packet loss, time 8999ms
rtt min/avg/max/mdev = 0.597/0.795/1.456/0.314 ms
nodo-c: # iperf -c 10.1.2.1 -i 5 -t 15
---------------------------------------Client connecting to 10.1.2.1, TCP port 5001
TCP window size: 16.0 KByte (default)
---------------------------------------[ 3] local 10.1.2.2 port 3962 connected with 10.1.2.1 port 5001
[ 3] 0.0- 5.0 sec 2.73 MBytes 4.97 Mbits/sec
[ 3] 5.0-10.0 sec 2.54 MBytes 4.26 Mbits/sec
[ 3] 10.0-15.0 sec 1.88 MBytes 3.15 Mbits/sec
[ 3] 0.0-15.0 sec 7.15 MBytes 4.00 Mbits/sec
nodo-b: #
108
CAPÍTULO 8. VERIFICACIÓN DEL ESTADO DE LA RED DE DATOS
Si con estos mismos equipos se está trabajando en enlaces más cortos, de alrededor de 15Km este nivel
de recepción obtenido aún se puede mejorar, al menos hasta llegar a -55dBm; pero para enlaces de 40Km con
estas tarjetas inalámbricas y antenas directivas, este nivel puede ser lo mejor que se logre.
Lograr un aceptable nivel de la señal y calidad del enlace no necesariamente garantiza un buen rendimiento;
además se debe observar los tiempos de ping que se hacen y el rendimiento (ver más adelante) que se puede
lograr; el resultados de estos esta relacionado con la correcta configuración de la distancia del enlace.
Inicialmente se puede dejar configurado el enlace con una distancia obtenida por medio de los simuladores
de enlaces WiFi y de las coordenadas obtenidas. Una vez en campo se puede encontrar la distancia más óptima
que puede estar alrededor de más o menos 300m del que se ha configurado. El cambio de la distancia se debe
hacer en ambos lados del enlace. En un enlace punto multipunto la distancia a configurar es la que se tiene con
la antena mas alejada.
Si no se ha configurado la distancia, por defecto se mostrará:
nodo-b:
48
nodo-b:
9
nodo-b:
48
nodo-b:
# cat /proc/sys/dev/wifi0/acktimeout
# cat /proc/sys/dev/wifi0/slottime
# cat /proc/sys/dev/wifi0/ctstimeout
#
Si se ha configurado para una distancia de 1000m por ejemplo; se tendría estos valores:
nodo-b:
89
nodo-b:
43
nodo-b:
89
nodo-b:
# cat /proc/sys/dev/wifi0/acktimeout
# cat /proc/sys/dev/wifi0/slottime
# cat /proc/sys/dev/wifi0/ctstimeout
#
Para no cambiar la distancia en /etc/network/interfaces se puede configurar por comandos y una
vez encontrado la distancia correcta se escribe en este archivo.
nodo-a: # athctrl -i wifi0 -d 10000
nodo-b: # athctrl -i wifi1 -d 10000
8.1.4.
Ping normal entre las interfaces del enlace
Una vez que se haya verificado los enlaces WiFi se debe verificar los parámetros TCP/IP de cada interfaz
de red. La IP y la máscara de red se observa con el comando ifconfig:
8.1 Conectividad en enlaces AP-STA
109
nodo-a: # ifconfig ath0
ath0
Link encap:Ethernet HWaddr 00:0C:42:18:F7:68
inet addr:10.1.2.2 Bcast:10.1.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:42ff:fe18:f768/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:28725 errors:0 dropped:0 overruns:0 frame:0
TX packets:27958 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4651917 (4.4 MiB) TX bytes:2217302 (2.1 MiB)
nodo-a: # ifconfig ath1
ath1
Link encap:Ethernet HWaddr 00:0C:42:18:F7:74
inet addr:10.1.2.1 Bcast:10.1.2.255 Mask:255.255.255.0
inet6 addr: fe80::20c:42ff:fe18:f774/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6687 errors:0 dropped:0 overruns:0 frame:0
TX packets:7962 errors:0 dropped:5 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1015702 (991.8 KiB) TX bytes:3055968 (2.9 MiB)
nodo-a: #
Se prueba la conectividad con el comando ping. Además de observar si la otra interfaz responde al ping; se
debe observar la regularidad de los ping que generalmente pueden oscilar entre 1 a 3ms en un enlace aceptable;
y además la pérdida de paquetes que generalmente deben estar entre 1 a 3 paquetes perdidos por cada 60
transmitidos (1 minuto). Para esta prueba se debe hacer un ping de unos 30 paquetes y por cada AP - STA del
enlace y anotar:
Si la otra interfaz responde al ping
Regularidad de los tiempos del ping,
Pérdida de paquetes
El resultado de los ping esta relacionados con la distancia del enlace y con nivel y calidad de la señal, se debe
tener en cuenta de éstos en esta prueba; quizás se tenga valor altos respecto a los referenciales.
voyage: # ping 11.11.11.1 -c 40
PING 11.11.11.1 (11.11.11.1) 56(84) bytes of data.
64 bytes from 11.11.11.1: icmp_seq=1 ttl=64 time=0.204 ms
64 bytes from 11.11.11.1: icmp_seq=2 ttl=64 time=0.118 ms
64 bytes from 11.11.11.1: icmp_seq=3 ttl=64 time=0.101 ms
64 bytes from 11.11.11.1: icmp_seq=4 ttl=64 time=0.133 ms
64 bytes from 11.11.11.1: icmp_seq=5 ttl=64 time=0.100 ms
...
64 bytes from 11.11.11.1: icmp_seq=39 ttl=64 time=0.098 ms
64 bytes from 11.11.11.1: icmp_seq=40 ttl=64 time=0.105 ms
-- 11.11.11.1 ping statistics -40 packets transmitted, 40 received, 0 % packet loss, time 38991ms
rtt min/avg/max/mdev = 0.097/0.109/0.204/0.021 ms
voyage: #
110
CAPÍTULO 8. VERIFICACIÓN DEL ESTADO DE LA RED DE DATOS
Si se obtiene resultados muy alejados de lo aceptable; se debe cambiar la distancia; cambiando en pasos de
100m hasta encontrar el más óptimo. Después de cada cambio se debe repetir la prueba de ping, como los ping
de mayor tamaño y el rendimiento del enlace.
8.1.5.
Ping con mayor tamaño entre las interfaces del enlace
Un ping con mayor bytes transmitidos muestra una aproximación de la carga que puede soportar el enlace;
esto se observa en la regularidad del tiempo de transmisión de paquetes y la pérdida de éstos. Si se transmiten
1500 bytes en el enlace ejemplo, el tiempo de cada ping debe ser regular y estar alrededor de 3 a 6ms; si se
tiene una irregularidad notable por ejemplo saltos de 5ms a 20ms en varios pings, se debe seguir vigilando y
revisar el enlace. La pérdida de paquetes debe ser muy baja o casi nula comparada con la cantidad que se está
enviando en total. De la misma manera que el ping normal, esta prueba está relacionada con la distancia, el
nivel y calidad del enlace. Para esta prueba se debe hacer ping con una cantidad de unos 30 paquetes; se debe
anotar.
Si la otra interfaz responde al ping
Regularidad de los tiempos del ping.
Pérdida de paquetes
voyage: # ping 11.11.11.1 -c 50 -s 1500
PING
1528
1528
1528
1528
1528
...
1528
1528
11.11.11.1
bytes from
bytes from
bytes from
bytes from
bytes from
(11.11.11.1) 1500(1528) bytes
11.11.11.1: icmp_seq=1 ttl=64
11.11.11.1: icmp_seq=2 ttl=64
11.11.11.1: icmp_seq=3 ttl=64
11.11.11.1: icmp_seq=4 ttl=64
11.11.11.1: icmp_seq=5 ttl=64
of data.
time=1.157
time=1.117
time=1.111
time=1.113
time=1.114
ms
ms
ms
ms
ms
bytes from 11.11.11.1: icmp_seq=39 ttl=64 time=1.120 ms
bytes from 11.11.11.1: icmp_seq=40 ttl=64 time=1.106 ms
-- 11.11.11.1 ping statistics -40 packets transmitted, 40 received, 0 % packet loss, time 38991ms
rtt min/avg/max/mdev = 1.104/1.114/1.157/1.017 ms
voyage: #
8.1.6.
Medición en el rendimiento de un enlace
La prueba con ping (simple y de mayor tamaño) se hacen simultáneamente con la prueba del rendimiento;
y estas tres están relacionados directamente con la distancia configurada. Si se ha verificado el buen nivel de
señal y la poca pérdida de paquetes en el enlace; el rendimiento que se obtendrá debe estar entre 3 a 9Mbps.
Tenga en cuenta la relación que existe entre el nivel de ruido y la velocidad configurada; si se tiene un enlace
de entre 1 a 2Mbps en buen tiempo (ausencia de lluvia y neblina) se debe revisar el enlace buscando posibles
fallas o mejoras al enlace; un valor menor a 1Mbps es un enlace malo y debe mejorarse. Se recomienda realizar
la prueba por unos 50s a más y por cada AP - STA del enlace y anotar:
Rendimiento por cada intervalo de tiempo de la prueba
Rendimiento promedio al finalizar la prueba
8.1 Conectividad en enlaces AP-STA
111
nodo-b: # iperf -s
---------------------------------------Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
---------------------------------------[ 4] local 10.1.2.2 port 5001 connected with 10.1.2.1 port 2545
[ 4] 0.0-50.1 sec 8.66 MBytes 4.82 Mbits/sec
nodo-a: # iperf -c 10.1.2.2 -i 5 -t 15
---------------------------------------Client connecting to 10.1.2.2, TCP port 5001
TCP window size: 16.0 KByte (default)
---------------------------------------[ 3] local 10.1.2.1 port 2545 connected with 10.1.2.2 port 5001
[ 3] 0.0- 5.0 sec 2.88 MBytes 4.84 Mbits/sec
[ 3] 5.0-10.0 sec 2.90 MBytes 4.86 Mbits/sec
[ 3] 10.0-15.0 sec 2.87 MBytes 4.81 Mbits/sec
...
[ 3] 0.0-50.1 sec 8.66 MBytes 4.82 Mbits/sec
nodo-a: #
8.1.7.
Verificación de la tabla de rutas y la ruta de salida
Se debe revisar que las redes a las que se desea acceder estén en la tabla de rutas de los equipos que
conforman el enlace; además de la ruta por defecto si se ha configurado. En la tabla se observa las redes
accesibles y no los equipos accesibles; para esto se usa, el comando route, con él se pueden ver las redes
accesibles (Flag con UG) inclusive si se está usando OSPF. Anotar:
Si los equipos del enlace contienen todo las rutas configuradas o no.
nodo-b: # route -n
Kernel IP routing table
Destination Gateway
Genmask
10.1.4.0
10.1.3.2 255.255.255.0
10.1.53.0
0.0.0.0
255.255.255.0
10.1.52.0
0.0.0.0
255.255.255.0
10.1.55.0
10.1.3.2 255.255.255.0
10.1.54.0
10.1.3.2 55.255.255.0
10.1.2.0
0.0.0.0
255.255.255.0
10.1.3.0
0.0.0.0
55.255.255.0
0.0.0.0
10.1.2.1 0.0.0.0
nodo-b: #
Flags
UG
U
U
UG
UG
U
U
UG
Metric
0
0
0
0
0
0
0
0
Ref
0
0
0
0
0
0
0
0
Use
0
0
0
0
0
0
0
0
Iface
ath1
eth1
eth0
ath1
ath1
ath0
ath1
ath0
Si se trabaja con enrutamiento dinámico las redes accesibles aparecerán en la tabla de rutas; si alguno no
aparece se debe comprobar; quizás el problema es que ciertos enlaces estén caídos; para esto se puede usar
traceroute.
nodo-b: # traceroute 10.1.4.2
traceroute to 10.1.4.2 (10.1.4.2), 30 hops max, 40 byte packets
1 10.1.1.2 (10.1.1.2) 0.573 ms 0.593 ms 1.258 ms
2 10.1.2.2 (10.1.2.2) 4.837 ms 2.315 ms 3.682 ms
3 10.1.3.2 (10.1.3.2) 8.673 ms 4.597 ms 5.248 ms
4 10.1.4.2 (10.1.4.2) 12.935 ms 6.315 ms 7.682 ms
nodo-b: #
112
CAPÍTULO 8. VERIFICACIÓN DEL ESTADO DE LA RED DE DATOS
Si se trabaja con enrutamiento estático necesariamente se debe comprobar el acceso a la red con el comando
traceroute para verificar que la red es accesible.
Si el equipo tiene salida a Internet se debe comprobar.
nodo-b: # ping www.google.com -c 5
PING www.google.com (64.233.169.147) 56(84) bytes of data.
64 bytes from www.google.com (64.233.169.147); icmp_seq=1 ttl=244
64 bytes from www.google.com (64.233.169.147): icmp_seq=2 ttl=244
64 bytes from www.google.com (64.233.169.147): icmp_seq=3 ttl=244
64 bytes from www.google.com (64.233.169.147): icmp_seq=4 ttl=244
64 bytes from www.google.com (64.233.169.147): icmp_seq=5 ttl=244
time=96.8
time=94.8
time=96.9
time=95.2
time=96.3
ms
ms
ms
ms
ms
-- www.google.com ping statistics -5 packets transmitted, 5 received, 0 % packet loss, time 4000ms
rtt min/avg/max/mdev = 94.866/96.034/96.918/0.849 ms
nodo-b: #
8.1.8.
Ping a todas las interfaces de red
Una vez revisado las rutas, se debe hacer ping (con una cantidad de 20 paquetes) desde cada equipo que
conforma el enlace hacia el resto de las interfaces de la red y observar:
Si a todos se llega correctamente o no.
Anotar además posibles retardos o pérdida de paquetes hacia una interfaz en particular para
su revisión posterior cuando se esté en ese nodo.
8.2.
Conectividad en una red troncal
Al hacer estas pruebas es probable que existan demasiadas pérdidas de paquetes; se debe tener en cuenta
el tiempo (lluvias, neblinas en zonas alejadas) y la gran distancia entre cada par de nodos de la troncal, es
recomendable realizar la prueba en tiempos buenos, en todo el tramo de la red. El gráfico de abajo muestra una
red troncal típica; la prueba se realiza desde los routers ubicados en los extremos de la troncal.
Figura 8.3: Enlace Troncal
8.2 Conectividad en una red troncal
8.2.1.
113
Ping a todas las interfaces de red
Se debe hacer ping desde uno de los extremos de la troncal hacia el resto de las interfaces de la red y
observar si a todos se llega correctamente o no; debe anotar además posibles retardos o pérdidas de paquetes
hacia una interfaz en particular para su revisión posterior cuando se visite ese nodo. Anotar:
Si es accesible a la interfaz o no
Observar si existe demasiada pérdida de paquetes.
8.2.2.
Medición del rendimiento de la troncal
Se espera tener un rendimiento de 1 a 2Mpbs; dependerá del número de enlaces que exista; pero aunque
se tenga muchos enlaces conectados un rendimiento menor a 1Mpbs seria muy bajo para el funcionamiento
correcto de los servicios de la red. Se recomienda realizar la prueba del rendimiento con el iperf con un
tiempo total de unos 50s a más; tal como la se muestra en el cálculo del rendimiento de un enlace. Se debe
anotar:
Rendimiento observado por cada intervalo de tiempo de la prueba.
Rendimiento promedio al finalizar la prueba.
114
CAPÍTULO 8. VERIFICACIÓN DEL ESTADO DE LA RED DE DATOS
9
Con guración de una red de Telefonía IP con Asterisk
9.1.
Configuración inicial
Si se va ha usar asterisk en un equipo donde exista OSPF se debe poner el nombre del equipo también en
/etc/hosts.
voyage: # cat /etc/hosts
127.0.0.1
localhost
127.0.1.1
voyage
Para activar el servicio en el arranque del sistema se debe poner en yes la variable RUNASTERISK en el
archivo /etc/default/asterisk.
voyage: # vim /etc/default/asterisk
# This file allows you to alter the configuration of the Asterisk
# init.d script
#
RUNASTERISK=yes
voyage: #
Es recomendable cargar el módulo ztdummy; descomentar en:
voyage: # cat /etc/modules
...
ledtrig-heartbeat
ledtrig-timer
#zaptel
#ztdummy
voyage: #
Esto permitirá que se cargue después de un reinicio; pero si se desea que se cargue en este momento se
puede hacer:
voyage: # modprobe ztdummy
115
116 CAPÍTULO 9. CONFIGURACIÓN DE UNA RED DE TELEFONÍA IP CON ASTERISK
9.2.
Configuración básica de Asterisk
El Asterisk en la Voyage, (/etc/asterisk/modules.conf), está adaptado para realizar tareas mínimas, al ser un equipo de bajo rendimiento para este tipo de aplicación.
Se ha desarrollado una configuración básica para realizar la comunicación entre clientes SIP de un mismo Asterisk y con clientes SIP administrados por otros Asterisk y además permitir la comunicación con la
red de telefonía pública; esta configuración involucra a los archivos sip.conf, extensions.conf, y
iax.conf, todos éstos ubicados en /etc/asterisk/. Se puede tomar esta configuración como plantilla
para una configuración particular. Recuerde que los comentarios en estos archivos de configuración empiezan
con ; al inicio de la línea.
9.2.1.
Configuración de los clientes SIP
El archivo /etc/asterisk/sip.conf tiene una configuración inicial para clientes SIP; donde se
puede especificar los identificadores del cliente y los codecs a usar.
[general]
;
bindport=5060
disallow=all
allow=ulaw
allow=g726aal2
allow=gsm
allow=ilbc
allow=g726
;
[210]
type=friend
host=dynamic
language=es
context=center
secret=passwd
username=210
callerid=210
dtmfmode=rfc2833
qualify=yes
;
Para configurar clientes SIP con puerto FXO, se puede usar la identificación 10; cambiado sólo lo necesario.
[10]
type=friend
port=5061
host=dynamic
language=es
context=center
secret=passwd
username=10
callerid=10
dtmfmode=rfc2833
qualify=yes
;
9.2 Configuración básica de Asterisk
9.2.2.
117
Programación de las llamadas telefónicas
En /etc/asterisk/extensions.conf es donde se configura la comunicación telefónica. En la
parte [globals] se especifica las variables usadas, aquí se muestra variables que representan la IP de los
otros Asterisk de la red.
[globals]
;
IP-SERVER200=
IP-SERVER300=20.20.20.13
IP-SERVER400=
IP-SERVER-PSTN=
PHONE-DEFAULT=
La variable PHONE-DEFAULT= contiene el teléfono que responderá por defecto después de escuchar el
IVR en una llamada proveniente del exterior.
En la parte (center) se especifica con que equipos se tendrá comunicación; está divido en: comunicación
con equipos locales, con equipos de otros Asterisk y con la telefonía pública
Aquí se muestra una especie de prueba de llamado al servidor, se especifica un número que identifique al
servidor Asterisk.
;prueba de llamada al servidor
exten =>200,1,Macro(call-svlocal,200)
;
Aquí se especifica los números telefónicos locales.
;llamar area local
exten =>210,1,Macro(dial-svlocal,SIP,${EXTEN})
exten =>211,1,Macro(dial-svlocal,SIP,${EXTEN})
;exten =>_21[0-9],1,Macro(dial-svlocal,SIP,${EXTEN})
Para comunicarse con otros servidores se especifica la numeración telefónica de estos, se puede usar rangos
como en este caso; además debe poner la IP del Asterisk que administra este rango de números telefónicos; como se observa esto se hace en base a variables por ejemplo IP-SERVER300 donde su valor estará en la sección
de variables.
Para la comunicación con la telefonía pública se especifica los números permitidos; tenga en cuenta que se
debe diferenciar de los números telefónicos usados en la red; a veces se usa un prefijo; en este caso se antepone
un cero, si se desea llamar al 147 sería 0147, si se desea una comunicación sin restricción se puede usar _0.
En el cuadro de abajo se muestran los comandos para comunicarse con la telefonía pública para el Asterisk
donde se va a registrar al cliente SIP que va ha conectar la telefonía IP con la telefonía pública. En la primera
parte se muestra los números permitidos para llamar a la telefonía pública y la segunda parte se muestra al identificador 11 que se usará para identificar todas las llamadas entrantes de la telefonía pública; como se observa,
están redirigidas al IVR.
;llamar a clientes de otros servidores
exten =>_3[0-5]X,1,Macro(dial-svred, $IP-SERVER300, ${EXTEN})
exten =>_4XX,1,Macro(dial-svred, $IP-SERVER400, ${EXTEN})
En el cuadro de abajo se muestran los comandos para un Asterisk que no registre al equipo que une a la
telefonía IP con la telefonía pública; en este caso el Asterisk deberá comunicarse con el Asterisk que registre a
este equipos que une ambas redes.
118 CAPÍTULO 9. CONFIGURACIÓN DE UNA RED DE TELEFONÍA IP CON ASTERISK
;exten =>0147,1,Macro(dial-svred,$IP-SERVER-PSTN,${EXTEN})
exten =>_0.,1,Macro(dial-svred,$IP-SERVER-PSTN,${EXTEN})
9.2.3.
Identificación de direcciones IP de los servidores Asterisk
Si un Asterisk tiene que establecer comunicación con otro Asterisk que está en un equipo que posee varias
IP, se debe elegir la IP de la interfaz que está más próxima entre la comunicación de ambos Asterisk. Abajo
se muestra las IP que contendría cada Asterisk en extensions.conf para comunicarse con el resto de los
Asterisk.
Figura 9.1: Identificación de direcciones IP de los servidores Asterisk
9.2.4.
Grabación de archivos de sonido
Para hacer archivos se sonido del tipo gsm, se puede usar la función implementada en /etc
/asterisk/extensions.conf; para esto se llama al 170; después de escuchar el beep se procederá a
grabar por el teléfono hasta que se presione el símbolo #; después se escuchará lo grabado y terminará la llamada.
;grabacion de archivos de sonido gsm
exten =>170,1,Macro(sounds-record,gsm)
;
Los archivos serán grabados en /root/ con el nombre de mensaje-pbx-X.gsm donde X cambiará (0, 1, 2
...) según se vaya grabando; cambien de nombre y según su uso deberá ser guardado en
/var/lib/asterisk/sounds/es/.
9.2.5.
Configuración de IVR básico
El IVR se utiliza para contestar y direccionar las llamadas entrantes provenientes de la telefonía pública; esto está en /etc/asterisk/extensions.conf. Se debe especificar los archivos de sonido para el saludo
correspondiente; xivr_bienvenido_pucp contiene un saludo presentando a la institución; xivr_opciones_pucp
contiene la opción de esperar para que sea respondido por algún cliente SIP; xnumero_incorrecto contiene el
mensaje de “numero incorrecto” Los archivos de sonido en español deben estar en /var/lib/asterisk/
sounds/es/. Además se debe especificar en la variable PHONE-DEFAULT el número telefónico que deberá
contestar si no se elige un teléfono válido. En la parte final se especifica los números telefónicos al que puede
acceder el llamante de la red de telefonía pública.
9.3 Registro de los clientes SIP
119
;ivr basico
;
(ivr)
;
exten =>s,1,Set(CHANNEL(LANGUAGE)=es)
exten =>s,2,Background(xivr_bienvenido_pucp)
exten =>s,3,Background(xivr_opciones_pucp)
exten =>s,4,Set(TIMEOUT(digit)=3)
exten =>s,5,Set(TIMEOUT(response)=9)
exten =>t,1,Goto(center,${PHONE-DEFAULT},1)
exten =>i,1,Set(LANGUAGE()=es)
exten =>i,2,Playback(xnumero_incorrecto)
exten =>i,3,Goto(s,3)
;
exten =>_2XX,1,Goto(center,${EXTEN},1)
exten =>_3XX,1,Goto(center,${EXTEN},1)
exten =>_4XX,1,Goto(center,${EXTEN},1)
;
9.2.6.
Comunicación con otros servidores Asterisk
El archivo /etc/asterisk/iax.conf se utiliza para la comunicación con otros Asterisk no es necesario que se edite; posee una configuración general; si se hace cambios en este se debe tener en cuenta que estos
cambios deben estar reflejados en /etc/asterisk/extensions.conf.
[general]
;
bindport=4569
language=es
disallow=all
allow=ulaw
allow=g726aal2
allow=gsm
allow=ilbc
allow=g726
;
[iaxuser]
type=user
username=iaxuser
callerid=iaxuser
secret=passwd
context=center
;
9.3.
Registro de los clientes SIP
Una vez configurado los archivos se comprobará el registro de los clientes y el funcionamiento del Asterisk.
Se utilizará el script /etc/init.d/asterisk para iniciar y detener el Asterisk.
nodo-b: #
nodo-b: #
nodo-b: #
/etc/init.d/asterisk start
/etc/init.d/asterisk stop
/etc/init.d/asterisk restart
Para correr el Asterisk
Para detener el Asterisk
Para reiniciar el Asterisk
En este caso se inicia la ejecución del Asterisk; para observar el estado del registro de los clientes y del
propio Asterisk se debe acceder a entorno CLI del Asterisk.
120 CAPÍTULO 9. CONFIGURACIÓN DE UNA RED DE TELEFONÍA IP CON ASTERISK
nodo-b: # asterisk -vvvvr
== Parsing '/etc/asterisk/asterisk.conf': Found
== Parsing '/etc/asterisk/extconfig.conf': Found
Asterisk 1.2.13, Copyright (C) 1999 - 2006 Digium, Inc. and others.
Created by Mark Spencer <[email protected]>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'show warranty'for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it
under certain conditions. Type 'show license'for details.
=========================================================================
Connected to Asterisk 1.2.13 currently running on nodo-b (pid = 7834)
Verbosity is at least 4
nodo-b*CLI>
nodo-b*CLI>sip show peers
Name/username
Host
Dyn Nat ACL Port
Status
10/10
(Unspecified)
D
0
UNKNOWN
211/211
(Unspecified)
D
0
UNKNOWN
210/210
(Unspecified)
D
0
UNKNOWN
nodo-b*CLI>
Dentro del CLI con el comando sip show peers se puede observar si los clientes se han registrado;
en el mensaje de arriba mostrado en la última columna se observa que los tres clientes están con el mensaje
UNKNOWN por tanto no están registrados si aparece OK entonces si estarán registrados.
Si ya se ha configurado los clientes SIP se debe comprobar su registro en el Asterisk.
nodo-b*CLI>
- Registered SIP '210át 10.1.52.3 port 5060 expires 3600
- Saved useragent "Linksys/SPA3102-3.3.6(GW)"for peer 210
- Registered SIP '10át 10.1.52.3 port 5061 expires 3600
- Saved useragent "Linksys/SPA3102-3.3.6(GW)"for peer 10
nodo-b*CLI>sip show peers
Name/username
Host
Dyn Nat ACL Port
Status
10/10
10.1.52.3
D
5061
OK (12 ms)
211/211
(Unspecified)
D
0
UNKNOWN
210/210
10.1.52.3
D
5060
OK (13 ms)
3 sip peers (2 online , 1 offline)
Se observa que los clientes 10 y 210 están ya registrados. Para salir del CLI sólo se hace exit.
nodo-b*CLI>exit
Executing last minute cleanups
nodo-b: #
Si se modifica los archivos de configuración para cargar ésta nueva configuración en el Asterisk se hace:
nodo-b*CLI>reload
Pero mejor quizás sea detener el Asterisk y de nuevo cargarlo así:
nodo-b*CLI>stop now
Executing last minute cleanups
nodo-b: # /etc/init.d/asterisk start
Debe asegurarse que el Asterisk esté activo; para esto se puede usar ps -le | grep asterisk si arroja resultado entonces el Asterisk está corriendo; sino no lo está. Si por cualquier motivo no se puede ejecutar
9.4 Verificación del estado de telefonía IP con Asterisk
121
el Asterisk entonces se debe ejecutar con la opción:
nodo-b:: # asterisk -vvvvc
...
...
Asterisk Ready.
*CLI>
En la Voyage-GTR el Asterisk corre como root. Con esto se observará la carga de cada módulo del Asterisk,
si uno de ellos falla nos lo mostrará; si la falla es grave no continuará con la carga del Asterisk y se detendrá
en el primer error grave; si todo está correcto se llegará al CLI del Asterisk, con esto se tendrá asegurado que
la falla no es debido a la carga de algún módulo; si aún hay fallas se debe seguir observando los mensaje que
aparecerán en el CLI.
Si todo está bien; se sale del CLI, pero como en este caso se ha ingresado al CLI con la opción -c, entonces
no se podrá usar el comando exit, para esto se debe detener el Asterisk y cargar de nuevo así:
*CLI>stop now
nodo-b: # /etc/init.d/asterisk start
No olvide que debe comprobar de nuevo que el Asterisk esté cargado o activo.
9.4.
Verificación del estado de telefonía IP con Asterisk
9.4.1.
Estado del registro de clientes y tono en los teléfonos
En el cuadro de abajo se observa el registro de los equipos clientes telefónicos 10 y 210; porque aparece
OK en Status. El tiempo de registro de los equipos telefónicos deberá ser menor a 50ms; si se tiene un tiempo
mayor se debe evaluar instalar un servidor en la misma red del equipo cliente. Anotar:
Que equipos están registrados
El tiempo de registro de los clientes telefónicos
nodo-b*CLI>sip show peers
Name/username
Host
Dyn Nat ACL Port
10/10
10.1.52.4
D
5061
211/211
(Unspecified)
D
0
210/210
10.1.52.3
D
5060
3 sip peers (2 online , 1 offline)
Status
OK (12 ms)
UNKNOWN
OK (13 ms)
Los equipos telefónicos deben dar tono una vez descolgado el auricular.
9.4.2.
Llamada de prueba al servidor de telefonía IP
Se debe realizar una llamada de prueba al servidor Asterisk, además se debe observar el resultado de ésta
llamada en el CLI del Asterisk la correcta ejecución de los comandos:
122 CAPÍTULO 9. CONFIGURACIÓN DE UNA RED DE TELEFONÍA IP CON ASTERISK
voyage-112*CLI>
- Executing [200@center:1] Macro("SIP/210-081b0fb8", çall-svlocal|200") in new stack
- Executing [s@macro-call-svlocal:1] Set("SIP/210-081b0fb8", ÇHANNEL(language)=es") in new stack
- Executing [s@macro-call-svlocal:2] Playback("SIP/210-081b0fb8", "xservidor") in new stack
- <SIP/210-081b0fb8>Playing 'xservidor'(language és')
- Executing [s@macro-call-svlocal:3] SayDigits("SIP/210-081b0fb8", "200") in new stack
- <SIP/210-081b0fb8>Playing 'digits/2'(language és')
- <SIP/210-081b0fb8>Playing 'digits/0'(language és')
- <SIP/210-081b0fb8>Playing 'digits/0'(language és')
- Executing [s@macro-call-svlocal:4] Wait("SIP/210-081b0fb8", "1") in new stack
- Executing [s@macro-call-svlocal:5] Hangup("SIP/210-081b0fb8", ) in new stack
== Spawn extension (macro-call-svlocal, s, 5) exited non-zero on 'SIP/210-081b0fb8ín macro 'call-svlocal'
== Spawn extension (center, 200, 1) exited non-zero on 'SIP/210-081b0fb8'
voyage-112*CLI>
9.4.3.
Llamada de prueba a un cliente local
Se debe realizar una llamada de prueba a un cliente administrado por el mismo servidor Asterisk al que se
está evaluando, además se debe observar el resultado de ésta llamada en el CLI. Anotar:
Si se realiza sin problemas una llamada de prueba con un cliente local.
Codec utilizado en la conversación.
Calidad en la conversación.
voyage-112*CLI>
voyage-112*CLI>
- Executing (210@center:1) Macro("SIP/211-b7200470", "dial-svlocal|SIP|210") in new stack
- Executing (s@macro-dial-svlocal:1) Dial("SIP/211-b7200470", "SIP/210|26") in new stack
- Called 210
- SIP/210-081b0fb8 is ringing
- SIP/210-081b0fb8 answered SIP/211-b7200470
- Native bridging SIP/211-b7200470 and SIP/210-081b0fb8
voyage-112*CLI>
voyage-112*CLI>
voyage-112*CLI>sip show channels
Peer
User/ANR
Call ID
Seq (Tx/Rx) Format
Hold
Last Message
20.20.20.199
210
1a234c1f236 00103/00000 0x4 (ulaw)
No
Tx: ACK
20.20.20.113
211
355739771-5 00102/00011 0x4 (ulaw)
No
Tx: ACK
2 active SIP channels voyage-112*CLI>
voyage-112*CLI>
voyage-112*CLI>core show channels
Channel
Location
State
Application(Data)
SIP/210-081b0fb8 (None)
Up
AppDial((Outgoing Line))
SIP/211-b7200470 s@macro-dial-svlocal Up
Dial(SIP/210|26)
2 active channels
1 active call
voyage-112*CLI>
voyage-112*CLI>
== Spawn extension (macro-dial-svlocal, s, 1) exited non-zero on 'SIP/211-b7200470ín macro 'dial-svlocal'
== Spawn extension (center, 210, 1) exited non-zero on 'SIP/211-b7200470'
voyage-112*CLI>
9.4.4.
Llamada de prueba al resto de servidores de telefonía IP
Se debe realizar una llamada de prueba a los otros servidores Asterisk y observar en el CLI de ambos
Asterisk la correcta ejecución de los comandos. Anotar:
Si se realiza sin problemas una llamada de prueba al resto de los servidores de telefonía de la red.
9.4 Verificación del estado de telefonía IP con Asterisk
123
voyage-112*CLI>
- Executing (300@center:1) Macro("SIP/210-081b0fb8", "dial-svred|20.20.20.13|300") in new stack
- Executing (s@macro-dial-svred:1) Dial("SIP/210-081b0fb8", ÏAX2/iaxuser:[email protected]/300|28")
in new stack
- Called iaxuser:[email protected]/300
- Call accepted by 20.20.20.13 (format ulaw)
- Format for call is ulaw
- IAX2/20.20.20.13:4569-9518 answered SIP/210-081b0fb8
- Hungup ÍAX2/20.20.20.13:4569-9518'
== Spawn extension (macro-dial-svred, s, 1) exited non-zero on 'SIP/210-081b0fb8ín macro 'dial-svred'
== Spawn extension (center, 300, 1) exited non-zero on 'SIP/210-081b0fb8'
voyage-112*CLI>
voyage*CLI>
- Accepting AUTHENTICATED call from 20.20.20.112:
>requested format = ulaw,
>requested prefs = (ulaw),
>actual format = ulaw,
>host prefs = (ulaw|g726),
>priority = mine
- Executing Macro(ÏAX2/20.20.20.112:4569-16325", çall-svlocal|300") in new stack
- Executing Set(ÏAX2/20.20.20.112:4569-16325", "LANGUAGE()=es") in new stack
- Executing Playback(ÏAX2/20.20.20.112:4569-16325", "xservidor") in new stack
- Playing 'xservidor'(language és')
- Executing SayDigits(ÏAX2/20.20.20.112:4569-16325", "300") in new stack
- Playing 'digits/3'(language és')
- Playing 'digits/0'(language és')
- Playing 'digits/0'(language és')
- Executing Wait(ÏAX2/20.20.20.112:4569-16325", "1") in new stack
- Executing Hangup(ÏAX2/20.20.20.112:4569-16325", ) in new stack
== Spawn extension (macro-call-svlocal, s, 5) exited non-zero on ÍAX2/20.20.20.112:4569-16325ín macro
'call-svlocal'
== Spawn extension (macro-call-svlocal, s, 5) exited non-zero on ÍAX2/20.20.20.112:4569-16325'
- Hungup ÍAX2/20.20.20.112:4569-16325'voyage*CLI>
9.4.5.
Llamada de prueba a un cliente administrado por otro servidor
Se debe realizar una llamada de prueba a un cliente remoto que sea administrado por otro Asterisk; anotar
si esto se realiza sin problemas, comentar sobre la calidad de la conversación; además se debe observar en el
CLI de ambos Asterisk si la comunicación se realiza con el codec configurado, si los comandos se ejecutan
correctamente. Se debe realizar llamado a todos, si es necesario. Anotar:
Si se realiza sin problemas una llamada de prueba con un cliente administrado por otro servidor.
Codec utilizado en la conversación.
Calidad de la conversación.
voyage-112*CLI>
- Executing (310@center:1) Macro("SIP/210-081b0fb8", "dial-svred|20.20.20.13|310") in new stack
- Executing (s@macro-dial-svred:1) Dial("SIP/210-081b0fb8", ÏAX2/iaxuser:[email protected]/310|28")
in new stack
- Called iaxuser:[email protected]/310
- Call accepted by 20.20.20.13 (format ulaw)
- Format for call is ulaw
- IAX2/20.20.20.13:4569-11764 is ringing
- IAX2/20.20.20.13:4569-11764 stopped sounds
- IAX2/20.20.20.13:4569-11764 answered SIP/210-081b0fb8
voyage-112*CLI>
voyage-112*CLI>
voyage-112*CLI>core show channels
Channel
Location
State
Application(Data)
IAX2/20.20.20.13:456 (None)
Up
AppDial((Outgoing Line))
SIP/210-081b0fb8
s@macro-dial-svred:1 Up
Dial(IAX2/iaxuser:[email protected]
2 active channels
1 active call
voyage-112*CLI>
voyage-112*CLI>
voyage-112*CLI>sip show channels
Peer
User/ANR
Call ID
Seq (Tx/Rx) Format
Hold
Last Message
20.20.20.199
210
1208132620- 00101/00051 0x4 (ulaw)
No
Rx: ACK
1 active SIP channel
124 CAPÍTULO 9. CONFIGURACIÓN DE UNA RED DE TELEFONÍA IP CON ASTERISK
voyage-112*CLI>
voyage-112*CLI>
- Hungup ÍAX2/20.20.20.13:4569-11764'
== Spawn extension (macro-dial-svred, s, 1) exited non-zero on 'SIP/210-081b0fb8ín macro 'dial-svred'
== Spawn extension (center, 310, 1) exited non-zero on 'SIP/210-081b0fb8'
voyage-112*CLI>
voyage-112*CLI>
voyage*CLI>
- Accepting AUTHENTICATED call from 20.20.20.112:
>requested format = ulaw,
>requested prefs = (ulaw),
>actual format = ulaw,
>host prefs = (ulaw|g726),
>priority = mine
- Executing Macro(ÏAX2/20.20.20.112:4569-1642", "dial-svlocal|SIP|310") in new stack
- Executing Dial(ÏAX2/20.20.20.112:4569-1642", "SIP/310|26") in new stack
- Called 310
- SIP/310-0817d6c8 is ringing
- SIP/310-0817d6c8 answered IAX2/20.20.20.112:4569-1642
voyage*CLI>
voyage*CLI>
== Spawn extension (macro-dial-svlocal, s, 1) exited non-zero on ÍAX2/20.20.20.112:4569-1642'
in macro 'dial-svlocal'
== Spawn extension (macro-dial-svlocal, s, 1) exited non-zero on ÍAX2/20.20.20.112:4569-1642'
- Hungup ÍAX2/20.20.20.112:4569-1642'
voyage*CLI>
voyage*CLI>
10
Caso de Estudio: Red Napo Sur
10.1.
Generalidades
El presente documento presenta la memoria técnica de los trabajos de instalación y puesta en operación de
los sistemas de comunicación de voz y datos del Proyecto “Mejora de las condiciones de salud de la población
materno-infantil a través del uso apropiado de las Tecnologías de la Información y las Comunicaciones (TIC)
en centros y puestos de salud del Río Napo (Perú)” el cuál ha sido financiado por el Ayuntamiento de Madrid
y ejecutado por la Fundación EHAS y el Grupo de Telecomunicaciones Rurales de la Pontificia Universidad
Católica del Perú (GTR-PUCP).
El proyecto fue ejecutado en los distritos de Punchana, Mazán y Napo, en la provincia de Maynas, departamento de Loreto. Contempló la interconexión de cinco establecimientos de salud rurales, el Vicariato de San
José del Amazonas (donde existe un albergue de reposo para los pacientes y sus familiares que son referidos al
Hospital Regional de Loreto para atenciones especializadas en la ciudad de Iquitos), la oficina de Radiofonía
de la Dirección Regional de Salud y los ambientes de Emergencia del Hospital Regional de Loreto. Adicionalmente esta nueva red ha sido interconectada con la red instalada por el proyecto PAMAFRO que incluyó a
once establecimientos de salud. A la fecha el objetivo ha sido cumplido en su totalidad. Con los sistemas de
comunicación de voz y datos operando se está contribuyendo a la reducción de la morbi-mortalidad Materno
Infantil en esta zona rural aislada del Perú.
Figura 10.1: Departamento de Loreto (izquierda) y Provincia de Maynas (derecha).
125
126
10.2.
CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR
Descripción General de la Red de Comunicaciones
El Proyecto contempló la instalación de sistemas de comunicaciones de voz y datos en los ambientes del
Hospital Regional de Loreto, Planta de Ventas PetroPerú y Vicariato (Distrito de Punchana); CS Mazán y PS
Huamán Urco (Distrito de Mazán); y PS Tuta Pishco, PS Negro Urco y PS Tacsha Curaray (Distrito de Napo).
En la siguiente tabla se muestra los datos georeferenciales de los establecimientos de salud que fueron
beneficiados con la instalación del sistema de transmisión de voz y datos:
Ítem
01
02
03
04
05
06
07
08
Establecimiento
Emergencia HRL
Radiofonía DISA Loreto
Vicariato
CS Mazán
PS Huamán Urco
PS Tuta Pishco
PS Negro Urco
PS Tacsha Curaray
Latitud
3∘ 43’33.85”
3∘ 43’32.78”
3∘ 43’34.13”
3∘ 29’51.70”
3∘ 19’07.10”
3∘ 06’35.00”
3∘ 01’14.20”
2∘ 48’48.00”
Longitud
73∘ 15’09.44”
73∘ 15’15.49”
73∘ 14’29.50”
73∘ 05’29.70”
73∘ 13’04.30”
73∘ 08’19.00”
73∘ 23’26.80”
73∘ 32’27.00”
Altura (msnm)
105
105
105
115
116
106
139
115
Tabla 10.1.- Coordenadas geográficas de los establecimientos de salud.
En la siguiente figura se muestra la ubicación geográfica de los establecimientos mencionados en la
Tabla 1.
Figura 10.2: Ubicación geográfica de los establecimientos de salud.
En la siguiente tabla se muestra los datos georeferenciales de la ubicación de las torres ventadas de
los establecimientos de salud y de las instalaciones que forman parte de la red troncal del sistema
de transmisión de voz y datos:
10.2 Descripción General de la Red de Comunicaciones
Item
01
02
03
04
05
06
07
Torres y/o Soportes
Hospital Regional de Loreto
Planta de Ventas PetroPerú
Mazán
Huamán Urco
Tuta Pishco
Negro Urco
Tacsha Curaray
Latitud
3 43’33.80”
3∘ 43’32.29”
3∘ 29’59.90”
3∘ 19’07.60”
3∘ 06’31.40”
3∘ 01’23.10”
2∘ 48’47.60”
∘
127
Longitud
73∘ 15’12.17”
73∘ 14’36.25”
73∘ 05’28.00”
73∘ 13’01.90”
73∘ 08’17.50”
73∘ 23’31.50”
73∘ 32’27.20”
Altura (msnm)
105
105
109
116
106
131
135
Tabla 10.2.- Coordenadas geográficas de las torres ventadas y soportes de antenas.
En la siguiente figura se muestra la ubicación geográfica de las torres ventadas e instalaciones
mencionadas en la Tabla 2.
Figura 10.3: Ubicación geográfica de las torres ventadas.
En la siguiente tabla se detallan las distancias existentes en los enlaces de la red troncal
Ítem
01
02
03
04
05
06
Enlaces
HRL
PetroPerú
PetroPerú
Mazán
Huamán Urco
Mazán
Huamán
Tuta Pishco
Urco
Negro Urco
Tuta Pishco
Negro Urco
Tacsha Curaray
Distancia (Km)
1.11
30.23
24.52
24.93
29.74
28.58
Tabla 10.3.- Distancia de los enlaces.
En la Figura 4 se muestra el esquema de la ampliación de la red del Napo, específicamente se observa la
red troncal, los enlaces de distribución, los repetidores y las estaciones clientes.
128
CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR
Figura 10.4: Esquema de la ampliación de la red del Napo.
La red troncal a quedado formada por siete repetidores con lo cual se han establecido seis nuevos enlaces.
En el caso de los enlaces de distribución hacia los establecimientos de salud cada estación repetidora cuenta
con un cliente, salvo el caso del repetidor ubicado en el Hospital Regional de Loreto, el cuál cuenta con dos
clientes. En la siguiente figura se muestra en detalle un segmento de red.
Figura 10.5: Topología detallada de un segmento de red.
10.3 Descripción de la Red de Telecomunicaciones
129
10.3.
Descripción de la Red de Telecomunicaciones
10.3.1.
Enlaces Troncales
Haciendo uso del software Radio Mobile y los datos georeferenciales adquiridos durante la visita de estudio
de campo se diseñó cada uno de los enlaces troncales de la red inalámbrica con el objetivo de obtener el mejor
rendimiento utilizando equipos inalámbricos 802.11b para los enlaces rurales (desde Tacsha Curaray hasta
Mazán) y utilizando equipos inalámbricos 802.11a para los enlaces urbanos (desde Mazán hasta el Hospital
Regional de Loreto). Ver Tabla 4.
Luego de realizado los trabajos de instalación se han adquirido los datos georeferenciales finales de cada
estación y los resultados de las simulaciones se detalla a continuación.
Figura 10.6: Esquema de la red troncal simulada con el software de Radio Mobile.
Enlace
Establecimientos
01
HRL
PetroPerú
02
PetroPerú
Mazán
03
Huamán Urco
Mazán
Huamán
04
Tuta Pishco
Urco
Negro Urco
05
Tuta Pishco
Negro Urco
Tacsha Curaray
06
Estándar
802.11a
802.11a
802.11b
802.11b
802.11b
802.11b
Tabla 10.4.- Estándar de los enlaces de la red troncal
130
CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR
Parámetros del enlace urbano Hospital Regional Loreto – PetroPerú
Frecuencia mínima (MHz): 5180
Frecuencia máxima (MHz): 5805
Modo estadístico: Difusión: 90 % tiempo / 80 % ubicaciones / 80 % situaciones
Clima: Continental Sub-Tropical
Sistema empleado: R52H (tx: 80mW rx: -90dBm) en modo 802.11a
Tipo de antena: Directiva tipo grilla de 27dBi de ganancia
Pérdida de línea: 0.5dB
Figura 10.7: Perfil del enlace Hospital Regional de Loreto – PetroPerú.
Figura 10.8: Enlace Hospital Regional de Loreto – PetroPerú.
10.3 Descripción de la Red de Telecomunicaciones
Parámetros del enlace urbano PetroPerú – Mazán
Frecuencia mínima (MHz): 5180
Frecuencia máxima (MHz): 5805
Modo estadístico: Difusión: 90 % tiempo / 80 % ubicaciones / 80 % situaciones
Clima: Continental Sub-Tropical
Sistema empleado: R52H (tx: 250mW rx: -90dBm) en modo 802.11a
Tipo de antena: Directiva tipo grilla de 27dBi de ganancia
Pérdida de línea: 0.5dB
Figura 10.9: Perfil del enlace PetroPerú – Mazán.
Figura 10.10: Enlace PetroPerú – Mazán.
131
132
CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR
Parámetros del enlace rural Mazán – Huamán Urco
Frecuencia mínima (MHz): 2400
Frecuencia máxima (MHz): 2483
Modo estadístico: Difusión: 90 % tiempo / 80 % ubicaciones / 80 % situaciones
Clima: Continental Sub-Tropical
Sistema empleado: R52H (tx: 320mW rx: -95dBm) en modo 802.11b
Tipo de antena: Directiva tipo grilla de 27dBi de ganancia
Pérdida de línea: 0.5dB
Figura 10.11: Perfil del enlace Mazán – Huamán Urco.
Figura 10.12: Enlace Mazán – Huamán Urco.
10.3 Descripción de la Red de Telecomunicaciones
Parámetros del enlace rural Huamán Urco – Tuta Pishco
Frecuencia mínima (MHz): 2400
Frecuencia máxima (MHz): 2483
Modo estadístico: Difusión: 90 % tiempo / 80 % ubicaciones / 80 % situaciones
Clima: Continental Sub-Tropical
Sistema empleado: R52H (tx: 320mW rx: -95dBm) en modo 802.11b
Tipo de antena: Directiva tipo grilla de 27dBi de ganancia
Pérdida de línea: 0.5dB
Figura 10.13: Perfil del enlace Huamán Urco – Tuta Pishco.
Figura 10.14: Enlace Huamán Urco – Tuta Pishco.
133
134
CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR
Parámetros del enlace rural Tuta Pishco – Negro Urco
Frecuencia mínima (MHz): 2400
Frecuencia máxima (MHz): 2483
Modo estadístico: Difusión: 90 % tiempo / 80 % ubicaciones / 80 % situaciones
Clima: Continental Sub-Tropical
Sistema empleado: R52H (tx: 320mW rx: -95dBm) en modo 802.11b
Tipo de antena: Directiva tipo grilla de 27dBi de ganancia
Pérdida de línea: 0.5dB
Figura 10.15: Perfil del enlace Tuta Pishco – Negro Urco.
Figura 10.16: Enlace Tuta Pishco – Negro Urco.
10.3 Descripción de la Red de Telecomunicaciones
Parámetros del enlace rural Negro Urco – Tacsha Curaray
Frecuencia mínima (MHz): 2400
Frecuencia máxima (MHz): 2483
Modo estadístico: Difusión: 90 % tiempo / 80 % ubicaciones / 80 % situaciones
Clima: Continental Sub-Tropical
Sistema empleado: R52H (tx: 320mW rx: -95dBm) en modo 802.11b
Tipo de antena: Directiva tipo grilla de 27dBi de ganancia
Pérdida de línea: 0.5dB
Figura 10.17: Perfil del enlace Negro Urco – Tacsha Curaray.
Figura 10.18: Enlace Negro Urco – Tacsha Curaray.
135
136
CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR
10.3.2.
Características de los Equipos Instalados
10.3.2.1.
Equipos empleados en los enlaces troncales de 2.4GHz – 802.11b/g
Equipo
Fabricante
Interface
802.11b/g
Ubiquiti
Networks
Antena
Hyperlink
Technologies
Router Computadora
PC Engines
SR2 Super
Range 2
HG2424G
ALIX 2C0
Heliax
SuperFlex
Cables
Coaxiales
Cables
pigtail
Modelo
Hyperlink
Características
Interface 2.4GHz 802.11b/g mini-PCI
Chipset Atheros AR5213 MAC/BB
Potencia de transmisión real de 24dBm, +/-1dB
para una tasa de 1-24 MbpsSensibilidad para una
tasa de 5.5Mbps de -95dBm, (en estándar 802.11b)
Consumo de corriente @3.3VTransmisión:
1-24 Mbps 1300mA, +/-100mARecepción:
350mA, +/-50mA
Antena direccional
2.4GHz Banda ISM 24dBi
Peso: 3.62Kgs
233 MHz AMD Geode SC1100 CPU
128 MB SDRAM
Almacenamiento a través de una Compact Flash.
Consume alrededor de 3 a 5W con 12V DC
2 Puertos Ethernet
2 Puertos miniPCI
Sistema operativo: Pebble Linux, Voyage Linux,
AstLinux, AspisOS, iMedia Wrap Linux, etc.
El sistema operativo instalado es la
Voyage-GTR-0.4
Impedancia característica
Pérdida por metro
Conectores usados
: 50 Ω
: 0.1 dB
: N macho
Un extremo conector: UFL (Compatible con
Hirose/iPax/Mini-PCI).
Otro extremo conector: N hembra
Longitud: 20cm
Frecuencia de trabajo: 2.4GHz – 6GHz.
Atenuación: 5.38dB/metro en 6GHz
Tabla 10.5.- Características de los equipos 802.11b/g de la red troncal.
10.3 Descripción de la Red de Telecomunicaciones
10.3.2.2.
137
Equipos empleados en los enlaces troncales de 5.8GHz – 802.11a
Equipo
Fabricante
Modelo
Características
Interface 5.8GHz 802.11a/b/g mini-PCI
Chipset
Potencia de transmisión real 24dBm
Sensibilidad -90dBm @ 6Mbps
Interface
802.11a
Mikrotik
Antena
Hyperlink
Technologies
HG5827G
Mikrotik
333MHz CPU
64MB SDRAM
Consume 19W con 12V DC
RouterBoard
3 Puertos Ethernet
333
3 Puertos miniPCI
Sistema operativo:
RouterOS 3.20 Licencia nivel 4
Router Computadora
R52H
Heliax
SuperFlex
Cables
Coaxiales
Cables
pigtail
Antena direccional tipo grilla
5.8GHz Banda ISM 27dBi
Peso: 2.4Kgs
Impedancia característica
: 50 Ω
Pérdida por metro
: 0.1dB
Conectores usados
: N macho
Un extremo conector: UFL (Compatible con
Hirose/iPax/Mini-PCI).
Otro extremo conector: N hembra
Longitud: 20cm
Frecuencia de trabajo: 2.4GHz – 6GHz.
Atenuación: 5.38dB/metro en 6GHz
Hyperlink
Tabla 10.6.- Características de los equipos 802.11a de la red troncal.
10.3.2.3.
Equipos empleados en los enlaces de distribución de 2.4GHz – 802.11g
Equipos
Fabricante
Modelo
Características
Interface 2.4GHz 802.11a/b/g mini-PCI
Potencia de salida máxima en estándar g: 25dBm
Interface
inalámbrica
Mikrotik
Antenas
Hyperlink
Technologies
HG2414P-NF
2.4 GHz Banda ISM
IEEE 802.11b, 802.11g Wireless LAN
Antena Panel Yagi 14dBi
Routers
Linksys
WRT54GL
Router, posee 5 puertos Ethernet, 1 puerto Internet
y punto de acceso Wireless-G (802.11g) a 54 Mbps
R52H
Tabla 10.7.- Características de los equipos 802.11g elegidos para el enlace de distribución.
138
CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR
10.3.3.
Distribución de los equipos en los repetidores y estaciones clientes
10.3.3.1.
Distribución en los repetidores de Tacsha Curaray, Negro Urco, Tuta Pishco y Huamán
Urco (enlaces en 2.4GHz)
En la siguiente figura se muestran los equipos que se han instalado en los repetidores (enlaces troncales y de
distribución) implementados en Tacsha Curaray, Negro Urco, Tuta Pishco y Huamán Urco. En cada repetidor se
han instalado dos placas ALIX, las cuales han sido etiquetadas como ALIX n1 y ALIX n2. La placa n1 cuenta
con dos tarjetas inalámbricas: una tarjeta SR2 para enlazar con su vecino del norte y una tarjeta inalámbrica
R52H encargada de establecer el enlace con su cliente local. En el caso de la placa n2 cuenta con solo una tarjeta
inalámbrica SR2. La cuál permite el enlace con su vecino del sur. Adicionalmente en ésta placa se encuentra
instalado el servidor Asterisk local. La energía de alimentación es proporcionada por el sistema fotovoltaico.
Figura 10.19: Esquema de conexiones en una estación repetidora de los enlaces rurales (Tacsha
Curaray Negro Urco Tuta Pishco Huamán Urco).
10.3 Descripción de la Red de Telecomunicaciones
10.3.3.2.
139
Distribución en el repetidor de Mazán (enlaces en 2.4GHz y 5.8GHz)
En el repetidor de Mazán se han instalado una placa ALIX y una placa MIKROTIK. La placa ALIX cuenta
con una tarjeta inalámbrica SR2 para enlazar con el repetidor de Huamán Urco (2.4GHz) y tiene instalado el
servidor Asterisk. La placa MIKROTIK cuenta con dos tarjetas inalámbricas R52H: la primera para enlazar con
el repetidor ubicado en Planta de Ventas de PetroPerú (enlace troncal en la frecuencia de 5.8GHz) y la segunda
tarjeta para el enlace con el Centro de Salud de Mazán (enlace de distribución en la frecuencia de 2.4GHz). La
energía es proporcionada por el sistema fotovoltaico.
Figura 10.20: Esquema de conexiones de la estación repetidora de Mazán.
140
10.3.3.3.
CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR
Distribución en el repetidor de PetroPerú (enlaces en 2.4GHz y 5.8GHz)
En el repetidor de PetroPerú se han instalado una placa ALIX y una placa MIKROTIK. La única función
que cumple la placa ALIX n2 es ser el servidor Asterisk local. Los enlaces inalámbricos los administra la
placa MIKROTIK n1 mediante tres tarjetas inalámbricas R52H. Los enlaces hacia el repetidor de Mazán y el
repetidor ubicado en el Hospital Regional de Iquitos son enlaces en la frecuencia de 5.8GHz. En el caso del
enlace de distribución hacia el Vicariato de San José del Amazonas se realiza en la frecuencia de 2.4GHz. La
energía es proporcionada desde la caseta de energía ubicada en la base de la torre.
Figura 10.21: Esquema de conexiones de la estación repetidora de PetroPerú.
10.3.3.4.
Distribución en el repetidor del Hospital Regional de Loreto (enlaces en 2.4GHz y
5.8GHz)
En el repetidor del Hospital Regional de Loreto se ha instalado una placa MIKROTIK con tres tarjetas
inalámbricas R52H. El enlace con el repetidor ubicado en Planta de Ventas se realiza en la frecuencia de
5.8GHz. Y los dos enlaces de distribución uno hacia la oficina de Radiofonía de la Dirección Regional de Salud
y el segundo hacia los ambientes de Emergencia del Hospital Regional de Loreto se realizan en la frecuencia
de 2.4GHz
10.3 Descripción de la Red de Telecomunicaciones
141
Figura 10.22: Esquema de conexiones de la estación repetidora de PetroPerú.
10.3.3.5.
Distribución en las estaciones clientes (enlaces de distribución)
En la siguiente figura se muestran los equipos inalámbricos y la red LAN instalados en cada estación cliente
(enlace de distribución); el Linksys es un equipo para interiores por lo que sus antenas fueron reemplazados por
una antena panel de 14dBi para exteriores. Todos los enlaces de distribución son en la frecuencia de 2.4GHz.
En la Figura 24 se muestra en detalle los equipos instalados en cada estación cliente.
142
CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR
Figura 10.23: Esquema de conexiones en una estación cliente.
10.3.4.
Sistema de Energía y Protección Eléctrica
En cada estación rural se han instalado sistemas de energía fotovoltaica con su respectivo sistema de protección eléctrica tanto en las estaciones repetidoras como los enlaces de distribución. En las siguientes dos figuras
se muestran los esquemas de ambos sistemas con los equipos y elementos empleados.
En el caso de las estaciones ubicadas en la ciudad de Iquitos son alimentadas con energía eléctrica de la
red pública de Electro Oriente y el sistema de protección eléctrica empleado es el encontrado ya instalado
previamente en cada establecimiento.
10.3 Descripción de la Red de Telecomunicaciones
143
Figura 10.24: Esquema del sistema de energía en una estación cliente rural y de su sistema de
protección eléctrica.
Figura 10.25: Esquema del sistema de energía en una estación repetidora rural y de su sistema de
protección eléctrica.
144
CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR
Los pozos de tierra construidos en las estaciones rurales son pozos horizontales de 10m de longitud lineales
en el caso de las estaciones clientes y de 20m de longitud en forma cuadrada alrededor de la base de la torre
ventada. La sección de ambos pozos es de 50cm de ancho por 60cm de profundidad.
En el caso del repetidor ubicado en la Planta de Ventas de PetroPerú la torre ventada cuenta con su sistema
de protección eléctrica instalada y supervisada por la misma empresa. Similar caso se presenta en con el repetidor ubicado en el Hospital Regional de Loreto donde los equipos han sido aterrados al sistema de protección
eléctrica del mismo hospital.
En la siguiente tabla se detalla las lecturas de resistencia de los pozos de tierra construidos en las comunidades de Negro Urco, Tuta Pishco, Huamán Urco y Mazán.
Establecimiento
Mazán
Huamán Urco
Tuta Pishco
Negro Urco
Resistencia de los Pozos Tierra
Estación Cliente (Ω)
Estación Repetidora (Ω)
8.65
7.11
1.65
5.32
3.81
6.75
6.42
8.95
Tabla 10.8.- Medida de resistencia de los sistemas PAT.
Bibliografía
[1] B. Raman,“Digital Gangetic Plains: 802.11-Based Low-Cost Networking for Rural Areas, 2001 −
2004: A Report”, by Bhaskaran Raman, Ed., DGP Media Labs Asia Team, July 2004.
[2] Chieng, D.; Tan, S.W.; Rahim, R.; Ting, A.,“QoS Performance Analysis of Multi-Radio Multi-Hop
Wi-Fi Chain Network”, Wireless Broadband and Ultra Wideband Communications, 2007. AusWireless
2007. The 2nd International Conference on , vol., no., pp.38-38, 27-30 Aug. 2007
[3] E Brewer, M Demmer, Bowei W. Du, M Ho, M Kam, S Nedevschi, J Pal, Rabin Patra, S Surana, and K
Fall,“The case for technology in developing regions”, (2005). Computer. 38 (6), pp. 25+.
[4] Experiences in using WiFi for Rural Internet in India, Bhaskaran Raman and Kameswari Chebrolu, IEEE
Communications Magazine, Jan 2007, Special Issue on New Directions In Networking Technologies In
Emerging Economies.
[5] Francisco Javier Simó Reigadas, “Modelado y Optimización de IEEE 802.11 para su aplicación en el
despliegue de redes extensas en zonas rurales aisladas de países en desarrollo”, 2007.
http://www.ehas.org/uploads/file/difusion/academico/Tesis/TesisJSimo.
pdf
[6] Grupo de Telecomunicaciones Rurales-PUCP, “Redes Inalambricas para Zonas Rurales”, Primera
Edición, 2008
http://gtr.telecom.pucp.edu.pe/
[7] Long Distance Wireless Mesh Network Planning: Problem Formulation and Solution, Sayandeep Sen
and Bhaskaran Raman. The 16th Annual Interntional World Wide Web Conference (WWW 2007), May
2007, Banff, Canada.
[8] Long-Distance 802.11b Links: Performance Measurements and Experience, Kameswari Chebrolu,
Bhaskaran Raman, and Sayandeep Sen, 12th Annual International Conference on Mobile Computing and
145
146
BIBLIOGRAFÍA
Networking (MOBICOM), Sep 2006, Los Angeles, USA.
[9] Pablo Osuna et al., “Application of IEEE 802.11 Technology for Health Isolated Rural Environments”, Proc. IFIP WCIT, Santiago, Chile, Aug. 2006.
[10] Rabin Patra and Sergiu Nedevschi, “Design and Implementation of High Performance WiFi Based
Long Distance Networks”, 2007.
http://www.usenix.org/events/nsdi07/tech/patra.html
[11] S. Garigala. Experimental Validation of Simultaneous Operation in an 802.11 Multi-hop Mesh Network.
Master's thesis, Indian Institute of Technology, Kanpur, July 2004.
[12] S. Xua and T. Saadawi. Revealing the problems with 802.11 medium access control protocol in multi-hop
wireless ad hoc networks. Computer Networks, 38, 2002.
[13] Z. Fu, P.Zerfos, H. Luo, S. Lu, L. Zhang, and M. Gerla. The impact of Multihop Wireless Channel on
TCP Throughput and Loss. In IEEE INFOCOM, 2003.
[14] Alvarion.
http://www.alvarion.com/
[15] Asterisk.
http://www.asterisk.org/
[16] Cisco Systems.
http://www.cisco.com/
[17] HyperGain HG2424G 2.4 Ghz 24 dBi High Perfomance Reflector Grid Antenna.
http://www.hyperlinktech.com/web/hg2424g.php
[18] International Telecommunications Union - Statistics.
http://www.itu.int/ITU-D/ict/statistics/
[19] MadWifi.
http://madwifi-project.org/
[20] Mikrotik
http://www.routerboard.com/
[21] PC Engines.
http://www.pcengines.ch/
BIBLIOGRAFÍA
[22] Rad Data Communications.
http://www.rad.com/
[23] Redline Communications.
http://www.redlinecommunications.com/
[24] Software Quagga.
http://www.quagga.net/
[25] Trango Broadband.
http://www.trangobroadband.com/
[26] TIER.
http://tier.cs.berkeley.edu/
[27] Ubiquiti.
http://www.ubnt.com/
[28] Voyage-Linux.
http://linux.voyage.hk/
[29] Waverider Communications.
http://www.waverider.com/
147
148
BIBLIOGRAFÍA
Glosario
ACK Acknowledgment code.
ACPI Interfaz Avanzada de Configuración y Energía.
ADSL Asymmetric Digital Subscriber Line.
AFSK Audio frecuency-shift Keying.
ANSI American National Standards Institute.
API Application Program Interface.
ATA Analog Telephone Adapter.
API Application Programming Interface.
BER Bit Error Rate.
CA Collision Avoidance.
CCK Complementary Code Keying.
CD collision Detection.
CF Compact Flash.
CPU Central processing unit.
CRC Cyclic redundancy check.
CSMA Carrier sense multiple access.
CSQ Carrier Squelch.
D/A Digital Analogico.
DAMA Demand Assigned Multiple Access.
DHCP Dynamic Host Configuration Protocol.
149
150
DIFS Tiempo que cada estación espera una vez que detecta que el canal ha quedado libre.
DNS Domain Name Server.
DQPSK Differential-quadrature Phase Shift Keying.
DTMF Multi Frecuencia de Tono Dual.
ETSI European Telecommunications Standards Institute.
FCC Federal Communications Commission.
FCS Frame check sequence.
FEC Forward Error Correction.
FM Frequency Modulation.
FSK Frequency-shift keying.
FXO Foreign Exchange Office.
FXS Foreign Exchange Station.
GPG GNU Privacy Guard.
GPS Global Positioning System.
GSM Global System for Mobile communications.
HAL Hardware Abstraction Layer.
HF High Frecuency.
HR/DSSS High Rate/Direct-sequence spread spectrum.
IAX Inter-Asterisk eXchange protocol.
ICMP Protocolo de Mensajes de Control de Internet.
IEEE Institute of Electrical and Electronics Engineers.
IP Internet Protocol.
ISM Industrial, Scientific and Medical.
ITU International Telecommunication Union.
LAN Local Area Network.
LUF Lowest useable frequency.
MAC Media Access Control.
MIB Management Information Base, Base de Información de Gestión.
MINSA Ministerio de salud.
Glosario
Glosario
151
MUF Maximum Usable Frequency.
MVC Modelo-Vista-Control, Model-View-Controller.
NAT Traducción de Dirección de Red.
NAV Network Allocation Vector.
NIC Network Interface Card.
NTP Network Time Protocol.
OFDM Orthogonal Frequency-Division Multiplexing.
ONG Organización No Gubernamental.
PAT Puesta a tierra.
PHY Physical layer.
PIRE La máxima potencia que podamos transmitir.
PtMP punto a multipunto.
PtP punto a punto.
PTT Push-to-talk.
PWM Pulse Width Modulation.
QoS Quality of service.
RIC Repeater Interface Controller.
ROE Relación de onda estacionaria.
RRCONN Round Robin Connections.
RTPC Red Telefónica Pública Conmutada.
RTS/CTS Request to Send / Clear To Send.
S.O. Sistema Operativo.
SIFS Tiempo fijo que define la separación entre la recepción del paquete de la transmisión de su ACK en el
receptor.
SIP Session Initiation Protocol.
SMTP Simple Mail Transfer Protocol.
SNMP Simple Network Management Protocol.
SNR Signal Noise Ratio.
SREJ Rechazo selectivo de paquetes.
152
TCP Transmission Control Protocol.
TIC Tecnologías de la información y las comunicaciones.
TOS Campo de 8 bits incluido dentro de un paquete IP.
UDP User Datagram Protocol.
UHF Ultra High Frecuency.
UUCP Unix to Unix CoPy.
VHF Very High Frecuency.
VoIP Voice Over IP, Voz sobre IP.
VSAT Very Small Aperture Terminals.
WAN Widee Area Network.
WiFi Wireless Fidelity.
WiLD WiFi based Long Distance.
WiMAX Worldwide Interoperability for Microwave Access.
WLAN Wireless LAN.
Glosario