Professional Documents
Culture Documents
Primera Edición
Edición: Daniel Carbajal, Jeffry Cornejo, José Luis Vargas, Luis Camacho, Aldo Duarte, Renzo
Navarro, Yuri Pacheco.
⃝2009,
c GTR-PUCP
Primera edición: Agosto 2009
Hecho el Depósito Legal en la Biblioteca Nacional del Perú 𝑁 𝑜 2009-09928
ISBN: 978-9972-659-93-5
Autores: Luis Camacho, River Quispe, César Córdova, Leopoldo Liñán, David Chávez.
Esta publicación ha sido elaborada gracias al financiamiento del Programa de Ciencia y Tecnología
FINCYT.
Los autores de este libro no se responsabilizan de los incidentes o daños que pudiera ocasionar la
utilización de la información contenida en él.
Este libro está publicado bajo la licencia Reconocimiento-Uso no Comercial-Compartir por Igual,
versión 2.5, de Creative Commons Perú.
http://creativecommons.org/licenses/by-nc-sa/2.5/pe/legalcode
Índice general
Índice general 1
Introducción 7
1
2.4.2. Ath5k y Ath9k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.4.3. Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4.4. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.5. Quagga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4. Enrutamiento Dinámico 59
4.1. Tipos de Enrutamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.1. Tabla de Enrutamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.1.2. Enrutamiento Estático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.1.3. Enrutamiento Dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2. Enrutamiento Dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.2.1. Tipos de Protocolos de Enrutamiento Dinámico: . . . . . . . . . . . . . . . . . 61
4.2.2. Características de los Protocolos de Enrutamiento Dinámico . . . . . . . . . . . 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. Métrica 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 más 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. Identificación de las aplicaciones a implementar . . . . . . . . . . . . . . . . . . . . 77
5.2. Configuración rápida mediante archivos de las interfaces de red (Ethernet y WiFi) . . 78
5.3. Configuración rápida de enrutamiento estático . . . . . . . . . . . . . . . . . . . . . 79
5.4. Seguridad WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.5. Enrutamiento dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.6. Telefonía IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.7. Configuración vía web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.8. Adaptación de Voyage para el trabajo en entornos rurales . . . . . . . . . . . . . . . 82
Bibliografía 157
Glosario 161
6
Introducción
Este libro es una nueva iniciativa del Grupo de Telecomunicaciones Rurales de la Pontificia Uni-
versidad Católica del Perú (GTR-PUCP) para contribuir a la ampliación y difusión del conocimiento
existente sobre tecnologías apropiadas para el acceso a la información y comunicación en zonas ru-
rales.
La mayor parte de los contenidos de este libro han sido gestados gracias al aporte financiero de
FINCyT, el Fondo de Inversión en Ciencia y Tecnología, http://www.fincyt.gob.pe; una ini-
ciativa del Estado Peruano para contribuir al incremento de la competitividad del país, fortaleciendo
las capacidades de investigación e innovación tecnológica y promoviendo la articulación de la Em-
presa, Universidad y Estado.
El libro es llamado WiLD, WiFi based Long Distance, citando un término probablemente acuñado
por TIER, Technology and Infraestructure for Emerging Regions, un grupo de investigación de la
Universidad de California en Berkeley. El término hace referencia al conjunto de soluciones para la
transmisión inalámbrica de voz y datos basados en el protocolo 802.11, y cuya virtud más notable, es
alcanzar enlaces de muy larga distancia (entre 50 y 100 km), mucho mayores que las distancias para
las que originalmente fue diseñado el protocolo 802.11.
El título es apropiado pues este libro trata sobre Voyage GTR, un sistema operativo basado en la
distribución Linux Voyage, a la cual se han añadido aplicaciones hasta obtener un sistema operativo
específico (un firmware si se quiere). Este software desarrollado instalado sobre un hardware apropia-
do, convierte al conjunto, en un router WiFi de largo alcance, como puede verse en la siguiente figura:
7
8
La gran cobertura es una de las varias características que hace que los routers Voyage GTR sean
apropiados para la creación de redes en zonas rurales.
En los capítulos tres y cuatro se narran aspectos teóricos de dos de las características más impor-
tantes dentro de Voyage GTR: Telefonía IP y Encaminamiento Dinámico OSPF. Estas dos propiedades
se implementan a través de los programas Asterisk y Quagga.
En el quinto capítulo se describe Voyage GTR y todas las modificaciones y aplicaciones aãdidas
a Linux Voyage para conseguir el producto final.
En los capítulos seis, siete y ocho se detalla los aspectos técnicos del uso de Voyage GTR: la
instalación y configuración básica, configuración de redes cableadas e inalámbricas y la verificación
del estado de una red instalada.
IP utilizando Asterisk.
Finalmente en el décimo capítulo se presenta un caso de estudio, la red Napo Sur (provincia de
Maynas, región Loreto en Perú), perteneciente a la Dirección Regional de Salud de Loreto, Perú; mon-
tada con routers Voyage GTR. Esta red sumada a la parte Norte (también instalada con los mismos
equipos) forman en conjunto probablemente la red en servicio WiFi multisalto más larga del planeta.
La población es pobre y dispersa, por lo que no puede soportar los costes de infraestructuras
caras de instalar, mantener y operar. Tampoco los estados de los países en vías de desarrollo
están en condiciones de poder subvencionar la instalación de redes de comunicaciones rurales
en pro de la cobertura total, tanto por su falta de recursos como por la enorme proporción que
las poblaciones rurales no contributivas representan en el total.
10
Tiene que ser robusta y sencilla de usar, ya que los usuarios van a ser poco cualificados y no
van a contar con el apoyo continuo de asesores preparados.
Tiene que requerir poco o ningún mantenimiento de técnicos especializados, ya que éstos van
a estar lejos y va a resultar caro y difícil atraerlos para la resolución de los problemas. Con más
razón debe ser mínima la necesidad de administración de las redes, ya que ésta genera costes
fijos considerables.
Debe ser de bajo consumo, ya que frecuentemente tendrá que depender de instalaciones de
energías fotovoltaicas o eólicas que encarecen las instalaciones y aumentan las necesidades y
costes de mantenimiento.
Debe tener costes de despliegue y de operación muy bajos. Ésto excluye las redes cableadas, las
de telefonía móvil y las redes satélite como soluciones únicas. En ocasiones se puede plantear
el acceso al mundo de toda una red por estos medios, pero la distribución del acceso se tendrá
que hacer con una tecnología complementaria más barata. Este criterio también desaconseja en
muchos casos las redes radio en bandas de frecuencia licenciadas.
Con estos condicionantes, el GTR-PUCP ha trabajado desde 1999 en varias líneas de investigación
que persiguen determinar cuales son las tecnologías inalámbricas más apropiadas a zonas rurales
aisladas de países en desarrollo, mejorarlas y aplicarlas de forma óptima. En [6] se describen distintas
tecnologías propuestas para la instalación de redes de telecomunicaciones en este contexto. Todas
ellas son inalámbricas, ya que dadas las características descritas anteriormente, una red cableada sería
muy costosa de instalar y mantener. En el presente libro se profundizará sobre el uso de la alternativa
tecnológica basada en WiFi.
Redes WiFi para largas distancias
1
Desde el 2001, una de las tecnologías que se ha tomado en consideración muy seriamente para
las comunicaciones de largas distancias es la IEEE802.11, popularmente llamada WiFi; si bien este
estándar no se concibió para redes extensas, sus indudables ventajas de costo, uso de frecuencias li-
bres de licencia y gran ancho de banda, han despertado el interés de diversos agentes tecnológicos de
países en desarrollo. Incluso en los núcleos urbanos de muchos países se han dado experiencias de
aplicación de WiFi para distribuir el acceso a Internet con la mayor cobertura posible en exteriores.
Además, el enorme éxito de WiFi en todos los ámbitos ha dado lugar a una gran cantidad de productos
en el mercado, casi todos ellos de bajo consumo, a precios bajos y mucha flexibilidad de uso, espe-
cialmente en combinación con desarrollos de software abierto. Respecto al uso de frecuencias en los
casos en que no hay un vacío legal, la mayor parte de los estados adoptan las restricciones de la FCC
en el uso de las banda ISM 2.4GHz y 5.8GHz usadas por esta tecnología. Como se puede apreciar en
el Cuadro 1.1, estas normas son mucho más permisivas que las europeas y permiten realizar en las
zonas rurales enlaces tanto punto a punto (PtP) como punto a multipunto (PtMP) de varias decenas
de kilómetros.
Las ventajas e inconvenientes que presenta el uso de esta tecnología se indican a continuación:
11
12 CAPÍTULO 1. REDES WIFI PARA LARGAS DISTANCIAS
Ventajas:
Uso de frecuencias sin licencia de las bandas ISM 2.4 / 5.8 GHz con ciertas limitaciones de
potencia.
Velocidades desde 1 hasta 54 Mbps, siempre teniendo en cuenta que el throughput neto obtenido
está alrededor de un 50-70 % de esos valores.
Tecnología con estándar ampliamente conocido y fácil de configurar, lo que favorece los bajos
costes de los equipos.
Flexibilidad: un nodo puede adherirse a la red si puede ver a uno de los nodos vecinos (las
zonas rurales aisladas normalmente no siguen una distribución geométrica ordenada alrededor
de un punto central).
Inconvenientes:
Requiere línea de vista directa (esto podría elevar, en algunos casos, el número de repetidores
necesarios aumentando demasiado el costo).
Al ser una tecnología creada para redes de corto alcance, hay que solventar ciertos problemas
relacionadas con su utilización para distancias de decenas de Km.
y IEEE802.11g, añadieron nuevas técnicas de modulación en la capa física logrando mayores veloci-
dades de transmisión y una mayor robustez en la conectividad.
El estándar IEEE802.11a trabaja en la banda de frecuencia de los 5GHz utilizando la técnica de
transmisión OFDM. Da soporte a velocidades de transmisión de 6Mbps a 54Mbps y ocho canales
no interferentes de 20MHz. Esta banda de frecuencia está menos saturada que la de 2.4GHz, lo cual
es una ventaja, ya que la banda de 2.4GHz también es utilizada por algunos teléfonos inalámbri-
cos, hornos microondas y equipos Bluetooth. El gran inconveniente de este estándar es el de no ser
compatible con el IEEE802.11b, mucho más difundido.
El estándar IEEE802.11b trabaja en la banda de frecuencia de 2.4GHz utilizando el sistema de
transmisión HR/DSSS. Mediante el uso de la modulación CCK se da soporte a las velocidades de
transmisión de 5.5Mbps y 11Mbps. Se cuenta con catorce canales (que pueden estar limitados a once
o trece según el país) de 22MHz, de los cuales se pueden utilizar simultaneamente hasta tres de forma
no interferente.
El estándar IEEE802.11g fue desarrollado a raíz del importante problema de incompatibilidad
entre los equipos de IEEE802.11a y IEEE802.11b. Además, la creación de este estándar atendía al
interés en incrementar la capacidad de los equipos y redes WiFi. IEEE802.11g trabaja en la banda de
frecuencia de 2.4GHz, manteniendo además los mismos canales y modulaciones de IEEE802.11b, y
añade el sistema OFDM mediante el cual se soportan velocidades de transmisión de hasta 54Mbps.
La sensibilidad de recepción.
La mínima relación señal a ruido que estemos dispuestos a aceptar como suficiente.
El propio estándar determina que los límites de potencia que se puede transmitir dependen de la
legislación que atañe a la banda de frecuencias ISM para cada región geográfica, éstas se mostraron
en la Cuadro 1.1.
Además, hay algunos aspectos de la capa física que deben ser tenidos en cuenta para obtener una
mayor estabilidad en el enlace:
conjunto de todas las anteriores para el modo 802.11g. Estos modos usan diferentes tipos de
modulación y codificación, de forma que cuanto mayor sea la velocidad, mayor es la poten-
cia necesaria en recepción para mantener un enlace con una BER baja. Esta potencia, llamada
sensibilidad, obliga a usar velocidades bajas si se quiere lograr enlaces de larga distancia con
una cierta estabilidad. La diferencia en la sensibilidad de recepción entre 1 y 11Mbps, aunque
depende de equipos, suele ser de más de 10 dB, lo cual equivale prácticamente a cuadruplicar
con 1Mbps el alcance que se tiene con 11Mbps. Si además se tiene en cuenta que la banda ISM
2.4 GHz impone limitaciones en cuanto al nivel de potencia que es legal transmitir, es fácil
comprobar que para enlaces muy largos normalmente deben usarse las velocidades más bajas
de 802.11b para tener estabilidad y buena calidad. La aparición de tarjetas con mejores sensibil-
idades o la tecnología 802.11g pueden ayudar a lograr velocidades mayores. Así, por ejemplo
en el modelo de tarjeta Ubiquiti SR2 802.11b/g de 400mW, la diferencia de sensibilidad entre
el modo b en 1 Mbps y el modo g en 6 Mbps es de sólo 3dB.
Añadir también que en términos de estabilidad y prestaciones resulta mejor configurar la ve-
locidad del canal a un valor fijo. La experiencia recomienda ser conservadores para soportar una
cierta pérdida de prestaciones que sin duda se va a dar con el tiempo por pérdida de alineación
de las antenas, cambios climáticos y otros factores.
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.
ACKtimeout: Este parámetro se define en el texto del estándar como el tiempo en que la estación
transmisora espera la llegada del ACK una vez que ha terminado la transmisión de un paquete.
Así pues, para que una comunicación WiFi funcione a una determinada distancia se tiene que
cumplir que el ACKtimeout sea mayor que el tiempo de propagación de ida y vuelta más el
SIFS, un tiempo fijo que define la separación entre la recepción del paquete de la transmisión
de su ACK en el receptor. No obstante, el estándar no da un valor claro a este parámetro, y
los equipos WiFi del mercado varían mucho en su implementación del ACKtimeout; algunos
sistemas tienen un valor por defecto de aproximadamente DIFS+SIFS pero que se puede mod-
ificar, y otras tienen valores no modificables pero más grandes. DIFS es el tiempo que cada
estación espera una vez que detecta que el canal ha quedado libre. Cuando una estación intenta
enviar un paquete a otra que está demasiado distante como para recibir de ella el ACK antes
de que transcurra el ACKtimeout, se interpretará que la transmisión falló y se retransmitirá; co-
mo lo mismo le sucede a cada retransmisión, cada paquete se retransmitirá el máximo número
de retransmisiones antes de descartarse y dejar paso al siguiente. La capa WiFi de la estación
transmisora “creerá” que no logró mandar el paquete, pero de hecho lo probable es que hayan
llegado correctamente varias copias de éste, de las que la primera se pasará a la capa superior
en el receptor. El resultado es que el enlace funciona, pero con un rendimiento ínfimo debido a
que todo se retransmite varias veces, por defecto 7.
Slottime. Los valores de Slottime, SIFS y DIFS imponen restricciones al funcionamiento del
MAC de WiFi a partir de ciertas distancias. El estándar prevé que las estaciones que transmiten
son oídas por las otras dentro del mismo slot en que se ha producido la transmisión, lo cual
impone un límite de unos 3 Km. Más allá de esa distancia, las prestaciones de los enlaces
empeoran con la distancia, aunque aún resultan utilizables si el número de nodos activos es
suficientemente bajo.
La vulnerabilidad con nodos ocultos. Se considera como “nodo oculto” a la situación donde
no todas las estaciones pueden escucharse, en IEEE 802.11 se emplea el mecanismo RTS/CTS
para evitar colisiones entre nodos ocultos; no obstante, ese mecanismo funciona si el cómputo
del NAV se corresponde con el tiempo que verdaderamente el canal va a permanecer ocupado;
puesto que el NAV no se calcula teniendo en cuenta el tiempo de propagación, a medida que
la distancia aumenta, su efectividad empeora; en enlaces PtMP con distancias del orden de
kilómetros, el RTS/CTS es prácticamente inservible, y no hay un mecanismo alternativo.
Como consecuencia de lo anterior, y dependiendo del tipo de enlace que define la arquitectura de
red 802.11, se pueden sacar las siguientes conclusiones:
16 CAPÍTULO 1. REDES WIFI PARA LARGAS DISTANCIAS
PtMP. Además de darse las mismas anomalías de comportamiento del MAC entre la estación
transmisora y receptora de un paquete que se han comentado para PtP, las otras estaciones que
observan pasivamente el canal esperando que se desocupe tomarán decisiones equivocadas al
considerar el canal libre cuando no lo está. Por ejemplo, si la distancia hace que los ACK se
reciban más tarde que DIFS, la estación transmisora todavía podrá esperar por el ACK si el
ACKTimeout es lo suficientemente grande, pero las otras estaciones cercanas a ésta que esperan
a que el canal se libere optarán a ocupar el canal de inmediato, pudiendo colisionar con cierta
probabilidad con el ACK que está en camino. Por lo que hay que fijar el ACKtimeout para el
enlace más largo que conforme ese PtMP.
En definitiva, WiFi puede servir, aunque con cierta pérdida de prestaciones, para enlaces PtP de
larga distancia si los equipos terminales permiten configurar el ACKtimeout y el Slottime; en cambio,
para PtMP, aún modificando esos parámetros, el funcionamiento es notablemente peor a menos que
la carga ofrecida y el número de nodos sean muy bajos.
En muchos casos, esta topología es la única posible para enlazar comunidades rurales estableci-
das a lo largo de ríos amazónicos o en valles interandinos longitudinales; por ello, es la topología
más estudiada por GTR-PUCP. Al igual que una red Mesh, esta topología también permite extender
notablemente la cobertura; a diferencia de ella, en una cadena multisalto el camino físico está plena-
mente establecido, la comunicación iniciada en un nodo intermedio necesariamente debe pasar por
el nodo que lo antecede o que lo precede para llegar a su destino. Tiene el obvio inconveniente que
la “rotura” de algún enlace interrumpe la comunicación entre extremos, por ello es deseable que la
cadena tenga más de un punto de contacto con el exterior. Eventualmente la cadena puede cerrarse y
volverse un anillo.
Esta red puede ramificarse como se ve en la figura 1.3. Aunque cada nodo puede estar compuesto
del mismo equipamiento hardware, podemos establecer una diferenciación funcional de tres tipos de
nodos:
Estación pasarela: es una estación dotada de conectividad final a Internet y a la RTPC, permi-
tiendo al resto de estaciones de la red inalámbrica acceder a través de ella a esas redes externas.
Puede haber una o varias de estas estaciones en una red inalámbrica, pero lo más frecuente es
que no se disponga más que de una. El uso de más de una implica el uso de encaminamien-
to dinámico. Estas estaciones frecuentemente tendrán que desempeñar funciones como NAT o
cortafuegos.
Repetidor: los distintos repetidores se unen formando la red troncal que se encarga de conmutar
las comunicaciones con otras estaciones.
Estación cliente: se encuentra en los puntos de servicio a usuarios. Suele tener conectado una
computadora y un teléfono IP.
Además es importante distinguir entre enlaces troncales y enlaces de distribución. Los enlaces
troncales constituyen la columna vertebral de la red, interconectan a todos los nodos repetidores y a
la estación pasarela, transportan el tráfico combinado de varios clientes. Los enlaces de distribución
permiten el acceso de los clientes a la red.
Como ya se mencionó, cada enlace punto a punto se realiza en modo infraestructura, lo que im-
plica que un extremo de este enlace es un router que tiene una interfaz inalámbrica de red que se
comporta como STA estación “final” (sin importar que en esta topología el enlace podría estar en
medio de la cadena) y en el otro extremo hay otro router con una interfaz que se comporta como
punto de acceso AP. Para lograr la comunicación a lo largo de toda la cadena, el router usado en cada
nodo debe poseer por lo menos dos, y típicamente tres interfaces de red inalámbrica, lo que es equiv-
alente a tener igual número de radios. En la figura 1.4 puede verse como cada una de estas interfaces
se puede configurar independientemente como STA ó como AP. También es posible que en cada nodo
20 CAPÍTULO 1. REDES WIFI PARA LARGAS DISTANCIAS
exista más de un router, unidos por enlaces cableados Ethernet. A fin de minimizar la interferencia,
cada par de enlaces contiguos se realiza en canales diferentes. 802.11b/g tiene 11 canales, 3 de ellos
no interferentes; por su parte 802.11a tiene 16 canales y 12 de ellos no solapados entre sí (4 de los 12,
señalados para enlaces punto a punto). Un equipo de estas características puede verse en la fig 1.5 en
la que se distinguen todos sus componentes, nótese que posee dos radios, de 400 y 80 mW.
Debido a que debe existir línea de vista entre las antenas que establecerán un enlace, estas se
montan en la cima de torres elevadas. Cada antena se conecta con una interfaz de red inalámbrica de
un router. En microondas, las pérdidas de señal en los cables coaxiales de conexión son muy elevadas,
por ello el router debe colocarse a pocos metros de las antenas, es decir que también se monta en la
torre y para energizarlo es común que además se instale un sistema eléctrico autónomo en la torre [6].
1.4 Arquitectura de redes WiFi para larga distancia 21
Bajo coste. No se pueden implementar soluciones de un alto costo que no sean sostenibles en
el medio y largo plazo por las comunidades objetivo de estas redes.
Reducido tamaño. De esta forma se asegura que el diseño final del router sea lo más compacto
posible.
Robusto ante condiciones meteorológicas adversas. Ya que el router se suele instalar en zonas
de selva y alta montaña es necesario que tenga cierta robustez en cuanto a condiciones extremas
de temperatura y humedad.
Tipo de procesador. El router debe contar con un procesador lo suficientemente potente para
poder realizar las diferentes tareas que se le exijan.
Número mínimo y tipos de interfaces inalámbricas. Debido a que el router actúa como repetidor
en diversos escenarios es recomendable que al menos cuente con 3 interfaces inalámbricas.
Además, es necesario que estas interfaces sean de un tipo determinado (PCMCIA, CardBus,
mini-PCI) como se detalla en un apartado posterior.
Resto de interfaces. Además de las interfaces inalámbricas es necesario considerar otro tipo
de interfaces. Entre otras las dos más importantes son: una interfaz serie a través de la cual
23
CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN
24 DE ROUTERS WIFI DE LARGA DISTANCIA
poder acceder al router para labores de configuración y mantenimiento, y al menos una inter-
faz Ethernet para conectar otros dispositivos de red (por ejemplo un teléfono IP). También es
recomendable la existencia de una interfaz USB que permita extensiones o conexiones futuras.
Los equipos comerciales propietarios que más se han acercado [14], [16], [22], [23], a cumplir
todos los requisitos técnicos finalmente han fallado en poseer una adecuada relación costo/beneficio.
Otra consideración en contra de los equipos comerciales es que no son completamente compatibles
con equipos de otros fabricantes, debido a que realizan modificaciones en el acceso al medio pre-
visto en el protocolo 802.11. Finalmente nada desdeñables son los problemas que pueden surgir al
seleccionar una solución comercial propietaria tales como: dependencia tecnológica de un proveedor,
descontinuidad de los productos y costos de licenciamiento futuro.
Usando equipamiento genérico que soporta estándares abiertos y software libre, se pueden evitar
esos riesgos. Por ello, en paralelo al surgimiento de las iniciativas para realizar enlaces WiFi de larga
distancia, aparecieron en el mercado hardware, tales como placas SBC, tarjetas de red inalámbrica y
otros insumos con los cuales se podía armar un router WiFi por un precio generalmente menor ó mu-
cho menor que el de un equipo propietario comercial. La aparición del mencionado hardware motivó
el desarrollo de herramientas de software libre tales como: versiones del sistema operativo Linux “a
medida” (instalable en poco espacio de disco, para hardware específico) y drivers para tarjetas de red
inalámbrica; y con ello finalmente la creación de routers WiFi apropiados se hizo posible.
Existen muchas maneras de armar un router inalámbrico, ya que se cuenta con muchos modelos
de tarjetas de red inalámbrica, placas SBC y accesorios. Por supuesto, también se puede armar routers
para uso en ambientes externos y muy agrestes, lo cuál depende de contar con una adecuada caja de
intemperie.
2.1 Placa SBC 25
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.
Los procesadores que sí poseen FPU como el AMD Geode LX700, mantienen compatibilidad
con la arquitectura x86; específicamente este procesador es del tipo genérico, y no está 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 sólo limitado por la velocidad de proce-
samiento. En este caso existen muchos sistemas operativos libres (en base a Linux, FreeBSD, NetB-
SD, OpenBSD) y propietarios que manejen arquitecturas compatibles con x86; y a la vez son sistemas
genéricos; la gran ventaja con usar sistemas libres es que se puede adicionar o quitar aplicaciones que
sean convenientes a nuestro trabajo. Al tener FPU se puede trabajar aplicaciones de alto nivel como
por ejemplo el servidor Asterisk (http://www.asterisk.org/) que es una PBX software para
implementar redes de VoIP.
2.1.2.3. Alix2C0
http://www.pcengines.ch/alix2c0.htm
Es una placa que se basa en el procesador AMD Geode LX700, es un x86 y posee FPU. No viene
con ningún sistema operativo, posee ranura para CF para instalar uno. Posee dos ranuras miniPCI que
con modificaciones soportará interfaces inalámbricas de alta potencia. Al ser un sistema x86 se tiene
la gran facilidad de trabajar con las distintas aplicaciones de redes conocidas de alto nivel.
RouterBOARD MPC8321, 64MB 64MB integrada 3 3 tipo |||A/|||B, 12 a 28V DC, 180 MikroTik Router OS
333 266.333 MHz, para alta potencia fuente de 25W
no FPU
Freescale
RouterBOARD MPC8343E, 64MB 64MB integrada y 2 3, soporta 4 tipo |||A/|||B, 10 a 56V DC, 245 MikroTik Router OS
600 266,400,533, ranuras de CF 1000Mbps para alta potencia fuente de 35W habilitado
Mhz, no FPU en mayo
AMD Geode 2, no menciona
Alix2C0 LX700, 433 128MB 1 ranura CF 2 alta potencia, pero 7 hasta 20V, 116 iMedia ALIX Linux
600 Mhz, posee se hace cambios fuente de 15W Voyage Linux
FPU para alta potencia MikroTik Router OS
AMD Geode 2, no menciona
net4826-48 SC1100, 233 128MB 256MB de 1 4 tipo |||A, no pero 6 a 28V DC, 200 Voyage Linux
600 Mhz, posee CompactFLASH menciona alta fuente de 15W
FPU integrada potencia
AMD 2, no menciona
net4526-30 ElanSC520, 64MB 256MB de 1 4 tipo |||A, no pero 6 a 20V DC, 150 Voyage Linux
600 133Mhz, CompactFLASH menciona alta fuente de 10W
posee FPU integrada potencia
2 tipo |||A/|||B más
MIPs32 4Kc, el daughterboards 6 a 22V o 25 a
RouterBOARD 400MHz, no 64MB 128MB integrada y 3 RB502 ($) se 56V DC (por 200 MikroTik Router OS
532A FPU 1 ranura CF tiene 2 más, para jumper), fuente
alta potencia de 24W
4, menciona para
Pronghorn Intel XScale, alta potencia, 48VDC (SBC- AD|LinuxDistribution
Metro SBC IXP425, 533 64MB 16MB soldado y 2 cada uno ofrece 48) o 24VDC 300 StarOS, Linux 2.6,
Quad-Radio Mhz, no FPU 1 ranura CF 6.5W, soporta (SBC-24) OpenWRT, IkarusOS
Wireless WiMax
2, menciona para
Pronghorn Intel IXP425 64MB 16MB soldado y 2 alta potencia, 5VDC 190 AD|LinuxDistribution
SBC-250 533Mhz, no 1 ranura CF cada uno ofrece StarOS, Linux 2.6,
FPU 6.5W OpenWRT, IkarusOS
29
CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN
30 DE ROUTERS WIFI DE LARGA DISTANCIA
Interfaces Estándar Potencia máx Potencia máx 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
R52H de Mikrotik
2.2.2. Pigtails
Los pigtails son cables coaxiales con conectores adecuados para las tarjetas de red inalámbricas.
Estos se tratan, típicamente, de conectores UFL y MMCX, mostrados en la Figura 2.14. En el otro
extremo los pigtails tienen conectores N hembra o macho. Dado que los conectores UFL y MMCX
son sumamente pequeños, los pigtails están fabricados con cables coaxiales muy delgados de mucha
atenuación motivo por el cual deben ser lo más cortos posible (típicamente de 30 cm).
2.2.3. Antenas
Las antenas son dispositivos pasivos que convierten la señal de radio frecuencia enviada por los
cables coaxiales en ondas electromagnéticas que se propagan en el espacio y viceversa.
Dada la diversidad de situaciones en las que las que se necesitan las antenas, tales como: PtP,
PtMP, con distancia entre los puntos variable, entre centenas de metros y decenas de kilómetros, y
con distintas características ambientales de los lugares donde se han instalado, se utilizan multitud de
modelos de antenas en función de estos requerimientos.
CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN
34 DE ROUTERS WIFI DE LARGA DISTANCIA
En la banda de 2.4 GHz algunos de los modelos utilizados son: la antena de grilla HG2424G de 24
dBi (Figura 2.15(b)), la antena de panel HG2418P de 14dBi, y las sectoriales HG2414SP-120 y la HG
2414SP-090 (Figura 2.15(d)) de 14 dBi de ganancia cada una y de 120 y 90o de haz, respectivamente.
En la de 5.8 GHz se han utilizado la antena de plato HG5829D de 29 dBi dada su gran ganancia y la
posibilidad de instalarle un radome, que la dota de mayor aerodinamicidad, fundamental en lugares
muy ventosos (Figura 2.15(a)), la antena de grilla HG5827G de 27 dBi y la de panel HG5819P de 19
dBi (Figura 2.15(c)).
NOTA: Las antenas de grilla tanto de 2.4 GHz como de 5.8 GHz tienen unas abrazaderas un tanto
débiles, por lo que en zonas de mucho viento se recomienda emplear un método de sujeción adicional.
2.3.1. Características
Las características más resaltantes de Linux Voyage son:
Su construcción está basada en la distribución Debian Sarge r3.1/Etch r4.0/Lenny r5.0 tomando
solo las aplicaciones necesarias para requerir un espacio de 128MB.
2.4 Driver MadWifi 35
La capacidad del sistema se puede incrementar de acuerdo a las necesidades por medio del
manejo de la aplicación apt
Soporte WiFi
Soporte para diversos drivers de redes inalámbricas como madwifi, hostap, prism54, etc.
madwifi-project.org/wiki/About/OpenHAL
Ar5k es parte del driver Ath de OpenBSD para tarjetas inalámbricas Atheros. Ar5k es el componente
del driver que se comunica directamente con el hardware.
2.4.3. Características
Madwifi Posee las siguientes características:
-Dispositivos compatibles:
Madwifi soporta dispositivos PCI, MiniPCI y Cardbus. Por el momento no hay soporte para USB.
-Modos de operación:
Sta (Station). También conocido como cliente o managed. Es el modo que se cargará por defecto
si es que no se elige algún modo de trabajo. El dispositivo actuará como una estación cliente de
una red inalámbrica.
Ap (Access point). También conocido como master. El dispositivo trabaja como un punto de
acceso común para que otros clientes se cuelguen a su red de trabajo.
Monitor.
WDS (wireless distribution system). Permite la comunicación inalámbrica directa entre APs.
-Encriptación:
WPA (WiFi Protected Access). Soportado en modos: sta (mediante: wpa_supplicant) y ap (me-
diante: hostapd)
2.4 Driver MadWifi 37
WPA2/IEEE 802.11i (WiFi Protected Access 2). Soportado en modos: sta (mediante: wpa_supplicant)
y ap (mediante: hostapd)
-Multi-BSSID:
Una de las características más interesantes de Madwifi es la creación de interfaces virtuales. Esto
significa que una sola interfaz física puede funcionar de distintos modos (sta, ap, repetidor, etc). Sin
embargo tiene limitaciones (como el uso de un canal común).
Colección de características propias de los chipset Atheros. Las cuáles fueron desarrolladas para
incrementar el ancho de banda y distancias de alcance de los dispositivos Atheros. Se pueden citar las
siguientes:
Bursting: Característica compatible con cualquier AP. Permite enviar varias tramas en simultá-
neo, en vez de enviarlas en cola. De este modo se toma menos tiempo para enviar gran cantidad
de datos incrementando el ancho de banda.
Fast Frame: Característica no soportada por todos los AP. Permite enviar mayor información en
cada trama, reduciendo tiempos de transmisión y aumentando el ancho de banda.
Compression: Los datos son comprimidos en cada trama que se envía, esto se realiza medi-
ante el algoritmo de Lempel Ziv. Una vez que la característica es habilitada, la compresión y
descompresión se ejecuta dentro del chipset Atheros.
Turbo Mode: Característica no soportada por todos los AP. Permite que se transmita por 2
canales, ofreciéndose así un doble ancho de banda. Es beneficioso solo si todas las estaciones
de la red lo soportan. Se distinguen 2 modos Turbo.
Dinamic: La red decide en que momento se puede usar y en que momento no se puede el modo
turbo, según se detecte el tráfico de los canales adyacentes.
Adaptive Radio (AR): La característica de elegir cuando se puede usar y cuando no el modo
turbo mediante el sondeo de la banda de radio es llamada comúnmente AR.
Extended Range (XR): Característica propia de los clientes provee alcances más largos por
incremento de la sensibilidad del receptor de hasta -105dBm. Adicionalmente se agregan nuevas
tasas de transmisión: 3, 2, 1, 0.5, y 0.25MBits/s.
-4-address header:
Soporte para juntar segmentos ethernet e inalámbricos en una sola dirección o manejar 4 direc-
ciones independientes.
CAPÍTULO 2. HARDWARE Y SOFTWARE APROPIADOS PARA LA CONSTRUCCIÓN
38 DE ROUTERS WIFI DE LARGA DISTANCIA
- Roaming:
- Background scanning:
2.4.4. Requerimientos
-Hardware:
Tarjetas inalámbricas PCI, miniPCI o Cardbus con chipset Atheros. La lista de equipos compat-
ibles es amplia, para revisar una lista completa visitar http://madwifi-project.org/wiki/
Compatibility
-Arquitectura:
Las arquitecturas soportadas por Madwifi son las siguientes: Alpha, ARM9, ARMv4, i386, MIPS,
MIPS ISA32, PowerPC (32 bits), SH4, Sparc (32 bits), Sparc64, X86_64 y XScale.
-Software:
2.5. Quagga
Quagga es un conjunto de programas de código abierto, para el control de protocolos de en-
rutamiento para sistemas Unix como NetBSD, FreeBSD, Solaris y Linux. Quagga esta bajo la licen-
cia de GNU/General Public License (GPL). Actualmente proporciona versiones de código libre de
los protocolos OSPF, RIP y BGP.
2.5 Quagga 39
La arquitectura de quagga consiste de un demonio (programa que siempre esta corriendo) central
llamado Zebra. Zebra es el corazón de Quagga y funciona como el administrador del enrutamiento IP;
sirve como un capa de abstracción para el kernel y proporciona un API para los clientes Quagga (Zerv.
clients). Estos clientes implementan los protocolos de enrutamiento y envían las actualizaciones del
enrutamiento al demonio Zebra. Los Zerv. clients son:
G.711: Estándar para la compresión de audio para telefonía. Representa las señales de audio
mediante muestras comprimidas en una señal digital con tasa de muestreo de 8000 muestras
por segundo con un flujo de datos de 64 Kbps. Existen dos tipos:
∙ 𝜇-law: Usado sobre todo en Norte América y Japón. Codifica cada 14 muestras
en palabras de 8 bits.
∙ a-law: Usado en Europa y en el resto del mundo. Codifica cada 13 muestras en
palabras de 8 bits.
41
42 CAPÍTULO 3. SOFTWARE PBX ASTERISK
G.726: Estándar basado en ADPCM (Adaptative Differential Pulse Code Modulation). Permite
trabajar con velocidades de 16, 24, 32 y 40 Kbps. Este codec proporciona una disminución
considerable del ancho de banda sin aumentar en gran medida la carga computacional.
G.729: Se usa sobre todo en aplicaciones de Voz sobre IP por los bajos requerimientos en ancho
de banda. Opera con tasas de 8 Kbps pero existen extensiones para tasas de 6.4 y 11.8 Kbps
para peor o mejor calidad de voz respectivamente.
GSM (Global System Mobile): Estándar que opera a 13 Kbps con una carga de CPU aceptable.
Inicialmente fue desarrollado para la telefonía móvil.
iLBC (Internet Low Bit rate Codec): Algoritmo complejo desarrollado por Global IP Sound
(GIPS) que ofrece una buena relación ancho de banda/calidad de voz a cambio de una mayor
carga computacional. Opera a 13.3 Kbps y 15.2 Kbps.
La supresión de silencios, otorga más eficiencia a la hora de realizar una transmisión de voz, ya
que se aprovecha mejor el ancho de banda al transmitir menos información.
3.2. Asterisk
Asterisk es una aplicación de software libre (bajo licencia GPL) que proporciona funcionalidades
de una central telefónica (PBX). Como cualquier PBX, se puede conectar un número determinado
de teléfonos para hacer llamadas entre sí e incluso conectar a proveedores de VoIP y de telefonía
convencional tanto analógica como digital. Originalmente desarrollado para el sistema operativo
GNU/Linux, Asterisk actualmente también se distribuye en versiones para los sistemas operativos
BSD, MacOSX, Solaris y Microsoft Windows, aunque la plataforma nativa (GNU/Linux) es la mejor
soportada de todas.
Asterisk incluye muchas características como buzón de voz, conferencias, IVR, distribución au-
tomática de llamadas, y otras muchas más tal como PBX comerciales. Los usuarios pueden crear
nuevas funcionalidades por medio de lenguaje script de Asterisk o añadiendo módulos escritos en
cualquier lenguaje de programación soportado por Linux.
Las versiones estables de Asterisk están compuestas por los módulos siguientes:
Cada uno de estos módulos cuenta con una versión estable y una versión de desarrollo. Hasta
ahora; las versiones desarrolladas son la 1.6 y la 1.4. Las versiones 1.2 y 1.0 se consideran paralizadas
y ya no se continuarán manteniendo. Actualmente la rama 1.4 es la aconsejada para sistemas en
producción.
API de Canales Asterisk: controla el tipo de conexión por el cual el cliente está llegando (bien
sea una conexión SIP, H323, BRI, etc).
API de Aplicaciones Asterisk: permite a varios módulos de tareas, cumplir varias funciones
(conferencias, buzones de voz, etc).
44 CAPÍTULO 3. SOFTWARE PBX ASTERISK
API de Traducción de Codecs: carga módulos, codecs, para apoyar varios tipos de audio, codi-
ficando y decodificando formatos tales como G711, G729, GSM11, etc.
Usando estas API Asterisk alcanza una completa abstracción entre sus funciones básicas y las
diferentes tecnologías y aplicaciones relacionadas.
Asterisk permite implementar los mismos servicios que una central clásica, entre ellas:
Asterisk tiene soporte para casi todos los codecs de audio como: G.711, G.723.1, G.726, G.729,
GSM, ilbc14, linear, lpc-1015, speex. Quizá lo más interesante de Asterisk es que soporta muchos
protocolos VoIP como pueden ser SIP, H.323, IAX y MGCP.
Asterisk permite integrar una red de telefonía IP con redes telefónicas tradicionales por medio de
interfaces analógicos y digitales. Para la conexión con líneas analógicas se hace a través de dispos-
itivos FXO y FXS. Para la conexión con líneas digitales RDSI se logra por medio de interfaces del
tipo BRI (2 canales de voz de + 1 de señalización) y PRI (30 canales de voz + 1 de señalización).
Las interfaces de telefonía analógica se encuentran en múltiples dispositivos de redes (routers,
centrales de telefonía IP, etc.) que operan como acceso hacia los servicios de voz convencionales
como la telefonía pública. Para la conexión con estas líneas analógicas se hace por medio de interfaces
FXS y FXO.
FXS Foreign eXchange Station: También denominada interfaz de abonado. Es el que envía
la línea analógica hacia el abonado. Se trata de interfaces que permiten conectar dispositivos
terminales, como un teléfono analógico convencional a un router o central de telefonía IP. Una
interfaz FXS proporciona alimentación eléctrica, señalización de llamada y tono al dispositivo
terminal.
FXO Foreign eXchange Office: Es un puerto que recibe la línea analógica. Es la interfaz que
permite conectar un dispositivo terminal a un servicio de telefonía como el servicio de telefonía
pública (PSTN) o una PBX. Envía al sistema telefónico una señal de colgado o descolgado.
FXS y FXO son siempre pares que se corresponden mutuamente; una interfaz FXS se conecta
en el otro extremo de la línea a una interfaz FXO. Cuando se instala una central telefónica (PBX),
la línea telefónica se conecta al puerto FXO de la PBX, la cual provee múltiples puertos FXS para
conectar los teléfonos o aparatos de fax. Un adaptador telefónico o ATA actúa como un FXS.
En las redes TCP/IP, las conversaciones (flujo audio/video) que usan señalización del tipo SIP
hacen uso del RTP. El protocolo RTP es el encargado de llevar las conversaciones (flujo audio/video)
de un lado a otro. De la misma forma que en una conversación existen dos flujos de voz, en una con-
versación en una red TCP/IP se tiene dos flujos de paquetes RTP.
Figura 3.4: La señalización SIP y las conversaciones de voz (RTP) viajan por caminos distintos.
Los Network Address Translators (NATs) son los problemas del RTP. El efecto de un NAT en 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 ningún flujo de audio originado detrás de los NAT llegará a su destino final. Para este
problema ya existen soluciones implementadas en Asterisk.
48 CAPÍTULO 3. SOFTWARE PBX ASTERISK
La configuración más simple para establecer una sesión SIP es utilizando sólo dos agentes de
usuario (UA) conectados uno a otro. Los elementos básicos de un sistema son los UA y los servidores;
estos últimos pueden ser de diferentes tipos: Proxy, de Registro y de Redirección.
El protocolo SIP permite el establecimiento de sesiones multimedia entre dos o más usuarios. Para
hacerlo se vale del intercambio de mensajes entre las partes que quieren comunicarse.
User agents (UA): Los Agentes de usuario son los puntos extremos del protocolo SIP, es decir son
los que emiten y procesan los mensajes del protocolo SIP. Un videoteléfono, un teléfono, un cliente
de software y cualquier otro dispositivo similar es un agente de usuario para SIP. El protocolo SIP no
se ocupa de la interfaz de estos dispositivos con el usuario final, sólo se interesa por los mensajes que
estos generan y cómo se comportan al recibir determinados mensajes.
Los agentes de usuario se comportan como clientes (UAC: User Agent Clients) y como servidores
(UAS: User Agent Servers). Un agente de usuario se comporta en UAC cuando realizan una petición
y son UAS cuando la reciben y responden a la misma. Por esto los agentes de usuario deben imple-
mentar un UAC y un UAS.
Servidores de Registro: El protocolo SIP permite establecer la ubicación física de un usuario de-
terminado, esto es en qué punto de la red está conectado. Para ello se vale del mecanismo de registro.
Cada usuario tiene una dirección lógica que es invariable respecto de la ubicación física del usuario.
Una dirección lógica del protocolo SIP es de la forma usuario@dominio. La dirección física es de-
pendiente del lugar en donde el usuario está conectado (su dirección IP). Cuando un usuario inicializa
su terminal (p. e. conectando su teléfono o abriendo su software de telefonía SIP) el agente de usuario
SIP que reside en dicho terminal envía una petición con el método REGISTER a un Servidor de Reg-
istro, informando a qué dirección física debe asociarse la dirección lógica del usuario. El Servidor de
Registro realiza entonces dicha asociación; esta asociación tiene un período de vigencia; termina si
no es renovada; también mediante un desregistro.
Un Servidor de Registro es comúnmente sólo una entidad lógica y la mayoría de las veces se localiza
junto con el Servidor Proxy.
normalmente atendido por un servidor o más de uno. Este servidor recibe las peticiones de sus usuar-
ios. Este servidor será el encargado de determinar la dirección física del usuario llamado. Un servidor
que recibe las peticiones destinadas a un dominio específico es denominado servidor entrante (In-
bound Server). Es habitual también, que exista un servidor que reciba las peticiones originadas por
los usuarios de un dominio hacia otros dominios. Este recibe el nombre de Servidor Saliente (Out-
bound Server).
Mensajes SIP: Existen dos tipos básicos de mensajes SIP, peticiones y respuestas. Las solicitudes
y las respuestas emplean el formato de mensaje genérico, que consiste en una línea inicial (Star – Line
o Request – Line) seguida de un o más campos de cabecera (Message Header), una línea vacía que
indica el final de las cabeceras, y por último, el cuerpo del mensaje (Message Body) que es opcional.
La línea inicial contiene la versión del protocolo; el método y direcciones involucradas en la sesión
para las peticiones; mientras que el estado de la sesión para el caso de las respuestas. El encabezado
contiene información relacionado con la llamada en forma de texto; por ejemplo el origen y destino
de la petición, el identificador de la llamada, etc. El cuerpo del mensaje o carga útil (payload) lleva la
información (comúnmente SDP o ISUP en caso de una troncal hacia la PSTN).
Las peticiones (Request Line) se emplean para iniciar alguna acción o para información; incluyen
el nombre del método al que invocan, el identificador del destinatario, el protocolo SIP que se esta
utilizando; para esto utiliza métodos y son:
Invite: Utilizado para invitar un usuario para participar en una sesión o para modificar parámet-
ros.
Ack: Confirma el establecimiento de una sesión.
Option: Solicita información sobre las capacidades de un servidor.
Bye: Indica la finalización de una sesión.
Cancel: Cancela una petición pendiente.
Register: Registra un UA.
Las peticiones no contienen por lo general un cuerpo de mensaje; porque no lo requiere.
Las respuestas (Status Line) se generan como retorno de una petición, devolviendo un código de
estado; la línea llevará el SIP utilizado, código de respuesta y una pequeña descripción de ese código.
Podemos recibir estas respuestas según el rango:
1xx: Mensaje provisional. La petición fue recibida pero se desconoce aun el resultado del proce-
samiento. El emisor detiene el envío de retransmisión después de recibir una petición de este
tipo. Un ejemplo es el código 180=ringing o el 100=trying.
2xx: Éxito. Son respuestas finales positivas. La petición fue recibida y procesada exitosamente.
Por ejemplo 200=OK significa que el extremo llamado acepto la invitación a la sesión.
3xx: Redirección: Son usados para redireccionar las llamadas. Dan información acerca de la
nueva localización de un usuario o sobre un Proxy alterno que puede resolver satisfactoriamente
alguna petición . El emisor del mensaje de petición debe reenviar su petición a otro para que su
petición sea atendida.
50 CAPÍTULO 3. SOFTWARE PBX ASTERISK
4xx: Fallo de método. Son respuestas finales negativas. Falla del lado del emisor, mala sintaxis
del mensaje, etc.
5xx: Fallos de servidor. Falla del lado del servidor. Aparentemente la petición es válida pero el
Proxy es incapaz de procesarla. El emisor debe reintentar después.
Transacciones SIP: Una transacción SIP es una secuencia de mensajes entre dos elementos de
Red. Una transacción corresponde a una petición y todas las respuestas a esa petición. Esto quiere
decir que una transacción incluirá cero o más respuestas provisionales y una o más respuestas finales;
en el caso de un mensaje INVITE puede ser dividido por un Proxy y por lo tanto tendrá múltiples
respuestas finales. Las entidades SIP que almacenan el estado de las transacciones son denominadas
Stateful; lo que hace por medio del registro de cada transacción.
Diálogos SIP: Un dialogo SIP es una conversación peer-to-peer entre dos UA. Los diálogos
son identificados usando los campos Call-ID, From y To. Los mensajes con estos campos iguales
pertenecen al mismo dialogo. El campo CSEQ es utilizado para ordenar los mensajes en un dialo-
go. De hecho el CSEQ representa el número de transacción. De forma simple se puede decir que un
diálogo es una secuencia de transacción.
Invitación a una sesión: Una invitación inicia con el mensaje INVITE dirigido comúnmente al
Proxy. Este responde con TRYING (100) para detener las retransmisiones y reenvía las peticiones
hacia el usuario llamado. Todas las respuestas provisionales generadas por el usuario llamado son
regresados al usuario origen. Por ejemplo RINGING (180) que es un mensaje que se envía cuando el
usuario es contactado y comienza a timbrar. Una respuesta 200 (OK) es generada en cuanto el usuario
llamado descuelga el auricular.
Terminación de sesión: Una sesión es finalizada cuando uno de los usuarios envía el mensaje
BYE al otro extremo. El otro usuario confirma el final de la conversación enviando por respuesta un
mensaje 200 (OK). La transacción para finalizar la sesión se realizará de un extremo a otro sin pasar
por el Proxy a menos que en el mismo se haya establecido un proceso de Registro de ruta.
Existen situaciones en las que el Proxy requiere estar en la ruta de todos los mensajes con fines de
control del tráfico o por ejemplo, cuando existe un NAT. El Proxy o los Proxy logran esto por medio
de la inserción del campo RECORD ROUTE en los encabezados de los mensajes SIP.
así como información de los flujos audiovisuales referentes a la misma. Este permite además asociar
más de un flujo audiovisual a una misma sesión; por ejemplo en una misma sesión puede existir un
flujo para audio y uno más para video o transferencia de documentos.
SDP es exclusivamente para propósito de descripción y negociación de los parámetros de sesión.
No transporta el flujo audiovisual en sí. Fue pensado para trabajar en conjunto con otros protocolos
como SIP, Megaco o HTTP. El transporte de información acerca de los flujos audiovisuales permite
a los destinatarios participar en la sesión si ellos soportan dichos flujo. Además SDP permite la ne-
gociación de los parámetros de flujo tales como la tasa de muestreo de la señal, el tamaño de los
paquetes, etc.
Verificar la entrega de los paquetes en orden (marca de tiempo) y si resulta necesario recordar
los bloques fuera de orden.
RTP utiliza UDP para el transporte de la información y aprovecha la suma de verificación del
mismo (Checksum) para verificar integridad de los datos. RTP no posee ningún método para garanti-
zar la calidad de servicio ni la entrega ordenada de paquetes. RTCP también utiliza UDP para enviar
paquetes de control hacia todos los participantes de una sesión. Los servicios que provee RTCP son
los siguientes:
Dar seguimiento a la calidad en la distribución de los datos, así como mantener el control de los
codecs activos.
Anunciar el número de participantes por sesión con el fin de ajustar la tasa de transmisión de
datos.
54 CAPÍTULO 3. SOFTWARE PBX ASTERISK
Enrutamiento Dinámico
4
El router es un componente importante en una red de datos; se encarga de conectar múltiples
redes entre si, por tanto, es responsable de entregar paquetes entre estas distintas redes. Los routers
son computadoras que poseen CPU, memoria y un sistema operativo; y posee varias interfaces, cada
una perteneciente a una red IP distinta.
La principal tarea del router es determinar la mejor ruta hacia una red para enviar los paquetes;
para esto utiliza protocolos de enrutamiento estático y dinámico para construir su tabla de enrutamien-
to.
55
56 CAPÍTULO 4. ENRUTAMIENTO DINÁMICO
Cuando un router recibe un paquete, usa su tabla de enrutamiento para determinar la mejor ruta
para poder enviar el paquete; en este caso puede ocurrir una de tres situaciones.
Redes remotas: Si la dirección IP de destino del paquete pertenece a una red remota, entonces
el paquete se enviará a otro router.
Sin determinación de ruta: si la dirección IP de destino del paquete no pertenece ya sea a una
red conectada o remota, y si además el router no posee una ruta por defecto, entonces el paquete
será descartado. El router enviará un mensaje ICMP de destino inalcanzable a la dirección IP
de origen del paquete.
Antes de configurar cualquier enrutamiento estático o dinámico en un router, éste solo conoce a las
redes conectadas directamente; éstas son las únicas redes que se muestran en la tabla de enrutamiento
hasta que se configure el enrutamiento estático o dinámico. Las rutas estáticas y dinámicas no pueden
existir en la tabla de enrutamiento sin las redes conectadas directamente.
El router desencapsula el paquete de capa 3 de la trama de capa 2, examina la dirección IP de
destino del paquete IP para encontrar la mejor ruta en la tabla de enrutamiento y encapsula el paquete
de capa 3 en una nueva trama de capa 2 y envía la trama desde la interfaz de salida; a esta función
se le conoce como conmutación. Cada router toma su decisión en forma independiente, según la
información de su propia tabla de enrutamiento. En este proceso es posible que el router haya recibido
el paquete encapsulado en un tipo de trama de enlace de datos, como una trama Ethernet, y ahora al
momento de enviar el paquete, el router lo encapsulará en otro tipo de trama de enlace de datos de
tecnología LAN como Ethernet o WAN como T1 que usa PPP, Frame Relay o ATM.
El hecho de que un router tenga cierta información en su tabla de enrutamiento no significa que
los otros routers tengan la misma información. La información de enrutamiento sobre una ruta desde
una red a otra no suministra información de enrutamiento sobre la ruta inversa o de regreso. Dado
que los routers no necesariamente tienen la misma información en sus tablas de enrutamiento, los
paquetes pueden recorrer la red en un sentido, utilizando una ruta, y regresar por otra ruta. Esto se
denomina enrutamiento asimétrico. El enrutamiento asimétrico es más común en Internet, que usa el
protocolo de enrutamiento BGP, que en la mayoría de las redes internas.
Si una red se conecta a Internet solamente a través de un único ISP (Internet Service Provider).
Evitar repentinos picos de tráfico en la red después del cambio de una ruta.
Converger rápidamente en una topología aceptada por todos los routers después de un cambio
de rutas.
4.2.2.4. Convergencia
La convergencia se da cuando todas las tablas de enrutamiento de una red están en un estado de
uniformidad. El tiempo de convergencia es el tiempo que tardan los routers en compartir información,
calcular las mejores rutas y actualizar su tabla de enrutamiento. Por lo general, RIP e IGRP tienen
convergencia lenta, mientras que EIGRP y OSPF tienen una convergencia más rápida.
Cada protocolo tiene una forma distinta de medir la calidad de un camino hacia una red remota, y
unos son más precisos que otros porque evalúa mayor cantidad de variables al momento de elegir.
IGRP e EIGRP: evalúa ancho de banda, retardo, confiabilidad y carga, se elige como mejor ruta
la que se evalué con el resultado más bajo.
IS-IS y OSPF: Evalúa el ancho de banda y obtiene el costo, la mejor ruta es la del costo más
bajo.
Si un router tiene dos caminos hacia la misma red, sólo se pondrá en la tabla de enrutamiento a
aquella que tenga mejor métrica; la única excepción es cuando los dos caminos tienen exactamente
la misma métrica; en ese caso se agregarán ambos caminos a la tabla de enrutamiento; este compor-
tamiento se denomina frecuentemente ECMP (Equal Cost MultiPath). La cantidad de rutas de misma
métrica que un router permite agregar a la tabla dependerá de la configuración del equipo.
Las distancias administrativas son una forma de dar prioridad cuando existe información sobre
una red proveniente de más de un origen de enrutamiento (protocolo); para seleccionar la mejor ruta.
A cada origen se le asigna un orden de preferencia, incluidas rutas estáticas y redes directamente
conectadas. La siguiente tabla muestra las distancias administrativas.
El protocolo de origen de la ruta que tenga menor distancia administrativa va a ser el que termine
llenando la tabla de enrutamiento. Cuando en una red todos los routers ejecutan varios protocolos
de enrutamiento dinámico a la vez; por ejemplo RIP y EIGRP; todas las métricas de RIP serían
significativamente menores a las de EIGRP, por lo que equivocadamente se podría pensar que el
router va a optar por los caminos RIP dada la métrica más baja. Otro ejemplo; si se tiene que RIP y
4.3 OSPF, Open Shortest Path First 61
Directamente Conectada 0
Estática 1
BGP Externa 20
EIGRP Interna 90
IGRP 100
OSPF 110
IS-IS 115
RIP 120
EGP 140
ODR 160
Desconocido 255
OSPF conocen como llegar a la red 200.0.0.0/24; dado que OSPF tiene menor distancia administrativa
(110 < 120), OSPF va a ser el que escriba la ruta en la tabla de enrutamiento.
Si se configura una ruta estática con interfaz de salida, esta aparecerá como directamente conecta-
da en la tabla de enrutamiento, y por defecto su distancia administrativa será 1. Las redes 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.
Realiza balance de carga si existe más de una ruta con la misma distancia hacia un destino dado;
dependerá de la aplicación y su configuración.
Puede operar con seguridad usando MD5 para autentificar a sus puntos antes de realizar nuevas
rutas y antes de aceptar avisos de enlace-estado.
62 CAPÍTULO 4. ENRUTAMIENTO DINÁMICO
OSPF está diseñado para trabajar tanto en redes punto a punto como de múltiples accesos, como
de difusión (Ethernet o Token Ring) o de no-difusión (X.25).
En OSPF no existe un intercambio de rutas directamente, lo que los routers transmiten 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-
ción de cada una de las redes conectadas directamente a ese router. Con esta información el router
construye su tabla de enrutamiento con la mejor ruta.
Una vez que un router recibe los LSA de sus vecinos, estos son almacenados en una base de datos
local llamada Link State Database (LSDB). Los routers llegan a estar sincronizados cuando todos los
routers dentro de la misma área cuentan con exactamente la misma base de datos de estado enlace;
en este punto todos los routers conocen sobre todos los destinos posibles en esa área; pero los LSA
hasta este punto no son consideradas como rutas; para calcular las rutas hacia cada destino el router
usa un algoritmo conocido como SPF (Shortest Path First) también se conocido con el nombre de su
creador, Dijkstra, para calcular la ruta más corta a cada destino.
OSPF utiliza un algoritmo de enlace-estado, a fin de construir y calcular el camino más corto para
todos los destinos. El algoritmo de por sí es bastante complicado. A continuación una descripción
simple de las distintas etapas del algoritmo:
Todos los routers intercambiarán los anuncios d estado enlace por medio de inundaciones
( ooding). Cada router que recibe una actualización del estado enlace debe guardar una copia
en su base de datos de estado enlace y propagar la actualización a otros routers.
Después de que la base de datos de cada router se ha completado; el router calculará una ruta de
acceso más corta para todos los destinos. El router utiliza el algoritmo de Dijkstra para calcular
el camino más corto. Los puntos de destino, el costo asociado y el próximo salto para llegar a
esos destinos formarán la tabla de enrutamiento IP.
En caso de que no se produzcan cambios en la red OSPF, como el cambio del costo de un enlace
o una red añadida o suprimida, OSPF debe estar estático. Las modificaciones que se produzcan
se comunicarán a través de paquetes estado enlace; y el algoritmo de Dijkstra vuelve a calcular
para encontrar el camino más corto.
Dos áreas sólo pueden hablar entre sí a través del backbone. Las rutas entre diferentes áreas
circulan siempre por el backbone, por lo tanto todas las áreas deben conectar con el backbone. Si no
es posible hacer una conexión directa con el backbone, se puede hacer un enlace virtual entre redes.
Las áreas ponen un límite en el anuncio de las actualizaciones del estado enlace. Las inundaciones
y el cálculo del algoritmo de Dijkstra, en un router se limitan a cambios dentro de la zona. Todos los
routers dentro de un espacio tienen exactamente la misma base de datos del estado enlace.
Routers periféricos de área: Son los que están en mas de un área, y por tanto las interconectan
(una de las áreas siempre es necesariamente el backbone).
Routers periféricos de AS: Los que intercambian tráfico con routers de otros ASes. Estos routers
pueden estar en el backbone o en cualquier otra área.
Standard Area: Este tipo de área se conecta a la de backbone. Todos los routers del área conocen
los demás routers del área y tiene la misma base de datos topológica. Sin embargo cada router tiene
su propia tabla de enrutamiento.
Backbone Area: El backbone, también denominado área cero, forma el núcleo de una red OSPF.
Es la única área que debe estar presente en cualquier red OSPF, y mantiene conexión, física o lógica,
con todas las demás áreas en que esté dividida la red. La conexión entre un área y el backbone se
realiza mediante los ABR (Area Border Router). OSPF espera que todas las áreas inyecten la infor-
mación de encaminamiento en el backbone y este inyectará aquella información en otras áreas.
Stub Area: Un área Stub es aquella que no recibe rutas externas (LSA tipo 5). Por lo tanto, los
rouerts necesitan normalmente apoyarse en las rutas predeterminadas para poder enviar tráfico a rutas
fuera del segmento Stub.
Área Totally Stub: Es idéntica al Stub Area (no acepta LSA tipo 5); pero además no acepta rutas
hacia redes de otras áreas y no conoce las rutas hacia routers ASBR (LSA tipos 3 y 4). La única forma
de salir del área es mediante una ruta por defecto. Este tipo de área es muy útil para sitios remotos
con pocas redes y conectividad limitada con el resto de la empresa. Esta es una solución propietaria
de Cisco Systems.
Not-so-Stubby Area: También conocidas como NSSA, constituyen un tipo de área Stub. No 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 múltiples áreas, y conectan estas áreas con el área backbone son lla-
mados routers de borde de area (ABR, Area Border Router). Los ABR deben mantener la información
que describe el backbone y las de las otras áreas adjuntas. Un router que tiene todos sus interfaces
64 CAPÍTULO 4. ENRUTAMIENTO DINÁMICO
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
dentro de una misma área es llamado un router interno (IR, Internal Router). Routers que actúan co-
mo gateway entre OSPF y otros protocolo de enrutamiento (IGRP,EIGRP, IS-IS, RIP, BGP, Static) u
otros casos de enrutamiento OSPF son llamados routers de frontera de un sistema autónomo (ASBR,
Autonomous System Boundary Router). Un router puede ser un ABR o un ASBR; un router puede ser
un router interno o un router de borde del área y al mismo tiempo ser un ASBR.
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.
La ruta más corta es calculada por el algoritmo Dijkstra. El algoritmo coloca cada router en la raíz
de un árbol y calcula la ruta más corta para cada destino basado sobre el costo acumulativo requerido
para llegar a ese destino. Cada router tiene su propia visión de la topología, aunque todos los routers
construirán un árbol de camino más corto usando la misma base de datos de enlace estado. Abajo se
muestra la construcción de la ruta más corta de cada destino del router RTA.
Los routers de una red basada en OSPF se conectan a ella a través de una o varias interfaces con
las que se conectan a otros routers de la red. El tipo de enlace define la configuración que asume la
interfaz correspondiente. OSPF soporta redes broadcast, redes No broadcast y redes punto a punto. El
tipo de red en la que esté trabajando OSPF determinará el funcionamiento del protocolo, y este a su
vez puede ser optimizado por el administrador de la red.
4.4 Funcionamiento de OSPF 65
En este punto por medio del protocolo Hello también se elegirá DR (Designated Router) y BRD
(Backup Designated Router) para la red, si es necesario (en redes broadcast). El router intentará
formar adyacencias (adjacencies) con algunos de sus nuevos vecinos recién descubiertos en base a
estos routers. Una adyacencia es una relación formada entre dos routers vecinos determinados con el
fin de intercambiar información de enrutamiento. No todos los pares de vecinos son adyacencias. Las
bases de datos de estado enlace se sincronizan entre pares de routers adyacentes. Cuando hay un router
DR es este el que decide que routers son adyacentes. Las adyacencias controlan la distribución de la
información de enrutamiento ya que las actualizaciones sólo se envían entre los routers adyacentes.
Las adyacencias de los routers se reflejan en los contenidos de sus LSA; esto permite al protocolo
detectar routers caídos de forma oportuna.
Los LSA inundan el área; asegurándose que todos los routers en un área tienen la misma base
de datos de estado enlace. Esta base de datos consiste en una colección de LSA originados por cada
router perteneciente al área. De esta base de datos cada router calcula el árbol de la primera ruta más
corta (SPF, Shortest Path First) consigo mismo como raíz. Cada vez que se recibe un LSA se calcula
el árbol SPF mediante el algoritmo de Dijkstra y se genera una tabla de enrutamiento.
Type: Identifica el tipo del paquete del OSPF. Los routers OSPF cuentan con 5 tipos de paquetes
para identificar a sus vecinos y para actualizar la información de enrutamiento.
Packet length: Especifica la longitud del paquete, incluyendo el encabezado OSPF, en bytes.
Area ID: Identifica el área a la que pertenece el paquete. Todos los paquetes OSPF están asociados a
una sola área.
Checksum: Verifica el contenido total del paquete por si ha sufrido algún daño durante su tránsito.
Rutas que son generadas dentro de un área son llamados rutas Intra-Area; rutas que se originan de
otras áreas son llamados rutas Inter-Area; rutas que se originan de otros protocolos de enrutamiento
y que son inyectados dentro del AS vía redistribución son llamados rutas External. Múltiples rutas al
mismo destino son preferidas en el orden siguiente: Intra-Area, Inter-Area, External type 1, External
type 2.
4.4 Funcionamiento de OSPF 69
Estado desactivado (Down): En el estado desactivado, el proceso OSPF del router no ha inter-
cambiado información con ningún vecino. OSPF se encuentra a la espera de pasar al siguiente
estado (etapa de inicialización).
Estado de inicialización (Init): Los routers envían paquetes de tipo 1 (Hello) en intervalos
regulares (por defecto 10 segundos en Quagga y en Cisco) para establecer relación con sus
routers vecinos, cuando una interfaz recibe su primer paquete Hello entonces decimos que el
router ha entrado en estado Init y está preparado para entrar en el siguiente estado.
Estado bidireccional (Two-Way): Utilizando paquetes Hello, cada router OSPF intenta es-
tablecer una comunicación bidireccional con cada router vecino que está ubicado en la misma
red IP. Un router entra en estado two-way en el momento que se ve en una de las actualizaciones
de uno de sus vecinos. El estado two-way es la relación más básica que pueden tener los routers
OSPF, pero la información de enrutamiento no se intercambia en este estado. Para aprender
sobre enlaces de otros routers el router tiene que tener al menos una adyacencia completa.
Estado cargando (Loading): Después de que todas las bases de datos han sido descritas a cada
router, se tiene que solicitar una información que es más completa utilizando paquetes de tipo
3. Cuando un router recibe un paquete de tipo 3, este responde con una actualización mediante
un paquete de tipo 4. Los paquetes de tipo 4 describen la información de estado del enlace que
es el corazón de los protocolos de enrutamiento de estado del enlace. Los paquetes de tipo 4
son respondidos con paquetes de tipo 5.
Estado de adyacencia completa (Full adjacency): Cuando termina el estado Loading, los
routers están en una adyacencia completa. Cada router mantiene una lista de sus vecinos adya-
centes, llamada base de datos de adyacencia.
Voyage GTR
5
El Grupo de Telecomunicaciones Rurales de la PUCP ha adaptado Voyage 0.5.2 para la imple-
mentación de enlaces inalámbricos WiFi de larga distancia; a esta Voyage, más sus aplicaciones adap-
tadas se le llama Voyage GTR que puede descargarse desde http://gtr.telecom.pucp.edu.
pe/webfm_send/987
71
72 CAPÍTULO 5. VOYAGE GTR
implementó OSPF; para lo cual se creó plantillas para que la configuración sea ordenada y rápida.
Al instalar quagga se tuvo que crear carpetas adicionales para ser adaptado a la estructura de
Voyage.
Se realizó muchas pruebas en laboratorio y campo para llegar a establecer una plantilla del OSPF
para ser usado como ejemplo de una configuración básica; los archivos involucrados en esta plantilla
son:
voyage: # cat /etc/quagga/ospfd.conf
voyage: # cat /etc/quagga/zebra.conf
5.6. Telefonía IP
Aunque un servidor de Telefonía IP normalmente necesita un equipo de mayor potencia que una
placa ALIX; Asterisk, un servidor de Telefonía IP de código abierto, puede ser instalado en estas
placas para que realice tareas mínimas como comunicación entre usuarios telefónicos y comunicación
entre usuarios administrados por otros Asterisk. La placa ALIX al tener un CPU y RAM reducidos
estará limitado a administrar hasta unas 5 llamadas simultaneas con clientes SIP administrados por
otros servidores Asterisk.
En un punto de la red que pertenezca a una zona rural no es necesario implementar servidores de
gran capacidad por que los usuarios son pocos (menos de 10 clientes SIP).
Voyage no trae Asterisk, se instaló la versión 1.4, la más actual en estos momentos. Para instalarla
se necesitó de sus dependencias y más que nada de los módulos zaptel. Al instalar Asterisk se tuvo
que crear carpetas adicionales para ser adaptado a la estructura de Voyage.
Por defecto, al instalar Asterisk no se crea su archivo logrotate, dado que es necesario se creó
/etc/logrotate.d/asterisk para controlar los log del Asterisk. Además se ha creado el script
/etc/init.d/asterisk que permita la carga programada del Asterisk cada vez que el sistema
inicie.
Se ha establecido una plantilla para ser usada como ejemplo de una configuración básica. La
placa ALIX está limitado en recursos por lo que el Asterisk no puede usar todos sus módulos, se
ha limitado y se ha adaptado a Voyage (/etc/asterisk/modules). Además se ha instalado los
archivos de sonido en español y se ha creado algunos archivos de sonido adicionales para el uso de la
plantilla.
La plantilla desarrollada es para realizar la comunicación entre clientes SIP de un mismo Asterisk
y con clientes SIP administrados por otros Asterisk y además de permitir la comunicación con la red
de telefonía pública; la plantilla contempla a los archivos:
/etc/asterisk/extensions.conf
/etc/asterisk/sip.conf
/etc/asterisk/iax.conf
Se tuvo problemas cuando el equipo que contenía al Asterisk no tenía una ruta por defecto; en
este caso el Asterisk no trabaja correctamente; para esto se encontró una solución que es la de poner
el nombre del equipo en /etc/hosts.
5.7 Configuración vía web 75
1. WiFiAdmin, http://wifiadmin.sourceforge.net
Antiguamente el tamaño de las CF suponía una limitación relativa para elegir un interfaz Web
(por ejemplo se buscaban servidores http ligeros, que ocuparan poco espacio). Hoy, con las CF de
gran capacidad a muy bajo precio, esa limitación prácticamente ha desaparecido, pero sí sigue siendo
importante que la aplicación requiera poco recurso de procesamiento.
Se decidió realizar una interfaz propia, debido a que las opciones evaluadas no poseían opción
para configuración de enrutamiento dinámico o la opción no era apropiada. A la interfaz web de
Voyage GTR se le ha llamado Uya.
Uya se ha liberado con licencia GPLv3 y puede descargarse desde http://code.google.com/
p/uya/
La interfaz web Uya ha sido construida mediante el lenguaje de programación Python, básicamente se usó
2 paquetes python: configmod y configmod-web.
Config-web. Es una máscara web para configmod que usa la aplicación cherrypy como servidor web.
También se puede usar Uya desde linea de comandos. Para crear o actualizar el archivo de configuración prin-
cipal de Uya se ejecuta el siguiente comando:
uya - - read-config
Ahora se puede modificar el archivo /etc/uya/uya.conf con un editor se texto y luego de la edición se
ejecuta la escritura mediante la ejecución del siguiente comando:
uya - - write-config
Scripts de escritura/lectura
La máscara web de Uya (frontend) usa las opciones de lectura/escritura de Uya, pero el modo en que
estas opciones son invocadas es configurable (revisar /etc/uya/scripts). Si se usa una distribución que
normalmente está en modo lectura (read-only) se necesitará ejecutar unos scripts que permitan realizar los cam-
bios pertinentes hacia el modo escritura. Para Voyage se ha desarrollado el script que se muestra a continuación:
76 CAPÍTULO 5. VOYAGE GTR
#!/bin/sh
# /etc/uya/scripts/write.sh
#
# Example write script for Voyage Linux
#
if test $# -ne 2; then
echo “Usage: $(basename $0) CONFIGFILE TEMPLATEFILE”
exit 1
fi
STATE=$(mount ∣ grep “ROOT_FS on / type” ∣ cut -d”(” -f2 ∣ head -c2)
test “$STATE ” = ”ro” && remountrw
uya -write-config -f “$1 ” -t “$2 ”
RETVAL=$?
test “$STATE ” = “ro” && remountro
exit $RETVAL
Archivos modificados
*General:
-Hostname: /etc/hostname y /etc/hosts
-Dns: /etc/resolv.conf
-Ntpdate: /etc/default/ntpdate (variable NTPSERVERS)
*Interfaces: /etc/network/interfaces
Ethernet(ethX interfaces)
Wireless (athX madwifi interfaces). WPA2-PSK crea archivos de autenticación
/etc/wpa_supplicant/wpasupplicant-INTERFACE.conf y
/etc/hostapd/hostapd-INTERFACE.conf files.
Routing(brX interfaces)
*Enrutamiento
Estático: /etc/quagga/daemons (deshabilitados zebra y ospfd).
Dynamic routing: /etc/quagga/daemons (habilitados zebra y ospfd).
Gateway y NAT: /etc/network/statics-routes-nat
Static routes: /etc/network/statics-routes-nat (ROUTESX entries)
Por defecto: /etc/quagga/zebra.conf y /etc/quagga/ospfd.conf
tanto la CF debe ser de al menos 1GB; este tamaño aún sigue siendo muy bajo comparado con las computadoras
estándares.
Voyage es un sistema que se carga en modo lectura; pero un sistema operativo por más que se cargue en
modo lectura necesita crear archivos temporales y reescribir o crear archivos. La partición donde está instalada
Voyage pertenece a la CF y se carga en modo lectura; pero existe una carpeta, la /rw, que está contenida en la
RAM del sistema en un espacio delimitado (originalmente a 8MB); por tanto está en modo escritura; en este
espacio se podrá manipular archivos o carpetas que se encuentren aquí; pero al estar en RAM se perderá la
información después de un reinicio. En /rw están ubicados especialmente los log del sistema y archivos que
necesitan ser modificados por las aplicaciones en cualquier tiempo.
Los log aumentan de tamaño mientras funcione el sistema; en Voyage GTR pueden crecer a razón de
0.5MB por día; este tamaño no es crítico; pero puede existir momentos en que los log crezcan rápidamente y
los 8MB dedicados para /rw puede resultar poco; por tanto se aumenta hasta 32MB. Este aumento de espacio
no quiere decir que se está quitando 32MB a los 128MB de la RAM; sino que mientras se necesite espacio se
puede usar hasta un límite de 32MB. La modificación se hace en /etc/fstab.
La aplicación logrotate que ya viene con Voyage será la encargada de borrar los log antiguos. Para
evitar que los log crezcan muy rápido antes de que actúe logrotate, se desarrolló el script /etc/
cron.hourly/cleanrw como tarea cron, para que cada hora evalúe el espacio en /rw, si es menor a
5MB deberá eliminar el exceso de log.
Toda lo modificado en /rw se pierde después de un reinicio; pero se modificó el script /etc/init.d/
voyage-util que permite guardar todo lo que se modifique en /rw para recuperarlo despues de un reinicio.
Para indicar que carpeta o archivo de /rw se desea conservar se indicará en /etc/voyage.conf.
Los equipos con Linux pueden permanecer encendidos por mucho tiempo y trabajan correctamente; pero
es recomendable realizar reinicios periódicamente. Para esto se crea la tarea cron para programar reinicios
/etc/cron.d/reboot-board.
La placa ALIX no posee batería para conservar la fecha del sistema mientras esté sin energía (apagado); si
se desea tener la fecha sincronizada se deberá usar ntpdate. Se implementó scripts para conservar el tiempo
mientras se reinicia el sistema.
Si el sistema reinicia, la fecha del sistema se conserva pero si se apaga el equipo (se quita la energía) la
fecha actual se pierde y al encender de nuevo, la fecha es antigua, alrededor de 1980. Existe aplicaciones que
van creando archivos o carpetas mientras el sistema arranca pero como las fuentes fueron instaladas posteriores
a 1980, en la creación de estos archivos o carpetas puede existir advertencias o quizás errores. Para evitar esto
se desarrolló los script /etc/init.d/a-before y /etc/init.d/z-after para conservar la fecha
después de un reinicio (sin quitar la energía de la placa) y si el equipo se apaga (se quita la energía del sistema)
se configura la fecha del sistema a una fecha aproximada al momento del grabado de Voyage GTR en la CF.
Se activó el watchdog para que reinicie al equipo si se está consumiendo demasiados recursos en un
momento. Si el promedio de uso del CPU en un minuto es más de 24 %, o en 5 minutos es más de 18 %, o en
15 minutos es más de 12 % el sistema reiniciará; además si el sistema sólo cuenta con 1MB de RAM libre el
sistema reiniciará.
Para tener un buen mantenimiento del sistema es necesario tener un respaldo, para esto se ha creado scripts
que permitan generar un respaldo de la configuración de las distintas aplicaciones; pero sin crear copia de todo
el sistema. El archivo /etc/backup.list es donde se indica las carpetas y archivos a respaldar; el script
/usr/local/sbin/mgbackup se encargará de generar el respaldo en un archivo comprimido.
Como ya se ha mencionado, se ha generado una distribución con varias aplicaciones a la que se llama
Voyage GTR y para poder instalarla se puede usar los script de Voyage original; pero en este caso se desarrolló
un script que permite una instalación más específica y además que permite coger el respaldo obtenido y copiar
a una Voyage GTR y así obtener una copia particular de la configuración de equipos.
Además en Voyage se instaló utilitarios para ser usados por medio de comandos, como: vim, telnet,
mutt, jnettop, lsof, cu, lynk, nmap y killall.
78 CAPÍTULO 5. VOYAGE GTR
6
Con guración e Instalación de Voyage GTR
6.1.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.3. Comando rm
Sirve para borrar archivos o carpetas.
Gtr-v106: # rm -r carpeta
gtr-v106: # rm archivo.txt
79
80 CAPÍTULO 6. CONFIGURACIÓN E INSTALACIÓN DE VOYAGE GTR
Muestra y manipula la tabla de particiones. Con al opción -l se muestra la lista de todas las particiones
encontradas en el equipo.
root@gtrdesktop: # fdisk -l
Muestra un mensaje de diagnóstico que contiene eventos generados en el arranque del sistema y durante la
depuración de aplicaciones.
gtr-v106: # dmesg
...
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: #
voyage: # hostname
voyage
voyage: #
voyage: #
voyage: #
@gtrdesktop: # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
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: #
root@gtrdesktop: # ls
grabar-voyage-gtr voyage-gtr-0.5.tar.gz
Si no se muestra ningún tipo de error o advertencia se puede dar por finalizada la grabación y se puede
extraer la CF y desconectar la lectora/grabadora del puerto USB.
6.3 Acceso inicial por puerto serial o por Ethernet 85
Al energizar la placa ALIX, en el terminal se podrá observar como se carga Voyage Linux hasta que se pida
el ingreso del usuario y la contraseña; por defecto el usuario es root y la contraseña es voyage. El uso del
puerto serial es muy importante porque nos permite ingresar a los equipos sin usar sus interfaces de red y en
caso de fallas para observar los problemas en el equipo
El puerto Ethernet eth0 de la placa esta configurado por defecto con la IP 11.11.11.1/24; por lo cual en un
inicio se puede ingresar por este puerto con ssh. Para ingresar se usará un cable cruzado y una vez que la placa
este encendida y cargado el sistema operativo (alrededor de un minuto) se puede hacer:
# ssh root@11.11.11.1
Después de esto se pedirá el ingreso de la clave, en éste caso inicial será voyage.
voyage: # mount
rootfs on / type rootfs (rw)
none on /sys type sysfs (rw)
none on /proc type proc (rw)
udev on /dev type tmpfs (rw)
/dev/disk/by-label/ROOT_ FS on / type ext2 (ro,noatime)
/dev/disk/by-label/ROOT_ FS on /dev/.static/dev type ext2 (rw)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec)
tmpfs on /rw type tmpfs (rw)
voyage: #
Para editar los archivos y carpetas se debe pasar el sistema al modo escritura; cuando acabe se debe regresar
el sistema al modo escritura.
voyage: # remountrw
...
...editar archivos
...
voyage: # remountro
86 CAPÍTULO 6. CONFIGURACIÓN E INSTALACIÓN DE VOYAGE GTR
Un sistema operativo por más que se cargue en modo lectura necesita crear archivos temporales y rescribir
o crear archivos; la partición donde está instalada Voyage GTR pertenece a la CF y es la se que carga en modo
lectura.
Voyage:/# ls -l
total 101
-rwxr-xr-x 1 root root 9743 Jun 29 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
también crear o eliminar archivos; pero al estar en RAM se perderá la información después de un reinicio.
6.6 Guardar archivos o carpetas de /rw 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 están ubicados físicamente en /rw pero que es sí son
/rw/root, /rw/var/log, /rw/var/spool respectivamente; por tanto /root,
/var/log, /var/spool son enlaces a estas carpetas. Cuando el sistema reinicia se perderá
/rw/root, /rw/var/log, /rw/var/spool y todo lo modificado o creado en estas carpetas; entonces
para crear de nuevo estas carpetas, se tiene a /ro; todo lo que está en /ro se copiará a /rw, por tanto una
vez que el sistema levante los enlaces /root, /var/log, /var/spool estarán apuntando de nuevo a
/rw/root, /rw/var/log, /rw/var/spool; lo creado o modificado en éstas carpetas antes del 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 sólo será la estructura inicial.
voyage:/rw# ls -l
total 0
drwxr-xr-x 2 root root 40 Jun 29 2008 dev
drwxr-xr-x 4 root root 140 Apr 24 16:28 etc
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 4 root root 1024 Apr 24 16:28 etc
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#
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.
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.
NTPSERVERS=”200.16.6.80"
...
Configurar el reinicio del equipo; editar el archivo /etc/cron.d/reboot-board y descomentar la
opción de reinicio aleatorio de entre las 4 y 4:30 horas cada sábado o reinicio a las 4 horas todos los días.
También se puede configurar uno particular.
6.8 Obtención de respaldo de la configuración de las aplicaciones en Voyage GTR 89
En el router GTR se tiene dos particiones críticas que son la /ro y /rw.
90 CAPÍTULO 6. CONFIGURACIÓN E INSTALACIÓN DE VOYAGE GTR
voyage: # df -l
Filesystem 1K-blocks Used Available Use % Mounted on
rootfs 998808 272816 675256 29 % /
udev 10240 20 10220 1 % /dev
/dev/disk/by-label/ROOT_ FS
998808 272816 675256 29 % /
/dev/disk/by-label/ROOT_ FS
998808 272816 675256 29 % /dev/.static/dev
tmpfs 63384 0 63384 0 % /lib/init/rw
tmpfs 63384 0 63384 0 % /dev/shm
tmpfs 32768 664 32104 3 % /rw
voyage: #
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
...
gtr-v106: # date
Fri May 8 15:05:18 PET 2009
gtr-v106: #
voyage: # uptime
14:29:10 up 10:10, 1 user, load average: 0.00, 0.00, 0.00
voyage: #
92 CAPÍTULO 6. CONFIGURACIÓN E INSTALACIÓN DE VOYAGE GTR
7
Con guración de Redes con Voyage GTR
Para empezar a configurar las interfaces de red se debe asegurar que el sistema reconozca los dispositivos;
para esto se puede hacer:
voyage: # lspci
00:01.0 Host bridge: Advanced Micro Devices [AMD] Unknown device 2080 (rev 33)
00:01.2 Entertainment encryption device: Advanced Micro Devices [AMD] Geode LX
AES Security Block
00:09.0 Ethernet controller: VIA Technologies, Inc. VT6105M [Rhine-III] (rev 96)
00:0b.0 Ethernet controller: VIA Technologies, Inc. VT6105M [Rhine-III] (rev 96)
00:0c.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC
(rev 01)
00:0f.0 ISA bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA
(rev 03)
00:0f.2 IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion]
IDE (rev 01)
00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion]
OHC (rev 02)
00:0f.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion]
EHC (rev 02)
voyage: #
Además se debe asegurar que el sistema disponga de los controladores para estos dispositivos, aunque esto
ya se ha hecho al implementar Voyage Gtr; se puede observar en /var/log/syslog una vez que el sistema
este cargado.
93
94 CAPÍTULO 7. CONFIGURACIÓN DE REDES CON VOYAGE GTR
voyage: #
voyage: # cat /var/log/syslog |grep wifi
May 20 15:40:16 voyage kernel: wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
May 20 15:40:16 voyage kernel: wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
May 20 15:40:16 voyage kernel: wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps
36Mbps 48Mbps 54Mbps
May 20 15:40:16 voyage kernel: wifi0: H/W encryption support:
WEP AES AES_CCM TKIP
May 20 15:40:16 voyage kernel: wifi0: mac 5.9 phy 4.3 radio 4.6
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 1 for WME_AC_BE traffic
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 0 for WME_AC_BK traffic
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 2 for WME_AC_VI traffic
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 3 for WME_AC_VO traffic
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 8 for CAB traffic
May 20 15:40:16 voyage kernel: wifi0: Use hw queue 9 for beacons
May 20 15:40:16 voyage kernel: wifi0: Atheros 5212: mem=0xe0080000, irq=9
voyage: #
voyage: # cat /var/log/syslog |grep eth
May 20 15:40:16 voyage kernel: eth0: VIA Rhine III (Management Adapter) at
0xe0000000, 00:0d:b9:16:e7:9c, IRQ 10.
May 20 15:40:16 voyage kernel: eth0: MII PHY found at address 1, status 0x786d
advertising 05e1 Link 45e1.
May 20 15:40:16 voyage kernel: eth1: VIA Rhine III (Management Adapter) at
0xe0040000, 00:0d:b9:16:e7:9d, IRQ 12.
May 20 15:40:16 voyage kernel: eth1: MII PHY found at address 1, status 0x7849
advertising 05e1 Link 0000.
May 20 15:40:16 voyage kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
May 20 15:40:28 voyage kernel: eth0: no IPv6 routers present
voyage: #
auto eth0
iface eth0 inet static
address 10.10.10.1
netmask 255.255.255.240
#auto eth1
#iface eth1 inet static
#address 11.11.11.1
#netmask 255.255.255.0
7.2 Configuración de las interfaces de red 95
Si se desea crear bridge, sólo se podrá hacer entre las Ethernet; se debe descomentar el bloque del bridge y
poner la IP/Máscara de red; además la configuración de las interfaces involucradas deben ser comentadas.
auto br0
iface br0 inet static
address 11.11.10.1
netmask 255.255.255.0
bridge_ports eth0 eth1
bridge_stp off
bridge_maxwait 5
Elección si es AP ó STA.
Establecer seguridad
Configuración de la IP/MASK
#--ap
ath_parent wifi0
ath_vaptype ap
Si es STA se descomenta las líneas:
#--cliente
ath_parent wifi0
ath_vaptype sta
#ath_vapopts nosbeacon
Sólo en el caso de que en una placa se mezclen AP y STA la línea #ath_vapopts nosbeacon del
STA deberá ser descomentada.
Algunos parámetros WiFi son obligatorios, se cambiará de valor según sea necesario.
#--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:
#--ip y netmask
address 10.10.1.2
netmask 255.255.255.240
Si se ha elegido seguridad WPA2-PSK además de habilitar las opciones se debe editar los archivos adi-
cionales; donde sólo se cambiará el nombre de la red y la clave WPA2-PSK (en caracteres y debe ser desde 8
a 63 caracteres). Existe un archivo plantilla para cada interfaz dependiendo si es STA o AP. Si se está configu-
rando un cliente que es ath0 entonces se edita
/etc/wpa_supplicant/wpasupplicant-ath0.conf y se cambia el ESSID y la clave WPA2-PSK.
...
ssid="LOCAL0"
scan_ssid=1
...
priority=10
psk="gtrcaswifi"
#psk=70df87c28aee0e42b49f55450df0f822200933ff3968406176fbcd41eb9a8a72
Si se esta configurando un AP que es ath2 entonces se edita /etc/hostapd/hostapd-ath2.conf
y se cambia el ESSID y la clave WPA2-PSK.
...
ssid=LOCAL2
...
wpa_passphrase=gtrcaswifi
7.3 Configuración del enrutamiento estático, gateway y NAT 97
Para activar los cambios realizados se ejecuta /etc/init.d/networking restart además se ac-
tualiza la configuración hecha /etc/network/statics-routes-nat.
DEFAULT_GW="10.13.1.2"
Si se desea adicionar rutas estático se habilitando la variable ROUTEX (donde X es 1,2,3...100) y en cada
una se pone la red, la máscara de red y la salida por donde se accederá a esta red; además se pone la métrica.
Si se adiciona otra ruta se van adicionando variables numeradas. Esta limitado hasta 100 variables.
Para NAT sólo se optara por habilitar o no habilitar; si se habilita se descomenta la variable DEFAULT_NAT
y se elige la interfaz que hará de NAT en el equipo.
DEFAULT_NAT= “eth1”
curco-2n2:/etc/quagga# ls
daemons ospfd.conf zebra.conf ....
.....
zebra=yes
bgpd=no
ospfd=yes
ospf6d=no
ripd=no
ripngd=no
isisd=no
En zebra.conf; antes de todo se pone un nombre que podría ser el mismo que en ospfd.conf.
Hostname ospf-voyage
interface ath0
bandwidth 10000000
ipv6 nd suppress-ra
Si este equipo pertenece a una red OSPF y está conectado a un equipo vecino que no pertenece a una red
OSPF y además existe redes detrás de este equipo vecino; entonces si se quiere que la red OSPF acceda a éstas
redes; entonces en éste archivo de debe especificar la ruta para llegar a esa red indicando por donde se llegaría
y además de la distancia. En resumen se está adicionadas rutas estáticas en una red OSPF.
Aquí también se puede poner la ruta por defecto del equipo; pero será mejor hacerlo en /etc/network
/nat-static-routes.
Para la configuración en si del OSPF se edita el archivo /etc/quagga/ospfd.conf.
Se pone un nombre.
hostname ospf-voyage
Se debe habilitar las interfaces involucradas descomentando los bloques respectivos; además se debe poner
un costo (valor entero), para que no se use el ancho de banda configurado en zebra.conf.
interface ath2
ip ospf cost 10
Ahora se debe especificar el identificador del equipo en la red OSPF, es importante este valor y debe ser
distinto en la red OSPF (al menos en una misma área).
Ahora se debe poner las redes locales involucradas en la red OSPF; indicando Red/Máscara y el área al
cual pertenece.
7.5 Configuración del DHCP 99
La diferencia está en always; con éste los routers tendrán una ruta por defecto este configurado o no en
el router que lo publica; sin always los routers tendrán una ruta por defecto mientras este configurado en el
router que lo publica.
interface=br0
dhcp-range=192.168.114.7,192.168.114.14,255.255.255.240,24h
dhcp-option=3,192.168.114.1
100 CAPÍTULO 7. CONFIGURACIÓN DE REDES CON VOYAGE GTR
Para completar se debe especificar los DNS que usará este servicio; para esto se descomenta los DNS en
/etc/resolv.conf los que se necesite.
Si una interfaz está como STA y se desea pasar a modo AP (o al revés), antes se debe deshabilitar la interfaz
lógica creada, así:
Se debe recordar que se está trabajando con comandos; después de un reinicio se perderá la configuración.
102 CAPÍTULO 7. CONFIGURACIÓN DE REDES CON VOYAGE GTR
8
Veri cación del Estado de la Red de Datos
Como se ha comentado ampliamente en 1.4, con la tecnología WiLD se puede llega a construir grandes
redes de datos. Estas se encuentran compuestas de redes troncales y de distribución. Una red troncal consiste
tradicionalmente en líneas relativamente largas que recogen y reparten el tráfico a las zonas de distribución
situadas en pequeñas poblaciones.
En la figura 8.1 se puede apreciar la red troncal de color negro y la red de distribución de color rojo. Tomando
como base el escenario presentado, a continuación se detalla las medidas de verificación de buen estado, que
debe realizarse en una red instalada con routers con sistema operativo Voyage GTR.
103
104 CAPÍTULO 8. VERIFICACIÓN DEL ESTADO DE LA RED DE DATOS
Estos parámetros representan la calidad del enlace. En largas distancias se puede asumir que se debe lograr
un nivel de entre -65dBm y -75dBm con una calidad (Link Quality) de unos 20dB; si se tiene un nivel por
debajo de -75dBm hasta -80dBm el enlace estará muy inestable y tendrá un rendimiento bajo. Tomar nota por
cada router del enlace:
En los nodos Managed se observa la MAC del AP, con esto se puede asegurar que existe enlace entre el
STA y el AP; además se observa nivel aceptable de 70dBm (con un link quality de 25/94 aprox.). Además con
el resultado de ésta información se debe verificar el nombre la red WiFi, el canal, la potencia configurada, la
velocidad máxima, y la seguridad apoyada de otros archivos.
Con el siguiente comando se observará las potencias configurables en las tarjetas inalámbricas; por ejemplo
este resultado corresponde a una SR2 de Ubiquiti (posee un offset de 10dBm).
Si se ha anulado la diversidad en una interfaz y se ha configurada el conector principal (Main) para transmitir y
recibir, se debe observar:
Si con estos mismos equipos se está trabajando en enlaces más cortos, de alrededor de 15Km este nivel
de recepción obtenido aún se puede mejorar, al menos hasta llegar a -55dBm; pero para enlaces de 40Km con
estas tarjetas inalámbricas y antenas directivas, este nivel puede ser lo mejor que se logre.
Lograr un aceptable nivel de la señal y calidad del enlace no necesariamente garantiza un buen rendimiento;
además se debe observar los tiempos de ping que se hacen y el rendimiento (ver más adelante) que se puede
lograr; el resultados de estos esta relacionado con la correcta configuración de la distancia del enlace.
Inicialmente se puede dejar configurado el enlace con una distancia obtenida por medio de los simuladores
de enlaces WiFi y de las coordenadas obtenidas. Una vez en campo se puede encontrar la distancia más óptima
que puede estar alrededor de más o menos 300m del que se ha configurado. El cambio de la distancia se debe
hacer en ambos lados del enlace. En un enlace punto multipunto la distancia a configurar es la que se tiene con
la antena mas alejada.
Si no se ha configurado la distancia, por defecto se mostrará:
Si se ha configurado para una distancia de 1000m por ejemplo; se tendría estos valores:
Una vez que se haya verificado los enlaces WiFi se debe verificar los parámetros TCP/IP de cada interfaz
de red. La IP y la máscara de red se observa con el comando ifconfig:
8.1 Conectividad en enlaces AP-STA 109
nodo-a: #
Se prueba la conectividad con el comando ping. Además de observar si la otra interfaz responde al ping; se
debe observar la regularidad de los ping que generalmente pueden oscilar entre 1 a 3ms en un enlace aceptable;
y además la pérdida de paquetes que generalmente deben estar entre 1 a 3 paquetes perdidos por cada 60
transmitidos (1 minuto). Para esta prueba se debe hacer un ping de unos 30 paquetes y por cada AP - STA del
enlace y anotar:
Pérdida de paquetes
El resultado de los ping esta relacionados con la distancia del enlace y con nivel y calidad de la señal, se debe
tener en cuenta de éstos en esta prueba; quizás se tenga valor altos respecto a los referenciales.
Si se obtiene resultados muy alejados de lo aceptable; se debe cambiar la distancia; cambiando en pasos de
100m hasta encontrar el más óptimo. Después de cada cambio se debe repetir la prueba de ping, como los ping
de mayor tamaño y el rendimiento del enlace.
8.1.5. Ping con mayor tamaño entre las interfaces del enlace
Un ping con mayor bytes transmitidos muestra una aproximación de la carga que puede soportar el enlace;
esto se observa en la regularidad del tiempo de transmisión de paquetes y la pérdida de éstos. Si se transmiten
1500 bytes en el enlace ejemplo, el tiempo de cada ping debe ser regular y estar alrededor de 3 a 6ms; si se
tiene una irregularidad notable por ejemplo saltos de 5ms a 20ms en varios pings, se debe seguir vigilando y
revisar el enlace. La pérdida de paquetes debe ser muy baja o casi nula comparada con la cantidad que se está
enviando en total. De la misma manera que el ping normal, esta prueba está relacionada con la distancia, el
nivel y calidad del enlace. Para esta prueba se debe hacer ping con una cantidad de unos 30 paquetes; se debe
anotar.
Pérdida de paquetes
nodo-b: # iperf -s
----------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
----------------------------------------
[ 4] local 10.1.2.2 port 5001 connected with 10.1.2.1 port 2545
[ 4] 0.0-50.1 sec 8.66 MBytes 4.82 Mbits/sec
Si se trabaja con enrutamiento dinámico las redes accesibles aparecerán en la tabla de rutas; si alguno no
aparece se debe comprobar; quizás el problema es que ciertos enlaces estén caídos; para esto se puede usar
traceroute.
Si se trabaja con enrutamiento estático necesariamente se debe comprobar el acceso a la red con el comando
traceroute para verificar que la red es accesible.
Si el equipo tiene salida a Internet se debe comprobar.
Anotar además posibles retardos o pérdida de paquetes hacia una interfaz en particular para
su revisión posterior cuando se esté en ese nodo.
Si es accesible a la interfaz o no
Si se va ha usar asterisk en un equipo donde exista OSPF se debe poner el nombre del equipo también en
/etc/hosts.
Para activar el servicio en el arranque del sistema se debe poner en yes la variable RUNASTERISK en el
archivo /etc/default/asterisk.
voyage: #
Esto permitirá que se cargue después de un reinicio; pero si se desea que se cargue en este momento se
puede hacer:
115
116 CAPÍTULO 9. CONFIGURACIÓN DE UNA RED DE TELEFONÍA IP CON ASTERISK
[general]
;
bindport=5060
disallow=all
allow=ulaw
allow=g726aal2
allow=gsm
allow=ilbc
allow=g726
;
[210]
type=friend
host=dynamic
language=es
context=center
secret=passwd
username=210
callerid=210
dtmfmode=rfc2833
qualify=yes
;
Para configurar clientes SIP con puerto FXO, se puede usar la identificación 10; cambiado sólo lo necesario.
[10]
type=friend
port=5061
host=dynamic
language=es
context=center
secret=passwd
username=10
callerid=10
dtmfmode=rfc2833
qualify=yes
;
9.2 Configuración básica de Asterisk 117
[globals]
;
IP-SERVER200=
IP-SERVER300=20.20.20.13
IP-SERVER400=
IP-SERVER-PSTN=
PHONE-DEFAULT=
La variable PHONE-DEFAULT= contiene el teléfono que responderá por defecto después de escuchar el
IVR en una llamada proveniente del exterior.
En la parte (center) se especifica con que equipos se tendrá comunicación; está divido en: comunicación
con equipos locales, con equipos de otros Asterisk y con la telefonía pública
Aquí se muestra una especie de prueba de llamado al servidor, se especifica un número que identifique al
servidor Asterisk.
Para la comunicación con la telefonía pública se especifica los números permitidos; tenga en cuenta que se
debe diferenciar de los números telefónicos usados en la red; a veces se usa un prefijo; en este caso se antepone
un cero, si se desea llamar al 147 sería 0147, si se desea una comunicación sin restricción se puede usar _0.
En el cuadro de abajo se muestran los comandos para comunicarse con la telefonía pública para el Asterisk
donde se va a registrar al cliente SIP que va ha conectar la telefonía IP con la telefonía pública. En la primera
parte se muestra los números permitidos para llamar a la telefonía pública y la segunda parte se muestra al iden-
tificador 11 que se usará para identificar todas las llamadas entrantes de la telefonía pública; como se observa,
están redirigidas al IVR.
;exten =>0147,1,Macro(dial-svred,$IP-SERVER-PSTN,${EXTEN})
exten =>_0.,1,Macro(dial-svred,$IP-SERVER-PSTN,${EXTEN})
;ivr basico
;
(ivr)
;
exten =>s,1,Set(CHANNEL(LANGUAGE)=es)
exten =>s,2,Background(xivr_bienvenido_pucp)
exten =>s,3,Background(xivr_opciones_pucp)
exten =>s,4,Set(TIMEOUT(digit)=3)
exten =>s,5,Set(TIMEOUT(response)=9)
exten =>t,1,Goto(center,${PHONE-DEFAULT},1)
exten =>i,1,Set(LANGUAGE()=es)
exten =>i,2,Playback(xnumero_incorrecto)
exten =>i,3,Goto(s,3)
;
exten =>_2XX,1,Goto(center,${EXTEN},1)
exten =>_3XX,1,Goto(center,${EXTEN},1)
exten =>_4XX,1,Goto(center,${EXTEN},1)
;
[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
;
nodo-b*CLI>
- Registered SIP '210át 10.1.52.3 port 5060 expires 3600
- Saved useragent "Linksys/SPA3102-3.3.6(GW)"for peer 210
- Registered SIP '10át 10.1.52.3 port 5061 expires 3600
- Saved useragent "Linksys/SPA3102-3.3.6(GW)"for peer 10
nodo-b*CLI>sip show peers
Name/username Host Dyn Nat ACL Port Status
10/10 10.1.52.3 D 5061 OK (12 ms)
211/211 (Unspecified) D 0 UNKNOWN
210/210 10.1.52.3 D 5060 OK (13 ms)
3 sip peers (2 online , 1 offline)
Se observa que los clientes 10 y 210 están ya registrados. Para salir del CLI sólo se hace exit.
nodo-b*CLI>exit
Executing last minute cleanups
nodo-b: #
Si se modifica los archivos de configuración para cargar ésta nueva configuración en el Asterisk se hace:
nodo-b*CLI>reload
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 Verificación del estado de telefonía IP con Asterisk 121
*CLI>stop now
nodo-b: # /etc/init.d/asterisk start
No olvide que debe comprobar de nuevo que el Asterisk esté cargado o activo.
voyage-112*CLI>
- Executing [200@center:1] Macro("SIP/210-081b0fb8", çall-svlocal|200") in new stack
- Executing [s@macro-call-svlocal:1] Set("SIP/210-081b0fb8", ÇHANNEL(language)=es") in new stack
- Executing [s@macro-call-svlocal:2] Playback("SIP/210-081b0fb8", "xservidor") in new stack
- <SIP/210-081b0fb8>Playing 'xservidor'(language és')
- Executing [s@macro-call-svlocal:3] SayDigits("SIP/210-081b0fb8", "200") in new stack
- <SIP/210-081b0fb8>Playing 'digits/2'(language és')
- <SIP/210-081b0fb8>Playing 'digits/0'(language és')
- <SIP/210-081b0fb8>Playing 'digits/0'(language és')
- Executing [s@macro-call-svlocal:4] Wait("SIP/210-081b0fb8", "1") in new stack
- Executing [s@macro-call-svlocal:5] Hangup("SIP/210-081b0fb8", ) in new stack
== Spawn extension (macro-call-svlocal, s, 5) exited non-zero on 'SIP/210-081b0fb8ín macro 'call-svlocal'
== Spawn extension (center, 200, 1) exited non-zero on 'SIP/210-081b0fb8'
voyage-112*CLI>
Calidad en la conversación.
voyage-112*CLI>
voyage-112*CLI>
- Executing (210@center:1) Macro("SIP/211-b7200470", "dial-svlocal|SIP|210") in new stack
- Executing (s@macro-dial-svlocal:1) Dial("SIP/211-b7200470", "SIP/210|26") in new stack
- Called 210
- SIP/210-081b0fb8 is ringing
- SIP/210-081b0fb8 answered SIP/211-b7200470
- Native bridging SIP/211-b7200470 and SIP/210-081b0fb8
voyage-112*CLI>
voyage-112*CLI>
voyage-112*CLI>sip show channels
Peer User/ANR Call ID Seq (Tx/Rx) Format Hold Last Message
20.20.20.199 210 1a234c1f236 00103/00000 0x4 (ulaw) No Tx: ACK
20.20.20.113 211 355739771-5 00102/00011 0x4 (ulaw) No Tx: ACK
2 active SIP channels voyage-112*CLI>
voyage-112*CLI>
voyage-112*CLI>core show channels
Channel Location State Application(Data)
SIP/210-081b0fb8 (None) Up AppDial((Outgoing Line))
SIP/211-b7200470 s@macro-dial-svlocal Up Dial(SIP/210|26)
2 active channels
1 active call
voyage-112*CLI>
voyage-112*CLI>
== Spawn extension (macro-dial-svlocal, s, 1) exited non-zero on 'SIP/211-b7200470ín macro 'dial-svlocal'
== Spawn extension (center, 210, 1) exited non-zero on 'SIP/211-b7200470'
voyage-112*CLI>
Si se realiza sin problemas una llamada de prueba al resto de los servidores de telefonía de la red.
9.4 Verificación del estado de telefonía IP con Asterisk 123
voyage-112*CLI>
- Executing (300@center:1) Macro("SIP/210-081b0fb8", "dial-svred|20.20.20.13|300") in new stack
- Executing (s@macro-dial-svred:1) Dial("SIP/210-081b0fb8", ÏAX2/iaxuser:passwd@20.20.20.13/300|28")
in new stack
- Called iaxuser:passwd@20.20.20.13/300
- Call accepted by 20.20.20.13 (format ulaw)
- Format for call is ulaw
- IAX2/20.20.20.13:4569-9518 answered SIP/210-081b0fb8
- Hungup ÍAX2/20.20.20.13:4569-9518'
== Spawn extension (macro-dial-svred, s, 1) exited non-zero on 'SIP/210-081b0fb8ín macro 'dial-svred'
== Spawn extension (center, 300, 1) exited non-zero on 'SIP/210-081b0fb8'
voyage-112*CLI>
voyage*CLI>
- Accepting AUTHENTICATED call from 20.20.20.112:
>requested format = ulaw,
>requested prefs = (ulaw),
>actual format = ulaw,
>host prefs = (ulaw|g726),
>priority = mine
- Executing Macro(ÏAX2/20.20.20.112:4569-16325", çall-svlocal|300") in new stack
- Executing Set(ÏAX2/20.20.20.112:4569-16325", "LANGUAGE()=es") in new stack
- Executing Playback(ÏAX2/20.20.20.112:4569-16325", "xservidor") in new stack
- Playing 'xservidor'(language és')
- Executing SayDigits(ÏAX2/20.20.20.112:4569-16325", "300") in new stack
- Playing 'digits/3'(language és')
- Playing 'digits/0'(language és')
- Playing 'digits/0'(language és')
- Executing Wait(ÏAX2/20.20.20.112:4569-16325", "1") in new stack
- Executing Hangup(ÏAX2/20.20.20.112:4569-16325", ) in new stack
== Spawn extension (macro-call-svlocal, s, 5) exited non-zero on ÍAX2/20.20.20.112:4569-16325ín macro
'call-svlocal'
== Spawn extension (macro-call-svlocal, s, 5) exited non-zero on ÍAX2/20.20.20.112:4569-16325'
- Hungup ÍAX2/20.20.20.112:4569-16325'voyage*CLI>
Si se realiza sin problemas una llamada de prueba con un cliente administrado por otro servidor.
Calidad de la conversación.
voyage-112*CLI>
- Executing (310@center:1) Macro("SIP/210-081b0fb8", "dial-svred|20.20.20.13|310") in new stack
- Executing (s@macro-dial-svred:1) Dial("SIP/210-081b0fb8", ÏAX2/iaxuser:passwd@20.20.20.13/310|28")
in new stack
- Called iaxuser:passwd@20.20.20.13/310
- Call accepted by 20.20.20.13 (format ulaw)
- Format for call is ulaw
- IAX2/20.20.20.13:4569-11764 is ringing
- IAX2/20.20.20.13:4569-11764 stopped sounds
- IAX2/20.20.20.13:4569-11764 answered SIP/210-081b0fb8
voyage-112*CLI>
voyage-112*CLI>
voyage-112*CLI>core show 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
124 CAPÍTULO 9. CONFIGURACIÓN DE UNA RED DE TELEFONÍA IP CON ASTERISK
voyage-112*CLI>
voyage-112*CLI>
- Hungup ÍAX2/20.20.20.13:4569-11764'
== Spawn extension (macro-dial-svred, s, 1) exited non-zero on 'SIP/210-081b0fb8ín macro 'dial-svred'
== Spawn extension (center, 310, 1) exited non-zero on 'SIP/210-081b0fb8'
voyage-112*CLI>
voyage-112*CLI>
voyage*CLI>
- Accepting AUTHENTICATED call from 20.20.20.112:
>requested format = ulaw,
>requested prefs = (ulaw),
>actual format = ulaw,
>host prefs = (ulaw|g726),
>priority = mine
- Executing Macro(ÏAX2/20.20.20.112:4569-1642", "dial-svlocal|SIP|310") in new stack
- Executing Dial(ÏAX2/20.20.20.112:4569-1642", "SIP/310|26") in new stack
- Called 310
- SIP/310-0817d6c8 is ringing
- SIP/310-0817d6c8 answered IAX2/20.20.20.112:4569-1642
voyage*CLI>
voyage*CLI>
== Spawn extension (macro-dial-svlocal, s, 1) exited non-zero on ÍAX2/20.20.20.112:4569-1642'
in macro 'dial-svlocal'
== Spawn extension (macro-dial-svlocal, s, 1) exited non-zero on ÍAX2/20.20.20.112:4569-1642'
- Hungup ÍAX2/20.20.20.112:4569-1642'
voyage*CLI>
voyage*CLI>
Caso de Estudio: Red Napo Sur
10
10.1. Generalidades
El presente documento presenta la memoria técnica de los trabajos de instalación y puesta en operación de
los sistemas de comunicación de voz y datos del Proyecto “Mejora de las condiciones de salud de la población
materno-infantil a través del uso apropiado de las Tecnologías de la Información y las Comunicaciones (TIC)
en centros y puestos de salud del Río Napo (Perú)” el cuál ha sido financiado por el Ayuntamiento de Madrid
y ejecutado por la Fundación EHAS y el Grupo de Telecomunicaciones Rurales de la Pontificia Universidad
Católica del Perú (GTR-PUCP).
El proyecto fue ejecutado en los distritos de Punchana, Mazán y Napo, en la provincia de Maynas, depar-
tamento de Loreto. Contempló la interconexión de cinco establecimientos de salud rurales, el Vicariato de San
José del Amazonas (donde existe un albergue de reposo para los pacientes y sus familiares que son referidos al
Hospital Regional de Loreto para atenciones especializadas en la ciudad de Iquitos), la oficina de Radiofonía
de la Dirección Regional de Salud y los ambientes de Emergencia del Hospital Regional de Loreto. 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
comunicación de voz y datos operando se está contribuyendo a la reducción de la morbi-mortalidad Materno
Infantil en esta zona rural aislada del Perú.
125
126 CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR
En la siguiente tabla se muestra los datos georeferenciales de la ubicación de las torres ventadas de
los establecimientos de salud y de las instalaciones que forman parte de la red troncal del sistema
de transmisión de voz y datos:
10.2 Descripción General de la Red de Comunicaciones 127
En la siguiente tabla se detallan las distancias existentes en los enlaces de la red troncal
La red troncal a quedado formada por siete repetidores con lo cual se han establecido seis nuevos enlaces.
En el caso de los enlaces de distribución hacia los establecimientos de salud cada estación repetidora cuenta
con un cliente, salvo el caso del repetidor ubicado en el Hospital Regional de Loreto, el cuál cuenta con dos
clientes. En la siguiente figura se muestra en detalle un segmento de red.
Figura 10.6: Esquema de la red troncal simulada con el software de Radio Mobile.
Tabla 10.7.- Características de los equipos 802.11g elegidos para el enlace de distribución.
138 CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR
Figura 10.19: Esquema de conexiones en una estación repetidora de los enlaces rurales (Tacsha
Curaray Negro Urco Tuta Pishco Huamán Urco).
10.3 Descripción de la Red de Telecomunicaciones 139
En el repetidor de PetroPerú se han instalado una placa ALIX y una placa MIKROTIK. La única función
que cumple la placa ALIX n2 es ser el servidor Asterisk local. Los enlaces inalámbricos los administra la
placa MIKROTIK n1 mediante tres tarjetas inalámbricas R52H. Los enlaces hacia el repetidor de Mazán y el
repetidor ubicado en el Hospital Regional de Iquitos son enlaces en la frecuencia de 5.8GHz. En el caso del
enlace de distribución hacia el Vicariato de San José del Amazonas se realiza en la frecuencia de 2.4GHz. La
energía es proporcionada desde la caseta de energía ubicada en la base de la torre.
En el repetidor del Hospital Regional de Loreto se ha instalado una placa MIKROTIK con tres tarjetas
inalámbricas R52H. El enlace con el repetidor ubicado en Planta de Ventas se realiza en la frecuencia de
5.8GHz. Y los dos enlaces de distribución uno hacia la oficina de Radiofonía de la Dirección Regional de Salud
y el segundo hacia los ambientes de Emergencia del Hospital Regional de Loreto se realizan en la frecuencia
de 2.4GHz
10.3 Descripción de la Red de Telecomunicaciones 141
Figura 10.24: Esquema del sistema de energía en una estación cliente rural y de su sistema de
protección eléctrica.
Figura 10.25: Esquema del sistema de energía en una estación repetidora rural y de su sistema de
protección eléctrica.
144 CAPÍTULO 10. CASO DE ESTUDIO: RED NAPO SUR
Los pozos de tierra construidos en las estaciones rurales son pozos horizontales de 10m de longitud lineales
en el caso de las estaciones clientes y de 20m de longitud en forma cuadrada alrededor de la base de la torre
ventada. La sección de ambos pozos es de 50cm de ancho por 60cm de profundidad.
En el caso del repetidor ubicado en la Planta de Ventas de PetroPerú la torre ventada cuenta con su sistema
de protección eléctrica instalada y supervisada por la misma empresa. Similar caso se presenta en con el repeti-
dor ubicado en el Hospital Regional de Loreto donde los equipos han sido aterrados al sistema de protección
eléctrica del mismo hospital.
En la siguiente tabla se detalla las lecturas de resistencia de los pozos de tierra construidos en las comu-
nidades de Negro Urco, Tuta Pishco, Huamán Urco y Mazán.
[1] B. Raman,“Digital Gangetic Plains: 802.11-Based Low-Cost Networking for Rural Areas, 2001 −
2004: A Report”, by Bhaskaran Raman, Ed., DGP Media Labs Asia Team, July 2004.
[2] Chieng, D.; Tan, S.W.; Rahim, R.; Ting, A.,“QoS Performance Analysis of Multi-Radio Multi-Hop
Wi-Fi Chain Network”, Wireless Broadband and Ultra Wideband Communications, 2007. AusWireless
2007. The 2nd International Conference on , vol., no., pp.38-38, 27-30 Aug. 2007
[3] E Brewer, M Demmer, Bowei W. Du, M Ho, M Kam, S Nedevschi, J Pal, Rabin Patra, S Surana, and K
Fall,“The case for technology in developing regions”, (2005). Computer. 38 (6), pp. 25+.
[4] Experiences in using WiFi for Rural Internet in India, Bhaskaran Raman and Kameswari Chebrolu, IEEE
Communications Magazine, Jan 2007, Special Issue on New Directions In Networking Technologies In
Emerging Economies.
[5] Francisco Javier Simó Reigadas, “Modelado y Optimización de IEEE 802.11 para su aplicación en el
despliegue de redes extensas en zonas rurales aisladas de países en desarrollo”, 2007.
http://www.ehas.org/uploads/file/difusion/academico/Tesis/TesisJSimo.
pdf
[6] Grupo de Telecomunicaciones Rurales-PUCP, “Redes Inalambricas para Zonas Rurales”, Primera
Edición, 2008
http://gtr.telecom.pucp.edu.pe/
[7] Long Distance Wireless Mesh Network Planning: Problem Formulation and Solution, Sayandeep Sen
and Bhaskaran Raman. The 16th Annual Interntional World Wide Web Conference (WWW 2007), May
2007, Banff, Canada.
[8] Long-Distance 802.11b Links: Performance Measurements and Experience, Kameswari Chebrolu,
Bhaskaran Raman, and Sayandeep Sen, 12th Annual International Conference on Mobile Computing and
145
146 BIBLIOGRAFÍA
[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/
[17] HyperGain HG2424G 2.4 Ghz 24 dBi High Perfomance Reflector Grid Antenna.
http://www.hyperlinktech.com/web/hg2424g.php
[19] MadWifi.
http://madwifi-project.org/
[20] Mikrotik
http://www.routerboard.com/
[21] PC Engines.
http://www.pcengines.ch/
BIBLIOGRAFÍA 147
[26] TIER.
http://tier.cs.berkeley.edu/
[27] Ubiquiti.
http://www.ubnt.com/
[28] Voyage-Linux.
http://linux.voyage.hk/
CA Collision Avoidance.
CD collision Detection.
CF Compact Flash.
149
150 Glosario
DIFS Tiempo que cada estación espera una vez que detecta que el canal ha quedado libre.
FM Frequency Modulation.
HF High Frecuency.
IP Internet Protocol.
PTT Push-to-talk.
SIFS Tiempo fijo que define la separación entre la recepción del paquete de la transmisión de su ACK en el
receptor.