Redes: Protocolos

CAPITULO I:
REDES:
La proliferación de redes de datos a lo largo de la década de los 90, tanto LANs como WANs, y el
interfuncionamiento entre ellas hace que los aspectos relativos a su control y gestión cada vez sean más
tenidos en cuenta, convirtiéndose en algo a lo que todos los responsables de redes han de prestar una gran
atención.
Dado que la tendencia natural de una red cualquiera es a crecer, conforme se añaden nuevas aplicaciones y
más y más usuarios hacen uso de la misma, los sistemas de gestión empleados han de ser lo suficientemente
flexibles para poder soportar los nuevos elementos que se van añadiendo, sin necesidad de realizar cambios
drásticos en la misma.
Este punto, el de gestión de red, es uno de los más controvertidos en teleinformática, ya que, prácticamente,
no existe una solución única, aceptada por todos y que sea fácilmente implantable. Las soluciones existentes
suelen ser propietarias −Netview de IBM, OpenView de HP, etc.− lo que hace que en una red compleja,
formada por equipos multifabricante, no exista un único sistema capaz de realizar la gestión completa de la
misma, necesitándose varias plataformas −una por cada fabricante−, lo que dificulta y complica enormemente
la labor del gestor de red.
CAPITULO II
ATM (Modo de Transferencia Asincrona):
La tecnología ATM (Asynchronous Transfer Mode) continua evolucionando y siendo fuente de interesantes y
novedosas propuestas. El desarrollo de avanzados protocolos de comunicaciones es uno de los campos de
investigación más activo, con la aspiración de ofrecer el adecuado soporte a las nuevas aplicaciones adaptadas
a las clases de servicio nativas ATM. En este contexto son aspectos clave los relativos a los protocolos nativos
ATM, así como las características multicast, la escalabilidad y la fiabilidad. Se profundiza en el concepto de
protocolo nativo ATM y son introducidos los protocolos más importantes que satisfacen este importante
requerimiento (N3, CONGRESS y kStack, entre otros). Es importante destacar también los protocolos de
transporte pensados específicamente para la tecnología ATM. La característica multicast
(multipoint−to−multipoint) es una de las que más esfuerzo está costando garantizar a ATM, pero existen ya
propuestas que permiten la comunicación fiable a elevados anchos de banda y entre múltiples emisores y
receptores (SMART, MCMP o MWAX). El artículo concluye con las investigacioness más novedosas en
torno a los protocolos ATM como las iniciativas que proponen redes ATM programables o activas (active
networks) usando agentes móviles.
Protocolo ATM:
El protocolo ATM consiste de tres niveles o capas básicas:
La primera capa llamada capa física (Physical Layer), define los interfases físicos con los medios de
transmisión y el protocolo de trama para la red ATM es responsable de la correcta transmisión y recepción de
los bits en el medio físico apropiado. A diferencia de muchas tecnologías LAN como Ethernet, que especifica
ciertos medios de transmisión, (10 base T, 10 base 5, etc.) ATM es independiente del transporte físico. Las
celdas ATM pueden ser transportadas en redes SONET (Synchronous Optical Network), SDH (Synchronous
Digital Hierarchy), T3/E3, TI/EI o aún en modems de 9600 bps. Hay dos subcapas en la capa física que
separan el medio físico de transmisión y la extracción de los datos:
1
La subcapa PMD (Physical Medium Depedent) tiene que ver con los detalles que se especifican para
velocidades de transmisión, tipos de conectores físicos, extracción de reloj, etc., Por ejemplo, la tasa de datos
SONET que se usa, es parte del PMD. La subcapa TC (Transmission Convergence) tiene que ver con la
extracción de información contenida desde la misma capa física. Esto incluye la generación y el chequeo del
Header Error Corrección (HEC), extrayendo celdas desde el flujo de bits de entrada y el procesamiento de
celdas "idles" y el reconocimiento del límite de la celda. Otra función importante es intercambiar información
de operación y mantenimiento (OAM) con el plano de administración
La subcapa TC es el nivel más bajo y realiza cinco funciones específicas:
• Generación/reconstrucción de la trama de transmisión; es decir, empaqueta las células en las tramas de
transmisión (lado emisor) y las desempaqueta (lado receptor)
• Adaptación de la trama de transmisión, dado que los procesos siguientes requieren conocer el esquema de
entramado empleado en el enlace.
• Delimitación de las células, de modo que el receptor reconozca los límites de cada célula en la cadena de
bits.
• Secuencia de generación/verificación del HEC. El control de errores en ATM se emplea sólo en la cabecera
de la célula, y se denomina Control de Errores de Cabecera (HEC ó Header Error Control). A través de un
sólo byte, con posibilidad de corrección de errores de un solo bit. Con su verificación se evita que células
fallidas sean conmutadas a destinos inadecuados.
• Cell Rate Decoupling. Un servicio de datos a ráfagas puede perder mucho tiempo sin transmitir datos, y en
otros momentos puede intentar enviar gran cantidad de datos al mismo tiempo (ráfagas). Durante los
periodos de inactividad, la capa TC insertará células "vacías" en el lado del emisor, que se retirarán en el
lado receptor. Sólo las células "no vacías" se pasan a la capa ATM.
La capa ATM define la estructura de la célula ATM y la señalización a través de las conexiones en una red
ATM. Esta capa crea también las células ATM y permite el establecimiento y "destrucción" de las conexiones
virtuales (VC y VP) en la red. Como corazón de la red ATM, esta capa la define: − La capa ATM multiplexa
(mezcla) células a través de un mismo enlace físico. Las células se distinguen en los nodos de la red
(conmutadores ATM), y en los equipos destinatarios, porque los campos de la cabecera identifican los
caminos virtuales y los canales virtuales. − La capa ATM traslada un identificador de camino virtual (VPI ó
Virtual Path Identifier) y un identificador de canal virtual (VCI ó Virtual Channel Identifier) entrantes, en un
enlace al par correcto VCI/VPI para el enlace de salida. Los valores se obtienen de una tabla en el
conmutador, que previamente había sido obtenida en el momento de la conexión por mensajes de
señalización. − En los extremos de la red, la capa ATM genera e interpreta las cabeceras de las células, y sólo
el campo de "payload" se pasa a las capas superiores. − La capa ATM proporciona un mecanismo de control
de flujo genérico (GFC ó Generic Flow Control) para el acceso al medio. La capa de adaptación al medio
(AAL) está diseñada para proporcionar la conversión en células de los diferentes tipos de paquetes, necesaria
para acomodar la mezcla de tipos de datos en una misma red. La AAL realiza las funciones de segmentación y
reensamblado que componen la información de las capas de niveles superiores, como paquetes de datos de
longitud variable en células ATM de longitud fija. Esta capa gestiona también el control de tiempos para las
transmisiones y maneja células perdidas u ordenadas incorrectamente. Hay cinco versiones de la capa de
adaptación al medio: − AAL1 soporta servicios CBR, orientados a conexión y trafico síncrono, para servicios
de voz y vídeo sin comprimir, emulación de circuitos, en los que se requiere una fuerte sincronización entre el
emisor y el destinatario, pero a velocidades fijas. − AAL2 soporta servicios VBR, orientados a conexión y
tráfico síncrono, para servicios de voz y vídeo comprimidos, donde la sincronización entre el emisor y el
destinatario también es importante, pero la velocidad es variable. − AAL3/4 proporciona servicios para
comunicación de datos, tanto orientados a conexiones como sin ellas, de tráfico asíncrono. Permite el empleo
de ATM con funciones de LAN (transferencia de ficheros, backup, ...), en general transferencias cortas pero
con grandes ráfagas de datos. − AAL5, por último, es una versión más eficiente que la AAL3/4, diseñada para
los requerimientos de redes locales de alta velocidad (paquetes, SMDS, ...), sin conexión y con servicios
VBR. En el futuro se podrán especificar otros niveles para cumplir con nuevos requisitos. Las funciones AAL
2
están organizadas en dos subcapas lógicas: la subcapa de convergencia (CS ó Convergence Sublayer) y la
subcapa de segmentación y reensamblado (SAR ó Segmentation and Reassembly Sublayer). La subcapa CS
opera en el punto de acceso al servicio y encapsula cualquier tipo de datos en un formato compatible ATM. Su
configuración es dependiente del servicio de acceso (Frame Relay, SMDS, Cell Relay Service, ...) La
funcionalidad de las subcapas de convergencia y SAR debe ser proporcionada en el equipamiento del cliente,
como encaminadores, DSU ó "pasarelas" (gateways). El punto más crítico por el momento, todavía sin
normalizar, y donde se presentan incompatibilidades entre productos de diferentes fabricantes, es la gestión de
la configuración y el tráfico, absolutamente imprescindibles en una red de alta velocidad para llegar a
prestaciones óptimas. Ello es absolutamente necesario en redes grandes en que se soportan multitud de tipos
de datos, gran número de usuarios, mezclas de protocolos, y variedad de aplicaciones. Aunque están
surgiendo estándares, deben estar completamente resueltos antes de que ATM sea una solución totalmente
viable.
La segunda capa es la capa ATM. Ello define la estructura de la celda y cómo las celdas fluyen sobre las
conexiones lógicas en una red ATM, esta capa es independiente del servicio. El formato de una celda ATM es
muy simple. Consiste de 5 bytes de cabecera y 48 bytes para información. Las celdas son transmitidas
serialmente y se propagan en estricta secuencia numérica a través de la red. El tamaño de la celda ha sido
escogido como un compromiso entre una larga celda, que es muy eficiente para transmitir largas tramas de
datos y longitudes de celdas cortas que minimizan el retardo de procesamiento de extremo a extremo, que son
buenas para voz, vídeo y protocolos sensibles al retardo. A pesar de que no se diseñó específicamente para
eso, la longitud de la celda ATM acomoda convenientemente dos Fast Packets IPX de 24 bytes cada uno.
Los comités de estándares han definido dos tipos de cabeceras ATM: los User−to−Network Interface
(UNI) y la Network to Network Interface (UNI). La UNI es un modo nativo de interfaz ATM que define
la interfaz entre el equipo del cliente (Customer Premises Equipment), tal como hubs o routerss ATM y
la red de área ancha ATM (ATM WAN). La NNI define la interfase entre los nodos de la redes (los
switches o conmutadores) o entre redes. La NNI puede usarse como una interfase entre una red ATM
de un usuario privado y la red ATM de un proveedor público (carrier). Específicamente, la función
principal de ambos tipos de cabeceras de UNI y la NNI, es identificar las "Virtual paths identifiers"
(VPIS) y los "virtual circuits" o virtual channels"(VCIS) como identificadores para el ruteo y la
conmutación de las celdas ATM.
Protocolos nativos ATM
Las aplicaciones nativas ATM están específicamente pensadas para usar la tecnología ATM y para explotar al
máximo sus especiales características. Los protocolos nativos se encargan, por tanto, de ofrecer esas
características intrínsecas de las redes de tecnología ATM (soporte de QoS, señalización, direccionamiento,
etc.) a las aplicaciones nativas ATM (VoD, pizarras compartidas, video−conferencia...). No obstante, existen
también activas investigaciones para conseguir soportar sobre redes ATM aplicaciones no nativas ATM
desarrolladas para otras tecnologías (IP, Frame Relay, SMDS...).
En, el termino native ATM services define servicios ATM específicos disponibles para el software y hardware
residentes en dispositivos de usuario UNI ATM. Por consiguiente, el programador de aplicaciones dispone de
nuevos servicios entre los que se pueden destacar los siguientes:
• Transferencias de datos (fiables o no) usando la capa ATM y varias capas de adaptación (AALs).
• Disponibilidad de circuitos virtuales conmutados (SVCs) y circuitos virtuales permanentes (PVCs).
• Consideraciones relativas a la gestión de tráfico (clases de servicio, garantías de QoS, etc.).
• Posibilidad de distribución de conexiones y de participación local en la administración de la red
(protocolos ILMI y OAM).
El propósito de los servicios nativos ATM es ofrecer el acceso a las clases de servicio o a las características de
3
QoS en redes ATM. Estos servicios nativos también ofrecen soporte a un amplio y heterogéneo rango de
flujos con diversas propiedades y requerimientos recomendados.
Los protocolos de transferencia nativos ATM gestionan la señalización UNI para establecer los SVCs,
configurar PVCs y mapear los perfiles de QoS en la correspondiente clase de servicio. Los protocolos nativos
también realizan funciones clásicas como las de transporte, mecanismos de control de errores, transferencia de
datos, y controles de flujo y de congestión.
Las redes ATM actuales que usan TCP como capa de transporte e IP−over−ATM como capa de red,
planteamiento, por otro lado, poco adecuado por las siguientes razones:
• Las redes IP no garantizan la QoS extremo−extremo ofrecida por las redes ATM a circuitos
individuales. IP multiplexa múltiples conexiones de transporte con distintos requerimientos de QoS en
VCs simples.
• TCP no soporta células RM (Resource Management) ABR y por consiguiente no puede usar
directamente las garantías de QoS ofrecidas por la red.
• ATM Adaptation Layer 5 (AAL5) realiza labores de checksum para detectar corrupción de datos.
TCP también realiza estas labores (redundantes con AAL5) costosas en overhead (cada byte de un
paquete debe ser chequeado).
TCP/IP son la representación de un grupo de protocolos bastante más antiguos que ATM y que ya han
experimentado determinados arreglos y evoluciones lo mismo que las aplicaciones que los emplean, lo que
acaba dando, en algunos casos, inadecuados comportamientos.
La interfaz Native ATM es constituida por la familia de protocolos PF_ATM que es directamente soportada
encima del dispositivo de red ATM sobrepasando la capa interfaz de red. El módulo CNTL abre una conexión
de señalización con el dispositivo ATM y establece una gestión de las llamadas de mensajes de configuración.
PF_ATM separa flujos de datos y de control para aliviar el límite de comportamiento en las comunicaciones.
Esto permite a los mecanismos de control de tráfico ser rápidos y sencillos, mientras los mecanismos de
control pueden ser tan complicados como sea necesario. Esta separación permite también que los dispositivos
puedan estar en los puntos finales de una conexión.
La interfaz PF_ATM da a las aplicaciones acceso directo a la capa de enlace ATM y extiende las garantías de
QoS a los puntos extremos de la comunicación.
Módulo troncal ATM para multiplexión inversa:
El módulo troncal de multiplexión inversa a través de ATM (Inverse multiplexing over ATM trunk module,
IMATM) permite que los proveedores de servicio y las empresas agreguen varios enlaces de comunicación
ATM T1 o E1. Los usuarios que necesiten velocidades de red superiores a T1 pero inferiores a T3 pueden
ampliar sus redes en incrementos T1 sin necesidad de invertir en un enlace T3 completo.
Características principales:
• Ancho de banda rentable y flexible: desde T1 o E1 hasta 8 x T1 u 8 x E1
• Diseño sólido que protege el sistema contra fallos de circuito y tarjeta
• Alta velocidad con un diseño de multiplexión eficiente que hace un uso completo de todo el ancho de
banda disponible
• Soporte multimedia para todos las clases de servicio ATM
• ATMF especificación 1.0 basado en los estándares basados en IMA
• Admite un máximo de ocho grupos IMA
4
Ruta de crecimiento económica para redes ATM:
Las redes ATM están diseñadas para poder hacer frente a las necesidades de alto rendimiento de voz, vídeo y
datos. El alto coste de los enlaces de las comunicaciones a larga distancia que operan a estas velocidades
limita el número y el tamaño de las WAN ATM de banda ancha disponibles, lo que impide a muchas
organizaciones el hacer uso de esta potente tecnología.
ATM Forum ha definido opciones de interfaz ATM de menor velocidad para T1 (1,544 Mbps) y E1 (2,048
Mbps). A pesar de que estas velocidades de interfaz ofrecen una opción económica para ATM, un solo
circuito T1 o E1, por lo general, no ofrece suficiente ancho de banda para ofrecer soporte para el tráfico
interswitch agregado o para altos niveles de demanda por parte de los usuarios finales.
Por tanto, numerosas organizaciones se encuentran limitadas por el escaso ancho de banda de las líneas T1 o
E1 y por el elevado coste (hasta ocho veces el de T1/E1) de pasar a enlaces de banda ancha. En estos casos, se
necesita una solución ATM de banda media.
El programa ATM multibanda de Cisco Systems hace frente a este reto al ofrecer soporte para enlaces ATM
de área amplia a velocidades entre T1/E1 y T3/E3 así como interfaces de usuario IMA n x T1 y n x E1.
Cisco ha desarrollado la multiplexión inversa a través de módulos troncales ATM (IMATM) para sus switches
de redes de área amplia con el fin de ofrecer a sus clientes un acceso inmediato a la tecnología de banda media
ATM de Cisco. El IMATM usa la multiplexión inversa a través de la tecnología ATM (IMA) para crear
enlaces troncales ATM a velocidades de entre 1,5 Mbps y 16 Mbps. Cisco también ha desarrollado el módulo
de servicio de usuario ATM (ATM user service module, AUSM) para conexiones a T1/E1 o n x T1/E1; el
AUSM puede aceptar interfaces usuario−red (UNI) ATM
T1/E1 estándar y también para conexiones de usuario IMA n x T1/E1. Rogamos consulte la hoja de datos
AUSM para más información sobre esta tarjeta.
La tecnología IMA agrega varias líneas T1 o E1 para crear un solo enlace ATM de alta velocidad. La
implementación de IMA basada en los estándares de Cisco, la IMATM y la tarjeta posterior asociada se
instalan en un concentrador de extremo MGX 8220. Los concentradores MGX 8220 funcionan con los
switches ATM de área extensa de Cisco para adaptar a ATM varios tipos de tráfico de servicio y agregar
tráfico antes de pasarlo al núcleo de conmutación del switch ATM.
Las tarjetas IMATM están disponibles en una versión de T3 a varias T1, una versión de E3 a varias E1 y una
versión de modo misto de T3 a varias E1, ofreciendo enlaces troncales entre switches WAN de Cisco a
velocidades de hasta 8 x T1 o de 8 x E1. Una versión más reciente de la tarjeta IMATM (modelo B) ofrece un
mayor nivel de tolerancia para retrasos diferenciales que excedan los requisitos de los estándares. En la
siguiente tabla se muestran las diferencias entre los modelos A y B de las tarjetas IMATM:
Característica/propiedad
Nombre de la placa frontal
Capacidad del bus de distribución
Retraso diferencial tolerable máximo
Cumplimiento con ATM Forum
Formatos de celda compatibles con la versión 3.X
FW
Formatos de celda compatibles con la versión 4.X
FW
IMATM Modelo B−T1
IMATM−8T1/B
Sí
275 mseg
Sí
IMATM Modelo B−E1
IMATM−8E1/B
No aplicable
200 mseg
Sí
No aplicable
No aplicable
STI/UNI/NNI
STI/UNI/NNI
Ancho de banda flexible
5
Las IMATM ofrecen una ruta de migración fácil para pasar de ATM de banda estrecha a ATM de banda
ancha. Un switch WAN de Cisco puede configurarse inicialmente para que use una sola línea T1 o E1. En ese
caso, el ancho de banda puede ampliarse en una o más líneas a la vez (hasta ocho líneas), lo que supone el
punto de equilibrio de coste para las tarifas de banda ancha. Al ofrecer una amplia gama de opciones entre
T1/E1 y T3/E3, los switches WAN de Cisco pueden configurarse para que satisfagan las necesidades de
tráfico de cada organización. Este nivel de versatilidad elimina el problema de tener que pagar por el ancho de
banda no necesario cuando una organización pasa directamente de T1/E1
a T3/E3.
Usando las tarjetas IMATM en el MGX 8220, los switches WAN de Cisco pueden contar con anchos de
bandas de enlace troncal con velocidades de entre T1/E1 y T3/E3.
Solidez:
Las IMATM de Cisco se han diseñado para que sean tolerantes a errores y para ofrecer un alto nivel de
rendimiento. Una de las ventajas inherentes de IMA sobre otras técnicas de multiplexión inversa es su
capacidad de encaminar circuitos a través de rutas diversas usando relojes distintos con la misma frecuencia
nominal. Por ejemplo, un enlace IMA troncal transatlántico puede dividirse en dos portadoras (cada una con
su reloj) ofreciendo un funcionamiento continuado si fallara el circuito de una de las portadoras.
Por naturaleza, la tecnología IMA mantiene el tráfico en movimiento incluso cuando falla un circuito
individual. En un sistema no multiplexado, es posible que los usuarios de un circuito dado no puedan pasar
fácilmente a una nueva ruta si su circuito falla. En un sistema basado en IMA, si falla uno de los enlaces T1 o
E1, todo el tráfico del enlace puede pasar a los enlaces restantes. Aunque se reduce el ancho de banda
disponible, los usuarios siguen contando con conectividad.
En situaciones en las que no es aceptable una reducción en el ancho de banda, los switches WAN de Cisco
con tarjetas IMATM pueden configurarse para que muestren el fallo de un enlace troncal cuando falle un
número de circuitos dado. En esta situación, la red inicia el reenrutamiento igual que si hubiese fallado el
enlace troncal. El software de gestión automática del enrutamiento (Automatic Routing Management) ofrece
soporte para este reenrutamiento de tráfico desde los enlaces troncales IMA que ya no pueden gestionar el
ancho de banda configurado.
Las tarjetas IMATM también ofrecen soporte para redundancia de tarjetas (1:1) a través de cableado en Y en
las interfaces. El cableado T1 o E1 se repite para cada línea
T1/E1 en el enlace troncal IMA.
Alta velocidad:
La tecnología ATM de banda media de Cisco permite que las conexiones aprovechen al máximo todo el
ancho de banda disponible. Por ejemplo, un segmento de red con cuatro líneas T1 multiplexadas a través de
IMATM puede usar las cuatro líneas para todos los niveles de tráfico en una conexión específica.
En comparación, cuando se usan varios enlaces T1 o E1 independientes (no multiplexados) entre dos
switches, cada conexión está limitada a la velocidad máxima de T1 o E1. Si una línea específica experimenta
una ráfaga de tráfico que supera el ancho de banda que puede utilizar, la tasa de transferencia se degrada
debido a que no puede enrutar el exceso de tráfico a otra línea.
Al ofrecer soporte para redundancia 1:1 y ajuste automático del ancho de banda IMA al número de circuitos
disponibles, se logra un sistema altamente resistente.
Soporte multimedia:
6
IMA está basado en la tecnología ATM y puede admitir todas las clases de servicio y tipos de tráfico ATM
con total compatibilidad con la gestión de clase de servicio (CoS) avanzada.
El especifica de gestión de CoS avanzada ofrece hasta 16 clases de servicio programables con descriptores de
calidad de servicio basados en _specifica. Este sistema ofrece flexibilidad para el aprovisionamiento y
_specificacione de servicios, así Comm para mantener la eficacia de la red.
Especificaciones técnicas:
Anchos de banda compatibles:
• AX−IMATM−8T1/B: desde 1,544 a 12,352 Mbps, en incrementos de 1,544 Mbps
• AX−IMATM−8E3/B: desde 2,048 a 16,384 Mbps, en incrementos de 2,048 Mbps
Varios grupos troncales IMA:
• Cada IMATM ofrece soporte para hasta 8 grupos troncales IMA; capaz de encaminar una amplia
gama de identificadores de ruta virtual (virtual path identifier, VPI) a distintos destinos (hasta ocho)
Interfaz T1:
• Tasa de línea: 1,544 Mbps ± 50 bps
• Sincronización: El PLL digital sincroniza todos los transmisores a una de las siguientes fuentes: la
línea T3, cualquiera de las líneas T1, o el reloj de 8 kHz del MGX 8220
• Código de línea: sustitución de 8 ceros binarios (Binary 8−zero substitution, B8ZS) según ANSI
T1.408
• Entramado de línea: formato supertrama ampliado (multitrama de 24 tramas Extended Superframe
[ESF]) según ANSI T1.408
• Tolerancia de fluctuación de fase (jitter) de entrada: según ATT TR 62411
• Tolerancia de fluctuación de fase (jitter) de salida: según ATT TR 62411 usando sincronización de
modo normal
• Alarmas de nivel físico: pérdida de señal (LOS), fuera de trama (OOF), señal de indicación de alarma
(AIS), identificación de deflexión remota (RDI)
• Parámetros de rendimiento de nivel físico: violación de código de línea (LCV), servidor de emulación
LAN (LES), LSES, CV, sistema final (ES), SES, SEFS, AISS y UAS
Interfaz E1:
• Tasa de línea: 2,048 Mbps ± 50 bps
• Sincronización: El PLL digital sincroniza todos los transmisores a una de las siguientes fuentes: la
línea E3, cualquiera de las líneas E1 o el reloj de 8 kHz del MGX 8220
• Código de línea: HDB3, AMI
• Entramado de línea: multitrama de 16 tramas según ITU G.704
• Tolerancia de fluctuación de fase (jitter) de entrada: según ITU G.823 para operación a 2,048 Mbps
• Tolerancia de fluctuación de fase (jitter) de salida: según ITU G.823 para operación a 2,048 Mbps
• Alarmas de nivel físico: LoS, OOF, AIS, RDI
• Parámetros de rendimiento de nivel físico: LCV, LES, LSES, CV, ES, SES, SEFS, AISS, UAS
Interfaz T3:
• Tasa de línea nominal: 44,736 Mbps
• Código de línea: B3ZS para DS3
7
• Entramado de línea: proceso de conversión de nivel físico para DS3 según ANSI TA−TSY−000772 y
TA−TSY−000773
• Normativas de entrada: según ATT 54014 e ITU−T G.703
Interfaz E3:
• Tasa de línea nominal: 34,368 Mbps
• Código de línea: HDB3
• Entramado de línea: según ITU−T G.804 y G.832
• Normativas de entrada: según ITU−T G.824
Interfaces físicas de la tarjeta trasera (módulo de línea):
• T1−−−Interfaz de ocho líneas T1: RJ−48C miniatura, 100 ohmios equilibrado
• T3−−−Interfaz de una línea T3: BNC, 75 ohmios no equilibrado
• E1−−−Interfaz de ocho líneas E1: RJ−48C miniatura, 100 ohmios equilibrado
• E3−−−Interfaz de una línea E3: BNC, 75 ohmios no equilibrado
• E1−−−Conectores de interfaz de ocho líneas E1: Server Message Block (SMB) miniatura, 75 ohmios
no equilibrado
• E3−−−Conector de interfaz de una línea E3: SMB miniatura, 75 ohmios no equilibrado
Control de congestiones:
• Los bits de indicador de congestión delantera explícita ATM (ATM explicit forward congestion
indicator, EFCI) se marcan cuando existe congestión, ofreciendo así control de extremo a extremo
Clase de servicio:
• Admite un máximo de 16 clases de servicio en redes ATM y Frame Relay así como en redes de
servicio, incluyendo:
♦ velocidad binaria constante (Constant bit rate, CBR), velocidad binaria sin especificar
(unspecified bit rate, UBR)
♦ VBR no en tiempo real (Non−real time VBR, NRT−VBR)
Opciones de gestión:
• Simple Network Management Protocol (SNMP)
• Protocolo de transferencia trivial de archivos (Trivial File Tranfer Protocol, TFTP) (para descarga de
código y de configuración y para la recogida de estadísticas)
• Interfaz de línea de instrucciones (por telnet)
• La gestión puede realizarse a través de Ethernet, protocolo Serial Line Internet Protocol (SLIP) o en
banda a través de la red ATM
Especificaciones físicas:
• Tarjeta frontal IMATM−8 T1/B: 7,25 pulgadas (18,4 cm) de altura, 16,25 pulgadas (41,3 cm.) de
longitud
• Tarjeta frontal IMATM−8 E1/B: 7,25 pulgadas (18,4 cm) de altura, 16,25 pulgadas (41,3 cm.) de
longitud
• Tarjeta trasera RJ−48−T3/T1 (conecta con la tarjeta frontal IMATM−8T1): 7 pulgadas (17,8 cm.) de
altura, 4,5 pulgadas (11,4 cm.) de longitud
• Tarjeta trasera RJ−48−E3/E1 (conecta con la tarjeta frontal IMATM−8E1): 7 pulgadas (17,8 cm.) de
8
altura, 4,5 pulgadas (11,4 cm.) de longitud
• Tarjeta trasera SMB−E3/E1 (conecta con la tarjeta frontal IMATM−8E1): 7 pulgadas (17,8 cm.) de
altura, 4,5 pulgadas (11,4 cm.) de longitud
• Tarjeta trasera RJ−48−T3/T1 (conecta con la tarjeta frontal IMATM−8E1): 7 pulgadas (17,8 cm.) de
altura, 4,5 pulgadas (11,4 cm.) de longitud
Especificaciones eléctricas:
• Tensión de entrada: −48 VCC
• Consumo: 30 vatios
Data Sheet:
Adaptador de puerto ATM PA−A1
El adaptador de puerto PA−A1 ATM es el primero de una nueva generación de
módulos de interfaz Modo Asíncrono de Transferencia (ATM) para los encaminadores de las series Cisco®
7200 y 7500. El adaptador de puerto ATM PA−A1 está basado en tecnología punta de adaptador de puerto, y
se trata de una interfaz ATM estándar que ofrece un alto rendimiento, flexibilidad y protección de la inversión
económica, permitiendo que los usuarios dispongan de uno de los productos ATM más rentables y potentes
del mercado.
El adaptador de puerto ATM PA−A1 puede usarse en cualquiera de los encaminadores de la serie Cisco 7200
o de la serie 7500 basados en Procesador de Interfaz Versátil 2 (VIP2), e interopera con cualquier dispositivo
ATM que cumpla con las normas UNI. El adaptador de puerto ATM PA−A1 convierte todo el tráfico no
ATM en celdas ATM y transmite datos a un conmutador ATM a velocidades de hasta 155 Mbps.
El adaptador de puerto ATM PA−A1 puede usarse en configuraciones de red ATM de gran tamaño y privadas
para aplicaciones de datos o que hagan un uso intensivo del ancho de banda en las que no se necesita la
formación de tráfico. Combinado con los servicios de software del Sistema Operativo Cisco para Trabajos en
Interred −Cisco Internetwork Operating System− (Cisco IOSTM) y con el sólido conjunto de protocolos de
legado utilizados en los encaminadores de las series Cisco 7200 y 7500, el adaptador de puerto ATM PA−A1
permite su uso en redes privadas virtuales (VPN) de gran tamaño.
Beneficios:
Interfaz ATM basada en estándares:
Las interfaces basadas en estándares garantizan la interoperación con otros dispositivos ATM estándares de la
red. Entre los estándares usados en el adaptador de puerto ATM se encuentran: categoría de servicio UNI
3.0/3.1, ATM adaptation Capa 5 (AAL5) y Tasa en Bits sin Especificar −unspecified bit rate− (UBR) para el
transporte de tráfico de datos, RFC 1483 y 1577 para interconexión de LAN, y flujos ATM Forum F4 y F5
OAM para la monitorización de rendimiento y errores.
Transmisión de datos de alto rendimiento:
El adaptador de puerto ATM permite su uso en velocidades de línea de nivel hasta OC−3 (155 Mbps) y ha
sido sometido a pruebas en una configuración Cisco 7500 a velocidades de transmisión de más de 150.000
paquetes de 64 bytes por segundo sin pérdida de paquetes. Además, el adaptador de puerto ATM permite el
equivalente de 512 SAR, a través de 2.000 conexiones virtuales (Circuito Virtual Permanente (PVC) o
9
Circuito Virtual Conmutado (SVC) de hasta 256 VLAN.
Optimizado para redes ATM privadas virtuales:
El adaptador de puerto ATM está diseñado para clientes que necesitan un mayor rendimiento de transmisión
(comparado con HSSI o FDDI) para tráfico LAN de ráfagas a través de líneas de transmisión privadas
(controladas por el cliente o de su propiedad).
Arquitectura avanzada de adaptador de puerto para los encaminadores de las series Cisco 7200 y 7500:
El adaptador de puerto ATM está basado en tecnología estándar, permitiendo una máxima flexibilidad y
protección de la inversión económica para propietarios de Cisco 7200 y 7500. La arquitectura de adaptador de
puerto ofrece importantes beneficios en una red ATM LAN, incluyendo la inserción en línea en plataformas
Cisco 7200, menores gastos por módulo de interfaz, mejor rendimiento en general, y mayor fiabilidad,
disponibilidad, capacidad de reparación y densidad de puerto.
Soporte Cisco IOS completamente integrado:
El adaptador de puerto ATM emplea todas las funciones ATM encontradas en el software Cisco IOS, la
avanzada infraestructura de software integrada en los productos de Cisco. Además del conjunto de
características ATM actualmente incorporadas en el software Cisco IOS (inclusive ATM LANE, UNI,
interconexión LAN, etc.), las constantes mejoras de ATM de Cisco IOS representan una gran ventaja que
permite que los clientes del adaptador de puerto ATM estén al día con el estándar ATM sin cambiar módulos
de hardware.
Especificaciones
Interfaces ATM físicas:
• Adaptador de puerto ATM nativo de un ancho, disponible para los encaminadores de las series Cisco
7200 y 7500
• SONET/SDH OC−3c/STM−1 155−Mbps, dos versiones de producto:
♦ Fibra multimodo, conector SC dúplex, hasta tres kilómetros (número de producto:
PA−A1−OC3MM)
♦ Fibra de modo único − alcance intermedio, conectores SC, hasta 15 kilómetros (número de
producto: PA−A1−OC3SM)
• Permite el equivalente de 521 SAR de paquetes simultáneos
• Cumple con las especificaciones ATM Forum, ITU−T, y ETSI
• Compatible con la función de inserción y extracción en línea −Online Insertion and Removal− (OIR)
de Cisco IOS en los encaminadores de las series Cisco 7200, que permite la instalación o extracción
de interfaces con el sistema en línea
Interfaces ATM virtuales:
• PVC y SVC
• Terminación de identificador de canal virtual e identificador de ruta (VCI y VPI)
• AAL 5
• Clase de servicio UBR
• Permite hasta 2.048 conexiones virtuales
• Compatible con hasta 256 VLAN
• Estándar ATM Forum UNI 3.0 (señalización 3.1 disponible en la versión 11.2 de Cisco IOS)
10
Servicios de interconexión ATM:
• Permite el uso del software Cisco IOS para ATM
• Soporte para servicios de interconexión de emulación LAN ATM Forum (LANE 1.0) y VLAN
• Soporte para servidor ATM ARP para Classical IP y ARP a través del soporte ATM según lo definido
en IETF RFC 1577 y 1755
• Compatible con el encaminamiento multiprotocolo a través de ATM para IP, Novell IPX, DECnet,
AppleTalk Fases 1 y 2, CLNS, XNS, y Banyan VINES a través de la encapsulación multiprotocolo
según lo definido en IETF RFC 1483
Gestión de red:
• Llamadas de monitorización de rendimiento OAM, detección de errores y aislamiento de fallos según
lo especificado en UNI 3.0/3.1 y I.610 para ruta virtual F4 y bucle de prueba de conexión virtual F5
• Soporte para ATM Forum para Interfaz de Gestión Local Provisional −Interim Local Management
Interface− (ILMI) para la adquisición de prefijo de dirección y registro de dirección de servicio ATM
con conmutadores compatibles con UNI a través de la red ATM
• Agente SNMP completo y soporte para la MIB de interfaz IETF RFC 1213 y soporte en un futuro
para especificaciones ATM MIB
• Soporte para los siguientes MIB:
♦ SONET
♦ AToM (IETF RFC 1695)
♦ Protocolo de Terminal Virtual −Virtual Terminal Protocol− (VTP)
♦ Interfaz de Gestión Local Provisional −Interim Local Management Interface− (ILMI) para
ATM
♦ Emulación LAN (LANE)
• Integración de gestión CiscoWorksTM; establecimiento de PVC a través de consola de gestión local o
a través de SNMP y CiscoViewTM
Indicadores LED:
• LED de activación para indicar que el adaptador de puerto ATM está listo para operar
• LED de recepción (RX) de celdas para indicar que el adaptador de puerto ATM está recibiendo celdas
• LED de recepción (RX) de portadora para indicar que el adaptador de puerto ATM está detectando
señal de portadora en el cable de recepción
• LED de alarma de recepción (RX) para indicar que el encaminador ha detectado una situación de
alarma
Aprobaciones regulatorias:
• Homologación IEC 825
• EN 55022, Class B, EN 50082−1
• EN 60950
• EN 41003
• UL 1950
• FCC Part 15, Class A
• AS/NZS 3260/AS TS001
• AS/NZS 3548, Class A
• CSA 22.2−950
• VCCI Class II
• Láser FDA Class 1
11
PROBLEMAS EN ATM:
En el pasado los protocolos de comunicaciones de datos evolucionaron en respuesta a circuitos poco
confiables. Los protocolos en general detectan errores en bits y tramas perdidas, luego retransmiten los datos.
Los usuarios puede que jamás vean estos errores reportados, la degradación de respuesta o de caudal (through
put) serían los únicos síntomas. A diferencia de los mecanismos de control extremo a extremo que utiliza TCP
en internerworking, la capacidad de Gbit/seg de la red ATM genera un juego de requerimientos necesarios
para el control de flujo. Si el control del flujo se hiciese como una realimentación del lazo extremo a extremo,
en el momento en que el mensaje de control de flujo arribase a la fuente, ésta habría transmitido ya algunos
Mbytes de datos en el sistema, exacerbando la congestión. Y en el momento en que la fuente reaccionase al
mensaje de control, la condición de congestión hubiese podido desaparecer apagando innecesariamente la
fuente. La constante de tiempo de la realimentación extremo a extremo en las redes ATM (retardo de
realimentación por producto lazo − ancho de banda) debe ser lo suficientemente alta como para cumplir con
las necesidades del usuario sin que la dinámica de la red se vuelva impractica.
Las condiciones de congestión en las redes ATM están previstas para que sean extremadamente dinámicas
requiriendo de mecanismos de hardware lo suficientemente rápidos para llevar a la red al estado estacionario,
necesitando que la red en sí, éste activamente involucrada en el rápido establecimiento de este estado
estacionario. Sin embargo, esta aproximación simplista de control reactivo de lazo cerrado extremo a extremo
en condiciones de congestión no se considera suficiente para las redes ATM. El consenso entre los
investigadores de este campo arroja recomendaciones que incluyen el empleo de una colección de esquemas
de control de flujo, junto con la colocación adecuada de los recursos y dimensionamiento de las redes, para
que aunados se pueda tratar y evadir la congestión ya sea:
Detectando y manipulando la congestión que se genera tempranamente monitoreando de cerca las
entradas/salidas que están dentro de los conmutadores ATM y reaccionando gradualmente a medida que vaya
arribando a ciertos niveles prefijados.
Tratando y controlando la inyección de la conexión de datos dentro de la red en la UNI (unidad interfaz de
red) de tal forma que su tasa de inyección sea modulada y medida allí primero, antes de tener que ir a la
conexión de usuario a tomar acciones mas drásticas. El estado de la red debe ser comunicado a la UNI,
generando rápidamente una celda de control de flujo siempre que se vaya a descartar una celda en algún nodo
debido a congestión. La UNI debe entonces manejar la congestión, cambiando su tasa de inyección o
notificándola a la conexión de usuario para que cese el flujo dependiendo del nivel de severidad de la
congestión.
El mayor compromiso durante el control de congestión es el de tratar y afectar solo a los flujos de conexión
que son responsables de la congestión y actuar de forma transparente frente a los flujos que observan buen
comportamiento. Al mismo tiempo, permitir que el flujo de conexión utilice tanto ancho de banda como
necesite sino hay congestión. La recomendación UIT − T I. 371 especifica un contrato de tráfico que define
como el tráfico del usuario seria administrado. El contrato que existe para cada conexion virtual (virtual path o
virtual channel), es básicamente un acuerdo entre el usuario y la red con respecto a la Calidad de Servicio
(Quality Of Service − Q o S) y los parámetros que regulan el flujo de celdas. Estos descriptores de trafico
dependen de una particular clase de servicio y pueden incluir bajo la especificación del ATM Forum UNI / a
cinco Q o S referenciados en los AALS. El objetivo de estas sub clases de servicio es agrupar características
de servicio como requerimiento de ancho de banda similares, sensibilidad a la perdida de datos y retardos para
un correcto manejo de los datos en los puertos de acceso ATM, etc. Estos parámetros pueden incluir el
Sustained Cell Rate (SCR), el Mínimum Cell Rate (MCR), el Peak Cell Rate (PCR) y/o el Burst Tolerance
(BT). Para soportar todas las diferentes clases de servicios definidos por los estándares el switch ATM debe
ser capaz de definir éstos parámetros en base a cada VC o cada VP y debe proveer amortiguadores (buffers)
para absorber las ráfagas de trafico.
12
INTEROPERABILIDAD ENTRE FRAME RELAY Y ATM
El objetivo final para todos los servicios descritos anteriormente es una migración suave de Frame Relay y/o
SMDS a redes ATM. Por ejemplo la recomendación UIT − T I.555, provee un marco para la interoperabilidad
de Frame Relay y ATM. Para alcanzar una máxima eficiencia se trata de brindar este servicio de
interoperabilidad en la capa más baja posible mediante conversión de protocolo.
PRIMER ESCENARIO:
Cuando el servicio de Frame Relay es dado sobre la RDSI en banda ancha y los usuarios se conectan a través
de la UNI de Frame Relay. En esta solución, se necesita un equipo que sirva de interfaz tanto para el usuario
que recibe, como para el que transmite.
Para proveer el servicio del primer escenario existen dos posibilidades:
POSIBILIDAD 1:
Construir un mallado utilizando conexiones ATM (VC/VP) para enlazar los puntos de acceso Frame Relay.
En este esquema se puede explotar la naturaleza de orientación a conexión Frame Relay (F R) siguiendo un
comportamiento como:
El usuario del enrutador pregunta por una conexión al equipo interfaz de red.
El equipo interfaz de la red coloca las conexiones Frame Relay dentro de una conexión ATM con las
direcciones destino apropiadas.
Por cada trama de equipo interfaz de red traslada de la conexión de Frame Relay a la ATM y viceversa.
La conexión ATM esta desocupada cuando no se necesita.
Para lograr este último punto, el manejo de la política de conexion del VC, sera un aspecto crucial para el
desempeño de este procedimiento. Resulta difícil de terminar el procedimiento para manejar un VC cuando la
fuente de tráfico es no orientada a conexión. En este caso se pueden utilizar varios mecanismos:
No utilizar manejo alguno, lo que involucra el uso de circuitos ATM permanentes (VPs) en lugar de los
conmutadores (VCs) con un costo muy elevado.
Abrir y cerrar una conexion ATM con el destino apropiado para cada trama que arribe del lado de Frame
Relay en el equipo interfaz de red.
Abrir una conexión ATM cuando se necesite y cerrarla de acuerdo a un temporizador de inactividad.
El problema debe ser solucionado ya sea por el enrutador del usuario o por el equipo interfaz de red.
POSIBILIDAD 2:
Utilizar un servicio Frame Relay en todos los lugares en los cuales se establezcan conexiones ATM en
estrella. En esta opción se toma ventaja del uso actual del FR, el cual es proveer un mallado virtual entre
diferentes sitios para cargar tráfico no orientado a conexión.
Cada enrutador esta conectado al servidor de FR.
13
Todos los DLCIs (Data Link Connection Identifier) en cada interfaz FR pueden ser cargados a un servidor FR
dentro de un VC ATM.
En este escenario la funcionalidad de los equipos interfaz de red se simplifica debido a que solo dialoga con el
servidor.
La complejidad reside en el servidor que ejecuta funciones de conmutación. Las tramas se conmutan en la
base de VCIs y DLCIs entrantes y salientes.
El servidor mantiene una tabla con las correspondencias entre los pares VCI / DLCI.
SEGUNDO ESCENARIO:
La red de Frame Relay y la red RDSI de banda ancha se interconectan a través de sus respectivas interfaces de
red (NNIs). Esto permitiría a un proveedor de red, manejar esta heterogénea red como un todo. Frame Relay
provee usualmente la interconexión para LAN a pesar de su natural orientación a conexión. En las redes
Frame Relay existentes se puede conseguir un mallado de LANs a traves de circuitos virtuales permanentes.
Los datagramas de los LANs son cargados dentro de tramas FR y enrutados de acuerdo con la etiqueta
contenida en el DLCI. Tratando de hacer un sobresimplificación los dos protocolos (AAL 3 y AAL 5) ofrecen
basicamente el mismo servicio CPAAL (Parte Común AAL) a las subcapas superiores. En este caso a la capa
de Convergencia de Frame Relay.
Existen sin embargo diferencia en las funcionalidades internas, simplicidad de implementación y eficiencia
del protocolo que incide en el costo. Las características a tomar en cuenta, cuyo detalle puede ser tema de otro
artículo, tienen que ver con Delimitación y Alineamiento de Tramas, Multiplexación, Detección de errores de
transmisión, eficiencia en la transmisión. Analizadas estas diferencias se propone seleccionar el AAL5 bajo la
subcapa FR−CS para soportar el servicio Frame Relay en RDSI de banda ancha.
CAPITULO III
Simple Network Management Protocol (SNMP):
Algo de Historia:
En 1988 se implementó y comenzó a utilizarse un protocolo de gestión denominado SNMP (Simple Network
Management Protocol), un protocolo sencillo para la gestión de red. Este protocolo ha sido muy aceptado
desde entonces y la mayoría de los fabricantes lo implementan en sus equipos con protocolos TCP/IP. Sin
embargo, la segunda estrategia no ha avanzado suficiente, debido quizá a la falta de estabilidad de las normas
OSI de gestión por lo que muy pocos fabricantes ofrecen esta solución para Gestión.
Actualmente, la gestión SNMP es un directo competidor de la Gestión OSI y se siguen definiendo normas
para la gestión SNMP. La última implementación del protocolo SNMP es la norma SNMP3, que actualmente
esta en fase de pruebas y desarrollo. El protocolo SGMP procede del protocolo SGMP−Simple Gateway
Management Protocol, un Protocolo Sencillo para Gestión de Ordenadores que efectúan el encaminamiento de
los datagramas IP en Internet.
El protocolo SNMP fue desarrollado por los mismos autores que el protocolo SGMP. Estas personas tienen
una visión práctica de las redes y desarrollaron el protocolo en solamente unos meses. SNMP (Simple
Network Management Protocol), en sus distintas versiones, es un conjunto de aplicaciones de gestión de red
que emplea los servicios ofrecidos por TCP/IP, protocolo del mundo UNIX, y que ha llegado a convertirse en
un estándar.
14
Surge a raíz del interés mostrado por la IAB (Internet Activities Board) en encontrar un protocolo de gestión
que fuese válido para la red Internet, dada la necesidad del mismo debido a las grandes dimensiones que
estaba tomando.
Los tres grupos de trabajo que inicialmente se formaron llegaron a conclusiones distintas, siendo finalmente el
SNMP (RFC 1098) el adoptado, incluyendo éste algunos de los aspectos más relevantes presentados por los
otros dos: HEMS (High−Level Management System) y SGMP (Simple Gateway Monitoring Protocol).
¿Qué es SNMP?
El Protocolo simple para administración de la red (SNMP) fue diseñado originalmente para proporcionar un
medio para manejar los enrutadores de una red. SNMP, aunque es parte de la familia de protocolos TCP/IP,
no depende del IP. SNMP fue diseñado para ser independiente del protocolo (de manera que pueda correr
igual de fácil bajo IPX de SPX/IPX de Novell, por ejemplo), aunque la mayor parte de las instalaciones
SNMP utilicen IP en redes TCP/IP.
SNMP no es un solo protocolo, sino tres protocolos que juntos forman una familia; todos diseñados para
trabajar en pro de las metas de la administración. Los protocolos que conforman la familia SNMP y sus
papeles se muestran a continuación:
• Base de información de la administración (MIB): Una base de datos que contiene información del
estado.
• Estructura e identificación de la información sobre la administración (SMI): Una especificación
que define las entradas en una MIB.
• Protocolo simple para administración de la red (SNMP): El método de comunicación entre los
dispositivos administrados y los servidores.
Los periféricos que tienen integradas las capacidades para SNMP corren un paquete de software agente para
administración, cargado como parte de un ciclo de arranque o incrustado en la memoria fija (firmware) del
dispositivo. Estos dispositivos que tienen agentes SNMP se dice que se tratan de dispositivos administrados.
Los dispositivos administrados por SNMP se comunican con el software servidor SNMP que está localizado
en cualquier parte de la red. El dispositivo habla con el servidor de dos formas: por sondeo o por
interrumpida.
Un dispositivo sondeado hace que el servidor se comunique con el dispositivo, preguntándole sobre su
condición o sobre sus estadísticas actuales. El sondeo en ocasiones se hace en intervalos regulares, teniendo al
servidor conectado a todos los dispositivos administrados de la red. El problema con el sondeo es que la
información no siempre es actual, el tráfico de la red se incrementa con el número de dispositivos
administrados y la frecuencia del sondeo.
Un sistema SNMP basado en la interrupción hace que el dispositivo administrado envíe mensajes al servidor
cuando algunas condiciones lo garanticen. De esta forma, el servidor conoce inmediatamente cualquier
problema (a menos que el dispositivo falle, en cuyo caso la notificación debe hacerse desde otro dispositivo
que haya tratado de comunicarse con el dispositivo que falló).
Los dispositivos basados en la interrupción tienen sus propios problemas. En primer lugar entre los problemas
está la necesidad de ensamblar un mensaje para el servidor, lo que pue requerir de una gran cantidad de ciclos
del CPU, todos los cuales se toman de la tarea normal del dispositivo. Esto puede provocar cuellos de botella
y otros problemas en el dispositivo. Si el mensaje que va a enviarse es extenso, como sucede cuando contiene
una gran cantidad de estadísticas, la red puede padecer de una notable degradación mientras el mensaje se
ensambla y transmite.
15
Si existe una falla mayor en cualquier parte de la red, como cuando falla la corriente eléctrica y se activan las
fiientes de energía, cada dispositivo administrado por SNMP tratará de enviar al mismo tiempo, mensajes
controlados por interrupción hacia el servidor, para reportar el problema. Esto puede congestionar la red y
producir una información errónea en el servidor. A menudo se utiliza una combinación de sondeo y de
interrupción para sobreponerse a todos estos problemas. La combinación se llama sondeo dirigido por trampa,
e implica que el servidor haga un sondeo de las estadísticas a intervalos regulares o cada vez que lo ordene el
administrador de sistema. Además, cada dispositivo administrado por SNMP puede generar un mensaje de
interrupción cuando se presenten ciertas condiciones, pero estos mensajes tienden a estar más rigurosamente
definidos que en el simple sistema controlado por interrupción. Por ejemplo, sí utiliza SNMP sólo mediante
interrupción, un enrutador puede reportar un incremento de la carga cada 10 por ciento. Si utiliza un sondeo
dirigido por trampa, usted conoce la carga del sondeo regular y puede dar instrucciones al enrutador para
enviar una sola interrupción cuando se experimente un incremento significativo en la carga. Después de
recibir un mensaje de interrupción con sondeo dirigido por trampa, el servidor puede seguir sondeando al
dispositivo para mayores detalles, en caso de ser necesario.
La computadora del administrador no necesita conectarse directamente hacia todas las redes físicas que
contiene entidades administradas.
Ejemplo de administración de red. Un administrador invoca software cliente de administración (MC) que
contacta al software cliente de administración (MC) que conecta al software servidor de administración (MS)
en los enrutadores, a través de la red.
Un paquete de software servidor SNMP puede comunicarse con los agentes
SNMP y transferir o solicitar diferentes tipos de información. Generalmente, el servidor solicita las
estadísticas del agente, induyendo el número de paquetes que se manejan, el estado del dispositivo, las
condiciones especiales que están asociadas con el tipo de dispositivo (como las indicaciones de que se terminó
el papel o la pérdida de la conexión en un módem) y la carga del procesador.
El servidor también puede enviar instrucciones al agente para modificar las entradas de su base de datos
MIB(la Base de Información sobre la Administración). El servidor también puede enviar los límites o las
condiciones bajo las cuales el agente SNMP debe generar un mensaje de interrupción para el servidor, como
cuando la carga del CPU alcanza el 90 por ciento.
Las comunicaciones entre el servidor y el agente se llevan a cabo de una forma un tanto sencilla, aunque
tienden a utilizar una notación abstracta para el contenido de sus mensajes. Por ejemplo, el servidor puede
enviar un mensaje what is your current load y recibir un mensaje del 75%. El agente nunca envía datos hacia
el servidor a menos que se genere una interrupción o se haga una solicitud de sondeo. Esto significa que
pueden existir algunos problemas constantes sin que el servidor SNMP sepa de ellos, simplemente porque no
se realizó un sondeo ni se generó interrupción
SNMP permite crear herramientas de gestión que:
Informen del funcionamiento de la red o subred
Detecten averías y funcionamientos incorrectos
Permitan actuar sobre los elementos de la red: modificando su configuración, desconectando equipos, etc.
Así pues, SNMP es un protocolo del nivel de aplicación basado en paquetes UDP, es decir, es un protocolo
"no orientado a la conexión". SNMP define una relación cliente/servidor entre el gestor de red (que actúa de
16
cliente, ojo) y los elementos gestionados (que son los servidores y reciben el nombre de "agentes
SNMP").Para el protocolo SNMP la red constituye un conjunto de elementos básicos, administradores o
management stations ubicados en el/los equipo(s), de gestion de red y Gestores Network, agentes (elementos
pasivos ubicados en los nodos− host, routers, modems, multiplexores, etc− a ser gestionados), siendo los
segundos los que envian información a los primeros, relativa a los elementos gestionados, por iniciativa
propia o al ser interrogados (polling), de manera secuencial, apoyándose en los parámetros contenidos en sus
MIB (Management Information Base).
Su principal inconveniente, es el exceso de trafico que se genera, lo que lo puede hacer incompatibles para
entornos amplios de red por el contrario CMIS/CMIP (Common Management Information Service/Protocol)
de OSI ofrece un mejor rendimiento y seguridad, estando orientado a la administración de sistemas
extendidos.La versión 2 de SNMP aporta una serie de mejoras frente a la original, que, fundamentalmente, se
manifiestan en tres áreas particulares: seguridad (autentificación, privacidad y control de accesos),
transferencia de datos y comunicaciones Administrador a Administrador. SNMP ha pasado por varias
iteraciones. La versión más utilizada se llama SNMP v1. Por lo general, SNMP se utiliza como una aplicación
cliente/servidor asincrónica, lo que significa que tanto el dispositivo administrado como el software servidor
SNMP pueden generar un mensaje para el otro y esperar una respuesta, en caso de que haya que esperar una.
Ambos lo empaquetan y manejan el software para red (como el IP) como lo haría cualquier otro paquete.
SNMP utiliza UDP como un protocolo de transporte de mensajes. El puerto 161 de UDP se utiliza para todos
los mensajes, excepto para las trampas, que llegan el puerto 162 de UDP. Los agentes reciben sus mensajes
del administrador a través del puerto UDP 161 del agente.
SNMP v2 añade algunas nuevas posibilidades a la versión anterior de SNMP, de las cuales, la más útil para
los servidores es la operación get−bulk. Ésta permite que se envíen un gran número de entradas MIB en un
solo mensaje, en vez de requerir múltiples consultas get−next para SNMP v1. Además, SNMP v2 tiene mucho
mejor seguridad que SNMP vl, evitando que los intrusos observen el estado o la condición de los dispositivos
administrados. Tanto la encriptación como la autentificación están soportadas por SNMP v2. SNMP v2 es un
protocolo más complejo y no se usa tan ampliamente como SNMP vl.
El SNMP reúne todas las operaciones en el paradigma obtener−almacenar (fetch store paradigm) .
Conceptualmente, el SNMP contiene sólo dos comandos que permiten a un administrador buscar y obtener un
valor desde un elemento de datos o almacenar un valor en un elemento de datos. Todas las otras operaciones
se definen como consecuencia de estas dos operaciones.
La mayor ventaja de usar el paradigma obtener−almacenar es la estabilidad, simplicidad flexibilidad. El
SNMP es especialmente estable ya que sus definiciones se mantienen fijas aun,cuando nuevos elementos de
datos se añadan al MIB y se definan nuevas operaciones como efectos del almacenamiento de esos elementos.
Desde el punto de vista de los administradores, por supuesto, el SNMP se mantiene oculto. usuario de una
interfaz para software de administración de red puede expresar operaciones corno comandos imperativos (por
ejemplo, arrancar). Así pues, hay una pequeña diferencia visible entre la forma en que un administrador utiliza
SNMP y otros protocolos de administración de red.
El SNMP ofrece más que las dos operaciones que hemos descrito:
Comando
get−request
get−next−request
get−response
set−request
trap
Significado
Obtener un valor desde una variable específica
Obtener un valor sin conocer su nombre exacto
Replicar a una operación fetch
Almacenar un valor en una variable específica
Réplica activada por un evento
17
A pesar de su extenso uso, SNMP tiene algunas desventajas. La más importante es que se apoya en UDP.
Puesto que UDP no tiene conexiones, no existe contabilidad inherente al enviar los mensajes entre el servidor
y el agente. Otro problema es que SNMP proporciona un solo protocolo para mensajes, por lo que no pueden
realizarse los mensajes de filtrado. Esto incrementa la carga del software receptor. Finalmente, SNMP casi
siempre utiliza el sondeo en cierto grado, lo que ocupa una considerable cantidad de ancho de banda.
Los cinco tipos de mensajes SNMP intercambiados entre los Agentes y los Administradores, son:
− Get Request
Una petición del Administrador al Agente para que envíe los valores contenidos en el MIB (base de datos).
− Get Next Request
Una petición del Administrador al Agente para que envíe los valores contenidos en el MIB referente al objeto
siguiente al especificado anteriormente.
− Get Response
La respuesta del Agente a la petición de información lanzada por el Administrador.
− Set Request
Una petición del Administrador al Agente para que cambie el valor contenido en el MIB referente a un
determinado objeto.
− Trap
Un mensaje espontáneo enviado por el Agente al Administrador, al detectar una condición predeterminada,
como es la conexión/desconexión de una estación o una alarma.
El protocolo de gestión SNMP facilita, pues, de una manera simple y flexible el intercambio de información
en forma estructurada y efectiva, proporcionando significantes beneficios para la gestión de redes
multivendedor, aunque necesita de otras aplicaciones en el NMS que complementen sus funciones y que los
dispositivos tengan un software Agente funcionando en todo momento y dediquen recursos a su ejecución y
recogida de datos.
Ventajas de SNMP
• Es muy popular y casi todo lo que se puede conectar a una red puede convertirse en un agente SNMP.
• Es flexible, se puede adaptar a las necesidades de gestión de cualquier elemento.
• Es extensible: un gestor bien diseñado puede aprender nuevos MIBs de forma automática.
Es la única manera conocida de gestionar una red grande heterogénea (como la propia Internet).
Desventajas de SNMP
• Es difícil de implementar.
• No es muy eficiente, ocupa demasiado ancho de banda.
Típicamente el gestor de red se ejecutará en una estación de trabajo controlada manualmente por el
administrador de red o automáticamente por un plan de trabajo definido previamente.
18
Los agentes pueden ser, por ejemplo:
• Ordenadores conectados a la red (el software del agente puede estar en la ROM de la tarjeta de red)
• Servidores de ficheros, webs, de correo, etc.
• Bridges
• Routers
• Concentradores (de un segmento Ethernet)
• Hubs de una red Token−Ring
• Impresoras de red, etc.
Agentes y gestor manejan una base de datos de información gestionable (el MIB o Management Information
Base) que contiene, organizados de forma jerárquica, un conjunto de informaciones estadísticas y valores de
control que pueden ser estándar (well−known values) o ser extensiones propias de los fabricantes de los
diferentes agentes/gestores.
SNMP sólo define dos operaciones a realizar:
• Lectura por parte del gestor de un registro (un valor) del MIB del agente
• Modificación de uno de estos valores.
MIB (Base de Información sobre la administración):
El estándar especifica los elementos de los datos que un anfitrión o un ruteador deben conservar y las
operaciones permitidas en cada uno.
Cada dispositivo administrado por SNMP mantiene una base de datos que contiene estadísticas y otro tipo de
información. Estas bases de datos se llaman Base de información sobre administración, o MIB. Las entradas
de MIB tienen cuatro datos: un tipo de objeto, una sintaxis, un campo de acceso y un campo de estado. Las
entradas MIB generalmente las estandarizan protocolos y siguen reglas esrtrictas para el formateo, definidas
por la Notación para Sintaxis Abstracta Uno (Abstract Syntax Notation One, ASN. l).
El tipo de objeto es el nombre de la entrada específica, generalmente a manera de un simple nombre. La
sintaxis es el tipo de valor, como una cadena o un entero. No todas las entradas una MIB tienen un valor. El
campo de acceso se utiliza para definir el nivel de acceso de la entrada, comúnmente está definida por los
valores de sólo lectura, lectura−escritura, sólo escritura y no accesible. El campo de estado contiene una
indicación de que la entrada de la MIB es obligatoria (lo que significa que el dispositivo administrado debe
aplicar la entrada), opcional (el dispositivo administrado puede aplicar la entrada), u obsoleta (que no se
utiliza).
Existen dos tipos de MIB, llamados MIB−1 y MIB−2. Las estructuras son diferentes. MIB−1 se utilizó a
principios de 1988 y tiene 114 entradas en la tabla, las cuales están divididas engrpos. Para que un dispositivo
administrado pueda ser compatible con MIB−1, debe manejar grupos que son aplicables a ésta. Por ejemplo,
una impresora administrada no tiene que aplicar todas las entradas que traten con el Protocolo para Gateway
Exterior (Exterior Gateway Protocol EGP), el cual generalmente lo aplican solamente los enrutadores y los
dispositivos similares.
MIB−2 es una ampliación a MIB− 1 hecha en 1990, está conformada por 171 entradas que están divididas en
diez grupos. Las adiciones amplían algunas de las entradas de los grupos básicos de MIB−1 y agregan tres
nuevos grupos. Al igual que con MIB− 1, un dispositivo SNMP que pretenda ser compatible con MIB−2 debe
adaptar todos esos grupos que son aplicables a ese tipo dt dispositivo. Usted encontrará muchos dispositivos
que son compatibles con MIB−1 pero que no lo son con MIB−2.
19
El MIB para TCP/IP divide la información de la administración en 8 categorís:
Categoría MIB
system
interfaces
addr.trans.
ip
icmp
tcp
udp
egp
Incluye información sobre
Sistema operativo del anfitrión o del ruteador
lnterfaz de red individual
Dirección de traducción (por ejemplo, transformación ARP)
Software de Protocolo de lnternet
Software de Protocolo de Mensajes de Control de lnternet
Software de Protocolo de Transmisión de lnternet
Software de Protocolo de Datagrama de Usuario
Software de Protocolo de Compuerta Exterior
SMI (Structure of Management Information ):
Estructura de la información de administración:
Además del estándar MIB, el cual especifica variables de administración de red y sus significados, un estándar
separado especifica un conjunto de reglas utilizadas para definir e identificar variables MIB. Las reglas se
conocen como especificaciones Structure of Management Information (SMD.
Para mantener los protocolos de administración de red simples, SMI establece restricciones a los tipos de
variables permitidas en MIB, especifica las reglas para nombrar tales variables y crea reglas para definir tipos
de variables. Por ejemplo, el estándar SMI incluye definiciones de términos como IpAddress (definiéndolo
como una cadena de cuatro octetos) y Counter (definida como un entero en el rango de 0 a 232−1) y
especifica que son los términos utilizados para definir variables MIB. Algo mu importante, las reglas en SMI
describen cómo se refiere MIB a las tablas de valores (por ejemplo, la tabla de ruteo IP).
El contenido del MIB de un agente concreto se define usando la ASN.1 (Abstract Syntax Notation) lo que
permite al software gestor incorporar a su base de datos la información de gestión de cualquier nuevo agente.
Manejando este MIB un gestor SNMP puede:
Modificar las tablas de rutado de un router
Conocer las estadísticas de funcionamiento de un servidor
Desconectar una estación de trabajo de la red
Ver los paquetes que circulan por una subred
¡conocer la temperatura de funcionamiento de un concentrador!, etc.
Por supuesto todo ésto de forma gráfica con iconos para los agentes, planos de los edificios donde se sitúan las
redes, mapas de situación (para redes internacionales), líneas de colores que indican el nivel de tráfico de los
enlaces, etc.
A través del MIB se tiene acceso a la información para la gestión, contenida en la memoria interna del
dispositivo en cuestión. MIB es una base de datos completa y bien definida, con una estructura en árbol,
adecuada para manejar diversos grupos de objetos (información sobre variables/valores que se pueden
adoptar), con identificadores exclusivos para cada objeto.
20
La arquitectura SNMP opera con un reducido grupo de objetos que se encuentran definido con detalle en la
RFC 1066 "Base de información de gestión para la gestión de redes sobre TCP/IP".
Los 8 grupos de objetos habitualmente manejados por MIB (MIB−I), que definen un total de 114 objetos
(recientemente, con la introducción de MIB−II se definen hasta un total de 185 objetos), son:
− Sistema: Incluye la identidad del vendedor y el tiempo desde la última reinicialización del sistema de
gestión.
− Interfaces: Un único o múltiples interfaces, local o remoto, etc.
− ATT (Address Translation Table): Contiene la dirección de la red y las equivalencias con las direcciones
físicas.
− IP (Internet Protocol): Proporciona las tablas de rutas, y mantiene estadísticas sobre los datagramas IP
recibidos.
− ICMP (Internet Communication Management Protocol): Cuenta el número de mensajes ICMP recibidos y
los errores.
− TCP (Transmission Control Protocol): Facilita información acerca de las conexiones TCP,
retransmisiones, etc.
− UDP (User Datagram Protocol): Cuenta el número de datagramas UDP, enviados, recibidos y entregados.
− EGP (Exterior Gateway Protocol): Recoge información sobre el número de mensajes EGP recibidos,
generados, etc.
Gestión a distancia
Además de éstos, ciertos fabricantes están cooperando para el desarrollo de extensiones particulares para
ciertas clases de productos y la gestión remota de dispositivos, conocidas como:
RMON (Remote MONitor), normas RFC 1757 (antes 1271) para Ethernet y RFC 1513 para Token Ring del
IETF (Internet Engineering Task Force), que incluyen sobre unos 200 objetos clasificados en 9 grupos:
Alarmas, Estadísticas, Historias, Filtros, Ordenadores, N Principales, Matriz de Tráfico, Captura de Paquetes
y Sucesos. Con RMONv2 se decodifican paquetes a nivel 3 de OSI, lo que implica que el trafico puede
monitorizarse a nivel de direcciones de red (puertos de los dispositivos) y aplicaciones específicas.
RMON define las funciones de supervisión de la red y los interfaces de comunicaciones entre la plataforma de
gestión SNMP, los monitores remotos y los Agentes de supervisión que incorporan los dispositivos
inteligentes.
− Alarmas: Informa de cambios en las características de la red, basado en valores umbrales para cualquier
variable MIB de interés. Permite que los usuarios configuren una alarma para cualquier Objeto gestionado.
− Estadísticas: Mantiene utilización de bajo nivel y estadísticas de error.
− Historias: Analiza la tendencia, según instrucciones de los usuarios, basándose en la información que
mantiene el grupo de estadísticas.
− Filtros: Incluye una memoria para paquetes entrantes y un número cualquiera de filtros definidos por el
21
usuario, para la captura selectiva de información; incluye las operaciones lógicas AND, OR y NOT.
− Ordenadores: Una tabla estadística basada en las direcciones MAC, que incluye información sobre los
datos transmitidos y recibidos en cada ordenador.
− Los N principales: Contiene solamente estadísticas ordenadas de los "N" ordenadores definidos por el
usuario, con lo que se evita recibir información que no es de utilidad.
− Matriz de tráfico: Proporciona información de errores y utilización de la red, en forma de una matriz
basada en pares de direcciones, para correlacionar las conversaciones en los nodos más activos.
− Captura de paquetes: Permite definir buffers para la captura de paquetes que cumplen las condiciones de
filtrado.
− Sucesos: Registra tres tipos de sucesos basados en los umbrales definidos por el usuario: ascendente,
descendente y acoplamiento de paquetes, pudiendo generar interrupciones para cada uno de ellos.
A diferencia de la mayor parte de los protocolos TCP/IP, los mensajes SNMP no tienen campos fijos. Por el
contrario, utilizan la codificación ASN.1 estándar. Aunque esto puede ser difícil de codificar y entender para
los usuarios.
Un mensaje SNMP consiste en tres partes principales:
• Una versión de protocolo.
• Un identificador community de SNMP (utilizada para reunir los ruteadores administrados por un solo
administrador dado)
• Un área data.
El área de datos se divide en protocol data units (PDU's) . Cada PDU consiste en una solicitud (enviada por el
cliente) o una respuesta (mandada por el servidor).
El siguiente formato muestra cómo puede describirse el mensaje en la notación ASN.1.
SNMP − Message::=
SEQUENCE{
version INTEGER{
version − 1 (0)
},
community
OCTET STRING,
data
ANY
}
22
Formato del mensaje SNMP en notación ASN.1. El área data contiene uno o más protocolos de unidades de
datos.
Los cinco tipos de unidades de datos de protocolo se describen a continuación en notación ASN.1:
SNMP − PDUs::=
CHOICE{
get − request
GetRequest − PDU,
get − next − request − PDU,
GetNextRequest − PDU,
get − response
GetResponse − PDU
set − request
SetRequest − PDU,
trap
Trap − PDU,
}
Definición ASN.1 de un PDU del SNMP. La sintaxis para cada tipo de solicitud debe especificarse.
La definición específica de cada unidad de datos de protocolo consiste en uno de cinco tipos de solicitudes o
respuestas. Para completar la definición de un mensaje SNMP, debemos especificar la sintaxis de los cinco
tipos individuales. El siguiente segmento muestra la definición de una get − request:
GetRequest − PDU::= [0]
IMPLICIT SEQUENCE {
request − id
RequestID,
error − status
ErrorStatus,
error − index
ErrorIndex,
23
variable − bindings
VarBindList
}
Definición ASN.1 de un mensaje get − request. Formalmente el mensaje se define como un GetRequest −
PDU.
Otras definiciones en el estándar especifican los terminos no definidos restantes. Request − ID se define como
un entero de cuatro octetos(utilizado para cotejar las respuestas y las solicitudes). Tanto ErrorStatus como
ErrorIndex son enteros de un solo octeto que contienen un valor cero en una solicitud.
Por último, VarBindList contiene una lista de identificadores de objetos para los que el cliente busca valores.
en terminos de ASN.1 las definiciones especifican que VarBindList es una secuencia de pares de nombres y
valores de objetos. ASN.1 representa el par común de secuencia de dos elementos. Así, en la solicitud más
sencilla posible, VarBindList es una secuencia de dos elementos: un nombre y un null.
Un RFC (Request For Comment) es un documento que circula por Internet con especificaciones de un
"estándar de facto", o parte de uno. Desde una introducción general, pedagógica y divertida sobre TCP/IP
(RFC1180) hasta las particularidades del SNMP sobre redes IPX (RFC1419) los RFCs contienen las
verdaderas especificaciones de funcionamiento de Internet.
RFCs interesantes sobre SNMP:
ð RFC1157: SNMP
ð RFC1212: definiciones MIB
ð RFC1213: MIB−II, base de información gestionable para SNMP
ð RFC1270: servicios SNMP
ð RFC1303: convenciones para la descripción de agentes
ð RFC1418: SNMP y OSI
ð RFC1419: SNMP y IPX
El administrador SNMP maneja el software general y las comunicaciones entre los dispositivos que utilizan el
protocolo de comunicaciones SNMP.
Todos los dispositivos administrados por SNMP contienen el software agente SNMP y una base de datos
llamada Base de Información sobre la Administración (Management Information Base, MIB).
La MIB tiene 126 áreas de información sobre el estado del dispositivo, el desempeño del dispositivo, sus
conexiones hacia los diferentes dispositivos y su configuración. El administrador SNMP consulta a MIB a
través del software agente y puede especificar los cambios que se le hicieron a la configuración. La mayor
parte de los administradores SNMP consultan a los agentes en un intervalo regular, 15 minutos por ejemplo, a
menos que el usuario indique otra cosa.
El software agente SNMP por lo general es bastante pequeño (comúnmente de 64KB) dado que el protocolo
24
SNMP es sencillo. SNMP está diseñado para ser un protocolo de sondeo (polling), lo que quiere decir que el
administrador produce mensajes para el agente. Los mensajes SNMP se colocan dentro de un datagrama UDP
y se enrutan vía IP (aunque podrían utilizarse otros protocolos). Existen cinco tipos de mensaje que están
disponibles en SNMP:
• Get request (Obtener solicitud): Utilizado para consultar una MIB.
• Get next request (Obtener la siguiente solicitud): Utilizado para leer secuencialmente a través de una
MIB.
• Get response (Obtener respuesta): Utilizado para lograr una respuesta a un mensaje para obtener
solicitud (get request).
• Set request (Fijar solicitud): Utilizado para fijar un valor en la MIB.
• Trap (Trampa): Utilizado para reportar eventos.
El puerto UDP 161 se utiliza para todos los mensajes, excepto para las trampas, que llegan al puerto UDP 162.
Los agentes reciben sus mensajes del administrador a través del puerto UDP 161 del agente.
Dado que UDP no tiene conexiones, no existe confiabilidad inherente en el envío de los mensajes. Otro
problema es que SNMP proporciona un solo protocolo de mensajes, por lo que no pueden realizarse mensajes
de filtrado. SNMP utiliza el sondeo, lo que ocupa una considerable cantidad de ancho de banda. Los
intercambios entre SNMP y su más reciente sucesor, CMIP, en el futuro tomarán decisiones más difíciles
concernientes al protocolo de administración.
SNMP permite la administración mediante proxy (máquina delegada), lo que significa que un dispositivo con
un agente SNMP y una MIB puede comunicarse con otros dispositivos que no tengan todo el software agente
SNMP.
Esta administración proxy permite que a través de una máquina que esté conectada se controlen otros
dispositivos, colocando la MIB del dispositivo dentro de la memoria del agente. Por ejemplo, una impresora
puede controlarse mediante administración proxy desde una estación de trabajo que actúe como un agente
SNMP, también corra el agente proxy y la MIB para la impresora.
Dependencia de protocolos
El gráfico siguiente muestra las dependencias entre los principales protocolos, entre ellos SNMP. Cada
polígono cerrado corresponde a un protocolo y está colocado directamente arriba de los protocolos que
utiliza. Por ejemplo, SMTP depende del TCP que a su vez depende del IP.
La capa inferior representa todos los protocolos que proporciona el hardware. La segunda capa está
integrada por las listas inferiores de ARP y RARP. La tercera capa de la parte inferior contiene IP. IP
es el único protocolo que ocupa toda la capa, los protocolos de más bajo nivel entregan información que
llega del IP y los de más alto nivel deben utilizar IP para enviar datagramas.
CONFIGURACIÓN DE SNMP EN UNIX
SNMP sigue siendo un protocolo muy orientado a UNIX, aunque otros sistemas operativos como WIndows
NT, soportan el software SNMP para cliente y servidor.
El software para cliente se ejecuta a través del daemon snmpd que generalmente corre todo el tiempo que se
utiliza SNMP en la red.
UNIX ofrece varios comandos, basados en SNMP, para que los administradores de red obtengan información
desde una MIB o desde un dispositivo compatible con SNMP. Los comandos exactos varían un poco
dependiendo de la aplicación, pero la mayor parte de los sistemas soportan los comandos mostrados en la
siguiente tabla:
Comando
Descripción
25
getone
getnext
getid
getmany
snmpstat
getroute
setany
Utiliza el comando get de SNMP para recuperar un valor variable
Utiliza el comando getnext de SNMP para recuperar el siguiente valor de
la variable
Recupera los valores para sysdesc r, sysobj ect ID y sysUpTime
Recupera un grupo de variables MIB
Recupera el contenido de las estructuras de datos de SNMP
Recupera la información del enrutamiento
Utiliza el comando set de SNMP para fijar un valor de la variable
Ninguno de los comandos SNMP puede considerarse amigable, dado que sus respuestas son breves y algunas
veces resultan difíciles de analizar. Por esta razón, muchos analizadores de red basados en GUI se están
volviendo populares, al ofrecer acceso basado en un menú para muchas funciones SNMP, así como una mejor
presentación de los datos. Una herramienta SNMP basada en GUI puede presentar despliegues gráficos a todo
color para las estadísticas de la red, en tiempo real. Sin embargo, estas herramientas GUI tienden a ser
costosas.
45
26