Enlaces Wifi Larga Distancia

WiLD
WiFi Based Long Distance

Primera Edicin
Grupo de Telecomunicaciones Rurales
Ponticia Universidad Catlica del Per
Publicacin nanciada por FINCYT
Lima, Agosto 2009
WiLD
WiFi Based Long Distance
Ponticia Universidad Catlica del Per
Grupo de Telecomunicaciones Rurales
GTR-PUCP, http://gtr.telecom.pucp.edu.pe
Edicin: Daniel Carbajal, Jeffry Cornejo, Jos Luis Vargas, Luis Camacho, Aldo Duarte, Renzo
Navarro, Yuri Pacheco.
c 2009, GTR-PUCP
Primera edicin: Agosto 2009
Hecho el Depsito Legal en la Biblioteca Nacional del Per
2009-09928
ISBN: 978-9972-659-93-5
Autores: Luis Camacho, River Quispe, Csar Crdova, Leopoldo Lin, David Chvez.
Esta publicacin ha sido elaborada gracias al nanciamiento del Programa de Ciencia y Tecnologa
FINCYT.
Los autores de este libro no se responsabilizan de los incidentes o daos que pudiera ocasionar la
utilizacin de la informacin contenida en l.
Este libro est publicado bajo la licencia Reconocimiento-Uso no Comercial-Compartir por Igual,
versin 2.5, de Creative Commons Per.
http://creativecommons.org/licenses/by-nc-sa/2.5/pe/legalcode
ndice general
ndice general 1
Introduccin 7
1. Redes WiFi para largas distancias 13
1.1. Estndares WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2. Problemtica del uso de WiFi para largas distancias . . . . . . . . . . . . . . . . . . 15
1.2.1. Capa fsica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.2. Capa MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3. Uso de telefona IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4. Arquitectura de redes WiFi para larga distancia . . . . . . . . . . . . . . . . . . . . 19
2. Hardware y software apropiados para la construccin de routers WiFi de larga distancia 25
2.1. Placa SBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.1. Tipo de procesador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.2. Descripcin de SBCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.2.1. RouterBOARD 532A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.2.2. RouterBOARD 333 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.2.3. Alix2C0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.2.4. Pronghorn SBC-250 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.2.5. Pronghorn Metro SBC Quad-Radio Wireless . . . . . . . . . . . . . . . . 30
2.1.3. Comparacin de SBCs para aplicacin de redes inalmbricas . . . . . . . . . . 32
2.2. Tarjetas de red inalmbrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2.1. Comparacin de tarjetas de red inalmbricas . . . . . . . . . . . . . . . . . . . 33
2.2.2. Pigtails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2.3. Antenas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3. Sistema Operativo Linux Voyage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.1. Caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4. Driver MadWi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.1. HAL y OpenHAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1
2.4.2. Ath5k y Ath9k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.3. Caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4.4. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.5. Quagga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3. Software PBX Asterisk 45
3.1. VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2. Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3. Protocolos VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.1. IAX (Inter Asterisk eXchange) . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.2. SIP (Session Initiation Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.3.2.1. Elementos del SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.3.2.2. Flujo de establecimiento de una sesin SIP . . . . . . . . . . . . . . . . . 55
3.3.3. Protocolo de Descripcin de Sesin SDP . . . . . . . . . . . . . . . . . . . . . 56
3.3.4. Protocolos RTP/RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4. Enrutamiento Dinmico 59
4.1. Tipos de Enrutamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.1. Tabla de Enrutamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.2. Enrutamiento Esttico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.1.3. Enrutamiento Dinmico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2. Enrutamiento Dinmico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.1. Tipos de Protocolos de Enrutamiento Dinmico: . . . . . . . . . . . . . . . . . 61
4.2.2. Caractersticas de los Protocolos de Enrutamiento Dinmico . . . . . . . . . . . 62
4.2.2.1. Algoritmo de enrutamiento Vector Distancia . . . . . . . . . . . . . . . . . 62
4.2.2.2. Algoritmo de enrutamiento de Estado Enlace . . . . . . . . . . . . . . . . 63
4.2.2.3. Enrutamiento con clase y sin clase . . . . . . . . . . . . . . . . . . . . . . 63
4.2.2.4. Convergencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.2.5. Balance de Carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.3. Mtrica y distancia administrativa . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3. OSPF, Open Shortest Path First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.1. reas y clases de routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3.2. Costo en OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.2.1. rbol de la ruta ms corta . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.2.2. Tipo de Interfaces de redes . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3.2.3. Rutas externas de tipo1 y tipo2 . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4. Funcionamiento de OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4.1. Encapsulamiento de paquetes en OSPF . . . . . . . . . . . . . . . . . . . . . 70
4.4.2. Tipos de LSA (Link State Advertisement) . . . . . . . . . . . . . . . . . . . . 72
4.4.3. Estados OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5. Voyage GTR 77
5.1. Identicacin de las aplicaciones a implementar . . . . . . . . . . . . . . . . . . . . 77
5.2. Conguracin rpida mediante archivos de las interfaces de red (Ethernet y WiFi) . . 78
5.3. Conguracin rpida de enrutamiento esttico . . . . . . . . . . . . . . . . . . . . . 79
5.4. Seguridad WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.5. Enrutamiento dinmico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.6. Telefona IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.7. Conguracin va web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.8. Adaptacin de Voyage para el trabajo en entornos rurales . . . . . . . . . . . . . . . 82
6. Conguracin e Instalacin de Voyage GTR 85
6.1. Comandos generales en Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1.1. Comando ls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1.2. Comando mkdir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1.3. Comando rm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1.4. Comando fdisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.1.5. Comando dmesg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.1.6. Comando lspci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.1.7. Comando ps aux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.1.8. Comando kill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.1.9. Comando hostname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.1.10. Comando tail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.1.11. Comando ifcong . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.1.12. Comando ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.1.13. Comando ssh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.1.14. Comando route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.2. Instalacin de Voyage GTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.3. Acceso inicial por puerto serial o por Ethernet . . . . . . . . . . . . . . . . . . . . . 91
6.4. Edicin de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.5. Estructura de archivos de Voyage GTR . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.6. Guardar archivos o carpetas de /rw . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.7. Conguracin previa a cualquier aplicacin en Voyage GTR . . . . . . . . . . . . . 94
6.8. Obtencin de respaldo de la conguracin de las aplicaciones en Voyage GTR . . . . 95
6.9. Vericacin del estado de Voyage GTR . . . . . . . . . . . . . . . . . . . . . . . . 95
6.9.1. Espacio ocupado y disponible . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.9.2. RAM libre y CPU desocupado en un instante . . . . . . . . . . . . . . . . . . . 96
6.9.3. Fecha del sistema y ltimo reinicio . . . . . . . . . . . . . . . . . . . . . . . . 96
7. Conguracin de Redes con Voyage GTR 99
7.1. Interfaces de Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.2. Conguracin de las interfaces de red . . . . . . . . . . . . . . . . . . . . . . . . . 100
7.2.1. Conguracin de Ethernet y de Bridge Ethernet . . . . . . . . . . . . . . . . . 100
7.2.2. Conguracin de las interfaces WiFi . . . . . . . . . . . . . . . . . . . . . . . 101
7.3. Conguracin del enrutamiento esttico, gateway y NAT . . . . . . . . . . . . . . . 103
7.4. Conguracin del enrutamiento dinmico con OSPF . . . . . . . . . . . . . . . . . 103
7.5. Conguracin del DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.6. Conguracin de interfaces WiFi y de parmetros TCP/IP mediante comandos . . . . 106
8. Vericacin del Estado de la Red de Datos 109
8.1. Conectividad en enlaces AP-STA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
8.1.1. Nivel de seal del enlace y relacin de la calidad del enlace . . . . . . . . . . . 109
8.1.2. Cantidad de clientes conectados al AP . . . . . . . . . . . . . . . . . . . . . . 112
8.1.3. Correccin del alineamiento de las antenas . . . . . . . . . . . . . . . . . . . . 112
8.1.4. Ping normal entre las interfaces del enlace . . . . . . . . . . . . . . . . . . . . 115
8.1.5. Ping con mayor tamao entre las interfaces del enlace . . . . . . . . . . . . . . 117
8.1.6. Medicin en el rendimiento de un enlace . . . . . . . . . . . . . . . . . . . . . 117
8.1.7. Vericacin de la tabla de rutas y la ruta de salida . . . . . . . . . . . . . . . . 118
8.1.8. Ping a todas las interfaces de red . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.2. Conectividad en una red troncal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.2.1. Ping a todas las interfaces de red . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.2.2. Medicin del rendimiento de la troncal . . . . . . . . . . . . . . . . . . . . . . 120
9. Conguracin de una red de Telefona IP con Asterisk 121
9.1. Conguracin inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
9.2. Conguracin bsica de Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
9.2.1. Conguracin de los clientes SIP . . . . . . . . . . . . . . . . . . . . . . . . . 122
9.2.2. Programacin de las llamadas telefnicas . . . . . . . . . . . . . . . . . . . . . 123
9.2.3. Identicacin de direcciones IP de los servidores Asterisk . . . . . . . . . . . . 124
9.2.4. Grabacin de archivos de sonido . . . . . . . . . . . . . . . . . . . . . . . . . 125
9.2.5. Conguracin de IVR bsico . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
9.2.6. Comunicacin con otros servidores Asterisk . . . . . . . . . . . . . . . . . . . 125
9.3. Registro de los clientes SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9.4. Vericacin del estado de telefona IP con Asterisk . . . . . . . . . . . . . . . . . . 128
9.4.1. Estado del registro de clientes y tono en los telfonos . . . . . . . . . . . . . . . 128
9.4.2. Llamada de prueba al servidor de telefona IP . . . . . . . . . . . . . . . . . . . 128
9.4.3. Llamada de prueba a un cliente local . . . . . . . . . . . . . . . . . . . . . . . 128
9.4.4. Llamada de prueba al resto de servidores de telefona IP . . . . . . . . . . . . . 129
9.4.5. Llamada de prueba a un cliente administrado por otro servidor . . . . . . . . . . 129
10. Caso de Estudio: Red Napo Sur 131
10.1. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
10.2. Descripcin General de la Red de Comunicaciones . . . . . . . . . . . . . . . . . . 132
10.3. Descripcin de la Red de Telecomunicaciones . . . . . . . . . . . . . . . . . . . . . 135
10.3.1. Enlaces Troncales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
10.3.2. Caractersticas de los Equipos Instalados . . . . . . . . . . . . . . . . . . . . . 144
10.3.2.1. Equipos empleados en los enlaces troncales de 2.4GHz 802.11b/g . . . . 144
10.3.2.2. Equipos empleados en los enlaces troncales de 5.8GHz 802.11a . . . . . 147
10.3.2.3. Equipos empleados en los enlaces de distribucin de 2.4GHz 802.11g . . 148
10.3.3. Distribucin de los equipos en los repetidores y estaciones clientes . . . . . . . 149
10.3.3.1. Distribucin en los repetidores de Tacsha Curaray, Negro Urco, Tuta Pishco
y Huamn Urco (enlaces en 2.4GHz) . . . . . . . . . . . . . . . . . . . . . 149
10.3.3.2. Distribucin en el repetidor de Mazn (enlaces en 2.4GHz y 5.8GHz) . . . 150
10.3.3.3. Distribucin en el repetidor de PetroPer (enlaces en 2.4GHz y 5.8GHz) . . 151
5
10.3.3.4. Distribucin en el repetidor del Hospital Regional de Loreto (enlaces en
2.4GHz y 5.8GHz) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
10.3.3.5. Distribucin en las estaciones clientes (enlaces de distribucin) . . . . . . . 152
10.3.4. Sistema de Energa y Proteccin Elctrica . . . . . . . . . . . . . . . . . . . . . 153
Bibliografa 157
Glosario 161
6
Introduccin
Este libro es una nueva iniciativa del Grupo de Telecomunicaciones Rurales de la Ponticia Uni-
versidad Catlica del Per (GTR-PUCP) para contribuir a la ampliacin y difusin del conocimiento
existente sobre tecnologas apropiadas para el acceso a la informacin y comunicacin en zonas ru-
rales.
En tal sentido, este libro tiene varios propsitos:
Compartir el conocimiento generado y/o utilizado por GTR-PUCP.
Incrementar la bibliografa en castellano sobre tecnologas apropiadas para zonas rurales.
Servir de partida para futuras actualizaciones conforme aumente la informacin disponible.
La mayor parte de los contenidos de este libro han sido gestados gracias al aporte nanciero de
FINCyT, el Fondo de Inversin en Ciencia y Tecnologa, http://www.fincyt.gob.pe; una ini-
ciativa del Estado Peruano para contribuir al incremento de la competitividad del pas, fortaleciendo
las capacidades de investigacin e innovacin tecnolgica y promoviendo la articulacin de la Em-
presa, Universidad y Estado.
El libro es llamado WiLD, WiFi based Long Distance, citando un trmino probablemente acuado
por TIER, Technology and Infraestructure for Emerging Regions, un grupo de investigacin de la
Universidad de California en Berkeley. El trmino hace referencia al conjunto de soluciones para la
transmisin inalmbrica de voz y datos basados en el protocolo 802.11, y cuya virtud ms notable, es
alcanzar enlaces de muy larga distancia (entre 50 y 100 km), mucho mayores que las distancias para
las que originalmente fue diseado el protocolo 802.11.
El ttulo es apropiado pues este libro trata sobre Voyage GTR, un sistema operativo basado en la
distribucin Linux Voyage, a la cual se han aadido aplicaciones hasta obtener un sistema operativo
especco (un rmware 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 gura:
7
8
Figura 1: Router Inalmbrico Integrado
Por qu es importante que exista un equipo de largo alcance?
La gran cobertura es una de las varias caractersticas que hace que los routers Voyage GTR sean
apropiados para la creacin de redes en zonas rurales.
Estructura del Libro:
En el primer captulo se narra la problemtica del uso del protocolo 802.11 para la transmisin
de voz y datos en enlaces de larga distancia, tomando en cuenta que este protocolo naci como una
solucin para redes LAN.
En el segundo captulo se describen y explican el hardware y software empleados para la construc-
cin de routers Voyage GTR. Todas estas herramientas estn enmarcadas en el mundo del software y
hardware libres.
En los captulos tres y cuatro se narran aspectos tericos de dos de las caractersticas ms impor-
tantes dentro de Voyage GTR: Telefona IP y Encaminamiento Dinmico OSPF. Estas dos propiedades
se implementan a travs de los programas Asterisk y Quagga.
En el quinto captulo se describe Voyage GTR y todas las modicaciones y aplicaciones adidas
a Linux Voyage para conseguir el producto nal.
En los captulos seis, siete y ocho se detalla los aspectos tcnicos del uso de Voyage GTR: la
instalacin y conguracin bsica, conguracin de redes cableadas e inalmbricas y la vericacin
del estado de una red instalada.
En el noveno captulo se detalla los aspectos tcnicos de la instalacin de un sistema de telefona
9
IP utilizando Asterisk.
Finalmente en el dcimo captulo se presenta un caso de estudio, la red Napo Sur (provincia de
Maynas, regin Loreto en Per), perteneciente a la Direccin Regional de Salud de Loreto, Per; mon-
tada con routers Voyage GTR. Esta red sumada a la parte Norte (tambin instalada con los mismos
equipos) forman en conjunto probablemente la red en servicio WiFi multisalto ms larga del planeta.
Zonas rurales en pases en vas de desarrollo
Las zonas rurales aisladas de pases en vas de desarrollo son el contexto vital de ms de la mitad
de la poblacin mundial, pese a lo cual es generalizada su casi total carencia de infraestructuras de
comunicacin y acceso a la informacin. La pretensin de dotar a estas zonas de conectividad a redes
de voz y datos ha sido en los ltimos aos una preocupacin del mayor orden de los agentes interna-
cionales multilaterales de desarrollo, ya que en algunos casos se puede considerar un servicio bsico,
y en todos es un sustrato de gran importancia para el desarrollo y la promocin humana. No obstante,
todos los esfuerzos por generalizar el acceso a redes de comunicacin en zonas aisladas de pases en
desarrollo suelen topar desde los primeros pasos con la ausencia de soluciones tecnolgicas realmente
apropiadas, realistas y sostenibles, debido en gran parte a las siguientes caractersticas especcas de
estos contextos:
No slo se carece de infraestructuras de telecomunicacin; tambin suele ser prcticamente
inexistente o de mala calidad la infraestructura de electricacin y, en muchos casos las vas
de acceso. La necesidad de dotar a los sistemas de telecomunicacin de alimentacin elctrica
autnoma para garantizar su funcionamiento continuo y su durabilidad los encarece y diculta
su mantenimiento, y la ausencia de vas de acceso tambin encarece y diculta tanto el de-
spliegue de redes como su mantenimiento.
El personal tcnico cualicado necesario para el mantenimiento y operacin de estas tec-
nologas suele encontrarse en las ciudades, y resulta caro y difcil contar con l en estas zonas.
La poblacin es pobre y dispersa, por lo que no puede soportar los costes de infraestructuras
caras de instalar, mantener y operar. Tampoco los estados de los pases en vas de desarrollo
estn en condiciones de poder subvencionar la instalacin de redes de comunicaciones rurales
en pro de la cobertura total, tanto por su falta de recursos como por la enorme proporcin que
las poblaciones rurales no contributivas representan en el total.
10
Caractersticas de las soluciones tecnolgicas para este contexto
Este contexto no slo explica la causa de esa prctica incomunicacin de la mitad del mundo
habitado, sino que tambin determina las especicaciones de cualquier solucin tecnolgica que se
pretenda aplicar de manera sostenible en entornos rurales de pases en desarrollo:
Tiene que ser robusta y sencilla de usar, ya que los usuarios van a ser poco cualicados y no
van a contar con el apoyo continuo de asesores preparados.
Tiene que requerir poco o ningn mantenimiento de tcnicos especializados, ya que stos van
a estar lejos y va a resultar caro y difcil atraerlos para la resolucin de los problemas. Con ms
razn debe ser mnima la necesidad de administracin de las redes, ya que sta genera costes
jos considerables.
Debe ser de bajo consumo, ya que frecuentemente tendr que depender de instalaciones de
energas fotovoltaicas o elicas que encarecen las instalaciones y aumentan las necesidades y
costes de mantenimiento.
Debe tener costes de despliegue y de operacin muy bajos. sto excluye las redes cableadas, las
de telefona mvil y las redes satlite como soluciones nicas. En ocasiones se puede plantear
el acceso al mundo de toda una red por estos medios, pero la distribucin del acceso se tendr
que hacer con una tecnologa complementaria ms barata. Este criterio tambin desaconseja en
muchos casos las redes radio en bandas de frecuencia licenciadas.
Con estos condicionantes, el GTR-PUCP ha trabajado desde 1999 en varias lneas de investigacin
que persiguen determinar cuales son las tecnologas inalmbricas ms apropiadas a zonas rurales
aisladas de pases en desarrollo, mejorarlas y aplicarlas de forma ptima. En [6] se describen distintas
tecnologas propuestas para la instalacin de redes de telecomunicaciones en este contexto. Todas
ellas son inalmbricas, ya que dadas las caractersticas descritas anteriormente, una red cableada sera
muy costosa de instalar y mantener. En el presente libro se profundizar sobre el uso de la alternativa
tecnolgica basada en WiFi.
1
Redes WiFi para largas distancias
Desde el 2001, una de las tecnologas que se ha tomado en consideracin muy seriamente para
las comunicaciones de largas distancias es la IEEE802.11, popularmente llamada WiFi; si bien este
estndar 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 inters de diversos agentes tecnolgicos de
pases en desarrollo. Incluso en los ncleos urbanos de muchos pases se han dado experiencias de
aplicacin de WiFi para distribuir el acceso a Internet con la mayor cobertura posible en exteriores.
Adems, el enorme xito de WiFi en todos los mbitos ha dado lugar a una gran cantidad de productos
en el mercado, casi todos ellos de bajo consumo, a precios bajos y mucha exibilidad de uso, espe-
cialmente en combinacin con desarrollos de software abierto. Respecto al uso de frecuencias en los
casos en que no hay un vaco legal, la mayor parte de los estados adoptan las restricciones de la FCC
en el uso de las banda ISM 2.4GHz y 5.8GHz usadas por esta tecnologa. Como se puede apreciar en
el Cuadro 1.1, estas normas son mucho ms permisivas que las europeas y permiten realizar en las
zonas rurales enlaces tanto punto a punto (PtP) como punto a multipunto (PtMP) de varias decenas
de kilmetros.
Mxima potencia Dominio legal Normativa
transmisible
1000mW USA y muchos pases en FCC 15.247
desarrollo
100mW Europa ETS 300-328
10 mW Japn MTP Ordenance for Regulating
Radio Equipment, Article 49-20
Cuadro 1.1: Mxima potencia transmisible en 2.4 GHz por regiones.
Las ventajas e inconvenientes que presenta el uso de esta tecnologa se indican a continuacin:
11
12 CAPTULO 1. REDES WIFI PARA LARGAS DISTANCIAS
Ventajas:
Uso de frecuencias sin licencia de las bandas ISM 2.4 / 5.8 GHz con ciertas limitaciones de
potencia.
Velocidades desde 1 hasta 54 Mbps, siempre teniendo en cuenta que el throughput neto obtenido
est alrededor de un 50-70 % de esos valores.
Tecnologa con estndar ampliamente conocido y fcil de congurar, lo que favorece los bajos
costes de los equipos.
Bajo consumo de potencia, menor a 10 W por enrutador.
Flexibilidad: un nodo puede adherirse a la red si puede ver a uno de los nodos vecinos (las
zonas rurales aisladas normalmente no siguen una distribucin geomtrica ordenada alrededor
de un punto central).
Hardware fcilmente integrable en un sistema impermeable que soporte condiciones meteo-
rolgicas adversas.
Inconvenientes:
Requiere lnea de vista directa (esto podra elevar, en algunos casos, el nmero de repetidores
necesarios aumentando demasiado el costo).
Al ser una tecnologa creada para redes de corto alcance, hay que solventar ciertos problemas
relacionadas con su utilizacin para distancias de decenas de Km.
El nmero de colisiones aumenta en relacin con el nmero de usuarios.
Tiene un nmero limitado de canales no interferentes, 3 en 2.4 GHz y 8 en 5.8 GHz.
1.1. Estndares WiFi
La familia de estndares IEEE 802.11 (802.11a, 802.11b y 802.1g), ms conocida como WiFi,
tiene asignadas las bandas ISM (Industrial, Scientic and Medical) 902-928 MHz, 2.400-2.4835 GHz,
5.725-5.850 GHz para uso en las redes inalmbricas basadas en espectro ensanchado con objeto de
lograr redes de rea local inalmbricas (WLAN).
WiFi comparte la mayora de su funcionamiento interno con Ethernet, sin embargo diere en
la especicacin de la capa fsica (PHY) utilizando seales radio en lugar cable y en su capa de
control de acceso al medio (MAC), ya que para controlar el acceso al medio Ethernet usa CSMA/CD,
mientras que WiFi usa CSMA/CA. El gran ancho de banda (entre 1 y 11 Mbps para 802.11b y hasta
54Mbps para 802.11a/g) a un precio reducido, lo presenta como una de las mejores opciones para la
transmisin de datos y redes de telefona empleando VoIP(voz sobre IP).
Existe una gran diferencia entre los distintos estndares WiFi. Es por ello que a continuacin se
realiza una presentacin terica ms detallada de cada uno de ellos.
El estndar 802.11 fue aprobado por el IEEE en 1997, permitiendo trabajar con velocidades de
transmisin de 1Mbps y 2Mbps. El estndar IEEE802.11b primero, y luego los estndares IEEE802.11a
1.2 Problemtica del uso de WiFi para largas distancias 13
y IEEE802.11g, aadieron nuevas tcnicas de modulacin en la capa fsica logrando mayores veloci-
dades de transmisin y una mayor robustez en la conectividad.
El estndar IEEE802.11a trabaja en la banda de frecuencia de los 5GHz utilizando la tcnica de
transmisin OFDM. Da soporte a velocidades de transmisin de 6Mbps a 54Mbps y ocho canales
no interferentes de 20MHz. Esta banda de frecuencia est menos saturada que la de 2.4GHz, lo cual
es una ventaja, ya que la banda de 2.4GHz tambin es utilizada por algunos telfonos inalmbri-
cos, hornos microondas y equipos Bluetooth. El gran inconveniente de este estndar es el de no ser
compatible con el IEEE802.11b, mucho ms difundido.
El estndar IEEE802.11b trabaja en la banda de frecuencia de 2.4GHz utilizando el sistema de
transmisin HR/DSSS. Mediante el uso de la modulacin CCK se da soporte a las velocidades de
transmisin de 5.5Mbps y 11Mbps. Se cuenta con catorce canales (que pueden estar limitados a once
o trece segn el pas) de 22MHz, de los cuales se pueden utilizar simultaneamente hasta tres de forma
no interferente.
El estndar IEEE802.11g fue desarrollado a raz del importante problema de incompatibilidad
entre los equipos de IEEE802.11a y IEEE802.11b. Adems, la creacin de este estndar atenda al
inters en incrementar la capacidad de los equipos y redes WiFi. IEEE802.11g trabaja en la banda de
frecuencia de 2.4GHz, manteniendo adems los mismos canales y modulaciones de IEEE802.11b, y
aade el sistema OFDM mediante el cual se soportan velocidades de transmisin de hasta 54Mbps.
1.2. Problemtica del uso de WiFi para largas distancias
Dado que la que la tecnologa WiFi fue en su inicio diseada para redes locales, la mayor dicultad
reside en su aplicacin para largas distancias.
1.2.1. Capa fsica
Sin embargo, una cuidadosa revisin del estndar no deja entrever ningn elemento de la capa
fsica que limite el alcance de las comunicaciones WiFi en trminos de distancia si no es el balance de
enlace. Los lmites fsicos de distancia alcanzable con WiFi dependern, por lo tanto, de los siguientes
parmetros:
La mxima potencia que podamos transmitir (PIRE).
Las prdidas de propagacin.
La sensibilidad de recepcin.
La mnima relacin seal a ruido que estemos dispuestos a aceptar como suciente.
El propio estndar determina que los lmites de potencia que se puede transmitir dependen de la
legislacin que atae a la banda de frecuencias ISM para cada regin geogrca, stas se mostraron
en la Cuadro 1.1.
Adems, hay algunos aspectos de la capa fsica que deben ser tenidos en cuenta para obtener una
mayor estabilidad en el enlace:
Velocidad. El protocolo IEEE802.11 recoge distintas velocidades segn 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
conjunto de todas las anteriores para el modo 802.11g. Estos modos usan diferentes tipos de
modulacin y codicacin, de forma que cuanto mayor sea la velocidad, mayor es la poten-
cia necesaria en recepcin para mantener un enlace con una BER baja. Esta potencia, llamada
sensibilidad, obliga a usar velocidades bajas si se quiere lograr enlaces de larga distancia con
una cierta estabilidad. La diferencia en la sensibilidad de recepcin entre 1 y 11Mbps, aunque
depende de equipos, suele ser de ms de 10 dB, lo cual equivale prcticamente a cuadruplicar
con 1Mbps el alcance que se tiene con 11Mbps. Si adems se tiene en cuenta que la banda ISM
2.4 GHz impone limitaciones en cuanto al nivel de potencia que es legal transmitir, es fcil
comprobar que para enlaces muy largos normalmente deben usarse las velocidades ms bajas
de 802.11b para tener estabilidad y buena calidad. La aparicin de tarjetas con mejores sensibil-
idades o la tecnologa 802.11g pueden ayudar a lograr velocidades mayores. As, por ejemplo
en el modelo de tarjeta Ubiquiti SR2 802.11b/g de 400mW, la diferencia de sensibilidad entre
el modo b en 1 Mbps y el modo g en 6 Mbps es de slo 3dB.
Aadir tambin que en trminos de estabilidad y prestaciones resulta mejor congurar la ve-
locidad del canal a un valor jo. La experiencia recomienda ser conservadores para soportar una
cierta prdida de prestaciones que sin duda se va a dar con el tiempo por prdida de alineacin
de las antenas, cambios climticos y otros factores.
Fenmenos meteorolgicos. En las zonas rurales es frecuente encontrar condiciones meteo-
rolgicas adversas. Aunque tradicionalmente se suele decir que las lluvias inuyen de forma
sensible a partir de los 10GHz, cuando los enlaces son muy largos una pequea atenuacin en
dB/Km acaba siendo importante. Los estudios consultados no parecen conceder mucho peso a
la atenuacin de nubes y nieblas, pero todo depende de la distancia.
Polarizacin. El mejor comportamiento se da con polarizacin vertical, pero las condiciones
atmosfricas y el terreno pueden producir una cierta despolarizacin, con lo que la recepcin
de la seal empeora y su atenuacin aumenta.
Interferencias. Si bien en las zonas rurales aisladas esto no suele suceder, los enlaces que
conectan zonas aisladas con zonas urbanas se pueden ver afectados por este problema.
1.2.2. Capa MAC
Asimismo, a parte de las restricciones que impone el balance de enlace, es patente que existen
restricciones explcitas de distancia ya que los resultados lo demuestran y, adems, porque la capa
MAC tiene multitud de tiempos constantes denidos que tienen diferente efecto en funcin de la
distancia que haya entre estaciones. Estos tiempos se pueden apreciar en la Figura 1.1. Tras una
revisin cuidadosa [5] del estndar base IEEE 802.11, se pueden extraer tres tipos de limitaciones:
el temporizador de espera de los ACKs, la denicin de tiempos relacionados con el Slottime, y el
clculo del vector que se encarga de controlar el tiempo que se debe esperar cuando el canal est
reservado para la deteccin de portadora virtual (NAV).
1.2 Problemtica del uso de WiFi para largas distancias 15
Figura 1.1: Esquema temporal de funcionamiento en el nivel MAC.
ACKtimeout: Este parmetro se dene en el texto del estndar como el tiempo en que la estacin
transmisora espera la llegada del ACK una vez que ha terminado la transmisin de un paquete.
As pues, para que una comunicacin WiFi funcione a una determinada distancia se tiene que
cumplir que el ACKtimeout sea mayor que el tiempo de propagacin de ida y vuelta ms el
SIFS, un tiempo jo que dene la separacin entre la recepcin del paquete de la transmisin
de su ACK en el receptor. No obstante, el estndar no da un valor claro a este parmetro, y
los equipos WiFi del mercado varan mucho en su implementacin del ACKtimeout; algunos
sistemas tienen un valor por defecto de aproximadamente DIFS+SIFS pero que se puede mod-
icar, y otras tienen valores no modicables pero ms grandes. DIFS es el tiempo que cada
estacin espera una vez que detecta que el canal ha quedado libre. Cuando una estacin intenta
enviar un paquete a otra que est demasiado distante como para recibir de ella el ACK antes
de que transcurra el ACKtimeout, se interpretar que la transmisin fall y se retransmitir; co-
mo lo mismo le sucede a cada retransmisin, cada paquete se retransmitir el mximo nmero
de retransmisiones antes de descartarse y dejar paso al siguiente. La capa WiFi de la estacin
transmisora creer que no logr mandar el paquete, pero de hecho lo probable es que hayan
llegado correctamente varias copias de ste, de las que la primera se pasar a la capa superior
en el receptor. El resultado es que el enlace funciona, pero con un rendimiento nmo debido a
que todo se retransmite varias veces, por defecto 7.
Slottime. Los valores de Slottime, SIFS y DIFS imponen restricciones al funcionamiento del
MAC de WiFi a partir de ciertas distancias. El estndar prev que las estaciones que transmiten
son odas por las otras dentro del mismo slot en que se ha producido la transmisin, lo cual
impone un lmite de unos 3 Km. Ms all de esa distancia, las prestaciones de los enlaces
empeoran con la distancia, aunque an resultan utilizables si el nmero de nodos activos es
sucientemente bajo.
La vulnerabilidad con nodos ocultos. Se considera como nodo oculto a la situacin donde
no todas las estaciones pueden escucharse, en IEEE 802.11 se emplea el mecanismo RTS/CTS
para evitar colisiones entre nodos ocultos; no obstante, ese mecanismo funciona si el cmputo
del NAV se corresponde con el tiempo que verdaderamente el canal va a permanecer ocupado;
puesto que el NAV no se calcula teniendo en cuenta el tiempo de propagacin, a medida que
la distancia aumenta, su efectividad empeora; en enlaces PtMP con distancias del orden de
kilmetros, el RTS/CTS es prcticamente inservible, y no hay un mecanismo alternativo.
Como consecuencia de lo anterior, y dependiendo del tipo de enlace que dene la arquitectura de
red 802.11, se pueden sacar las siguientes conclusiones:
PtP. Cuando la distancia es mayor de 3 Km, se incrementa proporcionalmente con la distancia,
en saltos de 3 Km, el nmero de slots en que una estacin puede empezar a transmitir y colision-
ar con un paquete cuya transmisin se inici en un slot determinado; esto tiene relativamente
poco impacto cuando la carga ofrecida es baja, pero es importante cuando el enlace est prxi-
mo a la saturacin, ya que en ese caso casi siempre hay un paquete listo para ser transmitido tan
pronto como se considere libre el canal, y para ventanas de contencin pequeas la probabilidad
de colisin ser signicativa. Tambin ser necesario cuidar el ajuste del ACKTimeout jndolo
a un valor ligeramente superior a dos veces el tiempo de propagacin.
PtMP. Adems de darse las mismas anomalas de comportamiento del MAC entre la estacin
transmisora y receptora de un paquete que se han comentado para PtP, las otras estaciones que
observan pasivamente el canal esperando que se desocupe tomarn decisiones equivocadas al
considerar el canal libre cuando no lo est. Por ejemplo, si la distancia hace que los ACK se
reciban ms tarde que DIFS, la estacin transmisora todava podr esperar por el ACK si el
ACKTimeout es lo sucientemente grande, pero las otras estaciones cercanas a sta que esperan
a que el canal se libere optarn a ocupar el canal de inmediato, pudiendo colisionar con cierta
probabilidad con el ACK que est en camino. Por lo que hay que jar el ACKtimeout para el
enlace ms largo que conforme ese PtMP.
En denitiva, WiFi puede servir, aunque con cierta prdida de prestaciones, para enlaces PtP de
larga distancia si los equipos terminales permiten congurar el ACKtimeout y el Slottime; en cambio,
para PtMP, an modicando esos parmetros, el funcionamiento es notablemente peor a menos que
la carga ofrecida y el nmero de nodos sean muy bajos.
1.3. Uso de telefona IP
Se puede utilizar la infraestructura de la red de datos WiFi para el transporte del trco, aplicando
protocolos de VoIP para el envo de tramas y sealizacin. Mediante el uso de este protocolo, la red
permite el acceso a servicios de telefona local (entre establecimientos de la misma zona) de forma
gratuita en las redes WiFi, y conexin con la RTPC con ciertas restricciones de llamadas salientes (las
llamadas entrantes no tendrn ningn lmite). Adems, tiene la capacidad de habilitar servicios adi-
cionales como buzn de voz, llamada a tres y ms, transferencia de llamadas, etc., sin coste adicional.
VoIP es una tecnologa de gestin y enrutamiento de comunicaciones de voz a travs de redes de
datos (LAN, WAN) basadas en protocolos TCP/IP. El objetivo de utilizar las redes de datos para la
transmisin de voz es reducir los costos de contratacin en lneas telefnicas locales convencionales.
Mediante este servicio los usuarios podrn 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 las
llamadas no tienen costo y la marcacin es similar al caso de anexos en una empresa privada, mien-
tras que para evitar problemas institucionales con temas de facturacin por llamadas a nmeros tele-
fnicos de la RTPC y para evitar tambin problemas legales de competencia a operadoras de teleco-
municacin, se ha decidido que las centralitas telefnicas instaladas permitan nicamente llamadas
salientes a nmeros de tarjetas prepago.
1.4 Arquitectura de redes WiFi para larga distancia 17
1.4. Arquitectura de redes WiFi para larga distancia
Tradicionalmente la topologa de red IEEE802.11 ms usada ha sido en modo infraestructura. En
ella todas las estaciones que forman parte de la red se comunican entre s a travs de un punto de
acceso. El punto de acceso puede adems proporcionar acceso a redes exteriores.
Sin embargo, la topologa ms bsica de una red WiFi es aquella en la que un conjunto de esta-
ciones (mnimo dos), se conectan entre s de forma directa. Dicha topologa suele recibir el nombre
de red Ad-Hoc. En este tipo de redes las estaciones se comunican de forma directa a travs del medio
inalmbrico sin que medie ninguna otra. Debido a las limitaciones inherentes en el alcance de las
transmisiones puede que no todas las estaciones sean capaces de establecer comunicacin entre s,
puesto que debern estar dentro del rango del alcance una de otra.
A partir del concepto de red Ad-Hoc en WiFi se contempla el establecimiento de redes Mesh. En
una red con topologa Mesh una estacin que desee transmitir a otra estacin fuera de su alcance,
comprobar en su tabla de encaminamiento a qu estacin dentro de su alcance debe transmitir la
informacin. Dicha estacin recibir el paquete y lo reenviar siguiendo el mismo procedimiento y
as sucesivamente hasta alcanzar la estacin destino. Esto implica que todos los nodos de la red van a
gestionar los paquetes a nivel IP. Esto introduce algo ms de retardo, pero ste, as como el ancho de
banda, se puede gestionar de forma muy avanzada.
Las redes Mesh adems de incrementar sustancialmente el rea de cobertura que puede alcanzar
una red (de lmite indenido si la distribucin y densidad de las estacin es adecuada) tienen la ventaja
de ser tolerantes a fallos, pues la cada de un nodo no implicar necesariamente la cada de la red (se
podrn seguir enviando los mensajes a travs de otras rutas).
Otra topologa posible es una cadena multisalto donde cada eslabn de la cadena est compuesto
por un enlace punto a punto en modo infraestructura. Ver gura 1.2:
Figura 1.2: Arquitectura de red cadena multisalto
En muchos casos, esta topologa es la nica posible para enlazar comunidades rurales estableci-
das a lo largo de ros amaznicos o en valles interandinos longitudinales; por ello, es la topologa
ms estudiada por GTR-PUCP. Al igual que una red Mesh, esta topologa tambin permite extender
notablemente la cobertura; a diferencia de ella, en una cadena multisalto el camino fsico est plena-
mente establecido, la comunicacin iniciada en un nodo intermedio necesariamente debe pasar por
el nodo que lo antecede o que lo precede para llegar a su destino. Tiene el obvio inconveniente que
la rotura de algn enlace interrumpe la comunicacin entre extremos, por ello es deseable que la
cadena tenga ms de un punto de contacto con el exterior. Eventualmente la cadena puede cerrarse y
volverse un anillo.
Figura 1.3: Red cadena multisalto ramicada
Esta red puede ramicarse como se ve en la gura 1.3. Aunque cada nodo puede estar compuesto
del mismo equipamiento hardware, podemos establecer una diferenciacin funcional de tres tipos de
nodos:
Estacin pasarela: es una estacin dotada de conectividad nal a Internet y a la RTPC, permi-
tiendo al resto de estaciones de la red inalmbrica acceder a travs de ella a esas redes externas.
Puede haber una o varias de estas estaciones en una red inalmbrica, pero lo ms frecuente es
que no se disponga ms que de una. El uso de ms de una implica el uso de encaminamien-
to dinmico. Estas estaciones frecuentemente tendrn que desempear funciones como NAT o
cortafuegos.
Repetidor: los distintos repetidores se unen formando la red troncal que se encarga de conmutar
las comunicaciones con otras estaciones.
Estacin cliente: se encuentra en los puntos de servicio a usuarios. Suele tener conectado una
computadora y un telfono IP.
Adems es importante distinguir entre enlaces troncales y enlaces de distribucin. Los enlaces
troncales constituyen la columna vertebral de la red, interconectan a todos los nodos repetidores y a
la estacin pasarela, transportan el trco combinado de varios clientes. Los enlaces de distribucin
permiten el acceso de los clientes a la red.
Figura 1.4: Encadenamiento de enlaces punto a punto en modo infraestructura
Como ya se mencion, cada enlace punto a punto se realiza en modo infraestructura, lo que im-
plica que un extremo de este enlace es un router que tiene una interfaz inalmbrica de red que se
comporta como STA estacin nal (sin importar que en esta topologa el enlace podra estar en
medio de la cadena) y en el otro extremo hay otro router con una interfaz que se comporta como
punto de acceso AP. Para lograr la comunicacin a lo largo de toda la cadena, el router usado en cada
nodo debe poseer por lo menos dos, y tpicamente tres interfaces de red inalmbrica, lo que es equiv-
alente a tener igual nmero de radios. En la gura 1.4 puede verse como cada una de estas interfaces
se puede congurar independientemente como STA como AP. Tambin es posible que en cada nodo
exista ms de un router, unidos por enlaces cableados Ethernet. A n de minimizar la interferencia,
cada par de enlaces contiguos se realiza en canales diferentes. 802.11b/g tiene 11 canales, 3 de ellos
no interferentes; por su parte 802.11a tiene 16 canales y 12 de ellos no solapados entre s (4 de los 12,
sealados para enlaces punto a punto). Un equipo de estas caractersticas puede verse en la g 1.5 en
la que se distinguen todos sus componentes, ntese que posee dos radios, de 400 y 80 mW.
1. Placa Alix 7. Pigtail uFL-N macho
2. Caja de exterior metlica impermeable 8. Cable de energa
3. Memoria CF de 512MB 9. Cable de red cruzado
4. Tarjeta inalmbrica SR2 (400mW) 10. Prensa estopa
5. Tarjeta inalmbrica CM9 (80mW) 11. Prensa estopa
6. Pigtail uFL-N macho
Figura 1.5: Elementos del router inalmbrico.
Debido a que debe existir lnea de vista entre las antenas que establecern un enlace, estas se
montan en la cima de torres elevadas. Cada antena se conecta con una interfaz de red inalmbrica de
un router. En microondas, las prdidas de seal en los cables coaxiales de conexin son muy elevadas,
por ello el router debe colocarse a pocos metros de las antenas, es decir que tambin se monta en la
torre y para energizarlo es comn que adems se instale un sistema elctrico autnomo en la torre [6].
Figura 1.6: Esquema de una estacin repetidora.
2
Hardware y software apropiados para la construccin de
routers WiFi de larga distancia
Un router inalmbrico es un dispositivo usado para la interconexin de redes inalmbricas con
otras redes, de cualquier tipo. En el mercado actual existen muchas soluciones y formas de equipamien-
to para un router inalmbrico WiFi. La mayora de ellas son soluciones propietarias diseadas para
enlaces interiores para enlaces exteriores de distancia media (alrededor de 30 km). En una solucin
propietaria, el fabricante guarda reserva sobre el hardware y software del equipo, solo brinda la infor-
macin suciente para la conguracin 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 energtico
de los diferentes componentes que conforman el router. En este sentido es importante que el
hardware usado tenga un consumo reducido.
Bajo coste. No se pueden implementar soluciones de un alto costo que no sean sostenibles en
el medio y largo plazo por las comunidades objetivo de estas redes.
Reducido tamao. De esta forma se asegura que el diseo nal del router sea lo ms compacto
posible.
Robusto ante condiciones meteorolgicas adversas. Ya que el router se suele instalar en zonas
de selva y alta montaa es necesario que tenga cierta robustez en cuanto a condiciones extremas
de temperatura y humedad.
Tipo de procesador. El router debe contar con un procesador lo sucientemente potente para
poder realizar las diferentes tareas que se le exijan.
Nmero mnimo y tipos de interfaces inalmbricas. Debido a que el router acta como repetidor
en diversos escenarios es recomendable que al menos cuente con 3 interfaces inalmbricas.
Adems, es necesario que estas interfaces sean de un tipo determinado (PCMCIA, CardBus,
mini-PCI) como se detalla en un apartado posterior.
Resto de interfaces. Adems de las interfaces inalmbricas es necesario considerar otro tipo
de interfaces. Entre otras las dos ms importantes son: una interfaz serie a travs de la cual
23
24
CAPTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIN
DE ROUTERS WIFI DE LARGA DISTANCIA
poder acceder al router para labores de conguracin y mantenimiento, y al menos una inter-
faz Ethernet para conectar otros dispositivos de red (por ejemplo un telfono IP). Tambin es
recomendable la existencia de una interfaz USB que permita extensiones o conexiones futuras.
Rangos y tipos de alimentacin. Por razones de exibilidad es recomendable que el router
cuente con un rango variable de alimentacin. Valores alrededor de 12V resultan ser muy tiles,
ya que de esta forma se pueden alimentar de forma directa con el sistema de energa solar.
Tambin ser ms que recomendable que la placa seleccionada tenga la opcin de poder ser
alimentada a travs de PoE (Power over Ethernet).
Disponibilidad de watchdog. Se recomienda la existencia de un watchdog hardware que permita
reiniciar la placa cuando sta se bloquee.
Disponibilidad de compra en el medio/largo plazo. Este requisito resulta especialmente im-
portante, ya que es necesario asegurar de alguna manera que el hardware seleccionado va a
seguir siendo distribuido en el medio y largo plazo. Son ms que recomendable tener posibles
alternativas localizadas en caso de que sea necesario llegar a usarlas.
Los equipos comerciales propietarios que ms se han acercado [14], [16], [22], [23], a cumplir
todos los requisitos tcnicos nalmente han fallado en poseer una adecuada relacin costo/benecio.
Otra consideracin en contra de los equipos comerciales es que no son completamente compatibles
con equipos de otros fabricantes, debido a que realizan modicaciones en el acceso al medio pre-
visto en el protocolo 802.11. Finalmente nada desdeables son los problemas que pueden surgir al
seleccionar una solucin comercial propietaria tales como: dependencia tecnolgica de un proveedor,
descontinuidad de los productos y costos de licenciamiento futuro.
Usando equipamiento genrico que soporta estndares abiertos y software libre, se pueden evitar
esos riesgos. Por ello, en paralelo al surgimiento de las iniciativas para realizar enlaces WiFi de larga
distancia, aparecieron en el mercado hardware, tales como placas SBC, tarjetas de red inalmbrica y
otros insumos con los cuales se poda armar un router WiFi por un precio generalmente menor mu-
cho menor que el de un equipo propietario comercial. La aparicin del mencionado hardware motiv
el desarrollo de herramientas de software libre tales como: versiones del sistema operativo Linux a
medida (instalable en poco espacio de disco, para hardware especco) y drivers para tarjetas de red
inalmbrica; y con ello nalmente la creacin de routers WiFi apropiados se hizo posible.
Existen muchas maneras de armar un router inalmbrico, ya que se cuenta con muchos modelos
de tarjetas de red inalmbrica, placas SBC y accesorios. Por supuesto, tambin se puede armar routers
para uso en ambientes externos y muy agrestes, lo cul depende de contar con una adecuada caja de
intemperie.
2.1 Placa SBC 25
Figura 2.1: Router inalmbrico alojado en caja de intemperie
Antes de pasar a describir las herramientas hardware y software mencionadas no se puede dejar
de mencionar que hay soluciones propietarias como [20] y [27] que se encuentran en un punto medio,
que poseen varias virtudes de los mundos propietario y libre.
2.1. Placa SBC
Single board computers (SBCs) son computadoras completas construidas en una sola tarjeta de
circuito impreso (PCB, printed circuit board). Ellas incluyen microprocesador, memoria RAM, puer-
tos de entrada y salida. No suelen incluir puertos para teclado y monitor, pues su n no es trabajar
como computadora de escritorio, sino servir para un propsito especco como puede ser un dispos-
itivo de telemetra o un router. Por este motivo tambin son llamadas computadoras empotradas
embedded systems. Algunas incorporan un sistema operativo y otras poseen ranuras para insertar
discos duros de estado slido en formato SD (Secure Digital) o CF (Compact Flash).
2.1.1. Tipo de procesador
En el mercado abundan las placas madres para desarrollar dispositivos de redes de datos con
procesadores sin FPU (http://en.wikipedia.org/wiki/Floating_point_unit, oating
point unit) y a la vez son de distintos tipos, lo que depende del fabricante; pero estos procesadores
estn optimizados para manejar todo los procesos referentes a redes de datos (manejo de nmeros en-
teros) como el Intel IXP425 Network Processor; aunque existen mtodos para que estos procesadores
sin FPU manejen procesos de punto otante (por ejemplo la ejecucin de procesos de servidores As-
terisk) los tiempos de operacin son mucho ms lentos comparados con los procesadores que poseen
FPU. Como existen distintos tipos de estos procesadores existen tambin muchos sistemas operativos
optimizados para cada tipo; por lo que los fabricantes de hardware adems desarrollan tambin el
sistema operativo para sus placas y algunos de ellos son propietarios; pero existen sistemas operativos
libres (especialmente desarrollados en base a Linux) que manejen una familia especca de estos
procesadores.
26
Los procesadores que s poseen FPU como el AMD Geode LX700, mantienen compatibilidad
con la arquitectura x86; especcamente este procesador es del tipo genrico, y no est optimiza-
do para las redes de datos sino que puede manejar este tipo de procesos y otros como si fuera un
procesador x86 para equipos de escritorio o servidores; pero slo 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 sistemas
genricos; la gran ventaja con usar sistemas libres es que se puede adicionar o quitar aplicaciones que
sean convenientes a nuestro trabajo. Al tener FPU se puede trabajar aplicaciones de alto nivel como
por ejemplo el servidor Asterisk (http://www.asterisk.org/) que es una PBX software para
implementar redes de VoIP.
2.1.2. Descripcin de SBCs
2.1.2.1. RouterBOARD 532A
http://www.routerboard.com/rb500.html
Es una de las placas que se basa en el procesador Freescale MPC8321 por lo que no tiene FPU.
Posee la gran ventaja de manejar hasta 4 y 6 interfaces inalmbricas miniPCI (por medio de tarjetas
adicionales) pero con el inconveniente que a ms interfaces menos potencia administrada a cada uno.
Adems 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 de
instalar otro sistema operativo no propietario no slo en su memoria integrada sino que al poseer una
ranura par CF se puede instalar otro sistema operativo sin perder el sistema propietario.
Figura 2.2: RouterBOARD 532A
2.1 Placa SBC 27
2.1.2.2. RouterBOARD 333
http://www.routerboard.com/pdf/rb333b.pdf
Es una de las placas muy utilizadas por los desarrollares de redes inalmbricas. Se basa en el
procesador Freescale MPC8321 por lo que no tiene FPU (unidad de punto otante). Posee la gran
ventaja de manejar tres interfaces inalmbricas miniPCI de alta potencia, adems, al igual que la
placa anterior viene con el sistema operativo RouterOS instalado.
Figura 2.3: RouterBOARD 333
2.1.2.3. Alix2C0
http://www.pcengines.ch/alix2c0.htm
Es una placa que se basa en el procesador AMD Geode LX700, es un x86 y posee FPU. No viene
con ningn sistema operativo, posee ranura para CF para instalar uno. Posee dos ranuras miniPCI que
con modicaciones soportar interfaces inalmbricas de alta potencia. Al ser un sistema x86 se tiene
la gran facilidad de trabajar con las distintas aplicaciones de redes conocidas de alto nivel.
Figura 2.4: Alix2C0
28
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 inalmbricas de alta potencia. No trae un sistema
operativo pero se le puede instalar el que ofrece el mismo fabricante u otro porque posee una ranura
para CF. Es una placa que suministra ms corriente a las interfaces miniPCI comparados con las otras
de la tabla.
Figura 2.5: Pronghorn SBC-250
2.1.2.5. Pronghorn Metro SBC Quad-Radio Wireless
http://www.adiengineering.com/php-bin/ecomm4/productDisplay.php?
product_id=85
Esta placa consume mucha potencia en comparacin a las anteriores porque maneja 4 interfaces
inalmbricas miniPCi de alta potencia, sin embargo justamente esta ltima caracterstica hace de-
seable la prueba de esta placa. Sus caractersticas son similares al Pronghorn SBC-250; pero adems
posee herramientas para manejar tarjetas WiMax.
Figura 2.6: Pronghorn Metro SBC Quad-Radio Wireless
2.1 Placa SBC 29
2
.
1
.
3
.
C
o
m
p
a
r
a
c
i
n
d
e
S
B
C
s
p
a
r
a
a
p
l
i
c
a
c
i
n
d
e
r
e
d
e
s
i
n
a
l
m
b
r
i
c
a
s
E
q
u
i
p
o
P
r
o
c
e
s
a
d
o
r
R
a
m
d
e
l
T
i
p
o
d
e
P
u
e
r
t
o
s
P
u
e
r
t
o
s
m
i
n
i
P
C
I
A
l
i
m
e
n
t
a
c
i
n
P
r
e
c
i
o
R
e
f
e
r
e
n
c
i
a
d
e
l
s
i
s
t
e
m
a
a
l
m
a
c
e
n
a
m
i
e
n
t
o
E
t
h
e
r
n
e
t
s
a
p
r
o
x
.
(
$
)
s
i
s
t
e
m
a
o
p
e
r
a
t
i
v
o
F
r
e
e
s
c
a
l
e
R
o
u
t
e
r
B
O
A
R
D
M
P
C
8
3
2
1
,
6
4
M
B
6
4
M
B
i
n
t
e
g
r
a
d
a
3
3
t
i
p
o
|
|
|
A
/
|
|
|
B
,
1
2
a
2
8
V
D
C
,
1
8
0
M
i
k
r
o
T
i
k
R
o
u
t
e
r
O
S
3
3
3
2
6
6
.
3
3
3
M
H
z
,
p
a
r
a
a
l
t
a
p
o
t
e
n
c
i
a
f
u
e
n
t
e
d
e
2
5
W
n
o
F
P
U
F
r
e
e
s
c
a
l
e
R
o
u
t
e
r
B
O
A
R
D
M
P
C
8
3
4
3
E
,
6
4
M
B
6
4
M
B
i
n
t
e
g
r
a
d
a
y
2
3
,
s
o
p
o
r
t
a
4
t
i
p
o
|
|
|
A
/
|
|
|
B
,
1
0
a
5
6
V
D
C
,
2
4
5
M
i
k
r
o
T
i
k
R
o
u
t
e
r
O
S
6
0
0
2
6
6
,
4
0
0
,
5
3
3
,
r
a
n
u
r
a
s
d
e
C
F
1
0
0
0
M
b
p
s
p
a
r
a
a
l
t
a
p
o
t
e
n
c
i
a
f
u
e
n
t
e
d
e
3
5
W
h
a
b
i
l
i
t
a
d
o
M
h
z
,
n
o
F
P
U
e
n
m
a
y
o
A
M
D
G
e
o
d
e
2
,
n
o
m
e
n
c
i
o
n
a
A
l
i
x
2
C
0
L
X
7
0
0
,
4
3
3
1
2
8
M
B
1
r
a
n
u
r
a
C
F
2
a
l
t
a
p
o
t
e
n
c
i
a
,
p
e
r
o
7
h
a
s
t
a
2
0
V
,
1
1
6
i
M
e
d
i
a
A
L
I
X
L
i
n
u
x
6
0
0
M
h
z
,
p
o
s
e
e
s
e
h
a
c
e
c
a
m
b
i
o
s
f
u
e
n
t
e
d
e
1
5
W
V
o
y
a
g
e
L
i
n
u
x
F
P
U
p
a
r
a
a
l
t
a
p
o
t
e
n
c
i
a
M
i
k
r
o
T
i
k
R
o
u
t
e
r
O
S
A
M
D
G
e
o
d
e
2
,
n
o
m
e
n
c
i
o
n
a
n
e
t
4
8
2
6
-
4
8
S
C
1
1
0
0
,
2
3
3
1
2
8
M
B
2
5
6
M
B
d
e
1
4
t
i
p
o
|
|
|
A
,
n
o
p
e
r
o
6
a
2
8
V
D
C
,
2
0
0
V
o
y
a
g
e
L
i
n
u
x
6
0
0
M
h
z
,
p
o
s
e
e
C
o
m
p
a
c
t
F
L
A
S
H
m
e
n
c
i
o
n
a
a
l
t
a
f
u
e
n
t
e
d
e
1
5
W
F
P
U
i
n
t
e
g
r
a
d
a
p
o
t
e
n
c
i
a
A
M
D
2
,
n
o
m
e
n
c
i
o
n
a
n
e
t
4
5
2
6
-
3
0
E
l
a
n
S
C
5
2
0
,
6
4
M
B
2
5
6
M
B
d
e
1
4
t
i
p
o
|
|
|
A
,
n
o
p
e
r
o
6
a
2
0
V
D
C
,
1
5
0
V
o
y
a
g
e
L
i
n
u
x
6
0
0
1
3
3
M
h
z
,
C
o
m
p
a
c
t
F
L
A
S
H
m
e
n
c
i
o
n
a
a
l
t
a
f
u
e
n
t
e
d
e
1
0
W
p
o
s
e
e
F
P
U
i
n
t
e
g
r
a
d
a
p
o
t
e
n
c
i
a
2
t
i
p
o
|
|
|
A
/
|
|
|
B
m
s
M
I
P
s
3
2
4
K
c
,
e
l
d
a
u
g
h
t
e
r
b
o
a
r
d
s
6
a
2
2
V
o
2
5
a
R
o
u
t
e
r
B
O
A
R
D
4
0
0
M
H
z
,
n
o
6
4
M
B
1
2
8
M
B
i
n
t
e
g
r
a
d
a
y
3
R
B
5
0
2
(
$
)
s
e
5
6
V
D
C
(
p
o
r
2
0
0
M
i
k
r
o
T
i
k
R
o
u
t
e
r
O
S
5
3
2
A
F
P
U
1
r
a
n
u
r
a
C
F
t
i
e
n
e
2
m
s
,
p
a
r
a
j
u
m
p
e
r
)
,
f
u
e
n
t
e
a
l
t
a
p
o
t
e
n
c
i
a
d
e
2
4
W
4
,
m
e
n
c
i
o
n
a
p
a
r
a
P
r
o
n
g
h
o
r
n
I
n
t
e
l
X
S
c
a
l
e
,
a
l
t
a
p
o
t
e
n
c
i
a
,
4
8
V
D
C
(
S
B
C
-
A
D
|
L
i
n
u
x
D
i
s
t
r
i
b
u
t
i
o
n
M
e
t
r
o
S
B
C
I
X
P
4
2
5
,
5
3
3
6
4
M
B
1
6
M
B
s
o
l
d
a
d
o
y
2
c
a
d
a
u
n
o
o
f
r
e
c
e
4
8
)
o
2
4
V
D
C
3
0
0
S
t
a
r
O
S
,
L
i
n
u
x
2
.
6
,
Q
u
a
d
-
R
a
d
i
o
M
h
z
,
n
o
F
P
U
1
r
a
n
u
r
a
C
F
6
.
5
W
,
s
o
p
o
r
t
a
(
S
B
C
-
2
4
)
O
p
e
n
W
R
T
,
I
k
a
r
u
s
O
S
W
i
r
e
l
e
s
s
W
i
M
a
x
2
,
m
e
n
c
i
o
n
a
p
a
r
a
P
r
o
n
g
h
o
r
n
I
n
t
e
l
I
X
P
4
2
5
6
4
M
B
1
6
M
B
s
o
l
d
a
d
o
y
2
a
l
t
a
p
o
t
e
n
c
i
a
,
5
V
D
C
1
9
0
A
D
|
L
i
n
u
x
D
i
s
t
r
i
b
u
t
i
o
n
S
B
C
-
2
5
0
5
3
3
M
h
z
,
n
o
1
r
a
n
u
r
a
C
F
c
a
d
a
u
n
o
o
f
r
e
c
e
S
t
a
r
O
S
,
L
i
n
u
x
2
.
6
,
F
P
U
6
.
5
W
O
p
e
n
W
R
T
,
I
k
a
r
u
s
O
S
30
2.2. Tarjetas de red inalmbrica
La eleccin de tarjetas WiFi se basa en parmetros tales como la potencia de transmisin, sensi-
bilidad de recepcin, temperatura y humedad soportadas en operacin, as como chipset incorporado.
Esta ltima condicin es importante, ya que es necesario disponer de soporte para un S.O. GNU/Linux
para todos los modos (Master, Managed, Ad-hoc, Monitor) para poder construir puntos de acceso,
puentes, repetidores y encaminadores. Se ha trabajado con tarjetas de dos chipsets diferentes (Intersil
Prism 2.5 y Atheros), con modelos que transmiten desde 80mW hasta 600mW. Se recomienda usar
como controladores de las interfaces inalmbricas el driver Hostap para el caso de tarjetas con chipset
Intersil Prism 2.5 y MadWi para tarjetas con chipset Atheros.
Mientras que el driver Madwi permite modicar el valor de ACKtimeout, CTSTimeout y SlotTime,
comentados anteriormente y por lo tanto un mejor control de las prestaciones del sistema, el Hostap
no permite modicar los valores anteriores, sin embargo, las tarjetas con este driver tienen un valor
mayor ACKtimeout, de manera que pueden ser usadas con prestaciones aceptables en enlaces largos
de hasta 30km. No obstante, mientras que estas ltimas slo pueden ser conguradas en modo b,
distintos modelos con chipset Atheros soportan los estndares 802.11 a,b o g.
En conclusin las caractersticas deseables son:
Tarjetas de alta potencia en los estndares 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. Comparacin de tarjetas de red inalmbricas
Interfaces Estndar Potencia mx Potencia mx Conector antena Sensibilidad Corriente
en g en dbm en a en dbm
SR2 g 26 @ 1-24Mbps - 1 U.FL y 1 MMCX 6 Mbps -94 dBm 1.1
12 Mbps -91 dBm
R52H ag 26 @ 6Mbps 26 @ 6Mbps 2 U.FL 6 Mbps -90dBm ag 0.8
SR5 a - 26 @ 6-24Mbps 1 U.FL y 1 MMCX 6 Mbps -94 dBm 1.3
12 Mbps -91 dBm
XR2 g 28 @ 1-24Mbps - 1 U.FL y 1 MMCX 6 Mbps -94 dBm 1.3
12 Mbps -91 dBm
XR5 a - 28 @ 6-24Mbps 1 U.FL y 1 MMCX 6 Mbps -94 dBm 1.8
12 Mbps -91 dBm
EMP ag 27 @ 6-24Mbps 22 @ 6-24Mbps 2 U.FL 6 Mbps -90 dBm a 1
-8602+S 6 Mbps -92 dBm g
WLM54A a - 26 @ 6-24Mbps 1 U.FL y 1 MMCX 6 Mbps -90 dBm a 1.5
-26dbm
WLM54G g 30 @ 6-24Mbps - 1 U.FL y 1 MCX 6 Mbps -90 dBm g 1.5
-6B-30
Cuadro 2.1: Comparacin de tarjetas inalmbricas para WiFi de larga distancia.
2.2 Tarjetas de red inalmbrica 31
SR2 de Ubiquiti Networks
Figura 2.7: SR2
R52H de Mikrotik
Figura 2.8: R52H
SR5 de Ubiquiti Networks
Figura 2.9: SR5
32
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 inalmbrica 33
WLM54A-26dbm de Compex Systems
Figura 2.13: WLM54A
2.2.2. Pigtails
Los pigtails son cables coaxiales con conectores adecuados para las tarjetas de red inalmbricas.
Estos se tratan, tpicamente, de conectores UFL y MMCX, mostrados en la Figura 2.14. En el otro
extremo los pigtails tienen conectores N hembra o macho. Dado que los conectores UFL y MMCX
son sumamente pequeos, los pigtails estn fabricados con cables coaxiales muy delgados de mucha
atenuacin motivo por el cual deben ser lo ms cortos posible (tpicamente de 30 cm).
(a) Pigtail MMCX. (b) Pigtail UFL.
Figura 2.14: Conectores Pigtail.
2.2.3. Antenas
Las antenas son dispositivos pasivos que convierten la seal de radio frecuencia enviada por los
cables coaxiales en ondas electromagnticas 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 kilmetros, y
con distintas caractersticas ambientales de los lugares donde se han instalado, se utilizan multitud de
modelos de antenas en funcin de estos requerimientos.
34
En GTR-PUCP siempre se ha conado para la adquisicin de estos equipos en la marca Hyperlink,
ya que es una marca ampliamente disponible y su relacin calidad precio es una de las mejores del
mercado. Dentro de esta marca y dado que las antenas siempre se instalan a la intemperie, se eligen los
modelos especcos para exteriores. A partir de aqu la eleccin de la antena depende de la ganancia
necesaria de la misma para poder realizar el enlace y de la frecuencia en la que se va a realizar. Estos
datos se obtienen durante la etapa de diseo de la red. Es importante resaltar que los precios de las
antenas aumentan con su ganacia, por lo que un ajuste no, en lo que a ganancia se reere, puede
suponer grandes reducciones en el costo.
(a) HG5829D. (b) HG2424G. (c) HG5819P. (d) HG2414SP-090.
Figura 2.15: Modelos de antena Hyperlink utilizados.
En la banda de 2.4 GHz algunos de los modelos utilizados son: la antena de grilla HG2424G de 24
dBi (Figura 2.15(b)), la antena de panel HG2418P de 14dBi, y las sectoriales HG2414SP-120 y la HG
2414SP-090 (Figura 2.15(d)) de 14 dBi de ganancia cada una y de 120 y 90
o
de haz, respectivamente.
En la de 5.8 GHz se han utilizado la antena de plato HG5829D de 29 dBi dada su gran ganancia y la
posibilidad de instalarle un radome, que la dota de mayor aerodinamicidad, fundamental en lugares
muy ventosos (Figura 2.15(a)), la antena de grilla HG5827G de 27 dBi y la de panel HG5819P de 19
dBi (Figura 2.15(c)).
NOTA: Las antenas de grilla tanto de 2.4 GHz como de 5.8 GHz tienen unas abrazaderas un tanto
dbiles, por lo que en zonas de mucho viento se recomienda emplear un mtodo de sujecin adicional.
2.3. Sistema Operativo Linux Voyage
Linux Voyage es una distribucin derivada de Debian que est optimizada para plataformas x86 de
propsito especco tales como las placas de PC Engines ALIX/WRAP o las de Soekris 45xx/48xx.
La instalacin tpica 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 pequeo,
por lo cul es adecuado para ejecutarlo con caractersticas como rewall, access point inalmbrico,
gateway de VoIP, etc.
2.3.1. Caractersticas
Las caractersticas ms resaltantes de Linux Voyage son:
Su construccin est basada en la distribucin Debian Sarge r3.1/Etch r4.0/Lenny r5.0 tomando
solo las aplicaciones necesarias para requerir un espacio de 128MB.
2.4 Driver MadWi 35
La capacidad del sistema se puede incrementar de acuerdo a las necesidades por medio del
manejo de la aplicacin apt
Kernel Linux 2.6
Total soporte para placas PC Engines ALIX/WRAP
Soporte WiFi
Soporte para diversos drivers de redes inalmbricas como madwi, hostap, prism54, etc.
Soporte WPA va hostapd y wpa_supplicant.
Soporte WDS va drivers hostap y madwi.
2.4. Driver MadWi
El proyecto Madwi (Multiband Atheros Driver for Wireless Fidelity) es una iniciativa de software
libre cuyo objetivo es disear drivers para dispositivos de redes inalmbricas que posean chipset
Atheros. El proyecto tiene 3 lneas de trabajo: Madwi, Ath5k y Ath9k. Madwi es estable y funciona
correctamente. Los drivers Ath5k y Ath9k que tambin estn siendo desarrollados por el proyecto
Madwi no dependern del HAL de Atheros, sin embargo, por el momento se debe preferir Madwi
si se requiere una red inalmbrica estable. Madwi posee licencia BSD/GPL, sin embargo el HAL se
distribuye bajo licencia del fabricante, en binario y como cdigo cerrado. En el proyecto Madwi se
han seguido las siguientes etapas:
Madwi-old: El trmino old se reere al driver madwi liberado en Noviembre del 2005. Este
driver fue dado de baja en Junio del 2006.
Madwi-ng: El trmino ng se reere a next generation. Fue el cdigo base entre Noviembre del
2005 y junio del 2006 y en ese tiempo fu llamado as (Madwi-ng).
Madwi: Abreviacin de Madwi-ng desde Junio del 2006.
2.4.1. HAL y OpenHAL
El HAL (Hardware Abstraction Layer)se reere a un software que da acceso a las caractersticas
del hardware, en nuestro caso da acceso a las caractersticas del chipset Atheros. Los requerimientos
de control de frecuencias y nivel de potencia han sido sealadas cmo requerimiento indispensable
para dispositivos inalmbricos en la FCC (Federal Communications Commission), y adems estos
mecanismos no deban ser fcilmente vulnerables. Sin embargo, a pesar de todas estas considera-
ciones Atheros liber su HAL bajo la licencia ISC (Internet Systems Consortium) lo cul permite
su uso en cualquier proyecto de software libre. Los chipset Atheros pueden ser usados en un amplio
rango de frecuencias (frecuencias licenciadas y frecuencias no licenciadas). Por ese motivo el HAL
es distribuido solo en forma de binario para que usuarios no autorizados no puedan modicarlo tan
fcilmente y sin embargo la comunidad de software libre pueda interactuar mediante l de un modo
permitido. Una de las caractersticas ms resaltantes del HAL Atheros es que se puede adecuar a las
caractersticas regulatorias de cada pas mediante el cdigo de ciudad (country code).
OpenHAL es un software que cumple las mismas funciones que el HAL Atheros y tiene como
objetivo reemplazarlo. Est basado en ar5k. Ms informacin acerca de OpenHAL en http://
36
madwifi-project.org/wiki/About/OpenHAL
Ar5k es parte del driver Ath de OpenBSD para tarjetas inalmbricas Atheros. Ar5k es el componente
del driver que se comunica directamente con el hardware.
2.4.2. Ath5k y Ath9k
El driver Ath5k an est en desarrollo pero ya se encuentra disponible para uso pblico, puesto
que se encuentra incorporado en el kernel linux (2.6.25 y posteriores). Tambin trabaja con tarjetas
de red inalmbricas Atheros, est basado en Madwi y OpenHAL, por lo tanto no requiere del HAL
de Atheros. Se encuentra alojado en el repositorio wireless-2.6. Por el momento trabaja en modo Ad-
hoc, Cliente y Mesh Point. Debido a que no depende del HAL de Atheros est proyectado que a largo
plazo reemplace a Madwi y supere sus caractersticas.
El driver Ath9k fu inicialmente desarrollado por Atheros. Atheros despus liber su cdigo para
que la comunidad de software libre contine su desarrollo. Soporta las caractersticas disponibles en
802.11n. Est disponible en el kernel linux desde la distribucin 2.6.27.
2.4.3. Caractersticas
Madwi Posee las siguientes caractersticas:
-Dispositivos compatibles:
Madwi soporta dispositivos PCI, MiniPCI y Cardbus. Por el momento no hay soporte para USB.
-Modos de operacin:
Son soportados los siguientes modos de operacin:
Sta (Station). Tambin conocido como cliente o managed. Es el modo que se cargar por defecto
si es que no se elige algn modo de trabajo. El dispositivo actuar como una estacin cliente de
una red inalmbrica.
Ap (Access point). Tambin conocido como master. El dispositivo trabaja como un punto de
acceso comn 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 comunicacin inalmbrica directa entre APs.
-Encriptacin:
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 MadWi 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 caractersticas ms interesantes de Madwi es la creacin de interfaces virtuales. Esto
signica que una sola interfaz fsica puede funcionar de distintos modos (sta, ap, repetidor, etc). Sin
embargo tiene limitaciones (como el uso de un canal comn).
-Atheros Super A/G:
Coleccin de caractersticas propias de los chipset Atheros. Las cules fueron desarrolladas para
incrementar el ancho de banda y distancias de alcance de los dispositivos Atheros. Se pueden citar las
siguientes:
Bursting: Caracterstica compatible con cualquier AP. Permite enviar varias tramas en simult-
neo, en vez de enviarlas en cola. De este modo se toma menos tiempo para enviar gran cantidad
de datos incrementando el ancho de banda.
Fast Frame: Caracterstica no soportada por todos los AP. Permite enviar mayor informacin en
cada trama, reduciendo tiempos de transmisin y aumentando el ancho de banda.
Compression: Los datos son comprimidos en cada trama que se enva, esto se realiza medi-
ante el algoritmo de Lempel Ziv. Una vez que la caracterstica es habilitada, la compresin y
descompresin se ejecuta dentro del chipset Atheros.
Turbo Mode: Caracterstica no soportada por todos los AP. Permite que se transmita por 2
canales, ofrecindose as un doble ancho de banda. Es benecioso solo si todas las estaciones
de la red lo soportan. Se distinguen 2 modos Turbo.
Static: Se mantiene este modo de trabajo hasta que se apague.
Dinamic: La red decide en que momento se puede usar y en que momento no se puede el modo
turbo, segn se detecte el trco de los canales adyacentes.
Adaptive Radio (AR): La caracterstica de elegir cuando se puede usar y cuando no el modo
turbo mediante el sondeo de la banda de radio es llamada comnmente AR.
Extended Range (XR): Caracterstica propia de los clientes provee alcances ms largos por
incremento de la sensibilidad del receptor de hasta -105dBm. Adicionalmente se agregan nuevas
tasas de transmisin: 3, 2, 1, 0.5, y 0.25MBits/s.
-4-address header:
Soporte para juntar segmentos ethernet e inalmbricos en una sola direccin o manejar 4 direc-
ciones independientes.
38
- Roaming:
Escoge el mejor enlace que tiene en sistemas de distribucin.
- Dynamic Frequency Selection (DFS):
Automticamente evita canales usados por radar u otras aplicaciones similares.
- Background scanning:
Permite escanear otros canales sin perder datos.
2.4.4. Requerimientos
-Hardware:
Tarjetas inalmbricas 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 Madwi 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 cul se desea instalar Madwi.
*Para Debian, Ubuntu y distribuciones anes ejecutar: apt-get install build-essential perl.
*Para Red Hat, Fedora y distribuciones anes ejecutar: yum install gcc make perl.
*Bajar ltima versin estable de Madwi de http://madwifi-project.org/
*Aplicaciones para compilar e instalar gcc, libc headers, make y perl.
*Comandos de paquete wireless-tools (iwcong, iwllist, etc.).
*Paquete wpa_supplicant para acceder a redes con encriptacin WPA.
2.5. Quagga
Quagga es un conjunto de programas de cdigo 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 cdigo libre de
los protocolos OSPF, RIP y BGP.
2.5 Quagga 39
La arquitectura de quagga consiste de un demonio (programa que siempre esta corriendo) central
llamado Zebra. Zebra es el corazn de Quagga y funciona como el administrador del enrutamiento IP;
sirve como un capa de abstraccin para el kernel y proporciona un API para los clientes Quagga (Zerv.
clients). Estos clientes implementan los protocolos de enrutamiento y envan las actualizaciones del
enrutamiento al demonio Zebra. Los Zerv. clients son:
ospfd: Implementacin del OSPFv2
ripd: Implementacin RIP v1 and V2
ospf6d: Implementacin OSPFv3 (IPv6)
ripngd: Implementacin RIPng (IPv6)
bgpd: Implementacin BGPv4+ (incluye soporte para multicast y IPv6)
Adems la arquitectura de Quagga tambin incluye bibliotecas para el desarrollo e implementacin
de ms protocolos, clientes y demonios.
Figura 2.16: Arquitectura de Quagga
40
3
Software PBX Asterisk
3.1. VoIP
Voz sobre IP (Voice over IP) es un grupo de recursos que hacen posible que la seal de voz viaje
a travs de redes TCP/IP. Esto signica que se enva la seal de voz en forma digital en paquetes en
lugar de enviarla (en forma digital o analgica) a travs de circuitos utilizables slo para telefona
como una compaa telefnica convencional (PSTN: Public Switched Telephone Network).
Los Protocolos que son usados para llevar las seales de voz sobre la red IP son comnmente
referidos como protocolos de Voz sobre IP. El trco de Voz sobre IP puede circular por cualquier red
TCP/IP, incluyendo aquellas conectadas a Internet.
VoIP es el conjunto de normas, dispositivos, protocolos, en denitiva la tecnologa que permite la
transmisin de la voz sobre el protocolo IP. Telefona sobre IP es el conjunto de nuevas funcionali-
dades de la telefona, tradicional debido a los servicios que se pueden ofrecer gracias a poder enviar
la voz sobre el protocolo IP en redes de datos TCP/IP.
La voz ha de codicarse para poder ser transmitida por la red IP. Para ello se hace uso de Codecs
que garanticen la codicacin y compresin del audio o del video para su posterior decodicacin y
descompresin antes de poder generar un sonido o imagen utilizable. Segn el Codec utilizado en la
transmisin, se utilizar ms o menos ancho de banda y recursos del sistema de cmputo. La cantidad
de ancho de banda suele ser directamente proporcional a la calidad de los datos transmitidos. Entre los
Codecs utilizados en VoIP encontramos los G.711, G.723.1 y el G.729 (especicados por la ITU-T).
Entre los codecs ms comunes se encuentran:
G.711: Estndar para la compresin de audio para telefona. Representa las seales de audio
mediante muestras comprimidas en una seal digital con tasa de muestreo de 8000 muestras
por segundo con un ujo de datos de 64 Kbps. Existen dos tipos:
-law: Usado sobre todo en Norte Amrica y Japn. Codica cada 14 muestras
en palabras de 8 bits.
a-law: Usado en Europa y en el resto del mundo. Codica cada 13 muestras en
palabras de 8 bits.
G.723: Estndar que puede operar a 6.3 Kbps o 5.3 kbps.
41
42 CAPTULO 3. SOFTWARE PBX ASTERISK
G.726: Estndar basado en ADPCM (Adaptative Differential Pulse Code Modulation). Permite
trabajar con velocidades de 16, 24, 32 y 40 Kbps. Este codec proporciona una disminucin
considerable del ancho de banda sin aumentar en gran medida la carga computacional.
G.729: Se usa sobre todo en aplicaciones de Voz sobre IP por los bajos requerimientos en ancho
de banda. Opera con tasas de 8 Kbps pero existen extensiones para tasas de 6.4 y 11.8 Kbps
para peor o mejor calidad de voz respectivamente.
GSM (Global System Mobile): Estndar que opera a 13 Kbps con una carga de CPU aceptable.
Inicialmente fue desarrollado para la telefona mvil.
iLBC (Internet Low Bit rate Codec): Algoritmo complejo desarrollado por Global IP Sound
(GIPS) que ofrece una buena relacin ancho de banda/calidad de voz a cambio de una mayor
carga computacional. Opera a 13.3 Kbps y 15.2 Kbps.
Speex: Implementa un algoritmo capaz de variar la velocidad de transmisin dependiendo de
las condiciones actuales de la red (VBR: Variable Bit Rate). El ancho de banda puede variar
desde 2.15 a 22.4 Kbps.
Actualmente no es posible garantizar la calidad de servicio sobre Internet y en cierto grado en
redes LAN; por eso, se presentan diversos problemas. No es aceptable latencias (tiempo transcurrido
desde el instante en que se genera un paquete hasta que se recibe) superiores a 300 ms ida y vuelta
(150 ms en una direccin). La calidad de este servicio se est logrando bajo los siguientes criterios:
La supresin de silencios, otorga ms eciencia a la hora de realizar una transmisin de voz, ya
que se aprovecha mejor el ancho de banda al transmitir menos informacin.
Compresin de cabeceras aplicando los estndares RTP/RTCP.
Priorizar los paquetes que requieran menor latencia.
3.2. Asterisk
Asterisk es una aplicacin de software libre (bajo licencia GPL) que proporciona funcionalidades
de una central telefnica (PBX). Como cualquier PBX, se puede conectar un nmero determinado
de telfonos para hacer llamadas entre s e incluso conectar a proveedores de VoIP y de telefona
convencional tanto analgica como digital. Originalmente desarrollado para el sistema operativo
GNU/Linux, Asterisk actualmente tambin se distribuye en versiones para los sistemas operativos
BSD, MacOSX, Solaris y Microsoft Windows, aunque la plataforma nativa (GNU/Linux) es la mejor
soportada de todas.
Asterisk incluye muchas caractersticas como buzn de voz, conferencias, IVR, distribucin au-
tomtica de llamadas, y otras muchas ms tal como PBX comerciales. Los usuarios pueden crear
nuevas funcionalidades por medio de lenguaje script de Asterisk o aadiendo mdulos escritos en
cualquier lenguaje de programacin soportado por Linux.
Las versiones estables de Asterisk estn compuestas por los mdulos siguientes:
Asterisk: Archivos base del proyecto.
3.2 Asterisk 43
Zaptel: Soporte para hardware Digium. Drivers de tarjetas.
Addons: Complementos y aadidos del paquete Asterisk.
Libpri: Soporte para conexiones digitales.
Sounds: Aporta sonidos y frases en diferentes idiomas.
Cada uno de estos mdulos cuenta con una versin estable y una versin de desarrollo. Hasta
ahora; las versiones desarrolladas son la 1.6 y la 1.4. Las versiones 1.2 y 1.0 se consideran paralizadas
y ya no se continuarn manteniendo. Actualmente la rama 1.4 es la aconsejada para sistemas en
produccin.
Figura 3.1: Arquitectura Asterisk.
La arquitectura de Asterisk est basada en 4 API:
API de Canales Asterisk: controla el tipo de conexin por el cual el cliente est llegando (bien
sea una conexin SIP, H323, BRI, etc).
API de Aplicaciones Asterisk: permite a varios mdulos de tareas, cumplir varias funciones
(conferencias, buzones de voz, etc).
API de Traduccin de Codecs: carga mdulos, codecs, para apoyar varios tipos de audio, codi-
cando y decodicando formatos tales como G711, G729, GSM11, etc.
API de formato de cheros Asterisk: controla la lectura y escritura de varios formatos de
archivos para el almacenaje de datos en el sistema de archivos.
Usando estas API Asterisk alcanza una completa abstraccin entre sus funciones bsicas y las
diferentes tecnologas y aplicaciones relacionadas.
Asterisk permite implementar los mismos servicios que una central clsica, entre ellas:
Transferencia de llamadas, internas y externas.
Desvo de llamadas si est ocupado o no contesta.
Opcin No molestar (Do Not Disturb).
Parking de llamadas (Call Parking).
Llamada en espera (Hold).
Grupos de llamada (Ring groups).
Identicador de llamante (CallerID).
Operadora Digital (mens interactivos y guiados).
Msica en espera y en transferencia (cheros MP3 actualizables por el usuario).
Captura de llamadas de forma remota (remote pickup).
Buzones de voz (general, individuales, por grupos) protegidos por contrasea.
Gestin de listas negras (nmeros telefnicos con acceso prohibido).
Salas de conferencia (2 o ms terminales simultneamente).
Registro y listados de llamadas entrantes y salientes, con grcas de consumo.
Deteccin automtica de entrada de faxes.
Recepcin de fax desde el propio sistema y posterior envo por e-mail.
Gestin de colas de llamadas entrantes.
Grabacin de llamadas entrantes y salientes.
Monitorizacin 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 ms interesante de Asterisk es que soporta muchos
protocolos VoIP como pueden ser SIP, H.323, IAX y MGCP.
Asterisk permite integrar una red de telefona IP con redes telefnicas tradicionales por medio de
interfaces analgicos y digitales. Para la conexin con lneas analgicas se hace a travs de dispos-
itivos FXO y FXS. Para la conexin con lneas digitales RDSI se logra por medio de interfaces del
tipo BRI (2 canales de voz de + 1 de sealizacin) y PRI (30 canales de voz + 1 de sealizacin).
Las interfaces de telefona analgica se encuentran en mltiples dispositivos de redes (routers,
centrales de telefona IP, etc.) que operan como acceso hacia los servicios de voz convencionales
como la telefona pblica. Para la conexin con estas lneas analgicas se hace por medio de interfaces
FXS y FXO.
FXS Foreign eXchange Station: Tambin denominada interfaz de abonado. Es el que enva
la lnea analgica hacia el abonado. Se trata de interfaces que permiten conectar dispositivos
terminales, como un telfono analgico convencional a un router o central de telefona IP. Una
interfaz FXS proporciona alimentacin elctrica, sealizacin de llamada y tono al dispositivo
terminal.
FXO Foreign eXchange Ofce: Es un puerto que recibe la lnea analgica. Es la interfaz que
permite conectar un dispositivo terminal a un servicio de telefona como el servicio de telefona
pblica (PSTN) o una PBX. Enva al sistema telefnico una seal de colgado o descolgado.
FXS y FXO son siempre pares que se corresponden mutuamente; una interfaz FXS se conecta
en el otro extremo de la lnea a una interfaz FXO. Cuando se instala una central telefnica (PBX),
la lnea telefnica se conecta al puerto FXO de la PBX, la cual provee mltiples puertos FXS para
conectar los telfonos o aparatos de fax. Un adaptador telefnico o ATA acta como un FXS.
Figura 3.2: Interfaces FXS y FXO.
3.3. Protocolos VoIP
El objetivo de VoIP es dividir en paquetes los ujos de audio para transportarlos sobre redes
basadas en IP. Los protocolos de redes IP originalmente no fueron diseados para el transporte en
tiempo real de audio o cualquier otro tipo de ujo de audio/video; por lo que se han creado protoco-
los para VoIP, cuyo mecanismo de conexin abarca una serie de transacciones de sealizacin entre
terminales que cargan ujos de audio para cada direccin de la conversacin.
3.3.1. IAX (Inter Asterisk eXchange)
IAX es uno de los protocolos utilizado por Asterisk; es utilizado para manejar conexiones VoIP
entre servidores Asterisk, y entre servidores y clientes que tambin utilizan protocolo IAX. El proto-
colo IAX ahora se reere generalmente al IAX2, la segunda versin del protocolo IAX.
IAX es robusto, lleno de novedades y muy simple en comparacin con otros protocolos. Permite
manejar una gran cantidad de codecs y un gran nmero de ujo audio/video, lo que signica que
puede ser utilizado para transportar virtualmente cualquier tipo de dato. Esta capacidad lo hace muy
til para realizar videoconferencias o realizar presentaciones remotas.
IAX utiliza un nico puerto UDP, generalmente el 4569, para comunicaciones entre puntos nales
para sealizacin y datos. El trco de voz es transmitido in-band (se reere a las comunicaciones que
tienen lugar dentro de un mtodo de comunicacin previamente establecido), lo que hace a IAX2 un
protocolo casi transparente a los cortafuegos y realmente ecaz para trabajar dentro de redes internas.
En esto se diferencia de SIP, que utiliza una cadena RTP out-of-band (se reere a las comunicaciones
que tienen lugar fuera de un mtodo de comunicacin previamente establecido) para entregar la in-
formacin.
IAX soporta Trunking (red), donde un simple enlace permite enviar datos y sealizacin por
mltiples canales. Cuando se realiza Trunking, los datos de mltiples llamadas son manejados en un
nico conjunto de paquetes, lo que signica que un datagrama IP puede entregar informacin para
ms llamadas sin crear latencia adicional. Esto es una gran ventaja para los usuarios de VoIP, donde
las cabeceras IP son un gran porcentaje del ancho de banda utilizado; en contraparte se consumir
mayores recursos del equipo de cmputo.
El principal objetivo de IAX ha sido minimizar el ancho de banda utilizado en la transmisin de
voz y vdeo a travs de la red IP, con particular atencin al control y a las llamadas de voz y proveyendo
un soporte nativo para ser transparente a NAT. La estructura bsica de IAX se fundamenta en la
multiplexacin de la sealizacin y del ujo de datos sobre un simple puerto UDP entre dos sistemas.
3.3.2. SIP (Session Initiation Protocol)
SIP (Session Initiation Protocol); fu desarrollado por el IETF MMUSIC (Multiparty Multimedia
Session Control)) Working Group; con la intencin de ser el estndar para la iniciacin, moderacin
y la nalizacin de sesiones multimedia de dos pares (unicast) o multipares (multicast). SIP es un
protocolo genrico, es un estndar y su RFC es la 3261. SIP ofrece exibilidad para controlar sesiones
multimedia como llamadas de voz y video, videoconferencia, mensajera instantnea; juegos online y
telefona IP. Una sesin puede ser una simple llamada telefnica de doble va o puede ser una sesin
de conferencia multimedia con muchas personas participando.
SIP es un protocolo de sealizacin orientado a conexiones end-to-end; esto quiere decir que toda
la lgica se encuentra almacenada en los dispositivos nales (salvo el enrutamiento de mensajes SIP).
La ventaja es la estabilidad que se obtiene pues los servidores no son saturados con mensajes SIP; la
desventaja de esto es que los encabezados son mucho mayores.
SIP esta basado en arquitectura cliente-servidor similar al HTTP y el SMTP. Esta similitud es
natural ya que SIP fue diseado para que la telefona se vuelva un servicio ms en la Internet.
SIP es un protocolo de la capa de Aplicaciones de la familia TCP/IP. Est relacionado estrechamente
con el Protocolo SDP y coexiste junto con otros protocolos del mismo nivel y funciones, como el
H323.
SIP no es protocolo de propsito general; su objetivo es ayudar a establecer y nalizar la comu-
nicacin. SIP se apoya de otros protocolos para lograr una llamada telefnica, una sesin de video
conferencia o mensajera instantnea; etc. Los protocolos que apoyan comnmente son: RTSP (Real-
Time Streaming Protocol) para el control de ujos y sesin, SDP (Session DescriptionProtocol) para
describir los ujos, RTP/RTCP (Real Time Protocol / Real Time Control Protocol) para el transporte
de datos en tiempo real y RSVP (Resource Reservation Setup Protocol) junto a DiffServ (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 (ujo audio/video) que usan sealizacin del tipo SIP
hacen uso del RTP. El protocolo RTP es el encargado de llevar las conversaciones (ujo audio/video)
de un lado a otro. De la misma forma que en una conversacin existen dos ujos de voz, en una con-
versacin en una red TCP/IP se tiene dos ujos de paquetes RTP.
Figura 3.4: La sealizacin SIP y las conversaciones de voz (RTP) viajan por caminos distintos.
Los Network Address Translators (NATs) son los problemas del RTP. El efecto de un NAT en voz
sobre TCP/IP es que no se pueden recibir conexiones iniciadas desde el exterior; el que inicia la lla-
mada desde dentro del NAT no puede escuchar a la otra parte. Si los dos comunicantes se encuentran
dentro de NAT ningn ujo de audio originado detrs de los NAT llegar a su destino nal. Para este
problema ya existen soluciones implementadas en Asterisk.
3.3.2.1. Elementos del SIP
La conguracin ms simple para establecer una sesin SIP es utilizando slo dos agentes de
usuario (UA) conectados uno a otro. Los elementos bsicos de un sistema son los UA y los servidores;
estos ltimos pueden ser de diferentes tipos: Proxy, de Registro y de Redireccin.
El protocolo SIP permite el establecimiento de sesiones multimedia entre dos o ms usuarios. Para
hacerlo se vale del intercambio de mensajes entre las partes que quieren comunicarse.
User agents (UA): Los Agentes de usuario son los puntos extremos del protocolo SIP, es decir son
los que emiten y procesan los mensajes del protocolo SIP. Un videotelfono, un telfono, un cliente
de software y cualquier otro dispositivo similar es un agente de usuario para SIP. El protocolo SIP no
se ocupa de la interfaz de estos dispositivos con el usuario nal, slo se interesa por los mensajes que
estos generan y cmo 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 peticin
y 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 ubicacin fsica 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 direccin lgica que es invariable respecto de la ubicacin fsica del usuario.
Una direccin lgica del protocolo SIP es de la forma usuario@dominio. La direccin fsica es de-
pendiente del lugar en donde el usuario est conectado (su direccin IP). Cuando un usuario inicializa
su terminal (p. e. conectando su telfono o abriendo su software de telefona SIP) el agente de usuario
SIP que reside en dicho terminal enva una peticin con el mtodo REGISTER a un Servidor de Reg-
istro, informando a qu direccin fsica debe asociarse la direccin lgica del usuario. El Servidor de
Registro realiza entonces dicha asociacin; esta asociacin tiene un perodo de vigencia; termina si
no es renovada; tambin mediante un desregistro.
Un Servidor de Registro es comnmente slo una entidad lgica y la mayora de las veces se localiza
junto con el Servidor Proxy.
Servidores Proxy y de Redireccin: Para encaminar un mensaje entre un agente de usuario
cliente y un agente de usuario servidor normalmente se recurre a los servidores.
El Proxy, se encarga de encaminar las invitaciones de la sesin para llevarlos hasta el UA llamado.
Como Redireccin, genera una respuesta que indica al que origina la comunicacin la direccin del
destino o de otro servidor que lo acerque al destino. Este tipo de servidor slo escucha peticiones y
regresa respuesta que contiene la localizacin 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 Redireccin una vez que indica al UAC cmo encaminar
el mensaje ya no interviene ms. Un mismo servidor puede actuar como Redireccin o como Proxy
dependiendo de la situacin.
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 valindose de otros servidores) las ubica-
ciones de los usuarios que son llamados por el agente de usuario en cuestin.
Un conjunto de usuarios que pertenecen a una compaa o proveedor de servicios de comunicaciones,
conforman un dominio. Este dominio, que se indica en una direccin SIP despus del caracter @ es
normalmente atendido por un servidor o ms de uno. Este servidor recibe las peticiones de sus usuar-
ios. Este servidor ser el encargado de determinar la direccin fsica del usuario llamado. Un servidor
que recibe las peticiones destinadas a un dominio especco es denominado servidor entrante (In-
bound Server). Es habitual tambin, que exista un servidor que reciba las peticiones originadas por
los usuarios de un dominio hacia otros dominios. Este recibe el nombre de Servidor Saliente (Out-
bound Server).
Mensajes SIP: Existen dos tipos bsicos de mensajes SIP, peticiones y respuestas. Las solicitudes
y las respuestas emplean el formato de mensaje genrico, que consiste en una lnea inicial (Star Line
o Request Line) seguida de un o ms campos de cabecera (Message Header), una lnea vaca que
indica el nal de las cabeceras, y por ltimo, el cuerpo del mensaje (Message Body) que es opcional.
La lnea inicial contiene la versin del protocolo; el mtodo y direcciones involucradas en la sesin
para las peticiones; mientras que el estado de la sesin para el caso de las respuestas. El encabezado
contiene informacin relacionado con la llamada en forma de texto; por ejemplo el origen y destino
de la peticin, el identicador de la llamada, etc. El cuerpo del mensaje o carga til (payload) lleva la
informacin (comnmente SDP o ISUP en caso de una troncal hacia la PSTN).
Las peticiones (Request Line) se emplean para iniciar alguna accin o para informacin; incluyen
el nombre del mtodo al que invocan, el identicador del destinatario, el protocolo SIP que se esta
utilizando; para esto utiliza mtodos y son:
Invite: Utilizado para invitar un usuario para participar en una sesin o para modicar parmet-
ros.
Ack: Conrma el establecimiento de una sesin.
Option: Solicita informacin sobre las capacidades de un servidor.
Bye: Indica la nalizacin de una sesin.
Cancel: Cancela una peticin 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 peticin, devolviendo un cdigo de
estado; la lnea llevar el SIP utilizado, cdigo de respuesta y una pequea descripcin de ese cdigo.
Podemos recibir estas respuestas segn el rango:
1xx: Mensaje provisional. La peticin fue recibida pero se desconoce aun el resultado del proce-
samiento. El emisor detiene el envo de retransmisin despus de recibir una peticin de este
tipo. Un ejemplo es el cdigo 180=ringing o el 100=trying.
2xx: xito. Son respuestas nales positivas. La peticin fue recibida y procesada exitosamente.
Por ejemplo 200=OK signica que el extremo llamado acepto la invitacin a la sesin.
3xx: Redireccin: Son usados para redireccionar las llamadas. Dan informacin acerca de la
nueva localizacin de un usuario o sobre un Proxy alterno que puede resolver satisfactoriamente
alguna peticin . El emisor del mensaje de peticin debe reenviar su peticin a otro para que su
peticin sea atendida.
4xx: Fallo de mtodo. Son respuestas nales negativas. Falla del lado del emisor, mala sintaxis
del mensaje, etc.
5xx: Fallos de servidor. Falla del lado del servidor. Aparentemente la peticin es vlida pero el
Proxy es incapaz de procesarla. El emisor debe reintentar despus.
6xx: Fallos globales. La peticin no puede ser atendida en ningn Proxy.
Transacciones SIP: Una transaccin SIP es una secuencia de mensajes entre dos elementos de
Red. Una transaccin corresponde a una peticin y todas las respuestas a esa peticin. Esto quiere
decir que una transaccin incluir cero o ms respuestas provisionales y una o ms respuestas nales;
en el caso de un mensaje INVITE puede ser dividido por un Proxy y por lo tanto tendr mltiples
respuestas nales. Las entidades SIP que almacenan el estado de las transacciones son denominadas
Stateful; lo que hace por medio del registro de cada transaccin.
Dilogos SIP: Un dialogo SIP es una conversacin peer-to-peer entre dos UA. Los dilogos
son identicados usando los campos Call-ID, From y To. Los mensajes con estos campos iguales
pertenecen al mismo dialogo. El campo CSEQ es utilizado para ordenar los mensajes en un dialo-
go. De hecho el CSEQ representa el nmero de transaccin. De forma simple se puede decir que un
dilogo es una secuencia de transaccin.
3.3.2.2. Flujo de establecimiento de una sesin SIP
En una sesin SIP comn 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 envo de un mensaje REGISTER seguido de su correspondiente respuesta
200 (OK). En caso de que el usuario no haya dado credenciales validas recibir por respuesta un
mensaje 407, con lo cual tendr que reenviar el mensaje de Registro hasta que tenga xito.
Invitacin a una sesin: Una invitacin inicia con el mensaje INVITE dirigido comnmente al
Proxy. Este responde con TRYING (100) para detener las retransmisiones y reenva las peticiones
hacia el usuario llamado. Todas las respuestas provisionales generadas por el usuario llamado son
regresados al usuario origen. Por ejemplo RINGING (180) que es un mensaje que se enva cuando el
usuario es contactado y comienza a timbrar. Una respuesta 200 (OK) es generada en cuanto el usuario
llamado descuelga el auricular.
Terminacin de sesin: Una sesin es nalizada cuando uno de los usuarios enva el mensaje
BYE al otro extremo. El otro usuario conrma el nal de la conversacin enviando por respuesta un
mensaje 200 (OK). La transaccin para nalizar la sesin se realizar de un extremo a otro sin pasar
por el Proxy a menos que en el mismo se haya establecido un proceso de Registro de ruta.
Existen situaciones en las que el Proxy requiere estar en la ruta de todos los mensajes con nes de
control del trco o por ejemplo, cuando existe un NAT. El Proxy o los Proxy logran esto por medio
de la insercin del campo RECORD ROUTE en los encabezados de los mensajes SIP.
3.3.3. Protocolo de Descripcin de Sesin SDP
Session Description Protocol (SDP); es un formato para describir parmetros de inicializacin de
ujo audiovisual. SDP esta diseado para transportar informacin de la sesin hacia los destinatarios,
Figura 3.5: Registro SIP
as como informacin de los ujos audiovisuales referentes a la misma. Este permite adems asociar
ms de un ujo audiovisual a una misma sesin; por ejemplo en una misma sesin puede existir un
ujo para audio y uno ms para video o transferencia de documentos.
SDP es exclusivamente para propsito de descripcin y negociacin de los parmetros de sesin.
No transporta el ujo audiovisual en s. Fue pensado para trabajar en conjunto con otros protocolos
como SIP, Megaco o HTTP. El transporte de informacin acerca de los ujos audiovisuales permite
a los destinatarios participar en la sesin si ellos soportan dichos ujo. Adems SDP permite la ne-
gociacin de los parmetros de ujo tales como la tasa de muestreo de la seal, el tamao de los
paquetes, etc.
La informacin que SDP incluye en sus paquetes de forma general es la siguiente:
La versin del protocolo
El nombre de la sesin y su propsito
El tiempo que la sesin esta activa.
Los medios relacionados con la sesin (video, audio, formatos para video, audio, etc.)
Las direcciones IP y los puertos pertinentes para el establecimiento de la sesin.
Los atributos especcos a la sesin o a los medio dentro de ella
Figura 3.6: Inicio de una sesin SIP
Figura 3.7: Fin de una sesin SIP
3.3.4. Protocolos RTP/RTCP
Son los protocolos usados para transportar ujo de audio/video en Telefona IP. RTP es utilizado
para transportar ujos en tiempo real (Real Media Streaming) y RTCP para monitorear la calidad del
servicio, as como para transportar informacin acerca de los participantes en la sesin. Sus funciones
son:
Identicacin del tipo de carga til transportada (codecs de audio/video)
Vericar la entrega de los paquetes en orden (marca de tiempo) y si resulta necesario recordar
los bloques fuera de orden.
Transportar informacin de sincronizacin para la codicacin y decodicacin.
Monitoreo de la entrega de la informacin.
RTP utiliza UDP para el transporte de la informacin y aprovecha la suma de vericacin del
mismo (Checksum) para vericar integridad de los datos. RTP no posee ningn mtodo para garanti-
zar la calidad de servicio ni la entrega ordenada de paquetes. RTCP tambin utiliza UDP para enviar
paquetes de control hacia todos los participantes de una sesin. Los servicios que provee RTCP son
los siguientes:
Dar seguimiento a la calidad en la distribucin de los datos, as como mantener el control de los
codecs activos.
Transportar un identicador constante para la fuente RTP.
Anunciar el nmero de participantes por sesin con el n de ajustar la tasa de transmisin de
datos.
4
Enrutamiento Dinmico
El router es un componente importante en una red de datos; se encarga de conectar mltiples
redes entre si, por tanto, es responsable de entregar paquetes entre estas distintas redes. Los routers
son computadoras que poseen CPU, memoria y un sistema operativo; y posee varias interfaces, cada
una perteneciente a una red IP distinta.
La principal tarea del router es determinar la mejor ruta hacia una red para enviar los paquetes;
para esto utiliza protocolos de enrutamiento esttico y dinmico para construir su tabla de enrutamien-
to.
4.1. Tipos de Enrutamiento
4.1.1. Tabla de Enrutamiento
Cuando se muestra una tabla de enrutamiento se observa las redes conectadas directamente, las
rutas estticas o rutas provenientes de protocolos de enrutamiento dinmico; la direccin y la mscara
de la red remota o conectada directamente y la interfaz de salida y/o la direccin IP del router del
siguiente salto para llegar a esta red; adems se incluye informacin adicional, como la mtrica de
enrutamiento y la distancia administrativa. A continuacin puede verse una tabla de enrutamiento:
root@hrradiofonia-30c1: # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.13.30.0 0.0.0.0 255.255.255.240 U 0 0 0 eth1
200.37.75.16 0.0.0.0 255.255.255.240 U 0 0 0 vlan1
10.14.30.0 0.0.0.0 255.255.255.240 U 0 0 0 br0
10.11.0.0 10.13.30.1 255.255.240.0 UG 0 0 0 eth1
10.11.16.0 10.13.30.1 255.255.240.0 UG 0 0 0 eth1
10.14.0.0 10.13.30.1 255.255.240.0 UG 0 0 0 eth1
10.12.16.0 10.13.30.1 255.255.240.0 UG 0 0 0 eth1
10.13.16.0 10.13.30.1 255.255.240.0 UG 0 0 0 eth1
10.12.0.0 10.13.30.1 255.255.240.0 UG 0 0 0 eth1
10.13.0.0 10.13.30.1 255.255.240.0 UG 0 0 0 eth1
10.14.16.0 10.13.30.1 255.255.240.0 UG 0 0 0 eth1
0.0.0.0 200.37.75.17 0.0.0.0 UG 0 0 0 vlan1
root@hrradiofonia-30c1: #
55
56 CAPTULO 4. ENRUTAMIENTO DINMICO
Cuando un router recibe un paquete, usa su tabla de enrutamiento para determinar la mejor ruta
para poder enviar el paquete; en este caso puede ocurrir una de tres situaciones.
Redes conectadas directamente: Si la direccin 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 paquete
se enviar a este dispositivo.
Redes remotas: Si la direccin IP de destino del paquete pertenece a una red remota, entonces
el paquete se enviar a otro router.
Sin determinacin de ruta: si la direccin IP de destino del paquete no pertenece ya sea a una
red conectada o remota, y si adems el router no posee una ruta por defecto, entonces el paquete
ser descartado. El router enviar un mensaje ICMP de destino inalcanzable a la direccin IP
de origen del paquete.
Existen varias formas de agregar rutas:
1.- Por medio de redes directamente conectadas.
2.- Por medio de rutas estticas
3.- Por medio de rutas aprendidas mediante un protocolo de enrutamiento dinmico.
Antes de congurar cualquier enrutamiento esttico o dinmico en un router, ste solo conoce a las
redes conectadas directamente; stas son las nicas redes que se muestran en la tabla de enrutamiento
hasta que se congure el enrutamiento esttico o dinmico. Las rutas estticas y dinmicas no pueden
existir en la tabla de enrutamiento sin las redes conectadas directamente.
El router desencapsula el paquete de capa 3 de la trama de capa 2, examina la direccin IP de
destino del paquete IP para encontrar la mejor ruta en la tabla de enrutamiento y encapsula el paquete
de capa 3 en una nueva trama de capa 2 y enva la trama desde la interfaz de salida; a esta funcin
se le conoce como conmutacin. Cada router toma su decisin en forma independiente, segn la
informacin de su propia tabla de enrutamiento. En este proceso es posible que el router haya recibido
el paquete encapsulado en un tipo de trama de enlace de datos, como una trama Ethernet, y ahora al
momento de enviar el paquete, el router lo encapsular en otro tipo de trama de enlace de datos de
tecnologa LAN como Ethernet o WAN como T1 que usa PPP, Frame Relay o ATM.
El hecho de que un router tenga cierta informacin en su tabla de enrutamiento no signica que
los otros routers tengan la misma informacin. La informacin de enrutamiento sobre una ruta desde
una red a otra no suministra informacin de enrutamiento sobre la ruta inversa o de regreso. Dado
que los routers no necesariamente tienen la misma informacin en sus tablas de enrutamiento, los
paquetes pueden recorrer la red en un sentido, utilizando una ruta, y regresar por otra ruta. Esto se
denomina enrutamiento asimtrico. El enrutamiento asimtrico es ms comn en Internet, que usa el
protocolo de enrutamiento BGP, que en la mayora de las redes internas.
4.1.2. Enrutamiento Esttico
El enrutamiento esttico es creado manualmente a diferencia de los protocolos dinmicos, que
intercambian las tablas de enrutamiento mediante actualizaciones peridicas. El enrutamiento esttico
es una solucin muy conveniente cuando la cantidad de nodos no es tan amplia. Las rutas estticas
deben usarse cuando:
4.2 Enrutamiento Dinmico 57
Si una red est compuesta por unos pocos routers.
Si una red se conecta a Internet solamente a travs de un nico ISP (Internet Service Provider).
Si una red extensa est congurada con una topologa hub-and-spoke.
4.1.3. Enrutamiento Dinmico
El uso de protocolos de enrutamiento dinmico hace que los routers aprendan automticamente
las rutas hacia las redes remotas y mantienen actualizada su tabla de enrutamiento; compensando de
esta manera los cambios en la topologa de la red. Un protocolo de enrutamiento dinmico requiere
menos sobrecarga administrativa, pero en cambio consumir parte de los recursos del router, como
tiempo del CPU y ancho de banda de los enlaces. A menudo se encontrar una combinacin de ambos
tipos de enrutamiento.
Un protocolo de enrutamiento debe estar diseado para:
Describir el costo de la mejor ruta haciendo uso de una mtrica de encaminamiento.
Contemplar la existencia de mltiples rutas activas entre dos redes.
Propagar la informacin de encaminamiento con precisin evitando crear rutas incorrectas.
Minimizar el trco 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 trco en la red despus del cambio de una ruta.
Escalar bien a redes ms grandes.
Converger rpidamente en una topologa aceptada por todos los routers despus de un cambio
de rutas.
Evitar propagar fallos de encaminamiento a largas distancias.
Tener aspectos de seguridad que prevengan falsas noticaciones.
4.2. Enrutamiento Dinmico
4.2.1. Tipos de Protocolos de Enrutamiento Dinmico:
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 polticas de intercambio de trco en una red se ha creado el concepto de Sistema
Autnomo (AS, Autonomous System). Un AS es la subred que es administrada o gestionada por una
autoridad comn, que tiene un protocolo de enrutamiento homogneo mediante el cual intercambia
informacin en toda la subred, y que posee una poltica comn para el intercambio de trco con otras
redes o AS. Normalmente cada ISP (Internet Service Provider) o empresa constituye un AS.
En Internet se dan dos niveles jerrquicos de enrutamiento, el que se realiza dentro de un AS y
el que se efecta entre ASs. Al primero se le denomina enrutamiento interno; y al otro enrutamiento
externo. Dado que los requerimientos en uno y otro caso son muy diferentes, se utilizan protocolos de
enrutamiento distintos. Los protocolos de enrutamiento dentro de un AS se denominan IGP (Interior
Gateway Protocol), mientras que los utilizados entre AS diferentes se llaman EGP (Exterior Gateway
Protocol).
IGP describe una necesidad y no el nombre de un protocolo denido. La mayora de las redes cor-
porativas operan como sistemas autnomos, aunque no estn conectados a Internet, por lo que los IGP
son utilizados con abundancia. Los protocolos IGP nunca aparecen en Internet, sino que permanecen
restringidos al mbito de un Sistema Autnomo. Entre los IGP se tiene a: RIP, IGRP, EIGRP, OSPF,
IS-IS y BGP.
Diferencia entre Enrutamiento Esttico y Dinmico:
Enrutamiento esttico Enrutamiento dinmico
Ventajas Desventajas Ventajas Desventajas
Poco procesamiento
del CPU.
Fcil de comprender y
mantener en redes
pequeas.
Fcil de congurar.
Se usa para
enrutamiento desde y
hacia redes de
conexin nica.
Uso de ruta por
defecto, cuando no
hay una mejor
coincidencia en la
tabla de enrutamiento.
Conguracin y
mantenimiento
prolongados
Propenso a errores en
redes extensas.
Requiere de
intervencin del
administrador para
mantenimiento.
No es adecuado para
redes en crecimiento
rpido.
Requiere de
conocimiento de toda
la red para su
implementacin.
Menos trabajo para
agregar o quitar redes.
Ajuste automtico
ante cambios en la
topologa.
Menos propenso a
errores de
conguracin.
Escalable; el
crecimiento de la red
usualmente no es un
problema
Requiere recursos del
router (CPU y ancho
de banda del enlace).
Requiere de ms
conocimientos para la
conguracin y
solucin de
problemas.
Cuadro 4.1: Enrutamiento esttico Versus enrutamiento dinmico.
4.2.2. Caractersticas de los Protocolos de Enrutamiento Dinmico
4.2.2.1. Algoritmo de enrutamiento Vector Distancia
El algoritmo de vector distancia se basa en calcular la direccin y la distancia hasta cualquier
enlace en la red. La distancia se dene en trminos de una mtrica como el conteo de saltos y la
direccin es simplemente el router del siguiente salto o la interfaz de salida. RIP cuenta los saltos
efectuados hasta llegar al destino mientras que IGRP adems utiliza otra informacin como el retardo
y el ancho de banda.
4.2 Enrutamiento Dinmico 59
El encaminamiento de un protocolo basado en vector de distancias requiere que un router informe
a sus vecinos de los cambios en la topologa peridicamente y en algunos casos cuando se detecta
un cambio en la topologa de la red. Los cambios son detectados peridicamente ya que la tabla
de encaminamiento de cada router se enva a todos los vecinos que usan el mismo protocolo. Una
vez que el router tiene toda la informacin; actualiza su propia tabla reejando los cambios y luego
informando a sus vecinos de los mismos.
Abajo se muestra a que tipo pertenece los protocolos conocidos:
Protocolos IGP: De vector distancia:
RIP y RIPv2: Routing Information Protocol
IGRP: Interior Gateway Routing Protocol
EIGRP: Enhanced IGRP
Protocolos IGP: De estado del enlace:
IS-IS: Intermediate System to Intermediate System
OSPF: Open Shortest Path First
Protocolos EGP: De vector distancia:
BGP: Border Gateway Protocol
4.2.2.2. Algoritmo de enrutamiento de Estado Enlace
Un protocolo de estado del enlace es un protocolo que enva informacin sobre los enlaces entre
los routers; y estn pensados para mantener las tablas de enrutamiento precisas y libres de bucles.
Enlace se reere a la conexin entre los routers (conexin fsica).
Los routers usan la informacin del estado de los enlaces recopilados de otros routers en una base
de datos para crear el mapa de la red; seleccionar la mejor ruta y mantener una imagen de la red
completa. De esta manera, un algoritmo SPF (Shortest Path First) como el algoritmo Dijkstra calcula
la mejor ruta como el camino ms 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-
van actualizaciones peridicas de la informacin de enrutamiento; stos slo envan actualizaciones
cuando se produce un cambio en la topologa de forma incremental.
4.2.2.3. Enrutamiento con clase y sin clase
Los protocolos de enrutamiento con clase no pueden usarse en redes que se subdividen usando
ms de una mscara de subred. Un ejemplo de este tipo es RIP v1, que no enva informacin de la
mscara de subred en las actualizaciones de enrutamiento.
En los protocolos sin clase, se enva la mscara de subred, junto con la direccin de red, como
parte de las actualizaciones de enrutamiento. La mayora de las redes modernas requieren protocolos
sin clase por que utilizan VLSM (variable length subnet mask) y redes no contiguas.
4.2.2.4. Convergencia
La convergencia se da cuando todas las tablas de enrutamiento de una red estn en un estado de
uniformidad. El tiempo de convergencia es el tiempo que tardan los routers en compartir informacin,
calcular las mejores rutas y actualizar su tabla de enrutamiento. Por lo general, RIP e IGRP tienen
convergencia lenta, mientras que EIGRP y OSPF tienen una convergencia ms rpida.
4.2.2.5. Balance de Carga
Cuando dos o ms rutas que llevan al mismo destino, resultan con la misma mtrica, el router
realizar un balance de carga del enlace, de manera que utiliza todos los enlaces que tienen el mismo
costo (mtrica) para ese destino. Se sabe que el balance de carga esta en uso, por que al mostrar la tabla
de enrutamiento dos o mas rutas se asociarn con el mismo destino. Esta caracterstica depender de
la aplicacin que hace uso del protocolo de enrutamiento.
4.2.3. Mtrica y distancia administrativa
Una mtrica es un valor cuantitativo que se usa para medir la distancia hacia una ruta determinada;
es una forma de evaluar cual ruta es la ms conveniente basndose en el conteo de saltos, ancho de
banda, carga en el trco de la red, conabilidad u otro valor establecido por el administrador para
indicar la preferencia de una ruta. La mejor ruta se determina por la mtrica ms baja.
Cada protocolo tiene una forma distinta de medir la calidad de un camino hacia una red remota, y
unos son ms precisos que otros porque evala mayor cantidad de variables al momento de elegir.
RIP: conteo de saltos, menor es mejor.
IGRP e EIGRP: evala ancho de banda, retardo, conabilidad y carga, se elige como mejor ruta
la que se evalu con el resultado ms bajo.
IS-IS y OSPF: Evala el ancho de banda y obtiene el costo, la mejor ruta es la del costo ms
bajo.
Si un router tiene dos caminos hacia la misma red, slo se pondr en la tabla de enrutamiento a
aquella que tenga mejor mtrica; la nica excepcin es cuando los dos caminos tienen exactamente
la misma mtrica; en ese caso se agregarn ambos caminos a la tabla de enrutamiento; este compor-
tamiento se denomina frecuentemente ECMP (Equal Cost MultiPath). La cantidad de rutas de misma
mtrica que un router permite agregar a la tabla depender de la conguracin del equipo.
Las distancias administrativas son una forma de dar prioridad cuando existe informacin sobre
una red proveniente de ms de un origen de enrutamiento (protocolo); para seleccionar la mejor ruta.
A cada origen se le asigna un orden de preferencia, incluidas rutas estticas y redes directamente
conectadas. La siguiente tabla muestra las distancias administrativas.
El protocolo de origen de la ruta que tenga menor distancia administrativa va a ser el que termine
llenando la tabla de enrutamiento. Cuando en una red todos los routers ejecutan varios protocolos
de enrutamiento dinmico a la vez; por ejemplo RIP y EIGRP; todas las mtricas de RIP seran
signicativamente menores a las de EIGRP, por lo que equivocadamente se podra pensar que el
router va a optar por los caminos RIP dada la mtrica ms 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
Esttica 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 congura una ruta esttica 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 conectadas
directamente siempre tienen un valor de distancia administrativa de 0 puesto que no existe una mejor
ruta que tener directamente conectada una red a una de sus interfaces.
4.3. OSPF, Open Shortest Path First
La respuesta del IETF a los problemas de RIP fue OSPF (Open Shortest Path First); OSPF es un
protocolo de enrutamiento basado en el estado del enlace. OSPF provee una rpida convergencia y
soporta mscaras de subred de longitud variable. Su complejidad es notablemente superior respecto
al RIP. Fue desarrollado por el OSPF Working Group del IETF.
Entre las caractersticas ms notables de OSPF podemos destacar las siguientes:
Es un algoritmo dinmico autoadaptivo, que reacciona a los cambios de manera automtica y
rpida.
Soporta una diversidad de parmetros para el clculo de la mtrica.
Soporta el parmetro de tipo de servicio (Tos) de la cabecera del datagrama IP.
Realiza balance de carga si existe ms de una ruta con la misma distancia hacia un destino dado;
depender de la aplicacin y su conguracin.
Puede operar con seguridad usando MD5 para autenticar a sus puntos antes de realizar nuevas
rutas y antes de aceptar avisos de enlace-estado.
Soporta rutas de red, de subred y de host.
Acepta CIDR (Classless Inter-Domain Routing).
OSPF est diseado para trabajar tanto en redes punto a punto como de mltiples accesos, como
de difusin (Ethernet o Token Ring) o de no-difusin (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 rea
OSPF transmite a sus vecinos paquetes LSA (Link State Advertisement) que contienen la descrip-
cin de cada una de las redes conectadas directamente a ese router. Con esta informacin el router
construye su tabla de enrutamiento con la mejor ruta.
Una vez que un router recibe los LSA de sus vecinos, estos son almacenados en una base de datos
local llamada Link State Database (LSDB). Los routers llegan a estar sincronizados cuando todos los
routers dentro de la misma rea cuentan con exactamente la misma base de datos de estado enlace;
en este punto todos los routers conocen sobre todos los destinos posibles en esa rea; pero los LSA
hasta este punto no son consideradas como rutas; para calcular las rutas hacia cada destino el router
usa un algoritmo conocido como SPF (Shortest Path First) tambin se conocido con el nombre de su
creador, Dijkstra, para calcular la ruta ms corta a cada destino.
OSPF utiliza un algoritmo de enlace-estado, a n de construir y calcular el camino ms corto para
todos los destinos. El algoritmo de por s es bastante complicado. A continuacin una descripcin
simple de las distintas etapas del algoritmo:
Tras la inicializacin o debido a cualquier cambio en la informacin de enrutamiento, un router
se podr generar un anuncio estado enlace.
Todos los routers intercambiarn los anuncios d estado enlace por medio de inundaciones
( ooding). Cada router que recibe una actualizacin del estado enlace debe guardar una copia
en su base de datos de estado enlace y propagar la actualizacin a otros routers.
Despus de que la base de datos de cada router se ha completado; el router calcular una ruta de
acceso ms corta para todos los destinos. El router utiliza el algoritmo de Dijkstra para calcular
el camino ms corto. Los puntos de destino, el costo asociado y el prximo salto para llegar a
esos destinos formarn la tabla de enrutamiento IP.
En caso de que no se produzcan cambios en la red OSPF, como el cambio del costo de un enlace
o una red aadida o suprimida, OSPF debe estar esttico. Las modicaciones que se produzcan
se comunicarn a travs de paquetes estado enlace; y el algoritmo de Dijkstra vuelve a calcular
para encontrar el camino ms corto.
4.3.1. reas y clases de routers
OSPF divide al sistema autnomo (AS) en reas, de forma que un router slo necesita conocer la
topologa e informacin de enrutamiento correspondiente a su rea. Los algoritmos de enrutamiento
se aplican dentro de cada rea. En todo AS hay al menos un rea, el rea 0 denominada backbone.
Un router puede pertenecer simultneamente a dos o ms reas, en cuyo caso debe disponer de la
informacin de enrutamiento y ejecutar los clculos correspondientes a todas ellas. Al menos un
router de cada rea debe estar adems en el backbone, para conectar dicha rea con el resto del AS.
4.3 OSPF, Open Shortest Path First 63
Dos reas slo pueden hablar entre s a travs del backbone. Las rutas entre diferentes reas
circulan siempre por el backbone, por lo tanto todas las reas deben conectar con el backbone. Si no
es posible hacer una conexin directa con el backbone, se puede hacer un enlace virtual entre redes.
Las reas ponen un lmite en el anuncio de las actualizaciones del estado enlace. Las inundaciones
y el clculo del algoritmo de Dijkstra, en un router se limitan a cambios dentro de la zona. Todos los
routers dentro de un espacio tienen exactamente la misma base de datos del estado enlace.
En OSPF se contemplan cuatro clases de routers:
Routers backbone: Los que se encuentran en el rea backbone.
Routers internos: Los que pertenecen nicamente a un rea.
Routers perifricos de rea: Son los que estn en mas de un rea, y por tanto las interconectan
(una de las reas siempre es necesariamente el backbone).
Routers perifricos de AS: Los que intercambian trco con routers de otros ASes. Estos routers
pueden estar en el backbone o en cualquier otra rea.
Standard Area: Este tipo de rea se conecta a la de backbone. Todos los routers del rea conocen
los dems routers del rea y tiene la misma base de datos topolgica. Sin embargo cada router tiene
su propia tabla de enrutamiento.
Backbone Area: El backbone, tambin denominado rea cero, forma el ncleo de una red OSPF.
Es la nica rea que debe estar presente en cualquier red OSPF, y mantiene conexin, fsica o lgica,
con todas las dems reas en que est dividida la red. La conexin entre un rea y el backbone se
realiza mediante los ABR (Area Border Router). OSPF espera que todas las reas inyecten la infor-
macin de encaminamiento en el backbone y este inyectar aquella informacin en otras reas.
Stub Area: Un rea Stub es aquella que no recibe rutas externas (LSA tipo 5). Por lo tanto, los
rouerts necesitan normalmente apoyarse en las rutas predeterminadas para poder enviar trco a rutas
fuera del segmento Stub.
rea Totally Stub: Es idntica al Stub Area (no acepta LSA tipo 5); pero adems no acepta rutas
hacia redes de otras reas y no conoce las rutas hacia routers ASBR (LSA tipos 3 y 4). La nica forma
de salir del rea es mediante una ruta por defecto. Este tipo de rea es muy til para sitios remotos
con pocas redes y conectividad limitada con el resto de la empresa. Esta es una solucin propietaria
de Cisco Systems.
Not-so-Stubby Area: Tambin 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 externas
NSSA (LSA tipo 7). En estas reas se crean los LSA de tipo 7 que son transformados a LSA de tipo
5 por el ABR del NSSA, de esta forma se puede propagar al resto del dominio OSPF.
Los routers que pertenecen a mltiples 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 informacin
que describe el backbone y las de las otras reas adjuntas. Un router que tiene todos sus interfaces
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 actan co-
mo gateway entre OSPF y otros protocolo de enrutamiento (IGRP,EIGRP, IS-IS, RIP, BGP, Static) u
otros casos de enrutamiento OSPF son llamados routers de frontera de un sistema autnomo (ASBR,
Autonomous System Boundary Router). Un router puede ser un ABR o un ASBR; un router puede ser
un router interno o un router de borde del rea y al mismo tiempo ser un ASBR.
4.3.2. Costo en OSPF
El costo (tambin llamado mtrica) de una interfaz en OSPF es una un indicativo del gasto nece-
sarios para enviar los paquetes a travs de esta interfaz. El costo de una interfaz es inversamente
proporcional al ancho de banda de la interfaz. Un gran ancho de banda indica un bajo costo. Hay ms
gasto y retardo en un enlace de 56Kbps serial que en un 10Mbps Ethernet. La frmula usada para
calcular el costo es:
costo= 10000 0000/bandwith in bps
Por defecto el costo de una interfaz es calculado y basado en el ancho de banda; pero se puede
forzar el costo de una interfaz por medio de comandos.
4.3.2.1. rbol de la ruta ms corta
La ruta ms corta es calculada por el algoritmo Dijkstra. El algoritmo coloca cada router en la raz
de un rbol y calcula la ruta ms corta para cada destino basado sobre el costo acumulativo requerido
para llegar a ese destino. Cada router tiene su propia visin de la topologa, aunque todos los routers
construirn un rbol de camino ms corto usando la misma base de datos de enlace estado. Abajo se
muestra la construccin de la ruta ms 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 travs de una o varias interfaces con
las que se conectan a otros routers de la red. El tipo de enlace dene la conguracin que asume la
interfaz correspondiente. OSPF soporta redes broadcast, redes No broadcast y redes punto a punto. El
tipo de red en la que est trabajando OSPF determinar el funcionamiento del protocolo, y este a su
vez puede ser optimizado por el administrador de la red.
4.4 Funcionamiento de OSPF 65
Figura 4.1: rbol de la ruta ms corta
4.3.2.3. Rutas externas de tipo1 y tipo2
Las rutas externas se enmarcan en dos categoras; 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 es
siempre el costo externo, independientemente de su costo en el interior para llegar a esa ruta. El costo
de tipo 1, es la adicin de los costos externos y el costo interno utilizado para llegar hasta esa ruta.
Una ruta de tipo 1 es siempre preferible a una ruta de tipo 2 para el mismo destino. Esto se ilustra en
el diagrama siguiente:
Figura 4.2: Rutas externas de tipo1 y tipo2
4.4. Funcionamiento de OSPF
Cuando un router arranca, primero inicializa las estructuras de datos necesarias y espera las in-
dicaciones de los protocolos de bajo nivel para indicar que sus interfaces estn operativas. El router
utiliza el protocolo Hello para descubrir sus vecinos; el router enva paquetes Hello y espera a que le
sean devueltos. En redes punto a punto y broadcast se detectan los vecinos dinmicamente enviando
paquetes de saludo multicast. En las redes en la que no es posible usar broadcast ser necesaria cierta
informacin de conguracin para descubrir vecinos.
En este punto por medio del protocolo Hello tambin 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 recin descubiertos en base a
estos routers. Una adyacencia es una relacin formada entre dos routers vecinos determinados con el
n de intercambiar informacin de enrutamiento. No todos los pares de vecinos son adyacencias. Las
bases de datos de estado enlace se sincronizan entre pares de routers adyacentes. Cuando hay un router
DR es este el que decide que routers son adyacentes. Las adyacencias controlan la distribucin de la
informacin de enrutamiento ya que las actualizaciones slo se envan entre los routers adyacentes.
Las adyacencias de los routers se reejan en los contenidos de sus LSA; esto permite al protocolo
detectar routers cados de forma oportuna.
Los LSA inundan el rea; asegurndose que todos los routers en un rea tienen la misma base
de datos de estado enlace. Esta base de datos consiste en una coleccin de LSA originados por cada
router perteneciente al rea. De esta base de datos cada router calcula el rbol de la primera ruta ms
corta (SPF, Shortest Path First) consigo mismo como raz. Cada vez que se recibe un LSA se calcula
el rbol SPF mediante el algoritmo de Dijkstra y se genera una tabla de enrutamiento.
4.4.1. Encapsulamiento de paquetes en OSPF
Los paquetes OSPF se encapsulan en IP con tipo de protocolo de transporte nmero 89. En la
cabecera OSPF existe un campo que indica el tipo de paquete. Todos los paquetes OSPF comparten
una comn cabecera. Cada paquete OSPF empieza con una cabecera de 24 bytes. Esta cabecera con-
tiene toda la informacin necesaria para determinar si los paquetes deben ser aceptados para futuros
procesos. Abajo se muestra el encapsulamiento del OSPF y su cabecera.
Figura 4.3: Encapsulamiento de paquetes OSPF
Figura 4.4: Longitud del campo en bytes
Version number: identica la versin del OSPF usada.
Type: Identica el tipo del paquete del OSPF. Los routers OSPF cuentan con 5 tipos de paquetes
para identicar a sus vecinos y para actualizar la informacin de enrutamiento.
Tipo Nombre Funcin
1 Hello Descubrir y mantener los vecinos
Resumen del contenido de la base de datos. Describe el
2 Database Descriptor (DBD) contenido de la base de datos topolgica. Se intercambian
estos mensajes cuando se inicializa una adyacencia.
Peticin de una descripcin la base de datos. Este tipo de
3 Link State Request (LSR) mensajes se intercambian cuando un router descubre
que cierta informacin de su base de datos est obsoleta.
4 Link State Update (LSU) Actualizacin 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: Especica la longitud del paquete, incluyendo el encabezado OSPF, en bytes.
Router ID: Identica el origen del paquete.
Area ID: Identica el rea a la que pertenece el paquete. Todos los paquetes OSPF estn asociados a
una sola rea.
Checksum: Verica el contenido total del paquete por si ha sufrido algn dao durante su trnsito.
Authentication type: Contiene el tipo de autenticacin. El tipo de autenticacin se congura en cada
rea.
Authentication: Contiene la informacin de autenticacin.
Data: Contiene informacin encapsulada de las capas superiores.
4.4.2. Tipos de LSA (Link State Advertisement)
Los LSAs describen el estado de una red o de un router. Esta descripcin cubre el estado de todos
los interfaces de los routers y sus adyacencias.
Tipo Nombre Descripcin
Se 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. Slo se propagan en un rea.
Se originan en los routers DR sobre un segmento. Esta informacin
es una indicacin de todos los routers conectados sobre un particular
2 Network-LSA segmento multiacceso como un Ethernet, Token Ring y FDDI (broadcast)
multiaccess); adems contiene una lista de los routers conectados a
n area determinada. Se envan slo dentro de un rea.
Describen las redes en el AS pero externas a un rea. Se originan en los
Routers de borde rea(ABR); cada uno describe una ruta hacia un
3,4 Summary-LSA destino fuera del rea, aunque todava dentro del AS. Normalmente los
Summary LSA son difundidos dentro del backbone y del backbone podr
pasar a otras reas por medio de los ABR. El tipo 3 describe rutas hacia
redes a travs del AS y el tipo 4 describe rutas hacia routers ASBR.
Originados por un ASBR. Cada uno describe una ruta con destino a otro
sistema autnomo. Estas redes son difundidas va redistribucin. Los ASBR
5 AS-External-LSA tiene la tarea de difundir estas rutas dentro de un AS. Estos LSAs van por
las reas estndar y backbone.
6 Group Este es una extensin Multicast OSPF (MOSPF); un protocolo de
Membership LSA enrutamiento multicast que no es de uso general.
Routers NNSA no reciben External LSA de una ABR; pero permiten
Routers in a Not- enviar informacin de enrutamiento externo por redistribucin. Estos
7 so-stubby-area routers usan LSA de tipo 7 para informarles a los ABR acerca de
(NSSA) estas rutas externas las cuales transformarn a tipo 5 (LSA External)
para ser inundados en el resto de la red OSPF.
Cuadro 4.5: Tipos de LSA
Rutas que son generadas dentro de un rea son llamados rutas Intra-Area; rutas que se originan de
otras reas son llamados rutas Inter-Area; rutas que se originan de otros protocolos de enrutamiento
y que son inyectados dentro del AS va redistribucin son llamados rutas External. Mltiples rutas al
mismo destino son preferidas en el orden siguiente: Intra-Area, Inter-Area, External type 1, External
type 2.
Figura 4.5: Rutas originadas en una determinada rea
4.4.3. Estados OSPF
Para una comprensin 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 informacin con ningn vecino. OSPF se encuentra a la espera de pasar al siguiente
estado (etapa de inicializacin).
Estado de inicializacin (Init): Los routers envan paquetes de tipo 1 (Hello) en intervalos
regulares (por defecto 10 segundos en Quagga y en Cisco) para establecer relacin con sus
routers vecinos, cuando una interfaz recibe su primer paquete Hello entonces decimos que el
router ha entrado en estado Init y est preparado para entrar en el siguiente estado.
Estado bidireccional (Two-Way): Utilizando paquetes Hello, cada router OSPF intenta es-
tablecer una comunicacin bidireccional con cada router vecino que est ubicado en la misma
red IP. Un router entra en estado two-way en el momento que se ve en una de las actualizaciones
de uno de sus vecinos. El estado two-way es la relacin ms bsica que pueden tener los routers
OSPF, pero la informacin de enrutamiento no se intercambia en este estado. Para aprender
sobre enlaces de otros routers el router tiene que tener al menos una adyacencia completa.
Estado de ExStart: Tcnicamente, cuando un router y su vecino entran en estado ExStart, su
conversacin se caracteriza por una adyacencia, pero los routers todava no tienen una adyacen-
cia completa. El estado ExStart se establece utilizando paquetes de tipo 2. Entre los dos routers
se utilizan paquetes Hello para determinar cual de los dos es el maestro y cual es el esclavo en
su relacin y se intercambian paquetes de tipo 2.
Estado de Intercambio (Exchange): En el estado exchange se utilizan paquetes de tipo 2 para
enviar informacin de estado del enlace. En otras palabras, un router describen sus bases de
datos de estado del enlace a otro router. Si alguna de las rutas no est en la base de datos del
enlace del router receptor de la informacin, este solicita una actualizacin completa, la cual se
realiza en el estado Loading.
Estado cargando (Loading): Despus de que todas las bases de datos han sido descritas a cada
router, se tiene que solicitar una informacin que es ms completa utilizando paquetes de tipo
3. Cuando un router recibe un paquete de tipo 3, este responde con una actualizacin mediante
un paquete de tipo 4. Los paquetes de tipo 4 describen la informacin de estado del enlace que
es el corazn de los protocolos de enrutamiento de estado del enlace. Los paquetes de tipo 4
son respondidos con paquetes de tipo 5.
Estado de adyacencia completa (Full adjacency): Cuando termina el estado Loading, los
routers estn en una adyacencia completa. Cada router mantiene una lista de sus vecinos adya-
centes, llamada base de datos de adyacencia.
5
Voyage GTR
El Grupo de Telecomunicaciones Rurales de la PUCP ha adaptado Voyage 0.5.2 para la imple-
mentacin de enlaces inalmbricos WiFi de larga distancia; a esta Voyage, ms sus aplicaciones adap-
tadas se le llama Voyage GTR que puede descargarse desde http://gtr.telecom.pucp.edu.
pe/webfm_send/987
5.1. Identicacin de las aplicaciones a implementar
Voyage (http://www.voyage.hk/) es un sistema operativo basado en Linux, derivado de la
distribucin Debian; Voyage es un sistema genrico que no contiene todas las aplicaciones para im-
plementar redes de datos; contiene slo lo bsico; como los controladores para el manejo de las
interfaces Ethernet y para el manejo de las interfaces inalmbricas en base a chipset Atheros.
Voyage se instala en plataformas x86; y est optimizado para equipos embebidos (tambin 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 inalmbricos de larga distancia.
Un router de larga distancia debe contener ciertas aplicaciones para poder implementar redes WiFi
de larga distancia; a Voyage original le faltan aplicaciones para cumplir con esta tarea; haciendo una
relacin entre las caractersticas comunes de los equipos comerciales, a Voyage le faltara implemen-
tar:
1. Conguracin rpida y cmoda de las interfaces de red,
2. Enrutamiento esttico, NAT y DHCP
3. Implementar seguridad WPA-PSK
4. Enrutamiento dinmico
5. Telefona IP
6. Conguracin va web
Estas caractersticas se ha implementado en Voyage GTR, pero adems se ha tenido cuidado
en que todas estas aplicaciones trabajen conjuntamente y que Voyage GTR tenga las herramientas
necesarias para su trabajo en entornos rurales. Estas herramientas son:
71
72 CAPTULO 5. VOYAGE GTR
1. Administracin de la memoria y del espacio de disco
2. Conservacin y borrado de registros de sistema (logs)
3. Creacin de archivos de respaldo
4. Apagado, reinicio y conservacin de fecha
5.2. Conguracin rpida mediante archivos de las interfaces de
red (Ethernet y WiFi)
Todas las conguraciones de las interfaces de red se realizan por medio de comandos; para no
perder esta conguracin se debe crear un script que contenga estos comandos y poder ser ejecutados
en el arranque del sistema. Existen archivos para realizar una conguracin rpida y ordenada como
/etc/network/interfaces; pero por defecto no contiene herramientas para congurar interfaces
WiFi en base a los controladores madwi.
Existe una aplicacin llamada mad wi-ifupdown que incorpora en /etc/network/interfaces
variables para poder congurar enlaces WiFi; pero esta aplicacin advierte que no est garantizado
su funcionamiento; aunque su uso hace cmodo la conguracin. Por tanto se corrigi y se adicion
variables en esta aplicacin para ser usado en Voyage GTR.
Al instalar mad wifi-ifupdown se tuvo que crear carpetas adicionales para ser adaptado a la
estructura de Voyage.
Se cre una plantilla en /etc/network/interfaces; para congurar las interfaces de red; esta
plantilla es slo til para dispositivos WiFi que hacen uso del madwi, se puede usar slo WEP y
WPA2-PSK, y est dedicado slo para el modo infraestructura; adems se puede congurar bridging
(una misma direccin para varias interfaces) entre interfaces Ethernet.
Para lograr esta plantilla:
1. en /etc/network/if-pre-up.d/madwifi se adicion la conguracin de:
1. La velocidad de transmisin.
2. La distancia.
3. La diversidad.
4. Se corrigi la activacin de la interfaz al elegir WEP.
2. en /etc/network/if-up.d/madwifi se adicion la creacin del archivo PID de seguridad
WPA-PSK en la seccin del archivo mencionado, correspondiente a hostapd; y se anul la
opcin de VAP en las interfaces de red.
3. en /etc/network/if-down.d/madwifi se corrigi la deshabilitacin incorrecta de WPA-
PSK en la seccin del archivo correspondiente a hostapd.
4. se modic /etc/init.d/networking para hacer ms efectiva la deshabilitacin del WPA-
PSK en las secciones correspondiente a hostapd y a wpa_ supplicant.
5.3 Conguracin rpida de enrutamiento esttico 73
5.3. Conguracin rpida de enrutamiento esttico
Para congurar las rutas estticas se utiliza comandos pero para que la conguracin quede o se
active despus de un reinicio se necesita de un script que se ejecute en el arranque del sistema. Esto no
es prctico por lo cual se ha creado un archivo de conguracin apoyado de un script para congurar
las rutas estticas.
El archivo de conguracin /etc/network/nat-static-routes ser el archivo para la con-
guracin de las rutas estticas, adems permitir la conguracin de la ruta por defecto y del NAT,
todo esto a travs de variables. En este archivo se ha creado un plantilla para esta conguracin.
Se ha creado el script /etc/init.d/mgnat-static-routes que permita coger la congu-
racin de /etc/network/nat-static-routes y ejecutarlo.
Adems se ha modicado /etc/init.d/networking para que la conguracin hecha en
/etc/network/nat-static-routes sea cargada cada vez que se ejecute
/etc/init.d/networking restart a travs de /etc/network/nat-static-routes. Adems
se implement un servidor DHCP, para esto se utiliz la aplicacin dnmasq que ya viene con Voyage;
pero se cre una plantilla en /etc/dnsmasq.conf que servir como ejemplo de una conguracin
bsica.
5.4. Seguridad WiFi
Actualmente la seguridad WEP no es muy conable en redes WiFi; por lo cual se debe usar WPA
que requiere una conectividad sin intermitencias; pero como se va a trabajar en enlaces largos que
podran tener repentinas desconexiones, WPA sera inadecuado. Por tanto en estas redes se usar una
variante de WPA que es WPA-PSK, que no necesita servidores de autenticacin y que soporta mejor
las desconexiones y que adems es ms seguro que el WEP.
Voyage incluye el servicio de seguridad WiFi a travs 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 conguracin sea ordenada y rpida. Al instalarlas se tuvo que crear
carpetas adicionales para ser adaptado a la estructura de Voyage.
Se cre archivos de conguracin para hasta tres interfaces WiFi, tanto para hostapd como para
wpa_ supplicant.
Los archivos creados son:
/etc/hostapd/hostapd-ath0.conf
/etc/wpa_ supplicant/wpasupplicant-ath0.conf
La eleccin del uso de este tipo de seguridad se ha hecho en /etc/network/interfaces; para
ser activados por /etc/init.d/networking.
El hostapd instalado haca que el MTU de las interfaces WiFi sea de 2400, cambiando el valor
de 1500 que se usa por defecto; esto traa problemas al implementar OSPF en estas interfaces; porque
no aceptaban un valor alto en el MTU; para esto se compil de nuevo el hostapd modicando el
cambio forzado del MTU en hostapd.h.
5.5. Enrutamiento dinmico
Voyage no trae ninguna aplicacin para este caso; quagga es el software que posee las aplica-
ciones para congurar enrutamiento dinmico con protocolos como RIP y OSPF. En este caso se
implement OSPF; para lo cual se cre plantillas para que la conguracin sea ordenada y rpida.
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 conguracin bsica; los archivos involucrados en esta plantilla
son:
voyage: # cat /etc/quagga/ospfd.conf
voyage: # cat /etc/quagga/zebra.conf
5.6. Telefona IP
Aunque un servidor de Telefona IP normalmente necesita un equipo de mayor potencia que una
placa ALIX; Asterisk, un servidor de Telefona IP de cdigo abierto, puede ser instalado en estas
placas para que realice tareas mnimas como comunicacin entre usuarios telefnicos y comunicacin
entre usuarios administrados por otros Asterisk. La placa ALIX al tener un CPU y RAM reducidos
estar limitado a administrar hasta unas 5 llamadas simultaneas con clientes SIP administrados por
otros servidores Asterisk.
En un punto de la red que pertenezca a una zona rural no es necesario implementar servidores de
gran capacidad por que los usuarios son pocos (menos de 10 clientes SIP).
Voyage no trae Asterisk, se instal la versin 1.4, la ms actual en estos momentos. Para instalarla
se necesit de sus dependencias y ms que nada de los mdulos zaptel. Al instalar Asterisk se tuvo
que crear carpetas adicionales para ser adaptado a la estructura de Voyage.
Por defecto, al instalar Asterisk no se crea su archivo logrotate, dado que es necesario se cre
/etc/logrotate.d/asterisk para controlar los log del Asterisk. Adems se ha creado el script
/etc/init.d/asterisk que permita la carga programada del Asterisk cada vez que el sistema
inicie.
Se ha establecido una plantilla para ser usada como ejemplo de una conguracin bsica. La
placa ALIX est limitado en recursos por lo que el Asterisk no puede usar todos sus mdulos, se
ha limitado y se ha adaptado a Voyage (/etc/asterisk/modules). Adems se ha instalado los
archivos de sonido en espaol y se ha creado algunos archivos de sonido adicionales para el uso de la
plantilla.
La plantilla desarrollada es para realizar la comunicacin entre clientes SIP de un mismo Asterisk
y con clientes SIP administrados por otros Asterisk y adems de permitir la comunicacin con la red
de telefona pblica; 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 contena al Asterisk no tena una ruta por defecto; en
este caso el Asterisk no trabaja correctamente; para esto se encontr una solucin que es la de poner
el nombre del equipo en /etc/hosts.
5.7 Conguracin va web 75
5.7. Conguracin va web
Para el uso comn de los usuarios tener una interfaz web facilita la conguracin 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 tamao de las CF supona una limitacin relativa para elegir un interfaz Web
(por ejemplo se buscaban servidores http ligeros, que ocuparan poco espacio). Hoy, con las CF de
gran capacidad a muy bajo precio, esa limitacin prcticamente ha desaparecido, pero s sigue siendo
importante que la aplicacin requiera poco recurso de procesamiento.
Se decidi realizar una interfaz propia, debido a que las opciones evaluadas no posean opcin
para conguracin de enrutamiento dinmico o la opcin no era apropiada. A la interfaz web de
Voyage GTR se le ha llamado Uya.
Uya se ha liberado con licencia GPLv3 y puede descargarse desde http://code.google.com/
p/uya/
La interfaz web Uya ha sido construida mediante el lenguaje de programacin Python, bsicamente se us
2 paquetes python: congmod y congmod-web.
Congmod. Posibilita las siguientes tareas:
*Leer archivos: Congmod lee archivos de conguracin y crea uno solo.
*Escribir archivos: Congmod actualiza archivos usando un solo archivo de conguracin.
Cong-web. Es una mscara web para congmod que usa la aplicacin cherrypy como servidor web.
Tambin se puede usar Uya desde linea de comandos. Para crear o actualizar el archivo de conguracin prin-
cipal de Uya se ejecuta el siguiente comando:
uya - - read-config
Ahora se puede modicar el archivo /etc/uya/uya.conf con un editor se texto y luego de la edicin se
ejecuta la escritura mediante la ejecucin del siguiente comando:
uya - - write-config
Scripts de escritura/lectura
La mscara web de Uya (frontend) usa las opciones de lectura/escritura de Uya, pero el modo en que
estas opciones son invocadas es congurable (revisar /etc/uya/scripts). Si se usa una distribucin que
normalmente 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 continuacin:
#!/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 modicados
Uya modica los siguientes archivos de conguracin:
*General:
-Hostname: /etc/hostname y /etc/hosts
-Dns: /etc/resolv.conf
-Ntpdate: /etc/default/ntpdate (variable NTPSERVERS)
*Interfaces: /etc/network/interfaces
Ethernet(ethX interfaces)
Wireless (athX madwi interfaces). WPA2-PSK crea archivos de autenticacin
/etc/wpa_supplicant/wpasupplicant-INTERFACE.conf y
/etc/hostapd/hostapd-INTERFACE.conf files.
Routing(brX interfaces)
*Enrutamiento
Esttico: /etc/quagga/daemons (deshabilitados zebra y ospfd).
Dynamic routing: /etc/quagga/daemons (habilitados zebra y ospfd).
Gateway y NAT: /etc/network/statics-routes-nat
Static routes: /etc/network/statics-routes-nat (ROUTESX entries)
Por defecto: /etc/quagga/zebra.conf y /etc/quagga/ospfd.conf
5.8. Adaptacin de Voyage para el trabajo en entornos rurales
Voyage GTR se usar en zonas rurales; por tanto su administracin estar limitada; quizs se deje de vigilar
por mucho tiempo (cada 6 meses debe existir revisiones) segn las condiciones de acceso. Por ello se debe
asegurar que las funciones de los servicios implementados trabajen correctamente por buen tiempo con el
mnimo de mantenimiento.
Voyage es un sistema que ocupa unos 100MB en la Compact Flash (CF); por lo que la CF debe ser al menos
de 256MB. Pero Voyage GTR con todas las aplicaciones instaladas, puede llegar a ocupar unos 400MB por
5.8 Adaptacin de Voyage para el trabajo en entornos rurales 77
tanto la CF debe ser de al menos 1GB; este tamao an sigue siendo muy bajo comparado con las computadoras
estndares.
Voyage es un sistema que se carga en modo lectura; pero un sistema operativo por ms que se cargue en
modo lectura necesita crear archivos temporales y reescribir o crear archivos. La particin donde est instalada
Voyage pertenece a la CF y se carga en modo lectura; pero existe una carpeta, la /rw, que est contenida en la
RAM del sistema en un espacio delimitado (originalmente a 8MB); por tanto est en modo escritura; en este
espacio se podr manipular archivos o carpetas que se encuentren aqu; pero al estar en RAM se perder la
informacin despus de un reinicio. En /rw estn ubicados especialmente los log del sistema y archivos que
necesitan ser modicados por las aplicaciones en cualquier tiempo.
Los log aumentan de tamao mientras funcione el sistema; en Voyage GTR pueden crecer a razn de
0.5MB por da; este tamao no es crtico; pero puede existir momentos en que los log crezcan rpidamente y
los 8MB dedicados para /rw puede resultar poco; por tanto se aumenta hasta 32MB. Este aumento de espacio
no quiere decir que se est quitando 32MB a los 128MB de la RAM; sino que mientras se necesite espacio se
puede usar hasta un lmite de 32MB. La modicacin se hace en /etc/fstab.
La aplicacin logrotate que ya viene con Voyage ser la encargada de borrar los log antiguos. Para
evitar que los log crezcan muy rpido antes de que acte logrotate, se desarroll el script /etc/
cron.hourly/cleanrw como tarea cron, para que cada hora evale el espacio en /rw, si es menor a
5MB deber eliminar el exceso de log.
Toda lo modicado en /rw se pierde despus de un reinicio; pero se modic el script /etc/init.d/
voyage-util que permite guardar todo lo que se modique en /rw para recuperarlo despues de un reinicio.
Para indicar que carpeta o archivo de /rw se desea conservar se indicar en /etc/voyage.conf.
Los equipos con Linux pueden permanecer encendidos por mucho tiempo y trabajan correctamente; pero
es recomendable realizar reinicios peridicamente. Para esto se crea la tarea cron para programar reinicios
/etc/cron.d/reboot-board.
La placa ALIX no posee batera para conservar la fecha del sistema mientras est sin energa (apagado); si
se desea tener la fecha sincronizada se deber usar ntpdate. Se implement scripts para conservar el tiempo
mientras se reinicia el sistema.
Si el sistema reinicia, la fecha del sistema se conserva pero si se apaga el equipo (se quita la energa) la
fecha actual se pierde y al encender de nuevo, la fecha es antigua, alrededor de 1980. Existe aplicaciones que
van creando archivos o carpetas mientras el sistema arranca pero como las fuentes fueron instaladas posteriores
a 1980, en la creacin de estos archivos o carpetas puede existir advertencias o quizs errores. Para evitar esto
se desarroll los script /etc/init.d/a-before y /etc/init.d/z-after para conservar la fecha
despus de un reinicio (sin quitar la energa de la placa) y si el equipo se apaga (se quita la energa del sistema)
se congura la fecha del sistema a una fecha aproximada al momento del grabado de Voyage GTR en la CF.
Se activ el watchdog para que reinicie al equipo si se est consumiendo demasiados recursos en un
momento. Si el promedio de uso del CPU en un minuto es ms de 24 %, o en 5 minutos es ms de 18 %, o en
15 minutos es ms de 12 % el sistema reiniciar; adems si el sistema slo cuenta con 1MB de RAM libre el
sistema reiniciar.
Para tener un buen mantenimiento del sistema es necesario tener un respaldo, para esto se ha creado scripts
que permitan generar un respaldo de la conguracin de las distintas aplicaciones; pero sin crear copia de todo
el sistema. El archivo /etc/backup.list es donde se indica las carpetas y archivos a respaldar; el script
/usr/local/sbin/mgbackup se encargar de generar el respaldo en un archivo comprimido.
Como ya se ha mencionado, se ha generado una distribucin con varias aplicaciones a la que se llama
Voyage GTR y para poder instalarla se puede usar los script de Voyage original; pero en este caso se desarroll
un script que permite una instalacin ms especca y adems que permite coger el respaldo obtenido y copiar
a una Voyage GTR y as obtener una copia particular de la conguracin de equipos.
Adems en Voyage se instal utilitarios para ser usados por medio de comandos, como: vim, telnet,
mutt, jnettop, lsof, cu, lynk, nmap y killall.
6
Con guracin e Instalacin de Voyage GTR
6.1. Comandos generales en Linux
Para un correcto entendimiento de la conguracin e instalacin de Voyage GTR, es necesario un repaso
de algunos comandos linux.
6.1.1. Comando ls
Muestra la lista de carpetas y archivos que contiene una carpeta.
gtr-v106:/var# ls
backups cache lib local lock log mail opt run spool tmp
gtr-v106:/var#
Gtr-v106: # ls-la
drwxr-xr-x 4 root 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 .profile
drwx------ 2 root root 60 Apr 6 07:40 .ssh
drwxr-xr-x 2 root root 40 Apr 8 10:21 backup
-rw-r-r--- 1 root root 0 Apr 8 10:22 configuracion.sh
gtr-v106:#
6.1.2. Comando mkdir
Sirve para crear directorios.
Gtr-v106: # mkdir backup
6.1.3. Comando rm
Sirve para borrar archivos o carpetas.
Gtr-v106: # rm -r carpeta
gtr-v106: # rm archivo.txt
79
80 CAPTULO 6. CONFIGURACIN E INSTALACIN DE VOYAGE GTR
6.1.4. Comando fdisk
Muestra y manipula la tabla de particiones. Con al opcin -l se muestra la lista de todas las particiones
encontradas en el equipo.
root@gtrdesktop: # fdisk -l
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065
*
512 = 8225280 bytes
Disk identifier: 0x31b931b9
Device Boot Start 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 bytes
16 heads, 63 sectors/track, 1006 cylinders
Units = cylinders of 1008
*
512 = 516096 bytes
Disk identifier: 0x88a4f2af
Device Boot Start End Blocks Id System
/dev/sdb1
*
1 1006 506992+ 83 Linux
root@gtrdesktop: #
6.1.5. Comando dmesg
Muestra un mensaje de diagnstico que contiene eventos generados en el arranque del sistema y durante la
depuracin de aplicaciones.
gtr-v106: # dmesg
Linux version 2.6.23-486-voyage (2.6.23-2) (root@punknix-uml) (gcc version
4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 PREEMPT Wed May 21
15:31:49 GMT 2008
...
6.1.6. Comando lspci
Se usa para listar todos los dispositivos PCI reconocidos en el equipo.
6.1 Comandos generales en Linux 81
voyage: # lspci 00:00.0 Host bridge: Cyrix Corporation PCI Master
00:0d.0 Ethernet controller: Atheros Communications, Inc. AR5006X 802.11abg NIC
(rev 01)
00:0e.0 Ethernet controller: National Semiconductor Corporation DP83815
(MacPhyter) Ethernet Controller
00:11.0 Ethernet controller: Atheros Communications, Inc. AR5006X 802.11abg NIC
(rev 01)
00:12.0 ISA bridge: National Semiconductor Corporation SC1100 Bridge
00:12.1 Bridge: National Semiconductor Corporation SC1100 SMI
0:12.2 IDE interface: National Semiconductor Corporation SCx200 IDE (rev 01)
00:12.3 Multimedia audio controller: National Semiconductor Corporation SCx200
Audio
00:12.5 Bridge: National Semiconductor Corporation SC1100 XBus
voyage: #
6.1.7. Comando ps aux
Comando que muestra informacin acerca de los procesos que se ejecutan en el equipo.
voyage: # ps aux
USER PID%CPU%MEM VSZ RSS TTY STAT START TIME COMMAND
...
root 1801 0.0 0.4 2172 580 ? S<s Apr02 0:02 udevd -daemon
root 2937 0.0 0.4 1752 612 ? Ss Apr02 2:16 /sbin/wpa_ supplicant
-B -P /var/run/wpa_ supplicant.ath0.p
daemon 3020 0.0 0.2 1680 352 ? Ss Apr02 0:00 /sbin/portmap
root 3109 0.0 0.4 1624 612 ? Ss Apr02 0:03 /sbin/syslogd
root 3115 0.0 0.2 1576 376 ? Ss Apr02 0:00 /sbin/klogd -x
root 3247 0.0 1.2 4720 1620 ? Ss Apr02 0:22 /usr/lib/postfix/master
postfix 3255 0.0 1.3 4764 1704 ? S Apr02 0:01 qmgr -l -t fifo -u
root 3256 0.0 0.4 1736 556 ? Ss Apr02 0:00 /usr/sbin/pptpd
quagga 3275 0.0 0.7 2636 944 ? Ss Apr02 0:01 /usr/lib/quagga/zebra
-daemon -A 127.0.0.1
quagga 3279 0.0 1.0 3268 1368 ? Ss Apr02 7:54 /usr/lib/quagga/ospfd
-daemon -A 127.0.0.1
root 3287 0.0 0.8 4852 1080 ? Ss Apr02 0:00 /usr/sbin/sshd
root 3325 0.0 0.6 2192 884 ? Ss Apr02 0:03 /usr/sbin/cron
root 3333 0.0 0.3 1620 440 ? Ss Apr02 0:59 /usr/sbin/watchdog
asterisk3356 0.1 4.6 13876 5848 ? Ssl Apr02 8:59 /usr/sbin/asterisk -p
-U asterisk
root 3397 0.0 0.3 1572 496 ttyS0 Ss+ Apr02 0:00 /sbin/getty -L ttyS0
38400
root 9697 0.7 1.8 7624 2320 ? Ss 10:45 0:00 sshd: root@pts/0
root 9701 6.2 2.0 3664 2540 pts/0 Ss 10:46 0:02 -bash
root 9719 0.0 0.7 2216 888 pts/0 R+ 10:46 0:00 ps aux
voyage: #
6.1.8. Comando kill
Sirve para cancelar procesos que se estn ejecutando en el sistema.
voyage: # kill 3356
6.1.9. Comando hostname
Muestra y modica el nombre del sistema.
voyage: # hostname
voyage
voyage: #
6.1.10. Comando tail
Muestra la ltima parte de archivos. Con la opcin -f se puede ver como cambia el contenido de los archivos.
voyage: # tail -f /var/log/syslog
Apr 8 08:55:08 voyage - MARK -
Apr 8 09:15:01 voyage /USR/SBIN/CRON[9286]: (root) CMD ( cd / && run-parts
-report /etc/cron.hourly)
Apr 8 10:15:01 voyage /USR/SBIN/CRON[9550]: (root) CMD ( cd / && run-parts
-report /etc/cron.hourly)
Apr 8 10:45:36 voyage kernel: eth0: Autonegotiation advertising 0x5e1
partner 0x00.
Apr 8 10:45:36 voyage kernel: eth0: link down.
Apr 8 10:45:46 voyage kernel: eth0: Autonegotiation advertising 0x5e1
partner 0x45e1.
Apr 8 10:45:46 voyage kernel: eth0: link up.
voyage: #
6.1.11. Comando ifcong
Muestra las condiciones en la cual se encuentra una interfaz de red y tambin sirve para congurar los
parmetros de red.
voyage: # ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:0D:B9:07:E9:C0
inet addr:20.20.20.210 Bcast:20.20.20.255 Mask:255.255.255.0
inet6 addr: fe80::20d:b9ff:fe07:e9c0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:485434 errors:0 dropped:0 overruns:0 frame:0
TX packets:52531 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:30162474 (28.7 MiB) TX bytes:4139442 (3.9 MiB)
Interrupt:10 Base address:0x8000
voyage: #
6.1.12. Comando ping
Manda una mensaje de prueba a un dispositivo de red y espera una respuesta mostrando el tiempo de re-
spuesta de cada paquete que enva; si no recibiera respuesta esto signicara que no hay conexin con ese
dispositivo.
6.2 Instalacin de Voyage GTR 83
voyage: # ping 20.20.20.1 -c 5
PING 20.20.20.1 (20.20.20.1) 56(84) bytes of data.
64 bytes from 20.20.20.1: icmp_ seq=1 ttl=64 time=0.723 ms
-- 20.20.20.1 ping statistics --
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.639/0.668/0.723/0.048 ms
voyage: #
6.1.13. Comando ssh
Mediante la ejecucin de este comando se puede ingresar remotamente a otros equipos conectados a la red.
voyage: # ssh 20.20.20.1
The authenticity of host 20.20.20.1 (20.20.20.1) can t be established.
RSA key fingerprint is 44:d6:51:d7:3c:eb:3b:20:30:3e:79:50:57:6f:02:a4.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 20.20.20.1 (RSA) to the list of known hosts.
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 -n
20.20.20.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth1
0.0.0.0 20.20.20.1 0.0.0.0 UG 0 0 0 eth1
root@gtrdesktop: #
6.2. Instalacin de Voyage GTR
Para instalar Voyage GTR en una Compact Flash (CF) se introduce la memoria CF en el lector/grabadora
de memorias USB y se conecta a una PC con Linux y se ejecuta el script de instalacin. Para la instalacin se
recomienda trabajar como usuario root en la PC; se debe obtener la versin de Voyage GTR junto al script que
permite su grabado; ambos se podran guardar en la carpeta /root/. Ahora se ejecuta el script que permite el
grabado de Voyage GTR.
root@gtrdesktop: # ls
grabar-voyage-gtr voyage-gtr-0.5.tar.gz
root@gtrdesktop: # bash grabar-voyage-gtr
####################################################################
Grabado de la voyage gtr
*
Fuentes del voyage: /root/voyage-gtr-0.5.tar.gz
*
Elija si es para alix(2c0/3c1) soekris(4511/4521) wrap(2E/1E): alix
*
Archivos de configuracion:
- - - - - - - Dispositivos encontrados en la PC
Disk /dev/sda: 80.0 GB, 80026361856 bytes
Disk /dev/sdb: 1008 MB, 1008730112 bytes
Disk /dev/sdc: 1039 MB, 1039417344 bytes
- - - - - - - !!! cuidado con lo elegido !!!
*
Seleccione CF, dispositivo (sdx): sdc
*
Se desea chequear la CF (si|no):si
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Resumen:
Fuente: voyage-gtr-0.5.tar.gz
Archivos conf:
Hardware: alix
Dispositivo CF: sdc
Chequeo CF: si
continuar(si/no)?: si
####################################################################
... buscando particiones montadas
... dispositivo /dev/sdc posee particion /dev/sdc1 montada
... particion /dev/sdc1 fue desmontada
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
... se encontro 15860 cilindros en /dev/sdc
... creando la particion /dev/sdc1
... formateando /dev/sdc1
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
... montando /dev/sdc1 en /mnt/tmp-voyage
... copiando voyage-gtr-0.3.tar.gz a /mnt/tmp-voyage
...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
... instalando GRUB
...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
... desmontando directorio /mnt/tmp-voyage
... chequeando integridad de la particion
ROOT_ FS: clean, 15075/63488 files, 74024/253756 blocks
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
... grabacion finalizada
####################################################################
root@gtrdesktop: #
Si no se muestra ningn tipo de error o advertencia se puede dar por nalizada la grabacin y se puede
extraer 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 Ethernet
Una vez instalado Voyage en la CF, sta se coloca en la placa ALIX y se procede al acceso; para esto se
usar una PC con Linux y un cable serial nulo; quizs sea necesario un adaptador serial-USB si la PC carece
de puerto serial sin encender la placa ALIX, se procede a conectar el cable serial a la PC y a la placa ALIX; en
un terminal, como administrador, se ejecuta los siguientes comandos:
Con puerto serial:
# chmod 777 /dev/ttyS0
# cu -l /dev/ttyS0 -s 38400
Con puerto serial y adaptador serial-USB:
# chmod 777 /dev/ttyUSB0
# cu -l /dev/ttyUSB0 -s 38400
Al energizar la placa ALIX, en el terminal se podr observar como se carga Voyage Linux hasta que se pida
el ingreso del usuario y la contrasea; por defecto el usuario es root y la contrasea es voyage. El uso del
puerto serial es muy importante porque nos permite ingresar a los equipos sin usar sus interfaces de red y en
caso de fallas para observar los problemas en el equipo
El puerto Ethernet eth0 de la placa esta congurado por defecto con la IP 11.11.11.1/24; por lo cual en un
inicio se puede ingresar por este puerto con ssh. Para ingresar se usar un cable cruzado y una vez que la placa
este encendida y cargado el sistema operativo (alrededor de un minuto) se puede hacer:
# ssh root@11.11.11.1
Despus de esto se pedir el ingreso de la clave, en ste caso inicial ser voyage.
6.4. Edicin de archivos
La particin donde se instala Voyage GTR inicialmente carga en modo lectura.
voyage: # mount
rootfs on / type rootfs (rw)
none on /sys type sysfs (rw)
none on /proc type proc (rw)
udev on /dev type tmpfs (rw)
/dev/disk/by-label/ROOT_ FS on / type ext2 (ro,noatime)
/dev/disk/by-label/ROOT_ FS on /dev/.static/dev type ext2 (rw)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec)
tmpfs on /rw type tmpfs (rw)
voyage: #
Para editar los archivos y carpetas se debe pasar el sistema al modo escritura; cuando acabe se debe regresar
el sistema al modo escritura.
voyage: # remountrw
...
...editar archivos
...
voyage: # remountro
6.5. Estructura de archivos de Voyage GTR
Un sistema operativo por ms que se cargue en modo lectura necesita crear archivos temporales y rescribir
o crear archivos; la particin donde est instalada Voyage GTR pertenece a la CF y es la se que carga en modo
lectura.
Voyage:/# ls -l
total 101
-rwxr-xr-x 1 root root 9743 Jun 29 2008 CHANGELOG
-rwxr-xr-x 1 root root 20711 Jun 22 2008 README
drwxr-xr-x 2 root root 2048 Jul 22 2008 bin
drwxr-xr-x 3 root root 1024 Jul 15 2008 boot
drwxr-xr-x 13 root root 12860 Apr 24 16:06 dev
drwxr-xr-x 65 root root 3072 Apr 24 17:17 etc
drwxr-xr-x 3 root root 1024 Jul 22 2008 home
drwxr-xr-x 2 root root 1024 Jun 28 2008 initrd
lrwxrwxrwx 1 root root 33 May 8 2009 initrd.img ->boot/initrd.img
-2.6.23-486-voyage
lrwxrwxrwx 1 root root 33 May 8 2009 initrd.img-2.6.23-486-voyage
->boot/initrd.img-2.6.23-486-voyage
drwxr-xr-x 12 root root 3072 Jul 15 2008 lib
drwx------ 2 root root 12288 Jul 15 2008 lost+found
drwxr-xr-x 2 root root 1024 Jun 28 2008 media
drwxr-xr-x 2 root root 1024 Oct 28 2006 mnt
drwxr-xr-x 4 root root 1024 Jul 22 2008 opt
dr-xr-xr-x 44 root root 0 Dec 31 1999 proc
drwxr-xr-x 8 root root 1024 Apr 24 14:58 ro
lrwxrwxrwx 1 root root 8 May 8 2009 root ->/rw/root
drwxr-xr-x 8 root root 160 Apr 24 14:58 rw
drwxr-xr-x 2 root root 3072 Jul 22 2008 sbin
drwxr-xr-x 2 root root 1024 Jun 28 2008 srv
drwxr-xr-x 10 root root 0 Dec 31 1999 sys
-rw-r-r--- 1 root root 352 Jul 11 2008 test.conf
lrwxrwxrwx 1 root root 7 May 8 2009 tmp ->/rw/tmp
drwxr-xr-x 10 root root 1024 Apr 24 14:53 usr
drwxr-xr-x 7 root root 1024 Jul 1 2008 var
lrwxrwxrwx 1 root root 30 May 8 2009 vmlinuz ->boot/vmlinuz
-2.6.23-486-voyage
lrwxrwxrwx 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.version
voyage:/#
Pero la carpeta /rw est contenida en un espacio delimitado (hasta 32MB) de la RAM del sistema, por
tanto est en modo escritura; por lo que en este espacio se podr editar los archivos que se encuentren aqu y
tambin crear o eliminar archivos; pero al estar en RAM se perder la informacin despus de un reinicio.
6.6 Guardar archivos o carpetas de /rw 87
voyage:/var# ls -l
total 5
drwxr-xr-x 2 root root 1024 Apr 24 18:00 backups
drwxr-xr-x 6 root root 1024 Jul 15 2008 cache
drwxr-xr-x 16 root root 1024 Apr 24 11:40 lib
drwxrwsr-x 2 root staff 1024 Oct 28 2006 local
lrwxrwxrwx 1 root root 12 May 8 2009 lock ->/rw/var/lock
lrwxrwxrwx 1 root root 11 May 8 2009 log ->/rw/var/log
lrwxrwxrwx 1 root root 12 May 8 2009 mail ->/rw/var/mail
drwxr-xr-x 2 root root 1024 Jun 28 2008 opt
lrwxrwxrwx 1 root root 11 May 8 2009 run ->/rw/var/run
lrwxrwxrwx 1 root root 13 May 8 2009 spool ->/rw/var/spool
lrwxrwxrwx 1 root root 11 May 8 2009 tmp ->/rw/var/tmp
voyage:/var#
Por ejemplo /root, /var/log, /var/spool estn ubicados fsicamente 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 modicado o creado en estas carpetas; entonces
para crear de nuevo estas carpetas, se tiene a /ro; todo lo que est en /ro se copiar a /rw, por tanto una
vez que el sistema levante los enlaces /root, /var/log, /var/spool estarn apuntando de nuevo a
/rw/root, /rw/var/log, /rw/var/spool; lo creado o modicado 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 copie
de /ro a /rw slo ser la estructura inicial.
voyage:/rw# ls -l
total 0
drwxr-xr-x 2 root root 40 Jun 29 2008 dev
drwxr-xr-x 2 root root 140 Apr 24 22:40 root
drwxrwxrwt 2 root root 40 Dec 31 1999 tmp
drwxr-xr-x 2 root root 40 Jun 29 2008 usr
drwxr-xr-x 9 root root 180 Jun 29 2008 var
voyage:/rw#
voyage: # cd /ro/
voyage:/ro# ls -l
total 6
drwxr-xr-x 2 root root 1024 Jun 29 2008 dev
drwxr-xr-x 2 root root 1024 Jul 23 2008 root
drwxrwxrwt 2 root root 1024 Jun 29 2008 tmp
drwxr-xr-x 2 root root 1024 Jun 29 2008 usr
drwxr-xr-x 9 root root 1024 Jun 29 2008 var
voyage:/ro#
6.6. Guardar archivos o carpetas de /rw
Todo lo modicado o creado en /rw se perder despus de un reinicio; pero existe la posibilidad de
guardar estas modicaciones; en el archivo /etc/voyage.conf, especcamente 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
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
guardarn, incluyendo su contenido, en /ro; cuando el sistema cargue despus del reinicio, en /rw estar lo
guardado.
voyage: # cat /etc/voyage.conf
#
# This file generated automatically by copyfiles.sh
# on Tue Jul 15 15:40:18 PET 2008
#
VOYAGE_ PROFILE=ALIX
VOYAGE_ SYSTEM_ CONSOLE=serial
# VOYAGE_ SYSTEM_ SYNCDIRS=/var/log"
# VOYAGE_ SYSTEM_ SYNCFILES=/var/log/syslog /var/log/kern.log"
VOYAGE_ SYSTEM_ SERIAL=38400
VOYAGE_ SYSTEM_ PCMCIA=no
VOYAGE_ SYSTEM_ MODULES=lm90; w83627hf; scx200_ acb base=0x810,0x820;
geodewdt; led-class; leds-alix; ledtrig-heartbeat; ledtrig-timer"
SYSTEM_ BOOTSTRAP=grub
Voyage: #
Si ya no se desea seguir guardando se comenta de nuevo las variables.
6.7. Conguracin previa a cualquier aplicacin en Voyage GTR
Dar nombre al equipo, editar /etc/hostname; el nombre del equipo no debe contener puntos ni espa-
cios en blanco o caracteres extraos.
voyage: # cat /etc/hostname
voyage
voyage: #
Dar una clave al sistema
voyage: # passwd
Si el equipo no va a ser un servidor de tiempo, se puede indicar un servidor o servidores NTP editando la
variable NTPSERVERS.
voyage: # cat /etc/default/ntpdate
...
# NTPSERVERS=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian
.pool.ntp.org 3.debian.pool.ntp.org"
NTPSERVERS=200.16.6.80"
...
Congurar el reinicio del equipo; editar el archivo /etc/cron.d/reboot-board y descomentar la
opcin de reinicio aleatorio de entre las 4 y 4:30 horas cada sbado o reinicio a las 4 horas todos los das.
Tambin se puede congurar uno particular.
6.8 Obtencin de respaldo de la conguracin de las aplicaciones en Voyage GTR 89
voyage: # cat /etc/cron.d/reboot-board
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# min hour dom month dow user command
#0 4
* *
6 root (sleep echo $(( $RANDOM / 20 )) ; reboot)
#0 4
* * *
root reboot
voyage: #
6.8. Obtencin de respaldo de la conguracin de las aplicaciones
en Voyage GTR
Para sacar un respaldo de la conguracin hecha en Voyage GTR se debe indicar que archivo o carpeta se
debe respaldar; esto se indica en el archivo de conguracin /etc/backup.list; originalmente ste archi-
vo contiene una lista de los archivos y/o carpetas que deberan ser respaldados; si en esta lista no se encuentra
una carpeta o archivo en particular se adiciona lnea por lnea. Despus se ejecuta el script mgbackup con la
opcin backup:
red-sur: # mgbackup backup
...
32: guardando /etc/default/snmpd
33: guardando /etc/snmp
34: guardando /etc/quagga/daemons
35: guardando /etc/quagga/ospfd.conf
36: guardando /etc/quagga/zebra.conf
37: guardando /etc/uya/passwd
... finalizado respaldo
... solo guarde el /opt/backup-conf-red-sur.tar.gz
red-sur: #
Si no se muestra error en la creacin del respaldo, se crear en /opt un archivo comprimido con el nombre
del equipo. Despus de la creacin del respaldo, el sistema regresar al modo lectura.
La opcin Archivos de configuracin mostrada al ejecutar el script que permite el grabado de
Voyage GTR en la CF, se utilizar para indicar el archivo de respaldo (obtenido antes) que se copiar en esta
grabacin de Voyage GTR; es decir Voyage GTR que se obtendr aqu ser idntica en conguracin de Voyage
GTR de donde se sac el respaldo.
6.9. Vericacin del estado de Voyage GTR
6.9.1. Espacio ocupado y disponible
Dependiendo del tipo de router se debe observar el espacio disponible en el disco total y en las particiones
crticas. Normalmente es necesario que se tenga al menos la mitad de espacio disponible en cada particin, si
se tiene ocupando ms de la mitad, se debe eliminar archivos innecesarios y vigilar. Anotar:
Espacio ocupado y disponible de las particiones crticas del equipo.
En el router GTR se tiene dos particiones crticas que son la /ro y /rw.
voyage: # df -l
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 998808 272816 675256 29% /
udev 10240 20 10220 1% /dev
/dev/disk/by-label/ROOT_ FS
998808 272816 675256 29% /
/dev/disk/by-label/ROOT_ FS
998808 272816 675256 29% /dev/.static/dev
tmpfs 63384 0 63384 0% /lib/init/rw
tmpfs 63384 0 63384 0% /dev/shm
tmpfs 32768 664 32104 3% /rw
voyage: #
6.9.2. RAM libre y CPU desocupado en un instante
Esto dar una idea de cuanta RAM o CPU se est usando en el equipo para prevenir un uso excesivo de
los recursos del sistema. Si se tiene un uso alto se debe seguir vigilando para asegurarse que quizs slo sea
un instante donde muchas aplicaciones estn con mucho trabajo. En un diseo no puede estar contemplado una
carga alta y constante por mucho tiempo, si esto sucede se debe buscar las aplicaciones que causan el excesivo
consumo o quizs reiniciar el equipo para regresar al estado normal. El uso excesivo se da generalmente en
pocos instantes y con poca duracin, en este instante se puede llegar a ms de 60 % de RAM y casi 100 % de
CPU; pero en el resto del tiempo generalmente se debe tener un consumo de alrededor de 20 % de RAM; y el
CPU debe estar casi en 90 % si uso. Anotar:
RAM libre en un instante de trabajo normal.
CPU desocupado en un instante de trabajo normal.
gtr-v106: # free
total used free shared buffers cached
Mem: 126768 47564 79204 0 2604 25148
-/+ buffers/cache: 19812 106956
Swap: 0 0 0
gtr-v106: #
gtr-v106: # top
top - 15:01:42 up 10:43, 1 user, load average: 0.01, 0.02, 0.00
Tasks: 34 total, 1 running, 33 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.3%us, 1.0%sy, 0.0%ni, 95.4%id, 0.0%wa, 0.3%hi, 2.0%si, 0.0%st
Mem: 126768k total, 68964k used, 57804k free, 2800k buffers
Swap: 0k total, 0k used, 0k free, 45956k cached
...
6.9.3. Fecha del sistema y ltimo reinicio
Tomar la fecha del sistema para saber si est sincronizando o no con el servidor de tiempo. Se recomienda
que est sincronizado; si no lo est por motivos de red se podra jar la fecha manualmente. Adems se debe
evaluar el correcto reinicio programado del router, se puede evaluar observando el ltimo reinicio del equipo.
Anotar:
Fecha del sistema.
Fecha del ltimo reinicio del sistema.
6.9 Vericacin del estado de Voyage GTR 91
gtr-v106: # date
Fri May 8 15:05:18 PET 2009
gtr-v106: #
gtr-v106: # date -set "05/11/09 14:51"
voyage: # uptime
14:29:10 up 10:10, 1 user, load average: 0.00, 0.00, 0.00
voyage: #
7
Con guracin de Redes con Voyage GTR
7.1. Interfaces de Red
Para empezar a congurar las interfaces de red se debe asegurar que el sistema reconozca los dispositivos;
para esto se puede hacer:
voyage: # lspci
00:01.0 Host bridge: Advanced Micro Devices [AMD] Unknown device 2080 (rev 33)
00:01.2 Entertainment encryption device: Advanced Micro Devices [AMD] Geode LX
AES Security Block
00:09.0 Ethernet controller: VIA Technologies, Inc. VT6105M [Rhine-III] (rev 96)
00:0b.0 Ethernet controller: VIA Technologies, Inc. VT6105M [Rhine-III] (rev 96)
00:0c.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC
(rev 01)
00:0f.0 ISA bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA
(rev 03)
00:0f.2 IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion]
IDE (rev 01)
00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion]
OHC (rev 02)
00:0f.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion]
EHC (rev 02)
voyage: #
Adems se debe asegurar que el sistema disponga de los controladores para estos dispositivos, aunque esto
ya se ha hecho al implementar Voyage Gtr; se puede observar en /var/log/syslog una vez que el sistema
este cargado.
93
94 CAPTULO 7. CONFIGURACIN DE REDES CON VOYAGE GTR
voyage: #
voyage: # cat /var/log/syslog |grep wifi
May 20 15:40:16 voyage kernel: wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
May 20 15:40:16 voyage kernel: wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
May 20 15:40:16 voyage kernel: wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps
36Mbps 48Mbps 54Mbps
May 20 15:40:16 voyage kernel: wifi0: H/W encryption support:
WEP AES AES_CCM TKIP
May 20 15:40:16 voyage kernel: wifi0: mac 5.9 phy 4.3 radio 4.6
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 1 for WME_AC_BE traffic
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 0 for WME_AC_BK traffic
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 2 for WME_AC_VI traffic
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 3 for WME_AC_VO traffic
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 8 for CAB traffic
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 9 for beacons
May 20 15:40:16 voyage kernel: wifi0: Atheros 5212: mem=0xe0080000, irq=9
voyage: #
voyage: # cat /var/log/syslog |grep eth
May 20 15:40:16 voyage kernel: eth0: VIA Rhine III (Management Adapter) at
0xe0000000, 00:0d:b9:16:e7:9c, IRQ 10.
May 20 15:40:16 voyage kernel: eth0: MII PHY found at address 1, status 0x786d
advertising 05e1 Link 45e1.
May 20 15:40:16 voyage kernel: eth1: VIA Rhine III (Management Adapter) at
0xe0040000, 00:0d:b9:16:e7:9d, IRQ 12.
May 20 15:40:16 voyage kernel: eth1: MII PHY found at address 1, status 0x7849
advertising 05e1 Link 0000.
May 20 15:40:16 voyage kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
May 20 15:40:28 voyage kernel: eth0: no IPv6 routers present
voyage: #
7.2. Conguracin de las interfaces de red
Los archivos de conguracin estn editados con una plantilla que se puede modicar o adicionar rpida-
mente. En el archivo /etc/network/interfaces se especica la conguracin 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. Conguracin de Ethernet y de Bridge Ethernet
Para congurar las interfaces Ethernet se descomenta las lneas correspondientes y se cambiar la IP/Mscara
de red si es necesario.
auto eth0
iface eth0 inet static
address 10.10.10.1
netmask 255.255.255.240
#auto eth1
#iface eth1 inet static
#address 11.11.11.1
#netmask 255.255.255.0
7.2 Conguracin de las interfaces de red 95
Si se desea crear bridge, slo se podr hacer entre las Ethernet; se debe descomentar el bloque del bridge y
poner la IP/Mscara de red; adems la conguracin de las interfaces involucradas deben ser comentadas.
auto br0
iface br0 inet static
address 11.11.10.1
netmask 255.255.255.0
bridge_ports eth0 eth1
bridge_stp off
bridge_maxwait 5
7.2.2. Conguracin de las interfaces WiFi
La conguracin implica los siguientes pasos:
Eleccin si es AP STA.
Conguracin parmetros WiFi
Establecer seguridad
Conguracin de la IP/MASK
Si es AP se descomenta las lneas:
#--ap
ath_parent wifi0
ath_vaptype ap
Si es STA se descomenta las lneas:
#--cliente
ath_parent wifi0
ath_vaptype sta
#ath_vapopts nosbeacon
Slo en el caso de que en una placa se mezclen AP y STA la lnea #ath_vapopts nosbeacon del
STA deber ser descomentada.
Algunos parmetros WiFi son obligatorios, se cambiar de valor segn sea necesario.
#--otros parametros wifi
ath_distance 19800 est en metros, cada interfaz de un mismo enlace debe estar
configurado con la misma distancia; si se tiene varios STA
se coloca la distancia ms larga que existe entre el AP
y el STA (NOB)
ath_diversity 0 puede ser 1 habilitado o 0 deshabilitado) (NOB)
ath_txantenna 1 puede ser 1 o 2; se refiere al conector de la tarjeta
inalmbrica donde ser conectado la antena para transmitir;
si ath_diversity es 1 no interesa su valor
ath_rxantenna 1 puede ser 1 o 2; si ath_diversity es 1 no interesa su valor
ath_txpower 23 est dado dBm, si se pone debe ser un valor valido, puede ser
de 0 a 30, se debe conocer antes segn la tarjeta
inalmbrica (NOB)
ath_wirelessmode 11g puede ser 11a o 11g (OB)
ath_ssid EHAS1 nombre de la red (OB)
ath_channel 11 puede ser 1 al 11 en 2.4GHz o 36 al 160 en 5.8GHz (OB si es AP)
ath_rate 9M puede ser 6M, 9M, 12M ... 54M (NOB)
(NOB: no obligatorio, OB: obligatorio)
Para la seguridad; se puede elegir si se usa WEP o WPA-PSK; si se usa WEP aqu se pone la clave que
debe ser en hexadecimal; si se usa WPA2-PSK se descomenta el bloque respectivo si es STA o AP; y se debe
editar el archivo mencionado donde se cambiara el nombre de la red y la clave WPA2-PSK.
Si se usa WEP; se habilita y adems se congura la clave; se elige 10 nmeros hexadecimales (WEP de
64b) o 26 (WEP de 128b).
#--seguridad wep
ath_security wep
ath_wep_key1 12345ABCDE
Si se usa WPA2-PSK en una AP se habilita:
#--seguridad wpa-psk ap
ath_security wpa2
ath_wpa_cfgfile /etc/hostapd/hostapd-ath0.conf
Si se usa WPA2-PSK en una STA se habilita:
#--seguridad wpa-psk sta
wpa_driver madwifi
wpa_conf /etc/wpa_supplicant/wpasupplicant-ath0.conf
Por ltimo se congura la IP y la Mscara de red de la interfaz.
#--ip y netmask
address 10.10.1.2
netmask 255.255.255.240
Si se ha elegido seguridad WPA2-PSK adems de habilitar las opciones se debe editar los archivos adi-
cionales; donde slo se cambiar el nombre de la red y la clave WPA2-PSK (en caracteres y debe ser desde 8
a 63 caracteres). Existe un archivo plantilla para cada interfaz dependiendo si es STA o AP. Si se est congu-
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=10
psk="gtrcaswifi"
#psk=70df87c28aee0e42b49f55450df0f822200933ff3968406176fbcd41eb9a8a72
Si se esta congurando un AP que es ath2 entonces se edita /etc/hostapd/hostapd-ath2.conf
y se cambia el ESSID y la clave WPA2-PSK.
...
ssid=LOCAL2
...
wpa_passphrase=gtrcaswifi
7.3 Conguracin del enrutamiento esttico, gateway y NAT 97
Para activar los cambios realizados se ejecuta /etc/init.d/networking restart adems se ac-
tualiza la conguracin hecha /etc/network/statics-routes-nat.
7.3. Conguracin del enrutamiento esttico, gateway y NAT
Para poner en la ruta por defecto, NAT o rutas estticas se usa el archivo
/etc/network/nat-static-routes, donde se encuentran variables que sern habilitadas segn el uso.
Si el equipo debe tener una ruta por defecto se habilita la variable DEFAULT_GW, y se pone la direccin IP de
la ruta por defecto (gateway).
DEFAULT_GW="10.13.1.2"
Si se desea adicionar rutas esttico se habilitando la variable ROUTEX (donde X es 1,2,3...100) y en cada
una se pone la red, la mscara de red y la salida por donde se acceder a esta red; adems se pone la mtrica.
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 slo se optara por habilitar o no habilitar; si se habilita se descomenta la variable DEFAULT_NAT
y se elige la interfaz que har de NAT en el equipo.
DEFAULT_NAT= eth1
Al ejecutar /etc/init.d/networking restart se actualiza la conguracin hecha en
/etc/network/interfaces y en /etc/network/statics-routes-nat.
Si se va a usar OSPF, se recomienda congurar las rutas estticas en zebra.conf y no hacerlo en este archivo.
7.4. Conguracin del enrutamiento dinmico con OSPF
Para la enrutamiento con OSPF los archivos usados son:
curco-2n2:/etc/quagga# ls
daemons ospfd.conf zebra.conf ....
Para los comentarios en zebra.conf y ospfd.conf se usa el smbolo !
En /etc/quagga/daemons se pone en yes si se desea usar OSPF.
.....
zebra=yes
bgpd=no
ospfd=yes
ospf6d=no
ripd=no
ripngd=no
isisd=no
En zebra.conf; antes de todo se pone un nombre que podra ser el mismo que en ospfd.conf.
Hostname ospf-voyage
Se habilita las interfaces involucradas en el enrutamiento; se descomenta el bloque respectivo. Adems se
puede cambiar el ancho de banda, por defecto esta en 10MB.
interface ath0
bandwidth 10000000
ipv6 nd suppress-ra
Si este equipo pertenece a una red OSPF y est conectado a un equipo vecino que no pertenece a una red
OSPF y adems existe redes detrs de este equipo vecino; entonces si se quiere que la red OSPF acceda a stas
redes; entonces en ste archivo de debe especicar la ruta para llegar a esa red indicando por donde se llegara
y adems de la distancia. En resumen se est adicionadas rutas estticas en una red OSPF.
ip route 10.14.1.0/28 10.13.1.2 1
Si hay ms redes se debe adicionar ms lneas de estas
ip route 10.14.2.0/28 10.15.1.2 1
ip route 10.14.3.0/28 10.15.1.2 1
Aqu tambin se puede poner la ruta por defecto del equipo; pero ser mejor hacerlo en /etc/network
/nat-static-routes.
Para la conguracin 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; adems se debe poner
un costo (valor entero), para que no se use el ancho de banda congurado en zebra.conf.
interface ath2
ip ospf cost 10
Ahora se debe especicar el identicador del equipo en la red OSPF, es importante este valor y debe ser
distinto en la red OSPF (al menos en una misma rea).
ospf router-id 0.0.1.2
Ahora se debe poner las redes locales involucradas en la red OSPF; indicando Red/Mscara y el rea al
cual pertenece.
7.5 Conguracin del DHCP 99
network 10.10.1.0/28 area 0.0.0.0
network 10.10.2.0/28 area 0.0.0.0
network 10.11.1.0/28 area 0.0.0.1
network 10.21.1.0/28 area 0.0.0.2
Si este equipo es el lmite entre reas OSPF se debe indicar las redes que estn el rea que no sea el cero.
area 0.0.0.1 range 10.11.0.0/16
area 0.0.0.1 range 10.12.0.0/16
area 0.0.0.2 range 10.21.0.0/16
area 0.0.0.2 range 10.22.0.0/16
Si al equipo se le ha adicionado rutas estticas (zebra.conf); entonces se debe especicar como se debe
publicar estas rutas a la red OSPF; para esto se descomenta la siguiente lnea especicando la mtrica y el tipo;
si no se desea publicar estas rutas estticas se deja comentada la lnea.
redistribute static metric 10 metric-type 1
Si se ha congurado una puerta de salida equipo (/etc/network/nat-static-routes); entonces
se debe especicar como se debe publicar en la red OSPF. Para esto se descomenta una de las siguientes lneas:
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 tendrn una ruta por defecto este congurado o no en
el router que lo publica; sin always los routers tendrn una ruta por defecto mientras este congurado en el
router 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/networking
restart lo del OSPF se perder, para activar de nuevo se debe ejecutar /etc/init.d/quagga restart.
7.5. Conguracin del DHCP
Para habilitar el servicio en el arranque; se debe poner yes en la variable RUNDNSMASQ en el archivo
/etc/default/dnsmasq. El archivo de conguracin es /etc/dnsmasq.conf; en este archivo se es-
pecica:
a) La interfaz por donde se brindar este servicio.
interface=br0
b) El rango de IP (inicio-nal) y la Mscara de red; adems del tiempo de asignacin 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
Para completar se debe especicar 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. Conguracin de interfaces WiFi y de parmetros TCP/IP
mediante comandos
Crear la interfaz ath0 como AP
nodo-a: # wlanconfig ath0 create wlandev wifi0 wlanmode ap
Crear la interfaz ath0 como STA
nodo-a: # wlanconfig ath0 create wlandev wifi0 wlanmode sta
Activar la interfaz ath0
nodo-a: # ifconfig ath0 up
Congurar 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 (wi0)
nodo-a: # echo 0 >/proc/sys/dev/wifi0/diversity
nodo-a: # echo 1 >/proc/sys/dev/wifi0/txantenna
nodo-a: # echo 1 >/proc/sys/dev/wifi0/rxantenna
Congurar el ESSID, canal, velocidad de TX, clave WEP de 64bits y limitar la potencia de TX
nodo-a: # iwconfig ath0 essid PUCP channel 11 rate 12M key
aabbccddee txpower 10
Congurar la distancia (en metros) del enlace
nodo-a: # athctrl -i wifi0 -d 1000
Congurar la IP/MASK de la interfaz ath0
nodo-a: # ifconfig ath0 12.12.12.1 netmask 255.255.255.0
Congurar la IP/MASK de la interfaz eth0
nodo-a: # ifconfig eth0 10.10.1.1 netmask 255.255.255.0
Congurar la IP/MASK de la interfaz eth1
7.6 Conguracin de interfaces WiFi y de parmetros TCP/IP mediante comandos 101
nodo-a: # ifconfig eth1 192.168.1.2 netmask 255.255.255.0
Congurar una puerta de salida
nodo-a: # route add default gw 192.168.1.1
Congurar una ruta
nodo-a: # route add -net 10.10.2.0/24 gw 12.12.12.2 metric 10
Congurar NAT sobre eth1
nodo-b: # iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
Si se desea congurar DNS se debe indicar en /etc/resolv.conf.
Si una interfaz est como STA y se desea pasar a modo AP (o al revs), antes se debe deshabilitar la interfaz
lgica creada, as:
nodo-a: # wlanconfig ath0 destroy
y despus se crear la interfaz lgica:
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; despus de un reinicio se perder la conguracin.
8
Veri cacin del Estado de la Red de Datos
Como se ha comentado ampliamente en 1.4, con la tecnologa WiLD se puede llega a construir grandes
redes de datos. Estas se encuentran compuestas de redes troncales y de distribucin. Una red troncal consiste
tradicionalmente en lneas relativamente largas que recogen y reparten el trco a las zonas de distribucin
situadas en pequeas poblaciones.
En la gura 8.1 se puede apreciar la red troncal de color negro y la red de distribucin de color rojo. Tomando
como base el escenario presentado, a continuacin se detalla las medidas de vericacin de buen estado, que
debe realizarse en una red instalada con routers con sistema operativo Voyage GTR.
Figura 8.1: Redes Troncal y de Distribucin
103
104 CAPTULO 8. VERIFICACIN DEL ESTADO DE LA RED DE DATOS
8.1. Conectividad en enlaces AP-STA
Se debe de tener en cuenta que en una conexin 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 distribucin. Este tipo de
conguracin lo realiza el Router Inalmbrico.
Figura 8.2: Enlace AP-STA
8.1.1. Nivel de seal del enlace y relacin de la calidad del enlace
Para analizar un enlace se debe saber que interfaces estn involucradas y quien es Master (AP) y Managed
(STA); podemos comprobar el enlace directamente usando el comando iwcong; pero si se tiene una interfaz
Managed entonces se puede escanear los AP (Master) de sus alrededores y observar el AP al que debera 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 seal de recepcin que es alrededor de 72dBm (con link
Quality 23/94).
nodo-b: # iwlist ath0 scan
ath0 Scan completed :
Cell 01 - Address: 00:0C:42:18:F7:74
ESSID:PUCP
Mode:Master
Frequency:2.462 GHz (channel 11)
Quality=23/94 Signal level=-72 dBm Noise level=-95 dBm
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
48 Mb/s; 54 Mb/s
Extra:bcn_int=100
Extra:wme_ie=dd180050f2020101830002a3400027a4000042435e
Extra:ath_ie=dd0900037f010100240000
Estos parmetros representan la calidad del enlace. En largas distancias se puede asumir que se debe lograr
un nivel de entre -65dBm y -75dBm con una calidad (Link Quality) de unos 20dB; si se tiene un nivel por
debajo de -75dBm hasta -80dBm el enlace estar muy inestable y tendr un rendimiento bajo. Tomar nota por
cada router del enlace:
Nivel de seal del enlace
8.1 Conectividad en enlaces AP-STA 105
Calidad del enlace
nodo-b: # iwconfig ath0
ath0 IEEE 802.11g ESSID:"PUCP"Nickname:
Mode:Managed Frequency:2.462 GHz Access Point:00:0C:42:18:F7:74
Bit Rate=12 Mb/s Tx-Power=10 dBm Sensitivity=0/3
Retry:off RTS thr:off Fragment thr:off
Encryption key:AABB-CCDD-EE Security mode:restricted
Power Management:off
Link Quality=22/94 Signal level=-73 dBm Noise level=-95 dBm
Rx invalid nwid:241 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
nodo-a: # iwconfig ath1
ath1 Link encap:Ethernet HWaddr 00:0C:42:18:F7:74
Mode:Master Frequency:2.462 GHz Access Point:00:0C:42:18:F7:74
Bit Rate=12 Mb/s Tx-Power=10 dBm Sensitivity=0/3
Encryption key:AABB-CCDD-EE Security mode:restricted
En los nodos Managed se observa la MAC del AP, con esto se puede asegurar que existe enlace entre el
STA y el AP; adems se observa nivel aceptable de 70dBm (con un link quality de 25/94 aprox.). Adems con
el resultado de sta informacin se debe vericar el nombre la red WiFi, el canal, la potencia congurada, la
velocidad mxima, y la seguridad apoyada de otros archivos.
Con el siguiente comando se observar las potencias congurables en las tarjetas inalmbricas; por ejemplo
este resultado corresponde a una SR2 de Ubiquiti (posee un offset de 10dBm).
nodo-b: # iwlist ath0 txpower
ath0 8 available transmit-powers :
0 dBm (1 mW)
4 dBm (2 mW)
6 dBm (3 mW)
8 dBm (6 mW)
10 dBm (10 mW)
12 dBm (15 mW)
14 dBm (25 mW)
16 dBm (39 mW)
Current Tx-Power:10 dBm (10 mW)
Si se ha anulado la diversidad en una interfaz y se ha congurada el conector principal (Main) para transmitir y
recibir, se debe observar:
nodo-b: # cat /proc/sys/dev/wifi0/diversity
0
nodo-b: # cat /proc/sys/dev/wifi0/txantenna
1
nodo-b: # cat /proc/sys/dev/wifi0/rxantenna
1
nodo-b: #
8.1.2. Cantidad de clientes conectados al AP
Segn el diseo se debe comprobar que todos los clientes estn conectados al AP.
Anotar la cantidad de clientes conectados al AP.
voyage: # cat /proc/net/Madwifi/ath0/associated_sta
8.1.3. Correccin del alineamiento de las antenas
En un enlace de larga distancia (punto a punto o punto a multipunto) uno de los objetivos grandes a cumplir
es dejar las antenas alineadas lo mejor posible.
En enlaces punto a punto es probable que se usen antenas directivas. En enlaces punto multipunto lo ms
probable es que se use antenas sectoriales; en este caso se puede empezar apuntando la antena sectorial a la
bisectriz del arco formado por el conjunto de antenas con el que se desea establecer enlace.
Para alinear las antenas se necesita inicialmente conocer el ngulo de elevacin y el azimut y encontrar la
mejor posicin apoyados por medio de un alineador de antenas externo; pero para lograr mayor precisin se
puede usar las herramientas de los equipos a instalar; en este caso; se puede usar el comando iwconfig para
poder corregir el alineamiento de las antenas de un enlace.
Si por ejemplo; en un enlace punto a punto de unos 40Km con tarjetas de 400mW y antenas directivas de
24dBi en ambos puntos; se obtiene un nivel de seal de -91dBm (que es muy cerca al nivel de ruido de -94dBm)
y una calidad del enlace de 3; no se podr establecer ningn enlace; se tendra que corregir el alineamiento de
las antenas.
nodo-c: # iwconfig ath0
ath0 IEEE 802.11g ESSID:USCO2"Nickname:
Mode:Managed Frequency:2.417 GHz Access Point:Not-Associated
Bit Rate=6 Mb/s Tx-Power=off Sensitivity=0/3
Encryption key:6375-7363-6F Security mode:restricted
Si al mejorar el alineamiento se tiene un nivel de alrededor -84dBm con una calidad de 12 se lograr tener
enlace; pero al tener un nivel muy bajo ser muy inestable. Abajo se muestra que existe demasiada prdida de
paquetes y un rendimiento bajo.
nodo-c: # ping 10.1.2.1 -c 10
64 bytes from 10.1.2.1: icmp_seq=2 ttl=64 time=0.624 ms
...
nodo-c: # iperf -c 10.1.2.1 -i 5 -t 15
----------------------------------------
Client connecting to 10.1.2.1, TCP port 5001
TCP window size: 16.0 KByte (default)
----------------------------------------
[ 3] local 10.1.2.2 port 3962 connected with 10.1.2.1 port 5001
[ 3] 0.0- 5.0 sec 104 KBytes 170 Kbits/sec
[ 3] 5.0-10.0 sec 56.0 KBytes 91.8 Kbits/sec
[ 3] 10.0-15.0 sec 104 KBytes 170 Kbits/sec
[ 3] 0.0-15.6 sec 272 KBytes 143 Kbits/sec
nodo-c: #
Si se logra tener un nivel de -71dBm y una calidad de 22; el rendimiento mejorar, y no existir prdida de
paquetes, al menos en el mayor tiempo.
nodo-c: # ping 10.1.2.1 -c 10
...
nodo-c: # iperf -c 10.1.2.1 -i 5 -t 15
----------------------------------------
----------------------------------------
[ 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
nodo-b: #
Si con estos mismos equipos se est trabajando en enlaces ms cortos, de alrededor de 15Km este nivel
de recepcin obtenido an se puede mejorar, al menos hasta llegar a -55dBm; pero para enlaces de 40Km con
estas tarjetas inalmbricas y antenas directivas, este nivel puede ser lo mejor que se logre.
Lograr un aceptable nivel de la seal y calidad del enlace no necesariamente garantiza un buen rendimiento;
adems se debe observar los tiempos de ping que se hacen y el rendimiento (ver ms adelante) que se puede
lograr; el resultados de estos esta relacionado con la correcta conguracin de la distancia del enlace.
Inicialmente se puede dejar congurado el enlace con una distancia obtenida por medio de los simuladores
de enlaces WiFi y de las coordenadas obtenidas. Una vez en campo se puede encontrar la distancia ms ptima
que puede estar alrededor de ms o menos 300m del que se ha congurado. El cambio de la distancia se debe
hacer en ambos lados del enlace. En un enlace punto multipunto la distancia a congurar es la que se tiene con
la antena mas alejada.
Si no se ha congurado la distancia, por defecto se mostrar:
nodo-b: # cat /proc/sys/dev/wifi0/acktimeout
48
nodo-b: # cat /proc/sys/dev/wifi0/slottime
9
nodo-b: # cat /proc/sys/dev/wifi0/ctstimeout
48
nodo-b: #
Si se ha congurado para una distancia de 1000m por ejemplo; se tendra estos valores:
nodo-b: # cat /proc/sys/dev/wifi0/acktimeout
89
nodo-b: # cat /proc/sys/dev/wifi0/slottime
43
nodo-b: # cat /proc/sys/dev/wifi0/ctstimeout
89
nodo-b: #
Para no cambiar la distancia en /etc/network/interfaces se puede congurar por comandos y una
vez encontrado la distancia correcta se escribe en este archivo.
nodo-a: # athctrl -i wifi0 -d 10000
nodo-b: # athctrl -i wifi1 -d 10000
8.1.4. Ping normal entre las interfaces del enlace
Una vez que se haya vericado los enlaces WiFi se debe vericar los parmetros TCP/IP de cada interfaz
de red. La IP y la mscara de red se observa con el comando ifconfig:
nodo-a: # ifconfig ath0
inet6 addr: fe80::20c:42ff:fe18:f768/64 Scope:Link
RX bytes:4651917 (4.4 MiB) TX bytes:2217302 (2.1 MiB)
nodo-a: # ifconfig ath1
inet6 addr: fe80::20c:42ff:fe18:f774/64 Scope:Link
RX bytes:1015702 (991.8 KiB) TX bytes:3055968 (2.9 MiB)
nodo-a: #
Se prueba la conectividad con el comando ping. Adems de observar si la otra interfaz responde al ping; se
debe observar la regularidad de los ping que generalmente pueden oscilar entre 1 a 3ms en un enlace aceptable;
y adems la prdida de paquetes que generalmente deben estar entre 1 a 3 paquetes perdidos por cada 60
transmitidos (1 minuto). Para esta prueba se debe hacer un ping de unos 30 paquetes y por cada AP - STA del
enlace y anotar:
Si la otra interfaz responde al ping
Regularidad de los tiempos del ping,
Prdida de paquetes
El resultado de los ping esta relacionados con la distancia del enlace y con nivel y calidad de la seal, se debe
tener en cuenta de stos en esta prueba; quizs se tenga valor altos respecto a los referenciales.
voyage: # ping 11.11.11.1 -c 40
...
voyage: #
Si se obtiene resultados muy alejados de lo aceptable; se debe cambiar la distancia; cambiando en pasos de
100m hasta encontrar el ms ptimo. Despus de cada cambio se debe repetir la prueba de ping, como los ping
de mayor tamao y el rendimiento del enlace.
8.1.5. Ping con mayor tamao entre las interfaces del enlace
Un ping con mayor bytes transmitidos muestra una aproximacin de la carga que puede soportar el enlace;
esto se observa en la regularidad del tiempo de transmisin de paquetes y la prdida de stos. Si se transmiten
1500 bytes en el enlace ejemplo, el tiempo de cada ping debe ser regular y estar alrededor de 3 a 6ms; si se
tiene una irregularidad notable por ejemplo saltos de 5ms a 20ms en varios pings, se debe seguir vigilando y
revisar el enlace. La prdida de paquetes debe ser muy baja o casi nula comparada con la cantidad que se est
enviando en total. De la misma manera que el ping normal, esta prueba est relacionada con la distancia, el
nivel y calidad del enlace. Para esta prueba se debe hacer ping con una cantidad de unos 30 paquetes; se debe
anotar.
Si la otra interfaz responde al ping
Regularidad de los tiempos del ping.
Prdida de paquetes
voyage: # ping 11.11.11.1 -c 50 -s 1500
...
voyage: #
8.1.6. Medicin en el rendimiento de un enlace
La prueba con ping (simple y de mayor tamao) se hacen simultneamente con la prueba del rendimiento;
y estas tres estn relacionados directamente con la distancia congurada. Si se ha vericado el buen nivel de
seal y la poca prdida de paquetes en el enlace; el rendimiento que se obtendr debe estar entre 3 a 9Mbps.
Tenga en cuenta la relacin que existe entre el nivel de ruido y la velocidad congurada; si se tiene un enlace
de entre 1 a 2Mbps en buen tiempo (ausencia de lluvia y neblina) se debe revisar el enlace buscando posibles
fallas o mejoras al enlace; un valor menor a 1Mbps es un enlace malo y debe mejorarse. Se recomienda realizar
la prueba por unos 50s a ms y por cada AP - STA del enlace y anotar:
Rendimiento por cada intervalo de tiempo de la prueba
Rendimiento promedio al nalizar la prueba
nodo-b: # iperf -s
----------------------------------------
Server listening on TCP port 5001
----------------------------------------
nodo-a: # iperf -c 10.1.2.2 -i 5 -t 15
----------------------------------------
----------------------------------------
[ 3] 0.0- 5.0 sec 2.88 MBytes 4.84 Mbits/sec
...
nodo-a: #
8.1.7. Vericacin de la tabla de rutas y la ruta de salida
Se debe revisar que las redes a las que se desea acceder estn en la tabla de rutas de los equipos que
conforman el enlace; adems de la ruta por defecto si se ha congurado. En la tabla se observa las redes
accesibles y no los equipos accesibles; para esto se usa, el comando route, con l se pueden ver las redes
accesibles (Flag con UG) inclusive si se est usando OSPF. Anotar:
Si los equipos del enlace contienen todo las rutas conguradas o no.
nodo-b: # route -n
10.1.4.0 10.1.3.2 255.255.255.0 UG 0 0 0 ath1
10.1.53.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.1.52.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.1.55.0 10.1.3.2 255.255.255.0 UG 0 0 0 ath1
10.1.54.0 10.1.3.2 55.255.255.0 UG 0 0 0 ath1
10.1.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ath0
10.1.3.0 0.0.0.0 55.255.255.0 U 0 0 0 ath1
0.0.0.0 10.1.2.1 0.0.0.0 UG 0 0 0 ath0
nodo-b: #
Si se trabaja con enrutamiento dinmico las redes accesibles aparecern en la tabla de rutas; si alguno no
aparece se debe comprobar; quizs el problema es que ciertos enlaces estn cados; para esto se puede usar
traceroute.
nodo-b: # traceroute 10.1.4.2
traceroute to 10.1.4.2 (10.1.4.2), 30 hops max, 40 byte packets
1 10.1.1.2 (10.1.1.2) 0.573 ms 0.593 ms 1.258 ms
2 10.1.2.2 (10.1.2.2) 4.837 ms 2.315 ms 3.682 ms
3 10.1.3.2 (10.1.3.2) 8.673 ms 4.597 ms 5.248 ms
4 10.1.4.2 (10.1.4.2) 12.935 ms 6.315 ms 7.682 ms
nodo-b: #
Si se trabaja con enrutamiento esttico necesariamente se debe comprobar el acceso a la red con el comando
traceroute para vericar 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
-- www.google.com ping statistics --
nodo-b: #
8.1.8. Ping a todas las interfaces de red
Una vez revisado las rutas, se debe hacer ping (con una cantidad de 20 paquetes) desde cada equipo que
conforma el enlace hacia el resto de las interfaces de la red y observar:
Si a todos se llega correctamente o no.
Anotar adems posibles retardos o prdida de paquetes hacia una interfaz en particular para
su revisin posterior cuando se est en ese nodo.
8.2. Conectividad en una red troncal
Al hacer estas pruebas es probable que existan demasiadas prdidas de paquetes; se debe tener en cuenta
el tiempo (lluvias, neblinas en zonas alejadas) y la gran distancia entre cada par de nodos de la troncal, es
recomendable realizar la prueba en tiempos buenos, en todo el tramo de la red. El grco de abajo muestra una
red troncal tpica; 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 red
Se debe hacer ping desde uno de los extremos de la troncal hacia el resto de las interfaces de la red y
observar si a todos se llega correctamente o no; debe anotar adems posibles retardos o prdidas de paquetes
hacia una interfaz en particular para su revisin posterior cuando se visite ese nodo. Anotar:
Si es accesible a la interfaz o no
Observar si existe demasiada prdida de paquetes.
8.2.2. Medicin del rendimiento de la troncal
Se espera tener un rendimiento de 1 a 2Mpbs; depender del nmero de enlaces que exista; pero aunque
se tenga muchos enlaces conectados un rendimiento menor a 1Mpbs seria muy bajo para el funcionamiento
correcto de los servicios de la red. Se recomienda realizar la prueba del rendimiento con el iperf con un
tiempo total de unos 50s a ms; tal como la se muestra en el clculo del rendimiento de un enlace. Se debe
anotar:
Rendimiento observado por cada intervalo de tiempo de la prueba.
Rendimiento promedio al nalizar la prueba.
9
Con guracin de una red de Telefona IP con Asterisk
9.1. Conguracin inicial
Si se va ha usar asterisk en un equipo donde exista OSPF se debe poner el nombre del equipo tambin en
/etc/hosts.
voyage: # cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 voyage
Para activar el servicio en el arranque del sistema se debe poner en yes la variable RUNASTERISK en el
archivo /etc/default/asterisk.
voyage: # vim /etc/default/asterisk
# This file allows you to alter the configuration of the Asterisk
# init.d script
#
RUNASTERISK=yes
voyage: #
Es recomendable cargar el mdulo ztdummy; descomentar en:
voyage: # cat /etc/modules
...
ledtrig-heartbeat
ledtrig-timer
#zaptel
#ztdummy
voyage: #
Esto permitir que se cargue despus de un reinicio; pero si se desea que se cargue en este momento se
puede hacer:
voyage: # modprobe ztdummy
115
116CAPTULO 9. CONFIGURACIN DE UNA RED DE TELEFONA IP CON ASTERISK
9.2. Conguracin bsica de Asterisk
El Asterisk en la Voyage, (/etc/asterisk/modules.conf), est adaptado para realizar tareas mn-
imas, al ser un equipo de bajo rendimiento para este tipo de aplicacin.
Se ha desarrollado una conguracin bsica para realizar la comunicacin entre clientes SIP de un mis-
mo Asterisk y con clientes SIP administrados por otros Asterisk y adems permitir la comunicacin con la
red de telefona pblica; esta conguracin involucra a los archivos sip.conf, extensions.conf, y
iax.conf, todos stos ubicados en /etc/asterisk/. Se puede tomar esta conguracin como plantilla
para una conguracin particular. Recuerde que los comentarios en estos archivos de conguracin empiezan
con ; al inicio de la lnea.
9.2.1. Conguracin de los clientes SIP
El archivo /etc/asterisk/sip.conf tiene una conguracin inicial para clientes SIP; donde se
puede especicar los identicadores del cliente y los codecs a usar.
[general]
;
bindport=5060
disallow=all
allow=ulaw
allow=g726aal2
allow=gsm
allow=ilbc
allow=g726
;
[210]
type=friend
host=dynamic
language=es
context=center
secret=passwd
username=210
callerid=210
dtmfmode=rfc2833
qualify=yes
;
Para congurar clientes SIP con puerto FXO, se puede usar la identicacin 10; cambiado slo lo necesario.
[10]
type=friend
port=5061
host=dynamic
language=es
context=center
secret=passwd
username=10
callerid=10
dtmfmode=rfc2833
qualify=yes
;
9.2 Conguracin bsica de Asterisk 117
9.2.2. Programacin de las llamadas telefnicas
En /etc/asterisk/extensions.conf es donde se congura la comunicacin telefnica. En la
parte [globals] se especica las variables usadas, aqu se muestra variables que representan la IP de los
otros Asterisk de la red.
[globals]
;
IP-SERVER200=
IP-SERVER300=20.20.20.13
IP-SERVER400=
IP-SERVER-PSTN=
PHONE-DEFAULT=
La variable PHONE-DEFAULT= contiene el telfono que responder por defecto despus de escuchar el
IVR en una llamada proveniente del exterior.
En la parte (center) se especica con que equipos se tendr comunicacin; est divido en: comunicacin
con equipos locales, con equipos de otros Asterisk y con la telefona pblica
Aqu se muestra una especie de prueba de llamado al servidor, se especica un nmero que identique al
servidor Asterisk.
;prueba de llamada al servidor
exten =>200,1,Macro(call-svlocal,200)
;
Aqu se especica los nmeros telefnicos locales.
;llamar area local
exten =>210,1,Macro(dial-svlocal,SIP,${EXTEN})
exten =>211,1,Macro(dial-svlocal,SIP,${EXTEN})
;exten =>_21[0-9],1,Macro(dial-svlocal,SIP,${EXTEN})
Para comunicarse con otros servidores se especica la numeracin telefnica de estos, se puede usar rangos
como en este caso; adems debe poner la IP del Asterisk que administra este rango de nmeros telefnicos; co-
mo se observa esto se hace en base a variables por ejemplo IP-SERVER300 donde su valor estar en la seccin
de variables.
Para la comunicacin con la telefona pblica se especica los nmeros permitidos; tenga en cuenta que se
debe diferenciar de los nmeros telefnicos usados en la red; a veces se usa un prejo; en este caso se antepone
un cero, si se desea llamar al 147 sera 0147, si se desea una comunicacin sin restriccin se puede usar _0.
En el cuadro de abajo se muestran los comandos para comunicarse con la telefona pblica para el Asterisk
donde se va a registrar al cliente SIP que va ha conectar la telefona IP con la telefona pblica. En la primera
parte se muestra los nmeros permitidos para llamar a la telefona pblica y la segunda parte se muestra al iden-
ticador 11 que se usar para identicar todas las llamadas entrantes de la telefona pblica; como se observa,
estn redirigidas al IVR.
;llamar a clientes de otros servidores
exten =>_3[0-5]X,1,Macro(dial-svred, $IP-SERVER300, ${EXTEN})
exten =>_4XX,1,Macro(dial-svred, $IP-SERVER400, ${EXTEN})
En el cuadro de abajo se muestran los comandos para un Asterisk que no registre al equipo que une a la
telefona IP con la telefona pblica; en este caso el Asterisk deber comunicarse con el Asterisk que registre a
este equipos que une ambas redes.
;exten =>0147,1,Macro(dial-svred,$IP-SERVER-PSTN,${EXTEN})
exten =>_0.,1,Macro(dial-svred,$IP-SERVER-PSTN,${EXTEN})
9.2.3. Identicacin de direcciones IP de los servidores Asterisk
Si un Asterisk tiene que establecer comunicacin con otro Asterisk que est en un equipo que posee varias
IP, se debe elegir la IP de la interfaz que est ms prxima entre la comunicacin de ambos Asterisk. Abajo
se muestra las IP que contendra cada Asterisk en extensions.conf para comunicarse con el resto de los
Asterisk.
Figura 9.1: Identicacin de direcciones IP de los servidores Asterisk
9.2.4. Grabacin de archivos de sonido
Para hacer archivos se sonido del tipo gsm, se puede usar la funcin implementada en /etc
/asterisk/extensions.conf; para esto se llama al 170; despus de escuchar el beep se proceder a
grabar por el telfono hasta que se presione el smbolo #; despus se escuchar lo grabado y terminar la lla-
mada.
;grabacion de archivos de sonido gsm
exten =>170,1,Macro(sounds-record,gsm)
;
Los archivos sern grabados en /root/ con el nombre de mensaje-pbx-X.gsm donde X cambiar (0, 1, 2
...) segn se vaya grabando; cambien de nombre y segn su uso deber ser guardado en
/var/lib/asterisk/sounds/es/.
9.2.5. Conguracin de IVR bsico
El IVR se utiliza para contestar y direccionar las llamadas entrantes provenientes de la telefona pblica; es-
to est en /etc/asterisk/extensions.conf. Se debe especicar los archivos de sonido para el saludo
correspondiente; xivr_bienvenido_pucp contiene un saludo presentando a la institucin; xivr_opciones_pucp
contiene la opcin de esperar para que sea respondido por algn cliente SIP; xnumero_incorrecto contiene el
mensaje de numero incorrecto Los archivos de sonido en espaol deben estar en /var/lib/asterisk/
sounds/es/. Adems se debe especicar en la variable PHONE-DEFAULT el nmero telefnico que deber
contestar si no se elige un telfono vlido. En la parte nal se especica los nmeros telefnicos al que puede
acceder el llamante de la red de telefona pblica.
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)
;
9.2.6. Comunicacin con otros servidores Asterisk
El archivo /etc/asterisk/iax.conf se utiliza para la comunicacin con otros Asterisk no es nece-
sario que se edite; posee una conguracin general; si se hace cambios en este se debe tener en cuenta que estos
cambios deben estar reejados en /etc/asterisk/extensions.conf.
[general]
;
bindport=4569
language=es
disallow=all
allow=ulaw
allow=g726aal2
allow=gsm
allow=ilbc
allow=g726
;
[iaxuser]
type=user
username=iaxuser
callerid=iaxuser
secret=passwd
context=center
;
9.3. Registro de los clientes SIP
Una vez congurado 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 Asterisk
nodo-b: # /etc/init.d/asterisk stop Para detener el Asterisk
nodo-b: # /etc/init.d/asterisk restart Para reiniciar el Asterisk
En este caso se inicia la ejecucin del Asterisk; para observar el estado del registro de los clientes y del
propio Asterisk se debe acceder a entorno CLI del 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 Public
License version 2 and other licenses; you are welcome to redistribute it
under certain conditions. Type show license for details.
=========================================================================
Connected to Asterisk 1.2.13 currently running on nodo-b (pid = 7834)
Verbosity is at least 4
nodo-b
*
CLI>
nodo-b
*
CLI>sip show peers
Name/username Host Dyn Nat ACL Port Status
10/10 (Unspecified) D 0 UNKNOWN
nodo-b
*
CLI>
Dentro del CLI con el comando sip show peers se puede observar si los clientes se han registrado;
en el mensaje de arriba mostrado en la ltima columna se observa que los tres clientes estn con el mensaje
UNKNOWN por tanto no estn registrados si aparece OK entonces si estarn registrados.
Si ya se ha congurado los clientes SIP se debe comprobar su registro en el Asterisk.
nodo-b
*
CLI>
- Registered SIP 210t 10.1.52.3 port 5060 expires 3600
- Saved useragent "Linksys/SPA3102-3.3.6(GW)"for peer 210
- Registered SIP 10t 10.1.52.3 port 5061 expires 3600
- Saved useragent "Linksys/SPA3102-3.3.6(GW)"for peer 10
nodo-b
*
CLI>sip show peers
10/10 10.1.52.3 D 5061 OK (12 ms)
210/210 10.1.52.3 D 5060 OK (13 ms)
3 sip peers (2 online , 1 offline)
Se observa que los clientes 10 y 210 estn ya registrados. Para salir del CLI slo se hace exit.
nodo-b
*
CLI>exit
Executing last minute cleanups
nodo-b: #
Si se modica los archivos de conguracin para cargar sta nueva conguracin en el Asterisk se hace:
nodo-b
*
CLI>reload
Pero mejor quizs sea detener el Asterisk y de nuevo cargarlo as:
nodo-b
*
CLI>stop now
Executing last minute cleanups
nodo-b: # /etc/init.d/asterisk start
Debe asegurarse que el Asterisk est activo; para esto se puede usar ps -le | grep asterisk si ar-
roja resultado entonces el Asterisk est corriendo; sino no lo est. Si por cualquier motivo no se puede ejecutar
9.4 Vericacin del estado de telefona IP con Asterisk 121
el Asterisk entonces se debe ejecutar con la opcin:
nodo-b:: # asterisk -vvvvc
...
...
Asterisk Ready.
*
CLI>
En la Voyage-GTR el Asterisk corre como root. Con esto se observar la carga de cada mdulo del Asterisk,
si uno de ellos falla nos lo mostrar; si la falla es grave no continuar con la carga del Asterisk y se detendr
en el primer error grave; si todo est correcto se llegar al CLI del Asterisk, con esto se tendr asegurado que
la falla no es debido a la carga de algn mdulo; si an hay fallas se debe seguir observando los mensaje que
aparecern en el CLI.
Si todo est bien; se sale del CLI, pero como en este caso se ha ingresado al CLI con la opcin -c, entonces
no se podr usar el comando exit, para esto se debe detener el Asterisk y cargar de nuevo as:
*
CLI>stop now
nodo-b: # /etc/init.d/asterisk start
No olvide que debe comprobar de nuevo que el Asterisk est cargado o activo.
9.4. Vericacin del estado de telefona IP con Asterisk
9.4.1. Estado del registro de clientes y tono en los telfonos
En el cuadro de abajo se observa el registro de los equipos clientes telefnicos 10 y 210; porque aparece
OK en Status. El tiempo de registro de los equipos telefnicos deber ser menor a 50ms; si se tiene un tiempo
mayor se debe evaluar instalar un servidor en la misma red del equipo cliente. Anotar:
Que equipos estn registrados
El tiempo de registro de los clientes telefnicos
nodo-b
*
CLI>sip show peers
10/10 10.1.52.4 D 5061 OK (12 ms)
210/210 10.1.52.3 D 5060 OK (13 ms)
3 sip peers (2 online , 1 offline)
Los equipos telefnicos deben dar tono una vez descolgado el auricular.
9.4.2. Llamada de prueba al servidor de telefona IP
Se debe realizar una llamada de prueba al servidor Asterisk, adems se debe observar el resultado de sta
llamada en el CLI del Asterisk la correcta ejecucin de los comandos:
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 )
- 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-081b0fb8n macro call-svlocal
== Spawn extension (center, 200, 1) exited non-zero on SIP/210-081b0fb8
voyage-112
*
CLI>
9.4.3. Llamada de prueba a un cliente local
Se debe realizar una llamada de prueba a un cliente administrado por el mismo servidor Asterisk al que se
est evaluando, adems 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 conversacin.
Calidad en la conversacin.
voyage-112
*
CLI>
voyage-112
*
CLI>
- Executing (210@center:1) Macro("SIP/211-b7200470", "dial-svlocal|SIP|210") in new stack
- Executing (s@macro-dial-svlocal:1) Dial("SIP/211-b7200470", "SIP/210|26") in new stack
- Called 210
- SIP/210-081b0fb8 is ringing
- SIP/210-081b0fb8 answered SIP/211-b7200470
- Native bridging SIP/211-b7200470 and SIP/210-081b0fb8
voyage-112
*
CLI>
voyage-112
*
CLI>
voyage-112
*
CLI>sip show channels
Peer User/ANR Call ID Seq (Tx/Rx) Format Hold Last Message
20.20.20.199 210 1a234c1f236 00103/00000 0x4 (ulaw) No Tx: ACK
20.20.20.113 211 355739771-5 00102/00011 0x4 (ulaw) No Tx: ACK
2 active SIP channels voyage-112
*
CLI>
voyage-112
*
CLI>
voyage-112
*
CLI>core show channels
Channel Location State Application(Data)
SIP/210-081b0fb8 (None) Up AppDial((Outgoing Line))
SIP/211-b7200470 s@macro-dial-svlocal Up Dial(SIP/210|26)
2 active channels
1 active call
voyage-112
*
CLI>
voyage-112
*
CLI>
== Spawn extension (macro-dial-svlocal, s, 1) exited non-zero on SIP/211-b7200470n 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 telefona IP
Se debe realizar una llamada de prueba a los otros servidores Asterisk y observar en el CLI de ambos
Asterisk la correcta ejecucin de los comandos. Anotar:
Si se realiza sin problemas una llamada de prueba al resto de los servidores de telefona de la red.
9.4 Vericacin del estado de telefona 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-081b0fb8n macro dial-svred
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 )
- 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-16325n macro
call-svlocal
== Spawn extension (macro-call-svlocal, s, 5) exited non-zero on AX2/20.20.20.112:4569-16325
- Hungup AX2/20.20.20.112:4569-16325 voyage
*
CLI>
9.4.5. Llamada de prueba a un cliente administrado por otro servidor
Se debe realizar una llamada de prueba a un cliente remoto que sea administrado por otro Asterisk; anotar
si esto se realiza sin problemas, comentar sobre la calidad de la conversacin; adems se debe observar en el
CLI de ambos Asterisk si la comunicacin se realiza con el codec congurado, si los comandos se ejecutan
correctamente. Se debe realizar llamado a todos, si es necesario. Anotar:
Si se realiza sin problemas una llamada de prueba con un cliente administrado por otro servidor.
Codec utilizado en la conversacin.
Calidad de la conversacin.
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 channels
Channel Location State Application(Data)
IAX2/20.20.20.13:456 (None) Up AppDial((Outgoing Line))
SIP/210-081b0fb8 s@macro-dial-svred:1 Up Dial(IAX2/iaxuser:passwd@20.20
2 active channels
1 active call
voyage-112
*
CLI>
voyage-112
*
CLI>
voyage-112
*
CLI>sip show channels
Peer User/ANR Call ID Seq (Tx/Rx) Format Hold Last Message
20.20.20.199 210 1208132620- 00101/00051 0x4 (ulaw) No Rx: ACK
1 active SIP channel
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-081b0fb8n macro dial-svred
voyage-112
*
CLI>
voyage-112
*
CLI>
voyage
*
CLI>
- Accepting AUTHENTICATED call from 20.20.20.112:
>requested format = ulaw,
>requested prefs = (ulaw),
>actual format = ulaw,
>host prefs = (ulaw|g726),
>priority = mine
- Executing Macro(AX2/20.20.20.112:4569-1642", "dial-svlocal|SIP|310") in new stack
- Executing Dial(AX2/20.20.20.112:4569-1642", "SIP/310|26") in new stack
- Called 310
- SIP/310-0817d6c8 is ringing
- SIP/310-0817d6c8 answered IAX2/20.20.20.112:4569-1642
voyage
*
CLI>
voyage
*
CLI>
== Spawn extension (macro-dial-svlocal, s, 1) exited non-zero on AX2/20.20.20.112:4569-1642
in macro dial-svlocal
== Spawn extension (macro-dial-svlocal, s, 1) exited non-zero on AX2/20.20.20.112:4569-1642
- Hungup AX2/20.20.20.112:4569-1642
voyage
*
CLI>
voyage
*
CLI>
10
Caso de Estudio: Red Napo Sur
10.1. Generalidades
El presente documento presenta la memoria tcnica de los trabajos de instalacin y puesta en operacin de
los sistemas de comunicacin de voz y datos del Proyecto Mejora de las condiciones de salud de la poblacin
materno-infantil a travs del uso apropiado de las Tecnologas de la Informacin y las Comunicaciones (TIC)
en centros y puestos de salud del Ro Napo (Per) el cul ha sido nanciado por el Ayuntamiento de Madrid
y ejecutado por la Fundacin EHAS y el Grupo de Telecomunicaciones Rurales de la Ponticia Universidad
Catlica del Per (GTR-PUCP).
El proyecto fue ejecutado en los distritos de Punchana, Mazn y Napo, en la provincia de Maynas, depar-
tamento de Loreto. Contempl la interconexin de cinco establecimientos de salud rurales, el Vicariato de San
Jos del Amazonas (donde existe un albergue de reposo para los pacientes y sus familiares que son referidos al
Hospital Regional de Loreto para atenciones especializadas en la ciudad de Iquitos), la ocina de Radiofona
de la Direccin 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 a
once establecimientos de salud. A la fecha el objetivo ha sido cumplido en su totalidad. Con los sistemas de
comunicacin de voz y datos operando se est contribuyendo a la reduccin de la morbi-mortalidad Materno
Infantil en esta zona rural aislada del Per.
Figura 10.1: Departamento de Loreto (izquierda) y Provincia de Maynas (derecha).
125
126 CAPTULO 10. CASO DE ESTUDIO: RED NAPO SUR
10.2. Descripcin General de la Red de Comunicaciones
El Proyecto contempl la instalacin de sistemas de comunicaciones de voz y datos en los ambientes del
Hospital Regional de Loreto, Planta de Ventas PetroPer y Vicariato (Distrito de Punchana); CS Mazn y PS
Huamn Urco (Distrito de Mazn); y PS Tuta Pishco, PS Negro Urco y PS Tacsha Curaray (Distrito de Napo).
En la siguiente tabla se muestra los datos georeferenciales de los establecimientos de salud que fueron
beneciados con la instalacin del sistema de transmisin de voz y datos:
tem
Establecimiento Latitud
Longitud Altura (msnm)
01
Emergencia HRL
3
4333.85 73
1509.44 105
02 Radiofona DISA Loreto 3
4332.78 73
1515.49 105
03 Vicariato 3
4334.13 73
1429.50 105
04 CS Mazn 3
2951.70 73
0529.70 115
05 PS Huamn Urco 3
1907.10 73
1304.30 116
06 PS Tuta Pishco 3
0635.00 73
0819.00 106
07 PS Negro Urco 3
0114.20 73
2326.80 139
08 PS Tacsha Curaray 2
4848.00 73
3227.00 115
Tabla 10.1.- Coordenadas geogrcas de los establecimientos de salud.
En la siguiente gura se muestra la ubicacin geogrca de los establecimientos mencionados en la
Tabla 1.
Figura 10.2: Ubicacin geogrca de los establecimientos de salud.
En la siguiente tabla se muestra los datos georeferenciales de la ubicacin de las torres ventadas de
los establecimientos de salud y de las instalaciones que forman parte de la red troncal del sistema
de transmisin de voz y datos:
10.2 Descripcin General de la Red de Comunicaciones 127
Item Torres y/o Soportes Latitud
Longitud Altura (msnm)
01
Hospital Regional de Loreto
3
4333.80 73
1512.17 105
02 Planta de Ventas PetroPer 3
4332.29 73
1436.25 105
03 Mazn 3
2959.90 73
0528.00 109
04 Huamn Urco 3
1907.60 73
1301.90 116
05 Tuta Pishco 3
0631.40 73
0817.50 106
06
Negro Urco
3
0123.10 73
2331.50 131
07 Tacsha Curaray 2
4847.60 73
3227.20 135
Tabla 10.2.- Coordenadas geogrcas de las torres ventadas y soportes de antenas.
En la siguiente gura se muestra la ubicacin geogrca de las torres ventadas e instalaciones
mencionadas en la Tabla 2.
Figura 10.3: Ubicacin geogrca 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.11
02 PetroPer Mazn 30.23
03 Mazn Huamn Urco 24.52
04
Huamn
Urco
Tuta Pishco 24.93
05 Tuta Pishco
Negro Urco
29.74
06
Negro Urco Tacsha Curaray 28.58
Tabla 10.3.- Distancia de los enlaces.
En la Figura 4 se muestra el esquema de la ampliacin de la red del Napo, especcamente se observa la
red troncal, los enlaces de distribucin, los repetidores y las estaciones clientes.
Figura 10.4: Esquema de la ampliacin 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 distribucin hacia los establecimientos de salud cada estacin repetidora cuenta
con un cliente, salvo el caso del repetidor ubicado en el Hospital Regional de Loreto, el cul cuenta con dos
clientes. En la siguiente gura se muestra en detalle un segmento de red.
Figura 10.5: Topologa detallada de un segmento de red.
10.3 Descripcin de la Red de Telecomunicaciones 129
10.3. Descripcin de la Red de Telecomunicaciones
10.3.1. Enlaces Troncales
Haciendo uso del software Radio Mobile y los datos georeferenciales adquiridos durante la visita de estudio
de campo se dise cada uno de los enlaces troncales de la red inalmbrica con el objetivo de obtener el mejor
rendimiento utilizando equipos inalmbricos 802.11b para los enlaces rurales (desde Tacsha Curaray hasta
Mazn) y utilizando equipos inalmbricos 802.11a para los enlaces urbanos (desde Mazn hasta el Hospital
Regional de Loreto). Ver Tabla 4.
Luego de realizado los trabajos de instalacin se han adquirido los datos georeferenciales nales de cada
estacin y los resultados de las simulaciones se detalla a continuacin.
Figura 10.6: Esquema de la red troncal simulada con el software de Radio Mobile.
Enlace Establecimientos Estndar
01 HRL PetroPer 802.11a
02 PetroPer Mazn 802.11a
03 Mazn Huamn Urco 802.11b
04
Huamn
Urco
Tuta Pishco 802.11b
05 Tuta Pishco
Negro Urco
802.11b
06
Negro Urco Tacsha Curaray 802.11b
Tabla 10.4.- Estndar de los enlaces de la red troncal
Parmetros del enlace urbano Hospital Regional Loreto PetroPer
Frecuencia mnima (MHz): 5180
Frecuencia mxima (MHz): 5805
Modo estadstico: Difusin: 90% tiempo / 80 % ubicaciones / 80 % situaciones
Clima: Continental Sub-Tropical
Sistema empleado: R52H (tx: 80mW rx: -90dBm) en modo 802.11a
Tipo de antena: Directiva tipo grilla de 27dBi de ganancia
Prdida de lnea: 0.5dB
Figura 10.7: Perl del enlace Hospital Regional de Loreto PetroPer.
Figura 10.8: Enlace Hospital Regional de Loreto PetroPer.
Parmetros del enlace urbano PetroPer Mazn
Sistema empleado: R52H (tx: 250mW rx: -90dBm) en modo 802.11a
Figura 10.9: Perl del enlace PetroPer Mazn.
Figura 10.10: Enlace PetroPer Mazn.
Parmetros del enlace rural Mazn Huamn Urco
Sistema empleado: R52H (tx: 320mW rx: -95dBm) en modo 802.11b
Figura 10.11: Perl del enlace Mazn Huamn Urco.
Figura 10.12: Enlace Mazn Huamn Urco.
Parmetros del enlace rural Huamn Urco Tuta Pishco
Figura 10.13: Perl del enlace Huamn Urco Tuta Pishco.
Figura 10.14: Enlace Huamn Urco Tuta Pishco.
Parmetros del enlace rural Tuta Pishco Negro Urco
Figura 10.15: Perl del enlace Tuta Pishco Negro Urco.
Figura 10.16: Enlace Tuta Pishco Negro Urco.
Parmetros del enlace rural Negro Urco Tacsha Curaray
Figura 10.17: Perl del enlace Negro Urco Tacsha Curaray.
Figura 10.18: Enlace Negro Urco Tacsha Curaray.
10.3.2. Caractersticas de los Equipos Instalados
10.3.2.1. Equipos empleados en los enlaces troncales de 2.4GHz 802.11b/g
Equipo
Fabricante Modelo Caractersticas
Interface
802.11b/g
Ubiquiti
Networks
SR2 Super
Range 2
Interface 2.4GHz 802.11b/g mini-PCI
Chipset Atheros AR5213 MAC/BB
Potencia de transmisin real de 24dBm, +/-1dB
para una tasa de 1-24 MbpsSensibilidad para una
tasa de 5.5Mbps de -95dBm, (en estndar 802.11b)
Consumo de corriente @3.3VTransmisin:
1-24 Mbps 1300mA, +/-100mARecepcin:
350mA, +/-50mA
Antena
Hyperlink
Technolo-
gies
HG2424G
Antena direccional
2.4GHz Banda ISM 24dBi
Peso: 3.62Kgs
Router -
Computado-
ra
PC Engines
ALIX 2C0
233 MHz AMD Geode SC1100 CPU
128 MB SDRAM
Almacenamiento a travs de una Compact Flash.
Consume alrededor de 3 a 5W con 12V DC
2 Puertos Ethernet
2 Puertos miniPCI
Sistema operativo: Pebble Linux, Voyage Linux,
AstLinux, AspisOS, iMedia Wrap Linux, etc.
El sistema operativo instalado es la
Voyage-GTR-0.4
Cables
Coaxiales
Heliax
SuperFlex
Impedancia caracterstica : 50
Prdida por metro : 0.1 dB
Conectores usados : N macho
Cables
pigtail
Hyperlink
Un extremo conector: UFL (Compatible con
Hirose/iPax/Mini-PCI).
Otro extremo conector: N hembra
Longitud: 20cm
Frecuencia de trabajo: 2.4GHz 6GHz.
Atenuacin: 5.38dB/metro en 6GHz
Tabla 10.5.- Caractersticas de los equipos 802.11b/g de la red troncal.
10.3.2.2. Equipos empleados en los enlaces troncales de 5.8GHz 802.11a
Equipo
Interface
802.11a
Mikrotik R52H
Interface 5.8GHz 802.11a/b/g mini-PCI
Chipset
Potencia de transmisin real 24dBm
Sensibilidad -90dBm @ 6Mbps
Antena
Hyperlink
Technologies
HG5827G
Antena direccional tipo grilla
5.8GHz Banda ISM 27dBi
Peso: 2.4Kgs
Router -
Computado-
ra
Mikrotik
RouterBoard
333
333MHz CPU
64MB SDRAM
Consume 19W con 12V DC
3 Puertos Ethernet
3 Puertos miniPCI
Sistema operativo:
RouterOS 3.20 Licencia nivel 4
Cables
Coaxiales
Heliax
SuperFlex
Impedancia caracterstica : 50
Prdida por metro : 0.1dB
Conectores usados : N macho
Cables
pigtail
Hyperlink
Un extremo conector: UFL (Compatible con
Hirose/iPax/Mini-PCI).
Otro extremo conector: N hembra
Longitud: 20cm
Frecuencia de trabajo: 2.4GHz 6GHz.
Atenuacin: 5.38dB/metro en 6GHz
Tabla 10.6.- Caractersticas de los equipos 802.11a de la red troncal.
10.3.2.3. Equipos empleados en los enlaces de distribucin de 2.4GHz 802.11g
Equipos
Interface
inalmbrica
Mikrotik R52H
Interface 2.4GHz 802.11a/b/g mini-PCI
Potencia de salida mxima en estndar g: 25dBm
Antenas
Hyperlink
Technologies
HG2414P-NF
2.4 GHz Banda ISM
IEEE 802.11b, 802.11g Wireless LAN
Antena Panel Yagi 14dBi
Routers
Linksys
WRT54GL
Router, posee 5 puertos Ethernet, 1 puerto Internet
y punto de acceso Wireless-G (802.11g) a 54 Mbps
Tabla 10.7.- Caractersticas de los equipos 802.11g elegidos para el enlace de distribucin.
10.3.3. Distribucin de los equipos en los repetidores y estaciones clientes
10.3.3.1. Distribucin en los repetidores de Tacsha Curaray, Negro Urco, Tuta Pishco y Huamn
Urco (enlaces en 2.4GHz)
En la siguiente gura se muestran los equipos que se han instalado en los repetidores (enlaces troncales y de
distribucin) implementados en Tacsha Curaray, Negro Urco, Tuta Pishco y Huamn Urco. En cada repetidor se
han instalado dos placas ALIX, las cuales han sido etiquetadas como ALIX n1 y ALIX n2. La placa n1 cuenta
con dos tarjetas inalmbricas: una tarjeta SR2 para enlazar con su vecino del norte y una tarjeta inalmbrica
R52H encargada de establecer el enlace con su cliente local. En el caso de la placa n2 cuenta con solo una tarjeta
inalmbrica SR2. La cul permite el enlace con su vecino del sur. Adicionalmente en sta placa se encuentra
instalado el servidor Asterisk local. La energa de alimentacin es proporcionada por el sistema fotovoltaico.
Figura 10.19: Esquema de conexiones en una estacin repetidora de los enlaces rurales (Tacsha
Curaray Negro Urco Tuta Pishco Huamn Urco).
10.3.3.2. Distribucin en el repetidor de Mazn (enlaces en 2.4GHz y 5.8GHz)
En el repetidor de Mazn se han instalado una placa ALIX y una placa MIKROTIK. La placa ALIX cuenta
con una tarjeta inalmbrica SR2 para enlazar con el repetidor de Huamn Urco (2.4GHz) y tiene instalado el
servidor Asterisk. La placa MIKROTIK cuenta con dos tarjetas inalmbricas R52H: la primera para enlazar con
el repetidor ubicado en Planta de Ventas de PetroPer (enlace troncal en la frecuencia de 5.8GHz) y la segunda
tarjeta para el enlace con el Centro de Salud de Mazn (enlace de distribucin en la frecuencia de 2.4GHz). La
energa es proporcionada por el sistema fotovoltaico.
Figura 10.20: Esquema de conexiones de la estacin repetidora de Mazn.
10.3.3.3. Distribucin 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 funcin
que cumple la placa ALIX n2 es ser el servidor Asterisk local. Los enlaces inalmbricos los administra la
placa MIKROTIK n1 mediante tres tarjetas inalmbricas R52H. Los enlaces hacia el repetidor de Mazn y el
repetidor ubicado en el Hospital Regional de Iquitos son enlaces en la frecuencia de 5.8GHz. En el caso del
enlace de distribucin hacia el Vicariato de San Jos del Amazonas se realiza en la frecuencia de 2.4GHz. La
energa es proporcionada desde la caseta de energa ubicada en la base de la torre.
Figura 10.21: Esquema de conexiones de la estacin repetidora de PetroPer.
10.3.3.4. Distribucin en el repetidor del Hospital Regional de Loreto (enlaces en 2.4GHz y
5.8GHz)
En el repetidor del Hospital Regional de Loreto se ha instalado una placa MIKROTIK con tres tarjetas
inalmbricas R52H. El enlace con el repetidor ubicado en Planta de Ventas se realiza en la frecuencia de
5.8GHz. Y los dos enlaces de distribucin uno hacia la ocina de Radiofona de la Direccin Regional de Salud
y el segundo hacia los ambientes de Emergencia del Hospital Regional de Loreto se realizan en la frecuencia
de 2.4GHz
Figura 10.22: Esquema de conexiones de la estacin repetidora de PetroPer.
10.3.3.5. Distribucin en las estaciones clientes (enlaces de distribucin)
En la siguiente gura se muestran los equipos inalmbricos y la red LAN instalados en cada estacin cliente
(enlace de distribucin); el Linksys es un equipo para interiores por lo que sus antenas fueron reemplazados por
una antena panel de 14dBi para exteriores. Todos los enlaces de distribucin son en la frecuencia de 2.4GHz.
En la Figura 24 se muestra en detalle los equipos instalados en cada estacin cliente.
Figura 10.23: Esquema de conexiones en una estacin cliente.
10.3.4. Sistema de Energa y Proteccin Elctrica
En cada estacin rural se han instalado sistemas de energa fotovoltaica con su respectivo sistema de protec-
cin elctrica tanto en las estaciones repetidoras como los enlaces de distribucin. En las siguientes dos guras
se muestran los esquemas de ambos sistemas con los equipos y elementos empleados.
En el caso de las estaciones ubicadas en la ciudad de Iquitos son alimentadas con energa elctrica de la
red pblica de Electro Oriente y el sistema de proteccin elctrica empleado es el encontrado ya instalado
previamente en cada establecimiento.
Figura 10.24: Esquema del sistema de energa en una estacin cliente rural y de su sistema de
proteccin elctrica.
Figura 10.25: Esquema del sistema de energa en una estacin repetidora rural y de su sistema de
proteccin elctrica.
Los pozos de tierra construidos en las estaciones rurales son pozos horizontales de 10m de longitud lineales
en el caso de las estaciones clientes y de 20m de longitud en forma cuadrada alrededor de la base de la torre
ventada. La seccin de ambos pozos es de 50cm de ancho por 60cm de profundidad.
En el caso del repetidor ubicado en la Planta de Ventas de PetroPer la torre ventada cuenta con su sistema
de proteccin elctrica 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 proteccin
elctrica 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, Huamn Urco y Mazn.
Resistencia de los Pozos Tierra
Establecimiento Estacin Cliente () Estacin Repetidora ()
Mazn 8.65 7.11
Huamn Urco 1.65 5.32
Tuta Pishco 3.81 6.75
Negro Urco
6.42 8.95
Tabla 10.8.- Medida de resistencia de los sistemas PAT.
Bibliografa
[1] B. Raman,Digital Gangetic Plains: 802.11-Based Low-Cost Networking for Rural Areas, 2001
2004: A Report, by Bhaskaran Raman, Ed., DGP Media Labs Asia Team, July 2004.
[2] Chieng, D.; Tan, S.W.; Rahim, R.; Ting, A.,QoS Performance Analysis of Multi-Radio Multi-Hop
Wi-Fi Chain Network, Wireless Broadband and Ultra Wideband Communications, 2007. AusWireless
2007. The 2nd International Conference on , vol., no., pp.38-38, 27-30 Aug. 2007
[3] E Brewer, M Demmer, Bowei W. Du, M Ho, M Kam, S Nedevschi, J Pal, Rabin Patra, S Surana, and K
Fall,The case for technology in developing regions, (2005). Computer. 38 (6), pp. 25+.
[4] Experiences in using WiFi for Rural Internet in India, Bhaskaran Raman and Kameswari Chebrolu, IEEE
Communications Magazine, Jan 2007, Special Issue on New Directions In Networking Technologies In
Emerging Economies.
[5] Francisco Javier Sim Reigadas, Modelado y Optimizacin de IEEE 802.11 para su aplicacin en el
despliegue de redes extensas en zonas rurales aisladas de pases en desarrollo, 2007.
http://www.ehas.org/uploads/file/difusion/academico/Tesis/TesisJSimo.
pdf
[6] Grupo de Telecomunicaciones Rurales-PUCP, Redes Inalambricas para Zonas Rurales, Primera
Edicin, 2008
http://gtr.telecom.pucp.edu.pe/
[7] Long Distance Wireless Mesh Network Planning: Problem Formulation and Solution, Sayandeep Sen
and Bhaskaran Raman. The 16th Annual Interntional World Wide Web Conference (WWW 2007), May
2007, Banff, Canada.
[8] Long-Distance 802.11b Links: Performance Measurements and Experience, Kameswari Chebrolu,
Bhaskaran Raman, and Sayandeep Sen, 12th Annual International Conference on Mobile Computing and
145
146 BIBLIOGRAFA
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 Based
Long Distance Networks, 2007.
http://www.usenix.org/events/nsdi07/tech/patra.html
[11] S. Garigala. Experimental Validation of Simultaneous Operation in an 802.11 Multi-hop Mesh Network.
Master s thesis, Indian Institute of Technology, Kanpur, July 2004.
[12] S. Xua and T. Saadawi. Revealing the problems with 802.11 medium access control protocol in multi-hop
wireless ad hoc networks. Computer Networks, 38, 2002.
[13] Z. Fu, P.Zerfos, H. Luo, S. Lu, L. Zhang, and M. Gerla. The impact of Multihop Wireless Channel on
TCP Throughput and Loss. In IEEE INFOCOM, 2003.
[14] Alvarion.
http://www.alvarion.com/
[15] Asterisk.
http://www.asterisk.org/
[16] Cisco Systems.
http://www.cisco.com/
[17] HyperGain HG2424G 2.4 Ghz 24 dBi High Perfomance Reector Grid Antenna.
http://www.hyperlinktech.com/web/hg2424g.php
[18] International Telecommunications Union - Statistics.
http://www.itu.int/ITU-D/ict/statistics/
[19] MadWi.
http://madwifi-project.org/
[20] Mikrotik
http://www.routerboard.com/
[21] PC Engines.
http://www.pcengines.ch/
BIBLIOGRAFA 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 BIBLIOGRAFA
Glosario
ACK Acknowledgment code.
ACPI Interfaz Avanzada de Conguracin y Energa.
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 Conguration Protocol.
149
150 Glosario
DIFS Tiempo que cada estacin 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 Ofce.
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, Scientic and Medical.
ITU International Telecommunication Union.
LAN Local Area Network.
LUF Lowest useable frequency.
MAC Media Access Control.
MIB Management Information Base, Base de Informacin de Gestin.
MINSA Ministerio de salud.
Glosario 151
MUF Maximum Usable Frequency.
MVC Modelo-Vista-Control, Model-View-Controller.
NAT Traduccin de Direccin de Red.
NAV Network Allocation Vector.
NIC Network Interface Card.
NTP Network Time Protocol.
OFDM Orthogonal Frequency-Division Multiplexing.
ONG Organizacin No Gubernamental.
PAT Puesta a tierra.
PHY Physical layer.
PIRE La mxima 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 Relacin de onda estacionaria.
RRCONN Round Robin Connections.
RTPC Red Telefnica Pblica Conmutada.
RTS/CTS Request to Send / Clear To Send.
S.O. Sistema Operativo.
SIFS Tiempo jo que dene la separacin entre la recepcin del paquete de la transmisin de su ACK en el
receptor.
SIP Session Initiation Protocol.
SMTP Simple Mail Transfer Protocol.
SNMP Simple Network Management Protocol.
SNR Signal Noise Ratio.
SREJ Rechazo selectivo de paquetes.
152 Glosario
TCP Transmission Control Protocol.
TIC Tecnologas de la informacin 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

Enlaces Wifi Larga Distancia

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Enlaces Wifi Larga Distancia

Cargado por

Copyright:

Formatos disponibles

WiLD

WiFi Based Long Distance

También podría gustarte