Captulo 3:

Metodologa

3.1 Descripcin del Problema

El objetivo del presente trabajo de memoria era generar un documento donde se detallen los
pasos a seguir en presencia de una falla, para resolverla en forma rpida, es decir, un esquema de
troubleshooting. Esto se realiz para dos tecnologas de acceso: Ethernet y ADSL. Esto no fue
una tarea simple ya que para poder realizar un buen troubleshooting se debe primero poseer un
slido conocimiento de la tecnologa en cuestin, adems de cierta experiencia en lo relativo a las
fallas ms tpicas que se presentan en ella.
El documento final ayuda a la realizacin de las siguientes tareas:
1. Recopilacin de informacin relativa a la falla, es decir, establecer cuales son los
sntomas que la caracterizan.
2. Generar hiptesis diagnsticas, es decir, posibles causas del problema.
3. Realizar las pruebas necesarias para determinar cual de las hiptesis diagnsticas es la
correcta, generando as el diagnstico.
4. Predecir que suceder si no se toman medidas para resolver la falla.
5. Realizar el tratamiento de la falla y resolverla.

3.2 Pasos a seguir

A continuacin se detallan cada uno de las tareas que debieron completarse para lograr generar el
documento con los esquemas de troubleshooting. Estas son las siguientes: anlisis de tecnologas,
definicin de parmetros de desempeo, definicin de herramientas de medicin de dichos
parmetros, definicn de tipos de servicio y sus requerimientos, recopilacin de informacin de
fallas, realizacin de laboratorios y pruebas, y generacin de esquemas de troubleshooting.

3.2.1 Anlisis de las Tecnologas

Esto es lo primero que debe realizarse. Debe poseerse un conocimiento amplio de cada una de las
tecnologas, de lo contrario sera imposible realizar el troubleshooting. Se deben conocer las
caractersticas ms relevantes de cada una de las tecnologas as como tambin las fallas ms
comunes relacionadas con cada una de ellas.
Para esto es necesario un anlisis terico de cada tecnologa pero tambin es de mucha
importancia ponerse en contacto directo con las tecnologas mediante un anlisis de la operacin
y las configuraciones tpicas de los equipos utilizados. Esto con el fin de familiarizarse con las
tecnologas ya que dada la naturaleza prctica de la memoria esto es de gran importancia.
40

3.2.2 Definicin Parmetros de Desempeo

Se deben definir ciertos parmetros de desempeo que sirvan para establecer las condiciones
ideales de operacin para cada servicio estudiado. Esto ya que posteriormente se podran asociar
deficiencias en ciertos parmetros a sntomas especficos en cada tipo de servicio.

3.2.3 Definicin Herramientas de Medicin

Debe poder medirse el estado de los parmetros de desempeo. Es por esto que debern definirse
las herramientas de medicin con que se realizar dicha labor. Existen mltiples alternativas para
esto, sin embargo, es importante que queden bien definidas desde el comienzo, ya que las
herramientas con las que se establecern las condiciones ideales de operacin deben ser las
mismas que se utilizarn luego para medir el estado de los parmetros cuando se est realizando
el troubleshooting.

3.2.4 Definicin Tipos de Servicio y Requerimientos

Luego de que se han analizado las distintas tecnologas, se deben definir tipos de servicio en base
a los requerimientos de cada uno de ellos, es decir, se agrupan servicios que tienen
requerimientos similares para funcionar correctamente. Una vez definidos estos grupos, se
debern establecer las condiciones ideales de operacin para cada uno de ellos (cuando sea
posible o razonable hacer esto). Estas condiciones deben ser tal que garanticen un
funcionamiento ptimo del servicio en cuestin. Esto se har en base a los parmetros de
desempeo establecidos en el punto anterior.

3.2.5 Recopilacin Informacin de Fallas

Se realiz una recopilacin de informacin relacionada con las fallas ms tpicas que se presentan
en cada una de las tecnologas de acceso. Para esto se utilizaron todas las posibles fuentes de
informacin a las que se pudo acceder. Esto con el fin de tener un conocimiento respecto de los
problemas ms importantes y ms frecuentes en cada tipo de acceso.

3.2.6 Laboratorios y Pruebas

En esta etapa se montaron laboratorios para los distintos tipos de acceso. Lo primero fue dejarlos
operando en condiciones ideales y con los servicios funcionando en forma correcta. Luego de
esto se realizaron modificaciones a estas condiciones ideales, que pueden ser cambios en la
configuracin de un equipo, cables desconectados, inyeccin de trfico adicional para saturar el
enlace, etc. Esto con el fin de observar los efectos que cada uno de estos cambios tiene sobre el
sistema, e ir almacenando esta informacin.
41

La idea entonces fue tener el sistema funcionando en condiciones ideales y echarlo a perder de la
mayor cantidad de formas posibles, documentando los efectos de cada una de las modificaciones
sobre cada uno de los tipos de servicio.

3.2.7 Generacin Esquemas Troubleshooting

Una vez que se ha recolectado una gran cantidad de informacin a travs de lo especificado en
los dos puntos anteriores, se pueden comenzar a generar los esquemas de troubleshooting, los que
debern permitir determinar la causa de una falla a partir de un conjunto de sntomas observables
o medibles. Estos esquemas debern especificar cada uno de los pasos a seguir y estarn basados
en la metodologa de los ocho pasos de Cisco, en conjunto con la metodologa de troubleshooting
por capas que se presentan ms adelante en este captulo.

3.3 Introduccin al Troubleshooting

Los problemas que se dan en sistemas computacionales y de redes son inevitables. Estos
problemas se pueden dar en distintos niveles, y pueden afectar a un equipo en particular, a un
grupo de stos o incluso al sistema completo. Si nos referimos al modelo OSI, tenemos que se
pueden dar fallas en todas las capas, pero las ms comunes son las que afectan la capa fsica, la
capa de enlace y la capa de red.
Sin embargo, tambin hay situaciones donde las fallas se dan en capas superiores, por ejemplo en
telefona IP, donde la capa de transporte y la capa de sesin tienen mayor importancia.
Encontrar y resolver un problema, es el proceso que se conoce como troubleshooting, y es
anlogo al proceso que realiza un mdico cuando se enfrenta a un paciente enfermo y tiene que
remediarlo. Esto puede ser muy difcil y puede tomarmucho tiempo si se intentan soluciones al
azar. Un mtodo de resolucin de fallas efectivo requiere la combinacin de un adecuado
conocimiento del sistema, de un esquema de descarte lgico de posibles causas y de un
acercamiento estructurado ordenado al problema. Dado que el conocimiento y la experiencia
varan en cada persona, todos se pueden beneficiar con un buen esquema de troubleshooting.
Las fallas en redes, y en cualquier otro sistema se caracterizan por ciertos sntomas. Estos
pueden ser generales, por ejemplo, que ciertos clientes no pueden acceder a servidores
especficos. Tambin pueden ser ms especficos, por ejemplo, una falla en la configuracin de
un enlace Ethernet. El proceso de recopilacin de sntomas e informacin acerca del sistema se
conoce como semiosis.
Cada sntoma se puede asociar a uno o ms problemas mediante el uso de diversas herramientas y
tcnicas para el troubleshooting. A estas posibles causas del problema se les denomina hiptesis
diagnsticas. Luego de identificar el problema descartando hiptesis diagnsticas hasta
42

encontrar la que causa el problema, ste puede ser remediado tomando una serie de acciones para
implementar la solucin o tratamiento.
Sin embargo, tambin se debe evaluar que podra ocurrir en caso de que no se realicen
modificaciones (lo que se conoce como prognosis), en el caso de que el implementar una
solucin involucre ciertas desventajas para el sistema.

43

3.4 Modelos de Troubleshooting

3.4.1 Modelo de ocho pasos de Cisco
Este modelo consta, como su nombre lo indica, de ocho pasos. Cada uno de ellos es de vital
importancia para realizar un buen troubleshooting, y est pensado para facilitar la labor de
deteccin y resolucin de fallas. A continuacin se detalla la metodologa planteada por este
modelo, con una descripcin de cada uno de los pasos que lo conforman.
3.4.1.1

Metodologa

Cuando se enfrenta un problema en un entorno de red, lo mejor es realizar un acercamiento

sistemtico al problema. Una accin poco sistemtica puede llevar a una prdida de tiempo y de
recursos, e incluso, puede llegar a empeorar el problema que se presentaban en un principio.
Una buena metodologa para resolver fallas parte por definir una serie de sntomas, luego, asocia
posibles causas (o hiptesis diagnsticas) a cada uno de dichos sntomas. Esto, para luego poder
ir descartando sistemticamente cada una de las hiptesis, desde la ms probable, hasta la menos
probable, hasta encontrar la causa real del problema. La metodologa que implementa Cisco se
basa en un grupo de ocho pasos a seguir para enfrentar cualquier problema.
Paso 1: Si se est analizando un problema en una red, hay que definir el problema en funcin de
los sntomas presentes, y de posibles causas.
Para realizar el anlisis del problema, se identifica el conjunto de sntomas presentes en el
sistema. Este proceso es anlogo al que realiza un mdico cuando quiere diagnosticar a un
paciente, y primero debe averiguar cules son los sntomas que ste presenta. En ambos casos,
luego se debe asignar posibles causas a cada sntoma, o al conjunto general de sntomas
presentes. Por ejemplo, un sntoma puede ser que un cliente no puede acceder a ciertos
servidores, donde ste problema puede darse por desperfectos en las tarjetas de red (capa fsica),
o bien a un problema de ruteo, donde cliente-servidor no estn en la misma red debido a una
configuracin errnea (capa de red).
Paso 2: En base a los sntomas presentes, se debe realizar una recoleccin de informacin, que
apunte a los problemas que se estn considerando. Este proceso de recoleccin de informacin se
conoce como Semiosis. Volviendo al anlogo mdico, en base a los sntomas presentes en el
paciente, el mdico se hace una idea de las enfermedades que pueden estar causando los sntomas
presentes, lo que se conoce como hiptesis diagnstica, y en base a esta hiptesis, se realizan
diversos tipos de exmenes orientados a las enfermedades que est considerando el mdico.

44

La informacin recolectada ser la base para aislar el problema, por lo que esta etapa es
fundamental. La experiencia y el conocimiento de la persona que est abordando el problema
juegan tambin un papel importante en esta fase, ya que una recoleccin de informacin escasa, o
mal orientada puede llevar a un problema sin solucin, o lo que es peor, a un mal diagnstico.
Primero, se debe revisar las cosas obvias: Est todo donde debe estar?, Todo est conectado?
Estn todos los archivos donde deben estar?, etc. Luego, se debe revisar si existe algn registro
documentado donde se describa un problema similar que haya ocurrido anteriormente, y si existe
alguna solucin adecuada.
Los usuarios del sistema pueden ser extremadamente tiles en la recoleccin de informacin. En
muchos casos, los usuarios pueden ser claves para descubrir el problema, ya que ellos pueden dar
informacin que puede ser la pista clave para encontrar el problema. La clave es hacer las
preguntas correctas, para determinar que es lo que hace la red o el equipo para que el usuario
piense que hay un problema.
Observaciones que siempre es til buscar son las siguientes:
No puedo conectarme
No puedo imprimir
La red esta muy lenta
Estaba conectado al servidor, pero perd la conexin
Mi computador se detiene cada vez que
Tengo este problema desde que se instal
Tengo este problema desde que movieron..:
Preguntas que pueden aislar el problema:
Cuntos usuarios estn afectados por el problema? Uno? Algunos? Todos? Usuarios al
azar?
Cundo comenz el problema?
Ha cambiado algo desde que el sistema funciona correctamente?
El problema es constante o intermitente?
El problema es en todas las aplicaciones o slo en una?
Hay nuevos usuarios en la red?
Hay equipos nuevos en la red?
Algn equipo se traslad ltimamente?
Este problema es similar a algn otro anterior?
Alguien ms intent resolver el problema?
Paso 3: Una vez finalizada la etapa de recoleccin de informacin, se deben considerar las causas
posibles del problema. Se pueden descartar algunas de las hiptesis diagnsticas a travs de un
anlisis de la informacin obtenida en la semiosis. Este proceso de anlisis de la informacin
recolectada se conoce como Diagnosis. Por ejemplo, en base a la informacin recolectada, se
45

puede descartar un problema de hardware si existe conectividad a nivel de red, lo que permitir
enfocarse a posibles problemas de software en capas superiores. Siempre se intenta reducir el
rango de problemas probables, para poder realizar un plan de accin eficiente.
Paso 4: Luego del proceso de diagnosis, se debe evaluar y predecir, que suceder con el sistema
si no se realiza ninguna accin, en un proceso conocido como Prognosis. Este proceso es
fundamental, debido a que en ciertos casos, tomar una accin para solucionar un problema puede
hacer que los sntomas presentes en el sistema desaparezcan, sin embargo, esta accin puede
causar otros problemas que pueden hacer aparecer nuevos sntomas indeseados.
Luego de los procesos de diagnosis y prognosis, se puede evaluar un plan de accin para resolver
el problema en cuestin, este proceso se conoce como tratamiento orientado a los posibles
problemas que no han sido descartados mediante la diagnosis. Se recomienda empezar por el
problema ms probable, y en este plan de accin se debe manipular slo una variable a la vez.
Manipular solo una variable a la vez permite encontrar una solucin a un problema especfico. Es
posible que cambiando diferentes variables simultneamente se solucione el problema, sin
embargo, encontrar precisamente qu cambio fue el que solucion el problema puede ser una
tarea engorrosa, lo que dificulta resolver fcilmente el problema si se presenta nuevamente en el
futuro.
Paso 5: Implementar el plan de accin, realizando cada paso cuidadosamente, mientras se
monitorea si los sntomas desaparecen o no.
Paso 6: Cada vez que se realicen cambios, es til asegurarse de recolectar informacin
nuevamente. Puede ser de utilidad realizar el mismo procedimiento usado en el paso 2, es decir,
consultar a los usuarios, y tomar mediciones con las herramientas de diagnstico, es decir, luego
de implementar el tratamiento, se debe volver a la etapa de semiosis.
Paso 7: Analizar mediante los resultados obtenidos en el paso 6 si el problema se ha solucionado.
De ser as, el proceso est terminado.
Paso 8: Si el problema no se ha resuelto, se debe volver a realizar un proceso de diagnosis y
prognosis, e implementar un nuevo tratamiento basado en el problema que es ms probable luego
del problema que se acaba de enfrentar. Volver al paso 4, cambiar una variable a la vez, y
continuar hasta que se resuelva el problema.

46

Un esquema lgico que representa lo anterior se muestra en la Figura 3-1:

Figura 3-1: Esquema troubleshooting

3.4.2 Modelo Troubleshooting por Capas

Adems de considerar el modelo de ocho pasos de Cisco para realizar el troubleshooting, tambin
se debe considerar un enfoque de anlisis por capas. Esto debido a que la falla puede presentarse
en cualquiera de las capas y una metodologa ordenada permitir ir descartando una por una,
hasta encontrar la causa del problema.
A continuacin se describen 3 aproximaciones distintas para realizar el troubleshooting por
capas, basndose en el modelo OSI, que son: bottom up (de abajo hacia arriba), top down (de
arriba hacia abajo) y divide and conquer (en el que se puede comenzar por cualquier capa).
3.4.2.1

Troubleshooting de abajo hacia arriba

Este enfoque de troubleshooting de abajo hacia arriba comienza por los componentes fsicos de la
red y va subiendo por las capas del modelo OSI. Si se concluye que todos los elementos
pertenecientes a una determinada capa funcionan correctamente, se procede a inspeccionar los
elementos asociados a la capa que sigue hacia arriba hasta que la(s) causa(s) del problema sea(n)
identificada(s).
El troubleshooting de abajo hacia arriba es un muy buen enfoque en situaciones en las que se
sospecha que el problema puede ser fsico. La gran mayora de los problemas en redes se
producen en las capas inferiores, por lo que este enfoque frecuentemente lleva a resultados
rpidos y eficientes. Cuando uno se enfrenta a un problema complejo de troubleshooting, este
enfoque es el ms utilizado. Esto ya que una vez que se asegura que los elementos asociados a
una determinada capa estn en buenas condiciones de operacin, se puede pasar a la capa
siguiente, y as sucesivamente hasta que se llega a la capa en que se encuentra el problema.

47

Lo malo del enfoque de abajo hacia arriba es que requiere que se revise cada equipo, interfaz, etc.
En otras palabras, independiente de la naturaleza del problema, se comienza con una revisin
exhaustiva de todos los elementos de cada capa, partiendo de la capa fsica hacia arriba. En cada
capa, la eleccin de por donde partir es arbitraria, y depender del troubleshooter. Una forma de
evitar el tener que empezar por la capa de ms abajo (capa fsica) es probar estas capas ms bajas
utilizando los comandos ping o traceroute/tracert. Un ping exitoso a travs de un link elimina
inmediatamente la posibilidad de un hardware daado (capa fsica) o problemas en la capa de
enlace de datos. La falla de los comandos ping o traceroute/tracert indica una posible falla en las
capas ms bajas.
Cuando se est realizando pruebas con herramientas como ping o traceroute, primero hay que
asegurarse que estas herramientas o los protocolos que utilizan sean soportadas por la red. En
otras palabras, en ciertos escenarios, de acuerdo con las polticas de administracin, los equipos
de la red eliminan o filtran los paquetes asociados con estas herramientas. En estas
circunstancias, la falla de estas aplicaciones puede llevar a confusin y a conclusiones
equivocadas. Es por esto que se debe estar seguro que estas aplicaciones son soportadas si se va a
hacer uso de ellas para realizar pruebas.
3.4.2.2

Troubleshooting de arriba hacia abajo

Tal como lo dice su nombre, el enfoque de arriba hacia abajo implica comenzar desde la capa de
aplicacin, bajando hacia las capas inferiores una por una hasta detectar el problema. Si una capa
no est funcionando correctamente, se inspecciona la capa debajo de ella. Cuando uno sabe que
una capa no est en buenas condiciones de operacin y se descubre que la capa inferior funciona
correctamente, se puede concluir que el problema se encuentra en la capa que est sobre la que
funciona correctamente. Luego de descubrir que capa el la ms baja que presenta problemas, se
puede comenzar a buscarla casa del problema dentro de esa capa.
Tpicamente se escoge el enfoque de arriba hacia abajo cuando existen razones para creer que el
problema se encuentra en la capa de aplicacin o alguna otra de las capas superiores.
Experiencias pasadas, nuevas instalaciones de software, cambios en la interfaz de usuario, o
nuevas propiedades de seguridad son razones comunes para creer que el problema est en la capa
de aplicacin o al menos en las capas superiores del modelo OSI. Este enfoque es ms utilizado
para problemas que son experimentados por una o por pocas personas, esto ya que los problemas
en las capas ms bajas (o sea, en la infraestructura de la red) usualmente afectan a ms de una
persona.
Generalmente este esquema se utiliza para los casos ms simples. La desventaja que tiene la
seleccin de este enfoque es que si el problema resulta ser ms complejo que lo que inicialmente
se pensaba, o si se origina en las capas ms bajas (fsica, enlace o red), se habr gastado mucho
tiempo y esfuerzo examinando las capas superiores. Adems de esto, una persona experta en
temas de internetworking no necesariamente posee el conocimiento para diagnosticar
correctamente problemas relativos a la capa de aplicacin.

48

3.4.2.3

Divide-and-Conquer Troubleshooting

Este enfoque de troubleshooting, a diferencia de los dos enfoques anteriores, no siempre

comienza en una determinada capa. Cuando se utiliza este enfoque, se selecciona una capa y se
revisa su funcionamiento. Basndose en el resultado de esto, se puede continuar en cualquier
direccin (hacia arriba o hacia abajo) a partir de la capa de inicio. Si una capa se encuentra
funcionando correctamente, se inspecciona la capa superior. Si la capa no funciona
correctamente, se inspecciona la capa inferior. Luego, cuando se encuentra una capa que funciona
mal pero su capa inferior funciona correctamente, entonces se ha encontrado la capa en la que se
encuentra el problema.
La capa a partir de la cual se comienza a buscar el problema, se escoger en base a la experiencia
de la persona que realiza el troubleshooting y en base a los sntomas que se logren recopilar del
problema. Por ejemplo, si un determinado usuario reporta que tiene problemas con una pgina
web en particular, pero no con otras pginas, se puede decidir que no es necesario comenzar el
troubleshooting en las capas fsica, de enlace o de red. Sin embargo, si muchos usuarios reportan
que tienen problemas accediendo a todos los recursos dela red, se podra empezar en la capa de
red y luego proceder dependiendo del funcionamiento de esta capa.
3.4.2.4

Seleccin del Enfoque Adecuado

La seleccin adecuada del enfoque a utilizar permite resolver los problemas de una forma ms
rpida. Para seleccionar el enfoque adecuado se debe hacer lo siguiente:
1. Determinar el alcance del problema.
2. Aplicarla experiencia.
3. Analizar los sntomas.
Determinar el alcance del problema significa seleccionar el enfoque a utilizar basndose en la
complejidad percibida del problema. Para problemas complejos tpicamente funciona mejor el
enfoque de abajo hacia arriba. Para problemas simples es generalmente mejor el enfoque de
arriba hacia abajo. El uso del enfoque de abajo hacia arriba para problemas simples puede ser
muy ineficiente y tomar mucho tiempo (ya que se debe pasar por muchas capas para llegar al
problema). Tpicamente cuando un usuario reporta un problema, se debe utilizar el enfoque de
arriba hacia abajo porque lo ms probable es que el problema est relacionado con la aplicacin.
En el caso en que los sntomas provengan de la red, es recomendable utilizar el enfoque de abajo
hacia arriba.
Aplicar la experiencia se refiere a que si se ha realizado troubleshooting previamente para un
problema en particular (o uno similar), puede que se conozca una forma de acortar el proceso. Si
se posee poca experiencia lo ms probable es que se implemente un enfoque de abajo hacia arriba
sin importar las circunstancias. Sin embargo, si se posee experiencia en troubleshooting, se puede
ahorrar tiempo utilizando el enfoque divide-and-conquer y comenzando en una capa intermedia.
49

Analizar los sntomas permite tener una mejor probabilidad de resolver el problema si se conoce
ms acerca de este. A veces se puede corregir un problema inmediatamente con un breve anlisis
de los sntomas y su posterior asociacin con una causa.

3.5 Metodologa para el desarrollo de pruebas

En este trabajo se realiz una recoleccin de datos asociados al rendimiento de ciertas tecnologas
de acceso, en un ambiente controlado, es decir en laboratorio.
Para comprender el procedimiento de resolucin de fallas, que es el foco de esta memoria,
primero se procede a estudiar tanto terica, como prcticamente una tecnologa tradicional
ampliamente usada, Ethernet, donde ya existen documentos de troubleshooting. Lo primero fue
validar estos documentos mediante pruebas de laboratorio con el fin de experimentar el proceso
de hacer troubleshooting.
Cisco posee una gran cantidad de documentacin sobre este tema. La tecnologa Ethernet es
formalmente conocida como el estndar 802.3 de la IEEE. Como ya se ha mencionado antes, esta
memoria est ligada al trabajo de Gonzalo Daz en troubleshooting para tecnologas de acceso
emergentes. Particularmente se realizaron en conjunto las pruebas de validacin de los
documentos de troubleshooting para Ethernet.
Bsicamente, la idea de las pruebas a realizar es la misma independiente de la tecnologa.
Primero, se deben montar pequeos sistemas, enlaces, o maquetas que permitan realizar un
proceso de monitoreo del rendimiento del sistema en cuestin. Este punto es fundamental, ya que
para realizar este monitoreo se debe tener la instrumentacin adecuada, tanto en hardware como
en software.
Dentro de esta lnea se encuentra la memoria de Andrs Bobadilla Diseo e Implementacin de
un Sistema de Instrumentacin para Telefona IP Econmico con Fines Docentes, que si bien
est enfocado a servicios de telefona IP, tambin tiene una gran utilidad en cualquier sistema de
red, en particular el software Bobareal, desarrollado en esta memoria.
Luego de montar un sistema, se debe ver el rendimiento del sistema en su condicin ptima, es
decir, un sistema sin trfico, sin cuellos de botella implementados manualmente, etc. Despus de
tener conocimiento de los parmetros de desempeo relevantes para el correcto funcionamiento
del sistema, se procede a realizar modificaciones en el mismo, con el fin de ver que sntomas se
presentan a partir de las modificaciones realizadas.
Estos problemas son documentados en una primera instancia, dado que la solucin a ellos es
precisamente realizar inversamente el cambio que se hizo en un principio, luego, gracias a esta
base de datos, se puede construir un documento de troubleshooting propiamente tal.
50

Despus de aplicar este modelo a Ethernet, se procede a realizar el mismo proceso para otras
tecnologas en particular, para ADSL, que es la tecnologa clave dentro de este trabajo.
Las pruebas son orientadas hacia servicios que se pueden montar sobre las distintas plataformas,
por ejemplo troncales que lleven datos y voz, con distinta prioridad para cada servicio. Debido a
esto, algunas pruebas fundamentales corresponden a pruebas de throughput, ya que con esto se
puede evaluar si es posible tener un servicio que ofrezca un cierto ancho de banda de datos
adems de un cierto nmero de lneas telefnicas. Otra prueba importante es la prueba de retardo
de paquetes, debido a la gran influencia que tiene este parmetro en conversaciones telefnicas o
servicios en tiempo real. El jitter tambin es muy importante dentro de esta lnea.

51

Captulo 4:

Resultados

En este captulo se presentan los resultados obtenidos a partir de la aplicacin de las

metodologas descritas en el captulo anterior. En particular, se desarrolla cada uno de los puntos
presentados en la estructura de pasos que all se plante. El anlisis de las tecnologas se
encuentra presente en el captulo de antecedentes por lo que no se incluye en esta captulo de
resultados.
Se presentan primero, los parmetros de desempeo; segundo, las herramientas de medicin de
dichos parmetros; tercero, los tipos de servicio y los requerimientos que cada uno tiene; cuarto y
ltimo, informacin relativa a fallas para las distintas tecnologas, los laboratorios montados, las
pruebas realizadas y los resultados obtenidos en cada caso; adems de los esquemas de
troubleshooting correspondientes.

4.1 Parmetros de Desempeo

4.1.1 Disponibilidad
Se refiere a si un enlace est efectivamente arriba. Para que esto suceda deben darse dos cosas:
primero, que exista conectividad, es decir, que haya una unin fsica entre los dos puntos que
conforman un enlace; y segundo, la funcionalidad, es decir, que los elementos que proporcionan
la unin fsica adems tengan un comportamiento adecuado y por lo tanto se establezca el enlace.

4.1.2 Throughput
Corresponde a la mxima tasa de transferencia de datos en la que no se pierde ningn paquete. A
veces se considera la mxima tasa de transferencia a la que se pierde menos del 1% de los
paquetes. Es por esto que es una buena medida de la capacidad de un canal de comunicaciones,
como por ejemplo de una conexin a Internet. Las mediciones se deben realizar sobre una
variedad de tamaos de paquetes.

4.1.3 Packet Loss o Prdida de Paquetes

La prdida de paquetes ocurre cuando uno o ms paquetes de datos que viajan a travs de una red
no logran llegar a su destino. Esto puede ser provocado por una serie de factores, los ms tpicos
son: degradacin de la seal sobre el medio fsico, enlaces sobresaturados, paquetes corruptos
descartados por nodos intermedios en la ruta y hardware defectuoso.

52

Los paquetes perdidos o descartados pueden provocar serios problemas de rendimiento y jitter en
videoconferencias y voz sobre IP, por dar algunos ejemplos. Algunos protocolos de transporte
como TCP proporcionan una entrega confiable de los paquetes, donde si eventualmente se pierde
un paquete el receptor puede solicitar una retransmisin o el emisor puede retransmitir si ha
pasado un tiempo determinado y an no recibe el acuse de recibo. A pesar de que TCP puede
garantizar la entrega de todos los paquetes a travs de una red con prdidas, stas provocan una
cada en el throughput de la conexin. Otros protocolos, como UDP, no proporcionan un
mecanismo de recuperacin de los paquetes perdidos y depender de la aplicacin determinar la
forma como esto se resuelve. Para determinar donde se producen las prdidas de paquetes en una
red generalmente se utiliza el comando traceroute o tracert.

4.1.4 Delay
Existen dos tipo de delay que se pueden medir. Estos son el one way delay y el round trip delay o
round trip time (RTT).
4.1.4.1

One way delay

Para la comunicacin entre una fuente y un destino se define el one way delay como el tiempo
que transcurre desde que la fuente enva el primer byte de datos hasta que el destino recibe el
ltimo byte de datos.
4.1.4.2

Round Trip Delay o Round Trip Time (RTT)

Para la comunicacin entre una fuente y un destino, y de vuelta a la fuente, corresponde al tiempo
que transcurre desde que es enviado el primer byte de datos desde el origen en direccin al
destino, hasta que regresa de vuelta al origen el ltimo byte da datos del paquete. Este parmetro
es significativo para aplicaciones interactivas donde la participacin desde ambos extremos es
similar, como por ejemplo VoIP, donde el RTT afecta directamente el throughput. Involucra los
retrasos en los nodos adems del tiempo de trnsito a travs de los enlaces.

4.1.5 Jitter
Lo que comnmente se conoce como jitter no es ms que la varianza en el delay con respecto a
una referencia (que puede ser el delay promedio o el delay mnimo). Puede ser causado por
congestin en la red, distintas rutas seguidas por los distintos paquetes y retransmisin debido a
prdidas de paquetes.

53

4.1.6 Latencia
Corresponde al retraso introducido cuando un equipo recibe un paquete, y antes de volver a
enviarlo a su destino primero es almacenado un momento en buffer, luego es analizado (para
saber donde debe ser enviado o si debe ser filtrado, etc.), y por ltimo es enviado en direccin a
su destino.

4.2 Herramientas de Medicin de los Parmetros

En esta seccin se presenta una descripcin de las herramientas utilizadas para medir los distintos
parmetros de desempeo. Cada una de ellas puede servir para medir uno o ms parmetros.

4.2.1 Iperf
Herramienta para medir el desempeo de una red. Funciona en base a un modelo cliente servidor,
en el que se inyecta trfico por el cliente en un enlace especificando la direccin IP de destino, y
ste es recibido por el servidor en el otro extremo para obtener los datos de dicho recorrido,
siendo esta informacin el ancho de banda disponible o estadsticas de paquetes perdidos,
retardos, tiempos RTT, entre otros. Su versatilidad radica en la interoperabilidad de sistemas
operativos para los cuales est diseado, es decir, est implementado para Windows y Linux, y el
cliente corriendo el Linux puede funcionar con el servidor ejecutado en Windows y de manera
inversa tambin.
Algunas de las opciones del software se mencionan a continuacin:
-s:
IPerf en modo servidor
-c <x.x.x.x>: IPerf en modo cliente conectndose a un servidor con la direccin IP x.x.x.x
-u:
Permite realizar un envo de trfico usando el protocolo UDP, esto permite ver la
prdida de paquetes asociada a una transmisin sin retransmisiones, si no se utiliza
esta opcin, IPerf trabaja en modo TCP por defecto.
-i <x>:
Permite generar reportes cada x segundos.
-b <x>:
Permite utilizar cierto ancho de banda donde x es la tasa de transmisin en bps, sin
embargo se puede agregar k o M para cambiar a kbps o Mbps si es necesario, esto
es sumamente til para congestionar un canal en modo UDP.
-p <x>:
Permite realizar la comunicacin en un puerto x determinado, lo que permite
realizar pruebas simultneas realizando multiplexin en capa 4.
-d:
Permite realizar una prueba dual, es decir Uplink/Downlink.
-l <x>:
Permite cambiar el tamao de paquetes, donde x = 22 permite tener frames de 64
Bytes y x=1458 permite enviar frames de 1500 Bytes, es decir si uno quiere enviar
frames de B bytes, se debe colocar -l (B-42).

54

4.2.2 InterWatch 95000

Corresponde a una plataforma modular para realizar pruebas de desempeo en redes. Proporciona
soporte para pruebas de Voz sobre IP (VoIP), Generalizad Multi Protocol Label Switching
(GMPLS/MPLS), Universal Mobile Telecomunications System (UMTS), Calidad de Servicio
(QoS), desempeo IP y tecnologas de acceso. Puede realizar operaciones en tiempo real y
anlisis que abarcan las siete capas del modelo OSI. Con esta herramienta se pueden realizar
mediciones de throughput y prdida de paquetes.

4.2.3 Ethereal
Corresponde a un sniffer y analizador de protocolos, diseado para ser utilizado en cualquier
computador, corriendo un sistema operativo Windows o Linux en principio y esta distribuido
bajo licencia GNU que lo hace gratuito y modificable siempre que las modificaciones hechas
sean compartidas con el resto del mundo.
Las capacidades de observacin dependen directamente de la o las tarjetas de red que se tengan,
permitiendo instrumentar en varias redes a la vez. Las capacidades de anlisis y estadsticas son
bastante poderosas, permitiendo obtener informacin de las capturas realizadas con anterioridad
desplegando grficos y datos adicionales en conjunto con las capturas.

4.2.4 Comando Ping

Entre los comandos includos en el Cisco IOS est el comando ping, que corresponde a una
herramienta sumamente poderosa de troubleshooting. Un ping bsicamente consiste en peticiones
ICMP, y si son exitosas, se genera una respuesta. Los mensajes ICMP son transportados en
datagramas IP; luego una respuesta ICMP verifica conectividad hasta la capa 3 del modelo OSI.
Adems, en el caso de existir conectividad, un ping entrega datos acerca del RTT (round trip
time).
En el caso de equipos Cisco, el comando ping se puede extender de manera de cambiar ciertos
parmetros en detalle, a continuacin se muestran estos parmetros.
Protoco:l El protocolo a probar.
Target address: El destino al que se quiere llegar.
Repeat count: Se puede extender el nmero de peticiones ICMP en el caso de que se sospeche
que el enlace falla intermitentemente.

55

Datagram size: El tamao del datagrama se puede aumentar si se sospecha que los paquetes estn
siendo descartados debido a latencia, o a fallas de fragmentacin, por ejemplo, se puede aumentar
el tamao a ms de 1500 bytes para forzar fragmentacin.
Timeout: El timeout se debe incrementar si uno sospecha que la falla se debe a respuestas
demasiado lentas en vez de que se estn descartando paquetes.
Extended commands: Se debe colocar yes para acceder a los siguientes commandos extendidos.
Si se responde no, no se accede a dichos comandos.
Source address: Esta debe ser la direccin IP de alguna de las interfaces del equipo.
Type of service: Se relaciona con las opciones referidas al RFC 791 TOS. Tpicamente se deja en
el valor por defecto que es 0.
Set DF bit in IP header?: Setear el bit DF impide la fragmentacin del paquete en la ruta a pesar
de que supere el MTU del medio.
Data pattern: [0_ABCD]: Se puede variar, para realizar pruebas sobre distintos medios, por
ejemplo se puede colocar.
Loose, Strict, Record, Timestamp, Verbose, [none]: Son opciones para el header. Se pueden
incluir demostraciones de Record y Verbose.
Sweep range of sizes [n]: Esta opcin es til para probar si paquetes largos estn siendo
descartados o procesados muy lento, o bien si est ocurriendo un error de fragmentacin.

4.2.5 Comando Traceroute

Al igual que el comando ping, tenemos el comando traceroute, que entrega informacin de los
saltos o hops, que hay en una ruta hacia un destino, esto se realiza usando ICMP manipulando
el TTL (Time to Live) con que se envan los datagramas, debido a que en cada salto se baja en
uno este contador, entonces al llegar una notificacin de que un paquete tiene TTL nulo, significa
que se pas por un salto (router). Al igual que el comando ping, existen comandos extendidos,
que son similares a los comandos extendidos de un ping.

56

4.2.6 IP SLA
Aplicacin de Cisco que permite inyectar trafico en diferentes formatos y luego tener estadsticas
de estos datos. Este trfico se realiza mediante routers colocados en los extremos del enlace que
se quiere probar. En particular se est usando para simular trfico de voz por el enlace de
pruebas.
Estas pruebas permiten utilizar datagramas que van con informacin de voz que consideran cdec
de audio, tamao de paquetes, cantidad de paquetes y duracin de la llamada. Luego se puede
obtener informacin como MOS, paquet loss entre otros datos de la prueba. Se puede generar
todo tipo de variantes en las simulaciones y en particular, se pueden generar todas las
conversaciones que uno quiera.
Adems permite realizar estas pruebas en diferentes VLANs, donde el requerimiento es que
ambos extremos tengan conectividad IP con el otro extremo de la prueba y viceversa. Para
realizar pruebas de voz se escogi el cdec G.711 ley u, usando 100 paquetes de 160 Bytes. En el
laboratorio de pruebas de Telmex se tuvo acceso a routers Cisco que permitan usar esta
aplicacin, por lo que se eligi sobre todo para tener estadsticas relevantes para el servicio de
telefona.

4.3 Servicios y Requerimientos

Aqu se entrega una descripcin y caracterizacin de las principales aplicaciones y servicios que
son soportados por Internet, para identificar los parmetros de desempeo que son ms
importantes y crticos para cada uno de los servicios o aplicaciones, lo que es muy til para el
troubleshooting. Se cubren principalmente servicios de voz, video y datos.

4.3.1 Acceso a Internet de Mejor Esfuerzo

Corresponde al servicio ms bsico. Este tipo de servicio no requiere ningn tipo de garanta de
calidad de servicio ni de priorizacin de trfico. Lo ms importante para este tipo de servicio es la
tasa de transferencia efectiva, lo que permitir por ejemplo, una navegacin ms rpida a travs
de sitios web. Generalmente la mayor cantidad de trfico es en el sentido descendente, es decir,
desde la red hacia el usuario, por lo que las tecnologas que permiten canales asimtricos se
ajustan mejor a los requerimientos de este tipo de servicio.

4.3.2 Servicios de Datos Diferenciados

En esta categora se incluyen servicios que son netamente de datos, pero que requieren una mayor
prioridad que el trfico de datos convencional. Dentro de esta categora se encuentran por
ejemplo, los juegos en lnea, que se ven beneficiados por las capacidades de calidad de servicio.
57

Para este tipo de servicios la tasa de transferencia no resulta tan crtica, a diferencia del retardo
que si es bastante crtico para este tipo de aplicaciones (lo que para el caso de un juego en lnea se
traduce en tiempo de respuesta desde que se ordena realizar una accin hasta que sta
efectivamente se realiza). Tiempos de retardo del orden de los 20 ms son suficientes para este
tipo de trfico.

4.3.3 Circuitos o Lneas para Voz o Telefona

Existen tecnologas de acceso que adems del servicio de transporte de datos, ofrecen una o
varias lneas para el trfico de voz. En el caso en que estas requieran niveles de servicio similares
a los del servicio POTS tradicional, se requiere de una tecnologa que entregue soporte para
asegurar ciertos niveles de QoS, en particular niveles bajos de retardo y jitter, que son los dos
parmetros de desempeo ms importantes para este tipo de servicio.

4.3.4 Servicios de Video Bajo Demanda (VoD)

Esto consiste en la transmisin de informacin de video sobre redes de mejor esfuerzo hasta
una estacin terminal la que lo almacena en un cach local y lo va reproduciendo utilizando
alguna aplicacin a medida que se va descargando el archivo. El parmetro de mayor importancia
para este tipo de aplicaciones es la tasa de transferencia (en particular, esta debe ser mayor que la
tasa a la que se reproduce el video).
En la Tabla 4-1 se muestran las caractersticas de ancho de banda y tipos de servicio requeridas
por los servicios descritos en la seccin anterior.

Servicio/Aplicacin

Ancho de banda
tpico (descendente)

Ancho de banda
tpico (ascendente)

Acceso a Internet de
alta velocidad

512 Kbps a 3 Mbps

256 Kbps a 1 Mbps

Parmetros ms
relevantes
Throughput

Juegos en lnea

64 Kbps a 512 Kbps

64 Kbps a 512 Kbps

Muy bajo retardo

y bajo jitter

Telefona

64 Kbps

64 Kbps

Bajo retardo y
bajo jitter

Video bajo demanda 300 Kbps a 750 Kbps

N/A

Bajo retardo

Tabla 4-1: Ancho de banda y parmetros ms relevantes requeridos por las aplicaciones

58

4.4 Tcnicas de Troubleshooting para TCP/IP

4.4.1 Aislamiento de problemas en redes TCP/IP
La identificacin de un problema es la fase inicial para resolverlo en redes que utilizan los
protocolos TCP/IP. Considrese un escenario donde un equipo local no tiene acceso a un equipo
remoto en una red TCP/IP. Puede haber diversas razones para que esto suceda, tales como
direcciones incorrectas, mscaras de sub-red no adecuadas, o una direccin errnea del default
gateway en el equipo local. Adems, pueden existir problemas de conectividad entre el equipo
local y el equipo remoto, como por ejemplo, la falta de rutas estticas en un router, e incluso
problemas en la capa 1 o 2 del modelo OSI.
Para aislar el problema de forma sistemtica se puede seguir el procedimiento descrito en la
Figura 4-1, mediante este procedimiento, se puede encontrar de manera lgica rpida y eficiente
un problema, descartando inicialmente los problemas ms bsicos o bien los ms probables.
La Figura 4-1 muestra pasos especficos a seguir para encontrar la causa del problema de
conectividad entre el equipo local y el equipo remoto. Estos pasos pueden ser seguidos
secuencialmente para aislar el problema, segn el siguiente listado1:
1. Revisar la configuracin del equipo local y revisar las direcciones IP asignadas al equipo,
la mscara de sub red, y el default gateway. Especificar los valores correctos para estas
direcciones especficas.
2. Revisar la conectividad entre el equipo local y el router ms cercano a ste. Para sto, use
el comando ping (respuesta de eco en ICMP) y el comando trace para comprobar
conectividad al router vecino y luego a los routers siguientes de manera equivalente.
Adems, use la direccin IP para detectar problemas con el servidor DNS.
3. Usar comandos show en el router para determinar su configuracin y su estado en el caso
de que los pings no estn respondiendo.
4. Revisar la tabla de rutas en el router usando el comando show ip route.
5. Revisar el cach fast-switching mediante el uso del commando show ip cache.
Luego de revisar el estado y la configuracin de los routers, revisar la configuracin del equipo
remoto. Para el equipo remoto, revise los valores correctos en la direccin IP, la mscara de subred y la direccin del default gateway.
1

Los comandos listados estn en base al software de equipos IOS del proveedor Cisco

59

Figura 4-1: Esquema de troubleshooting para redes TCP/IP

60

4.4.2 Sntomas y Problemas en TCP/IP

En esta seccin se consideran diversos problemas relacionados con redes TCP/IP. Considrese
un escenario en una red TCP/IP donde los equipos A y B son capaces de acceder a un equipo X
remoto, sin embargo, los equipos D y E no pueden conectarse al equipo X. Pueden haber
mltiples razones para este problema, como por ejemplo, una lista de acceso mal configurada.
La Tabla 4-2 muestra varios sntomas y los posibles problemas asociados a cada uno de ellos que
pueden crear problemas de conectividad en redes TCP/IP. Luego basados en estos problemas, se
puede realizar un plan de accin para resolverlos. Mediante este procedimiento se puede
identificar y aislar los problemas y luego implementar un plan de accin adecuado.

Sntomas

Posibles problemas

Un equipo no puede acceder a otras

redes a travs de un router.

1. Lista de acceso mal configurada.

2. No hay un default gateway especificado
en el host local.
3. Red discontinua debido a falla en un
enlace capa 1 o 2 del modelo OSI.

Un equipo no puede acceder a

equipos en otras redes a travs de
un router.

1. Mscara de sub red incorrecta en el

equipo local.
2. El router entre los equipos no est en
funcionamiento.
3. No hay un default gateway especificado
en el equipo local.

Algunos servicios de red estn

disponibles mientras que otros no lo
estn.

1. La lista de acceso extendida est

configurada incorrectamente.

El router recibe paquetes y

actualizaciones de rutas duplicadas.

2. Un bridge o un repetidor est

funcionando en paralelo con el router.

Algunos protocolos estn siendo

ruteados pero otros no.
El router deja de funcionar cuando se
usa redistribucin.

1. La lista de acceso extendida est

configurada incorrectamente.
1. Problema con la distancia administrativa.
2. Ausencia de redistribucin o comando de
mtrica por defecto.

61

Tanto el router como el equipo no se

pueden comunicar con ciertas partes
de la red.

1. Discordancia entre las mscaras de sub

red del equipo y del router.
2. El default gateway no est especificado.
3. La lista de acceso est mal configurada.

Los usuarios pueden acceder a ciertos

equipos en la red pero no pueden
acceder a otros.

1. El default gateway no est especificado

en los equipos remotos.
2. La lista de acceso est mal configurada.
3. La mscara de sub red o las direcciones
del equipo o del router estn mal
configuradas.

Los usuarios no pueden conectarse a

las redes cuando una ruta redundante
est inactiva.

1. El protocolo de ruteo no ha convergido.

2. La lista de acceso o los filtros de ruteo
estn configurados incorrectamente.
3. Red discontinuada debido a un enlace
roto.

Tabla 4-2: Sntomas y problemas en TCP/IP

62

En la siguiente tabla se muestran los diversos problemas sealados anteriormente y un plan de

accin asociado a cada uno de ellos destinado a corregir cada problema2.

Problema

Plan de Accin

Lista de acceso o filtros mal

configurados.

1. Use los comandos ping o trace para

aislar el router que tiene la lista de acceso
mal configurada.
2. Use el comando show ip route para
revisar la tabla de ruteo.
3. Revisar el intercambio de protocolos
usando comandos como debug ip rip en
el caso de que se estn usando rutas
dinmicas.
4. Deshabilite la lista de acceso usando el
commando no ip access-group.
5. Realizar un debug de la lista de acceso.

El router entre los equipos no est

funcionando.

1. Use el comando ping para identificar y

aislar el rea problemtica en la red. Esta
aplicacin del comando ping se denomina
pinging outward.
2. Revisar las configuraciones en el router
y corregirlas.
3. Revisar problemas en las LAN
intermedias o en la WAN.

El default gateway no est

especificado en el equipo local o
en el equipo remoto.

1. Revisar la tabla de ruteo del equipo

mediante el comando netstat rn.
2. Si no hay un default gateway
especificado, use el comando route add
default address 1. En este comando,
address 1 es la direccin IP del default
gateway.
3. Si el default gateway ya se encuentra
especificado, cargar el equipo con el
default gateway, especificando la direccin
IP del default gateway en el equipo en la
siguiente ruta de archivos:
files/etc/defaultrouter.

Los comandos siguientes estn basados en el software IOS del proveedor Cisco

63

La mscara de sub red esta mal

configurada en el equipo local, en el
equipo remoto o en router.

1. Revisar los archivos del equipo,

files/etc/netmasks y /etc/re.local.
2. Revisar la configuracin del router
usando el comando show ip interface.
3. Revisar la configuracin del equipo
usando el comando ipconfig a.

Red discontinua debido a mal diseo

o a falla de enlace.

1. Revisar las rutas usando el comando

show ip route.
2. Use el comando ping y/o trace para
determinar dnde se detiene o congestiona
el trfico.
3. Asignar una direccin secundaria si un
camino alternativo est disponible.
3. Arregle el enlace fallado en la red.
4. Vuelva a rehacer la topologa anterior
y/o reasignar las direcciones.

El router no ha convergido.

1. Revise la configuracin y/o estado del

router mediante el show ip route.

Tabla 4-3: Problemas y Acciones a tomar en redes TCP/IP

Otro problema con las redes TCP/IP es que un router empiece a recibir actualizaciones de ruteas
por diferentes interfaces, lo que produce una prdida de conectividad y un bajo rendimiento de la
red. Esto ocurre porque un bridge o un repetidor se puede haber colocado en paralelo hacia el
router, lo que hace que el router vea a otros routers por mltiples interfaces. Para enfrentar estos
problemas, use el comando show ip route para identificar las rutas para cada interfaz. Adems, se
puede usar el comando debug ip para examinar las actualizaciones de rutas recibidas por el
router.

64

4.5 Troubleshooting en Ambientes de LAN Switching

A continuacin se presentan soluciones para los problemas ms comunes que ocurren en este tipo
de ambientes. En particular, se analizan los siguientes temas:

Troubleshooting para Problemas de Conectividad de Puertas

Troubleshooting Autonegociacin Ethernet 10/100-Mb Half-/Full-Duplex
ISL Trunking en Switches de las familias Catalyst 5000, 6000
Configuracin de EtherChannel Switch-a-Switch en Switches Catalyst 4000/5000/6000
Utilizacin de PortFast y otros comandos para solucionar problemas de conectividad de
estaciones terminales en el arranque.
Troubleshooting para Protocolo Spanning Tree

4.5.1 Troubleshooting para Problemas de Conectividad de las Puertas

Si una puerta no funciona, nada funciona, es por esto que es tan importante esta etapa del
troubleshooting. Algunas puertas tienen especial importancia debido a su ubicacin en la red y
por la cantidad de trfico que pasa a travs de ellas. Entre ellas se encuentran las que estn
conectadas a otros switches, routers o servidores. Puede que el troubleshooting en estos casos sea
ms complicado debido a que aprovechan propiedades especiales como Trunking y Etherchannel.
El resto de las puertas son tambin muy importantes ya que se conectan a los usuarios de la red.
Hay muchos factores que pueden producir fallas en una puerta: Problemas de Hardware, de
Configuracin, y de Trfico.
4.5.1.1 Problemas de Hardware
Para obtener una buena funcionalidad en un enlace se requieren dos puertas funcionando unidas
por un cable en buen estado (y del tipo correcto). A continuacin se mencionarn algunas formas
de revisar si la capa 1 est arriba o no.
Revisar el estado de las dos puertas involucradas, y asegrese que ninguna de ellas est en estado
shutdown. Las puertas pueden estar en estado shutdown debido a que el administrador las dej
as en forma manual, o el software lo hizo debido a problemas de configuracin. El link no
funcionar correctamente a menos que ambas puertas estn arriba (enabled). Cuando se unen
dos puertas en estado enable con un cable, ambas puertas deberan mostrar un led en color verde
luego de algunos segundos. Adems, el estado dela puerta debiera decir connected en la CLI.
Si en estas condiciones no se tiene el link arriba, hay tres cosas que pueden estar fallando:
cualquiera de las dos puertas o el cable que las une.

65

Se deben buscar conexiones sueltas. A veces un cable parece estar conectado pero en realidad no
lo est. Reinserte ambos cables. Tambin se deben revisar los pins de los conectores, los que
pueden estar sucios o quebrados. Tambin puede ser que el cable est conectado en la puerta
equivocada, lo que a menudo resuelve el problema. Asegrese que ambos extremos del cable
estn conectados donde corresponde. La luz verde en la puerta no garantiza que el cable est
funcionando correctamente. Puede que funcione a un nivel marginal, pero presente un alto
porcentaje de errores en los paquetes.
Para determinar si el problema es el cable, intercmbielo con otro que est bueno y que sea del
tipo correcto. Si el cable es demasiado largo (a travs de un extenso territorio y bajo tierra por
ejemplo), sera lo ideal tener una buena herramienta para probar el cable. En caso de que esto no
sea as, intente lo siguiente:
- Probar con distintas puertas para ver si suben utilizando el mismo cable.
- Poner los switches uno cerca del otro temporalmente para probar con un buen cable.
4.5.1.2 Problemas de Configuracin
Si una puerta tiene el led en naranjo, significa que el software ha bajado la puerta ya sea a travs
de la interfaz de usuario o por procesos internos. Se debe chequear el estado de las puertas para
asegurarse que el administrador no ha bajado las puertas en forma manual. El link no estar arriba
hasta que ambas puertas estn arriba.
Algunos switches bajan las puertas cuando detectan un error. Al revisar el estado de la puerta se
ver errDisable. En estos casos se debe arreglar el problema de configuracin y luego subir la
puerta en forma manual. Algunas de las causas de este tipo de error se enumeran a continuacin:
Mala Configuracin de EtherChannel: Si solo un lado est configurado como EtherChannel se
bloquear la puerta del lado en que est configurado el EtherChannel. Si se trata de configurar
EtherChannel pero las puertas involucradas no tienen los mismos parmetros configurados
(velocidad, duplex, trunking, etc.) tambin se puede llegar al estado errDisable.
No concuerdan los modos Duplex: Si una puerta recibe muchas late collisions, esto
generalmente indica un problema de duplex. El lado full cree que puede mandar en cualquier
momento, pero el lado half espera los paquetes solo en determinados momentos.
Problemas con BPDUs: Una puerta que utiliza PortFast debiera estar conectada a una estacin
terminal, y no a equipos que generan paquetes de Spanning Tree (BPDUs). Si el switch ve una
BPDU entrando por una puerta que tiene habilitado PortFast, pondr la puerta en estado
errDisable.
Deteccin de Link Unidireccional (UDLD por la sigla en ingls): Este es un protocolo que
descubre si la comunicacin en un enlace es slo en una direccin. Un cable defectuoso podra
66

provocar este tipo de comunicacin en un solo sentido. UDLD puede ser configurado para poner
una puerta en estado errDisable si detecta un enlace en una sola direccin.
No concuerdan las VLANs nativas: Si no est en modo trunking, una puerta pertenece solo a
una VLAN, pero con modo trunking una puerta puede manejar trfico perteneciente a muchas
VLANs. La puerta aun recordar la VLAN a la que perteneca antes de pasar al modo trunking, la
que ser la VLAN nativa. Si esta VLAN nativa no concuerda en ambos lados, las puertas pasarn
al estado errDisable.
Otros: Cualquier proceso dentro del switch en el que se detecte un problema con una puerta,
puede poner la puerta en estado errDisable.
4.5.1.3 Problemas de Trfico
La mayora de los switches tienen una forma de hacer seguimiento a los paquetes que entran y
salen de una puerta. Los comandos que entregan este tipo de informacin en switches Catalyst
4000/5000/6000 son show port y show mac. Se puede ver que cantidad de datos est siendo
transmitida y recibida en una puerta. Otros campos muestran cuantos frames con errores llegan a
una puerta. Si hay una gran cantidad de errores de FCS o late collisions, esto puede indicar un
error de duplex (uno est en half y el otro lado est en full). Otras posibles causas para este tipo
de errores pueden ser las NIC (Network Interface Card) o en los cables. Si se pierde una gran
cantidad de frames es seal de que el segmento posee demasiado trfico, y el switch no es capaz
de enviar la cantidad de trfico suficiente para vaciar sus buffers. Debe considerarse cambiar
algunos equipos a otro segmento.
4.5.1.4 Falla de Hardware del Switch
Si ha intentado todo lo que se le ocurre para reparar la falla y sta an persiste, puede que exista
un problema de hardware. A veces las puertas se daan por descargas electrostticas, y puede que
no haya rastro de esto. Revise el power on self test (POST) para ver si se indican fallas en alguna
parte del switch.
Si se aprecia un comportamiento extrao, puede que se trate de una falla de hardware, pero
podra tratarse tambin de una falla de software. Generalmente es ms fcil cargar nuevamente el
software que conseguir un nuevo hardware, por lo que se recomienda trabajar con el software
primero.
Puede que el sistema operativo tenga un bug, y cargando un sistema operativo ms nuevo podra
solucionar esto. Tambin cargando la misma versin del sistema operativo nuevamente podra
solucionar algunos problemas. Antes de realizar cambios en el hardware del switch se
recomienda intentar lo siguiente:

67

Resetear el switch: A veces esto elimina los problemas.

Revisar el software del switch: Si es una instalacin nueva, debe recordarse que algunos
componentes pueden funcionar solo con algunas versiones del software.
Si se tiene certeza acerca del problema de hardware, reemplace el componente defectuoso.

4.5.2 Troubleshooting para Autonegociacin 10/100-Mb Half-/Full-Duplex

La Autonegociacin es una funcin opcional del estndar IEEE 802.3u que permite que los
equipos intercambien informacin en forma automtica acerca de la velocidad y el modo duplex.
La Autonegociacin apunta a puertas que se encuentran en lugares en que usuarios o equipos se
conectan en forma temporal a la red. No debe ser utilizada esta funcin en puertas que soportan
infraestructura de la red o sistemas terminales permanentes como impresoras o servidores. En
estos casos es preferible configurar segn el comportamiento deseado en vez de permitir que se
negocie. En caso que las puertas no puedan operar de acuerdo con como fueron configuradas,
deben dejar de pasar el trfico. Un enlace que no funciona es ms fcil de detectar que uno que si
funciona pero que no lo hace ni a la velocidad ni en el modo deseado.
Una de las causas ms comunes de problemas de desempeo en enlaces Ethernet de 10/100 Mb
es que se tiene una puerta operando en modo half-duplex mientras que la otra opera en modo fullduplex. Esto puede ocurrir cuando uno de los switches es reseteado y el proceso de
autonegociacin no resulta en ambas puertas con la misma configuracin.
Tambin sucede cuando los usuarios cambian la configuracin en un lado del enlace pero olvidan
hacerlo en el otro lado. En la Tabla 4-4 se presentan posibles problemas relacionados con la
Autonegociacin y sus soluciones, seguida por un esquema de troubleshoting para este tipo de
problemas, el cual se ve en la Figura 4-2:

Posible Problema

Solucin

El actual estado
del enlace fue
autonegociado?

1. Use el comando show port mod_num/port_num o show

int status para determinar el actual estado del enlace.
Si ambas puertas tienen el prefijo "-a" en los campos
del duplex y la velocidad, la autonegociacin fue exitosa.

La autonegociacin es
soportada?

1. Use el comando show port capabilities o show int

capabilities para verificar que el switch soporte la
autonegociacin.

68

La autonegociacin no
est funcionando
en los switches
Catalyst

1. Utilice el comando set port speed para configurar la

autonegociacin. O en el modo conf en la interfaz
correspondiente utilice los comandos speed y duplex.
2. Intntelo con distintas interfaces
3. Intntelo con distintos cables
4. Apague y prenda los equipos

Tabla 4-4: Problemas y soluciones para autonegociacin de velocidad y modo duplex

Figura 4-2: Esquema troubleshooting para autonegociacin 10/100 Mb y Half/Full Duplex.

69

4.5.3 Troubleshooting ISL Trunking en Switches Catalyst 5000 y 6000

Las puertas troncales permiten conexiones entre switches que transportan datos pertenecientes a
ms de una VLAN. Sin trunking un enlace entre dos switches puede transportar informacin de
una sola VLAN. A continuacin se muestra un esquema de troubleshooting y una tabla en la que
se presentan posibles problemas relacionados con el Trunking y sus posibles soluciones:

Posible Problema
Estn las puertas en modo
trunking?

Solucin
1. Use el comando show trunk o sh run pare determinar si
las puertas estn en modo trunking.

Es soportado el modo
trunking?

1. Utilice el comando show port capabilities o sh int

capabilities para verificar si el modo trunking es soportado por
el switch.

Las puertas no estn en

modo trunking

1. Use el comando set trunk para configurar la puerta en modo

trunking. O el comando switchport mode trunk.

Verifique que el nombre

del dominio VTP ha
sido configurado

1. Use el comando show vtp domain o sh vtp status para

determinar si ha sido o no configurado.
Todos los switches en un mismo dominio deben tener el mismo
nombre.

El nombre del dominio

VTP no est configurado

1. Use el comando vtp o vtp domain.

Ha ocurrido un problema
de password en el
dominio VTP

1. Use el comando show vtp domain o sh vtp status para

determinar si existe el password. Todos los switches deben tener
el mismo password.

Tabla 4-5: Problemas y soluciones para Trunking

70

Figura 4-3: Esquema troubleshooting para modo Trunking

En DTP (Dymanic Trunking Protocol) el modo trunking por defecto es Auto. El DTP es el
reemplazo del Dynamic ISL. Los distintos estados que existen en DTP son los siguientes:

71

Auto: La puerta escucha los frames DTP del switch vecino. Si este indica que quisiera ser una
troncal, o si es una troncal, luego el estado Auto crea la troncal con el switch vecino. En este
estado depende solo del vecino si se crea o no la troncal.
Desirable: Se habla DTP con el switch vecino. Se le comunica al switch vecino que se es capaz
de ser una troncal y que le gustar que el switch vecino tambin lo fuera.
On: Se habla DTP con el switch vecino. Automticamente se habilita el ISL trunking en su
puerta sin importar el estado del switch vecino. Permanece como un troncal ISL a menos que
reciba un paquete ISL que deshabilite explcitamente la troncal ISL.
Nonegotiate: No se habla DTP al switch vecino. Automticamente se habilita el trunking ISL en
su puerta sin importar el estado del switch vecino.
Off: No se permite ISL en esta puerta, sin importar el modo DTP que est configurado en el otro
switch.
En un enlace troncal, es recomendable configurar el modo trunking deseado en la puerta ms
cercana al ncleo de la red, y modo auto trunking en el otro lado.
4.5.3.1 Posibles combinaciones de configuraciones DTP
En la Tabla 4-6 se pueden ver las 15 posibles combinaciones de modos DTP y se indica si van a
resultar en una troncal bidireccional activa o no. Aunque es tericamente posible que un enlace
sea una troncal en una direccin y no en la otra, no es recomendado.
Modo DTP Switch 1
Auto
Desirable
On
Nonegotiate
Off
Desirable
On
Nonegotiate
Off
On
Nonegotiate
Off
Nonegotiate
Off
Off

Modo DTP Switch 2

Auto
Auto
Auto
Auto
Auto
Desirable
Desirable
Desirable
Desirable
On
On
On
Nonegotiate
Nonegotiate
Off

Estado Troncal ISL

Not-trunking
Trunking
Trunking
Not-trunking
Not-trunking
Trunking
Not-trunking
Not-trunking
Not-trunking
Trunking
Trunking
Not-trunking
Trunking
Not-trunking
Not-trunking

Tabla 4-6: Combinaciones DTP y estado del enlace resultante

72

4.5.4 Configuracin de EtherChannel en Switches Catalyst 4000/5000/6000

EtherChannel permite que varios enlaces fsicos (Fast Ethernet o Gigabit Ethernet) se combinen
en un solo enlace lgico. Esto permite que se distribuya el trfico en todos los enlaces fsicos y
entrega redundancia en caso de que uno de los enlaces falle. EtherChannel puede ser configurado
en forma manual usando la CLI o puede ser configurado en forma automtica mediante una
negociacin con el otro lado usando PagP (Port Agregation Protocol). Es recomendable utilizar
PagP ya que la configuracin manual puede causar problemas.
La Tabla 4-7 muestra todos los posibles escenarios que se presentan con distintas combinaciones
del Channel Mode en los switches: Algunas de estas combinaciones pueden provocar que el
Protocolo Spanning Tree ponga las puertas en estado errDisable.

Channel Mode Switch 1

On
On
On
On
Off
Off
Off
Off
Auto
Auto
Auto
Auto
Desirable
Desirable
Desirable
Desirable

Channel Mode Switch 2

On
Off
Auto
Desirable
On
Off
Auto
Desirable
On
Off
Auto
Desirable
On
Off
Auto
Desirable

Channel State
Channel
Not-Channel (errdisable)
Not-Channel (errdisable)
Not-Channel (errdisable)
Not-Channel (errdisable)
Not-Channel
Not-Channel
Not-Channel
Not-Channel (errdisable)
Not-Channel
Not-Channel
Channel
Not-Channel (errdisable)
Not-Channel
Channel
Channel

Tabla 4-7: Combinaciones de channel mode y estado del canal resultante

73

4.5.4.1 Troubleshooting EtherChannel

Los desafos relativos a EtherChannel se pueden dividir en dos grandes reas: troubleshooting
durante la fase de configuracin y troubleshooting durante la ejecucin. Los errores de
configuracin tpicamente ocurren debido a parmetros que no concuerdan en las puertas
involucradas (diferentes velocidades, distinto duplex, distintos valores de las puertas en Spanning
Tree, etc.). Adems de esto tambin se pueden producir errores durante la configuracin debido a
que se setea la configuracin del canal en un lado y se deja pasar mucho tiempo antes de
configurar el otro lado. Esto provoca loops de Spanning Tree, lo que genera errores y la puerta
puede pasar al estado shut down.

4.5.5 Utilizacin de PortFast para solucionar problemas de conectividad de

estaciones terminales en el arranque
A medida que ms personas se conectan a la red a travs de switches dejando de lado los hubs,
se ven problemas relacionados con el delay al iniciar una sesin en ambientes cliente/servidor. El
mayor problema que se aprecia es que clientes de Windows 95/98 NT, Novell, VINES, IBM
Network Station y Apple Talk no se pueden conectar a sus servidores. Si el software de estos
equipos no es lo suficientemente persistente durante el procedimiento de inicio, dejarn de
intentar conectarse antes incluso de que el switch comience a dejar pasar el trfico.
Con la diversidad de funciones que se incluyen actualmente en los switches, puede pasar cerca de
un minuto antes que el switch comience a proporcionar el servicio a una estacin terminal que
recin se conecta. Este delay afectar a la estacin cada vez que esta sea encendida o
reiniciallizada. Las cuatro principales razones de este delay se ennumeran a continuacin:
Protocolo Spanning Tree
Negociacin de EtherChannel
Negociacin de Trunking
Negociacin de velocidad del enlace y modo duplex entre el switch y la estacin de trabajo
Las cuatro razones se enumeraron partiendo por la que causa el mayor delay (Spanning Tree)
hasta la que causa el menor delay (negociacin de velocidad y duplex). Una estacin conectada a
un switch generalmente no causa loops de spanning tree, no necesita EtherChannel y
generalmente no necesita negociar el modo trunking.
Para entender como la utilizacin del PortFast ayuda a disminuir el delay se debe entender
primero que es lo que lo provoca, por esto a continuacin se tiene una breve resea del STP.

74

4.5.5.1 Spanning Tree y PortFast

El Spanning Tree Protocol previene la creacin de loops en una red switcheada. Sin embargo,
este protocolo provoca que todas las puertas que estn incluidas en el proceso de Spanning Tree
se activen mucho ms lento que sin el protocolo ya que este detecta y bloquea los loops. Una red
bridgeada con loops y sin spanning tree colapsar.
Luego de que una puerta de un switch forma un enlace hacia la red, correr el protocolo spanning
tree en esa puerta. Una puerta con spanning tree puede estar en uno de cinco estados: blocking,
listening, learning, forwarding o disabled. El protocolo dice que una puerta parte en estado
blocking y luego pasa inmediatamente a travs de los estados listening y learning. Por defecto,
permenecer aproximadamente 15 segundos en estado listening y 15 en learning.
Durante el estado listening, el switch trata de determinar si es o no parte de un loop fsico. De ser
as, entonces puede que la puerta pase al estado bloqueado. En este estado (blocking) la puerta no
puede enviar ni recibir datos con el fin de eliminar el loop. Si la puerta no es parte de un loop,
pasar al estado learning. Todo el proceso de inicializacin del spanning tree demora
aproximadamente 30 segundos.
Si se est conectando una estacin de trabajo o un servidor con una sola tarjeta de red, esta
conexin no puede crear un loop. A estas conexiones se les llamas hojas del spanning tree. No
existe razn alguna para hacer que una estacin de trabajo o un servidor espere 30 segundos
mientras que el switch busca los loops cuando se sabe que no puede crear un loop. Es por esto
que Cisco agreg el PortFast o Fast Start, lo que significa que para estas puertas el spannning tree
asumir que la puerta no es parte de un loop pasndola inmediatamente al estado forwarding, sin
pasar por los estados listening ni learning. Esto permite ahorrar bastante tiempo. Este comando
no elimina el spanning tree, solo hace que el algoritmo en la puerta seleccionada se salte un par
de pasos innecesarios al comienzo.
4.5.5.2 Beneficio Adicional de PortFast
Existe un beneficio adicional ligado a la utilizacin del PortFast. Cada vez que un enlace se
activa y pasa al estado forwarding del spanning tree, el switch enva paquetes especiales de
spanning tree llamados Topology Change Notification (TCN). Estos paquetes pasan al root del
spanning tree de donde se propaga a todos los dems suites en la VLAN. Esto produce que todos
los switches eliminen sus tablas de direcciones MAC usando el parmetro forward delay que
normalmente es 15 segundos. Por lo tanto, cada vez que una nueva estacin se agrega a la red, las
tablas de direcciones MAC de todos los switches se eliminarn luego de 15 segundos en vez de
los 300 segundos que es lo normal.
Cuando una estacin de trabajo se activa, no cambia en forma significativa la topologa de la red,
por lo que en lo que respecta a los switches de la VLAN, es innecesario que tengan que pasar por
este rpido perodo de eliminacin de las tablas de direcciones MAC. Si se habilita PortFast en la
75

puerta en la que se conectar la nueva estacin, el switch no enviar los TCN cuando la puerta se
activa.

4.5.6 Troubleshooting para Protocolo Spanning Tree

La principal funcin del Algoritmo Spanning Tree (STA) es eliminar los loops creados por los
links redundantes en las redes switcheadas. El Protocolo Spanning Tree (STP) opera en la capa 2
del modelo OSI y a travs de BPDUs (Bridge Protocol Data Units) intercambiadas entre los
switches, determina si una puerta va a bloquear o dejar pasar trfico a travs de ella. Este
protocolo puede fallar en ciertos casos especficos, y el troubleshooting puede ser bastante
complicado dependiendo de la situacin especfica. Se puede decir que en esta rea en particular,
la mayor parte del troubleshooting se realiza antes que el problema ocurra.
A continuacin se tocarn los siguientes temas (asumiendo que se conoce el protocolo, el que se
encuentra explicado con mayor detalle en los anexos):
Las razones por las que el STP puede llegar a fallar
Que informacin mirar para identificar la causa del problema
Que tipo de diseo minimiza los riesgos y es fcil para realizar troubleshooting
4.5.6.1 Falla del Protocolo Spanning Tree
Una falla en el algoritmo STA generalmente lleva a un loop. Generalmente, un loop en STP
proviene de una puerta que debiese estar en estado blocking pero est dejando pasar el trfico.
Que puede provocar que una puerta bloqueada pase al estado forwarding? Primero revisemos por
que una puerta se encuentra en estado blocking.
Cada LAN tiene un solo bridge designado. Este es el responsable de la conectividad de la LAN
hacia el root bridge. En la Figura 4-4, el bridge B ha sido seleccionado como el bridge designado,
y el bridge C est bloqueando slo porque proporciona un camino alternativo al root. El que
bloquea es el bridge C y no el B porque ste tiene una mejor BPDU que el C. El bridge B sigue
mandando BPDUs avisando su superioridad por sobre los otros bridges en la LAN. Si el bridge C
deja de recibir las BPDUs por un perodo de tiempo (llamado el max-age, 20 segundos por
defecto), comenzar la transicin hacia el estado forwarding.

Figura 4-4: La puerta bloqueada en el bridge C sigue recibiendo BPDUs del bridge B
76

4.5.6.2 Duplex Mismatch

El duplex mismatch en un enlace punto a punto es un error tpico de configuracin. Esto sucede
especialmente cuando un lado del enlace est configurado para estar en modo full duplex. Si se
deja el otro lado en modo autonegociacin, ste teminar en modo half duplex (una puerta con el
modo duplex configurado ya no negocia).
El peor caso posible sucede cuando un bridge que est enviando BPDUs est configurado para
operar en half duplex en un enlace, mientras que su par est configurado para operar en full
duplex. En la Figura 4-5, el duplex mismatch en el enlace entre los bridges A y B puede llevar
fcilmente a un loop. Dado que el bridge B est configurado para operar en modo full duplex, no
realiza carrier sense antes de acceder al enlace. El bridge B entonces empezar a enviar frames a
pesar de que el bridge A se encuentre utilizando el enlace.
Esto representa un problema para el bridge A, el cual detecta una colisin y corre el algoritmo de
back off antes de intentar transmitir nuevamente. El resultado de esto es que si hay suficiente
trfico de B hacia A, cada paquete (incluyendo BPDUs) enviado por A colisionar y por lo tanto
se perder. Desde el punto de vista del STP, dado que no recibe BPDUs del bridge A, el bridge B
habr perdido su root. Esto lleva a que el bridge B desbloquee su puerta hacia el bridge C,
creando as un loop.

Figura 4-5: Loop creado por un Duplex Mismatch

4.5.6.3 Enlace Unidireccional
Esta es una causa comn de creacin de loops. Los enlaces unidireccionales generalmente son
causados por una falla no detectada en un enlace de fibra, por ejemplo, debido a un problema con
un transceiver. Cualquier cosa que pueda llevar a que un enlace se mantenga arriba
proporcionando comunicacin en una sola direccin es muy peligroso para el STP. A
continuacin se muestra un ejemplo:

77

Figura 4-6: Loop generado en un enlace en una sola direccin

Supongamos que el enlace entre A y B es unidireccional y bota todo el trfico que va desde A
hacia B mientras que transmite correctamente el trfico desde B hacia A. Supongamos que el
bridge B debiera estar bloqueando. Ya se mencion que una puerta puede bloquear siempre y
cuando est recibiendo BPDUs de un bridge que tiene una mejor prioridad. En este ejemplo,
todas las BPDUs que vienen desde A se pierden, por lo que el bridge B pasar a estado
forwarding, creando un loop. Ntese que en este caso si la falla exista en la partida, el STP no
converger correctamente.
Cisco introdujo el protocolo UDLD. Este protocolo es capaz de detectar errores de cableado o
enlaces unidireccionales en capa 2 y automticamente elimina los loops que se generen
deshabilitando algunas puertas.
4.5.6.4 Corrupcin de Paquetes
La corrupcin de paquetes puede llevar al mismo tipo de falla. Si un enlace est experimentando
una gran tasa de errores a nivel fsico, se podran perder un cierto nmero de BPDUs
consecutivas, llevando a una puerta bloqueada al estado forwarding. Este caso no es tan frecuente
ya que los parmetros por defecto del STP son bastante conservadores. La puerta bloqueada
tendra que dejar de recibir las BPDUs por 50 segundos antes de pasar al estado forwarding, y
una sola BPDU transmitida correctamente terminara con el loop. Este caso ocurre en especial
cuando los parmetros de STP han sido ajustados sin el debido cuidado (por ejemplo reduccin
del max age).
4.5.6.5 Errores de Recursos
En todos los switches, el STP est implementado en software. Esto quiere decir que si la CPU del
bridge est sobreutilizada por cualquier motivo, es posible que no le alcancen los recursos para
enviar BPDUs. El STA en general no usa muchos recursos y en general tiene prioridad por sobre
otros procesos, por lo que en general no presenta mayores problemas debido a esto, pero si puede
eventualmente suceder llegando a situaciones como las de los casos anteriores.

78

4.5.6.6 Error de Configuracin de PortFast

PortFast tpicamente se habilita en puertas que se encuentran conectadas a hosts. Cuando un
enlace sube en esta puerta, las primeras etapas del STA se omiten y la puerta pasa directamente al
estado forwarding. Esto puede ser peligroso si no se utiliza correctamente. Los loops ocurren
entonces cuando se mueve un cable y debieran ser transientes solamente.
En la Figura 4-7, el bridge A tiene la puerta p1 en forwarding y la puerta p2 configurada con
PortFast. El bridge B es un hub. Cuando el segundo cable es enchufado en el bridge A, p2 pasa a
forwarding y crea un loop entre p1 y p2. Esto terminar cuando p1 o p2 reciba una BPDU que
pondr a una de las puertas en estado blocking. El problema con los loops transientes es que si el
trfico en el loop es mucho, el bridge podra tener problemas para mandar la BPDU que detendr
el loop. Esto puede demorar la covergencia considerablemente.

Figura 4-7: Loop transiente por error de configuracin de PortFast

4.5.7 Troubleshooting Transparent Bridging

En esta seccin se muestra informacin de troubleshooting para problemas de conectividad en
una red con transparent bridging. Se describen sntomas especficos, los problemas que pueden
causar dichos sntomas y las soluciones a los problemas.
Para realizar un troubleshooting eficiente, se debe tener un conocimiento bsico del diseo de la
red, especialmente cuando est involucrado el Spanning Tree. Se debe tratar de tener lo siguiente
antes de comenzar a hacer el troubleshooting:
Un mapa con la topologa de la red
La ubicacin del root bridge
La ubicacin de los enlaces redundantes (y de las puertas bloqueadas)

79

Cuando se realiza troubleshooting para problemas de conectividad, se debe tratar de acotar el

problema a un nmero mnimo de hosts (idealmente un cliente y un servidor). En las secciones
que siguen se describen los problemas ms comunes en este tipo de redes, que son: no hay
conectividad, spanning tree inestable, las sesiones terminan inesperadamente, y hay loops y
excesivo broadcast.
4.5.7.1 No hay Conectividad
Sntoma: Un cliente no se puede conectar a un host a travs de una red transparente mediante un
bridge.
La tabla a continuacin describe las posibles causas de este sntoma y las soluciones para esos
problemas:

Posibles Causas

Problema de
hardware o
del medio

El host est
abajo

Acciones Sugeridas
1. Use el comando show bridge para ver si existe un problema de
conectividad. Si lo hay, la salida no mostrar direcciones MAC
en la tabla.
2. Use el comando show interfaces para determinar si la interfaz
y el protocolo estn arriba.
3. Si la interfaz est abajo, realice troubleshooting al hardware o al
medio.
4. Si el protocolo est abajo, revise las conexiones fsicas entre la
interfaz y la red. Asegrese que la conexin esta correcta y que
los cables no estn daados.
1. Use el comando show bridge para asegurar que la tabla de
bridge incluya las direcciones MAC de los nodos terminales
adyacentes.
2. Si algn nodo terminal falta, revise el estado de los nodos para
verificar que estn conectados y correctamente configurados.
3. Reinicie o reconfigure los nodos terminales segn sea necesario
y reexamine la tabla de bridge usando el comando show bridge

80

El camino de
bridging
est cortado

1. Identifique el camino que los paquetes debieran seguir entre los

nodos terminales. Si hay un router en este camino, divida el
troubleshooting en dos partes: nodo 1-router y router-nodo 2.
2. Conctese a cada bridge en el camino, y revise el estado de las
puertas que son utilizadas en el camino entre los nodos terminales
tal como fue descrito para el caso de problemas de harware o medio.
3. Usando el comando show bridge revise que las direcciones MAC
de los nodos son aprendidas en las puertas que corresponde. De no
ser as, puede que haya inestabilidad en la topologa de STP.
4. Revise el estado de las puertas usando el comando show span.
Si las puerta que debieran transmitir el trfico entre los nodos
terminales no estn en forwarding, la topologa del Spanning Tree
puede haber cambiado inesperadamente.

Filtros de
bridging mal
configurados

1. Use el comando show runing config para revisar si hay filtros

configurados.
2. Deshabilite los filtros en las puertas por las que pasa el trfico y
revise si se recupera la conectividad.
3. Si no se recupera conectividad, no es un problema de filtro. Si la
conectividad regresa, alguno de los filtros est causando el problema.
4. Si existe ms de un filtro configurado, aplique cada uno por separado
para determinar cual es el que est causando el problema.
5. Modifique cualquier filtro o lista de acceso que est bloqueando
trfico. Contine las pruebas de filtros hasta que estn todos
funcionando y la conexin est arriba.

Colas de entrada
y salida
estn llenas

Exceso de trfico broadcast o multicast puede producir la saturacin

de las colas de entrada y salida, provocando prdida de paquetes.
1. Use el comando show interfaces para buscar prdidas en la entrada
o en la salida. Si el nmero de paquetes en la cola de entrada es
mayor o igual que el 80% del tamao total de la cola, la cola de
entrada podra necesitar acomodarse a la tasa de entrada. Aunque
el numero de paquetes en la cola de entrada sea menor que el
tamao de la cola, las rfagas de paquetes pueden provocar el
colapso de la cola.
2. Reduzca el trfico broadcast y multicast en las redes vecinas
implementando filtros, o segmente la red usando ms elementos de
red.
3. Si la conexin es un enlace serial, aumente el ancho de banda,
aplique encolado prioritario o modifique el tamao del buffer.
Tabla 4-8: Troubleshooting problema de conectividad

81

4.5.7.2 Spanning Tree Inestable

Sntoma: Prdida de conectividad transiente entre hosts. Varios hosts afectados al mismo tiempo.

Posibles Causas

Enlace cambiante

Acciones Sugeridas
1. Use el comando show span para revisar si el nmero de
cambios en la topologa est en crecimiento.
2. De ser as, revise el enlace entre los bridges usando el
comando show interface. Si no puede encontrar un enlace
cambiando entre dos bridges de esta forma, use el comando
debug spantree event.

Root bridge cambiante /

muchos bridges quieren
ser root bridge

1. Revise la consistencia de la informacin del root brodge en

toda la red usando el comando show span en todos los
bridges.
2. Si varios bridges dicen ser root, revise que se est corriendo el
mismo protocolo spanning tree en todos los bridges.
3. Use el comando bridge <group> priority <number> en el
root para forzar el root deseado a que sea efectivamente el
root.
Mientras menor sea la prioridad, mayor probabilidad tiene el
bridge de ser el root.
4. Revise el dimetro de la red. Con las configuraciones estndar
nunca debiera haber ms de 7 saltos entre hosts.

No hay intercambio de
Hellos

1. Revise si los bridges se estn comunicando entre ellos. Use un

analizador de red o el comando debug spantree tree para ver
si estn siendo intercambiados los frames Hello.
2. Si los Hellos no estn siendo intercambiados, revise las
conexiones fsicas y las configuraciones de software en los
bridges.

Tabla 4-9: Troubleshooting conectividad intermitente

82

4.5.7.3 Sesiones Terminan Inesperadamente

Sntoma: Las sesiones se inician correctamente pero terminan en forma repentina e inesperada.
Posibles Causas

Acciones Sugeridas

Retransmisiones
excesivas

1. Use un analizador de red para buscar retransmisiones de los

hosts
2. Si ve retransmisiones en lneas seriales lentas, aumente los
timers de transmisin en el host.
3. Use un analizador de red para ver si el numero de
retransmisiones disminuye.

Delay excesivo sobre

un enlace serial

1. Aumente el ancho de banda, aplique encolado con

prioridad, aumente el tamao de la cola, o modifique el
tamao del buffer del sistema.

Tabla 4-10: Troubleshooting trmino repentino de sesiones

4.5.7.4 Loops y excesivo Broadcast
Sntoma: Ambas cosas suceden en ambientes de bridging transparente. Las estaciones terminales
se ven forzadas a retransmitir excesivamente, causando que las sesiones se caigan.
Los loops son el peor escenario en una red usando bridges porque pueden impactar a todos los
usuarios. En caso de emergencia, la mejor forma de recuperar rpidamente la conectividad es
deshabilitar en forma manual todas las interfaces que proporcionan caminos redundantes en la
red. Desafortunadamente, la causa del loop ser muy difcil de identificar luego de esto. En la
siguiente tabla se muestran algunas acciones que se deben tomar antes de recurrir a esta medida
extrema.

Posibles Causas

Acciones Sugeridas

No est
implementado el
Spanning Tree

1. Examine el mapa de la red en busca de posibles loops.

2. Elimine los loops que existan, o asegrese que los links redundantes
estn en modo backup.
3. Si persisten los excesivos broadcasts y las prdidas de paquetes,
use el comando show interfaces para obtener las estadsticas de
entrada y salida de paquetes. Si los contadores aumentan a una tasa
fuera de lo comn (relativo a la carga de trfico normal),
probablemente an haya un loop en la red.
4. Implemente el algoritmo Spanning Tree para prevenir los loops.

83

1. Use el comando show span en cada bridge para determinar que

algoritmo de Spanning Tree est siendo utilizado.
2. Asegrese que todos los bridges estn usando el mismo algoritmo
de Spanning Tree (DEC o IEEE). El uso de ambos algoritmos puede
ser necesario en algunos casos muy particulares. Si el mismatch no
es lo que se desea, deben reconfigurarse los bridges para que todos
usen el mismo algoritmo de Spanning Tree.

Discordancia del
algoritmo
Spanning Tree

1. Use el comando show span en cada bridge para asegurar que todos
los nmeros de grupos de dominios coinciden con los dominios
de bridgeo correspondientes.
Mltiples dominios 2. Si en el bridge hay mltiples grupos de dominios configurados,
de
asegrese que todas las especificaciones del dominio estn
bridgeo configurados
correctamente asignadas. Use el comando bridge <group> domain
en
<domain-number> para realizar los cambios necesarios.
forma incorrecta.
3. Asegrese que no existen loops entre dominios de bridgeo. En un
ambiente de bridgeo interdominio no proporciona la prevencin de
loops basndose en Spanning tree. Cada dominio tiene su propio
Spanning Tree, que es independiente de los de otros dominios.

Error de Enlace
(enlace
unidireccional),
mismatch
en el duplex, alto
nivel de
error en una puerta.

1. Identifique las puertas que estn bloqueadas en su diagrama dela red.

2. Revise el estado de las puertas que debieran estar bloqueadas en la
red, usando los comandos show interface y show bridge.
3. Si encuentra una puerta que debiera estar bloqueada pero est en
modo forwarding (o a punto de estarlo, en listening o learning), ha
encontrado la verdadera fuente del problema. Revise de donde recibe
las BPDUs esta puerta. Si no las recibe, probablemente se trate del
enlace conectado a la puerta (revise los errores de enlace, duplex,
velocidad, etc.). Si la puerta est recibiendo BPDUs, vaya al bridge
que debiera ser el designado para la LAN en la que estamos. Desde
ah, revise todos los enlaces en el camino hacia el root. Debiera
encontrar un problema en alguno de estos enlaces (suponiendo que el
diagrama de red estaba correcto).

Tabla 4-11: Troubleshooting loops y excesivo broadcast

84

4.6 Laboratorios para la realizacin de pruebas

En esta seccin se muestran los laboratorios realizados para Ethernet y para ADSL. Se muestran
las maquetas montadas para ambas tecnologas y las pruebas realizadas en cada caso. Para el caso
de Ethernet el objetivo es validar la informacin de troubleshooting presentada en la seccin
anterior, y para el caso de ADSL las pruebas apuntan a la generacin de esquemas de
troubleshooting para esta tecnologa.
Para implementar servicios de telefona sobre las plataformas de acceso se utiliz un IAD
Huawei, registrado en un sofswitch de pruebas de Telmex. Por otro lado, se consider un acceso a
Internet usando una direccin pblica asociada a pruebas de Telmex. Finalmente, se consider un
servidor remoto al cual se puede tener acceso va Telnet, donde se puede correr IPerf, para
realizar pruebas contra un equipo conectado en el extremo asociado al usuario de los servicios ya
mencionados.

4.6.1 Maqueta de pruebas para Ethernet

Para comprobar el funcionamiento de una red de acceso Ethernet se utiliz la maqueta de pruebas
de la Figura 4-8. Es importante mencionar que el trabajo en este modelo de pruebas para Ethernet
y sus resultados fueron realizados en conjunto con Gonzalo Daz en el contexto del desarrollo de
su memoria de titulo Troubleshooting en tecnologas de acceso emergentes guiada por el Sr.
Alfonso Ehijo al igual que el presente trabajo.

Figura 4-8: Maqueta de pruebas para Ethernet

En este modelo se considera un enlace troncal entre los dos switches, que corresponden a un
switch Cisco 3550 de Ingeniera y a otro switch Cisco 3550 de Pruebas, en donde se tiene acceso
85

a configuracin de ambos equipos atravs de la CLI, donde el switch de Ingeniera se accede

mediante Telnet y al otro switch se accede mediante la interfaz de consola. El enlace troncal usa
encapsulacin 802.1q permitiendo el paso de dos VLANs, la 3533 asociada a Internet, y la 3532
asociada a telefona.
El switch de Ingeniera llega a la red IP MPLS donde se tiene salida a Internet con direcciones
externas y tambin se cuenta con salida hacia un softswitch de prueba a travs de las VLAN ya
mencionadas.
Para la instrumentacin de la maqueta se cuenta con cuatro herramientas: la primera, es el
comando ping en su versin extendida, para ver temas de conectividad, y retardo de paquetes. Por
otro lado se tiene IPerf, el que se utiliz como herramienta de pruebas de transmisin de datos y
de recuento de paquetes recibidos. Tambin se tienen dos routers IP SLA, los que se configuraron
de manera de realizar pruebas a travs de la VLAN de telefona, en particular, una prueba de
MOS. Por ltimo se tiene Ethereal corriendo el PC de IP 200.29.150.50, para ver las trazas
recibidas o generadas por este equipo.
4.6.1.1 Condicin Ideal
El punto central de la maqueta es el switch de pruebas, en el que se realizaron distintas
modificaciones. Estas se hicieron tanto en la puerta asociada a la troncal, como a las puertas de
acceso de telefona o Internet. Para realizar una comparacin, se tom como referencia la
situacin con todas las puertas configuradas en 100 Mbps / Full Duplex sin direcciones IP para
dejar esta parte en capa 2 y sin usar spanning tree portfast en ninguna puerta.
Bajo estas condiciones se realiz una prueba de IPerf tanto en sentido ascendente como
descendente usando paquetes de 1500 Bytes, y por otro lado se obtuvo el MOS usando IP SLA.
Los resultados obtenidos se muestran en la Tabla 4-12:

Throughput 1500 B Uplink

Throughput 1500 B Downlink

MOS

62.2 Mbps

61.6 Mbps

4.34

Tabla 4-12: Condicin Ideal de un enlace Ethernet

IPerf se utiliz con la siguiente configuracin:
Servidor: iperf -s -u -i 1 -l 1458
-s:
Para correr iperf en modo servidor
-u:
Para utilizar trfico UDP
-i 1:
Entrega reportes cada 1 segundo
-l 1458: Para poner el tamao de paquetes en 1500 Bytes
86

Cliente: iperf -c x.x.x.x -u -i 1 -l 1458 - b ancho_de_banda

-c x.x.x.x: El cliente se conecta a la IP x.x.x.x
-b ancho_de_banda: Se genera esta tasa de transferencia, luego en el servidor se
entrega a que tasa se recibe, adems de la prdida de paquetes. Manipulando este
parmetro se puede congestionar el enlace usando anchos de banda apropiados.
4.6.1.2 Throughput vs Tamao de Paquetes
El throughput atravs de un enlace Ethernet, presenta variaciones al pasar trfico de paquetes de
distintos tamaos. Para mostrar esta caracterstica, se realizaron pruebas de throughput utilizando
distintos tamaos de paquetes y congestionando el canal con trfico continuo. Para esto se
utilizaron dos interfaces de un equipo Interwatch, para enviar y recibir trfico en sentido
ascendente y descendente. Esta prueba a diferencia de la prueba anterior se realiz sin pasar
servicios, y sin estar conectados a la red externa, considerando el esquema de la Figura 4-9:

Figura 4-9: Prueba de Troughput vs Tamao de paquetes para Ethernet

Los resultados de esta prueba se muestran en la tabla 4-13 y en los grficos 4-1 y 4-2 para los
sentidos ascendente y descendente respectivamente:
Tamao de paquetes

Throughput Downlink

Throughput Uplink

64 Bytes

91,3 Mbps

89,9 Mbps

128 Bytes

91,7 Mbps

91,1 Mbps

256 Bytes

94,5 Mbps

92,4 Mbps

400 Bytes

95,8 Mbps

94,2 Mbps

512 Bytes

97,4 Mbps

95,7 Mbps

1024 Bytes

98,5 Mbps

96,8 Mbps

1280 Bytes

98,4 Mbps

96,4 Mbps

1500 Bytes

98,8 Mbps

96,9 Mbps

Tabla 4-13: Tabla de Throughput vs Tamao de paquetes para el enlace Ethernet

87

98

Troughput [Mbps]

96
94
92
90
88
86
84
64

128

256

400

512

1024 1280 1500

Tamao de paquetes [bytes]

Grfico 4-1: Throughput vs Tamao de Paquetes Ascendente en Ethernet

100

Troughput [Mbps]

98
96
94
92
90
88
86
64

128

256

400

512

1024 1280 1500

Tamao de paquetes [bytes]

Grfico 4-2: Throughput vs Tamao de Paquetes Descendente en Ethernet

De los grficos se puede ver que para paquetes pequeos se reduce considerablemente el
throughput tanto en sentido ascendente como en sentido descendente. Sin embargo esta maqueta
considera un acceso ms real, dado que se considera la red MPLS, con la congestin que sta
incluye.
4.6.1.3 Generacin de problemas
En esta seccin se utiliz IPerf como herramienta de medicin, debido a la facilidad para
implementar el servidor en otro punto de la red. Sin embargo, se debe tener en cuenta que IPerf
es ejecutado en PCs, por lo que los anchos de banda estn acotados por las tarjetas de red de los
computadores involucrados.
La medicin sigue siendo vlida para velocidades menores adems de que IPerf permite
monitorear la prdida de paquetes, que corresponde a un parmetro importante para los servicios
que se consideran en este trabajo.
88

Lo primero que se realiz es cambiar la configuracin inicial del switch de pruebas, para lo que
se consider modificar el modo duplex de uno de los extremos del enlace troncal, de manera de
forzar una discordancia o mismatch. Este cambio se hizo por ambos lados, es decir dejando
como full duplex el 3550 de ingeniera y el 3550 de pruebas como half duplex y viceversa, y se
realizaron las mismas mediciones que en la condicin ideal. Los resultados obtenidos se muestran
en las Tablas 4-14 y 4-15.

Throughput 1500 B Uplink

Throughput 1500 B Downlink

MOS

59.9 Mbps

58.4 Mbps

4.34

Tabla 4-14: Duplex Mismatch (Switch pruebas en Half Duplex)

Throughput 1500 B Uplink

59 Mbps

Throughput 1500 B Downlink

54.7 Mbps

MOS
4.34

Tabla 4-15: Duplex Mismatch (Switch Ingeniera en Half Duplex)

Es importante mencionar de que a tasas de transferencia elevadas se produce una prdida de
paquetes de un 3 % hasta un 8% del total, lo que adems se refleja enviando ping de 1500 Bytes,
donde se pierden entre 1 y 3 pings por cada 1000 enviados.
En ambas situaciones se realizaron llamadas telefnicas exitosas con una calidad de voz buena, lo
que es concordante con la medida de MOS obtenida con el router.
Otra prueba realizada corresponde a fijar ambos extremos de la troncal en 10 Mbps, ya que al
producirse una incompatibilidad en este parmetro, el enlace no se da. Se realizaron las mismas
pruebas anteriores con lo que se obtuvo lo siguiente:
Throughput 1500 B Uplink
9.41 Mbps

Throughput 1500 B Downlink

9.41 Mbps

MOS
4.34

Tabla 4-16: Troncal en 10 Mbps

Sin embargo al realizar un duplex mismatch en 10 Mbps se obtuvo lo siguiente:
Throughput 1500 B Uplink
8.9 Mbps

Throughput 1500 B Downlink

8.87 Mbps

Tabla 4-17: Duplex Mismatch con troncal en 10 Mbps

89

MOS
4.34

Aqu podemos ver nuevamente las prdidas que se dan tambin en el caso del duplex mismatch
en 100 Mbps, sin embargo las llamadas son de buena calidad en todos estos casos.
4.6.1.4 Generacin de problemas para STP
En esta etapa se generaron distintos tipos de proble asociados al protocolo STP para lo que se
consider el esquema dela Figura 4-10:

Interwatch 95000
Interwatch 95000
Switch 3550 Pruebas

Switch 2950

Figura 4-10: Modelo de pruebas para STP

Este esquema es similar al que se utiliz para las pruebas de throughput, sin embargo se agreg
una conexin adicional para forzar loops. En este contexto, se configuraron puertas en modo
PortFast para que se produjeran loops transientes, ya que en esta configuracin las puertas quedan
inmediatamente en estado forward por un corto tiempo antes de que el switch automticamente
deje una de las puertas involucradas en el loop en estad blocking.
Adems se utilizaron los Interwatch para provocar prdidas en los mensajes usados por el
protocolo STP, lo que se pudo ver usando Ethereal y haciendo una copia o mirror en las
puertas que se quisieran analizar. El proceso de copiar una puerta se realiza en los switch
haciendo una sesin con un origen y destino referenciados a ciertas puertas o interfaces del
switch, ya que a travs de una puerta se puede monitorear una VLAN, que puede corresponder a
muchas puertas o interfaces fsicas del equipo.
Con este procedimiento se validaron los documentos de troubleshooting para STP que se
presentan ms adelante en el documento. En particular se pudo comprobar el funcionamiento del
protocolo de spanning-tree, y se pudo forzar puertas en los distintos estados asociados a este
mecanismo, adems de ciertos errores que se pueden presentar, tanto por configuracin como por
congestin.

90

4.6.1.5 Generacin de problemas para TCP/IP y ambientes LAN

Para validar el resto de las situaciones descritas en el documento se utiliz el esquema dela
Figura 4-11 donde se consideraron problemas asociados a ambientes LAN y TCP/IP. Es
importante destacar que este procedimiento y los resultados obtenidos se realizaron en conjunto
con Gonzalo Daz, como ya se ha mencionado anteriormente.

Figura 4-11: Esquema de pruebas para ambientes LAN y TCP/IP

En el esquema utilizado se pueden ver tres computadores, donde dos de ellos tienen direcciones
asociadas a la misma red y otro que no. La idea del esquema es ver problemas bsicos de
conectividad a nivel de LAN, por ejemplo, errores en capa fsica (cables, conectores, etc.) y
errores de configuracin de VLAN o bien de nivel TCP/IP como errores en la misma
configuracin IP (que se modific para todos los equipos) y las mscaras de sub-red. El ltimo
elemento es un servidor que se encuentra conectado a travs de la MPLS para ver conectividad a
travs de un par de saltos.

4.6.2 Maqueta de Pruebas para ADSL

Lo primero fue realizar pruebas de throughput, jitter y RTT (round trip time) para el equipo
ADSL Netopia Cayman 3347W conectado a un DSLAM Zyxel IES-1000 Series, para lo cual se
utiliz la herramienta Iperf y el comando ping, basndose en el esquema que se muestra en la
Figura 4-12. El router ADSL se configur con PAT (Port Address Translation) para poder utilizar
una direccin IP pblica (la que se muestra en la figura) para las pruebas.

91

Figura 4-12: Maqueta de Pruebas ADSL con Netopa Cayman 3347W

Para realizar la configuracin del router ADSL se utiliz telnet y para el DSLAM Zyxel se utiliz
una interfaz va web. Se utiliz encapsulacin de enlace de datos RFC1483 en modo bridged y se
utilizaron los valores de VPI/VCI de 8/105 (con UBR o undefined bit rate) conectndose a la
puerta 1 del DSLAM. El router posee en su interfaz WAN la direccin IP 200.29.161.82 y en su
interfaz LAN la 192.168.1.1. Al PC utilizado se le asign la IP 192.168.1.100 la cual es asignada
en forma dinmica a travs de DHCP por el router y para la comunicacin con el exterior utiliza a
travs del PAT la direccin 200.29.161.88. Por ltimo se tiene que el router tiene como default
gateway la direccin 200.29.161.94, que corresponde a la direccin de la VLAN de Internet del
switch catalyst 3550 de Ingeniera.
Debe mencionarse adems que las pruebas se realizaron para distintas velocidades de uplink y
downlink las que se configuraron en el DSLAM. Especficamente, se consideraron 4 casos
particulares con las siguientes velocidades: 2048/512, 1024/256, 512/256, 256/64, donde el
primer valor corresponde a la velocidade del downlink y el segundo corresponde al uplink.
4.6.2.1 Pruebas de Throughput, Jitter y Round Trip Time
4.6.2.1.1 Condiciones de Prueba
Se realizaron pruebas con dos tamaos de paquetes distintos: 64 Bytes y 1500 Bytes, y las
condiciones en las que esto se realiz se describen, para cada caso, a continuacin:
a) Paquetes 64 Bytes
En el servidor: iperf -s -i 1 -u -l 22
En el cliente: iperf c 200.29.161.88 -i 1 -u -l 22
b) Paquetes 1500 Bytes
En el servidor: iperf -s -i 1 -u -l 1458

92

En el cliente: iperf c 200.29.161.88 -i 1 -u -l 1458

Debe notarse que en algunos casos se utiliz la opcin b para fijar la cantidad de bytes a enviar.
En particular, esta opcin fue utilizada para los casos con velocidades downstream de 1024 y
2048 kbps.
4.6.2.1.2 Pruebas Downstream
En este caso el cliente se encontraba en la direccin 200.29.161.91 enviando paquetes hacia el
servidor que corresponda en este caso al PC con la direccin 200.29.161.88 (asignada a travs de
PAT). Los resultados obtenidos se resumen en la Tabla 4-18:

Paquetes 64 Bytes
Velocidad
Throughput
Down/Up (kbps)
(kbps)
2048/512
424
1024/256
212
512/128
106
256/64
53

Jitter
(ms)
1,333
1,618
2,685
5,610

Paquetes 1500 Bytes

RTT
(ms)
18
24
30
41

Throughput
(kbps)
1760
878
439
212

Jitter
(ms)
7,623
8,225
8,532
9,989

RTT
(ms)
52
87
159
297

Tabla 4-18: Throughput, Jitter y RTT para enlace ADSL en Downstream

4.6.2.1.3 Pruebas Upstream
En este caso el cliente se encontraba en la direccin 200.29.161.88 (asignada a travs de PAT)
enviando paquetes hacia el servidor que corresponda en este caso a la direccin 200.29.161.88.
Los resultados obtenidos se resumen en la Tabla 4-19:

Paquetes 64 Bytes
Velocidad
Throughput
Down/Up (kbps)
(kbps)
2048/512
103
1024/256
31,7
512/128
25,7
256/64
12.8

Jitter
(ms)
3,393
7,863
9,626
29,545

Paquetes 1500 Bytes

RTT
(ms)
18
24
30
41

Throughput
(kbps)
430
215
107
54

Jitter
(ms)
11,581
19,803
37,404
101,173

RTT
(ms)
52
87
159
297

Tabla 4-19: Throughput, Jitter y RTT para enlace ADSL en Upstream

Debe notarse que en ambas tablas se muestran los mismos valores de RTT. Esto se debe a que
este parmetro considera el tiempo que demora el recorrido de ida y de vuelta entre ambos hosts.

93

4.6.2.2 Throughput vs Tamao de Paquetes

Se realizaron pruebas para ver la dependencia del throughput con el tamao de los paquetes. Esta
medicin fue realizada utilizando Iperf con el mismo esquema de la Figura 4-12. Los resultados
obtenidos se muestran en los Grficos 4-3 y 4-4. Aqu se aprecian las variaciones del throughput
utilizando un enlace de 2048/512 Kbps en downlink y uplink respectivamente.

Throughput [Kbps]

Throughput vs Tamao de Paquetes

2000
1500
1000
500
0
0

500

1000

1500

2000

Tamao de Paquetes [Bytes]

Grfico 4-3: Throughput vs Tamao de paquetes en downlink

Throughput [Kbps]

Throughput vs Tamao de Paquetes

500
400
300
200
100
0
0

500

1000

1500

2000

Tamao de Paquetes [Bytes]

Grfico 4-4: Throughput vs Tamao de paquetes en uplink

94

4.6.2.3 Jitter vs Tamao de Paquetes

Se realizaron pruebas para ver la dependencia del jitter con el tamao de los paquetes. Esta
medicin fue realizada utilizando Iperf con el mismo esquema de la Figura 4-12. Los resultados
obtenidos se muestran en los Grficos 4-5 y 4-6. Aqu se aprecian las variaciones del jitter del
uplink y del downlink, con ancho de banda de 2048/512 Kbps respectivamente.

Jitter [ms]

Jitter vs Tamao de Paquetes

6,000
5,000
4,000
3,000
2,000
1,000
0,000
0

500

1000

1500

2000

Tamao de Paquetes [Bytes]

Grfico 4-5: Jitter vs Tamao de Paquetes en Downlink

Jitter vs Tamao de Paquetes

Jitter [ms]

20
15
10
5
0
0

500

1000

1500

Tamao de Paquetes [Bytes]

Grfico 4-6: Jitter vs Tamao de Paquetes en Uplink

95

2000

4.7 Troubleshooting ADSL

4.7.1 Fallas Forzadas y Pruebas con Ping
Una vez realizadas las pruebas de throughput, jitter y RTT se procedi a provocar fallas
modificando la configuracin del router Netopia y se prob la conectividad. Debe mencionarse
que para la gran parte de las modificaciones se perda la conectividad hacia Internet. Es por esto
que el troubleshooting a realizar estar enfocado principalmente a problemas de conectividad.
Para cada modificacin se hizo ping a las siguientes direcciones:
a) 66.102.7.104 (Google)
b) 200.29.161.81 (Gateway Internet)
c) 200.29.161.84 (DSLAM)
d) 200.29.161.82 (Router ADSL, WAN)
e) 192.168.1.1 (Router ADSL, LAN)
Se hizo una tabla con los resultados obtenidos a partir de la prueba de ping, para esto se asoci a
cada posible salida de este comando un nmero para una ms fcil representacin. Esto se
muestra a continuacin:
1.
2.
3.
4.
5.
6.
7.

Host desconocido www.google.cl

Respuesta desde 192.168.1.1: Host de destino inaccesible
Tiempo de espera agotado para esta solicitud
Respuesta desde 200.29.161.84: Red de destino inaccesible
Host de destino inaccesible
Respuesta desde 192.168.1.1: Red de destino inaccesible
Respuesta desde x.x.x.x: bytes=xx tiempo=xx TTL=xx

En la tabla 4-20 se resumen los resultados obtenidos al hacer ping a las distintas direcciones
mostradas anteriormente.

N
1
2
3
4
5
6
7

Problemas Posibles
Data Link Encapsulation equivocado
VPI/VCI equivocado
Underlying Encapsulation PPoE en vez de None
RFC Mode Routed en vez de Bridged
Address Translation Deshabilitada
IP Addressing Unnumbered
WAN IP Mask Equivocada (255,255,255,248)
96

a
1
1
2
3
3
2
1

b
2
3
2
3
3
2
7

c
2
3
2
3
3
2
7

d
2
7
2
7
7
2
7

e
7
7
7
7
7
7
7

8
9
10
11
12
13
14
15
16
17
18
19
20
21

WAN IP Mask Equivocada (255,255,255,252)

1
7
2
Default IP Gateway equivocado (200,29,161,84)
4
7
7
Default IP Gateway equivocado (200,29,161,82)
3
7
7
IP Address Serving Off
1
5
5
QoS VBR con valores inadecuados
1
3
3
Easy Setup Profile Disabled
1
6
6
No hay NAT map list (none)
6
6
6
Filtro Inadecuado (salida o entrada)
1
3
3
Lnea ADSL desconectada o cable malo (led DSL Off) 1
2
2
PC no conectado al router ADSL (Led LAN OFF)
1
5
5
Puerta inactiva en DSLAM
1
2
2
PVC inactivo en DSLAM
1
3
3
PVC no configurado en DSLAM
1
3
3
Muy pequeo max rate en DSLAM
3/7 3/7 3/7

7
7
7
5
7
6
7
3
2
5
2
7
7
7

7
7
7
5
7
7
7
7
7
5
7
7
7
7

Tabla 4-20: Resultados pruebas con comando ping

4.7.2 Sntomas, Posibles Problemas y Acciones Sugeridas

En esta seccin representan, a partir de los sntomas, los posibles problemas que pueden estar
provocndolos y sus respectivas soluciones. Los problemas con sus respectivas soluciones estn
enfocados a un enlace esttico sin autenticacin de usuario.

4.7.2.1 Problemas de Throughput en enlaces ADSL

Sntoma: Las pginas web demoran mucho tiempo en cargar.

Posible Problema

Accin Sugerida

El cable desde el PC al router

ADSL est en mal estado

1. Utilice una herramienta para revisarse el cable

efectivamente est daado.
2. Revise el estado de los conectores
3. Cambie el cable por uno que usted tenga la certeza
que est bueno.

El cable desde el router hacia el

DSLAM est en mal estado

1. Utilice una herramienta para revisarse el cable

efectivamente est daado.
2. Revise el estado de los conectores
3. Cambie el cable por uno que usted tenga la certeza
que est bueno.

97

El ancho de banda est limitado

1. Revise el parmetro max rate en el DSLAM y

aumente su valor.

Tabla 4-21: Problemas de Throughput en enlaces ADSL

4.7.2.2 Problemas de disponibilidad en enlaces ADSL

Sntoma: No hay disponibilidad de Internet

Posible Problema

Accin Sugerida

No hay conectividad entre el PC

y el router ADSL

1. Revise si estn ambos equipos conectados con un

cable RJ-45.
2. Asegrese que el cable est en buen estado.
3. Revise el estado de los conectores.

No hay conectividad entre el

router ADSL y el DSLAM.

1. Revise que ambos equipos estn conectados

mediante un cable RJ-11.
2. Asegrese que el cable est en buen estado.
3. Revise el estado de los conectores.
4. Asegrese que se est conectando a una puerta
ADSL del DSLAM.

No est activa la puerta del

DSLAM

1. Ingrese al DSLAM y en el men port setup active

la puerta a la que est conectado el router.

No est configurado el PVC en

el DSLAM

1. Verifique si est creado el PVC. Para esto ingrese

al men port setup, luego escoga la puerta a la que
se est conectando el router e ingrese a channel
setup. Si est creado debiera aparecer ah.
2. Si no est creado, presione add e ingrese los
valores de VPI/VCI correspondientes.

No est activo el PVC en

el DSLAM

1. Verifique si est o no activo el PVC. Para esto

ingrese al men port setup, luego escoja la puerta a
la que est conectado el router e ingrese a channel
setup. Luego seleccione el PVC que corresponda y
revise que est marcado el botn active.
2. En caso de no estar marcado el botn active,
mrquelo.

No est configurado el PVC en

el router ADSL

1. Verifique si est configurado el PVC en el router.

Para esto ingrese al men WAN setup.
2. Si no est configurado el PVC, configrelo con los
98

mismos valores utilizados en el DSLAM.

Estn mal configurados los
parmetros de QoS

Est deshabilitado el easy

setup profile

Hay un problema de
encapsulacin de enlace de datos

1. Si est configurado el QoS como CBR o UBR, ok.

2. Si desea utilizar VBR, utilice los valores adecuados
de PCR, SCR y MBS.
1. Ingrese al men Display/Change Connection
Profile, luego a Easy Setup Profile y seleccione
enabled yes.
1. Escoja encapsulacin RFC 1483 en el router.
2. Escoja none en el campo de underlying
encapsulation en el router.
3. Escoja en modo bridged para la encapsulacin RFC
1483.
Estas modificaciones deben ser realizadas en el men
Easy Setup/Connection Profile 1: Easy Setup Profile
Aqu se pueden distinguir dos casos:

Hay un problema de DHCP

Hay un problema con el modo

de direccionamiento IP

Existe un problema de NAT

Hay un filtro mal configurado

1. Si se desea que el router acte como DHCP, se debe

configurar ste para funcionar como servidor
DHCP. Adems se debe configurar el PC para que
un servidor DHCP le asigne su direccin IP.
2. Si se desea que el router no acte como DHCP, se
debe asignar la direccin IP al PC en forma manual.
1. Utilice el modo de direccionamiento numerado.
Esto debe ser configurado en el router. Para esto,
ingrese al men Easy Setup/Connection Profile 1:
Easy Setup Profile, y ah seleccione en IP
addressing: numbered
1. Verifique la existencia de la lista de mapeo de NAT.
Si sta no existe, debe ser creada. Esto se hace en el
men WAN Setup.
2. Verifique que est habilitado el NAT. En caso de no
estarlo, habiltelo. Esto se hace tambin en el men
WAN Setup.
1. Revise las configuraciones de los filtros, para
permitir el paso del trfico desde y hacia Internet.
Esto se realiza dentro del men WAN Setup.

99

Hay un problema de mscaras o

Default Gateway del PC

1. Revise que la mscara de subred sea la que

corresponde en el PC.
2. Utilice la direccin correcta para el Default
Gateway.

Tabla 4-22: Problemas de disponibilidad en enlaces ADSL

4.7.3 Esquemas de Troubleshooting

En esta seccin se muestran los esquemas de troubleshooting para el acceso a travs del router
Netopa 3347W y el DSLAM Zyxel 1000 series. Estos esquemas sirven para resolver problemas
de conectividad hacia Internet. Se debe realizar la prueba de ping hacia una direccin IP de
Internet (por ejemplo www.google.cl) luego de cada modificacin en la configuracin de los
equipos para verificar si se resolvi el problema. Esto no se incluy en los esquemas para efectos
de simplicidad del mismo sin embargo es de suma importancia ya que de lo contrario se llegar al
final del esquema an cuando el problema se halla resuelto en el primer paso. Los esquemas se
muestran en las Figuras 4-13 y 4-14:

Figura 4-13: Esquema troubleshooting ADSL (1)

100

Figura 4-14: Esquema troubleshooting ADSL (2)

101

4.8 Troubleshooting QoS en VoIP

El primer objetivo de la calidad de servicio (Quality of Service o QoS) es mejorar el servicio de
las redes y hacerlas ms predecibles al asignarles ancho de banda dedicado, jitter controlado,
latencia controlada, y mejorando las prdidas de paquetes asociadas a estas redes. QoS logra
estos objetivos entregando herramientas para el manejo de congestin de redes, ajustando el
trfico presente, usando los enlaces de manera ms efectiva y configurando polticas de trfico a
travs de la red.
Cuando las llamadas VoIP se han establecido, el siguiente paso es verificar que la calidad de voz
sea buena. Se deben considerar los siguientes aspectos para lograr obtener una Buena calidad de
audio:

Entender cunto ancho de banda usa una llamada VoIP usando diferentes cdecs,
incluyendo las cabeceras de capa 2/IP/UDP/.
Entender las caractersticas de la red IP por donde viajan las llamadas. Asegurar que el
delay y el jitter estn siendo controlados y eliminados en la medida de lo posible. Un
retraso (delay) en el camino de ida (o de vuelta) no debe exceder los 150 ms segn la
recomendacin G.114.
Usar una tcnica de encolamiento que permita que el trfico VoIP sea identificado y
priorizado.
Cuando se est transmitiendo VoIP sobre enlaces de baja velocidad, considere usar
tcnicas de fragmentacin a nivel de capa 2, tales como Multilink Point-to-Point Protocol
(MLPPP) con Link Fragmentation and Interleaving (LFI) en enlaces punto a punto, o
FRF.12 en enlaces Frame Relay. La fragmentacin de paquetes largos permite tener
menos jitter y delay en la transmission de trfico VoIP debido a que los paquetes pueden
ser intercalados en el enlace.
Intentar realizar las llamadas con diferentes codecs y habilitando/deshabilitando el
detector de actividad de voz (voice activity detector o VAD) para entender la utilizacin
del DSP involucrado en el procesamiento de la voz.

Con VoIP, cuando se realiza un proceso de resolucin de problemas asociados a QoS, se debe
tener en consideracin especialmente por paquetes perdidos y cuellos de botella que puedan
causar delay y jitter.
Especficamente, mirar alguno de los siguientes casos:

Prdidas en las interfaces

Prdidas en los buffers de encolamiento
Prdidas por policy-maps
Congestin en las interfaces
Congestin en los enlaces
102

Cada interfaz en el camino de la llamada VoIP debe ser examinada y se deben eliminar tanto las
prdidas de paquetes como la congestin. Adems el tiempo de viaje o round-trip delay debe ser
reducido al mnimo posible. Los pings entre los puntos extremos de la llamada VoIP dan una
indicacin del delay del enlace. Este tiempo de retraso no debe exceder los 300 ms en la medida
de lo posible. Si el delay es superior a este valor, los esfuerzos se deben enfocar a que este delay
sea constante, es decir, reducir el jitter o delay variable.

4.8.1.1 Problemas Comunes en QoS para VoIP

Algunos temas comunes relacionados con la calidad de servicio son los siguientes:

El delay en las redes de voz

Prdida de paquetes
Ajuste de jitter
Ajuste de eco
Ajuste del nivel de la voz

La siguiente tabla muestra algunos problemas de QoS que se puede encontrar en la configuracin
de puertos de voz en gateways de voz y algunos remedios a stos3.

Sntoma
El aparato telefnico vibra o no
suena

Conversacin distorsionada

La msica en espera (MOH) no

se escucha

Accin sugerida
Use el comando show voice port para confirmar que la
frecuencia de sonido de llamada est configurada
correctamente. Esta debe concordar con la frecuencia
asociada al aparato telefnico.
Use el comando show voice port para confirmar que el
cptone (tambin conocido como region tone) est
configurado de acuerdo a la configuracin adecuada a la
regin donde se est usando el servicio.
Reduzca el nivel umbral de msica para hacer que el VAD
sea menos sensitivo usando la configuracin de musicthreshold

El sonido ambiente no se escucha

Habilite el comando comfort-noise

Pausas largas en la conversacin,

como si se estuviera hablando
por walkie-talkie

El delay probablemente es excesivo; el delay adecuado

debe ser menor a 150 ms en una de las vas. Mida el delay
enviando pings a distintas horas del da con diferentes
niveles de congestin en la red. Si el delay debe
disminuirse, examine el delay de propagacin de la
seales entre en transmisor y el receptor, el delay de

Los comandos estn referidos a sistemas con IOS del proveedor Cisco

103

codificacin, y el tiempo de paquetizacin para distintos

cdecs VoIP.
Delay variable, o jitter estn siendo introducidos por
congestin en la red de paquetes. Existen dos posibles
remedios:
Conversacin entrecortada o
poco fluida

Conversacin confusa o cortada

1. Reducir la cantidad de congestin en la red de

paquetes. Los pings entre terminales VoIP dan
informacin del RTT el que no debe superar los
300 ms. El encolamiento en los nodos de la red y
la prdida de paquetes tambin deben ser
examinados.
2. Aumentar el tamao del buffer de jitter con el
comando playout-delay.
Reduzca la ganancia de entrada
Cambie el nivel de VAD. A veces VAD corta el sonido
prematuramente y la voz de un hablante se corta. Tambin
puede cambiar el perodo de tiempo en que el VAD
espera por un silencio.

Conversacin cortada

Reduzca el nivel de entrada del equipo del usuario que

est escuchando.

Volumen muy bajo o se pierden

las seales DTMF

Aumente el nivel de salida al equipo de la persona que

habla o bien el nivel de entrada del equipo del que
escucha.

El intervalo de eco es mayor que

25 ms (suena como una voz
separada)
Mucho eco

Configure el comando echo-cancel enable y aumente el

valor echo-cancel coverage.
Reduzca el nivel de salida en el Puerto de voz del
hablante.

Tabla 4-23: Troubleshooting para la calidad de voz en puertos de voz

4.8.1.2 Delay en redes de voz

El delay es el tiempo que le toma a los paquetes de voz viajar entre dos terminales. Cuando es
excesivo puede causar problemas de calidad con trfico en tiempo real como la voz. Sin embargo,
debido a la velocidad de los enlaces y el procesamiento de datos en los equipos intermedios,
siempre se espera tener algo de delay en las transmisiones.
Cuando est escuchando una conversacin, el odo humano puede aceptar hasta unos 150 ms de
delay sin darse cuenta. El estndar G.114 de la ITU recomienda no tener ms de 150 ms de delay
104

en un sentido en una conversacin normal de voz. Cuando se excede este valor, la conversacin
es ms como un "walkie-talkie" en donde una persona debe esperar a que la otra pare de hablar
antes de empezar a hablar.
Distintos tipos de delay se combinan para generar el delay total entre los terminales asociados a
las llamadas de voz:
1. Delay de codificacin: Corresponde a la cantidad del tiempo que usa el DSP para
comprimir las muestras de audio.
2. Delay de manejo: Es el tiempo que tarda el procesamiento de los datos (aadir cabeceras,
muestrear, formar paquetes, etc).
3. Delay de serializacin: Es un retardo fijo relacionado al tiempo de reloj de las interfaces.
Este tiempo de retardo se muestra en la tabla 2.

Tamao del frame

Velocidad de
la lnea

1 Byte 64 Bytes

56 kpbs

143 s

9 ms

18 ms

36 ms

72 ms

144 ms

214 ms

64 kbps

125 s

8 ms

16 ms

32 ms

64 ms

128 ms

187 ms

128 kbps

62.5 s 4 ms

8 ms

16 ms

32 ms

64 ms

93 ms

256 kbps

31 s

4 ms

8 ms

16 ms

32 ms

46 ms

512 kbps

15.5 s 1.28 ms

2 ms

4 ms

8 ms

16 ms

23 ms

768 kbps

10 s

640 s

1.28 ms 2.56 ms 5.12 ms 10.24 ms 15 ms

1536 kbps

5 s

320 s

640 s

2 ms

128
Bytes

256
Bytes

512
Bytes

1024
Bytes

1.28 ms 2.56 ms 5.12 ms

1500 Bytes

7.5 ms

Tabla 4-24: Tiempo de retardo por serializacin

4. Delay de propagacin: Es el tiempo que tardan los paquetes en viajar a travs del medio
fsico.
5. Delay de encolamiento: Es la cantidad de tiempo debido a la congestin. Cada
dispositivo de red entre dos terminales involucrados en una llamada es una fuente
potencial de encolamiento o delay debido a los buffers de almacenamiento. Use una traza
generada por un sniffer en cada nodo para ver dnde se introduce delay o jitter.
6. Delay variable o jitter: Es el tiempo que causa que la comunicacin se corte o que sea
inentendible.

105

Los rangos recomendables para el delay se muestran en la Tabla 4-25. Estos rangos son para
conexiones donde el eco es controlado. Los canceladores de eco son necesarios cuando el delay
en un sentido sobrepasa los 25 milisegundos.

Recomendacin de la
ITU

Recomendacin para redes

privadas

0 a 150 milisegundos

0 a 200 milisegundos

Aceptable para la mayora de las

aplicaciones.

150 a 400 milisegundos

200 a 250 milisegundos

Aceptable si los administradores

estn concientes del tiempo de
transmisin y de su impacto en la
calidad de voz.

Sobre 400 milisegundos

Sobre 250 milisegundos

Aceptable en la mayora de las

situaciones.

Descripcin

Tabla 4-25: Tiempos de retardo recomendados para VoIP

4.8.1.3 Prdida de paquetes

La prdida de paquetes es una causa comn de problemas de calidad en la transmisin de voz en
una red IP. En una red adecuadamente diseada, sta debe ser cercana a cero. Los codecs de voz
pueden tolerar cierto porcentaje de prdida de paquetes sin tener un gran efecto en la calidad de la
voz. Los paquetes de audio deben ser marcados para tener una prdida de paquetes cercana a
cero. En redes de datos y voz, la cantidad de llamadas simultneas y el ancho de banda para el
enlace de datos deben ser limitados. El ancho de banda para las llamadas debe ser garantizado
dndole prioridad al trfico de voz. La prdida de paquetes puede tener un impacto en la calidad
de voz de diferentes maneras:

La prdida de paquetes puede crecer a medida que aumenta el nmero de llamadas

simultneas.
Las transmisiones de fax y de mdem son mayormente afectadas por la prdida de
paquetes.

Una causa frecuente de prdida de paquetes es la incompatibilidad en la configuracin del

duplex. Esto ocurre cuando un lado de la conexin est configurado para transmitir en full duplex
mientras que el lado opuesto est configurado para transmitir en half duplex. Mire el enlace
donde se est produciendo la prdida de paquetes y revise la configuracin de modo duplex en
ambos extremos para cerciorarse que no sea sta la causa de las prdidas.

106

A pesar que la incompatibilidad de modo duplex es comn, existen otras causas que producen
prdida de paquetes. Para encontrar la causa de este problema, revise las interfaces de los
extremos del segmento donde se estn produciendo las prdidas usando el comando show
interface. Si los paquetes descartados aparecen en alguna interfaz, el enlace puede estar
sobreutilizado o puede haber otro trfico inesperado en ese enlace. En este caso use un analizador
de red (o sniffer) para revisar que trafico puede estar congestionando el enlace.

4.8.1.4 Ajuste de jitter

El delay puede causar efectos poco naturales de comienzo y trmino de conversaciones, pero el
delay variable (tambin conocido como jitter) puede causar que la conversacin se corte y se
vuelva inentendible. El jitter no es usualmente un problema con las llamadas en la PSTN debido a
que el ancho de banda en estas llamadas es fijo y cada una tiene un circuito dedicado durante toda
la llamada. Sin embargo, en las redes VoIP, el trfico de datos puede ser variable, y el jitter en la
red de paquetes se vuelve ms significante.
Los paquetes asociados a una misma conversacin pueden llegar en diferentes tiempos,
especialmente en horas de congestin en la red, lo que interrumpe la llegada constante y continua
de paquetes, cosa que es necesaria para las llamadas de voz. Los gateway de voz de Cisco tiene
incorporado un buffer dedicado a compensar una cierta cantidad de jitter; el comando playoutdelay puede ser ajustado para modificar el buffer dedicado al jitter.
Normalmente, las caractersticas por defecto del buffer de jitter son adecuados para la mayora de
las redes. Sin embargo un pequeo playout-delay puede causar prdida de paquetes y audio
entrecortado, y un gran playout-delay puede causar un delay terminal a terminal demasiado alto.

107

Captulo 5:

Discusin

En esta seccin se realiza una discusin de los resultados presentados en el captulo anterior. Se
analizan los resultados obtenidos en cada una de las secciones.
Con respecto a los parmetros de desempeo se puede decir que son de suma importancia a la
hora de realizar labores de troubleshooting. El parmetro de desempeo ms importante es la
disponibilidad, ya que garantiza que un enlace est arriba, es decir, que exista conectividad a
nivel fsico, y adems que los elementos que proporcionan dicha conectividad funcionen
correctamente. Si no hay disponibilidad del enlace no tiene sentido hablar de los dems
parmetros de desempeo, ya que todos ellos dependen primero de que exista disponibilidad.
El segundo parmetro ms importante es sin duda el throughput, o tasa de transferencia efectiva.
Este parmetro es de gran importancia para la mayora de los servicios, ya que cuando es muy
pequeo su valor, se ve afectada la calidad de los servicios. Puede provocar, por ejemplo, que la
carga de pginas web sea muy lenta para el acceso a Internet.
La prdida de paquetes tambin es un parmetro muy importante, en especial para los servicios
que utilizan el protocolo UDP. Esto se debe a que este protocolo es utilizado para aplicaciones de
tiempo real como ToIP o VoD, las cuales se pueden ver afectadas de forma importante por las
prdidas de paquetes. Esto no es igual de crtico en el caso de servicios que utilizan el protocolo
TCP, ya que en estos casos el protocolo se encarga de retransmitir los paquetes que se han
perdido.
Una de las herramientas ms importantes y la ms utilizada en el troubleshooting de redes en
general es el comando ping. Esto se debe a que es utilizada para determinar si hay o no
disponibilidad del enlace. Como la disponibilidad es el parmetro ms importante, obviamente la
herramienta de medicin ms importante ser la que se utilice para medir este parmetro.
La otra herramienta que es de mucha importancia es Iperf. Se utiliza principalmente para medir
throughput, pero tambin entrega valores de RTT y prdida de paquetes. Es una herramienta de
software que funciona en base a un modelo cliente servidor y para utilizarla slo se necesita un
PC. Se puede montar sobre Windows o Linux, lo cual es otra gracia que hace de esta herramienta
una de las ms importantes principalmente por su simpleza.
Otra de las herramientas utilizadas fue IP SLA, que es de gran importancia para la telefona ya
que permite medir MOS, que es un parmetro que representa la calidad de la voz. Esto evita tener
que realizar llamadas y evaluar la calidad en forma subjetiva.

108

De los servicios descritos en la seccin 4.3 se trabaj, para efectos de troubleshooting, slo con el
acceso a Internet de mejor esfuerzo y lneas de voz o telefona. Esto ya que se consider que
eran los ms importantes dentro de la amplia gama de servicios a los que se puede acceder a
travs de las redes de telecomunicaciones. Para el acceso a Internet se pudo verificar como afecta
el throughput a este servicio, y se apreci que afecta principalmente el tiempo que se demora en
cargar un determinado sitio web. Para la telefona un parmetro importante es el delay, ya que
dependiendo del valor (promedio) de este, una conversacin telefnica fluir o no con
naturalidad. Si el delay es muy grande se har muy difcil establecer una comunicacin buena
entre ambas partes.
Las redes TCP/IP, as como las redes basadas en el modelo OSI, requieren tcnicas modeladas
para la identificacin y solucin de problemas. Un tratamiento sistemtico asegura que los
problemas sean detectados y resueltos a tiempo, y que la red est arriba y funcionando. Los
problemas de red pueden ir desde simples problemas de conectividad entre dos puntos terminales
hasta equipos de red mal configurados en la red.
Se puede hacer una distincin entre los distintos tipos de problemas que se presentan en una red
de acuerdo al impacto que stos. Por una parte un problema de hardware en un equipo que se
encuentra en el ncleo de una red puede dejar sin servicio a un gran nmero de usuarios, en
cambio un problema de software en el PC de un determinado usuario lo afectar solamente a l.
Desde el punto de vista del troubleshooting ser mucho ms importante resolver rpidamente el
problema que afecta a una gran cantidad de usuarios.
Tambin se puede hacer una distincin en base al tipo de cliente que presenta una falla, ya que
para el proveedor del servicio ser ms importante resolver una falla que afecta a un cliente
importante y por lo tanto se le dar ms prioridad a l. Es por esto que es muy importante saber
exactamente que infraestructura de red es la que utiliza cada usuario para acceder a la red, ya que
en presencia de una falla no se debe perder tiempo tratando de descubrir cual es el punto de
acceso del usuario afectado.
Los esquemas presentados en la seccin de troubleshooting para TCP/IP son de gran utilidad en
diversas situaciones. Esto se debe a que en la mayora de los casos pueden existir problemas que
afectan a la capa de red, y es precisamente a esta capa a la que apuntan los procedimientos
descritos en la seccin 4.4. El conjunto de sntomas, posibles problemas y soluciones presentados
en dicha seccin es bastante completo y permite resolver prcticamente cualquier problema que
tenga su raz a nivel de la capa de red.
La seccin 4.5 describe los procedimientos de troubleshooting para ambientes de LAN switching.
El anlisis realizado para los problemas de conectividad de las puertas es aplicable, en parte,
tambin a otras tecnologas, ya que muchos de los problemas aqu planteados son ms bien
generales, por ejemplo problemas relacionados con cables malos o problemas del hardware de los
equipos.

109

Las tablas y esquemas de troubleshooting presentados en dicha seccin permiten realizar una
resolucin de fallas en forma bastante eficiente, ya que se encuentran detallados todos los
problemas tpicos que se dan en ambientes LAN switching. Lo nico que puede variar en estos
esquemas son los comandos utilizados, los que dependern de tipo de switch que se utilice y de la
versin del sistema operativo de los equipos.
Dentro de las pruebas realizadas son de gran importancia las pruebas de throughput, ya que
permiten conocerla mxima tasa de transferencia que es capaz de soportar un determinado enlace.
Esto es de utilidad cuando se desea montar un servicio y se quiere saber si el funcionamiento va a
ser el adecuado. Dependiendo del tipo de servicio del que se trate el requerimiento de ancho de
banda ser distinto. Conociendo entonces el throughput que puede soportar un enlace, se puede
saber que servicios se pueden montar sobre l.
Para el troubleshooting de ADSL se realizaron modificaciones en la configuracin del router y el
DSLAM que formaban el enlace. Con esto se logr obtener una idea de los efectos que tena cada
una de las modificaciones sobre los parmetros de desempeo. Se pudo apreciar que para la
mayora de las modificaciones que se realizaban, se perda la conectividad. Es por esto que el
troubleshooting realizado est enfocado principalmente a problemas de este tipo. Esto se debe a
que el enlace entre el router y el DSLAM es nico y no presenta redundancia, por lo que si
presenta un mal funcionamiento, los datos no cuentan con un camino alternativo para transitar,
perdindose as la disponibilidad de los servicios.
A partir de las pruebas con el comando ping de la seccin 4.7.1, se obtiene que utilizando la tabla
es posible hacer troubleshooting usando como herramienta nicamente este comando. Se debe
enviar ping a las cinco direcciones que corresponden a un sitio web (por ejemplo
www.google.cl), al gateway de Internet, al DSLAM, a la interfaz WAN del router ADSL y a la
interfaz LAN del router. Luego se puede comparar los resultados obtenidos con la tabla para ver
cuales son las posibles causas del problema. Esto puede ser una forma muy rpida y fcil de
acotar el problema, ya que en base a los resultados obtenidos se pueden descartar varias posibles
causas del problema.
Hay que ser muy cuidadoso al utilizar el comando ping, ya que en ocasiones los equipos (routers,
switches o PCs) estn configurados para rechazar las peticiones de eco ICMP (ping) y por lo
tanto el resultado de esta prueba podra ser interpretado de forma equivocada si no se toman las
debidas precauciones al realizarla.
Se puede realizar una discusin tambin respecto del maletn del troubleshooter. Este se describe
en detalle en la memoria de ttulo de Andrs Bobadilla Diseo e Implementacin de un sistema
de Instrumentacin para telefona IP econmico con fines docentes. Es de suma importancia
contar con los sistemas de instrumentacin adecuados para poder realizar un buen
troubleshooting. Las herramientas necesarias pueden variar dependiendo del sistema con el que
se est trabajando. En este caso en particular el maletn descrito est pensado para realizar
troubleshooting para telefona IP. Se realizan adems consideraciones monetarias de donde se
110

desprenden dos versiones del maletn; la versin completa (sin considerar limitaciones
monetarias) y la versin econmica.
Sin la instrumentacin adecuada es imposible realizar un buen troubleshooting por lo que es muy
importante saber que herramientas son las que se necesitan en una determinada situacin para
poder realizar las mediciones adecuadas y lograr as un diagnstico y una solucin eficaz.

111

Captulo 6:

Conclusiones

6.1 Importancia del troubleshooting

En cualquier sistema existir siempre la posibilidad de una falla, y estar preparado para
enfrentarla de buena forma es fundamental. En sistemas de redes las fallas deben ser resueltas en
el menor tiempo posible. Es de particular importancia el caso de las fallas en el acceso a las
redes. Esto se debe a que una falla en este eslabn en la mayora de los casos se traduce en una
interrupcin total del servicio.
La tendencia actual tanto de clientes residenciales como de las empresas es estar siempre
conectados, y una interrupcin en el servicio es indeseable. Ya que es imposible evitar
totalmente que esto suceda, la mejor alternativa consiste en poseer procedimientos que permitan
resolver las fallas de una forma rpida. Esto es el troubleshooting.
Para llevar a cabo un buen troubleshooting es necesario ser ordenado y utilizar una metodologa
adecuada, ya que de lo contrario se puede terminar invirtiendo mucho tiempo sin obtener
resultados satisfactorios. Se pudo comprobar que tanto el modelo de troubleshooting por capas
como el modelo de los ocho pasos de Cisco son de gran utilidad a la hora de resolver fallas. El
primero porque proporciona una forma de determinar por donde se empieza a realizar el
troubleshooting (que capa del modelo OSI) y el segundo porque entrega una secuencia de pasos
ordenados a seguir para realizar la semiosis, diagnosis, prognosis y el tratamiento, es decir,
el troubleshooting.
Adems de la importancia del troubleshooting mismo, esta memoria apunta a las tecnologas
Ethernet y ADSL, que son dos de las ms ampliamente difundidas en lo que a tecnologas de
acceso se refiere. Esto hace que sea de particular importancia contar con procedimientos de
troubleshooting para estas tecnologas.

6.2 Aportes al troubleshooting

Se realizaron aportes importantes al troubleshooting en esta memoria. Esto se realiz
particularmente para las tecnologas Ethernet y ADSL, a las cuales se les dio un tratamiento
desde el punto de vista prctico. Sin embargo tambin se abordaron las tecnologas de Cable
Mdem y SHDSL desde una perspectiva ms terica y sin mucho nfasis en el troubleshooting,
sino que ms bien en un anlisis terico de las tecnologas.
Para Ethernet se realiz la validacin de los procedimientos de troubleshooting para lo cual hubo
que montar distintas maquetas de pruebas. Se valid informacin de troubleshooting relativa a
Autonegociacin Half/Full Duplex y 10/100 Mbps, Etherchannel, ISL Trunking y el Protocolo
112

Spanning Tree, entre otros. Este trabajo permiti un acercamiento inicial al troubleshooting y
tambin proporcion un modelo para la documentacin de los posibles problemas y las
respectivas acciones sugeridas (ambas asociadas a determinados sntomas), el que sera
posteriormente utilizado para el caso de ADSL.
Para ADSL se utiliz un enlace esttico y sin autenticacin de usuario, con encapsulacin RFC
1483 en modo bridged. Se crearon, a partir de determinados sntomas, tablas en las que se
enumeran posibles problemas que pueden estar causando los sntomas, cada uno asociado a
diversas acciones que se pueden tomar para eliminar el problema. Esto se hizo basado en el
modelo de Ethernet, como se mencion anteriormente. Tambin se crearon esquemas de
troubleshooting en los que se realizan preguntas y en base a las respuestas se sugiere tomar
determinadas acciones, o se pasa a la siguiente pregunta. Adems de esto se propone un esquema
alternativo para realizar troubleshooting basado en la salida entregada por el comando ping. Todo
esto en su conjunto permite realizar un buen troubleshooting para ADSL.
Un aporte importante al troubleshooting es el poder contar con un listado de las fallas ms
comunes que se dan en un determinado ambiente o tecnologa. Para el caso de las tecnologas de
acceso, la gran mayora de los errores en el enlace (ya sea de configuracin, equipos o cables
defectuosos, etc.) llevan a dos sntomas, que son la prdida de disponibilidad del enlace y el bajo
throughput.

6.3 Acerca de la metodologa

La metodologa aplicada en este trabajo consisti en lo siguiente. Primero se mont un acceso
que operara de buena forma, a lo que se le llam condiciones ideales de operacin. Una vez
que se tena este sistema funcionando correctamente, se procedi a realizar modificaciones de
diversos tipos, e ir documentando los efectos que cada modificacin tena sobre el sistema (esto
se meda en base a los parmetros de desempeo). Se realizaron todas las modificaciones posibles
en el enlace, tanto en los componentes fsicos, como en las configuraciones de los equipos. Una
vez que se tuvo una buena cantidad de informacin se procedi a generar los esquemas de
troubleshooting.
Durante este proceso se pudo observar que distintas modificaciones llevaban a un mismo sntoma
(por ejemplo, la prdida de disponibilidad del enlace puede ser causada por una infinidad de
factores). Esto vindolo en forma inversa sera que a un sntoma se le pueden asociar muchas
hiptesis diagnsticas. Es por esto que el diagnstico rara vez es inmediato.
Se debe mencionar que los esquemas generados deben ser sujetos a una validacin, ya que slo
fueron utilizados en un ambiente controlado de laboratorio, y siempre en la forma de
troubleshooting inverso. Para esto se necesitan dos personas: una que realice las
modificaciones en el sistema, y otra que se apoye en los documentos para realizar el
troubleshooting.

113

6.4 Importancia de la instrumentacin

La instrumentacin es una parte fundamental para poder hacer troubleshooting. Si no se cuenta
con las herramientas adecuadas ser muy difcil realizar la labor en forma eficiente, si es que se
logra realizar. Dentro de este contexto, el comando ping es de suma importancia y
afortunadamente la mayora de los equipos de red permiten enviar estas solicitudes de eco ICMP.
La importancia de este comando radica en que permite determinar si hay o no disponibilidad de
un determinado enlace en forma bastante rpida. En pocas palabras, sin herramientas de medicin
no se puede realizar troubleshooting. He aqu la importancia de la instrumentacin.

6.5 Trabajo Futuro

Si bien se pretendi abarcar la mayor cantidad de problemas que surgen en las redes de acceso,
hay un gran tema que se qued fuera de esta memoria. Corresponde al tema de la seguridad.
Existe una gran cantidad de ataques a la seguridad de los sistemas de redes, por lo que sera
interesante incorporar los mismos desde el punto de vista del troubleshoooting. Sera ideal
conocer los procedimientos ptimos para recuperar un sistema de redes luego de un determinado
ataque. Esto no es un tema menor, ya que existe una gran cantidad de amenazas a la seguridad de
las redes.
La principal forma de enfrentar este tipo de problemas es a travs de la prevencin, es decir,
evitar que ocurran los ataques. Sin embargo, tal como sucede en las fallas en sistemas de redes, es
tambin imposible estar totalmente protegido e inmune a este tipo de situaciones. Debe por lo
tanto estar previsto que este tipo de cosas debe suceder y no vernos sorprendidos sin saber que
hacer cuando los hechos ocurren.
Existe otra tecnologa que est ampliamente difundida al igual que el ADSL. sta es el Cable
Mdem, del cual se encuentra una resea terica en uno de los anexos. Sera de gran importancia
poder realizar troubleshooting para esta tecnologa, dada la amplia difusin que sta tiene sobre
todo en el sector residencial. Es por esto que sera interesante la realizacin de un trabajo futuro
orientado a este tema.

114

Captulo 7:

Bibliografa

7.1 Libros y Documentos Electrnicos

[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]

Networking TCP/IP Analysis and Troubleshooting Toolkit, Kevin Burns, 2003.

Comparativa de Tecnologas de Acceso a Redes IP, Juan Ignacio Alfaro de Prado,
Memoria de Ttulo ICE, Universidad de Chile, 2005.
Diseo e Implementacin de un Sistema de Instrumentacin para Telefona IP
Econmico con Fines Docentes, Andrs Bobadilla, 2006.
Ethernet: The Definitive Guide, Charles E. Spurgeon, 2000.
Cisco Internetworking & Troubleshooting, Cormac S. Long, 2000
Cisco Ip Routing Protocols Troubleshooting Techniques, V. Anand and K.
Chakrabarty, 2004
Metodologa de apoyo al diagnstico mdico: aplicacin a enfermedades
cardiovasculares, Claudio Prez F., 1985.
Technical Report TR-017, ATM over ADSL Recommendation, 1999.
RFC1242 Benchmarking Terminology for Network Interconnection Devices.
RFC 2285 Benchmarking Terminology for LAN Switching Devices.
RFC 2330 Framework for IP Performance Metrics.
RFC 2544 Benchmarking Methodology for Network Interconnection Devices.
RFC 2679 A one way delay metric for IPPM.
RFC 2889 Benchmarking Methodology for LAN Switching Devices.
Building Cisco Multilayer Switched Networks, Karen Webb, CCIE, 2001
Upgrading and Repairing Networks, Terry William Ogletree, 2003.
Sams Teach Yourself Network Troubleshooting in 24 hours, Jonathan Feldman, 1998.
Practical Industrial Data Networks: Design, Installation & Troubleshooting, Steve
Mackay, 2004.
Network Troubleshooting Tools, Joseph D. Sloan, 2001.
Internetwork Troubleshooting Guide, Cisco.
Troubleshooting de Tecnologas de Acceso Emergentes, Gonzalo Daz Meza,
Memoria de Ttulo ICE, Universidad de Chile, 2006.

7.2 Sitios de Internet

(1) www.Cisco.com Pgina genrica de informacin de equipamiento Cisco
(2) http://www.wikipedia.org Enciclopedia electrnica abierta
(3) http://www.eicon.com/support/training/SlideShow2.asp?p=ADSL_Tech Informacin
terica acerca de la tecnologa ADSL.
(4) http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/atm.htm Informacin terica
acerca de la tecnologa ATM.
115

(5) http://techrepublic.com.com/5100-1035-5902706-2.html Documento sobre

troubleshooting por capas.
(6) http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ethernet.htm#wp1020560
Informacin terica sobre redes Ethernet.
(7) http://www.fujitsu.com/downloads/TEL/fnc/pdfservices/ethernet-prerequisite.pdf
Informacin terica sobre redes Ethernet.
(8) http://www.mcmcse.com/cisco/guides/hierarchical_model.shtml Tecnologas de acceso y
modelo jerrquico de redes.
(9) http://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1/tr1901.htm Troubleshooting
overview, modelo de los ocho pasos de Cisco.
(10) http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/introint.htm#xtocid5
Informacin acerca del modelo OSI.
(11) http://www.raduniversity.com/networks/1994/osi/layers.htm Informacin acerca del
modelo OSI.
(12) http://www.cisco.com/univercd/cc/td/doc/cisintwk/itg_v1/tr1920.htm Referencia de
Cisco para Troubleshooting en ambientes LAN.
(13) http://chapters.scte.org/newengland/reference/Cable_Modems/Contents.htm Informacin
acerca de Cable Mdem.
(14) http://www.cable-modems.org/tutorial/14.htm Informacin referida a Cable Mdem.
(15) http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/transbdg.htm Protocolo
Spanning Tree.
(16) http://www.cisco.com/univercd/cc/td/doc/product/lan/cat5000/rel_5_2/config/ Protocolo
Spanning Tree.
(17) http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/prod_troubleshooting_guide_
chapter09186a008055851f.html Troubleshooting QoS en VoIP.
(18) http://es.wikipedia.org/wiki/TCP/IP Troubleshooting TCP/IP.

116

Captulo 8:

Anexos

8.1 Spanning Tree Protocol (STP)

Para comprender la utilidad del protocolo Spanning Tree, se debe analizar primero el
funcionamiento de los transparent bridges para ver que sucede cuando estos operan en un
ambiente en que existen links redundantes y, por lo tanto, tambin mltiples caminos para llegar
desde un host de origen a uno de destino dentro de la red.

8.1.1 Operacin de Transparent Bridges

Por definicin, un transparent bridge debe hacer lo siguiente:
-

No debe modificar los frames que pasan a travs de l.

Debe aprender las direcciones escuchando en las puertas la direccin MAC de la fuente.
Si una direccin fuente proviene de una puerta especfica, el bridge aprende que dicha
direccin se encuentra en esa puerta. Este luego construye una tabla donde se almacenan
todas las direcciones que ha ido aprendiendo. Un bridge est siempre escuchando y
aprendiendo.
Cuando recibe un broadcast, ste debe replicar el frame en todas las puertas, excepto en la
cual recibi el broadcast.
Si una direccin MAC de destino se desconoce (an no ha sido aprendida), el bridge debe
replicar el frame en todas las puertas, excepto en la cual recibi el frame.
Cuando recibe un frame, puede filtrarlo, si el destino del mismo es a travs del puerto que
se recibe, o replicarlo en todas las puertas en el caso en que el destino se encuentre en otra
puerta.

En la Figura 8-1, el bridge aprende la ubicacin del host A y del host B escuchando las
direcciones de origen de los frames que cada uno enva. Luego de esto, el bridge construye una
tabla con las direcciones MAC y las respectivas puertas donde se encuentran dichas direcciones.
Esta tabla se llama CAM (Content Addressable Memory) en un switch Cisco. Cuando el host A
enva algo al host B, el switch busca en la tabla CAM la puerta correspondiente y luego enva el
frame a dicha puerta.

Figura 8-1: Transparent bridge

117

Este proceso debe ser transparente para los equipos en la red, por lo que el bridge no debe realizar
modificacin alguna a los frames. En un ambiente simple, y sin links redundantes, el transparent
bridging funciona perfectamente, sin embargo, cuando existen links redundantes comienzan los
problemas. En la Figura 8-2 se ve que el host A ahora posee dos caminos alternativos para llegar
hasta el host B.

Figura 8-2: Bridging loop en una red con links redundantes

Cuando el host A transmite hacia el host B y ninguno de los dos bridges tiene al host B en sus
tablas de direcciones, sucede lo siguiente:
Paso 1: El host A transmite el frame en la red 2 (que es donde se encuentra este host como se ve
en la figura). Los dos bridges que estn conectados a dicha red (red 2) reciben el frame e
incorporan a su tabla de direcciones que el host A vive en la red 2.
Paso 2: Ambos switches envan el frame hacia la red 1. Ahora no solamente el host B recibe el
frame, sino que ambos switches tambin vern que el frame viene del otro switch. Debido a una
de las caractersticas bsicas del transparent bridging, que es escuchar la direccin de origen con
el fin de aprenderla e incorporarla a sus tablas, cada switch aprender ahora que el host A se
encuentra en la red 1. Los switches ahora asumen incorrectamente que los frames para el host A
deben ser enviados a la red 1. Adems de esto, cada switch ve un nuevo frame que debe ser
entregado sin darse cuenta que est viendo el mismo frame anterior.
Paso 3: El frame es entonces nuevamente enviado hacia la red 2, de donde originalmente
provino. Este es el comienzo de un loop. Dado que ninguno de los switches sabe de la existencia
del otro, ambos envan continuamente el frame a travs de la otra puerta. Y as el loop contina
para siempre.

118

8.1.2 Protocolo Spanning Tree

Este protocolo fue creado para sobreponerse a los problemas originados por el transparent
bridging en redes con links redundantes. El propsito de este protocolo es evitar y eliminar los
loops en la red a travs de la creacin de un camino libre de loops a travs de un root bridge
como se ve en la Figura 8-3. Esto lo hace determinando donde hay loops en la red y bloqueando
los links redundantes. De esta forma se garantiza que existir solamente un camino para cada
destino, de tal forma que un loop no pueda ocurrir. En caso de falla de un link, el root bridge
sabr que existe un link redundante y habilitara el link que se encontraba bloqueado para
recuperar la conectividad.

Figura 8-3: Camino libre de loops

El STP (Spanning Tree Protocol) ejecuta un algoritmo llamado Spanning Tree Algorithm (STA).
Para encontrar los links redundantes, el STA escoge un punto de referencia, llamado el root
bridge, y luego determina todos los caminos posibles hacia el punto de referencia. Si encuentra
caminos redundantes, determina el mejor camino para habilitarlo y bloquea todos los dems
caminos.
Si en algn momento, y debido a una falla, uno de los segmentos pertenecientes al Spanning Tree
se torna inalcanzable, el algoritmo Spanning Tree reconfigura la topologa para permitir que
dicho segmento sea accesible. Esto lo hace levantando algn link que se encontraba en estado
bloqueado.

8.1.2.1

Bridge Protocol Data Units

Todos los switches en una LAN que participan en STP recopilan informacin acerca de los otros
switches en la red a travs de un intercambio de mensajes. Estos mensajes se llaman Bridge
Protocol Data Units (BPDUs). Un BPDU se muestra en la Figura 8-4. La columna de la izquierda
indica el nmero de bytes de cada campo y la columna derecha indica el contenido de cada
campo.

119

Nmero de bytes Contenido del campo

2
Protocol ID
1
Version
1
Message Type
1
Flags
2
Root Priority
6
Root ID
4
Path Cost
2
Bridge Priority
6
Bridge ID
1
Port Priority
1
Port ID
2
Message Age
2
Max Age
2
Hello Timer
2
Fwd Delay

Figura 8-4: Formato BPDU

Los BPDUs se envan cada 2 segundos por cada puerta para asegurar una topologa estable y
libre de loops. A continuacin se explica algo sobre los contenidos de un BPDU:
-

Root information: Consiste en 2 bytes de root priority y 6 bytes de root ID. Esta
informacin indica que equipo ha sido elegido para ser el root bridge.

Path Cost: Indica que tan lejos del root bridge la BPDU ha viajado. Esta informacin se
utiliza para determinar que puertas debern estar arriba y cuales quedarn bloqueadas.

Bridge Information: Informacin acerca del bridge que envi la BPDU. Se usa para
indicar el bridge vecino que envi la BPDU y tambin el bridge designado que se utilizar
para llegar al root bridge. Esta informacin contiene el Bridge priority y el Bridge ID.

Port Information: Corresponde a 1 byte de Port Priority y 1 byte de Port ID. Tiene
informacin acerca de la puerta que envi la BPDU. Se utiliza para determinar que
puertas estarn arriba y cuales estarn bloqueadas.

Timers: Se utilizan para indicar cuanto tiempo demora el Spanning Tree en realizar cada
una de sus funciones. stas incluyen message age, max age, hello y fwd delay.

El intercambio de mensajes BPDU sirve para lo siguiente:

-

La eleccin de un root switch para la topologa estable de Spanning Tree.

La eleccin de un switch designado para cada segmento switcheado.
La eliminacin de loops poniendo las puertas redundantes en estado bloqueado.
120

8.1.2.2

Eleccin de un Root Bridge

El primer paso para crear un Spanning Tree libre de loops es la eleccin de un root bridge. Este
es un punto de referencia que los dems switches utilizan para determinar si hay loops en la red.
En un principio, el switch asume que l es el root bridge y setea la bridge ID igual a la root ID. El
bridge ID consta de dos componentes:
-

La prioridad (2 bytes): El switch setea este nmero. Por defecto, es el mismo para todos
los switches. En los switches Cisco la prioridad por defecto es 32768 o 0x8000.
Direccin MAC (6 bytes): La direccin MAC del switch o bridge.

La combinacin de estos dos nmeros determina quien ser el root bridge. Mientras ms pequeo
sea el nmero, mayor ser la probabilidad de que ese switch sea el root bridge. Si un switch ve
una root ID menor que la suya, incorpora esa root ID a sus BPDUs. Mediante el intercambio de
BPDUs, los switches determinan quien es el root bridge.
Ntese que si todos los equipos poseen la misma prioridad, el switch con la direccin MAC ms
pequea ser el root bridge. Mientras menor sea la prioridad, mayor la probabilidad de
convertirse en root bridge.

8.1.2.3

Asociacin con el Root Bridge

Luego de que se ha elegido al root bridge, cada switch deber formar una asociacin con el root
bridge. Esto lo realiza escuchando las BPDUs a medida que entran por todas las puertas. La
recepcin de BPDUs por ms de una puerta indica que existe ms de un camino hacia el root
bridge.
Con el fin de determinar que puertas del switch dejen pasar los datos y que puertas los bloquean,
el switch se fija en los siguientes tres componentes de las BPDUs:
-

Path Cost
Bridge Information
Port Information

Primero el switch mira el path cost para ver que puerta est recibiendo a travs del camino de
menor costo. El path cost se calcula basndose en la velocidad de los links y en la cantidad de
links que la BPDU atraves desde el root bridge. Es decir, se determina en base a la suma de los
path costs entre el origen y el destino.

121

Si una puerta tiene el menor path cost, sta deja pasar los datos. Todas las dems puertas que
estn recibiendo BPDUs se bloquean.
Si los path costs recibidos en distintas puertas son iguales, el switch mira la bridge ID para
determinar que puerta debiera quedar arriba. La puerta con la menor bridge ID se escoge para
quedar arriba mientras que las dems se dejan bloqueadas.
Si los path cost y bridge IDs son iguales, como en el caso de links paralelos, el que define el
empate es el port ID. La puerta con menor port ID queda arriba y las dems quedan bloqueadas.
El resultado del intercambio de BPDUs es el siguiente:
-

Un switch se elige como root bridge o switch.

Se calcula la ms corta distancia desde cada switch hacia el root switch.
Se selecciona un switch designado. Este es el switch que est ms cerca del root switch y
a travs del cual pasan los frames que van hacia el root switch. A veces se le llama
tambin parent switch.
Se selecciona un root port para cada switch. Esta es la puerta que proporciona el mejor
camino (de ms bajo costo) hacia el root switch.
Las puertas que no estarn arriba se ponen en estado bloqueado. Estas puertas continuarn
recibiendo BPDUs pero no podrn enviar o recibir datos.

8.1.2.4

Estado de las puertas en Spanning Tree

Para construir una red libre de loops, el Spanning Tree fuerza a cada puerta a pasar por varios
estados diferentes:
-

Blocked: Todas las puertas parten en este estado con el fin de prevenir que se cree un
loop. La puerta se mantendr en este estado si el Spanning Tree determina que hay un
mejor camino hacia el root bridge.

Listen: En este estado, la puerta puede escuchar los frames, pero no puede enviar ni
recibir datos. Tampoco se permite que ponga la informacin que recibe en sus tablas de
direcciones. Este estado se utiliza para indicar que la puerta est casi lista para transmitir
pero que prefiere escuchar un rato ms para asegurarse de no crear un loop. El switch
escucha por un perodo de tiempo llamado el fwd delay (forward delay).

Learn: Es muy similar al estado listen, excepto que en este estado se puede incorporar
informacin a las tablas de direcciones. Tampoco se permite enviar ni recibir datos en este
estado. El tiempo que se mantiene en este estado se llama tambin forward delay.

122

Forward: En este estado se puede enviar y recibir datos. Una puerta no se encontrar en
este estado a no ser que no existan links redundantes o se haya determinado que es el
mejor camino al root switch.

Disabled: Se puede encontrar una puerta en este estado por varias razones, entre las que
se incluyen problemas de hardware, la eliminacin de la VLAN nativa de la puerta, etc.

Si se borra la VLAN asignada a una puerta, la puerta pasa al estado disabled. La puerta vuelve a
estar habilitada si se asigna a una VLAN vlida o si se vuelve a crear la VLAN que se elimin.

8.1.2.5

Spanning Tree Timers

A medida que las BPDUs se propagan a travs de una red switcheada, pueden tener retrasos de
propagacin, los que ocurren debido a una serie de factores. Debido al largo de los paquetes,
procesamiento en los switches, utilizacin de ancho de banda, y otros. Como consecuencia de
esto, los cambios en la topologa pueden suceder en tiempos y lugares distintos en una red
switcheada. Cuando un switch pasa de un estado de no participacin a un estado forwarding se
pueden crear loops si el switch no conoce toda la informacin de la red.
El protocolo Spanning Tree implementa los llamados timers para forzar a las puertas a esperar
que les llegue la informacin correcta acerca de la actual topologa de la red. Estos se encuentran
seteados por defecto en el switch. Estos se han calculado basndose en el supuesto de que el
dimetro de la red es 7 y el hello timer es 2 segundos. Basndose en estos supuestos, la red
debiese converger a una topologa estable. Los valores seteados por defecto en los switches son
los siguientes:
-

Hello time: 2 segundos

Maximum time (max age): 20 segundos
Forward delay (fwd delay): 15 segundos

El dimetro se mide desde el root switch, y ste cuenta como el switch numero uno. Cada switch
que pasa hacia fuera se suma hasta llegar a la parte ms externa de la red obtenindose de esta
forma el dimetro real de la red. De ser necesario se debe modificar el dimetro de la red para
obtener as un mejor reflejo de la topologa real de sta.
Los tiempos tpicos que toman las transiciones entre los estados se muestran a continuacin:
-

de blocking a listening: 20 segundos

de listening a learning: 15 segundos
de learning a forwarding: 15 segundos
de forwarding a disabled en el evento de una falla

123

8.1.2.6
8.1.2.6.1

Manejo de Cambios en la Topologa

Propsito del mecanismo de Manejo de Cambios en la Topologa

Aprendiendo de los frames que recibe, un switch crea una tabla que asocia a cada puerta las
direcciones MAC que pueden ser alcanzadas a travs de esta puerta. Esta tabla es utilizada para
enviar los frames directamente a travs de la puerta que corresponde evitando as inundar todas
las puertas con los frames. Slo despus que un host ha estado en silencio por 300 segundos (5
minutos) su entrada desaparece de la tabla del switch. He aqu un ejemplo de por que es deseable
que este tiempo sea menor.
En la red de la Figura 8-5, asumamos que el bridge B1 est bloqueando su link hacia B4. A y B
son dos estaciones que han establecido una conexin. El trfico de A hacia B va a travs de B1,
B2, B3 y luego B4. El esquema muestra la tabla de direcciones MAC aprendida por los cuatro
bridges en esta situacin:

Figura 8-5: Manejo de cambios de la topologa

Ahora, asumamos que el link entre B2 y B3 falla. La comunicacin entre A y B es interrumpida
al menos hasta que B1 coloque su puerta hacia B4 en el estado forwarding (un mximo de 50
segundos con los parmetros por defecto). Sin embargo, cuando A quiere enviar un frame a B, B1
aun mantiene una entrada en su tabla que lo lleva a B2 y el frame es enviado a un hoyo negro.
Lo mismo sucede cuando B quiere enviar un frame a A. La comunicacin se pierde por 5
minutos, hasta que las entradas guardadas en las tablas para alcanzar A y B expiren.

124

Figura 8-6: Manejo de cambios en la topologa (2)

Las tablas de direcciones MAC implementadas en los bridges son bastante eficientes en una red
estable. Sin embargo, existen innumerables situaciones en las que el tiempo de expiracin de
cinco minutos es un serio problema luego de un cambio en la topologa. El mecanismo de
cambios en la topologa existe para este tipo de situaciones. Cuando un bridge detecta un cambio
en la topologa (un link se cae o pasa a forwarding), anuncia el evento a toda la red.
En la siguiente seccin (Principio de Operacin) se explica como esto es implementado. Todos
los bridges son notificados y reducen su tiempo de expiracin (aging time) al forward delay (15
segundos por defecto) por un cierto perodo de tiempo (max age + fwd delay). Es mejor reducir el
tiempo de expiracin en vez de borrar las tablas debido a que los host que estn activos y
transmitiendo trfico, no son borrados de las tablas.
8.1.2.6.2

Principio de Operacin

Esta seccin explica como un bridge avisa un cambio de topologa al nivel de las BPDUs. Ya se
ha explicado brevemente cuando un bridge considera que ha detectado un cambio en la topologa.
La definicin exacta de esto es:

Cuando una puerta que estaba en forwarding se cae.

Cuando una puerta pasa a forwarding y el bridge tiene una puerta designada.

El proceso de notificacin a todos los bridges de la red involucra dos pasos:

El bridge notifica al root bridge del spanning tree.

El root bridge enva un "broadcast" con la informacin a toda la red.

125

8.1.2.6.2.1 Notificacin al Root Bridge:

En la operacin normal del STP, un bridge recibe BPDUs de configuracin del root bridge en su
puerta root. Sin embargo, nunca enva una BPDU hacia el root bridge. Para lograr esto, una
BPDU especial, llamada BPDU de notificacin de cambio en la topologa (TCN por la sigla en
ingls) se introduce. Por lo tanto, cuando un bridge necesita avisar un cambio en la topologa,
comienza a enviar TCNs en su puerta root. El bridge designado recibe la TCN, toma
conocimiento, y genera otra TCN en su respectiva puerta root. El proceso contina hasta que la
TCN llega al root bridge.

Figura 8-7: Notificacin al root bridge

La TCN es una BPDU bastante simple que no contiene la informacin que un bridge enva cada
hello_time. El bridge designado toma conocimiento de la TCN mediante un envo inmediato de
una BPDU normal de configuracin con el bit de Topology Change Acknowledgement (TCA)
seteado. El bridge que notifica el cambio en la topologa no deja de enviar sus TCN hasta que
recibe la TCA.
8.1.2.6.2.2 Envo de Broadcast del evento a la red:

Una vez que el root bridge ha tomado conocimiento que ha habido un cambio en la topologa,
comienza a enviar sus BPDUs con el bit de TC seteado. Estas BPDUs son retransmitidas por
todos los bridges de la red con el bit TC seteado. Como resultado de esto, todos los bridges se
enteran del cambio en la topologa y reducen su tiempo de expiracin al fwd delay. Los bridges
reciben la BPDUs de cambio de topologa tanto en las puertas forwarding como en las
bloqueadas.
El bit TC queda seteado por el root por un tiempo igual al max age + fwd delay, que es 20+15=35
segundos por defecto.

126

Figura 8-8: Envo de broadcast del evento a la red

8.1.2.7

Como Funciona el PortFast

El PortFast del Spanning Tree produce que una puerta pase inmediatamente al estado forwarding
saltndose los estados listening y learning. Se puede utilizar PortFast en puertas de switches que
se hayan conectadas a una sola estacin de trabajo o a un servidor para permitir que estos equipos
se conecten a la red inmediatamente, en vez de esperar que la puerta pase por los estados
listening y learning antes de llegar al estado forwarding.
PortFast debe utilizarse solamente en puertas conectadas a una sola estacin de trabajo o
servidor, ya que de habilitarse PortFast en una puerta que est conectada a otro equipo como por
ejemplo un switch, pueden crearse loops.
En general, cuando el switch recin se enciende, o cuando un equipo se conecta a una puerta, sta
normalmente pasa al estado listening. Cuando expira el forward delay timer, la puerta pasa al
estado learning. Una vez que expira nuevamente el forward delay timer, la puerta pasa al estado
forwarding o blocking. Cuando se habilita el PortFast en una puerta, sta pasa inmediatamente al
estado forwarding.

8.1.2.8

Como Funciona el UplinkFast

El UplinkFast proporciona una rpida convergencia en la capa de acceso luego de un cambio en

la topologa del spanning tree utilizando los grupos uplink. Un grupo uplink corresponde a un set
de puertas (por VLAN), donde slo uno est en estado forwarding en un determinado momento.
Especficamente, un grupo uplink estar formado por la puerta root (en estado forwarding) mas
un set de puertas bloqueadas. El grupo uplink proporciona un camino alternativo en caso de que
la actual puerta en estado forwarding falle.

127

En la Figura 8-9 (paso 1) se ve un ejemplo de una topologa de red con UplinkFast. El switch A
(el root), est conectado directamente al switch B a travs del link L1 y al switch C a travs del
link L2. La puerta del switch C que se conecta al switch B a travs del link L3 est en estado
blocking.

Figura 8-9: Funcionamiento de Uplink Fast

Si el switch C detecta una falla en el link L2, UplinkFast desbloquea la puerta bloqueada en el
switch C y se produce una transicin hacia el estado forwarding inmediatamente, saltndose los
estados listening y learning (como se ve en el paso 2). Esta transicin demora aproximadamente 5
segundos.

8.1.2.9

Como Funciona el BackboneFast

El BackboneFast proporciona una rpida convergencia en la red luego de un cambio en la

topologa del spanning tree. Un switch detecta una falla indirecta de un link (una falla en un link
al que el switch no est directamente conectado) cuando el switch recibe un BPDU inferior de su
designated bridge en su puerta root o en alguna de sus puertas bloqueadas. Esta BPDU inferior
indica que el designated bridge ha perdido su conexin con el root bridge.
El switch trata de determinar si existe algn camino alternativo hacia el root bridge. Si la BPDU
inferior llega a una puerta bloqueada, la puerta root y las dems puertas bloqueadas sern
caminos alternativos hacia el root. Si la BPDU llega en la puerta root, todas las puertas
bloqueadas sern caminos alternativos hacia el root. Si la BPDU llega en la puerta root y no
existen puertas bloqueadas, el switch asume que ha perdido conectividad con el root switch, y se
transforma en el root switch, de acuerdo con las reglas del spanning tree.
Si el switch posee caminos alternativos hacia el root switch, transmite Root Link Query BPDUs
por todos los caminos alternativos hacia el root. Si el switch determina que an posee caminos
alternativos hacia el root, provoca que el maximum aging time expire en la puerta en que recibi
la BPDU inferior. Si todos los caminos alternativos hacia el root indican que el switch ha perdido
128

la conectividad con el root, provoca que el maximum aging time expire en todas las puertas en las
que recibi las BPDUs inferiores. Si uno o mas caminos alternativos an pueden conectarse con
el root, el switch transforma todas las puertas en que recibi BPDUs inferiores en puerta
designada sacndolas del estado blocking (si estaban en este estado), a travs de los estados
listening y learning y hacia el estado forwarding.
En la Figura 8-10 (Paso 1), se muestra un ejemplo de una topologa BackboneFast. El switch A
(el root), se conecta directamente al switch B a travs del link L1 y al switch C a travs del link
L2. La puerta del switch C que se conecta directamente al switch B a travs del link L3 est en
blocking.

Figura 8-10: Funcionamiento de Backbone Fast

Si el link L1 falla, el switch C detecta la falla en forma indirecta ya que no est conectado
directamente al link L1. El switch B ya no posee un camino hacia el root switch. BackboneFast
permite que la puerta bloqueada en el switch C pase directamente al estado listening sin esperar
que expire el maximum aging time. Luego, BackboneFast realiza la transicin de la puerta del
switch C hacia el estado forwarding, proporcionando as un camino del switch A al switch B.
Esto toma aproximadamente 30 segundos. En la Figura 7-10 (paso 2), se ve como el
BackboneFast reconfigura la topologa para remediarla falla del link L1.

129

8.2 ATM
ATM (Asynchronous Transfer Mode) es un estndar de la ITU-T que soporta servicios de voz,
datos y video utilizando celdas pequeas de tamao fijo. Las redes ATM son orientadas a la
conexin. La Figura 8-11 muestra una red ATM privada y una red ATM pblica que llevan
trfico de datos, voz y video.

Figura 8-11: Redes ATM pblicas y privadas con trfico de datos, voz y video

8.2.1 Equipos ATM y el Ambiente de la Red

ATM es una tecnologa de switcheo y multiplexacin de celdas que combina los beneficios del
switcheo de circuitos (capacidad garantizada y delay constante) con los del switcheo de paquetes
(flexibilidad y eficiencia para trfico intermitente). Proporciona ancho de banda escalable desde
unos pocos megabits por segundo (Mbps) hasta varios gigabits por segundo (Gbps). Debido a su
naturaleza asncrona, ATM es ms eficiente que las tecnologas sncronas, como TDM (Time
Division Multiplexing), por ejemplo.
En TDM, a cada usuario se le asigna una ranura de tiempo, y ninguna otra estacin puede
transmitir en dicha ranura. Si una estacin posee mucha informacin que desea transmitir, slo
puede hacerlo cuando le corresponde, aunque las dems ranuras de tiempo se encuentren
desocupadas. Sin embargo, si una estacin no tiene nada que transmitir cuando le corresponde su
turno, la ranura queda vaca y es desperdiciada. Debido a que ATM es asncrono, las ranuras de
tiempo estn disponibles bajo demanda.

130

8.2.2 Formato Bsico de las Celdas ATM

En ATM se transfiere la informacin en unidades de tamao fijo llamadas celdas. Cada celda
consta de 53 octetos o bytes. Los primeros 5 bytes contienen informacin de encabezado de la
celda, y los restantes 48 contienen los datos de usuario. Estas celdas pequeas y de tamao fijo
son buenas para transferir trfico de voz y video ya que este tipo de trfico es intolerante al delay
que se produce cuando se transfieren grandes paquetes de informacin. La Figura 8-12 ilustra el
formato bsico de una celda ATM.

Figura 8-12: Formato bsico de una celda ATM

8.2.3 Equipos ATM

Una red ATM est formada por switches ATM y puntos terminales ATM. Un switch ATM es
responsable del trnsito de las celdas a travs de la red. La tarea del switch ATM est claramente
definida: acepta la celda proveniente de un punto terminal o de otro switch ATM. Luego lee y
actualiza la informacin del encabezado y rpidamente switchea la celda hacia una interfaz de
salida en direccin al destino final.
Un punto terminal ATM (o sistema terminal) debe contener un adaptador de interfaz de red
ATM. Ejemplos de puntos terminales son estaciones de trabajo, routers, unidades digitales de
servicios (DSUs), switches LAN y codificadores-decodificadores de video (CODECs).

8.2.4 Interfaces de Red ATM

Una red ATM consta de un set de switches ATM interconectados por enlaces o interfaces punto a
punto. Los switches ATM soportan dos tipos principales de interfaces: UNI (User to Network
Interface) y NNI (Network to Network Interface). La UNI conecta sistemas terminales (como
hosts o routers) a switches ATM, mientras que la NNI sirve para conectar dos switches ATM.
Dependiendo de si el switch es privado y ubicado en las dependencias del cliente o si es pblico y
operado por la compaa telefnica, UNIs y NNIs se pueden subdividir en privadas y pblicas.
Una UNI privada conecta un punto terminal a un switch ATM privado. Su contraparte pblica
conecta un punto terminal o switch privado a un switch pblico. Una NNI privada conecta dos
131

switches ATM dentro de la misma organizacin privada. Una NNI pblica conecta dos switches
ATM dentro de una misma organizacin pblica. Adems se tiene la Broadband Intercarrier
Interface (B-ICI), la que conecta dos switches pertenecientes a distintos proveedores de servicios.
La Figura 8-13 muestra los distintos tipos de interfaces que pueden existir:

Figura 8-13: Tipos de interfaces en redes ATM

8.2.5 Formato de Encabezado de Celdas ATM

El encabezado de las celdas ATM puede ser UNI o NNI. El encabezado UNI se utiliza para las
comunicaciones entre puntos terminales ATM y switches ATM en redes privadas. El encabezado
NNI se utiliza para las comunicaciones entre switches ATM. La Figura 8-14 muestra el formato
bsico de los encabezados UNI ATM y NNI ATM.

Figura 8-14: Encabezados de celdas ATM UNI y ATM NNI

132

A diferencia del encabezado ATM UNI, el ATM NNI no incluye el campo GFC (Generic Flow
Control). Adems, el encabezado NNI tiene un campo VPI (Virtual Path Identifier) que ocupa los
primeros 12 bits, permitiendo troncales ms grandes entre switches ATM pblicos.

8.2.6 Campos del Encabezado de las Celdas ATM

A continuacin se describen los campos del encabezado ATM que se aprecian en la Figura 2-28:
Generic Flow Control (GFC): Proporciona funciones locales, como la identificacin de las
mltiples estaciones que comparten una interfaz ATM. Este campo en general no se usa y se
setea en su valor por defecto que es 0 (en binario 0000).
Virtual Path Identifier (VPI): En conjunto con el VCI, identifica el siguiente destino de una
celda a medida que sta pasa a travs de una serie de switches ATM en direccin a su destino
final.
Virtual Channel Identifier (VCI): En conjunto con el VPI, identifica el siguiente destino de una
celda a medida que sta pasa a travs de una serie de switches ATM en direccin a su destino
final.
Payload Type (PT): Indica en el primer bit si la celda contiene datos de usuario o de control. Si
contiene datos de usuario, el primer bit ser cero. Si contiene informacin de control, su valor
ser 1. El segundo bit indica congestin (0 indica que no hay congestin y 1 indica que hay
congestin), y el tercer bit indica si la celda es la ltima en una serie de celdas que representan un
frame AAL5 (1 indica que es la ltima celda del frame).
Cell Loss Priority (CLP): Indica si la celda puede ser descartada en caso de encontrarse con una
congestin extrema a medida que avanza a travs de la red. Si el bit vale 1, la celda deber ser
descartada antes que una que posee el valor 0.
Header Error Control (HEC): Puede detectar y corregir errores slo en los 4 primeros bytes del
encabezado. HEC puede corregir un error de un bit en estos bytes preservando as la celda en vez
de descartarla.

8.2.7 Servicios ATM

Existen tres tipos de servicio: Circuitos Virtuales Permanentes (PVCs), Circuitos Virtuales
Switcheados (SVCs) y servicio sin conexin (similar a SMDS).
Los PVCs permiten directa conectividad entre sitios. De esta forma, un PVC es similar a una
lnea dedicada. Una de sus ventajas es que garantiza la disponibilidad de una conexin y no
requiere de procesos de seteo entre switches. Una de sus desventajas es que la conectividad es

133

esttica y el seteo es en forma manual. En cada equipo entre la fuente y el destino debe ser
configurado manualmente el PVC.
Un SVC se crea y se destruye en forma dinmica y permanence utilizable solo mientras se
transfieren datos a travs de l. En este sentido, es similar a una llamada telefnica. El control
dinmico de la llamada requiere un protocolo de sealizacin entre el punto terminal y el switch.
Una ventaja de los SVCs es la flexibilidad de la conexin y el establecimiento de la llamada, el
que puede ser manejado en forma automtica por un equipo de red. Una desventaja sera el
tiempo extra que se requiere para establecer la conexin.

8.2.8 Conexiones virtuales en ATM

Las redes ATM son fundamentalmente orientadas a la conexin, lo que quiere decir que un canal
virtual (VC) debe crearse a travs de la red ATM previo a la transferencia de informacin.
Existen dos tipo de conexiones en ATM: virtual paths, los que se identifican mediante virtual
path identifiers (VPI); y virtual channels, los que se identifican mediante la combinacin de un
VPI y un virtual channel identifier (VCI).
Un virtual path es un conjunto de virtual channels, donde todos son switcheados en forma
transparente a travs de la red ATM basndose en el VPI comn. Sin embargo, todos los VPIs y
VCIs tienen significado local a travs de un enlace en particular, y son remapeados, segn
corresponda, en cada switch. Un camino de transmisin corresponde al medio fsico que
transporta los virtual paths y virtual channels. La Figura 8-15 muestra como los VCs al juntarse
forman VPs, los que a su vez, forman el medio de transmisin.

Figura 8-15: Virtual Channels, Virtual Paths y Medio de Transmisin

8.2.9 Operaciones de Switcheo en ATM

Las cedas se reciben a travs de un enlace con valores conocidos de VCI y VPI. El switch busca
los valores en una tabla de traduccin para determinar la puerta (o puertas) por las que debe
reenviar la celda y los nuevos valores de VPI/VCI para ese enlace. El switch entonces retransmite
la celda en dicho enlace con los identificadores de conexin apropiados. Dado que todos los VPIs
134

y VCIs tienen significado local a travs de un enlace en particular, estos valores son remapeados,
segn sea necesario, en cada switch.

8.2.10

Modelo de Referencia ATM

La arquitectura ATM utiliza un modelo lgico para describir la funcionalidad que soporta. La
funcionalidad de ATM corresponde a la capa fsica y parte de la capa de enlace de datos del
modelo OSI. El modelo ATM se compone de los siguientes planos, que atraviesan todas las
capas:
Control: Este plano es el responsable de la generacin y administracin de los requerimientos de
sealizacin.
User (Usuario): Este plano es el responsable de la transferencia de datos.
Management (Administracin): Este plano contiene dos componentes:
1. La administracin de capas se encarga de las funciones especficas de las capas, como la
deteccin de fallas y problemas de protocolo.
2. La administracin de planos se encarga de coordinar las funciones relacionadas con el
sistema como un todo.
El modelo de referencia ATM se compone de las siguientes capas ATM:
Physical Layer (Capa Fsica): Anloga a la capa fsica del modelo OSI, esta capa maneja la
transmisin dependiente del medio.
ATM Layer (Capa ATM): Combinada con la capa de adaptacin ATM (ATM adaptation layer),
la capa ATM es aproximadamente anloga a la capa de enlace de datos del modelo OSI. Esta
capa es la responsable de la utilizacin simultnea del medio fsico por parte de los circuitos
virtuales (multiplexacin de celdas) y del paso de dichas celdas a travs de la red ATM. Para
esto, se utiliza la informacin de VPI y VCI en los encabezados de las celdas ATM.
ATM adaptation layer (AAL): En conjunto con la capa ATM, la AAL es aproximadamente
anloga a la capa de enlace de datos del modelo OSI. La AAL es responsable de aislar a las capas
superiores de los detalles de los procesos ATM. Esta capa prepara los datos de usuario para
convertirlos en celdas y segmenta los datos en trozos de 48 bytes.
Por ltimo, las capas superiores que se encuentran sobre la AAL aceptan los datos de usuario, lo
insertan en paquetes, y se los entregan a la AAL. La Figura 8-16 muestra el modelo de referencia
ATM.
135

Figura 8-16: Modelo ATM relacionado con las dos capas ms bajas del modelo OSI

8.2.10.1

La Capa Fsica de ATM

La capa fsica del modelo ATM tiene cuatro funciones: convertir las cedas en un tren de bits,
controlar la transmisin y recepcin del tren de bits a travs del medio fsico, rastrear los lmites
de las celdas, y paquetizar las celdas en el tipo de frames adecuados para el medio fsico.
Esta capa se divide en dos partes: la subcapa dependiente del medio fsico (physical mdium
dependent o PMD) y la subcapa de convergencia de transmisin (transmisin convergente o TC).
La subcapa PMD proporciona dos funciones claves: Primero, sincroniza la transmisin y la
recepcin a travs del envo y recepcin de un flujo contnuo de bits con informacin de
sincronizacin. Segundo, especifica el medio fsico utilizado, incluyendo conectores y cables.
Ejemplos de medios fsicos tpicos utilizados en ATM incluyen SDH/SONET, DS3/E3, 155
Mbps utilizando fibra multimodo (MMF) usando el esquema de codificacin 8B/10B, y 155
Mbps 8B/10B sobre par trenzado protegido (STP).
La subcapa TC tiene cuatro funciones: delineacin de las celdas, generacin y verificacin de
secuencia de control de error de encabezado (header error control o HEC), desacople de la tasa de
celdas y adaptacin de la transmisin de frames. La funcin de delineacin de celdas mantiene
los lmites de las celdas ATM, permitiendo que los equipos ubiquen sus celdas en un tren de bits.
La generacin y verificacin de la secuencia de HEC genera y revisa el cdigo HEC para
asegurar que los datos son vlidos. El desacople de la tasa de celdas mantiene la sincronizacin e
inserta o suprime celdas ATM ociosas para adaptar la tasa de celdas ATM vlidas a la capacidad
136

del sistema de transmisin. La adaptacin de la transmisin de frames paquetiza las celdas ATM
en frames aceptables para la implementacin de capa fsica.

8.2.10.2

ATM Adaptation Layers: AAL1

AAL1, un servicio orientado a la conexin, es apropiado para manejar fuentes de tasa de bits
constante (constant bit rate o CBR), como voz o videoconferencia. ATM transporta el trfico
CBR utilizando servicios que emulan circuitos. AAL1 requiere sincronizacin temporal entre la
fuente y el destino. Es por esto que AAL1 depende de un medio que soporte un reloj, como
SONET.
El proceso AAL1 prepara una celda para su transmisin en tres pasos: Primero, muestras
sncronas (por ejemplo 1 byte de datos a una tasa de muestreo de 125 ms) son insertadas en el
campo de datos. Segundo, los campos Sequence Number (SN) y Sequence Number Protection
(SNP) se agregan para proporcionar informacin que el AAL1 receptor utiliza para verificar que
ha recibido las celdas en el orden correcto. Tercero, el resto del campo de datos se llena hasta
completar 48 bytes.

8.2.10.3

ATM Adaptation Layers: AAL2

Existe otro tipo de trfico que tiene requerimientos similares a los de CBR. Corresponde al
trfico con tasa de bits variable (variable bit rate o VBR). Este tipo de trfico tpicamente incluye
voz o video paquetizados que no poseen una velocidad de transmisin constante pero si poseen
requerimientos similares a los de servicios con CBR. AAL2 es apropiado para trfico VBR. El
proceso AAL2 utiliza 44 bytes para los datos de usuario y reserva 4 bytes para soportar los
procesos AAL2. El trfico VBR se caracteriza ya sea como de tiempo real (VBR-RT) o no
tiempo real (VBR-NRT). AAL2 soporta ambos tipos de trfico.

8.2.10.4

ATM Adaptation Layers: AAL3/4

AAL3/4 soporta servicios orientados a la conexin y servicios sin conexin. Fue diseado para
proveedores de servicios de redes y est alineado con Switched Multimegabit Data Service
(SMDS). AAL3/4 se utiliza para transmitir paquetes SMDS a travs de una red ATM. AAL3/4
prepara una celda para ser transmitida en cuatro pasos:
Primero, la subcapa de convergencia (CS) crea una PDU (Protocol Data Unit) colocando una
marca al comienzo del frame y un campo de largo al final del frame. Segundo, la subcapa de
segmentacin y reensamble (SAR) segmenta la PDU y le aade un encabezado. Luego la subcapa
SAR agrega un campo CRC-10 al final de cada PDU para control de errores. Por ltimo, la PDU
SAR completa se transforma en el campo de datos de una celda ATM, a la que la capa ATM le
agrega el encabezado ATM estndar.

137

En AAL3/4 en encabezado SAR PDU consiste en los campos Type, Sequence Number y
Multiplexing Identfier. El campo Type identifica si la celda corresponde al comienzo,
continuacin o final de un mensaje. El campo Sequence Number identifica el orden en que las
celdas debieran se reensambladas. El campo Multiplexing Identifier determina que celdas de
distintas fuentes de trfico se encuentran en el mismo VCC (Virtual Circuit Connection) para que
las celdas correctas sean reensambladas en el destino.

8.2.10.5

ATM Adaptation Layers: AAL5

AAL5 es la principal AAL para datos y soporta servicios de datos orientados a la conexin y sin
conexin. Se utiliza para transferir la mayora de los datos que no son SMDS, como IP sobre
ATM y LAN emulation (LANE). Tambin se le conoce como la capa de adaptacin simple y
eficiente (Simple and Efficient Adaptation Layer o SEAL) dado que la subcapa SAR
simplemente acepta el CS-PDU y lo segmenta en SAR-PDUs de 48 octetos sin reservar bytes en
cada celda.
AAL5 prepara las celdas para la transmisin en tres pasos: Primero, la subcapa CS aade un
campo de largo variable al comienzo y 8 bytes al final. El campo de largo variable asegura que la
PDU resultante sea de 48 bytes de largo. Los 8 bytes del final incluyen el largo del frame y un
CRC de 32 bits calculado a partir de toda la PDU. Esto permite que el proceso de recepcin del
AAL5 detecte errores de bits, prdida de celdas, o celdas que estn fuera de secuencia. Segundo,
la subcapa SAR segmenta las CS-PDUs en bloques de 48 bytes. No se agrega nada ni al
comienzo ni al final (a diferencia de AAL3/4) por lo que los mensajes no pueden ser intercalados.
Finalmente, la capa ATM coloca cada bloque dentro del campo de datos de una celda ATM. Para
todas las celdas excepto para la ltima, un bit en el campo Payload Type (PT) se setea en 0 para
indicar que la celda no es la ltima en una serie que representa un solo frame. Para la ltima
celda, el bit en el campo PT toma el valor 1.

8.2.11

Direccionamiento ATM

El estndar de la ITU-T se basa en el uso de direcciones E.164 (similares a los nmeros

telefnicos) para redes ATM pblicas (B-ISDN). El ATM Forum extendi el direccionamiento
ATM para incluir redes privadas. Se decidi por el modelo de direccionamiento por subredes en
que la capa ATM es la responsable del mapeo entre las direcciones de la capa de red y las
direcciones de la capa ATM. Este modelo de subred es una alternativa a la utilizacin de
direcciones y protocolos de la capa de red. El ATM Forum defini un formato de direcciones
basado en la estructura de las direcciones del OSI Network Service Access Point (NSAP).

8.2.11.1

Modelo de Direccionamiento de Subredes

El modelo de direccionamiento de subredes desacopla la capa ATM de cualquier protocolo de

capas superiores, como IP o IPX. Por lo tanto, requiere de un esquema de direccionamiento y
protocolos de ruteo totalmente nuevos. A cada sistema ATM se le debe asignar una direccin
ATM, adems de las direcciones correspondientes a protocolos de capas superiores. Esto requiere
138

de un protocolo de resolucin de direcciones ATM (ATM ARP) para mapear las direcciones de
capas superiores a sus direcciones ATM correspondientes.

8.2.11.2

Direcciones ATM de Formato NSAP

El formato de direcciones ATM NSAP de 20 bytes est diseado para ser utilizado en redes ATM
privadas, mientras que las redes pblicas tpicamente utilizan las direcciones E.164. El ATM
Forum especific una codificacin NSAP para las direcciones E.164, que se utiliza para codificar
las direcciones E.164 en redes pblicas, pero estas direcciones tambin pueden ser utilizadas en
algunas redes privadas. Dichas redes privadas pueden basar su propio direccionamiento (formato
NSAP) en las direcciones E.164 de la UNI pblica a la que estn conectados y pueden tomar el
prefijo de la direccin del nmero E.164, identificando los nodos locales con los bits de ms bajo
orden.
Todas las direcciones ATM con formato NSAP constan de tres componentes: el identificador de
autoridad y formato (Authority and Format Identifier o AFI), el identificador del dominio inicial
(Inicial Domain Identifier o IDI), y la parte especfica del dominio (Domain Specific Part DSP).
La AFI identifica el tipo y el formato del IDI, el que a su vez, identifica la asignacin de
direccin y la autoridad administrativa. El DSP contiene informacin de ruteo.
Resumido de otra forma, los prmeros 13 bytes del prefijo NSAP son los que responden a la
pregunta Qu switch? Cada switch debe poseer un valor que lo identifique unvocamente. Los
equipos conectados al switch heredan el mismo valor del prefijo como parte de su propia
direccin NSAP. El prefijo es utilizado por los switches para soportar el ruteo ATM. Los
siguientes 6 bytes, llamados End Station Identifier (ESI), identifican el elemento ATM que est
conectado al switch. Cada elemento conectado al switch debe tener un valor nico de ESI
(identificador de estacin terminal). El ltimo byte, llamado el selector (SEL), identifica el
proceso dentro del equipo al que apunta la conexin.
Los tres formatos de direccionamiento privado ATM difieren en la naturaleza de la AFI e IDI. En
el formato E.164 codificado con NSAP, la IDI es un nmero E.164. En el formato DCC, la IDI es
un cdigo de datos de pas (Data Country Code o DCC), que identifica pases en particular, segn
lo especificado en la ISO 3166. En el formato ICD, la IDI es un designador internacional de
cdigo (ICD). Los cdigos ICD identifican organizaciones internacionales particulares. El ATM
Forum recomienda a las organizaciones o redes proveedores de servicios de redes privadas que
utilicen ya sea los formatos DCC o ICD con su propio plan de numeracin.

8.2.12

Conexiones ATM

ATM soporta dos tipos de conexiones: punto a punto y punto/multipunto. Las punto a punto
conectan dos sistemas terminales ATM y pueden ser unidireccionales (comunicacin en un solo
sentido) o bidireccionales (comunicacin en ambos sentidos). Las punto/multipunto conectan un
solo sistema terminal fuente hacia mltiples sistemas terminales de destino. Este tipo de
139

conexiones pueden ser slo unidireccionales. Los nodos raz pueden transmitir hacia las
hojas, pero no al revs. Tampoco puede haber comunicacin entre las hojas sobre la misma
conexin. Se realiza la rplica de las celdas en los switches en los que la conexin se separa en
dos o ms ramas.
Sera deseable que en las redes ATM pudiesen existir conexiones bidireccionales multipuntomultipunto. Este tipo de conexiones son anlogas a las capacidades de broadcasting o
multicasting en LANs de medio compartido como Ethernet o Token Ring. Desafortunadamente,
esto no puede ser implementado utilizando AAL5, que es la ms comn de las AAL para
transmitir datos a travs de una red ATM.
A diferencia de AAL3/4, que posee un campo identificador de mensajes (MID), AAL5 no
proporciona una forma en su formato de celdas para intercalar celdas provenientes de distintos
paquetes AAL5 en una sola conexin. Esto significa que todos los paquetes AAL5 enviados a
una direccin particular a travs de una determinada conexin deben ser recibidos en secuencia;
de lo contrario, el proceso de reensamblado ser incapaz de reconstruir los paquetes. Es por esto
que las conexiones punto multipunto con AAL5 pueden ser slo unidireccionales. Si un nodo
hoja transmitiera un paquete AAL5 hacia la conexin, por ejemplo, sera recibido tanto por el
nodo raz como tambin por todos los otros nodos hoja. En las hojas, el paquete podra ser
intercalado con los paquetes enviados por la raz y posiblemente por otras hojas, impidiendo el
reensamble los paquetes.

8.3 Cable Mdem

Es un trmino que se refiere a aquellos dispositivos capaces de permitir el transporte de datos a
alta velocidad a travs de una red de televisin por cable. Esta red puede estar basada
completamente en cable coaxial o puede ser una red HFC (Hybrid Fiber Coaxial), la cual
combina el cable coaxial con la fibra ptica. Existen al menos tres estndares para el cable
mdem: IEEE 802.14, DOCSIS y DVB/DAVIC. El estndar ms utilizado en Chile es DOCSIS
versin 1.1 sobre redes HFC.
La velocidad de una conexin de cable mdem est entre los 3 y los 50 Mbps y la distancia puede
llegara superar los 100 km. El CMTS (Cable Modem Termination System) puede hablar con
todos los Cable Mdems, pero stos slo pueden hablar con el CMTS. Si un Cable Mdem
necesita hablar con otro, debe hacerlo a travs del CMTS. El stack de protocolos para una
implementacin basada en el estndar DOCSIS se ve como se muestra en la Tabla 8-1:
Lo que aparece en parntesis corresponde a EuroDOCSIS, que es una versin de DOCSIS con
ciertas modificaciones en la capa fsica orientadas al Mercado europeo.

140

OSI

DOCSIS

Capas Superiores

Aplicaciones

Capa de Transporte

TCP/UDP

Capa de Red

IP

Capa de Enlace de Datos

Capa Fsica

Mensajes
de Control
DOCSIS
IEEE 802.2

Upstream

Downstream

TDMA (mini-slots)
5 - 42(65) MHz
QPSK/16-QAM

TDM (MPEG)
42(65) - 850 MHz
64/256-QAM
ITU-T J.83 Annex B(A)

Tabla 8-1: Stack de protocolos para implementacin basada en DOCSIS

8.3.1 Redes de TV cable (CATV)

El punto central de una red de TV cable es el Head End o cabecera, que se encarga de generar las
seales de televisin, datos y telefona que se distribuyen a los abonados. Esta se conecta
mediante un enlace troncal del cual cuelgan splitters que se encargan de dividir el trfico para as
proveer una amplia cobertura geogrfica. De aqu salen los enlaces de alimentacin. Las seales
se atenan a medida que viajan por la red, por lo que deben ser amplificadas aproximadamente
cada 1 kilmetro. Los abonados se conectan a los enlaces de alimentacin mediante cables
coaxiales. Estos son de aproximadamente 10 metros y se conectan al cable de alimentacin
mediante un tap. Con esta distribucin se forma una topologa de red similar a un rbol. En el que
la raz es el Head End y los usuarios son las hojas.
Con una mejora en el sistema, es posible permitir que las seales fluyan en ambas direcciones.
Las ms altas frecuencias fluyen hacia el abonado y las ms bajas en la otra direccin.

8.3.2 Redes HFC

Una red HFC (Hybrid Fiber Coaxial) combina transmisin mediante fibra ptica y cable coaxial.
Tpicamente est dividida en tres sectores: red troncal, red de distribucin y red de acceso. De
estas tres partes, las dos primeras son implementadas utilizando fibra ptica y solamente la red de
acceso se implementa usando cable coaxial. Las redes HFC son la evolucin de las redes basadas
nicamente en cable coaxial. Las razones que motivaron la migracin hacia este tipo de redes
hbridas son: la capacidad insuficiente de las redes coaxiales puras para la transmisin de datos a
altas velocidades, la mayor confiabilidad de las redes HFC y las prdidas en la calidad de la seal
al alimentar a gran cantidad de abonados.

141

La red troncal est constituida por el Head End y por los nodos pticos primarios. El Head End es
el elemento encargado de la difusin de las seales de televisin, la transmisin y recepcin de
datos, y de la conexin con las centrales de telefona. La funcin de los nodos pticos primarios
de la red troncal es la de transmitir las seales provenientes del Head End hacia los nodos de
distribucin y viceversa.
La red de distribucin ptica es la encargada de conectar un nodo ptico primario con varios
nodos de distribucin, los cuales son los encargados de realizar la conversin ptico elctrica de
las seales. Un nodo ptico de distribucin puede cubrir un rea entre 500 y 2000 abonados.
Por ltimo, la red de distribucin de cable coaxial es la que conecta un nodo de distribucin con
los usuarios finales. Generalmente la divisin se realiza en zonas que abarcan entre 125 y 500
casas, y se dispone de al menos un amplificador por cada zona.
Con respecto a las bandas de frecuencia que se utilizan, el cable coaxial que recibe cada abonado
tiene un ancho de banda tpico de 750 MHz, pudiendo llegar hasta 1 GHz. Este ancho de banda
disponible es utilizado por los canales de televisin analgicos, canales de televisin digital, y
canales para la transmisin de datos.

8.3.3 Tipos de Cable Mdem

Las tres configuraciones que se muestran a continuacin son las ms utilizadas en la actualidad.
Estas son: cable mdem externo, cable mdem interno, y set top box interactivo.

8.3.3.1 Cable Mdem Externo

El cable mdem externo consiste en una pequea caja externa que se conecta al computador
generalmente a travs de un cable Ethernet. Lo malo es que se debe agregar una tarjeta de red al
PC antes de conectarlo al cable mdem. Lo bueno es que se puede conectar ms de un
computador. Adems, el cable mdem funciona con la mayora de los sistemas operativos y
plataformas de hardware. Otra interfaz para un cable mdem externo es el USB, que tiene la
ventaja de una ms rpida instalacin. Lo malo es que se puede conectar slo un PC con un cable
mdem basado en USB.

Figura 8-17: Cable Mdem Externo

142

8.3.3.2 Cable Mdem Interno

El cable mdem interno tpicamente es una tarjeta PCI para el PC. Esta es la implementacin ms
barata que existe actualmente, pero tiene algunas desventajas. El principal problema es que slo
puede utilizarse en PCs de escritorio. Se pueden incluir en MACs y laptops pero requieren de un
diseo especial.

Figura 8-18: Cable Mdem Interno

8.3.3.3 Set Top Box Interactivo

El set top box interactivo es en realidad un cable mdem disfrazado. La principal funcin del set
top box es proporcionar una mayor cantidad de canales de televisin en el mismo nmero
(limitado) de frecuencias. Esto es posible gracias a la utilizacin de la codificacin de televisin
digital (DVB). Este sistema proporciona un canal de retorno generalmente a travs del sistema
telefnico tradicional (POTS), que permite que el usuario realice navegacin por pginas web,
revise correo electrnico, etc. directamente en la pantalla de televisin.

Figura 8-19: Set Top Box Interactivo

8.3.4 Instalacin Tpica de un Cable Mdem

Cuando se instala un cable mdem, usualmente se requiere un splitter y un nuevo cable. El
splitter divide la seal para las viejas instalaciones y el nuevo segmento se conecta al cable
mdem. No se aceptan televisiones en el segmento que va al cable mdem.
La seal transmitida desde el cable mdem puede ser tan intensa que cualquier televisin que se
conecte en la misma rama puede sufrir severas perturbaciones. El aislamiento del splitter
generalmente no es suficiente, por lo que se aade un filtro pasa altos adicional en el segmento
que va hacia los televisores. El filtro slo deja pasar las frecuencias correspondientes a los
canales de televisin.

143

8.3.5 Interfaces de Datos

En cualquier tipo de cable mdem externo, se necesita algn tipo de interfaz de datos que conecte
el computador al cable mdem.

8.3.5.1 Ethernet
En la mayora de los mdems externos, la interfaz de datos es una Ethernet de 10 Mbps. Se
podra argumentar que se necesitan 100 Mbps para poder lograr la capacidad mxima de bajada
del cable mdem (27-56 Mbps), pero esto no es cierto. Incluso en una muy buena instalacin, un
cable mdem no puede mantener una tasa de 10 Mbps de bajada, dado que este ancho de banda
es compartido por varios usuarios.

8.3.5.2 USB (Universal Serial Bus)

Con este tipo de interfaz la instalacin se hace ms fcil para los usuarios con menos habilidades
computacionales. Esto dado que no se necesita abrir el computador para instalar la tarjeta de red
Ethernet si se posee una interfaz USB. Por supuesto, en el caso que el PC no posea interfaz USB,
esta deber ser instalada, volviendo a la situacin anterior.

8.3.6 Interior del Cable Mdem

Los cable mdem en general son diferentes. Pueden ser externos, internos, o incluso set top boxes
interactivos, pero a pesar de esto, poseen ciertos componentes funcionales que son comunes para
todos ellos. Esto se ilustra en la Figura 8-20, y a continuacin se describen las caractersticas
principales de cada componente.

Figura 8-20: Interior del Cable Mdem

144

8.3.6.1 Sintonizador (Tuner)

El sintonizador (tuner) se conecta a la salida del cable, a veces precedido por un splitter que sirve
para separar los datos de Internet de los canales de TV. Lo que hace es simplemente recibir la
seal modulada y entregarla al demodulador. En algunos casos, el sintonizador contendr un
diplexor, que le permite hacer uso de un set de frecuencias (generalmente entre 42 y 850 MHz)
para el trfico de bajada, y otro set (entre 5 y 42 MHz) para los datos de subida. Otros sistemas,
generalmente aquellos con capacidad ms limitada, utilizarn el sintonizador del cable mdem
para los datos de bajada, y un mdem dial-up telefnico para el trfico de subida. En ambos
casos, luego de recibir la seal, el sintonizador se la pasa al demodulador.

8.3.6.2 Demodulador
Los demoduladores ms comunes tienen cuatro funciones. Un demodulador de QAM
(Quadrature Amplitude Modulation) toma una seal de radio frecuencia que posee la informacin
codificada mediante variaciones en su fase y amplitud, y la transforma en una seal simple que
puede ser tratada por un conversor anlogo digital (A/D). El conversor A/D toma la seal, que
vara en voltaje, y la transforma en una serie de unos y ceros. Luego un mdulo de correccin de
errores compara la informacin recibida con un estndar conocido, para que los problemas que
puedan haberse producido en la transmisin puedan ser detectados y corregidos. En la mayora de
los casos, los frames, o grupos de datos, estn en formato MPEG, y un sincronizador MPEG es
utilizado para asegurar que los frames se mantengan en lnea y en orden.

8.3.6.3 Modulador
En los cable mdem que usan el sistema de cable para el trfico de subida, se utiliza un
modulador para convertir la informacin digital proveniente del computador en seales de radio
frecuencia para la transmisin. Este componente consta de tres partes: la primera, para insertar
informacin que ser utilizada para correccin de errores en el extremo receptor; la segunda, un
modulador QAM; y por ltimo, un convertidor digital anlogo (D/A).

8.3.6.4 MAC
La MAC se encuentra entre las porciones de subida y de bajada del cable mdem, y acta como
interfaz entre las porciones de hardware y software de los diversos protocolos de red. Todos los
equipos de red poseen MACs pero en el caso del cable mdem las tareas son ms complejas que
las de una tarjeta de red ordinaria. Es por esto que, en la mayora de los casos, algunas de las
funciones de las MAC sern asignadas a la CPU, ya sea la que est en el cable mdem o la que
est en la estacin de trabajo del usuario.

145

8.3.6.5 Microprocesador
El trabajo del microprocesador depender de si el cable mdem fue diseado para ser parte de un
sistema ms grande o para proporcionar acceso a Internet sin soporte adicional. En ambos casos
le tocar encargarse de una parte de la funcin MAC.

8.3.7 Cable Mdem Termination System

El CMTS (Cable Mdem Termination System) proporciona muchas de las mismas funciones que
el DSLAM en un sistema DSL. Toma el trfico proveniente de un grupo de clientes, lo junta y lo
enva a un ISP (Proveedor de Servicios de Internet) para la conexin a Internet. En el Head End,
los proveedores de cable tendrn espacio para que un ISP tenga: servidores, para contabilidad y
logging; Dynamic Host Configuration Protocol (DHCP), para asignar y administrar las
direcciones IP de los usuarios; y servidores de control, para el protocolo DOCSIS (Data Over
Cable Service Interface Specifications), el principal estndar utilizado en Chile para proveer
acceso a Internet a travs de redes de televisin por cable.
La informacin de bajada fluye hacia todos los usuarios conectados, tal como sucede en una red
Ethernet. Depende de cada cable mdem individual decidir si un bloque de datos determinado es
para el. En el lado de subida, la informacin es enviada desde los usuarios hacia el CMTS. Los
usuarios no ven nunca los datos enviados por otros usuarios. El ancho de banda de subida es
dividido en ranuras de tiempo, medidas en milisegundos, en que los clientes pueden transmitir
una rfaga a la vez hacia la Internet. La divisin por tiempo funciona bien para comandos cortos,
preguntas y direcciones que corresponden a la mayora del trfico de subida hacia Internet.
Un CMTS permite que alrededor de 1000 clientes se conecten a Internet a travs de un solo canal
de 6 MHz. Dado que un canal tiene una capacidad entre 30 y 40 Mbps, los usuarios perciben un
rendimiento ampliamente superior al que se obtiene con un mdem dial up tradicional.

146

8.3.7.1 Downstream
Corresponde al trmino utilizado para referirse a la seal recibida por el cable mdem. Las
caractersticas elctricas se resumen en la Tabla 8-2. Ntese que la mayora de las redes CATV
en Europa permiten un ancho de banda de 8 MHZ, mientras que en USA slo permiten 6 MHz.

Frecuencia
Ancho de Banda

Modulacin

42-850 MHz en USA y 65-850 MHz en Europa

6 MHz en USA y 8 MHz en Europa
64-QAM con 6 bits por smbolo (normal)
256-QAM con 8 bits por smbolo (ms rpido, pero ms sensible
a ruido)
Tabla 8-2: Caractersticas Elctricas

La tasa de datos depende de la modulacin y del ancho de banda como se ve en la Tabla 8-3:
64-QAM

256-QAM

6 MHz

31.2 Mbit/s

41.6 Mbit/s

8 MHz

41.4 Mbit/s

55.2 Mbit/s

Tabla 8-3: Tasas de datos en funcin de modulacin y ancho de banda

Dado que los datos de bajada (downstream) son recibidos por todos los cable mdem, el ancho de
banda total es compartido por todos ellos. Esto es similar a un sistema Ethernet, slo que el ancho
de banda que se desperdicia en Ethernet es mucho ms que en cable mdem. Cada cable mdem
filtra los datos que necesita de todos los que recibe.

8.3.7.2 Upstream
Corresponde al trmino para referirse a la seal transmitida por el cable mdem. El upstream
siempre es por rfagas, por lo que muchos mdems pueden transmitir en la misma frecuencia. El
rango de frecuencias utilizado tpicamente es entre 5 y 65 MHz o entre 5 y 42 MHz. El ancho de
banda por canal puede ser por ejemplo 2 MHz para un canal QPSK de 3 Mbps.

147

Las formas de modulacin son QPSK (2 bits por smbolo) y 16-QAM (4 bits por smbolo), donde
la ltima es la ms rpida. Una canal de bajada generalmente est apareado con varios canales de
subida para balancear los anchos de banda.
Cada mdem transmite rfagas en ranuras de tiempo, que pueden estar marcadas como
reservadas, de contencin o ranging. A continuacin se describe cada una de ellas:
8.3.7.2.1 Ranuras reservadas
Una ranura reservada es una ranura de tiempo que est reservada para un cable mdem en
particular. Ningn otro cable mdem puede transmitir en esa ranura de tiempo. El CMTS (Head
End) asigna las ranuras de tiempo a los distintos cable mdem a travs de un algoritmo de
asignacin. Este tipo de ranuras son utilizadas para transmisiones largas de datos.
8.3.7.2.2 Ranuras de Contencin
Estas ranuras se encuentran disponibles para que cualquier cable mdem transmita en ellas. Si
dos cables mdem deciden transmitir en la misma ranura, los paquetes colisionan y los datos se
pierden. El CMTS avisar que no se han recibido datos, para que los cable mdems intenten
transmitir nuevamente en otro momento (en forma aleatoria). Las ranuras de contencin se
utilizan para transmisiones cortas de datos (como por ejemplo para solicitar un nmero de ranuras
reservadas para transmitir ms datos).
8.3.7.2.3 Ranuras Ranging
Debido a la distancia fsica que existe entre el CMTS (Head End) y el cable mdem, existe un
delay que vara bastante y se encuentra en el rango de los milisegundos. Para compensar por esto,
los cable mdems emplean un protocolo de ranging, el que mueve el clock de los cable
mdems hacia delante o hacia atrs para compensar por el delay. Para lograr esto, un nmero
(tpicamente tres) de ranuras consecutivas se dejan de lado. Al cable mdem se le ordena que
intente transmitir en la segunda ranura. El CMTS mide esto, y le indica al cable mdem un
pequeo valor positivo o negativo de correccin para su clock local.
El otro propsito de este tipo de ranuras es hacer que todos los cable mdems transmitan a un
nivel de potencia que haga que todas las rfagas de subida desde todos los cable mdems lleguen
al CMTS al mismo nivel. Esto es importante en la deteccin de colisiones, pero tambin para
lograr un desempeo ptimo del demodulador de upstream en el CMTS. La variacin en
atenuacin desde el cable mdem hasta el CMTS es del orden de los 15 dB.

148

8.4 Symetric High-speed Digital Subscriber Line

Symetric High-speed Digital Subscriber Line (SHDSL) se basa en HDSL y est especificado en
la recomendacin G.991.2 de la ITU (Internacional Telecomunications Union) llamado SinglePair High-Speed Digital Subscriber Line Transceivers. Hoy, SHDSL puede operar a tasas que
van desde los 192 kbps hasta los 2312 kbps (usando 1 par de cobre) y desde los 384 kbps hasta
los 4624 kbps (usando dos pares de cobre). Es espectralmente compatible con todas las dems
tecnologas de la familia xDSL, y utiliza la codificacin TC-PAM. SHDSL combina lo mejor de
los servicios legacy en una sola tecnologa que puede ser utilizada para lineas E1/T1, Digital
Added Main Lines (mltiples canales de voz) y aplicaciones de videoconferencia utilizando un
solo par trenzado de cobre.
Aunque el acceso a internet es por naturaleza asimtrico existe una creciente necesidad por
aplicaciones de tipo simtrico, como aplicaciones de voz, aplicaciones peer-to-peer, trfico de
datos en empresas, etc. Es por esto que se hace importante la existencia de una tecnologa que
pueda satisfacer estas necesidades.

8.4.1 Compatibilidad Espectral

compatibilidad espectral de dos sistemas de transmisin DSL se define por el efecto del crosstalk
que un sistema introduce en el otro en el mismo cable. Los cables estn hechos de muchos pares
de cobre que se juntan en un solo gran cable. Cuando los cables estn tan cerca, parte de la
energa que va por uno de los pares es inducida en pares adyacentes. Dado que el servicio no se le
comienza a proporcionar a todos los clientes en forma simultnea, con el paso del tiempo y a
medida que van emergiendo nuevos estndares, es posible tener una mezcla de tecnologas DSL
en un mismo cable. Por experiencia, se sabe que ciertas tcnicas generan ms interferencia o
crosstalk que otras.
Distintos tipos de DSL en un cable utilizan distinto ancho de banda. Dependiendo de la energa
de las seales y de su posicionamiento espectral, los distintos tipos de sistemas DSL pueden ser o
no compatibles unos con otros. El efecto crosstalk que un sistema DSL tiene sobre otro en el
cable define la compatibilidad espectral.
En el diseo de sistemas DSL la compatibilidad espectral es importante ya que la implementacin
de cualquier sistema DSL nuevo no debiera tener efectos negativos sobre los sistema previamente
existentes. De la misma forma, los servicios existentes no debieran impedir que la nueva forma
de DSL alcance desempeo esperado.
La compatibilidad espectral es una funcin del grado de superposicin entre la seal recibida y la
seal crosstalk, y las potencias relativas de cada seal. Diversos factores influyen en la severidad
del crosstalk en pares de cobre.
149

El estndar SHDSL fue desarrollado no solo para resolver problemas de interoperabilidad sino
que tambin tom en consideracin las caractersticas espectrales de las codificaciones de lnea
existentes y las tcnicas de transmisin de uso comn en las redes existentes. SHDSL se basa en
modificaciones realizadas a HDSL2 y utiliza TC-PAM, proporcionando 16 niveles de
codificacin en vez de los 4 niveles utilizados en 2B1Q mejorando de esta forma la eficiencia
espectral. La codificacin Trellis, la decodificacin Viterbi, y la precodificacin Tomlinson
proporcionan BER (Bit Error Rate) y SNR (Signal to Noise Ratio) mejoradas.

Figura 8-21: Eficiencia espectral de SHDSL a 768 kbps

La Figura 8-21 muestra las caractersticas y la eficiencia mejoradas de la densidad espectral de
potencia (PSD) en SHDSL. La densidad espectral de potencia representa la cantidad de energa
requerida para enviar informacin. Con una cantidad de energa reducida a travs de una banda
de frecuencias, la potencialidad de interferencia con un cliente ADSL es reducida enormemente.
Por lo tanto, SHDSL molesta menos en los loops equipados con ADSL, y asegura compatibilidad
espectral con las implementaciones existentes.

8.4.2 Handshake
Otra ventaja que SHDSL tiene sobre otras tecnologas DSL simtricas previas incluye la
utilizacin del estndar de sealizacin G.994.1 Handshake Procedures for DSL Transceivers,
frecuentemente llamado G.hs para hacerlo ms corto. Este estndar define seales, mensajes y
procedimientos para intercambio de informacin entre equipos DSL. El uso de esta capacidad de
sealizacin ocurre luego de que el equipo DSL ha pasado por su etapa de inicializacin y entra
en el modo en que necesita establecer en forma automtica ciertas caractersticas operacionales
antes de que pueda existir intercambio de informacin.
150

Por ejemplo, los procedimientos G.hs se utilizan para habilitar la adaptacin de la tasa (rate
adaptation). El ancho de banda y por lo tanto la tasa de datos que puede ser soportada en un bucle
local de cobre puede ajustarse para alcanzar una cierta tasa de error basndose en un SLA
(Service Level Agreement), o para alcanzar mayores distancias. De esta forma, el ajuste de la
potencia y de la tasa se hace en forma automtica. Luego de completados los procedimientos de
inicializacin y handshake, el equipo DSL ingresa a SHOWTIME. Este es el modo en que el
usuario y la red pueden comenzar su comunicacin a travs de la red de acceso.

8.4.3 Ventajas de los proveedores de servicios

Mientras que la demanda por accesos de mayor velocidad contina, los proveedores de servicios
(carriers) estn comenzando a darle mayor importancia a la flexibilidad y programabilidad. Para
los ISPs (Internet Service Providers), ILECs (Incumbent Local Exchange Carriers) y CLECs
(Competitive Local Exchange Carriers), la meta es incrementar el ingreso mediante la
incorporacin de nuevos servicios y aplicaciones a su portafolio de servicios existentes. La
tecnologa DSL est evolucionando para satisfacer dichas necesidades. Los proveedores de
servicios estn desarrollando nuevos estndares para mayores distancias, tasas adaptables, menor
potencia, fcil implementacin y mayores ingresos. SHDSL ofrece una variada gama de
beneficios en la implementacin de servicios avanzados.
1. Implementar nuevos servicios utilizando la base instalada de DSLAMs.
2. Ancho de banda simtrico soporta aplicaciones que requieren buen desempeo en ambas
direcciones.
3. Diseo con un solo par con opcin de dos pares, y tasas adaptables proporcionan
flexibilidad en el diseo y en la implementacin.
4. Elimina la necesidad de repetidores E1/T1 en bucles de menos de 18000 pies.
5. Compatibilidad espectral superior con otras tecnologas rebaja las limitaciones en la
implementacin.
6. Ahorro en costos de transporte por la utilizacin de lneas existentes.
7. Estndares mundiales
interoperables.

permiten

mayor

disponibilidad

de

equipos

totalmente

8.4.4 Aplicaciones Objetivo para SHDSL

Los sistemas que utilizan SHDSL pueden soportar un gran nmero de aplicaciones de acceso
simtrico. Aunque SHDSL ha sido apuntado principalmente como el servicio simtrico para
negocios y clientes SOHO (Small Office Home Office), tambin es aplicable para ciertos casos

151

en el mercado residencial. Dado que los servicios son manejados en el dominio digital, el ancho
de banda puede ser dinmicamente asignado entre aplicaciones de voz, datos y video.
La Figura 8-22 es una ilustracin de la red del proveedor de servicios y del ambiente de
aplicaciones de acceso que SHDSL puede soportar. Es importante notar que en el 2002 haba
aproximadamente 196 millones de lneas de acceso E1/T1 en uso en el mundo. En el futuro, la
mayora de estas lneas son candidatas para utilizar SHDSL para soportar aplicaciones nuevas o
de ms altas velocidades que puedan ser soportadas sobre las lneas E1/T1, y a costos
operacionales ms bajos. Estas se discuten ms abajo.

Figura 8-22: Aplicaciones DSL simtricas

8.4.5 Usuarios Empresas

SHDSL sirve para aplicaciones de voz y datos que necesitan altas tasas de datos en upstream y
downstream y funciona bien para las siguientes aplicaciones:

8.4.5.1 Multi-line Voice over DSL (VoDSL)

Un servicio de voz sobre DSL requiere del uso de un CPE / IAD (Integrated Access Device) el
que tpicamente proporciona entre 4 y 16 puertas de voz adicionales a las puertas de datos. Para
VoDSL con mltiples canales de voz hay grandes requerimientos en el enlace de uplink, por lo
que requiere ancho de banda garantizado (QoS) y le sienta mejor una conexin simtrica que una
asimtrica para operar en forma ptima.

152

8.4.5.2 Web hosting

Aplicacin en la que un servidor web est ubicado en las dependencias del usuario, y se conecta a
Internet a travs del enlace DSL. Requiere un gran ancho de banda en la direccin upstream. Esto
debido a que debe ser posible que varios usuarios accedan a l en forma simultnea.

8.4.5.3 Videoconferencia
Un servicio de este tipo puede pasar datos, texto y video sobre un enlace ISDN (tpicamente).
DSL tiene la capacidad de ofrecer el mismo servicio pero con una mayor tasa de datos
entregando de esta forma mejor calidad de video o pudiendo tener mltiples videoconferencias a
la vez sobre la misma lnea. Dado que el servicio de videoconferencia es en ambos sentidos,
servicios DSL simtricos (SHDSL) son los mejores para este tipo de aplicaciones.

8.4.5.4 Servicios VPN

Una red privada virtual (VPN) es una red privada de datos que hace uso de la infraestructura
pblica de telecomunicaciones, manteniendo la privacidad a travs del uso de ciertos protcolos y
procedimientos de seguridad. SHDSL es una buena alternativa para el provisionamiento de este
tipo de servicios interconectando pequeas oficinas o sucursales donde los accesos de mayor
velocidad proporcionados por E3/T3 o fibra ptica no estn disponibles o son muy caros mientras
que los pares de cobre se encuentran ya instalados.

8.4.5.5 Acceso Remoto a LANs

Este servicio es comnmente utilizado para acceder a redes corporativas. SHDSL sirve para este
tipo de aplicaciones dado que permite a los usuarios subir informacin tan rpido como
bajarla. Las tasas van desde 192 kbps hasta 4,6 Mbps dependiendo del servicio o del alcance.

8.4.6 Usuarios Residenciales

Los siguientes puntos destacan atributos que hacen de SHDSL una tecnologa aplicable para
usuarios residenciales. Dado que SHDSL utiliza el ancho de banda del POTS, mecanismos
alternativos han sido desarrollados para soportar voz. En la eventualidad de una prdida de
potencia, el servicio Emergency Lifeline en general no es soportado. Sin embargo, SHDSL
proporciona una opcin que puede ser utilizada para proporcionar una lnea de emergencia en
caso de prdida de potencia en la lnea principal.

8.4.6.1 Distancia extendida para clientes remotos

A diferencia de ADSL, la tecnologa SHDSL puede alcanzar ms altas tasas de datos a mayores
distancias, y tambin soporta el uso de repetidores. Esto permite que usuarios fuera del rango de
153

alcance de ADSL puedan tener servicios utilizando SHDSL. Con esta tecnologa se logra un rea
de cobertura un 40% ms grande que con otras tecnologas simtricas previas como SDSL.

8.4.6.2 Acceso a Gateway Residencial

El trmino gateway residencial se utiliza para describir a un CPE (Customer Premises
Equipment) instalado en un hogar que proporciona acceso hacia/desde el hogar para mltiples
servicios (acceso a Internet, vigilancia a travs de video, etc.)

8.4.6.3 Juegos en Internet

Estos se basan en una arquitectura cliente-servidor. Los juegos a travs de Internet son muy
cmodos ya que se juega desde el propio hogar. En un ambiente competitivo, el jugador compite
contra el servidor o contra otra persona que est conectada al mismo servidor. Con servicios
asimtricos, la velocidad de upstream es muy pequea por lo que el jugador est en desventaja
contra otro que posee una mayor velocidad. Es por esto que lo ptimo es contar con una conexin
simtrica para este tipo de aplicaciones.

8.4.6.4 Servicios Peer-to-Peer

Una persona que tiene un negocio en casa y necesita compartir informacin con clientes caera en
esta categora. SHDSL es bueno para este tipo de servicios ya que permite compartir grandes
archivos con los clientes y recibir grandes archivos de los clientes. SHDSL permite una
comunicacin fluida en ambos sentidos.

154