WiLDWiFi Based Long Distance

Primera Edición

Grupo de Telecomunicaciones RuralesPontificia Universidad Católica del Perú

Publicación financiada por FINCYT

Lima, Agosto 2009

WiLDWiFi Based Long Distance

Pontificia Universidad Católica del PerúGrupo de Telecomunicaciones RuralesGTR-PUCP, http://gtr.telecom.pucp.edu.pe

Edición: Daniel Carbajal, Jeffry Cornejo, José Luis Vargas, Luis Camacho, Aldo Duarte, RenzoNavarro, Yuri Pacheco.

c⃝2009, GTR-PUCPPrimera edición: Agosto 2009Hecho el Depósito Legal en la Biblioteca Nacional del Perú N o 2009-09928ISBN: 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íaFINCYT.

Los autores de este libro no se responsabilizan de los incidentes o daños que pudiera ocasionar lautilizació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 131.1. Estándares WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2. Problemática del uso de WiFi para largas distancias . . . . . . . . . . . . . . . . . . 15

1.2.1. Capa física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2.2. Capa MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.3. Uso de telefonía IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.4. Arquitectura de redes WiFi para larga distancia . . . . . . . . . . . . . . . . . . . . 19

2. Hardware y software apropiados para la construcción de routers WiFi de larga distancia 252.1. Placa SBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.1.1. Tipo de procesador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.1.2. Descripción de SBCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.1.2.1. RouterBOARD 532A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.1.2.2. RouterBOARD 333 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.1.2.3. Alix2C0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.1.2.4. Pronghorn SBC-250 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.1.2.5. Pronghorn Metro SBC Quad-Radio Wireless . . . . . . . . . . . . . . . . 30

2.1.3. Comparación de SBCs para aplicación de redes inalámbricas . . . . . . . . . . 322.2. Tarjetas de red inalámbrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.2.1. Comparación de tarjetas de red inalámbricas . . . . . . . . . . . . . . . . . . . 332.2.2. Pigtails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.2.3. Antenas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.3. Sistema Operativo Linux Voyage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.3.1. Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.4. Driver MadWifi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.4.1. HAL y OpenHAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

1

2.4.2. Ath5k y Ath9k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.4.3. Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.4.4. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.5. Quagga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3. Software PBX Asterisk 453.1. VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.2. Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.3. Protocolos VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.3.1. IAX (Inter Asterisk eXchange) . . . . . . . . . . . . . . . . . . . . . . . . . . 503.3.2. SIP (Session Initiation Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.3.2.1. Elementos del SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.3.2.2. Flujo de establecimiento de una sesión SIP . . . . . . . . . . . . . . . . . 55

3.3.3. Protocolo de Descripción de Sesión SDP . . . . . . . . . . . . . . . . . . . . . 563.3.4. Protocolos RTP/RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4. Enrutamiento Dinámico 594.1. Tipos de Enrutamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.1.1. Tabla de Enrutamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.1.2. Enrutamiento Estático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.1.3. Enrutamiento Dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.2. Enrutamiento Dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2.1. Tipos de Protocolos de Enrutamiento Dinámico: . . . . . . . . . . . . . . . . . 614.2.2. Características de los Protocolos de Enrutamiento Dinámico . . . . . . . . . . . 62

4.2.2.1. Algoritmo de enrutamiento Vector Distancia . . . . . . . . . . . . . . . . . 624.2.2.2. Algoritmo de enrutamiento de Estado Enlace . . . . . . . . . . . . . . . . 634.2.2.3. Enrutamiento con clase y sin clase . . . . . . . . . . . . . . . . . . . . . . 634.2.2.4. Convergencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.2.2.5. Balance de Carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.2.3. Métrica y distancia administrativa . . . . . . . . . . . . . . . . . . . . . . . . . 644.3. OSPF, Open Shortest Path First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.3.1. Áreas y clases de routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.3.2. Costo en OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.3.2.1. Árbol de la ruta más corta . . . . . . . . . . . . . . . . . . . . . . . . . . 684.3.2.2. Tipo de Interfaces de redes . . . . . . . . . . . . . . . . . . . . . . . . . . 684.3.2.3. Rutas externas de tipo1 y tipo2 . . . . . . . . . . . . . . . . . . . . . . . . 69

4.4. Funcionamiento de OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.4.1. Encapsulamiento de paquetes en OSPF . . . . . . . . . . . . . . . . . . . . . 704.4.2. Tipos de LSA (Link State Advertisement) . . . . . . . . . . . . . . . . . . . . 724.4.3. Estados OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5. Voyage GTR 775.1. Identificación de las aplicaciones a implementar . . . . . . . . . . . . . . . . . . . . 775.2. Configuración rápida mediante archivos de las interfaces de red (Ethernet y WiFi) . . 785.3. Configuración rápida de enrutamiento estático . . . . . . . . . . . . . . . . . . . . . 795.4. Seguridad WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.5. Enrutamiento dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.6. Telefonía IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.7. Configuración vía web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.8. Adaptación de Voyage para el trabajo en entornos rurales . . . . . . . . . . . . . . . 82

6. Configuración e Instalación de Voyage GTR 856.1. Comandos generales en Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.1.1. Comando ls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.1.2. Comando mkdir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.1.3. Comando rm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.1.4. Comando fdisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866.1.5. Comando dmesg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866.1.6. Comando lspci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866.1.7. Comando ps aux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.1.8. Comando kill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.1.9. Comando hostname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.1.10. Comando tail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.1.11. Comando ifconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.1.12. Comando ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.1.13. Comando ssh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896.1.14. Comando route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.2. Instalación de Voyage GTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896.3. Acceso inicial por puerto serial o por Ethernet . . . . . . . . . . . . . . . . . . . . . 916.4. Edición de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.5. Estructura de archivos de Voyage GTR . . . . . . . . . . . . . . . . . . . . . . . . . 926.6. Guardar archivos o carpetas de /rw . . . . . . . . . . . . . . . . . . . . . . . . . . . 936.7. Configuración previa a cualquier aplicación en Voyage GTR . . . . . . . . . . . . . 946.8. Obtención de respaldo de la configuración de las aplicaciones en Voyage GTR . . . . 956.9. Verificación del estado de Voyage GTR . . . . . . . . . . . . . . . . . . . . . . . . 95

6.9.1. Espacio ocupado y disponible . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.9.2. RAM libre y CPU desocupado en un instante . . . . . . . . . . . . . . . . . . . 966.9.3. Fecha del sistema y último reinicio . . . . . . . . . . . . . . . . . . . . . . . . 96

7. Configuración de Redes con Voyage GTR 997.1. Interfaces de Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 997.2. Configuración de las interfaces de red . . . . . . . . . . . . . . . . . . . . . . . . . 100

7.2.1. Configuración de Ethernet y de Bridge Ethernet . . . . . . . . . . . . . . . . . 1007.2.2. Configuración de las interfaces WiFi . . . . . . . . . . . . . . . . . . . . . . . 101

7.3. Configuración del enrutamiento estático, gateway y NAT . . . . . . . . . . . . . . . 1037.4. Configuración del enrutamiento dinámico con OSPF . . . . . . . . . . . . . . . . . 1037.5. Configuración del DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057.6. Configuración de interfaces WiFi y de parámetros TCP/IP mediante comandos . . . . 106

8. Verificación del Estado de la Red de Datos 1098.1. Conectividad en enlaces AP-STA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

8.1.1. Nivel de señal del enlace y relación de la calidad del enlace . . . . . . . . . . . 1098.1.2. Cantidad de clientes conectados al AP . . . . . . . . . . . . . . . . . . . . . . 1128.1.3. Corrección del alineamiento de las antenas . . . . . . . . . . . . . . . . . . . . 1128.1.4. Ping normal entre las interfaces del enlace . . . . . . . . . . . . . . . . . . . . 1158.1.5. Ping con mayor tamaño entre las interfaces del enlace . . . . . . . . . . . . . . 1178.1.6. Medición en el rendimiento de un enlace . . . . . . . . . . . . . . . . . . . . . 1178.1.7. Verificación de la tabla de rutas y la ruta de salida . . . . . . . . . . . . . . . . 1188.1.8. Ping a todas las interfaces de red . . . . . . . . . . . . . . . . . . . . . . . . . 119

8.2. Conectividad en una red troncal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1198.2.1. Ping a todas las interfaces de red . . . . . . . . . . . . . . . . . . . . . . . . . 1198.2.2. Medición del rendimiento de la troncal . . . . . . . . . . . . . . . . . . . . . . 120

9. Configuración de una red de Telefonía IP con Asterisk 1219.1. Configuración inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1219.2. Configuración básica de Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

9.2.1. Configuración de los clientes SIP . . . . . . . . . . . . . . . . . . . . . . . . . 1229.2.2. Programación de las llamadas telefónicas . . . . . . . . . . . . . . . . . . . . . 1239.2.3. Identificación de direcciones IP de los servidores Asterisk . . . . . . . . . . . . 1249.2.4. Grabación de archivos de sonido . . . . . . . . . . . . . . . . . . . . . . . . . 1259.2.5. Configuración de IVR básico . . . . . . . . . . . . . . . . . . . . . . . . . . . 1259.2.6. Comunicación con otros servidores Asterisk . . . . . . . . . . . . . . . . . . . 125

9.3. Registro de los clientes SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1269.4. Verificación del estado de telefonía IP con Asterisk . . . . . . . . . . . . . . . . . . 128

9.4.1. Estado del registro de clientes y tono en los teléfonos . . . . . . . . . . . . . . . 1289.4.2. Llamada de prueba al servidor de telefonía IP . . . . . . . . . . . . . . . . . . . 1289.4.3. Llamada de prueba a un cliente local . . . . . . . . . . . . . . . . . . . . . . . 1289.4.4. Llamada de prueba al resto de servidores de telefonía IP . . . . . . . . . . . . . 1299.4.5. Llamada de prueba a un cliente administrado por otro servidor . . . . . . . . . . 129

10. Caso de Estudio: Red Napo Sur 13110.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13110.2. Descripción General de la Red de Comunicaciones . . . . . . . . . . . . . . . . . . 13210.3. Descripción de la Red de Telecomunicaciones . . . . . . . . . . . . . . . . . . . . . 135

10.3.1. Enlaces Troncales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13510.3.2. Características de los Equipos Instalados . . . . . . . . . . . . . . . . . . . . . 144

10.3.2.1. Equipos empleados en los enlaces troncales de 2.4GHz – 802.11b/g . . . . 14410.3.2.2. Equipos empleados en los enlaces troncales de 5.8GHz – 802.11a . . . . . 14710.3.2.3. Equipos empleados en los enlaces de distribución de 2.4GHz – 802.11g . . 148

10.3.3. Distribución de los equipos en los repetidores y estaciones clientes . . . . . . . 14910.3.3.1. Distribución en los repetidores de Tacsha Curaray, Negro Urco, Tuta Pishco

y Huamán Urco (enlaces en 2.4GHz) . . . . . . . . . . . . . . . . . . . . . 14910.3.3.2. Distribución en el repetidor de Mazán (enlaces en 2.4GHz y 5.8GHz) . . . 15010.3.3.3. Distribución en el repetidor de PetroPerú (enlaces en 2.4GHz y 5.8GHz) . . 151

5

10.3.3.4. Distribución en el repetidor del Hospital Regional de Loreto (enlaces en2.4GHz y 5.8GHz) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

10.3.3.5. Distribución en las estaciones clientes (enlaces de distribución) . . . . . . . 15210.3.4. Sistema de Energía y Protección Eléctrica . . . . . . . . . . . . . . . . . . . . . 153

Bibliografía 157

Glosario 161

6

Introducción

Este libro es una nueva iniciativa del Grupo de Telecomunicaciones Rurales de la Pontificia Uni-versidad Católica del Perú (GTR-PUCP) para contribuir a la ampliación y difusión del conocimientoexistente sobre tecnologías apropiadas para el acceso a la información y comunicación en zonas ru-rales.

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 deFINCyT, el Fondo de Inversión en Ciencia y Tecnología, http://www.fincyt.gob.pe; una ini-ciativa del Estado Peruano para contribuir al incremento de la competitividad del país, fortaleciendolas capacidades de investigación e innovación tecnológica y promoviendo la articulación de la Em-presa, Universidad y Estado.

El libro es llamado WiLD, WiFi based Long Distance, citando un término probablemente acuñadopor TIER, Technology and Infraestructure for Emerging Regions, un grupo de investigación de laUniversidad de California en Berkeley. El término hace referencia al conjunto de soluciones para latransmisión inalámbrica de voz y datos basados en el protocolo 802.11, y cuya virtud más notable, esalcanzar enlaces de muy larga distancia (entre 50 y 100 km), mucho mayores que las distancias paralas 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 ladistribución Linux Voyage, a la cual se han añadido aplicaciones hasta obtener un sistema operativoespecífico (un firmware si se quiere). Este software desarrollado instalado sobre un hardware apropia-do, 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 seanapropiados 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ónde voz y datos en enlaces de larga distancia, tomando en cuenta que este protocolo nació como unasolución para redes LAN.

En el segundo capítulo se describen y explican el hardware y software empleados para la construc-ción de routers Voyage GTR. Todas estas herramientas están enmarcadas en el mundo del software yhardware libres.

En los capítulos tres y cuatro se narran aspectos teóricos de dos de las características más impor-tantes dentro de Voyage GTR: Telefonía IP y Encaminamiento Dinámico OSPF. Estas dos propiedadesse 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ãdidasa 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: lainstalación y configuración básica, configuración de redes cableadas e inalámbricas y la verificacióndel 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 deMaynas, región Loreto en Perú), perteneciente a la Dirección Regional de Salud de Loreto, Perú; mon-tada con routers Voyage GTR. Esta red sumada a la parte Norte (también instalada con los mismosequipos) 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 mitadde la población mundial, pese a lo cual es generalizada su casi total carencia de infraestructuras decomunicación y acceso a la información. La pretensión de dotar a estas zonas de conectividad a redesde voz y datos ha sido en los últimos años una preocupación del mayor orden de los agentes interna-cionales 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 endesarrollo suelen topar desde los primeros pasos con la ausencia de soluciones tecnológicas realmenteapropiadas, realistas y sostenibles, debido en gran parte a las siguientes características específicas deestos contextos:

No sólo se carece de infraestructuras de telecomunicación; también suele ser prácticamenteinexistente o de mala calidad la infraestructura de electrificación y, en muchos casos las víasde acceso. La necesidad de dotar a los sistemas de telecomunicación de alimentación eléctricaautónoma para garantizar su funcionamiento continuo y su durabilidad los encarece y dificultasu mantenimiento, y la ausencia de vías de acceso también encarece y dificulta tanto el de-spliegue de redes como su mantenimiento.

El personal técnico cualificado necesario para el mantenimiento y operación de estas tec-nologí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 infraestructurascaras de instalar, mantener y operar. Tampoco los estados de los países en vías de desarrolloestán en condiciones de poder subvencionar la instalación de redes de comunicaciones ruralesen pro de la cobertura total, tanto por su falta de recursos como por la enorme proporción quelas 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 mundohabitado, sino que también determina las especificaciones de cualquier solución tecnológica que sepretenda 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 novan a contar con el apoyo continuo de asesores preparados.

Tiene que requerir poco o ningún mantenimiento de técnicos especializados, ya que éstos vana estar lejos y va a resultar caro y difícil atraerlos para la resolución de los problemas. Con másrazón debe ser mínima la necesidad de administración de las redes, ya que ésta genera costesfijos considerables.

Debe ser de bajo consumo, ya que frecuentemente tendrá que depender de instalaciones deenergías fotovoltaicas o eólicas que encarecen las instalaciones y aumentan las necesidades ycostes de mantenimiento.

Debe tener costes de despliegue y de operación muy bajos. Ésto excluye las redes cableadas, lasde telefonía móvil y las redes satélite como soluciones únicas. En ocasiones se puede plantearel 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 enmuchos 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ónque persiguen determinar cuales son las tecnologías inalámbricas más apropiadas a zonas ruralesaisladas de países en desarrollo, mejorarlas y aplicarlas de forma óptima. En [6] se describen distintastecnologías propuestas para la instalación de redes de telecomunicaciones en este contexto. Todasellas son inalámbricas, ya que dadas las características descritas anteriormente, una red cableada seríamuy costosa de instalar y mantener. En el presente libro se profundizará sobre el uso de la alternativatecnológica basada en WiFi.

1Redes WiFi para largas distancias

Desde el 2001, una de las tecnologías que se ha tomado en consideración muy seriamente paralas comunicaciones de largas distancias es la IEEE802.11, popularmente llamada WiFi; si bien esteestándar no se concibió para redes extensas, sus indudables ventajas de costo, uso de frecuencias li-bres de licencia y gran ancho de banda, han despertado el interés de diversos agentes tecnológicos depaíses en desarrollo. Incluso en los núcleos urbanos de muchos países se han dado experiencias deaplicació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 productosen el mercado, casi todos ellos de bajo consumo, a precios bajos y mucha flexibilidad de uso, espe-cialmente en combinación con desarrollos de software abierto. Respecto al uso de frecuencias en loscasos en que no hay un vacío legal, la mayor parte de los estados adoptan las restricciones de la FCCen el uso de las banda ISM 2.4GHz y 5.8GHz usadas por esta tecnología. Como se puede apreciar enel Cuadro 1.1, estas normas son mucho más permisivas que las europeas y permiten realizar en laszonas rurales enlaces tanto punto a punto (PtP) como punto a multipunto (PtMP) de varias decenasde kilómetros.

Máxima potencia Dominio legal Normativatransmisible1000mW USA y muchos países en FCC 15.247

desarrollo100mW Europa ETS 300-32810 mW Japón 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 depotencia.

Velocidades desde 1 hasta 54 Mbps, siempre teniendo en cuenta que el throughput neto obtenidoestá alrededor de un 50-70 % de esos valores.

Tecnología con estándar ampliamente conocido y fácil de configurar, lo que favorece los bajoscostes 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 (laszonas rurales aisladas normalmente no siguen una distribución geométrica ordenada alrededorde un punto central).

Hardware fácilmente integrable en un sistema impermeable que soporte condiciones meteo-rológicas adversas.

Inconvenientes:

Requiere línea de vista directa (esto podría elevar, en algunos casos, el número de repetidoresnecesarios aumentando demasiado el costo).

Al ser una tecnología creada para redes de corto alcance, hay que solventar ciertos problemasrelacionadas 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 WiFiLa 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 delograr redes de área local inalámbricas (WLAN).

WiFi comparte la mayoría de su funcionamiento interno con Ethernet, sin embargo difiere enla especificación de la capa física (PHY) utilizando señales radio en lugar cable y en su capa decontrol 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 hasta54Mbps para 802.11a/g) a un precio reducido, lo presenta como una de las mejores opciones para latransmisió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 serealiza 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 detransmisió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 veloci-dades 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 detransmisión OFDM. Da soporte a velocidades de transmisión de 6Mbps a 54Mbps y ocho canalesno interferentes de 20MHz. Esta banda de frecuencia está menos saturada que la de 2.4GHz, lo cuales una ventaja, ya que la banda de 2.4GHz también es utilizada por algunos teléfonos inalámbri-cos, hornos microondas y equipos Bluetooth. El gran inconveniente de este estándar es el de no sercompatible 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 detransmisión HR/DSSS. Mediante el uso de la modulación CCK se da soporte a las velocidades detransmisión de 5.5Mbps y 11Mbps. Se cuenta con catorce canales (que pueden estar limitados a onceo trece según el país) de 22MHz, de los cuales se pueden utilizar simultaneamente hasta tres de formano interferente.

El estándar IEEE802.11g fue desarrollado a raíz del importante problema de incompatibilidadentre los equipos de IEEE802.11a y IEEE802.11b. Además, la creación de este estándar atendía alinterés en incrementar la capacidad de los equipos y redes WiFi. IEEE802.11g trabaja en la banda defrecuencia de 2.4GHz, manteniendo además los mismos canales y modulaciones de IEEE802.11b, yañ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 distanciasDado 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ísicaSin 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 deenlace. Los límites físicos de distancia alcanzable con WiFi dependerán, por lo tanto, de los siguientespará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 lalegislación que atañe a la banda de frecuencias ISM para cada región geográfica, éstas se mostraronen la Cuadro 1.1.

Además, hay algunos aspectos de la capa física que deben ser tenidos en cuenta para obtener unamayor estabilidad en el enlace:

Velocidad. El protocolo IEEE802.11 recoge distintas velocidades según el modo de funcionamien-to: 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 demodulación y codificación, de forma que cuanto mayor sea la velocidad, mayor es la poten-cia necesaria en recepción para mantener un enlace con una BER baja. Esta potencia, llamadasensibilidad, obliga a usar velocidades bajas si se quiere lograr enlaces de larga distancia conuna cierta estabilidad. La diferencia en la sensibilidad de recepción entre 1 y 11Mbps, aunquedepende de equipos, suele ser de más de 10 dB, lo cual equivale prácticamente a cuadruplicarcon 1Mbps el alcance que se tiene con 11Mbps. Si además se tiene en cuenta que la banda ISM2.4 GHz impone limitaciones en cuanto al nivel de potencia que es legal transmitir, es fácilcomprobar que para enlaces muy largos normalmente deben usarse las velocidades más bajasde 802.11b para tener estabilidad y buena calidad. La aparición de tarjetas con mejores sensibil-idades o la tecnología 802.11g pueden ayudar a lograr velocidades mayores. Así, por ejemploen el modelo de tarjeta Ubiquiti SR2 802.11b/g de 400mW, la diferencia de sensibilidad entreel 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 ve-locidad del canal a un valor fijo. La experiencia recomienda ser conservadores para soportar unacierta pérdida de prestaciones que sin duda se va a dar con el tiempo por pérdida de alineaciónde las antenas, cambios climáticos y otros factores.

Fenómenos meteorológicos. En las zonas rurales es frecuente encontrar condiciones meteo-rológicas adversas. Aunque tradicionalmente se suele decir que las lluvias influyen “de formasensible” a partir de los 10GHz, cuando los enlaces son muy largos una pequeña atenuación endB/Km acaba siendo importante. Los estudios consultados no parecen conceder mucho peso ala 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 condicionesatmosféricas y el terreno pueden producir una cierta despolarización, con lo que la recepciónde la señal empeora y su atenuación aumenta.

Interferencias. Si bien en las zonas rurales aisladas esto no suele suceder, los enlaces queconectan zonas aisladas con zonas urbanas se pueden ver afectados por este problema.

1.2.2. Capa MACAsimismo, 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 capaMAC tiene multitud de tiempos constantes definidos que tienen diferente efecto en función de ladistancia que haya entre estaciones. Estos tiempos se pueden apreciar en la Figura 1.1. Tras unarevisió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 elcá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óntransmisora 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 quecumplir que el ACKtimeout sea mayor que el tiempo de propagación de ida y vuelta más elSIFS, un tiempo fijo que define la separación entre la recepción del paquete de la transmisiónde su ACK en el receptor. No obstante, el estándar no da un valor claro a este parámetro, ylos equipos WiFi del mercado varían mucho en su implementación del ACKtimeout; algunossistemas tienen un valor por defecto de aproximadamente DIFS+SIFS pero que se puede mod-ificar, y otras tienen valores no modificables pero más grandes. DIFS es el tiempo que cadaestación espera una vez que detecta que el canal ha quedado libre. Cuando una estación intentaenviar un paquete a otra que está demasiado distante como para recibir de ella el ACK antesde que transcurra el ACKtimeout, se interpretará que la transmisión falló y se retransmitirá; co-mo lo mismo le sucede a cada retransmisión, cada paquete se retransmitirá el máximo númerode retransmisiones antes de descartarse y dejar paso al siguiente. La capa WiFi de la estacióntransmisora “creerá” que no logró mandar el paquete, pero de hecho lo probable es que hayanllegado correctamente varias copias de éste, de las que la primera se pasará a la capa superioren el receptor. El resultado es que el enlace funciona, pero con un rendimiento ínfimo debido aque todo se retransmite varias veces, por defecto 7.

Slottime. Los valores de Slottime, SIFS y DIFS imponen restricciones al funcionamiento delMAC de WiFi a partir de ciertas distancias. El estándar prevé que las estaciones que transmitenson oídas por las otras dentro del mismo slot en que se ha producido la transmisión, lo cualimpone un límite de unos 3 Km. Más allá de esa distancia, las prestaciones de los enlacesempeoran con la distancia, aunque aún resultan utilizables si el número de nodos activos essuficientemente bajo.

La vulnerabilidad con nodos ocultos. Se considera como “nodo oculto” a la situación dondeno todas las estaciones pueden escucharse, en IEEE 802.11 se emplea el mecanismo RTS/CTSpara evitar colisiones entre nodos ocultos; no obstante, ese mecanismo funciona si el cómputodel 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 quela distancia aumenta, su efectividad empeora; en enlaces PtMP con distancias del orden dekiló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 dered 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 colision-ar con un paquete cuya transmisión se inició en un slot determinado; esto tiene relativamentepoco impacto cuando la carga ofrecida es baja, pero es importante cuando el enlace está próxi-mo a la saturación, ya que en ese caso casi siempre hay un paquete listo para ser transmitido tanpronto como se considere libre el canal, y para ventanas de contención pequeñas la probabilidadde colisión será significativa. También será necesario cuidar el ajuste del ACKTimeout fijándoloa 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óntransmisora y receptora de un paquete que se han comentado para PtP, las otras estaciones queobservan pasivamente el canal esperando que se desocupe tomarán decisiones equivocadas alconsiderar el canal libre cuando no lo está. Por ejemplo, si la distancia hace que los ACK sereciban más tarde que DIFS, la estación transmisora todavía podrá esperar por el ACK si elACKTimeout es lo suficientemente grande, pero las otras estaciones cercanas a ésta que esperana que el canal se libere optarán a ocupar el canal de inmediato, pudiendo colisionar con ciertaprobabilidad con el ACK que está en camino. Por lo que hay que fijar el ACKtimeout para elenlace más largo que conforme ese PtMP.

En definitiva, WiFi puede servir, aunque con cierta pérdida de prestaciones, para enlaces PtP delarga 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 quela 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, aplicandoprotocolos de VoIP para el envío de tramas y señalización. Mediante el uso de este protocolo, la redpermite el acceso a servicios de telefonía local (entre establecimientos de la misma zona) de formagratuita en las redes WiFi, y conexión con la RTPC con ciertas restricciones de llamadas salientes (lasllamadas entrantes no tendrán ningún límite). Además, tiene la capacidad de habilitar servicios adi-cionales 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 dedatos (LAN, WAN) basadas en protocolos TCP/IP. El objetivo de utilizar las redes de datos para latransmisió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 establec-imientos que forman parte de la red y con cualquier abonado de la RTPC. En el primer caso lasllamadas no tienen costo y la marcación es similar al caso de anexos en una empresa privada, mien-tras que para evitar problemas institucionales con temas de facturación por llamadas a números tele-fónicos de la RTPC y para evitar también problemas legales de competencia a operadoras de teleco-municación, se ha decidido que las centralitas telefónicas instaladas permitan únicamente llamadassalientes a números de tarjetas prepago.

1.4 Arquitectura de redes WiFi para larga distancia 17

1.4. Arquitectura de redes WiFi para larga distanciaTradicionalmente 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 deacceso. 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 esta-ciones (mínimo dos), se conectan entre sí de forma directa. Dicha topología suele recibir el nombrede red Ad-Hoc. En este tipo de redes las estaciones se comunican de forma directa a través del medioinalámbrico sin que medie ninguna otra. Debido a las limitaciones inherentes en el alcance de lastransmisiones 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. Enuna 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 lainformación. Dicha estación recibirá el paquete y lo reenviará siguiendo el mismo procedimiento yasí sucesivamente hasta alcanzar la estación destino. Esto implica que todos los nodos de la red van agestionar los paquetes a nivel IP. Esto introduce algo más de retardo, pero éste, así como el ancho debanda, se puede gestionar de forma muy avanzada.

Las redes Mesh además de incrementar sustancialmente el área de cobertura que puede alcanzaruna red (de límite indefinido si la distribución y densidad de las estación es adecuada) tienen la ventajade ser tolerantes a fallos, pues la caída de un nodo no implicará necesariamente la caída de la red (sepodrá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á compuestopor 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 estableci-das a lo largo de ríos amazónicos o en valles interandinos longitudinales; por ello, es la topologíamás estudiada por GTR-PUCP. Al igual que una red Mesh, esta topología también permite extendernotablemente la cobertura; a diferencia de ella, en una cadena multisalto el camino físico está plena-mente establecido, la comunicación iniciada en un nodo intermedio necesariamente debe pasar porel nodo que lo antecede o que lo precede para llegar a su destino. Tiene el obvio inconveniente quela “rotura” de algún enlace interrumpe la comunicación entre extremos, por ello es deseable que lacadena tenga más de un punto de contacto con el exterior. Eventualmente la cadena puede cerrarse yvolverse 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 compuestodel mismo equipamiento hardware, podemos establecer una diferenciación funcional de tres tipos denodos:

Estación pasarela: es una estación dotada de conectividad final a Internet y a la RTPC, permi-tiendo 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 esque no se disponga más que de una. El uso de más de una implica el uso de encaminamien-to dinámico. Estas estaciones frecuentemente tendrán que desempeñar funciones como NAT ocortafuegos.

Repetidor: los distintos repetidores se unen formando la red troncal que se encarga de conmutarlas comunicaciones con otras estaciones.

Estación cliente: se encuentra en los puntos de servicio a usuarios. Suele tener conectado unacomputadora y un teléfono IP.

Además es importante distinguir entre enlaces troncales y enlaces de distribución. Los enlacestroncales constituyen la columna vertebral de la red, interconectan a todos los nodos repetidores y ala estación pasarela, transportan el tráfico combinado de varios clientes. Los enlaces de distribuciónpermiten 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 im-plica que un extremo de este enlace es un router que tiene una interfaz inalámbrica de red que secomporta como STA estación “final” (sin importar que en esta topología el enlace podría estar enmedio de la cadena) y en el otro extremo hay otro router con una interfaz que se comporta comopunto de acceso AP. Para lograr la comunicación a lo largo de toda la cadena, el router usado en cadanodo debe poseer por lo menos dos, y típicamente tres interfaces de red inalámbrica, lo que es equiv-alente a tener igual número de radios. En la figura 1.4 puede verse como cada una de estas interfacesse 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 ellosno 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 enla que se distinguen todos sus componentes, nótese que posee dos radios, de 400 y 80 mW.

1. Placa Alix 7. Pigtail uFL-N macho2. Caja de exterior metálica impermeable 8. Cable de energía3. Memoria CF de 512MB 9. Cable de red cruzado4. Tarjeta inalámbrica SR2 (400mW) 10. Prensa estopa5. Tarjeta inalámbrica CM9 (80mW) 11. Prensa estopa6. Pigtail uFL-N macho

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 semontan en la cima de torres elevadas. Cada antena se conecta con una interfaz de red inalámbrica deun 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 latorre 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 21

Figura 1.6: Esquema de una estación repetidora.

22 CAPÍTULO 1. REDES WIFI PARA LARGAS DISTANCIAS

2Hardware 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 conotras redes, de cualquier tipo. En el mercado actual existen muchas soluciones y formas de equipamien-to para un router inalámbrico WiFi. La mayoría de ellas son soluciones propietarias diseñadas paraenlaces interiores ó para enlaces exteriores de distancia media (alrededor de 30 km). En una soluciónpropietaria, el fabricante guarda reserva sobre el hardware y software del equipo, solo brinda la infor-mación suficiente para la configuración de los mismos.Por otro lado, ninguno de los modelos propietarios disponibles en el mercado posee todos los requi-sitos necesarios para su uso en zonas rurales, tales como:

Bajo consumo. El dimensionado de los paneles solares es proporcional al consumo energéticode los diferentes componentes que conforman el router. En este sentido es importante que elhardware usado tenga un consumo reducido.

Bajo coste. No se pueden implementar soluciones de un alto costo que no sean sostenibles enel 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 compactoposible.

Robusto ante condiciones meteorológicas adversas. Ya que el router se suele instalar en zonasde selva y alta montaña es necesario que tenga cierta robustez en cuanto a condiciones extremasde temperatura y humedad.

Tipo de procesador. El router debe contar con un procesador lo suficientemente potente parapoder 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 repetidoren 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 tipode interfaces. Entre otras las dos más importantes son: una interfaz serie a través de la cual

23

24CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN

DE ROUTERS WIFI DE LARGA DISTANCIA

poder acceder al router para labores de configuración y mantenimiento, y al menos una inter-faz Ethernet para conectar otros dispositivos de red (por ejemplo un teléfono IP). También esrecomendable 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 routercuente 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 seralimentada a través de PoE (Power over Ethernet).

Disponibilidad de watchdog. Se recomienda la existencia de un watchdog hardware que permitareiniciar la placa cuando ésta se bloquee.

Disponibilidad de compra en el medio/largo plazo. Este requisito resulta especialmente im-portante, ya que es necesario asegurar de alguna manera que el hardware seleccionado va aseguir siendo distribuido en el medio y largo plazo. Son más que recomendable tener posiblesalternativas 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 cumplirtodos 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 compatiblescon equipos de otros fabricantes, debido a que realizan modificaciones en el acceso al medio pre-visto en el protocolo 802.11. Finalmente nada desdeñables son los problemas que pueden surgir alseleccionar 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 evitaresos riesgos. Por ello, en paralelo al surgimiento de las iniciativas para realizar enlaces WiFi de largadistancia, aparecieron en el mercado hardware, tales como placas SBC, tarjetas de red inalámbrica yotros insumos con los cuales se podía armar un router WiFi por un precio generalmente menor ó mu-cho 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 “amedida” (instalable en poco espacio de disco, para hardware específico) y drivers para tarjetas de redinalá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 modelosde tarjetas de red inalámbrica, placas SBC y accesorios. Por supuesto, también se puede armar routerspara uso en ambientes externos y muy agrestes, lo cuál depende de contar con una adecuada caja deintemperie.

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 dejarde 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 decircuito impreso (PCB, printed circuit board). Ellas incluyen microprocesador, memoria RAM, puer-tos de entrada y salida. No suelen incluir puertos para teclado y monitor, pues su fin no es trabajarcomo computadora de escritorio, sino servir para un propósito específico como puede ser un dispos-itivo 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 insertardiscos 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 conprocesadores sin FPU (http://en.wikipedia.org/wiki/Floating_point_unit, �oatingpoint unit) y a la vez son de distintos tipos, lo que depende del fabricante; pero estos procesadoresestán optimizados para manejar todo los procesos referentes a redes de datos (manejo de números en-teros) como el Intel IXP425 Network Processor; aunque existen métodos para que estos procesadoressin FPU manejen procesos de punto flotante (por ejemplo la ejecución de procesos de servidores As-terisk) los tiempos de operación son mucho más lentos comparados con los procesadores que poseenFPU. Como existen distintos tipos de estos procesadores existen también muchos sistemas operativosoptimizados para cada tipo; por lo que los fabricantes de hardware además desarrollan también elsistema operativo para sus placas y algunos de ellos son propietarios; pero existen sistemas operativoslibres (especialmente desarrollados en base a Linux) que manejen una familia específica de estosprocesadores.

26CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN

DE ROUTERS WIFI DE LARGA DISTANCIA

Los procesadores que sí poseen FPU como el AMD Geode LX700, mantienen compatibilidadcon la arquitectura x86; específicamente este procesador es del tipo genérico, y no está optimiza-do para las redes de datos sino que puede manejar este tipo de procesos y otros como si fuera unprocesador x86 para equipos de escritorio o servidores; pero sólo limitado por la velocidad de proce-samiento. En este caso existen muchos sistemas operativos libres (en base a Linux, FreeBSD, NetB-SD, OpenBSD) y propietarios que manejen arquitecturas compatibles con x86; y a la vez son sistemasgenéricos; la gran ventaja con usar sistemas libres es que se puede adicionar o quitar aplicaciones quesean convenientes a nuestro trabajo. Al tener FPU se puede trabajar aplicaciones de alto nivel comopor ejemplo el servidor Asterisk (http://www.asterisk.org/) que es una PBX software paraimplementar redes de VoIP.

2.1.2. Descripción de SBCs2.1.2.1. RouterBOARD 532A

http://www.routerboard.com/rb500.htmlEs 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 tarjetasadicionales) 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 inconve-niente por que no se podrá adicionar o cambiar aplicaciones particulares; pero existe la posibilidad deinstalar otro sistema operativo no propietario no sólo en su memoria integrada sino que al poseer unaranura par CF se puede instalar otro sistema operativo sin perder el sistema propietario.

Figura 2.2: RouterBOARD 532A

2.1 Placa SBC 27

2.1.2.2. RouterBOARD 333

http://www.routerboard.com/pdf/rb333b.pdfEs 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 granventaja de manejar tres interfaces inalámbricas miniPCI de alta potencia, además, al igual que laplaca anterior viene con el sistema operativo RouterOS instalado.

Figura 2.3: RouterBOARD 333

2.1.2.3. Alix2C0

http://www.pcengines.ch/alix2c0.htmEs 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 quecon modificaciones soportará interfaces inalámbricas de alta potencia. Al ser un sistema x86 se tienela gran facilidad de trabajar con las distintas aplicaciones de redes conocidas de alto nivel.

Figura 2.4: Alix2C0

28CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN

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 sistemaoperativo pero se le puede instalar el que ofrece el mismo fabricante u otro porque posee una ranurapara CF. Es una placa que suministra más corriente a las interfaces miniPCI comparados con las otrasde 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 interfacesinalámbricas miniPCi de alta potencia, sin embargo justamente esta última característica hace de-seable la prueba de esta placa. Sus características son similares al Pronghorn SBC-250; pero ademásposee herramientas para manejar tarjetas WiMax.

Figura 2.6: Pronghorn Metro SBC Quad-Radio Wireless

2.1 Placa SBC 292.

1.3.

Com

para

ción

deSB

Csp

ara

aplic

ació

nde

rede

sina

lám

bric

as

Equ

ipo

Proc

esad

orR

amde

lTi

pode

Puer

tos

Puer

tosm

iniP

CI

Alim

enta

ción

Prec

ioR

efer

enci

ade

lsi

stem

aal

mac

enam

ient

oE

ther

nets

apro

x.($

)si

stem

aop

erat

ivo

Free

scal

eR

oute

rBO

AR

DM

PC83

21,

64M

B64

MB

inte

grad

a3

3tip

o|||A

/|||B

,12

a28

VD

C,

180

Mik

roT i

kR

oute

rOS

333

266.

333

MH

z,pa

raal

tapo

tenc

iafu

ente

de25

Wno

FPU

Free

scal

eR

oute

rBO

AR

DM

PC83

43E

,64

MB

64M

Bin

tegr

ada

y2

3,so

port

a4

tipo

|||A/||

|B,

10a

56V

DC

,24

5M

ikro

T ik

Rou

terO

S60

026

6,40

0,53

3,ra

nura

sde

CF

1000

Mbp

spa

raal

tapo

tenc

iafu

ente

de35

Wha

bilit

ado

Mhz

, no

FPU

enm

ayo

AM

DG

eode

2,no

men

cion

aA

lix2C

0L

X70

0,43

312

8MB

1ra

nura

CF

2al

tapo

tenc

ia,p

ero

7ha

sta

20V,

116

iMed

iaA

LIX

Lin

ux60

0M

hz,p

osee

seha

ceca

mbi

osfu

ente

de15

WVo

yage

Lin

uxFP

Upa

raal

tapo

tenc

iaM

ikro

T ik

Rou

terO

SA

MD

Geo

de2,

nom

enci

ona

net4

826-

48SC

1100

,233

128M

B25

6MB

de1

4tip

o|||A

,no

pero

6a

28V

DC

,20

0Vo

yage

Lin

ux60

0M

hz, p

osee

Com

pact

FLA

SHm

enci

ona

alta

fuen

tede

15W

FPU

inte

grad

apo

tenc

iaA

MD

2,no

men

cion

ane

t452

6-30

Ela

nSC

520,

64M

B25

6MB

de1

4tip

o|||A

,no

pero

6a

20V

DC

,15

0Vo

yage

Lin

ux60

013

3Mhz

,C

ompa

ctFL

ASH

men

cion

aal

tafu

ente

de10

Wpo

see

FPU

inte

grad

apo

tenc

ia2

tipo

|||A/||

|Bm

ásM

IPs3

24K

c,el

daug

hter

boar

ds6

a22

Vo

25a

Rou

terB

OA

RD

400M

Hz,

no64

MB

128M

Bin

tegr

ada

y3

RB

502

($)s

e56

VD

C(p

or20

0M

ikro

Tik

Rou

terO

S53

2AFP

U1

ranu

raC

Ftie

ne2

más

,par

aju

mpe

r),f

uent

eal

tapo

tenc

iade

24W

4,m

enci

ona

para

Pron

ghor

nIn

telX

Scal

e,al

tapo

tenc

ia,

48V

DC

(SB

C-

AD

|Lin

uxD

istr

ibut

ion

Met

roSB

CIX

P425

,533

64M

B16

MB

sold

ado

y2

cada

uno

ofre

ce48

)o24

VD

C30

0St

arO

S,L

inux

2.6,

Qua

d-R

adio

Mhz

,no

FPU

1ra

nura

CF

6.5W

,sop

orta

(SB

C-2

4)O

penW

RT,

Ikar

usO

SW

irel

ess

WiM

ax2,

men

cion

apa

raPr

ongh

orn

Inte

lIX

P425

64M

B16

MB

sold

ado

y2

alta

pote

ncia

,5V

DC

190

AD

|Lin

uxD

istr

ibut

ion

SBC

-250

533M

hz,n

o1

ranu

raC

Fca

daun

oof

rece

Star

OS,

Lin

ux2.

6,FP

U6.

5WO

penW

RT,

Ikar

usO

S

30CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN

DE ROUTERS WIFI DE LARGA DISTANCIA

2.2. Tarjetas de red inalámbricaLa elección de tarjetas WiFi se basa en parámetros tales como la potencia de transmisión, sensi-

bilidad 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/Linuxpara 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 (IntersilPrism 2.5 y Atheros), con modelos que transmiten desde 80mW hasta 600mW. Se recomienda usarcomo controladores de las interfaces inalámbricas el driver Hostap para el caso de tarjetas con chipsetIntersil 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 Hostapno permite modificar los valores anteriores, sin embargo, las tarjetas con este driver tienen un valormayor ACKtimeout, de manera que pueden ser usadas con prestaciones aceptables en enlaces largosde 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 Potencia máx Conector antena Sensibilidad Corrienteen g en dbm en a en dbm

SR2 g 26 @ 1-24Mbps - 1 U.FL y 1 MMCX 6 Mbps -94 dBm 1.112 Mbps -91 dBm

R52H ag 26 @ 6Mbps 26 @ 6Mbps 2 U.FL 6 Mbps -90dBm ag 0.8SR5 a - 26 @ 6-24Mbps 1 U.FL y 1 MMCX 6 Mbps -94 dBm 1.3

12 Mbps -91 dBmXR2 g 28 @ 1-24Mbps - 1 U.FL y 1 MMCX 6 Mbps -94 dBm 1.3

12 Mbps -91 dBmXR5 a - 28 @ 6-24Mbps 1 U.FL y 1 MMCX 6 Mbps -94 dBm 1.8

12 Mbps -91 dBmEMP ag 27 @ 6-24Mbps 22 @ 6-24Mbps 2 U.FL 6 Mbps -90 dBm a 1

-8602+S 6 Mbps -92 dBm gWLM54A a - 26 @ 6-24Mbps 1 U.FL y 1 MMCX 6 Mbps -90 dBm a 1.5

-26dbmWLM54G g 30 @ 6-24Mbps - 1 U.FL y 1 MCX 6 Mbps -90 dBm g 1.5

-6B-30

Cuadro 2.1: Comparación de tarjetas inalámbricas para WiFi de larga distancia.

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

32CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN

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. PigtailsLos 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 otroextremo los pigtails tienen conectores N hembra o macho. Dado que los conectores UFL y MMCXson sumamente pequeños, los pigtails están fabricados con cables coaxiales muy delgados de muchaatenuació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. AntenasLas 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, ycon distintas características ambientales de los lugares donde se han instalado, se utilizan multitud demodelos de antenas en función de estos requerimientos.

34CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN

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 delmercado. Dentro de esta marca y dado que las antenas siempre se instalan a la intemperie, se eligen losmodelos específicos para exteriores. A partir de aquí la elección de la antena depende de la ganancianecesaria de la misma para poder realizar el enlace y de la frecuencia en la que se va a realizar. Estosdatos se obtienen durante la etapa de diseño de la red. Es importante resaltar que los precios de lasantenas aumentan con su ganacia, por lo que un ajuste fino, en lo que a ganancia se refiere, puedesuponer 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 24dBi (Figura 2.15(b)), la antena de panel HG2418P de 14dBi, y las sectoriales HG2414SP-120 y la HG2414SP-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 laposibilidad de instalarle un radome, que la dota de mayor aerodinamicidad, fundamental en lugaresmuy ventosos (Figura 2.15(a)), la antena de grilla HG5827G de 27 dBi y la de panel HG5819P de 19dBi (Figura 2.15(c)).

NOTA: Las antenas de grilla tanto de 2.4 GHz como de 5.8 GHz tienen unas abrazaderas un tantodébiles, por lo que en zonas de mucho viento se recomienda emplear un método de sujeción adicional.

2.3. Sistema Operativo Linux VoyageLinux 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 almace-namiento 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ísticasLas 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 tomandosolo 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 delmanejo 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 MadWifiEl 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 chipsetAtheros. El proyecto tiene 3 líneas de trabajo: Madwifi, Ath5k y Ath9k. Madwifi es estable y funcionacorrectamente. Los drivers Ath5k y Ath9k que también están siendo desarrollados por el proyectoMadwifi no dependerán del HAL de Atheros, sin embargo, por el momento se debe preferir Madwifisi se requiere una red inalámbrica estable. Madwifi posee licencia BSD/GPL, sin embargo el HAL sedistribuye bajo licencia del fabricante, en binario y como código cerrado. En el proyecto Madwifi sehan seguido las siguientes etapas:Madwifi-old: El término “old” se refiere al driver madwifi liberado en Noviembre del 2005. Estedriver 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 del2005 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 OpenHALEl 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 requerimientosde control de frecuencias y nivel de potencia han sido señaladas cómo requerimiento indispensablepara dispositivos inalámbricos en la FCC (Federal Communications Commission), y además estosmecanismos no deban ser fácilmente vulnerables. Sin embargo, a pesar de todas estas considera-ciones Atheros liberó su HAL bajo la licencia ISC (Internet Systems Consortium) lo cuál permitesu uso en cualquier proyecto de software libre. Los chipset Atheros pueden ser usados en un ampliorango de frecuencias (frecuencias licenciadas y frecuencias no licenciadas). Por ese motivo el HALes distribuido solo en forma de binario para que usuarios no autorizados no puedan modificarlo tanfácilmente y sin embargo la comunidad de software libre pueda interactuar mediante él de un modopermitido. Una de las características más resaltantes del HAL Atheros es que se puede adecuar a lascaracterí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 comoobjetivo reemplazarlo. Está basado en ar5k. Más información acerca de OpenHAL en http://

36CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN

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 componentedel driver que se comunica directamente con el hardware.

2.4.2. Ath5k y Ath9kEl 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 tarjetasde red inalámbricas Atheros, está basado en Madwifi y OpenHAL, por lo tanto no requiere del HALde Atheros. Se encuentra alojado en el repositorio wireless-2.6. Por el momento trabaja en modo Ad-hoc, Cliente y Mesh Point. Debido a que no depende del HAL de Atheros está proyectado que a largoplazo reemplace a Madwifi y supere sus características.El driver Ath9k fué inicialmente desarrollado por Atheros. Atheros después liberó su código paraque la comunidad de software libre continúe su desarrollo. Soporta las características disponibles en802.11n. Está disponible en el kernel linux desde la distribución 2.6.27.

2.4.3. CaracterísticasMadwifi 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 defectosi es que no se elige algún modo de trabajo. El dispositivo actuará como una estación cliente deuna red inalámbrica.

Ap (Access point). También conocido como master. El dispositivo trabaja como un punto deacceso 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 (me-diante: 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. Estosignifica que una sola interfaz física puede funcionar de distintos modos (sta, ap, repetidor, etc). Sinembargo 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 paraincrementar el ancho de banda y distancias de alcance de los dispositivos Atheros. Se pueden citar lassiguientes:

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 cantidadde datos incrementando el ancho de banda.

Fast Frame: Característica no soportada por todos los AP. Permite enviar mayor información encada 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 medi-ante el algoritmo de Lempel Ziv. Una vez que la característica es habilitada, la compresión ydescompresión se ejecuta dentro del chipset Atheros.

Turbo Mode: Característica no soportada por todos los AP. Permite que se transmita por 2canales, ofreciéndose así un doble ancho de banda. Es beneficioso solo si todas las estacionesde 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 modoturbo, 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 modoturbo 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 porincremento de la sensibilidad del receptor de hasta -105dBm. Adicionalmente se agregan nuevastasas 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 direc-ciones independientes.

38CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN

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 compat-ibles 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 en-rutamiento para sistemas Unix como NetBSD, FreeBSD, Solaris y Linux. Quagga esta bajo la licen-cia de GNU/General Public License (GPL). Actualmente proporciona versiones de código libre delos protocolos OSPF, RIP y BGP.

2.5 Quagga 39

La arquitectura de quagga consiste de un demonio (programa que siempre esta corriendo) centralllamado 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 delenrutamiento 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ónde más protocolos, clientes y demonios.

Figura 2.16: Arquitectura de Quagga

40CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN

DE ROUTERS WIFI DE LARGA DISTANCIA

3Software 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 viajea través de redes TCP/IP. Esto significa que se envía la señal de voz en forma digital en paquetes enlugar de enviarla (en forma digital o analógica) a través de circuitos utilizables sólo para telefoníacomo 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únmentereferidos como protocolos de Voz sobre IP. El tráfico de Voz sobre IP puede circular por cualquier redTCP/IP, incluyendo aquellas conectadas a Internet.

VoIP es el conjunto de normas, dispositivos, protocolos, en definitiva la tecnología que permite latransmisión de la voz sobre el protocolo IP. Telefonía sobre IP es el conjunto de nuevas funcionali-dades de la telefonía, tradicional debido a los servicios que se pueden ofrecer gracias a poder enviarla 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 Codecsque garanticen la codificación y compresión del audio o del video para su posterior decodificación ydescompresión antes de poder generar un sonido o imagen utilizable. Según el Codec utilizado en latransmisión, se utilizará más o menos ancho de banda y recursos del sistema de cómputo. La cantidadde ancho de banda suele ser directamente proporcional a la calidad de los datos transmitidos. Entre losCodecs 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 audiomediante muestras comprimidas en una señal digital con tasa de muestreo de 8000 muestraspor 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 muestrasen palabras de 8 bits.

∙ a-law: Usado en Europa y en el resto del mundo. Codifica cada 13 muestras enpalabras 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). Permitetrabajar con velocidades de 16, 24, 32 y 40 Kbps. Este codec proporciona una disminuciónconsiderable 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 anchode banda. Opera con tasas de 8 Kbps pero existen extensiones para tasas de 6.4 y 11.8 Kbpspara 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 mayorcarga computacional. Opera a 13.3 Kbps y 15.2 Kbps.

Speex: Implementa un algoritmo capaz de variar la velocidad de transmisión dependiendo delas condiciones actuales de la red (VBR: Variable Bit Rate). El ancho de banda puede variardesde 2.15 a 22.4 Kbps.

Actualmente no es posible garantizar la calidad de servicio sobre Internet y en cierto grado enredes LAN; por eso, se presentan diversos problemas. No es aceptable latencias (tiempo transcurridodesde 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, yaque 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. AsteriskAsterisk 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 determinadode teléfonos para hacer llamadas entre sí e incluso conectar a proveedores de VoIP y de telefoníaconvencional tanto analógica como digital. Originalmente desarrollado para el sistema operativoGNU/Linux, Asterisk actualmente también se distribuye en versiones para los sistemas operativosBSD, MacOSX, Solaris y Microsoft Windows, aunque la plataforma nativa (GNU/Linux) es la mejorsoportada de todas.

Asterisk incluye muchas características como buzón de voz, conferencias, IVR, distribución au-tomática de llamadas, y otras muchas más tal como PBX comerciales. Los usuarios pueden crearnuevas funcionalidades por medio de lenguaje script de Asterisk o añadiendo módulos escritos encualquier 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. Hastaahora; las versiones desarrolladas son la 1.6 y la 1.4. Las versiones 1.2 y 1.0 se consideran paralizadasy ya no se continuarán manteniendo. Actualmente la rama 1.4 es la aconsejada para sistemas enproducció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 (biensea 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, codi-ficando y decodificando formatos tales como G711, G729, GSM11, etc.

API de formato de ficheros Asterisk: controla la lectura y escritura de varios formatos dearchivos 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 lasdiferentes 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 muchosprotocolos 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 deinterfaces analógicos y digitales. Para la conexión con líneas analógicas se hace a través de dispos-itivos FXO y FXS. Para la conexión con líneas digitales RDSI se logra por medio de interfaces deltipo 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 convencionalescomo la telefonía pública. Para la conexión con estas líneas analógicas se hace por medio de interfacesFXS y FXO.

FXS Foreign eXchange Station: También denominada interfaz de abonado. Es el que envíala línea analógica hacia el abonado. Se trata de interfaces que permiten conectar dispositivosterminales, como un teléfono analógico convencional a un router o central de telefonía IP. Unainterfaz FXS proporciona alimentación eléctrica, señalización de llamada y tono al dispositivoterminal.

FXO Foreign eXchange Office: Es un puerto que recibe la línea analógica. Es la interfaz quepermite conectar un dispositivo terminal a un servicio de telefonía como el servicio de telefoníapú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 conectaen 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 paraconectar 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 VoIPEl 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 entiempo real de audio o cualquier otro tipo de flujo de audio/video; por lo que se han creado protoco-los para VoIP, cuyo mecanismo de conexión abarca una serie de transacciones de señalización entreterminales que cargan flujos de audio para cada dirección de la conversación.

46 CAPÍTULO 3. SOFTWARE PBX ASTERISK

3.3.1. IAX (Inter Asterisk eXchange)

IAX es uno de los protocolos utilizado por Asterisk; es utilizado para manejar conexiones VoIPentre servidores Asterisk, y entre servidores y clientes que también utilizan protocolo IAX. El proto-colo 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. Permitemanejar una gran cantidad de codecs y un gran número de flujo audio/video, lo que significa quepuede 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 finalespara señalización y datos. El tráfico de voz es transmitido in-band (se refiere a las comunicaciones quetienen lugar dentro de un método de comunicación previamente establecido), lo que hace a IAX2 unprotocolo 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 comunicacionesque tienen lugar fuera de un método de comunicación previamente establecido) para entregar la in-formación.

IAX soporta Trunking (red), donde un simple enlace permite enviar datos y señalización pormú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 paramás llamadas sin crear latencia adicional. Esto es una gran ventaja para los usuarios de VoIP, dondelas 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 devoz y vídeo a través de la red IP, con particular atención al control y a las llamadas de voz y proveyendoun soporte nativo para ser transparente a NAT. La estructura básica de IAX se fundamenta en lamultiplexació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 MultimediaSession Control)) Working Group; con la intención de ser el estándar para la iniciación, moderacióny la finalización de sesiones multimedia de dos pares (unicast) o multipares (multicast). SIP es unprotocolo genérico, es un estándar y su RFC es la 3261. SIP ofrece flexibilidad para controlar sesionesmultimedia como llamadas de voz y video, videoconferencia, mensajería instantánea; juegos online ytelefonía IP. Una sesión puede ser una simple llamada telefónica de doble vía o puede ser una sesiónde conferencia multimedia con muchas personas participando.

SIP es un protocolo de señalización orientado a conexiones end-to-end; esto quiere decir que todala 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; ladesventaja de esto es que los encabezados son mucho mayores.

SIP esta basado en arquitectura cliente-servidor similar al HTTP y el SMTP. Esta similitud esnatural 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 estrechamentecon el Protocolo SDP y coexiste junto con otros protocolos del mismo nivel y funciones, como elH323.

3.3 Protocolos VoIP 47

SIP no es protocolo de propósito general; su objetivo es ayudar a establecer y finalizar la comu-nicación. SIP se apoya de otros protocolos para lograr una llamada telefónica, una sesión de videoconferencia o mensajería instantánea; etc. Los protocolos que apoyan comúnmente son: RTSP (Real-Time Streaming Protocol) para el control de flujos y sesión, SDP (Session DescriptionProtocol) paradescribir los flujos, RTP/RTCP (Real Time Protocol / Real Time Control Protocol) para el transportede datos en tiempo real y RSVP (Resource Reservation Setup Protocol) junto a DiffServ (Differenti-ated 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 SIPhacen 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 con-versació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 vozsobre TCP/IP es que no se pueden recibir conexiones iniciadas desde el exterior; el que inicia la lla-mada desde dentro del NAT no puede escuchar a la otra parte. Si los dos comunicantes se encuentrandentro de NAT ningún flujo de audio originado detrás de los NAT llegará a su destino final. Para esteproblema ya existen soluciones implementadas en Asterisk.

48 CAPÍTULO 3. SOFTWARE PBX ASTERISK

3.3.2.1. Elementos del SIP

La configuración más simple para establecer una sesión SIP es utilizando sólo dos agentes deusuario (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. Parahacerlo 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 sonlos que emiten y procesan los mensajes del protocolo SIP. Un videoteléfono, un teléfono, un clientede software y cualquier otro dispositivo similar es un agente de usuario para SIP. El protocolo SIP nose ocupa de la interfaz de estos dispositivos con el usuario final, sólo se interesa por los mensajes queestos 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óny son UAS cuando la reciben y responden a la misma. Por esto los agentes de usuario deben imple-mentar un UAC y un UAS.

Servidores de Registro: El protocolo SIP permite establecer la ubicación física de un usuario de-terminado, 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 de-pendiente del lugar en donde el usuario está conectado (su dirección IP). Cuando un usuario inicializasu terminal (p. e. conectando su teléfono o abriendo su software de telefonía SIP) el agente de usuarioSIP que reside en dicho terminal envía una petición con el método REGISTER a un Servidor de Reg-istro, informando a qué dirección física debe asociarse la dirección lógica del usuario. El Servidor deRegistro realiza entonces dicha asociación; esta asociación tiene un período de vigencia; termina sino 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 localizajunto con el Servidor Proxy.

Servidores Proxy y de Redirección: Para encaminar un mensaje entre un agente de usuariocliente 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 deldestino o de otro servidor que lo acerque al destino. Este tipo de servidor sólo escucha peticiones yregresa 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 encaminarel mensaje ya no interviene más. Un mismo servidor puede actuar como Redirección o como Proxydependiendo de la situación.Un agente de usuario normalmente encamina todos sus pedidos hacia un servidor de su propio do-minio. Es este quien determina (por sus propios medios o valiéndose de otros servidores) las ubica-ciones 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 usuar-ios. Este servidor será el encargado de determinar la dirección física del usuario llamado. Un servidorque recibe las peticiones destinadas a un dominio específico es denominado servidor entrante (In-bound Server). Es habitual también, que exista un servidor que reciba las peticiones originadas porlos usuarios de un dominio hacia otros dominios. Este recibe el nombre de Servidor Saliente (Out-bound Server).

Mensajes SIP: Existen dos tipos básicos de mensajes SIP, peticiones y respuestas. Las solicitudesy las respuestas emplean el formato de mensaje genérico, que consiste en una línea inicial (Star – Lineo Request – Line) seguida de un o más campos de cabecera (Message Header), una línea vacía queindica 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ónpara las peticiones; mientras que el estado de la sesión para el caso de las respuestas. El encabezadocontiene información relacionado con la llamada en forma de texto; por ejemplo el origen y destinode la petición, el identificador de la llamada, etc. El cuerpo del mensaje o carga útil (payload) lleva lainformació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; incluyenel nombre del método al que invocan, el identificador del destinatario, el protocolo SIP que se estautilizando; para esto utiliza métodos y son:

Invite: Utilizado para invitar un usuario para participar en una sesión o para modificar parámet-ros.

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 deestado; 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 proce-samiento. El emisor detiene el envío de retransmisión después de recibir una petición de estetipo. 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 lanueva localización de un usuario o sobre un Proxy alterno que puede resolver satisfactoriamentealguna petición . El emisor del mensaje de petición debe reenviar su petición a otro para que supetició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 sintaxisdel mensaje, etc.

5xx: Fallos de servidor. Falla del lado del servidor. Aparentemente la petición es válida pero elProxy 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 deRed. Una transacción corresponde a una petición y todas las respuestas a esa petición. Esto quieredecir 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últiplesrespuestas finales. Las entidades SIP que almacenan el estado de las transacciones son denominadasStateful; 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álogosson identificados usando los campos Call-ID, From y To. Los mensajes con estos campos igualespertenecen al mismo dialogo. El campo CSEQ es utilizado para ordenar los mensajes en un dialo-go. De hecho el CSEQ representa el número de transacción. De forma simple se puede decir que undiá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 respuesta200 (OK). En caso de que el usuario no haya dado credenciales validas recibirá por respuesta unmensaje 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 alProxy. Este responde con TRYING (100) para detener las retransmisiones y reenvía las peticioneshacia el usuario llamado. Todas las respuestas provisionales generadas por el usuario llamado sonregresados al usuario origen. Por ejemplo RINGING (180) que es un mensaje que se envía cuando elusuario es contactado y comienza a timbrar. Una respuesta 200 (OK) es generada en cuanto el usuariollamado descuelga el auricular.

Terminación de sesión: Una sesión es finalizada cuando uno de los usuarios envía el mensajeBYE al otro extremo. El otro usuario confirma el final de la conversación enviando por respuesta unmensaje 200 (OK). La transacción para finalizar la sesión se realizará de un extremo a otro sin pasarpor 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 decontrol del tráfico o por ejemplo, cuando existe un NAT. El Proxy o los Proxy logran esto por mediode la inserción del campo RECORD ROUTE en los encabezados de los mensajes SIP.

3.3.3. Protocolo de Descripción de Sesión SDPSession 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 asociarmás de un flujo audiovisual a una misma sesión; por ejemplo en una misma sesión puede existir unflujo 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 protocoloscomo SIP, Megaco o HTTP. El transporte de información acerca de los flujos audiovisuales permitea los destinatarios participar en la sesión si ellos soportan dichos flujo. Además SDP permite la ne-gociación de los parámetros de flujo tales como la tasa de muestreo de la señal, el tamaño de lospaquetes, 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 utilizadopara transportar flujos en tiempo real (Real Media Streaming) y RTCP para monitorear la calidad delservicio, así como para transportar información acerca de los participantes en la sesión. Sus funcionesson:

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 recordarlos 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 delmismo (Checksum) para verificar integridad de los datos. RTP no posee ningún método para garanti-zar la calidad de servicio ni la entrega ordenada de paquetes. RTCP también utiliza UDP para enviarpaquetes de control hacia todos los participantes de una sesión. Los servicios que provee RTCP sonlos siguientes:

Dar seguimiento a la calidad en la distribución de los datos, así como mantener el control de loscodecs 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 dedatos.

54 CAPÍTULO 3. SOFTWARE PBX ASTERISK

4Enrutamiento Dinámico

El router es un componente importante en una red de datos; se encarga de conectar múltiplesredes entre si, por tanto, es responsable de entregar paquetes entre estas distintas redes. Los routersson computadoras que poseen CPU, memoria y un sistema operativo; y posee varias interfaces, cadauna 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 enrutamien-to.

4.1. Tipos de Enrutamiento

4.1.1. Tabla de EnrutamientoCuando 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áscarade la red remota o conectada directamente y la interfaz de salida y/o la dirección IP del router delsiguiente salto para llegar a esta red; además se incluye información adicional, como la métrica deenrutamiento y la distancia administrativa. A continuación puede verse una tabla de enrutamiento:

root@hrradiofonia-30c1: # route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface10.13.30.0 0.0.0.0 255.255.255.240 U 0 0 0 eth1200.37.75.16 0.0.0.0 255.255.255.240 U 0 0 0 vlan110.14.30.0 0.0.0.0 255.255.255.240 U 0 0 0 br010.11.0.0 10.13.30.1 255.255.240.0 UG 0 0 0 eth110.11.16.0 10.13.30.1 255.255.240.0 UG 0 0 0 eth110.14.0.0 10.13.30.1 255.255.240.0 UG 0 0 0 eth110.12.16.0 10.13.30.1 255.255.240.0 UG 0 0 0 eth110.13.16.0 10.13.30.1 255.255.240.0 UG 0 0 0 eth110.12.0.0 10.13.30.1 255.255.240.0 UG 0 0 0 eth110.13.0.0 10.13.30.1 255.255.240.0 UG 0 0 0 eth110.14.16.0 10.13.30.1 255.255.240.0 UG 0 0 0 eth10.0.0.0 200.37.75.17 0.0.0.0 UG 0 0 0 vlan1root@hrradiofonia-30c1: #

55

56 CAPÍTULO 4. ENRUTAMIENTO DINÁMICO

Cuando un router recibe un paquete, usa su tabla de enrutamiento para determinar la mejor rutapara 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 dispos-itivo en una red que está directamente conectado a una de las interfaces del router; el paquetese enviará a este dispositivo.

Redes remotas: Si la dirección IP de destino del paquete pertenece a una red remota, entoncesel 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 unared conectada o remota, y si además el router no posee una ruta por defecto, entonces el paqueteserá descartado. El router enviará un mensaje ICMP de destino inalcanzable a la dirección IPde origen del paquete.

Existen varias formas de agregar rutas:

1.- Por medio de redes directamente conectadas.2.- Por medio de rutas estáticas3.- 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 lasredes conectadas directamente; éstas son las únicas redes que se muestran en la tabla de enrutamientohasta que se configure el enrutamiento estático o dinámico. Las rutas estáticas y dinámicas no puedenexistir 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 dedestino del paquete IP para encontrar la mejor ruta en la tabla de enrutamiento y encapsula el paquetede capa 3 en una nueva trama de capa 2 y envía la trama desde la interfaz de salida; a esta funciónse le conoce como conmutación. Cada router toma su decisión en forma independiente, según lainformación de su propia tabla de enrutamiento. En este proceso es posible que el router haya recibidoel paquete encapsulado en un tipo de trama de enlace de datos, como una trama Ethernet, y ahora almomento de enviar el paquete, el router lo encapsulará en otro tipo de trama de enlace de datos detecnologí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 quelos otros routers tengan la misma información. La información de enrutamiento sobre una ruta desdeuna red a otra no suministra información de enrutamiento sobre la ruta inversa o de regreso. Dadoque los routers no necesariamente tienen la misma información en sus tablas de enrutamiento, lospaquetes pueden recorrer la red en un sentido, utilizando una ruta, y regresar por otra ruta. Esto sedenomina enrutamiento asimétrico. El enrutamiento asimétrico es más común en Internet, que usa elprotocolo de enrutamiento BGP, que en la mayoría de las redes internas.

4.1.2. Enrutamiento EstáticoEl 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áticoes una solución muy conveniente cuando la cantidad de nodos no es tan amplia. Las rutas estáticasdeben 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ámicoEl 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 deesta manera los cambios en la topología de la red. Un protocolo de enrutamiento dinámico requieremenos sobrecarga administrativa, pero en cambio consumirá parte de los recursos del router, comotiempo del CPU y ancho de banda de los enlaces. A menudo se encontrará una combinación de ambostipos 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 cambiode 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 SistemaAutónomo (AS, Autonomous System). Un AS es la subred que es administrada o gestionada por unaautoridad común, que tiene un protocolo de enrutamiento homogéneo mediante el cual intercambiainformación en toda la subred, y que posee una política común para el intercambio de tráfico con otrasredes 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 yel que se efectúa entre ASs. Al primero se le denomina enrutamiento interno; y al otro enrutamientoexterno. Dado que los requerimientos en uno y otro caso son muy diferentes, se utilizan protocolos deenrutamiento distintos. Los protocolos de enrutamiento dentro de un AS se denominan IGP (InteriorGateway Protocol), mientras que los utilizados entre AS diferentes se llaman EGP (Exterior GatewayProtocol).

IGP describe una necesidad y no el nombre de un protocolo definido. La mayoría de las redes cor-porativas operan como sistemas autónomos, aunque no estén conectados a Internet, por lo que los IGPson utilizados con abundancia. Los protocolos IGP nunca aparecen en Internet, sino que permanecenrestringidos 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 Enrutamiento dinámicoVentajas Desventajas Ventajas Desventajas

Poco procesamientodel CPU.Fácil de comprender ymantener en redespequeñas.Fácil de configurar.Se usa paraenrutamiento desde yhacia redes deconexión única.Uso de ruta pordefecto, cuando nohay una mejorcoincidencia en latabla de enrutamiento.

Configuración ymantenimientoprolongadosPropenso a errores enredes extensas.Requiere deintervención deladministrador paramantenimiento.No es adecuado pararedes en crecimientorápido.Requiere deconocimiento de todala red para suimplementación.

Menos trabajo paraagregar o quitar redes.Ajuste automáticoante cambios en latopología.Menos propenso aerrores deconfiguración.Escalable; elcrecimiento de la redusualmente no es unproblema

Requiere recursos delrouter (CPU y anchode banda del enlace).Requiere de másconocimientos para laconfiguración ysolución deproblemas.

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 cualquierenlace en la red. La distancia se define en términos de una métrica como el conteo de saltos y ladirección es simplemente el router del siguiente salto o la interfaz de salida. RIP cuenta los saltosefectuados hasta llegar al destino mientras que IGRP además utiliza otra información como el retardoy el ancho de banda.

4.2 Enrutamiento Dinámico 59

El encaminamiento de un protocolo basado en vector de distancias requiere que un router informea sus vecinos de los cambios en la topología periódicamente y en algunos casos cuando se detectaun cambio en la topología de la red. Los cambios son detectados periódicamente ya que la tablade encaminamiento de cada router se envía a todos los vecinos que usan el mismo protocolo. Unavez que el router tiene toda la información; actualiza su propia tabla reflejando los cambios y luegoinformando 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 entrelos 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 basede datos para crear el mapa de la red; seleccionar la mejor ruta y mantener una imagen de la redcompleta. De esta manera, un algoritmo SPF (Shortest Path First) como el algoritmo Dijkstra calculala 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 en-vían actualizaciones periódicas de la información de enrutamiento; éstos sólo envían actualizacionescuando 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 usandomás de una máscara de subred. Un ejemplo de este tipo es RIP v1, que no envía información de lamá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, comoparte de las actualizaciones de enrutamiento. La mayoría de las redes modernas requieren protocolossin 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 deuniformidad. 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 tienenconvergencia 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 routerrealizará un balance de carga del enlace, de manera que utiliza todos los enlaces que tienen el mismocosto (métrica) para ese destino. Se sabe que el balance de carga esta en uso, por que al mostrar la tablade enrutamiento dos o mas rutas se asociarán con el mismo destino. Esta característica dependerá dela aplicación que hace uso del protocolo de enrutamiento.

4.2.3. Métrica y distancia administrativaUna 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 debanda, carga en el tráfico de la red, confiabilidad u otro valor establecido por el administrador paraindicar 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, yunos 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 rutala 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ásbajo.

Si un router tiene dos caminos hacia la misma red, sólo se pondrá en la tabla de enrutamiento aaquella que tenga mejor métrica; la única excepción es cuando los dos caminos tienen exactamentela misma métrica; en ese caso se agregarán ambos caminos a la tabla de enrutamiento; este compor-tamiento se denomina frecuentemente ECMP (Equal Cost MultiPath). La cantidad de rutas de mismamé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 sobreuna 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 directamenteconectadas. La siguiente tabla muestra las distancias administrativas.

El protocolo de origen de la ruta que tenga menor distancia administrativa va a ser el que terminellenando la tabla de enrutamiento. Cuando en una red todos los routers ejecutan varios protocolosde enrutamiento dinámico a la vez; por ejemplo RIP y EIGRP; todas las métricas de RIP seríansignificativamente menores a las de EIGRP, por lo que equivocadamente se podría pensar que elrouter 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 61

Origen de la Ruta 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 conecta-da en la tabla de enrutamiento, y por defecto su distancia administrativa será 1. Las redes conectadasdirectamente siempre tienen un valor de distancia administrativa de 0 puesto que no existe una mejorruta que tener directamente conectada una red a una de sus interfaces.

4.3. OSPF, Open Shortest Path FirstLa 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 ysoporta máscaras de subred de longitud variable. Su complejidad es notablemente superior respectoal 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 yrá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 nuevasrutas 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, comode 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 mutua-mente es el estado del enlace. En los protocolos de estado enlace cada router dentro de la misma áreaOSPF transmite a sus vecinos paquetes LSA (Link State Advertisement) que contienen la descrip-ción de cada una de las redes conectadas directamente a ese router. Con esta información el routerconstruye 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 datoslocal llamada Link State Database (LSDB). Los routers llegan a estar sincronizados cuando todos losrouters 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 LSAhasta este punto no son consideradas como rutas; para calcular las rutas hacia cada destino el routerusa un algoritmo conocido como SPF (Shortest Path First) también se conocido con el nombre de sucreador, 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 paratodos los destinos. El algoritmo de por sí es bastante complicado. A continuación una descripciónsimple de las distintas etapas del algoritmo:

Tras la inicialización o debido a cualquier cambio en la información de enrutamiento, un routerse 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 copiaen 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 deacceso más corta para todos los destinos. El router utiliza el algoritmo de Dijkstra para calcularel camino más corto. Los puntos de destino, el costo asociado y el próximo salto para llegar aesos 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 enlaceo una red añadida o suprimida, OSPF debe estar estático. Las modificaciones que se produzcanse comunicarán a través de paquetes estado enlace; y el algoritmo de Dijkstra vuelve a calcularpara encontrar el camino más corto.

4.3.1. Áreas y clases de routersOSPF 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 enrutamientose 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 lainformación de enrutamiento y ejecutar los cálculos correspondientes a todas ellas. Al menos unrouter 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 áreascirculan siempre por el backbone, por lo tanto todas las áreas deben conectar con el backbone. Si noes 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 inundacionesy el cálculo del algoritmo de Dijkstra, en un router se limitan a cambios dentro de la zona. Todos losrouters 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 routerspueden 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 conocenlos demás routers del área y tiene la misma base de datos topológica. Sin embargo cada router tienesu 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 serealiza mediante los ABR (Area Border Router). OSPF espera que todas las áreas inyecten la infor-mació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, losrouerts necesitan normalmente apoyarse en las rutas predeterminadas para poder enviar tráfico a rutasfuera del segmento Stub.

Área Totally Stub: Es idéntica al Stub Area (no acepta LSA tipo 5); pero además no acepta rutashacia redes de otras áreas y no conoce las rutas hacia routers ASBR (LSA tipos 3 y 4). La única formade salir del área es mediante una ruta por defecto. Este tipo de área es muy útil para sitios remotoscon pocas redes y conectividad limitada con el resto de la empresa. Esta es una solución propietariade Cisco Systems.

Not-so-Stubby Area: También conocidas como NSSA, constituyen un tipo de área Stub. No acep-tan LSA de tipo 4 y 5 pero puede importar rutas externas hacia el domino OSPF como rutas externasNSSA (LSA tipo 7). En estas áreas se crean los LSA de tipo 7 que son transformados a LSA de tipo5 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 lla-mados routers de borde de area (ABR, Area Border Router). Los ABR deben mantener la informaciónque describe el backbone y las de las otras áreas adjuntas. Un router que tiene todos sus interfaces

64 CAPÍTULO 4. ENRUTAMIENTO DINÁMICO

Area Type 1 y 2 3 4 5 7

Backbone 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 co-mo gateway entre OSPF y otros protocolo de enrutamiento (IGRP,EIGRP, IS-IS, RIP, BGP, Static) uotros 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 serun 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 nece-sarios para enviar los paquetes a través de esta interfaz. El costo de una interfaz es inversamenteproporcional al ancho de banda de la interfaz. Un gran ancho de banda indica un bajo costo. Hay másgasto y retardo en un enlace de 56Kbps serial que en un 10Mbps Ethernet. La fórmula usada paracalcular 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 puedeforzar 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ízde un árbol y calcula la ruta más corta para cada destino basado sobre el costo acumulativo requeridopara llegar a ese destino. Cada router tiene su propia visión de la topología, aunque todos los routersconstruirán un árbol de camino más corto usando la misma base de datos de enlace estado. Abajo semuestra 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 conlas que se conectan a otros routers de la red. El tipo de enlace define la configuración que asume lainterfaz correspondiente. OSPF soporta redes broadcast, redes No broadcast y redes punto a punto. Eltipo de red en la que esté trabajando OSPF determinará el funcionamiento del protocolo, y este a suvez 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 diferen-cia entre ambos está en la forma en que el costo de la ruta se calcula. El costo de una ruta de tipo 2 essiempre el costo externo, independientemente de su costo en el interior para llegar a esa ruta. El costode 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 enel diagrama siguiente:

Figura 4.2: Rutas externas de tipo1 y tipo2

4.4. Funcionamiento de OSPFCuando un router arranca, primero inicializa las estructuras de datos necesarias y espera las in-

dicaciones de los protocolos de bajo nivel para indicar que sus interfaces estén operativas. El routerutiliza el protocolo Hello para descubrir sus vecinos; el router envía paquetes Hello y espera a que lesean devueltos. En redes punto a punto y broadcast se detectan los vecinos dinámicamente enviandopaquetes de saludo multicast. En las redes en la que no es posible usar broadcast será necesaria ciertainformació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 aestos routers. Una adyacencia es una relación formada entre dos routers vecinos determinados con elfin de intercambiar información de enrutamiento. No todos los pares de vecinos son adyacencias. Lasbases de datos de estado enlace se sincronizan entre pares de routers adyacentes. Cuando hay un routerDR es este el que decide que routers son adyacentes. Las adyacencias controlan la distribución de lainformació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 protocolodetectar routers caídos de forma oportuna.

Los LSA inundan el área; asegurándose que todos los routers en un área tienen la misma basede datos de estado enlace. Esta base de datos consiste en una colección de LSA originados por cadarouter perteneciente al área. De esta base de datos cada router calcula el árbol de la primera ruta máscorta (SPF, Shortest Path First) consigo mismo como raíz. Cada vez que se recibe un LSA se calculael árbol SPF mediante el algoritmo de Dijkstra y se genera una tabla de enrutamiento.

4.4.1. Encapsulamiento de paquetes en OSPFLos 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 compartenuna común cabecera. Cada paquete OSPF empieza con una cabecera de 24 bytes. Esta cabecera con-tiene toda la información necesaria para determinar si los paquetes deben ser aceptados para futurosprocesos. 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 paquetespara identificar a sus vecinos y para actualizar la información de enrutamiento.

Tipo Nombre Función1 Hello Descubrir y mantener los vecinos

Resumen del contenido de la base de datos. Describe el2 Database Descriptor (DBD) 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

3 Link State Request (LSR) mensajes se intercambian cuando un router descubreque cierta información de su base de datos está obsoleta.

4 Link State Update (LSU) Actualización de la base de datos; es la respuesta al LSR.

5 Link State Ack (LSAck) Reconocimiento de los LSU.Describen el estado local de un router o red, para un

- Link-State Advertisement router incluye el estado de las interfaces y sus adya-(LSA) cencias. 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 auna 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 CAPÍTULO 4. ENRUTAMIENTO DINÁMICO

4.4.2. 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 DescripciónSe originan en todos los routers. Describe un conjunto de estados y el

1 Router-LSA costo de interfaces de routers para un área; cada router puede gene-rar 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ónes una indicación de todos los routers conectados sobre un particular

2 Network-LSA 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 losRouters de borde área(ABR); cada uno describe una ruta hacia un

3,4 Summary-LSA destino fuera del área, aunque todavía dentro del AS. Normalmente losSummary LSA son difundidos dentro del backbone y del backbone podrápasar a otras áreas por medio de los ABR. El tipo 3 describe rutas haciaredes 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 otrosistema autónomo. Estas redes son difundidas vía redistribución. Los ASBR

5 AS-External-LSA tiene la tarea de difundir estas rutas dentro de un AS. Estos LSAs van porlas áreas estándar y backbone.

6 Group Este es una extensión Multicast OSPF (MOSPF); un protocolo deMembership LSA enrutamiento multicast que no es de uso general.

Routers NNSA no reciben External LSA de una ABR; pero permitenRouters in a Not- enviar información de enrutamiento externo por redistribución. Estos

7 so-stubby-area routers usan LSA de tipo 7 para informarles a los ABR acerca de(NSSA) 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 deotras áreas son llamados rutas Inter-Area; rutas que se originan de otros protocolos de enrutamientoy que son inyectados dentro del AS vía redistribución son llamados rutas External. Múltiples rutas almismo destino son preferidas en el orden siguiente: Intra-Area, Inter-Area, External type 1, Externaltype 2.

4.4 Funcionamiento de OSPF 69

Figura 4.5: Rutas originadas en una determinada área

4.4.3. Estados OSPFPara 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 inter-cambiado información con ningún vecino. OSPF se encuentra a la espera de pasar al siguienteestado (etapa de inicialización).

Estado de inicialización (Init): Los routers envían paquetes de tipo 1 (Hello) en intervalosregulares (por defecto 10 segundos en Quagga y en Cisco) para establecer relación con susrouters vecinos, cuando una interfaz recibe su primer paquete Hello entonces decimos que elrouter 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 es-tablecer una comunicación bidireccional con cada router vecino que está ubicado en la mismared IP. Un router entra en estado two-way en el momento que se ve en una de las actualizacionesde uno de sus vecinos. El estado two-way es la relación más básica que pueden tener los routersOSPF, pero la información de enrutamiento no se intercambia en este estado. Para aprendersobre 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, suconversación se caracteriza por una adyacencia, pero los routers todavía no tienen una adyacen-cia completa. El estado ExStart se establece utilizando paquetes de tipo 2. Entre los dos routersse utilizan paquetes Hello para determinar cual de los dos es el maestro y cual es el esclavo ensu relación y se intercambian paquetes de tipo 2.

Estado de Intercambio (Exchange): En el estado exchange se utilizan paquetes de tipo 2 paraenviar información de estado del enlace. En otras palabras, un router describen sus bases dedatos de estado del enlace a otro router. Si alguna de las rutas no está en la base de datos delenlace del router receptor de la información, este solicita una actualización completa, la cual serealiza 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 cadarouter, se tiene que solicitar una información que es más completa utilizando paquetes de tipo3. Cuando un router recibe un paquete de tipo 3, este responde con una actualización medianteun paquete de tipo 4. Los paquetes de tipo 4 describen la información de estado del enlace quees el corazón de los protocolos de enrutamiento de estado del enlace. Los paquetes de tipo 4son respondidos con paquetes de tipo 5.

Estado de adyacencia completa (Full adjacency): Cuando termina el estado Loading, losrouters están en una adyacencia completa. Cada router mantiene una lista de sus vecinos adya-centes, llamada base de datos de adyacencia.

5Voyage GTR

El Grupo de Telecomunicaciones Rurales de la PUCP ha adaptado Voyage 0.5.2 para la imple-mentación de enlaces inalámbricos WiFi de larga distancia; a esta Voyage, más sus aplicaciones adap-tadas 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 implementarVoyage (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 im-plementar redes de datos; contiene sólo lo básico; como los controladores para el manejo de lasinterfaces 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 lla-mados (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 WiFide larga distancia; a Voyage original le faltan aplicaciones para cumplir con esta tarea; haciendo unarelación entre las características comunes de los equipos comerciales, a Voyage le faltaría implemen-tar:

1. Configuración rápida y cómoda de las interfaces de red,2. Enrutamiento estático, NAT y DHCP3. Implementar seguridad WPA-PSK4. Enrutamiento dinámico5. Telefonía IP6. Configuración vía web

Estas características se ha implementado en Voyage GTR, pero además se ha tenido cuidadoen que todas estas aplicaciones trabajen conjuntamente y que Voyage GTR tenga las herramientasnecesarias para su trabajo en entornos rurales. Estas herramientas son:

71

72 CAPÍTULO 5. VOYAGE GTR

1. Administración de la memoria y del espacio de disco2. Conservación y borrado de registros de sistema (logs)3. Creación de archivos de respaldo4. Apagado, reinicio y conservación de fecha

5.2. Configuración rápida mediante archivos de las interfaces dered (Ethernet y WiFi)

Todas las configuraciones de las interfaces de red se realizan por medio de comandos; para noperder esta configuración se debe crear un script que contenga estos comandos y poder ser ejecutadosen 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 interfacesWiFi en base a los controladores madwifi.

Existe una aplicación llamada mad wifi-ifupdown que incorpora en /etc/network/interfacesvariables para poder configurar enlaces WiFi; pero esta aplicación advierte que no está garantizadosu 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 laestructura de Voyage.

Se creó una plantilla en /etc/network/interfaces; para configurar las interfaces de red; estaplantilla es sólo útil para dispositivos WiFi que hacen uso del madwifi, se puede usar sólo WEP yWPA2-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 seguridadWPA-PSK en la sección del archivo mencionado, correspondiente a hostapd; y se anuló laopción de VAP en las interfaces de red.

3. en /etc/network/if-down.d/madwifi se corrigió la deshabilitación incorrecta de WPA-PSK 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 WPA-PSK en las secciones correspondiente a hostapd y a wpa_ supplicant.

5.3 Configuración rápida de enrutamiento estático 73

5.3. Configuración rápida de enrutamiento estáticoPara 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 noes práctico por lo cual se ha creado un archivo de configuración apoyado de un script para configurarlas rutas estáticas.

El archivo de configuración /etc/network/nat-static-routes será el archivo para la con-figuració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 configu-ració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ásse 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ónbásica.

5.4. Seguridad WiFiActualmente 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 quepodrían tener repentinas desconexiones, WPA sería inadecuado. Por tanto en estas redes se usará unavariante de WPA que es WPA-PSK, que no necesita servidores de autenticación y que soporta mejorlas 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 de-sarrolló plantillas para que la configuración sea ordenada y rápida. Al instalarlas se tuvo que crearcarpetas adicionales para ser adaptado a la estructura de Voyage.

Se creó archivos de configuración para hasta tres interfaces WiFi, tanto para hostapd como parawpa_ 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; paraser activados por /etc/init.d/networking.

El hostapd instalado hacía que el MTU de las interfaces WiFi sea de 2400, cambiando el valorde 1500 que se usa por defecto; esto traía problemas al implementar OSPF en estas interfaces; porqueno aceptaban un valor alto en el MTU; para esto se compiló de nuevo el hostapd modificando elcambio forzado del MTU en hostapd.h.

5.5. Enrutamiento dinámicoVoyage no trae ninguna aplicación para este caso; quagga es el software que posee las aplica-

ciones 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 plantillason: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 unaplaca ALIX; Asterisk, un servidor de Telefonía IP de código abierto, puede ser instalado en estasplacas para que realice tareas mínimas como comunicación entre usuarios telefónicos y comunicaciónentre usuarios administrados por otros Asterisk. La placa ALIX al tener un CPU y RAM reducidosestará limitado a administrar hasta unas 5 llamadas simultaneas con clientes SIP administrados porotros servidores Asterisk.

En un punto de la red que pertenezca a una zona rural no es necesario implementar servidores degran 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 instalarlase necesitó de sus dependencias y más que nada de los módulos zaptel. Al instalar Asterisk se tuvoque 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 sistemainicie.

Se ha establecido una plantilla para ser usada como ejemplo de una configuración básica. Laplaca ALIX está limitado en recursos por lo que el Asterisk no puede usar todos sus módulos, seha limitado y se ha adaptado a Voyage (/etc/asterisk/modules). Además se ha instalado losarchivos de sonido en español y se ha creado algunos archivos de sonido adicionales para el uso de laplantilla.

La plantilla desarrollada es para realizar la comunicación entre clientes SIP de un mismo Asterisky con clientes SIP administrados por otros Asterisk y además de permitir la comunicación con la redde 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; eneste caso el Asterisk no trabaja correctamente; para esto se encontró una solución que es la de ponerel nombre del equipo en /etc/hosts.

5.7 Configuración vía web 75

5.7. Configuración vía webPara 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. Es-tá 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 degran capacidad a muy bajo precio, esa limitación prácticamente ha desaparecido, pero sí sigue siendoimportante 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ónpara configuración de enrutamiento dinámico o la opción no era apropiada. A la interfaz web deVoyage 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 prin-cipal 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 seejecuta 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 queestas opciones son invocadas es configurable (revisar /etc/uya/scripts). Si se usa una distribución quenormalmente está en modo lectura (read-only) se necesitará ejecutar unos scripts que permitan realizar los cam-bios 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/interfacesEthernet(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)

*EnrutamientoEstático: /etc/quagga/daemons (deshabilitados zebra y ospfd).Dynamic routing: /etc/quagga/daemons (habilitados zebra y ospfd).Gateway y NAT: /etc/network/statics-routes-natStatic 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 ruralesVoyage 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 debeasegurar que las funciones de los servicios implementados trabajen correctamente por buen tiempo con elmínimo de mantenimiento.

Voyage es un sistema que ocupa unos 100MB en la Compact Flash (CF); por lo que la CF debe ser al menosde 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 computadorasestándares.

Voyage es un sistema que se carga en modo lectura; pero un sistema operativo por más que se cargue enmodo lectura necesita crear archivos temporales y reescribir o crear archivos. La partición donde está instaladaVoyage pertenece a la CF y se carga en modo lectura; pero existe una carpeta, la /rw, que está contenida en laRAM del sistema en un espacio delimitado (originalmente a 8MB); por tanto está en modo escritura; en esteespacio se podrá manipular archivos o carpetas que se encuentren aquí; pero al estar en RAM se perderá lainformación después de un reinicio. En /rw están ubicados especialmente los log del sistema y archivos quenecesitan 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 de0.5MB por día; este tamaño no es crítico; pero puede existir momentos en que los log crezcan rápidamente ylos 8MB dedicados para /rw puede resultar poco; por tanto se aumenta hasta 32MB. Este aumento de espaciono quiere decir que se está quitando 32MB a los 128MB de la RAM; sino que mientras se necesite espacio sepuede 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. Paraevitar 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 a5MB 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; peroes 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); sise desea tener la fecha sincronizada se deberá usar ntpdate. Se implementó scripts para conservar el tiempomientras 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) lafecha actual se pierde y al encender de nuevo, la fecha es antigua, alrededor de 1980. Existe aplicaciones quevan creando archivos o carpetas mientras el sistema arranca pero como las fuentes fueron instaladas posterioresa 1980, en la creación de estos archivos o carpetas puede existir advertencias o quizás errores. Para evitar estose desarrolló los script /etc/init.d/a-before y /etc/init.d/z-after para conservar la fechadespué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 unmomento. 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 en15 minutos es más de 12 % el sistema reiniciará; además si el sistema sólo cuenta con 1MB de RAM libre elsistema reiniciará.

Para tener un buen mantenimiento del sistema es necesario tener un respaldo, para esto se ha creado scriptsque permitan generar un respaldo de la configuración de las distintas aplicaciones; pero sin crear copia de todoel 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 llamaVoyage 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 copiara 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

6Con�guración e Instalación de Voyage GTR

6.1. Comandos generales en LinuxPara 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 lsMuestra la lista de carpetas y archivos que contiene una carpeta.

gtr-v106:/var# lsbackups cache lib local lock log mail opt run spool tmpgtr-v106:/var#

Gtr-v106: # ls-ladrwxr-xr-x 4 root root 160 Apr 8 10:22 .drwxr-xr-x 8 root root 180 Dec 31 1999 ..-rw------- 1 root root 21 Apr 7 07:28 .bash_ history-rw-r-r--- 1 root root 432 Jul 15 2008 .bashrc-rw-r-r--- 1 root root 110 Nov 10 2004 .profiledrwx------ 2 root root 60 Apr 6 07:40 .sshdrwxr-xr-x 2 root root 40 Apr 8 10:21 backup-rw-r-r--- 1 root root 0 Apr 8 10:22 configuracion.shgtr-v106:#

6.1.2. Comando mkdirSirve para crear directorios.

Gtr-v106: # mkdir backup

6.1.3. Comando rmSirve para borrar archivos o carpetas.

Gtr-v106: # rm -r carpetagtr-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 particionesencontradas en el equipo.

root@gtrdesktop: # fdisk -l

Disk /dev/sda: 160.0 GB, 160041885696 bytes255 heads, 63 sectors/track, 19457 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytesDisk identifier: 0x31b931b9

Device Boot Start End Blocks Id System/dev/sda1 * 1 3647 29294496 7 HPFS/NTFS/dev/sda2 3648 19457 126993825 5 Extended/dev/sda5 3648 7294 29294496 b W95 FAT32/dev/sda6 7295 10941 29294496 83 Linux/dev/sda7 10942 14588 29294496 83 Linux/dev/sda8 14589 14710 979933+ 82 Linux swap / Solaris/dev/sda9 14711 17142 19535008+ 83 Linux/dev/sda10 17143 19457 18595206 83 Linux

Disk /dev/sdb: 519 MB, 519192576 bytes16 heads, 63 sectors/track, 1006 cylindersUnits = cylinders of 1008 * 512 = 516096 bytesDisk identifier: 0x88a4f2af

Device Boot Start End Blocks Id System/dev/sdb1 * 1 1006 506992+ 83 Linuxroot@gtrdesktop: #

6.1.5. Comando dmesg

Muestra un mensaje de diagnóstico que contiene eventos generados en el arranque del sistema y durante ladepuración de aplicaciones.

gtr-v106: # dmesg

Linux version 2.6.23-486-voyage (2.6.23-2) (root@punknix-uml) (gcc version4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 PREEMPT Wed May 2115: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 Master00:0d.0 Ethernet controller: Atheros Communications, Inc. AR5006X 802.11abg NIC(rev 01)00:0e.0 Ethernet controller: National Semiconductor Corporation DP83815(MacPhyter) Ethernet Controller00:11.0 Ethernet controller: Atheros Communications, Inc. AR5006X 802.11abg NIC(rev 01)00:12.0 ISA bridge: National Semiconductor Corporation SC1100 Bridge00:12.1 Bridge: National Semiconductor Corporation SC1100 SMI0:12.2 IDE interface: National Semiconductor Corporation SCx200 IDE (rev 01)00:12.3 Multimedia audio controller: National Semiconductor Corporation SCx200Audio00:12.5 Bridge: National Semiconductor Corporation SC1100 XBusvoyage: #

6.1.7. Comando ps aux

Comando que muestra información acerca de los procesos que se ejecutan en el equipo.

voyage: # ps auxUSER PID%CPU%MEM VSZ RSS TTY STAT START TIME COMMAND...root 1801 0.0 0.4 2172 580 ? S<s Apr02 0:02 udevd -daemonroot 2937 0.0 0.4 1752 612 ? Ss Apr02 2:16 /sbin/wpa_ supplicant-B -P /var/run/wpa_ supplicant.ath0.pdaemon 3020 0.0 0.2 1680 352 ? Ss Apr02 0:00 /sbin/portmaproot 3109 0.0 0.4 1624 612 ? Ss Apr02 0:03 /sbin/syslogdroot 3115 0.0 0.2 1576 376 ? Ss Apr02 0:00 /sbin/klogd -xroot 3247 0.0 1.2 4720 1620 ? Ss Apr02 0:22 /usr/lib/postfix/masterpostfix 3255 0.0 1.3 4764 1704 ? S Apr02 0:01 qmgr -l -t fifo -uroot 3256 0.0 0.4 1736 556 ? Ss Apr02 0:00 /usr/sbin/pptpdquagga 3275 0.0 0.7 2636 944 ? Ss Apr02 0:01 /usr/lib/quagga/zebra-daemon -A 127.0.0.1quagga 3279 0.0 1.0 3268 1368 ? Ss Apr02 7:54 /usr/lib/quagga/ospfd-daemon -A 127.0.0.1root 3287 0.0 0.8 4852 1080 ? Ss Apr02 0:00 /usr/sbin/sshdroot 3325 0.0 0.6 2192 884 ? Ss Apr02 0:03 /usr/sbin/cronroot 3333 0.0 0.3 1620 440 ? Ss Apr02 0:59 /usr/sbin/watchdogasterisk3356 0.1 4.6 13876 5848 ? Ssl Apr02 8:59 /usr/sbin/asterisk -p-U asteriskroot 3397 0.0 0.3 1572 496 ttyS0 Ss+ Apr02 0:00 /sbin/getty -L ttyS038400root 9697 0.7 1.8 7624 2320 ? Ss 10:45 0:00 sshd: root@pts/0root 9701 6.2 2.0 3664 2540 pts/0 Ss 10:46 0:02 -bashroot 9719 0.0 0.7 2216 888 pts/0 R+ 10:46 0:00 ps auxvoyage: #

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 hostnameMuestra y modifica el nombre del sistema.

voyage: # hostnamevoyagevoyage: #

6.1.10. Comando tailMuestra 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/syslogApr 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 0x5e1partner 0x00.Apr 8 10:45:36 voyage kernel: eth0: link down.Apr 8 10:45:46 voyage kernel: eth0: Autonegotiation advertising 0x5e1partner 0x45e1.Apr 8 10:45:46 voyage kernel: eth0: link up.

voyage: #

6.1.11. Comando ifconfigMuestra las condiciones en la cual se encuentra una interfaz de red y también sirve para configurar los

parámetros de red.

voyage: # ifconfig eth0eth0 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.0inet6 addr: fe80::20d:b9ff:fe07:e9c0/64 Scope:LinkUP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1RX packets:485434 errors:0 dropped:0 overruns:0 frame:0TX packets:52531 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:1000RX bytes:30162474 (28.7 MiB) TX bytes:4139442 (3.9 MiB)Interrupt:10 Base address:0x8000

voyage: #

6.1.12. Comando pingManda una mensaje de prueba a un dispositivo de red y espera una respuesta mostrando el tiempo de re-

spuesta de cada paquete que envía; si no recibiera respuesta esto significaría que no hay conexión con esedispositivo.

6.2 Instalación de Voyage GTR 83

voyage: # ping 20.20.20.1 -c 5PING 20.20.20.1 (20.20.20.1) 56(84) bytes of data.64 bytes from 20.20.20.1: icmp_ seq=1 ttl=64 time=0.723 ms64 bytes from 20.20.20.1: icmp_ seq=2 ttl=64 time=0.639 ms64 bytes from 20.20.20.1: icmp_ seq=3 ttl=64 time=0.641 ms64 bytes from 20.20.20.1: icmp_ seq=4 ttl=64 time=0.700 ms64 bytes from 20.20.20.1: icmp_ seq=5 ttl=64 time=0.641 ms

-- 20.20.20.1 ping statistics --5 packets transmitted, 5 received, 0% packet loss, time 3998msrtt min/avg/max/mdev = 0.639/0.668/0.723/0.048 msvoyage: #

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.1The 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)? yesWarning: Permanently added '20.20.20.1'(RSA) to the list of known hosts.root@20.20.20.1'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 -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface20.20.20.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth10.0.0.0 20.20.20.1 0.0.0.0 UG 0 0 0 eth1root@gtrdesktop: #

6.2. Instalación de Voyage GTR

Para instalar Voyage GTR en una Compact Flash (CF) se introduce la memoria CF en el lector/grabadorade memorias USB y se conecta a una PC con Linux y se ejecuta el script de instalación. Para la instalación serecomienda trabajar como usuario root en la PC; se debe obtener la versión de Voyage GTR junto al script quepermite su grabado; ambos se podrían guardar en la carpeta /root/. Ahora se ejecuta el script que permite elgrabado de Voyage GTR.

84 CAPÍTULO 6. CONFIGURACIÓN E INSTALACIÓN DE VOYAGE GTR

root@gtrdesktop: # lsgrabar-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 PCDisk /dev/sda: 80.0 GB, 80026361856 bytesDisk /dev/sdb: 1008 MB, 1008730112 bytesDisk /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.gzArchivos conf:Hardware: alixDispositivo CF: sdcChequeo CF: sicontinuar(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 particionROOT_ 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 puedeextraer la CF y desconectar la lectora/grabadora del puerto USB.

6.3 Acceso inicial por puerto serial o por Ethernet 85

6.3. Acceso inicial por puerto serial o por EthernetUna 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 carecede puerto serial sin encender la placa ALIX, se procede a conectar el cable serial a la PC y a la placa ALIX; enun 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 pidael ingreso del usuario y la contraseña; por defecto el usuario es root y la contraseña es voyage. El uso delpuerto serial es muy importante porque nos permite ingresar a los equipos sin usar sus interfaces de red y encaso 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 uninicio se puede ingresar por este puerto con ssh. Para ingresar se usará un cable cruzado y una vez que la placaeste encendida y cargado el sistema operativo (alrededor de un minuto) se puede hacer:

# ssh root@11.11.11.1

Después de esto se pedirá el ingreso de la clave, en éste caso inicial será voyage.

6.4. Edición de archivosLa partición donde se instala Voyage GTR inicialmente carga en modo lectura.

voyage: # mountrootfs 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 regresarel 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 rescribiro crear archivos; la partición donde está instalada Voyage GTR pertenece a la CF y es la se que carga en modolectura.

Voyage:/# ls -ltotal 101-rwxr-xr-x 1 root root 9743 Jun 29 2008 CHANGELOG-rwxr-xr-x 1 root root 20711 Jun 22 2008 READMEdrwxr-xr-x 2 root root 2048 Jul 22 2008 bindrwxr-xr-x 3 root root 1024 Jul 15 2008 bootdrwxr-xr-x 13 root root 12860 Apr 24 16:06 devdrwxr-xr-x 65 root root 3072 Apr 24 17:17 etcdrwxr-xr-x 3 root root 1024 Jul 22 2008 homedrwxr-xr-x 2 root root 1024 Jun 28 2008 initrdlrwxrwxrwx 1 root root 33 May 8 2009 initrd.img ->boot/initrd.img-2.6.23-486-voyagelrwxrwxrwx 1 root root 33 May 8 2009 initrd.img-2.6.23-486-voyage->boot/initrd.img-2.6.23-486-voyagedrwxr-xr-x 12 root root 3072 Jul 15 2008 libdrwx------ 2 root root 12288 Jul 15 2008 lost+founddrwxr-xr-x 2 root root 1024 Jun 28 2008 mediadrwxr-xr-x 2 root root 1024 Oct 28 2006 mntdrwxr-xr-x 4 root root 1024 Jul 22 2008 optdr-xr-xr-x 44 root root 0 Dec 31 1999 procdrwxr-xr-x 8 root root 1024 Apr 24 14:58 rolrwxrwxrwx 1 root root 8 May 8 2009 root ->/rw/rootdrwxr-xr-x 8 root root 160 Apr 24 14:58 rwdrwxr-xr-x 2 root root 3072 Jul 22 2008 sbindrwxr-xr-x 2 root root 1024 Jun 28 2008 srvdrwxr-xr-x 10 root root 0 Dec 31 1999 sys-rw-r-r--- 1 root root 352 Jul 11 2008 test.conflrwxrwxrwx 1 root root 7 May 8 2009 tmp ->/rw/tmpdrwxr-xr-x 10 root root 1024 Apr 24 14:53 usrdrwxr-xr-x 7 root root 1024 Jul 1 2008 varlrwxrwxrwx 1 root root 30 May 8 2009 vmlinuz ->boot/vmlinuz-2.6.23-486-voyagelrwxrwxrwx 1 root root 30 May 8 2009 vmlinuz-2.6.23-486-voyage->boot/vmlinuz-2.6.23-486-voyage-rw-r-r--- 1 root root 11213 Jun 29 2008 voyage.depends.list-rw-r-r--- 1 root root 17239 Jun 29 2008 voyage.dpkg-l-rw-r-r--- 1 root root 3165 Jun 29 2008 voyage.dpkg.list-rw-r-r--- 1 root root 96 Apr 24 16:06 voyage.gtr.variables-rw-r-r--- 1 root root 54 Apr 24 20:27 voyage.gtr.versionvoyage:/#

Pero la carpeta /rw está contenida en un espacio delimitado (hasta 32MB) de la RAM del sistema, portanto está en modo escritura; por lo que en este espacio se podrá editar los archivos que se encuentren aquí ytambié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 87

voyage:/var# ls -ltotal 5drwxr-xr-x 2 root root 1024 Apr 24 18:00 backupsdrwxr-xr-x 6 root root 1024 Jul 15 2008 cachedrwxr-xr-x 16 root root 1024 Apr 24 11:40 libdrwxrwsr-x 2 root staff 1024 Oct 28 2006 locallrwxrwxrwx 1 root root 12 May 8 2009 lock ->/rw/var/locklrwxrwxrwx 1 root root 11 May 8 2009 log ->/rw/var/loglrwxrwxrwx 1 root root 12 May 8 2009 mail ->/rw/var/maildrwxr-xr-x 2 root root 1024 Jun 28 2008 optlrwxrwxrwx 1 root root 11 May 8 2009 run ->/rw/var/runlrwxrwxrwx 1 root root 13 May 8 2009 spool ->/rw/var/spoollrwxrwxrwx 1 root root 11 May 8 2009 tmp ->/rw/var/tmpvoyage:/var#

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; entoncespara crear de nuevo estas carpetas, se tiene a /ro; todo lo que está en /ro se copiará a /rw, por tanto unavez 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 reini-cio se perderá en /ro no se guarda directamente los cambios hechos en estas carpetas; por tanto lo que se copiede /ro a /rw sólo será la estructura inicial.

voyage:/rw# ls -ltotal 0drwxr-xr-x 2 root root 40 Jun 29 2008 devdrwxr-xr-x 4 root root 140 Apr 24 16:28 etcdrwxr-xr-x 2 root root 140 Apr 24 22:40 rootdrwxrwxrwt 2 root root 40 Dec 31 1999 tmpdrwxr-xr-x 2 root root 40 Jun 29 2008 usrdrwxr-xr-x 9 root root 180 Jun 29 2008 varvoyage:/rw#

voyage: # cd /ro/voyage:/ro# ls -ltotal 6drwxr-xr-x 2 root root 1024 Jun 29 2008 devdrwxr-xr-x 4 root root 1024 Apr 24 16:28 etcdrwxr-xr-x 2 root root 1024 Jul 23 2008 rootdrwxrwxrwt 2 root root 1024 Jun 29 2008 tmpdrwxr-xr-x 2 root root 1024 Jun 29 2008 usrdrwxr-xr-x 9 root root 1024 Jun 29 2008 varvoyage:/ro#

6.6. Guardar archivos o carpetas de /rwTodo 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 vari-able 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á loguardado.

voyage: # cat /etc/voyage.conf## This file generated automatically by copyfiles.sh# on Tue Jul 15 15:40:18 PET 2008#

VOYAGE_ PROFILE=ALIXVOYAGE_ SYSTEM_ CONSOLE=serial# VOYAGE_ SYSTEM_ SYNCDIRS=/var/log"# VOYAGE_ SYSTEM_ SYNCFILES=/var/log/syslog /var/log/kern.log"VOYAGE_ SYSTEM_ SERIAL=38400VOYAGE_ SYSTEM_ PCMCIA=noVOYAGE_ SYSTEM_ MODULES=”lm90; w83627hf; scx200_ acb base=0x810,0x820;geodewdt; led-class; leds-alix; ledtrig-heartbeat; ledtrig-timer"SYSTEM_ BOOTSTRAP=grubVoyage: #

Si ya no se desea seguir guardando se comenta de nuevo las variables.

6.7. Configuración previa a cualquier aplicación en Voyage GTRDar nombre al equipo, editar /etc/hostname; el nombre del equipo no debe contener puntos ni espa-

cios en blanco o caracteres extraños.

voyage: # cat /etc/hostnamevoyagevoyage: #

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 lavariable 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 laopció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-boardPATH=/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 rebootvoyage: #

6.8. Obtención de respaldo de la configuración de las aplicacionesen Voyage GTR

Para sacar un respaldo de la configuración hecha en Voyage GTR se debe indicar que archivo o carpeta sedebe respaldar; esto se indica en el archivo de configuración /etc/backup.list; originalmente éste archi-vo contiene una lista de los archivos y/o carpetas que deberían ser respaldados; si en esta lista no se encuentrauna carpeta o archivo en particular se adiciona línea por línea. Después se ejecuta el script mgbackup con laopción backup:

red-sur: # mgbackup backup...32: guardando /etc/default/snmpd33: guardando /etc/snmp34: guardando /etc/quagga/daemons35: guardando /etc/quagga/ospfd.conf36: guardando /etc/quagga/zebra.conf37: guardando /etc/uya/passwd... finalizado respaldo... solo guarde el /opt/backup-conf-red-sur.tar.gzred-sur: #

Si no se muestra error en la creación del respaldo, se creará en /opt un archivo comprimido con el nombredel 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 deVoyage GTR en la CF, se utilizará para indicar el archivo de respaldo (obtenido antes) que se copiará en estagrabación de Voyage GTR; es decir Voyage GTR que se obtendrá aquí será idéntica en configuración de VoyageGTR 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 particionescríticas. Normalmente es necesario que se tenga al menos la mitad de espacio disponible en cada partición, sise 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 -lFilesystem 1K-blocks Used Available Use% Mounted onrootfs 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/devtmpfs 63384 0 63384 0% /lib/init/rwtmpfs 63384 0 63384 0% /dev/shmtmpfs 32768 664 32104 3% /rwvoyage: #

6.9.2. RAM libre y CPU desocupado en un instanteEsto 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 seaun instante donde muchas aplicaciones estén con mucho trabajo. En un diseño no puede estar contemplado unacarga alta y constante por mucho tiempo, si esto sucede se debe buscar las aplicaciones que causan el excesivoconsumo o quizás reiniciar el equipo para regresar al estado normal. El uso excesivo se da generalmente enpocos instantes y con poca duración, en este instante se puede llegar a más de 60 % de RAM y casi 100 % deCPU; pero en el resto del tiempo generalmente se debe tener un consumo de alrededor de 20 % de RAM; y elCPU 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: # freetotal used free shared buffers cached

Mem: 126768 47564 79204 0 2604 25148-/+ buffers/cache: 19812 106956Swap: 0 0 0gtr-v106: #

gtr-v106: # toptop - 15:01:42 up 10:43, 1 user, load average: 0.01, 0.02, 0.00Tasks: 34 total, 1 running, 33 sleeping, 0 stopped, 0 zombieCpu(s): 1.3%us, 1.0%sy, 0.0%ni, 95.4%id, 0.0%wa, 0.3%hi, 2.0%si, 0.0%stMem: 126768k total, 68964k used, 57804k free, 2800k buffersSwap: 0k total, 0k used, 0k free, 45956k cached...

6.9.3. Fecha del sistema y último reinicioTomar 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 debeevaluar 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 91

gtr-v106: # dateFri May 8 15:05:18 PET 2009gtr-v106: #

gtr-v106: # date -set "05/11/09 14:51"

voyage: # uptime14:29:10 up 10:10, 1 user, load average: 0.00, 0.00, 0.00voyage: #

92 CAPÍTULO 6. CONFIGURACIÓN E INSTALACIÓN DE VOYAGE GTR

7Con�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: # lspci00:01.0 Host bridge: Advanced Micro Devices [AMD] Unknown device 2080 (rev 33)00:01.2 Entertainment encryption device: Advanced Micro Devices [AMD] Geode LXAES Security Block00: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 estoya se ha hecho al implementar Voyage Gtr; se puede observar en /var/log/syslog una vez que el sistemaeste cargado.

93

94 CAPÍTULO 7. CONFIGURACIÓN DE REDES CON VOYAGE GTR

voyage: #voyage: # cat /var/log/syslog |grep wifiMay 20 15:40:16 voyage kernel: wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11MbpsMay 20 15:40:16 voyage kernel: wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54MbpsMay 20 15:40:16 voyage kernel: wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps36Mbps 48Mbps 54MbpsMay 20 15:40:16 voyage kernel: wifi0: H/W encryption support:WEP AES AES_CCM TKIPMay 20 15:40:16 voyage kernel: wifi0: mac 5.9 phy 4.3 radio 4.6May 20 15:40:16 voyage kernel: wifi0: Use hw queue 1 for WME_AC_BE trafficMay 20 15:40:16 voyage kernel: wifi0: Use hw queue 0 for WME_AC_BK trafficMay 20 15:40:16 voyage kernel: wifi0: Use hw queue 2 for WME_AC_VI trafficMay 20 15:40:16 voyage kernel: wifi0: Use hw queue 3 for WME_AC_VO trafficMay 20 15:40:16 voyage kernel: wifi0: Use hw queue 8 for CAB trafficMay 20 15:40:16 voyage kernel: wifi0: Use hw queue 9 for beaconsMay 20 15:40:16 voyage kernel: wifi0: Atheros 5212: mem=0xe0080000, irq=9voyage: #voyage: # cat /var/log/syslog |grep ethMay 20 15:40:16 voyage kernel: eth0: VIA Rhine III (Management Adapter) at0xe0000000, 00:0d:b9:16:e7:9c, IRQ 10.May 20 15:40:16 voyage kernel: eth0: MII PHY found at address 1, status 0x786dadvertising 05e1 Link 45e1.May 20 15:40:16 voyage kernel: eth1: VIA Rhine III (Management Adapter) at0xe0040000, 00:0d:b9:16:e7:9d, IRQ 12.May 20 15:40:16 voyage kernel: eth1: MII PHY found at address 1, status 0x7849advertising 05e1 Link 0000.May 20 15:40:16 voyage kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1May 20 15:40:28 voyage kernel: eth0: no IPv6 routers presentvoyage: #

7.2. Configuración de las interfaces de redLos archivos de configuración están editados con una plantilla que se puede modificar o adicionar rápida-

mente. 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/nat-static-routes.

7.2.1. Configuración de Ethernet y de Bridge EthernetPara configurar las interfaces Ethernet se descomenta las líneas correspondientes y se cambiará la IP/Máscara

de red si es necesario.

auto eth0iface eth0 inet static

address 10.10.10.1netmask 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 yponer la IP/Máscara de red; además la configuración de las interfaces involucradas deben ser comentadas.

auto br0iface br0 inet static

address 11.11.10.1netmask 255.255.255.0bridge_ports eth0 eth1bridge_stp offbridge_maxwait 5

7.2.2. Configuración de las interfaces WiFiLa 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:

#--apath_parent wifi0ath_vaptype ap

Si es STA se descomenta las líneas:

#--clienteath_parent wifi0ath_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 delSTA deberá ser descomentada.

Algunos parámetros WiFi son obligatorios, se cambiará de valor según sea necesario.

#--otros parametros wifiath_distance 19800 está en metros, cada interfaz de un mismo enlace debe estar

configurado con la misma distancia; si se tiene varios STAse coloca la distancia más larga que existe entre el APy 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 valorath_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 tarjetainalá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 quedebe ser en hexadecimal; si se usa WPA2-PSK se descomenta el bloque respectivo si es STA o AP; y se debeeditar 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 de64b) o 26 (WEP de 128b).

#--seguridad wepath_security wepath_wep_key1 12345ABCDE

Si se usa WPA2-PSK en una AP se habilita:

#--seguridad wpa-psk apath_security wpa2ath_wpa_cfgfile /etc/hostapd/hostapd-ath0.conf

Si se usa WPA2-PSK en una STA se habilita:

#--seguridad wpa-psk stawpa_driver madwifiwpa_conf /etc/wpa_supplicant/wpasupplicant-ath0.conf

Por último se configura la IP y la Máscara de red de la interfaz.

#--ip y netmaskaddress 10.10.1.2netmask 255.255.255.240

Si se ha elegido seguridad WPA2-PSK además de habilitar las opciones se debe editar los archivos adi-cionales; donde sólo se cambiará el nombre de la red y la clave WPA2-PSK (en caracteres y debe ser desde 8a 63 caracteres). Existe un archivo plantilla para cada interfaz dependiendo si es STA o AP. Si se está configu-rando 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=10psk="gtrcaswifi"#psk=70df87c28aee0e42b49f55450df0f822200933ff3968406176fbcd41eb9a8a72

Si se esta configurando un AP que es ath2 entonces se edita /etc/hostapd/hostapd-ath2.confy 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 ac-tualiza 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 dela 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 cadauna 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 10.13.1.2 1"ROUTE3="10.15.1.0/28 10.13.2.2 1"ROUTE4="10.15.1.0/28 10.13.3.2 1"....

Para NAT sólo se optara por habilitar o no habilitar; si se habilita se descomenta la variable DEFAULT_NATy 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# lsdaemons 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=yesbgpd=noospfd=yesospf6d=noripd=noripngd=noisisd=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 sepuede cambiar el ancho de banda, por defecto esta en 10MB.

interface ath0bandwidth 10000000ipv6 nd suppress-ra

Si este equipo pertenece a una red OSPF y está conectado a un equipo vecino que no pertenece a una redOSPF y además existe redes detrás de este equipo vecino; entonces si se quiere que la red OSPF acceda a éstasredes; entonces en éste archivo de debe especificar la ruta para llegar a esa red indicando por donde se llegaríay 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 estasip route 10.14.2.0/28 10.15.1.2 1ip route 10.14.3.0/28 10.15.1.2 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 ponerun costo (valor entero), para que no se use el ancho de banda configurado en zebra.conf.

interface ath2ip ospf cost 10

Ahora se debe especificar el identificador del equipo en la red OSPF, es importante este valor y debe serdistinto 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 alcual pertenece.

7.5 Configuración del DHCP 99

network 10.10.1.0/28 area 0.0.0.0network 10.10.2.0/28 area 0.0.0.0network 10.11.1.0/28 area 0.0.0.1network 10.21.1.0/28 area 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 0.0.0.1 range 10.11.0.0/16area 0.0.0.1 range 10.12.0.0/16area 0.0.0.2 range 10.21.0.0/16area 0.0.0.2 range 10.22.0.0/16

Si al equipo se le ha adicionado rutas estáticas (zebra.conf); entonces se debe especificar como se debepublicar 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); entoncesse 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 enel router que lo publica; sin always los routers tendrán una ruta por defecto mientras este configurado en elrouter que lo publica.

Al ejecutar /etc/init.d/quagga stop y /etc/init.d/quagga start se actualiza los cam-bios del enrutamiento. Si una vez que OSPF ya está trabajando se hace /ect/init.d/networkingrestart lo del OSPF se perderá, para activar de nuevo se debe ejecutar /etc/init.d/quagga restart.

7.5. Configuración del DHCPPara 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 es-pecifica:

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/IPmediante 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/diversitynodo-a: # echo 1 >/proc/sys/dev/wifi0/txantennanodo-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 keyaabbccddee 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 interfazló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

8Veri�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 grandesredes de datos. Estas se encuentran compuestas de redes troncales y de distribución. Una red troncal consistetradicionalmente en líneas relativamente largas que recogen y reparten el tráfico a las zonas de distribuciónsituadas 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. Tomandocomo base el escenario presentado, a continuación se detalla las medidas de verificación de buen estado, quedebe 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-STASe 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 deconfiguració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 enlacePara 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 interfazManaged entonces se puede escanear los AP (Master) de sus alrededores y observar el AP al que debería conec-tarse. 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 linkQuality 23/94).

nodo-b: # iwlist ath0 scanath0 Scan completed :

Cell 01 - Address: 00:0C:42:18:F7:74ESSID:“PUCP”Mode:MasterFrequency:2.462 GHz (channel 11)Quality=23/94 Signal level=-72 dBm Noise level=-95 dBmEncryption key:onBit 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/s48 Mb/s; 54 Mb/s

Extra:bcn_int=100Extra:wme_ie=dd180050f2020101830002a3400027a4000042435eExtra:ath_ie=dd0900037f010100240000

Estos parámetros representan la calidad del enlace. En largas distancias se puede asumir que se debe lograrun nivel de entre -65dBm y -75dBm con una calidad (Link Quality) de unos 20dB; si se tiene un nivel pordebajo de -75dBm hasta -80dBm el enlace estará muy inestable y tendrá un rendimiento bajo. Tomar nota porcada router del enlace:

Nivel de señal del enlace

8.1 Conectividad en enlaces AP-STA 105

Calidad del enlace

nodo-b: # iwconfig ath0ath0 IEEE 802.11g ESSID:"PUCP"Nickname:

Mode:Managed Frequency:2.462 GHz Access Point:00:0C:42:18:F7:74Bit Rate=12 Mb/s Tx-Power=10 dBm Sensitivity=0/3Retry:off RTS thr:off Fragment thr:offEncryption key:AABB-CCDD-EE Security mode:restrictedPower Management:offLink Quality=22/94 Signal level=-73 dBm Noise level=-95 dBmRx invalid nwid:241 Rx invalid crypt:0 Rx invalid frag:0Tx excessive retries:0 Invalid misc:0 Missed beacon:0

nodo-a: # iwconfig ath1ath1 Link encap:Ethernet HWaddr 00:0C:42:18:F7:74

Mode:Master Frequency:2.462 GHz Access Point:00:0C:42:18:F7:74Bit Rate=12 Mb/s Tx-Power=10 dBm Sensitivity=0/3Retry:off RTS thr:off Fragment thr:offEncryption key:AABB-CCDD-EE Security mode:restrictedPower Management:offLink Quality=26/94 Signal level=-70 dBm Noise level=-96 dBmRx invalid nwid:84237 Rx invalid crypt:0 Rx invalid frag:0Tx 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 elSTA y el AP; además se observa nivel aceptable de 70dBm (con un link quality de 25/94 aprox.). Además conel resultado de ésta información se debe verificar el nombre la red WiFi, el canal, la potencia configurada, lavelocidad máxima, y la seguridad apoyada de otros archivos.

Con el siguiente comando se observará las potencias configurables en las tarjetas inalámbricas; por ejemploeste resultado corresponde a una SR2 de Ubiquiti (posee un offset de 10dBm).

nodo-b: # iwlist ath0 txpowerath0 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 yrecibir, se debe observar:

nodo-b: # cat /proc/sys/dev/wifi0/diversity0nodo-b: # cat /proc/sys/dev/wifi0/txantenna1nodo-b: # cat /proc/sys/dev/wifi0/rxantenna1nodo-b: #

106 CAPÍTULO 8. VERIFICACIÓN DEL ESTADO DE LA RED DE DATOS

8.1.2. Cantidad de clientes conectados al APSegú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 antenasEn 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 labisectriz 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 lamejor posición apoyados por medio de un alineador de antenas externo; pero para lograr mayor precisión sepuede usar las herramientas de los equipos a instalar; en este caso; se puede usar el comando iwconfig parapoder 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 de24dBi 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 delas antenas.

nodo-c: # iwconfig ath0ath0 IEEE 802.11g ESSID:ÇUSCO2"Nickname:

Mode:Managed Frequency:2.417 GHz Access Point:Not-AssociatedBit Rate=6 Mb/s Tx-Power=off Sensitivity=0/3Retry:off RTS thr:off Fragment thr:offEncryption key:6375-7363-6F Security mode:restrictedPower Management:offLink Quality=3/94 Signal level=-91 dBm Noise level=-94 dBmRx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0Tx 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á tenerenlace; pero al tener un nivel muy bajo será muy inestable. Abajo se muestra que existe demasiada pérdida depaquetes y un rendimiento bajo.

nodo-c: # iwconfig ath0ath0 IEEE 802.11g ESSID:ÇUSCO2"Nickname:

Mode:Managed Frequency:2.412 GHz Access Point:00:0C:42:18:F7:74Bit Rate=6 Mb/s Tx-Power=off Sensitivity=0/3Retry:off RTS thr:off Fragment thr:offEncryption key:6375-7363-6F Security mode:restrictedPower Management:offLink Quality=12/94 Signal level=-84 dBm Noise level=-96 dBmRx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0Tx 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 10PING 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 ms64 bytes from 10.1.2.1: icmp_seq=4 ttl=64 time=0.588 ms64 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 9007msrtt 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 5001TCP 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/secnodo-c: #

Si se logra tener un nivel de -71dBm y una calidad de 22; el rendimiento mejorará, y no existirá pérdida depaquetes, al menos en el mayor tiempo.

nodo-c: # iwconfig ath0ath0 IEEE 802.11g ESSID:ÇUSCO2"Nickname:

Mode:Managed Frequency:2.412 GHz Access Point:00:0C:42:18:F7:74Bit Rate=6 Mb/s Tx-Power=off Sensitivity=0/3Retry:off RTS thr:off Fragment thr:offEncryption key:6375-7363-6F Security mode:restrictedPower Management:offLink Quality=22/94 Signal level=-71 dBm Noise level=-93 dBmRx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0Tx excessive retries:0 Invalid misc:0 Missed beacon:0

nodo-c: # ping 10.1.2.1 -c 10PING 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 ms64 bytes from 10.1.2.1: icmp_seq=2 ttl=64 time=0.624 ms64 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 8999msrtt 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 5001TCP 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/secnodo-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 nivelde recepción obtenido aún se puede mejorar, al menos hasta llegar a -55dBm; pero para enlaces de 40Km conestas 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 puedelograr; 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 simuladoresde enlaces WiFi y de las coordenadas obtenidas. Una vez en campo se puede encontrar la distancia más óptimaque puede estar alrededor de más o menos 300m del que se ha configurado. El cambio de la distancia se debehacer en ambos lados del enlace. En un enlace punto multipunto la distancia a configurar es la que se tiene conla antena mas alejada.

Si no se ha configurado la distancia, por defecto se mostrará:

nodo-b: # cat /proc/sys/dev/wifi0/acktimeout48nodo-b: # cat /proc/sys/dev/wifi0/slottime9nodo-b: # cat /proc/sys/dev/wifi0/ctstimeout48nodo-b: #

Si se ha configurado para una distancia de 1000m por ejemplo; se tendría estos valores:

nodo-b: # cat /proc/sys/dev/wifi0/acktimeout89nodo-b: # cat /proc/sys/dev/wifi0/slottime43nodo-b: # cat /proc/sys/dev/wifi0/ctstimeout89nodo-b: #

Para no cambiar la distancia en /etc/network/interfaces se puede configurar por comandos y unavez 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 interfazde 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 ath0ath0 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.0inet6 addr: fe80::20c:42ff:fe18:f768/64 Scope:LinkUP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1RX packets:28725 errors:0 dropped:0 overruns:0 frame:0TX packets:27958 errors:0 dropped:0 overruns:0 carrier:0collisions:0 txqueuelen:0RX bytes:4651917 (4.4 MiB) TX bytes:2217302 (2.1 MiB)

nodo-a: # ifconfig ath1ath1 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.0inet6 addr: fe80::20c:42ff:fe18:f774/64 Scope:LinkUP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1RX packets:6687 errors:0 dropped:0 overruns:0 frame:0TX packets:7962 errors:0 dropped:5 overruns:0 carrier:0collisions:0 txqueuelen:0RX 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; sedebe 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 60transmitidos (1 minuto). Para esta prueba se debe hacer un ping de unos 30 paquetes y por cada AP - STA delenlace 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 debetener 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 ms64 bytes from 11.11.11.1: icmp_seq=2 ttl=64 time=0.118 ms64 bytes from 11.11.11.1: icmp_seq=3 ttl=64 time=0.101 ms64 bytes from 11.11.11.1: icmp_seq=4 ttl=64 time=0.133 ms64 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 ms64 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 38991msrtt min/avg/max/mdev = 0.097/0.109/0.204/0.021 msvoyage: #

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 de100m hasta encontrar el más óptimo. Después de cada cambio se debe repetir la prueba de ping, como los pingde mayor tamaño y el rendimiento del enlace.

8.1.5. Ping con mayor tamaño entre las interfaces del enlaceUn 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 transmiten1500 bytes en el enlace ejemplo, el tiempo de cada ping debe ser regular y estar alrededor de 3 a 6ms; si setiene una irregularidad notable por ejemplo saltos de 5ms a 20ms en varios pings, se debe seguir vigilando yrevisar 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, elnivel y calidad del enlace. Para esta prueba se debe hacer ping con una cantidad de unos 30 paquetes; se debeanotar.

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 11.11.11.1 (11.11.11.1) 1500(1528) bytes of data.1528 bytes from 11.11.11.1: icmp_seq=1 ttl=64 time=1.157 ms1528 bytes from 11.11.11.1: icmp_seq=2 ttl=64 time=1.117 ms1528 bytes from 11.11.11.1: icmp_seq=3 ttl=64 time=1.111 ms1528 bytes from 11.11.11.1: icmp_seq=4 ttl=64 time=1.113 ms1528 bytes from 11.11.11.1: icmp_seq=5 ttl=64 time=1.114 ms...1528 bytes from 11.11.11.1: icmp_seq=39 ttl=64 time=1.120 ms1528 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 38991msrtt min/avg/max/mdev = 1.104/1.114/1.157/1.017 msvoyage: #

8.1.6. Medición en el rendimiento de un enlaceLa 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 deseñ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 enlacede entre 1 a 2Mbps en buen tiempo (ausencia de lluvia y neblina) se debe revisar el enlace buscando posiblesfallas o mejoras al enlace; un valor menor a 1Mbps es un enlace malo y debe mejorarse. Se recomienda realizarla 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 5001TCP 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 5001TCP 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/secnodo-a: #

8.1.7. Verificación de la tabla de rutas y la ruta de salidaSe 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 redesaccesibles y no los equipos accesibles; para esto se usa, el comando route, con él se pueden ver las redesaccesibles (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 -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface10.1.4.0 10.1.3.2 255.255.255.0 UG 0 0 0 ath110.1.53.0 0.0.0.0 255.255.255.0 U 0 0 0 eth110.1.52.0 0.0.0.0 255.255.255.0 U 0 0 0 eth010.1.55.0 10.1.3.2 255.255.255.0 UG 0 0 0 ath110.1.54.0 10.1.3.2 55.255.255.0 UG 0 0 0 ath110.1.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ath010.1.3.0 0.0.0.0 55.255.255.0 U 0 0 0 ath10.0.0.0 10.1.2.1 0.0.0.0 UG 0 0 0 ath0nodo-b: #

Si se trabaja con enrutamiento dinámico las redes accesibles aparecerán en la tabla de rutas; si alguno noaparece se debe comprobar; quizás el problema es que ciertos enlaces estén caídos; para esto se puede usartraceroute.

nodo-b: # traceroute 10.1.4.2traceroute to 10.1.4.2 (10.1.4.2), 30 hops max, 40 byte packets1 10.1.1.2 (10.1.1.2) 0.573 ms 0.593 ms 1.258 ms2 10.1.2.2 (10.1.2.2) 4.837 ms 2.315 ms 3.682 ms3 10.1.3.2 (10.1.3.2) 8.673 ms 4.597 ms 5.248 ms4 10.1.4.2 (10.1.4.2) 12.935 ms 6.315 ms 7.682 msnodo-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 comandotraceroute 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 time=96.8 ms

64 bytes from www.google.com (64.233.169.147): icmp_seq=2 ttl=244 time=94.8 ms

64 bytes from www.google.com (64.233.169.147): icmp_seq=3 ttl=244 time=96.9 ms

64 bytes from www.google.com (64.233.169.147): icmp_seq=4 ttl=244 time=95.2 ms

64 bytes from www.google.com (64.233.169.147): icmp_seq=5 ttl=244 time=96.3 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 redUna 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 parasu revisión posterior cuando se esté en ese nodo.

8.2. Conectividad en una red troncalAl 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, esrecomendable realizar la prueba en tiempos buenos, en todo el tramo de la red. El gráfico de abajo muestra unared 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 113

8.2.1. Ping a todas las interfaces de redSe 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 paqueteshacia 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 troncalSe 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 funcionamientocorrecto de los servicios de la red. Se recomienda realizar la prueba del rendimiento con el iperf con untiempo total de unos 50s a más; tal como la se muestra en el cálculo del rendimiento de un enlace. Se debeanotar:

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

9Con�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/hosts127.0.0.1 localhost127.0.1.1 voyage

Para activar el servicio en el arranque del sistema se debe poner en yes la variable RUNASTERISK en elarchivo /etc/default/asterisk.

voyage: # vim /etc/default/asterisk# This file allows you to alter the configuration of the Asterisk# init.d script#RUNASTERISK=yesvoyage: #

Es recomendable cargar el módulo ztdummy; descomentar en:

voyage: # cat /etc/modules...ledtrig-heartbeatledtrig-timer#zaptel#ztdummy

voyage: #

Esto permitirá que se cargue después de un reinicio; pero si se desea que se cargue en este momento sepuede hacer:

voyage: # modprobe ztdummy

115

116CAPÍ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ín-imas, 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 mis-mo Asterisk y con clientes SIP administrados por otros Asterisk y además permitir la comunicación con lared de telefonía pública; esta configuración involucra a los archivos sip.conf, extensions.conf, yiax.conf, todos éstos ubicados en /etc/asterisk/. Se puede tomar esta configuración como plantillapara una configuración particular. Recuerde que los comentarios en estos archivos de configuración empiezancon ; 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 sepuede especificar los identificadores del cliente y los codecs a usar.

[general];bindport=5060disallow=allallow=ulawallow=g726aal2allow=gsmallow=ilbcallow=g726;[210]type=friendhost=dynamiclanguage=escontext=centersecret=passwdusername=210callerid=210dtmfmode=rfc2833qualify=yes;

Para configurar clientes SIP con puerto FXO, se puede usar la identificación 10; cambiado sólo lo necesario.

[10]type=friendport=5061host=dynamiclanguage=escontext=centersecret=passwdusername=10callerid=10dtmfmode=rfc2833qualify=yes;

9.2 Configuración básica de Asterisk 117

9.2.2. Programación de las llamadas telefónicasEn /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 losotros Asterisk de la red.

[globals];IP-SERVER200=IP-SERVER300=20.20.20.13IP-SERVER400=IP-SERVER-PSTN=PHONE-DEFAULT=

La variable PHONE-DEFAULT= contiene el teléfono que responderá por defecto después de escuchar elIVR en una llamada proveniente del exterior.

En la parte (center) se especifica con que equipos se tendrá comunicación; está divido en: comunicacióncon 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 alservidor Asterisk.

;prueba de llamada al servidorexten =>200,1,Macro(call-svlocal,200);

Aquí se especifica los números telefónicos locales.

;llamar area localexten =>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 rangoscomo en este caso; además debe poner la IP del Asterisk que administra este rango de números telefónicos; co-mo se observa esto se hace en base a variables por ejemplo IP-SERVER300 donde su valor estará en la secciónde variables.

Para la comunicación con la telefonía pública se especifica los números permitidos; tenga en cuenta que sedebe diferenciar de los números telefónicos usados en la red; a veces se usa un prefijo; en este caso se anteponeun 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 Asteriskdonde se va a registrar al cliente SIP que va ha conectar la telefonía IP con la telefonía pública. En la primeraparte se muestra los números permitidos para llamar a la telefonía pública y la segunda parte se muestra al iden-tificador 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 servidoresexten =>_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 latelefonía IP con la telefonía pública; en este caso el Asterisk deberá comunicarse con el Asterisk que registre aeste equipos que une ambas redes.

118CAPÍ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 AsteriskSi 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. Abajose muestra las IP que contendría cada Asterisk en extensions.conf para comunicarse con el resto de losAsterisk.

Figura 9.1: Identificación de direcciones IP de los servidores Asterisk

9.2.4. Grabación de archivos de sonidoPara 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á agrabar por el teléfono hasta que se presione el símbolo #; después se escuchará lo grabado y terminará la lla-mada.

;grabacion de archivos de sonido gsmexten =>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ásicoEl IVR se utiliza para contestar y direccionar las llamadas entrantes provenientes de la telefonía pública; es-

to está en /etc/asterisk/extensions.conf. Se debe especificar los archivos de sonido para el saludocorrespondiente; xivr_bienvenido_pucp contiene un saludo presentando a la institución; xivr_opciones_pucpcontiene la opción de esperar para que sea respondido por algún cliente SIP; xnumero_incorrecto contiene elmensaje 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 puedeacceder 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 AsteriskEl archivo /etc/asterisk/iax.conf se utiliza para la comunicación con otros Asterisk no es nece-

sario que se edite; posee una configuración general; si se hace cambios en este se debe tener en cuenta que estoscambios deben estar reflejados en /etc/asterisk/extensions.conf.

[general];bindport=4569language=esdisallow=allallow=ulawallow=g726aal2allow=gsmallow=ilbcallow=g726;[iaxuser]type=userusername=iaxusercallerid=iaxusersecret=passwdcontext=center;

9.3. Registro de los clientes SIPUna 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: # /etc/init.d/asterisk start Para correr el Asterisknodo-b: # /etc/init.d/asterisk stop Para detener el Asterisknodo-b: # /etc/init.d/asterisk restart Para reiniciar el Asterisk

En este caso se inicia la ejecución del Asterisk; para observar el estado del registro de los clientes y delpropio Asterisk se debe acceder a entorno CLI del Asterisk.

120CAPÍ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 <markster@digium.com>Asterisk comes with ABSOLUTELY NO WARRANTY; type 'show warranty'for details.This is free software, with components licensed under the GNU General PublicLicense version 2 and other licenses; you are welcome to redistribute itunder certain conditions. Type 'show license'for details.=========================================================================Connected to Asterisk 1.2.13 currently running on nodo-b (pid = 7834)Verbosity is at least 4nodo-b*CLI>nodo-b*CLI>sip show peersName/username Host Dyn Nat ACL Port Status10/10 (Unspecified) D 0 UNKNOWN211/211 (Unspecified) D 0 UNKNOWN210/210 (Unspecified) D 0 UNKNOWNnodo-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 mensajeUNKNOWN 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 peersName/username Host Dyn Nat ACL Port Status10/10 10.1.52.3 D 5061 OK (12 ms)211/211 (Unspecified) D 0 UNKNOWN210/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>exitExecuting last minute cleanupsnodo-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 nowExecuting last minute cleanupsnodo-b: # /etc/init.d/asterisk start

Debe asegurarse que el Asterisk esté activo; para esto se puede usar ps -le | grep asterisk si ar-roja 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 quela falla no es debido a la carga de algún módulo; si aún hay fallas se debe seguir observando los mensaje queaparecerá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, entoncesno se podrá usar el comando exit, para esto se debe detener el Asterisk y cargar de nuevo así:

*CLI>stop nownodo-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 apareceOK en Status. El tiempo de registro de los equipos telefónicos deberá ser menor a 50ms; si se tiene un tiempomayor 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 peersName/username Host Dyn Nat ACL Port Status10/10 10.1.52.4 D 5061 OK (12 ms)211/211 (Unspecified) D 0 UNKNOWN210/210 10.1.52.3 D 5060 OK (13 ms)3 sip peers (2 online , 1 offline)

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 éstallamada en el CLI del Asterisk la correcta ejecución de los comandos:

122CAPÍ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 seestá 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 channelsPeer User/ANR Call ID Seq (Tx/Rx) Format Hold Last Message20.20.20.199 210 1a234c1f236 00103/00000 0x4 (ulaw) No Tx: ACK20.20.20.113 211 355739771-5 00102/00011 0x4 (ulaw) No Tx: ACK2 active SIP channels voyage-112*CLI>voyage-112*CLI>voyage-112*CLI>core show channelsChannel 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 channels1 active callvoyage-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 ambosAsterisk 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:passwd@20.20.20.13/300|28")

in new stack- Called iaxuser:passwd@20.20.20.13/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; anotarsi esto se realiza sin problemas, comentar sobre la calidad de la conversación; además se debe observar en elCLI de ambos Asterisk si la comunicación se realiza con el codec configurado, si los comandos se ejecutancorrectamente. 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:passwd@20.20.20.13/310|28")

in new stack- Called iaxuser:passwd@20.20.20.13/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 channelsChannel 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:passwd@20.202 active channels1 active callvoyage-112*CLI>voyage-112*CLI>voyage-112*CLI>sip show channelsPeer User/ANR Call ID Seq (Tx/Rx) Format Hold Last Message20.20.20.199 210 1208132620- 00101/00051 0x4 (ulaw) No Rx: ACK1 active SIP channel

124CAPÍ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>

10Caso 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 delos sistemas de comunicación de voz y datos del Proyecto “Mejora de las condiciones de salud de la poblaciónmaterno-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 Madridy ejecutado por la Fundación EHAS y el Grupo de Telecomunicaciones Rurales de la Pontificia UniversidadCatólica del Perú (GTR-PUCP).

El proyecto fue ejecutado en los distritos de Punchana, Mazán y Napo, en la provincia de Maynas, depar-tamento de Loreto. Contempló la interconexión de cinco establecimientos de salud rurales, el Vicariato de SanJosé del Amazonas (donde existe un albergue de reposo para los pacientes y sus familiares que son referidos alHospital Regional de Loreto para atenciones especializadas en la ciudad de Iquitos), la oficina de Radiofoníade la Dirección Regional de Salud y los ambientes de Emergencia del Hospital Regional de Loreto. Adicional-mente esta nueva red ha sido interconectada con la red instalada por el proyecto PAMAFRO que incluyó aonce establecimientos de salud. A la fecha el objetivo ha sido cumplido en su totalidad. Con los sistemas decomunicación de voz y datos operando se está contribuyendo a la reducción de la morbi-mortalidad MaternoInfantil en esta zona rural aislada del Perú.

Figura 10.1: Departamento de Loreto (izquierda) y Provincia de Maynas (derecha).

125

126 CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR

10.2. 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 delHospital Regional de Loreto, Planta de Ventas PetroPerú y Vicariato (Distrito de Punchana); CS Mazán y PSHuamá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 fueronbeneficiados con la instalación del sistema de transmisión de voz y datos:

Ítem Establecimiento Latitud Longitud Altura (msnm)01 Emergencia HRL 3∘43’33.85” 73∘15’09.44” 10502 Radiofonía DISA Loreto 3∘43’32.78” 73∘15’15.49” 10503 Vicariato 3∘43’34.13” 73∘14’29.50” 10504 CS Mazán 3∘29’51.70” 73∘05’29.70” 11505 PS Huamán Urco 3∘19’07.10” 73∘13’04.30” 11606 PS Tuta Pishco 3∘06’35.00” 73∘08’19.00” 10607 PS Negro Urco 3∘01’14.20” 73∘23’26.80” 13908 PS Tacsha Curaray 2∘48’48.00” 73∘32’27.00” 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 laTabla 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 delos establecimientos de salud y de las instalaciones que forman parte de la red troncal del sistemade transmisión de voz y datos:

10.2 Descripción General de la Red de Comunicaciones 127

Item Torres y/o Soportes Latitud Longitud Altura (msnm)01 Hospital Regional de Loreto 3∘43’33.80” 73∘15’12.17” 10502 Planta de Ventas PetroPerú 3∘43’32.29” 73∘14’36.25” 10503 Mazán 3∘29’59.90” 73∘05’28.00” 10904 Huamán Urco 3∘19’07.60” 73∘13’01.90” 11605 Tuta Pishco 3∘06’31.40” 73∘08’17.50” 10606 Negro Urco 3∘01’23.10” 73∘23’31.50” 13107 Tacsha Curaray 2∘48’47.60” 73∘32’27.20” 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 instalacionesmencionadas 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 Enlaces Distancia (Km)01 HRL PetroPerú 1.1102 PetroPerú Mazán 30.2303 Mazán Huamán Urco 24.52

04 HuamánUrco

Tuta Pishco 24.93

05 Tuta Pishco Negro Urco 29.7406 Negro Urco Tacsha Curaray 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 lared 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 cuentacon un cliente, salvo el caso del repetidor ubicado en el Hospital Regional de Loreto, el cuál cuenta con dosclientes. 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 TroncalesHaciendo 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 mejorrendimiento utilizando equipos inalámbricos 802.11b para los enlaces rurales (desde Tacsha Curaray hastaMazán) y utilizando equipos inalámbricos 802.11a para los enlaces urbanos (desde Mazán hasta el HospitalRegional de Loreto). Ver Tabla 4.

Luego de realizado los trabajos de instalación se han adquirido los datos georeferenciales finales de cadaestació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 Estándar01 HRL PetroPerú 802.11a02 PetroPerú Mazán 802.11a03 Mazán Huamán Urco 802.11b

04 HuamánUrco

Tuta Pishco 802.11b

05 Tuta Pishco Negro Urco 802.11b06 Negro Urco Tacsha Curaray 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): 5180Frecuencia máxima (MHz): 5805Modo estadístico: Difusión: 90 % tiempo / 80 % ubicaciones / 80 % situacionesClima: Continental Sub-TropicalSistema empleado: R52H (tx: 80mW rx: -90dBm) en modo 802.11aTipo de antena: Directiva tipo grilla de 27dBi de gananciaPé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 131

Parámetros del enlace urbano PetroPerú – Mazán

Frecuencia mínima (MHz): 5180Frecuencia máxima (MHz): 5805Modo estadístico: Difusión: 90 % tiempo / 80 % ubicaciones / 80 % situacionesClima: Continental Sub-TropicalSistema empleado: R52H (tx: 250mW rx: -90dBm) en modo 802.11aTipo de antena: Directiva tipo grilla de 27dBi de gananciaPérdida de línea: 0.5dB

Figura 10.9: Perfil del enlace PetroPerú – Mazán.

Figura 10.10: Enlace PetroPerú – Mazán.

132 CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR

Parámetros del enlace rural Mazán – Huamán Urco

Frecuencia mínima (MHz): 2400Frecuencia máxima (MHz): 2483Modo estadístico: Difusión: 90 % tiempo / 80 % ubicaciones / 80 % situacionesClima: Continental Sub-TropicalSistema empleado: R52H (tx: 320mW rx: -95dBm) en modo 802.11bTipo de antena: Directiva tipo grilla de 27dBi de gananciaPé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 133

Parámetros del enlace rural Huamán Urco – Tuta Pishco

Frecuencia mínima (MHz): 2400Frecuencia máxima (MHz): 2483Modo estadístico: Difusión: 90 % tiempo / 80 % ubicaciones / 80 % situacionesClima: Continental Sub-TropicalSistema empleado: R52H (tx: 320mW rx: -95dBm) en modo 802.11bTipo de antena: Directiva tipo grilla de 27dBi de gananciaPé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.

134 CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR

Parámetros del enlace rural Tuta Pishco – Negro Urco

Frecuencia mínima (MHz): 2400Frecuencia máxima (MHz): 2483Modo estadístico: Difusión: 90 % tiempo / 80 % ubicaciones / 80 % situacionesClima: Continental Sub-TropicalSistema empleado: R52H (tx: 320mW rx: -95dBm) en modo 802.11bTipo de antena: Directiva tipo grilla de 27dBi de gananciaPé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 135

Parámetros del enlace rural Negro Urco – Tacsha Curaray

Frecuencia mínima (MHz): 2400Frecuencia máxima (MHz): 2483Modo estadístico: Difusión: 90 % tiempo / 80 % ubicaciones / 80 % situacionesClima: Continental Sub-TropicalSistema empleado: R52H (tx: 320mW rx: -95dBm) en modo 802.11bTipo de antena: Directiva tipo grilla de 27dBi de gananciaPérdida de línea: 0.5dB

Figura 10.17: Perfil del enlace Negro Urco – Tacsha Curaray.

Figura 10.18: Enlace Negro Urco – Tacsha Curaray.

136 CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR

10.3.2. Características de los Equipos Instalados10.3.2.1. Equipos empleados en los enlaces troncales de 2.4GHz – 802.11b/g

Equipo Fabricante Modelo Características

Interface802.11b/g

UbiquitiNetworks

SR2 SuperRange 2

Interface 2.4GHz 802.11b/g mini-PCIChipset Atheros AR5213 MAC/BBPotencia de transmisión real de 24dBm, +/-1dBpara una tasa de 1-24 MbpsSensibilidad para unatasa de 5.5Mbps de -95dBm, (en estándar 802.11b)Consumo de corriente @3.3VTransmisión:1-24 Mbps 1300mA, +/-100mARecepción:350mA, +/-50mA

AntenaHyperlinkTechnolo-gies

HG2424GAntena direccional2.4GHz Banda ISM 24dBiPeso: 3.62Kgs

Router -Computado-ra

PC Engines ALIX 2C0

233 MHz AMD Geode SC1100 CPU128 MB SDRAMAlmacenamiento a través de una Compact Flash.Consume alrededor de 3 a 5W con 12V DC2 Puertos Ethernet2 Puertos miniPCISistema operativo: Pebble Linux, Voyage Linux,AstLinux, AspisOS, iMedia Wrap Linux, etc.El sistema operativo instalado es laVoyage-GTR-0.4

CablesCoaxiales

HeliaxSuperFlex

Impedancia característica : 50 ΩPérdida por metro : 0.1 dBConectores usados : N macho

Cablespigtail Hyperlink

Un extremo conector: UFL (Compatible conHirose/iPax/Mini-PCI).Otro extremo conector: N hembraLongitud: 20cmFrecuencia 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 137

10.3.2.2. Equipos empleados en los enlaces troncales de 5.8GHz – 802.11a

Equipo Fabricante Modelo Características

Interface802.11a

Mikrotik R52H

Interface 5.8GHz 802.11a/b/g mini-PCIChipsetPotencia de transmisión real 24dBmSensibilidad -90dBm @ 6Mbps

AntenaHyperlinkTechnologies HG5827G

Antena direccional tipo grilla5.8GHz Banda ISM 27dBiPeso: 2.4Kgs

Router -Computado-ra

MikrotikRouterBoard333

333MHz CPU64MB SDRAMConsume 19W con 12V DC3 Puertos Ethernet3 Puertos miniPCISistema operativo:RouterOS 3.20 Licencia nivel 4

CablesCoaxiales

HeliaxSuperFlex

Impedancia característica : 50 Ω

Pérdida por metro : 0.1dBConectores usados : N macho

Cablespigtail Hyperlink

Un extremo conector: UFL (Compatible conHirose/iPax/Mini-PCI).Otro extremo conector: N hembraLongitud: 20cmFrecuencia de trabajo: 2.4GHz – 6GHz.Atenuación: 5.38dB/metro en 6GHz

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ísticasInterfaceinalámbrica

Mikrotik R52HInterface 2.4GHz 802.11a/b/g mini-PCIPotencia de salida máxima en estándar g: 25dBm

AntenasHyperlinkTechnologies HG2414P-NF

2.4 GHz Banda ISMIEEE 802.11b, 802.11g Wireless LANAntena Panel Yagi 14dBi

Routers Linksys WRT54GLRouter, posee 5 puertos Ethernet, 1 puerto Internety punto de acceso Wireless-G (802.11g) a 54 Mbps

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 clientes10.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 dedistribución) implementados en Tacsha Curaray, Negro Urco, Tuta Pishco y Huamán Urco. En cada repetidor sehan instalado dos placas ALIX, las cuales han sido etiquetadas como ALIX n1 y ALIX n2. La placa n1 cuentacon dos tarjetas inalámbricas: una tarjeta SR2 para enlazar con su vecino del norte y una tarjeta inalámbricaR52H encargada de establecer el enlace con su cliente local. En el caso de la placa n2 cuenta con solo una tarjetainalámbrica SR2. La cuál permite el enlace con su vecino del sur. Adicionalmente en ésta placa se encuentrainstalado 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 (TacshaCuraray Negro Urco Tuta Pishco Huamán Urco).

10.3 Descripción de la Red de Telecomunicaciones 139

10.3.3.2. 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 cuentacon una tarjeta inalámbrica SR2 para enlazar con el repetidor de Huamán Urco (2.4GHz) y tiene instalado elservidor Asterisk. La placa MIKROTIK cuenta con dos tarjetas inalámbricas R52H: la primera para enlazar conel repetidor ubicado en Planta de Ventas de PetroPerú (enlace troncal en la frecuencia de 5.8GHz) y la segundatarjeta para el enlace con el Centro de Salud de Mazán (enlace de distribución en la frecuencia de 2.4GHz). Laenergía es proporcionada por el sistema fotovoltaico.

Figura 10.20: Esquema de conexiones de la estación repetidora de Mazán.

140 CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR

10.3.3.3. 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ónque cumple la placa ALIX n2 es ser el servidor Asterisk local. Los enlaces inalámbricos los administra laplaca MIKROTIK n1 mediante tres tarjetas inalámbricas R52H. Los enlaces hacia el repetidor de Mazán y elrepetidor ubicado en el Hospital Regional de Iquitos son enlaces en la frecuencia de 5.8GHz. En el caso delenlace de distribución hacia el Vicariato de San José del Amazonas se realiza en la frecuencia de 2.4GHz. Laenergí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 y5.8GHz)

En el repetidor del Hospital Regional de Loreto se ha instalado una placa MIKROTIK con tres tarjetasinalámbricas R52H. El enlace con el repetidor ubicado en Planta de Ventas se realiza en la frecuencia de5.8GHz. Y los dos enlaces de distribución uno hacia la oficina de Radiofonía de la Dirección Regional de Saludy el segundo hacia los ambientes de Emergencia del Hospital Regional de Loreto se realizan en la frecuenciade 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 poruna 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éctricaEn cada estación rural se han instalado sistemas de energía fotovoltaica con su respectivo sistema de protec-

ción eléctrica tanto en las estaciones repetidoras como los enlaces de distribución. En las siguientes dos figurasse 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 lared pública de Electro Oriente y el sistema de protección eléctrica empleado es el encontrado ya instaladopreviamente 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 deprotección eléctrica.

Figura 10.25: Esquema del sistema de energía en una estación repetidora rural y de su sistema deprotecció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 linealesen el caso de las estaciones clientes y de 20m de longitud en forma cuadrada alrededor de la base de la torreventada. 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 sistemade protección eléctrica instalada y supervisada por la misma empresa. Similar caso se presenta en con el repeti-dor ubicado en el Hospital Regional de Loreto donde los equipos han sido aterrados al sistema de proteccióneléctrica del mismo hospital.

En la siguiente tabla se detalla las lecturas de resistencia de los pozos de tierra construidos en las comu-nidades de Negro Urco, Tuta Pishco, Huamán Urco y Mazán.

Resistencia de los Pozos TierraEstablecimiento Estación Cliente (Ω) Estación Repetidora (Ω)Mazán 8.65 7.11Huamán Urco 1.65 5.32Tuta Pishco 3.81 6.75Negro Urco 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-HopWi-Fi Chain Network”, Wireless Broadband and Ultra Wideband Communications, 2007. AusWireless2007. 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 KFall,“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, IEEECommunications Magazine, Jan 2007, Special Issue on New Directions In Networking Technologies InEmerging Economies.

[5] Francisco Javier Simó Reigadas, “Modelado y Optimización de IEEE 802.11 para su aplicación en eldespliegue 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”, PrimeraEdición, 2008http://gtr.telecom.pucp.edu.pe/

[7] Long Distance Wireless Mesh Network Planning: Problem Formulation and Solution, Sayandeep Senand Bhaskaran Raman. The 16th Annual Interntional World Wide Web Conference (WWW 2007), May2007, 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 Environ-ments”, Proc. IFIP WCIT, Santiago, Chile, Aug. 2006.

[10] Rabin Patra and Sergiu Nedevschi, “Design and Implementation of High Performance WiFi BasedLong 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-hopwireless 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 onTCP 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] Mikrotikhttp://www.routerboard.com/

[21] PC Engines.http://www.pcengines.ch/

BIBLIOGRAFÍA 147

[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/

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 Glosario

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 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 elreceptor.

SIP Session Initiation Protocol.

SMTP Simple Mail Transfer Protocol.

SNMP Simple Network Management Protocol.

SNR Signal Noise Ratio.

SREJ Rechazo selectivo de paquetes.

152 Glosario

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.

154 Glosario