Informática

Redes: Protocolos

Compartir 0 Me sirvió 0 No me sirvió

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:

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

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	IMATM Modelo B-T1	IMATM Modelo B-E1
Nombre de la placa frontal	IMATM-8T1/B	IMATM-8E1/B
Capacidad del bus de distribución	Sí	No aplicable
Retraso diferencial tolerable máximo	275 mseg	200 mseg
Cumplimiento con ATM Forum	Sí	Sí
Formatos de celda compatibles con la versión 3.X FW	No aplicable	No aplicable
Formatos de celda compatibles con la versión 4.X FW	STI/UNI/NNI	STI/UNI/NNI

Ancho de banda flexible

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:

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
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 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 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)

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

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.

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.

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.

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.

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 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	Significado
get-request	Obtener un valor desde una variable específica
get-next-request	Obtener un valor sin conocer su nombre exacto
get-response	Replicar a una operación fetch
set-request	Almacenar un valor en una variable específica
trap	Réplica activada por un evento

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.

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.

El MIB para TCP/IP divide la información de la administración en 8 categorís:

Categoría MIB	Incluye información sobre
system	Sistema operativo del anfitrión o del ruteador
interfaces	lnterfaz de red individual
addr.trans.	Dirección de traducción (por ejemplo, transformación ARP)
ip	Software de Protocolo de lnternet
icmp	Software de Protocolo de Mensajes de Control de lnternet
tcp	Software de Protocolo de Transmisión de lnternet
udp	Software de Protocolo de Datagrama de Usuario
egp	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.

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

}

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,

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 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
getone	Utiliza el comando get de SNMP para recuperar un valor variable
getnext	Utiliza el comando getnext de SNMP para recuperar el siguiente valor de la variable
getid	Recupera los valores para sysdesc r, sysobj ect ID y sysUpTime
getmany	Recupera un grupo de variables MIB
snmpstat	Recupera el contenido de las estructuras de datos de SNMP
getroute	Recupera la información del enrutamiento
setany	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.

Tal vez te pueda interesar:

Descargar

Enviado por:	Javier
Idioma:	castellano
País:	Venezuela

Palabras clave:

Informática Modelo de referencia Nativos Ancho de banda flexible Administración

Te va a interesar