Federico D. R.

Navarro

Administracin de Redes

ADMINISTRACIN DE REDES
CAPITULO 8 Administracin de Redes Internet: SNMPv1 y MIB-II
1. INTRODUCCIN
DE

La administracin de redes, dispositivos y hosts es referida en Internet como ADMINISTRACIN RED, en cambio en OSI se conoce como ADMINISTRACIN DE SISTEMAS.

Originalmente en Internet, la administracin de redes se haca usando el Simple Gateway Monitoring Protocol (SGMP). Luego, se defini el SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) para la administracin de redes y dispositivos de red. SNMP necesita, debajo de l, el soporte de las capas de transporte (proveyendo multiplexacin y demultiplexacin de servicios, y checksum para confiabilidad ) y de red (ruteo entre redes, proteccin de entidades SNMP de las diferencias del medio fsico, fragmentacin y reensamblado de paquetes).
(Fig. 8.1) PROTOCOLOS DE ADMINISTRACIN SNMP:

Los objetos a ser administrados se definen en la BASE DE INFORMACIN DE ADMINISTRACIN (MIB). Estos objetos deben seguir un determinado conjunto de reglas como las mencionadas en la ESTRUCTURA DE INFORMACIN DE ADMINISTRACIN (SMI). En Internet, los OBJETOS son similares a los atributos de OSI, y un GRUPO DE OBJETOS es anlogo a una clase de MO de OSI. Cada objeto puede tener una o ms instancias, cada una de las cuales, a su vez, tiene uno o ms valores. El SISTEMA DE ADMINISTRACIN DE RED consiste de una o ms ESTACIONES DE ADMINISTRACIN DE RED (NMSs), anlogo a un manager, y uno o ms ELEMENTOS DE RED (NEs) con funciones de administracin de red (desarrolladas en los agentes), informacin de administracin y protocolos de administracin.
(Fig. 8.2) ADMINISTRACIN DE RED INTERNET:

-1-

Federico D. R. Navarro

Administracin de Redes

Las NMSs tienen, principalmente, las siguientes funciones: Recuperar valores de los objetos en NEs usando agentes (mediante Get). Cambiar los valores de objetos en NEs usando agentes (mediante Set). Enviar requerimientos a los agentes. Recibir respuestas y traps (notificaciones) de los agentes. Las ENTIDADES DE APLICACIN, que pueden ser Administrador o Agente, intercambian informacin de administracin, y se conocen como ENTIDADES DE APLICACIN SNMP (SNMP AEs). Los AGENTES residen en NEs conocidos como NODOS ADMINISTRADOS, que son dispositivos tales como hosts, routers, adaptadores LAN, mdems, hubs, multiplexores, impresoras . Tienen las siguientes funciones: Recuperar informacin de administracin de los objetos (recursos) que controla ( Get). Alterar los valores de los objetos (Set). Recibir respuestas y traps de los objetos, y enviarlos, a su vez, a las NMSs.

SNMP se usa para comunicar informacin de administracin entre una estacin de administracin y los agentes. FILOSOFA SNMP:

SEGUIDA PARA EL DISEO DE

Protocolo de administracin simple y de bajo costo. Administracin de red robusta y capaz de proveer servicios an cuando el estado de la red no sea confiable o cuando haya errores. MIB extensible fcilmente: tendr definidos objetos centrales y se podrn agregrar objetos nuevos. En la distribucin de la carga de trabajo entre NMSs y agentes, la mayor carga de trabajo ser descargada en las NMSs. El transporte para llevar protocolos de administracin es UDP sin conexin, porque un transporte orientado a la conexin agregara complejidad. Objetivo inicial: fcil migracin a la administracin de red de OSI . Hoy, ese objetivo est cuestionado: algunos estn buscando el crecimiento independiente de la administracin de red Internet.

2.

MARCO

DE

REFERENCIA

DE

SNMPV1

El framework de administracin de red original se conoca como SNMP Versin 1 (SNMPv1) y consista de los siguientes RFCs: 1155 (sintaxis y semntica para definir objetos para administracin de red - SMI), 1157 (protocolo de administracin para acceder a los objetos, monitorearlos y controlarlos - SNMP) 1212 (lineamientos para definir nuevos mdulos sin generar redundancia MIB Concisa).

Luego, se agreg el RFC 1213 que provee las definiciones de un conjunto central de objetos MIB II.
(Fig. 8.3) FRAMEWORK DE ADMINSTRACIN DE RED SNMPV1:
RFC 1155 (SMI)

RFC 1212 (MIB Concisa)

Framework de Administracin de Red SNMPv1

RFC 1213 (MIB-II)

-2RFC 1157 (SNMP)

Federico D. R. Navarro

Administracin de Redes

Para lograr que SNMP sea un protocolo simple, se establecieron las siguientes restricciones (las tres primeras son algunas de las razones de elegir UDP sin conexin): Evitar la sobregarga de tener que establecer, mantener y cortar una o ms conexiones por cada operacin de una entidad SNMP sobre un objeto. Obviar el reensamblado de frames. Evitar la recuperacin de fallas. Limitar las operaciones de recuperacin o configuracin de los valores de una variable. Los traps enviados desde los agentes son muy limitados para reducir trfico en la red. Evitar los comandos imperativos o que disparan otras acciones.

Cuando una SNMP AE en un agente se asocia con un conjunto de SNMP AEs en uno o ms administradores, este par se conoce como COMUNIDAD. Cada comunidad tiene un identificador conocido como NOMBRE DE COMUNIDAD.
(Fig. 8.4) COMUNIDAD SNMPV1:

Un MENSAJE SNMP (Fig. 8.23) consiste de un IDENTIFICADOR DE VERSIN, un NOMBRE DE COMUNIDAD SNMP y una PDU SNMP. Los mensajes intercambiados entre una NMS y los agentes son independientes unos de otros. En la implementacin de SNMP se recomienda que la longitud de los mensajes no
sea ms de 484 octetos.

El esquema de autenticacin de comunidad SNMP determina cundo los mensajes enviados entre AEs son autnticos.

3.

OBJETOS

DE INTERNET

SNMP usa ASN.1 para definir objetos y las PDUs intercambiadas , usando slo un subconjunto de TIPOS DE DATOS definidos en ASN.1 para OSI: INTEGER, OCTET STRING, OBJECT IDENTIFIER, NULL, SEQUENCE y SEQUENCE OF. SNMP usa slo un subconjunto del BER de OSI para sintaxis de transferencia. El RFC 1155 establece CMO DEBEN DEFINIRSE sigue: 1. NOMBRE
LOS

OBJETOS. La sintaxis de un objeto es como

DE OBJETO: consiste del OBJECT DESCRIPTOR (nombre textual nico, consistente de un string imprimible) junto con el OBJECT IDENTIFIER (del rbol jerrquico de registracin de objetos ). Ej.: sysLocation {system 6} : sysLocation es el DESCRIPTOR DE OBJETO y {system 6} es el IDENTIFICADOR DE OBJETO.

2. SINTAXIS: tipo de objeto, que debe mapearse con uno de los tipos de datos permitidos por ASN.1. 3. DEFINICIN: descripcin no ambigua del tipo de objeto. 4. ACCESO: establece cmo los objetos pueden ser accedidos por operaciones de administracin , y es el mnimo nivel soportado por un tipo de objeto. Los valores pueden ser: read-only (pueden usarse las operaciones de GetRequest y GetNextRequest; no se puede usar SetRequest), readwrite (GetRequest, GetNextRequest y SetRequest), write-only (SetRequest) and not-accesible. 5. ESTADO: mandatory, optional u obsolete. El estandar SMI del RFC 1155 define adems los siguientes TIPOS DE OBJETOS ADICIONALES: 1. NETWORK ADDRESS: actualmente slo se permite la familia Internet de direcciones de red. 2. IP ADDRESS: se representa usando OCTET STRING.

-3-

Federico D. R. Navarro

Administracin de Redes

3. COUNTER: valor entero no negativo, que se incrementa de 0 a un mximo de 2 32-1. Despus de alcanzar el mximo, se pone a 0 y vuelve a ir incrementndose (wrapping around). 4. GAUGE: valor entero no negativo, que puede incrementarse o decrementarse. El mximo permitido es 232-1. Despus de alcanzar el mximo, comienza a decrementarse hasta llegar a 0 (no wrapping around). 5. TIMETICKS: entero no negativo que representa en centsimas de segundos el tiempo transcurrido desde una determinada accin. 6. OPAQUE: permite a un objeto transmitir cualquier dato como un OCTET STRING (obsoleto; slo para compatibilidad).

4.

DEFINICIONES SMI

El SMI del RFC 1155 cubre el modelo de informacin de objeto y un conjunto de tipos genricos usados para describir informacin de administracin. Se usa para definir las
Ej.:
ESTRUCTURAS DE DATOS DEL

SNMP (es muy similar a GDMO).

Ver DEFINICIONES en pgs. 176 178. tokenRingPrice OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS optional ::= {enterprises 100]

5.

BASE

DE INFORMACIN DE

ADMINISTRACIN (MIB-II)

Los detalles de los objetos se almacenan en una base de datos llamada BASE DE INFORMACIN DE ADMINISTRACIN (MIB). Aqu, los objetos tienen el tipo de objeto descripto por el OBJECT DESCRIPTOR junto con el OBJECT IDENTIFIER. Las MIBs estn definidas por diferentes RFCs. El RFC 1212, Definiciones de MIB Concisa, provee mtodos para limpiar y remover las descripciones de objetos redundantes. En el RFC 1213, MIB II para Administracin de Redes de Internets basadas en TCP/IP, la MIB es otra mejora sobre los RFCs anteriores (1156 y 1158): agrega y refina objetos ya definidos, y usa el RFC 1212.

5.1-

JERARQUA DE REGISTRACIN INTERNET

Para manipulacin con propsitos de administracin, los objetos deben estar identificados unvocamente, lo cual se lleva a cabo usando IDENTIFICADORES DE OBJETOS, que son series de identificadores derivados por etiquetar los nmeros adjuntos a los nodos, desde la raz, en la jerarqua de registracin, separados por puntos.
(Fig. 8.5) JERARQUA DE REGISTRACIN INTERNET

5.2-

IDENTIFICACIN DE INSTANCIAS DE OBJETOS

Para conocer el valor de una instancia de un objeto, se necesita identificar la instancia, usando el OBJECT IDENTIFIER. CONVENCIONES
PARA IDENTIFICAR INSTANCIAS:

1. Objetos Escalares (o Variables Simples): tienen slo una instancia asociada con cada objeto escalar, que se identifica por concatenar un valor 0 al OBJECT IDENTIFIER. 2. Objetos Columnares (o Tablas): las instancias de estos objetos se identifican en una tabla por la clusula INDEX, que se refiere a una fila en una tabla. (Fig. 8.6)

-4-

Federico D. R. Navarro

Administracin de Redes

3. Tablas y Filas Conceptuales: no tienen identificadores de instancias asociados. 4. Orden Lexicogrfico: los OBJECT IDENTIFIERs estn ordenados en forma creciente en las MIBs SNMP.

-5-

Federico D. R. Navarro

Administracin de Redes

5.3-

MANIPULACIN DE TABLAS

En las tablas de la MIB-II, cada OBJETO est representado por una columna, y el valor de cada de objeto por una fila. Se atraviesa completamente cada columna a lo largo, y luego uno se mueve a la columna siguiente.
INSTANCIA

Para agregar un valor a una instancia, se ingresa el valor en una fila con una operacin Set.
(se recomienda removerlo despus).

Para borrar una entrada, nuevamente usando la operacin Set, se pone el valor como invlido

6.

DETALLES

OBJETOS

DE LA

MIB-II (RFC 1213)

Cuando se definen nuevas MIBs, es necesario seguir algunas reglas, para permitir la coexistencia de mltiples versiones de MIBs: Los tipos de objetos viejos no se borran, pero deben ser removidos en las versiones siguientes. Las semnticas de los tipos de objetos viejos no debera cambiar entre versiones. Sin embargo, si se necesita cambiar la semntica, deben formarse nuevos tipos de objetos. En la MIB, slo se definen los objetos esenciales, siguiendo los lineamientos provistos por la SMI para definir nuevos objetos. Estos nuevos objetos pueden agregarse bajo el subrbol {experimental 3} o bajo {enterprises 4.1}. A la MIB-II se le ha agregado los tipos de datos DisplayString (OCTET STRING de caracteres ASCII imprimibles, de 0 a 255 octetos) , y PhyAddress (OCTET STRING usado para representar direcciones fsicas). Los objetos en Internet se clasifican en diferentes grupos, bajo {mgmt 2}. Los objetos bajo estos grupos deben implementarse como un grupo. Ej.: si se implementa el grupo TCP, entonces todos
los objetos bajo el grupo TCP, tales como tcpRtoAlgorithm y tcpRtoMin, deben ser implementados. (Fig. 8.7) GRUPOS DE OBJETOS DE LA MIB-II:

6.1-

Grupo System (obligatorio)

EQUIPO:

Sus objetos especifican nombre, ubicacin y descripcin del HW y SW, vendedor, nombre de dominio, etc.
(Fig. 8.8) system (mib-2 1) sysDescr (1) sysObjectID (2) sysUpTime (3) sysContact (4) sysName (5) sysLocation (6) sysServices (7)

nombres y versiones del

La mayora de estos objetos son tiles para administracin de la configuracin y de fallas.

6.2-

Grupo Interfaces (obligatorio)

Se refiere a las
INTERFACES

asociadas con una subred.

Consiste de detalles como cantidad de interfaces, objetos en la subred, fabricante de cada interface, protocolos de capa fsica y de enlace, ancho de banda, etc. til para administracin de performance y de fallas.
(Fig. 8.9) interfaces (mib-2 2) ifNumber (1) ifTable (2) ifEntry (1) ifIndex (1) ifDescr (2) ifType (3) ifMtu (4) ifSpeed (5) ifPhyAddress (6)

-6-

Federico D. R. Navarro

Administracin de Redes

ifAdminStatus (7) ifOperStatus (8) ifLastChange (9) ifInOctets (10) ifInUcastPkts (11) ifInNUcastPkts (12) ifInDiscards (13) ifInErrors (14) ifInUnknownProtos (15) ifOutOctets (16) ifOutUcastPkts (17) ifOutNUcastPkts (18) ifOutDiscards (19) ifOutErrors (20) ifOutQLen (21) ifSpecific (22)

6.3-

Grupo Address Translation (obligatorio)

Este grupo se provee para compatibilidad con MIB-I, y podra ser removida en versiones posteriores de MIB.

MAC).

Tiene una tabla para mapear direcciones de red (como dir. IP) a direcciones fsicas (como dir.
(Fig. 8.10) at (mib-2 3) atTable (1) atEntry (1) atIfIndex (1) atPhyAddress (2) atNetAddress (3)

6.4-

Grupo IP (obligatorio)
Provee estadsticas sobre DATAGRAMAS IP, y es til para performance.
(Fig. 8.11) ip (mib-2 4) ipForwarding (1) ipDefaultTTL (2) ipInReceives (3) ipInHdrErrors (4) ipInAddrErrors (5) ipForwDatagrams (6) ipInUnknownProtos (7) ipInDiscards (8) ipInDelivers (9) ipOutRequests (10) ipOutDiscards (11) ipOutNoRoutes (12) ipReasmTimeout (13) ipReasmReqds (14) ipReasmOKs (15) ipReasmFails (16) ipFragOKs (17) ipFragFails (18) ipFragCreates (19) ipAddrTable (20) ipAddrEntry (1) ipAdEntAddr (1) ipAdEntIfIndex (2) ipAdEntNetMask (3) ipAdEntBcasAddr (4) ipAdEntReasmMaxSize (5) ipRouteTable (21) ipRouteEntry (1) ipRouteDest (1) ipRouteIfIndex (2) ipRouteMetric1 (3) ipRouteMetric2 (4) ipRouteMetric3 (5) ipRouteMetric4 (6) ipRouteNextHop (7) ipRouteType (8) ipRouteProto (9)

(Fig. 8.12)

(Fig. 8.13)

-7-

Federico D. R. Navarro

Administracin de Redes

ipRouteAge (10) ipRouteMask (11) ipRouteMetric5 (12) ipRouteInfo (13) ipNetToMediaTable (22) ipNetToMediaEntry (1) ipNetToMediaIndex (1) ipNetToMediaPhysAddress (2) ipNetToMediaNetAddress (3) ipNetToMediaType (4) ipRoutingDiscards (23)

(Fig. 8.14)

6.5-

Grupo ICMP (obligatorio)

Provee estadsticas sobre MENSAJES ICMP, y es til para administracin de performance. Bsicamente tiene contadores sobre diferentes tipos y condiciones de mensajes ICMP.
(Fig. 8.15) icmp (mib-2 5) icmpInMsgs (1) icmpInErrors (2) icmpInDestUnreachs (3) icmpInTimeExcds (4) icmpInParmProbs (5) icmpInSrcQuenchs (6) icmpInRedirects (7) icmpInEchos (8) icmpInEchoReps (9) icmpInTimestamps (10) icmpInTimestampReps (11) icmpInAddrMasks (12) icmpInAddrMaskReps (13) icmpOutMsgs (14) icmpOutErrors (15) icmpOut DestUnreachs (16) icmpOutTimeExcds (17) icmpOutParmProb (18) icmpOutSrcQuenchs (19) icmpOutRedirects (20) icmpOutEchos (21) icmpOut EchoReps (22) icmpOutTimestamps (23) icmpOutTimestampReps (24) icmpOutAddrMasks (25) icmpOutAddrMaskReps (26)

6.6-

Grupo TCP (obligatorio si se implementa TCP)

Provee algoritmos, parmetros y estadsticas sobre TCP. Supervisa segmentos enviados y recibidos, cantidad actual y acumulada de conexiones abiertas, estadsticas de errores. Es til para administracin de performance.
(Fig. 8.16) tcp (mib-2 6) tcpRtoAlgorithm (1) tcpRtoMin (2) tcpRtoMax (3) tcpMaxConn (4) tcpActiveOpens (5) tcpPassiveOpens (6) tcpAttemptFails (7) tcpEstabResets (8) tcpCurrEstab (9) tcpInSegs (10) tcpOutSegs (11) tcpRetransSegs (12) tcpConnTable (13) tcpConnEntry (1) tcpConnState (1) tcpConnLocalAddress (2) tcpConnLocalPort (3) tcpConnRemAddress (4) tcpConnRemPort (5)

(Fig. 8.17)

-8-

Federico D. R. Navarro

Administracin de Redes

tcpInErrs (14) tcpOutRsts (15)

6.7-

Grupo UDP (obligatorio si se implementa UDP)

Provee estadsticas de trfico UDP: detalles sobre datagramas UDP y puntos extremos UDP.
(Fig. 8.18) udp (mib-2 7) udpInDatagrams (1) udpNoPorts (2) udpInErrors (3) udpOutDatagrams (4) udpTable (5) udpEntry (1) udpLocalAddress (1) udpLocalPort (2)

6.8-

Grupo EGP (obligatorio si se implementa EGP)

Provee estadsticas de trfico EGP: detalles sobre mensajes EGP generados, recibidos y no enviados, y condiciones de vecinos EGP.
(Fig. 8.19) egp (mib-2 8) egpInMsgs (1) egpInErrors (2) egpOutMsgs (3) egpOutErrors (4) egpNeighTable (5) egpNeighEntry (1) egpNeighState (1) egpNeighAddr (2) egpNeighAs (3) egpNeighInMsgs (4) egpNeighInErrs (5) egpNeighOutMsgs (6) egpNeighOutErrs (7) egpNeighInErrMsgs (8) egpNeighOutErrMsgs (9) egpNeighStateUps (10) egpNeighStateDowns (11) egpNeighIntervalHello (12) egpNeighIntervalPoll (13) egpNeighMode (14) egpNeighEventTrigger (15) egpAs (6)

(Fig. 8.20)

6.9-

Grupo CMOT
Como este grupo ha sido relegado a estado histrico, las posibilidades de usarlo son muy remotas.

6.10- Grupo Transmission

Para objetos relacionados con el medio de transmisin subyacente. Reservado para MIBs especficas de un medio fsico. 6.11-

Grupo SNMP (obligatorio si se soporta SNMP)

Provee estadsticas de trfico y operaciones SNMP . Como un nodo puede ser un agente o una estacin administradora, en algunos casos los objetos de la lista pueden tener valor 0.
(Fig. 8.21) snmp (mib-2 11) snmpInPkts (1) snmpOutPkts (2) snmpInBadVersions (3) snmpInBadCommunityNames (4) snmpInBadCommunityUses (5) snmpInASNParseErrs (6) (7) No usado snmpInTooBigs (8)

-9-

Federico D. R. Navarro

Administracin de Redes

snmpInNoSuchNames (9) snmpInBadValues (10) snmpInReadOnlys (11) snmpInGenErrs (12) snmpInTotalReqVars (13) snmpInTotalSetVars (14) snmpInGetRequests (15) snmpInGetNexts (16) snmpInSetRequests (17) snmpInGetResponses (18) snmpInTraps (19) snmpOutTooBigs (20) snmpOutNoSuchNames (21) snmpOutBadValues (22) (23) No usado snmpOutGenErrs (24) snmpOutGetRequests (25) snmpOutGetNexts (26) snmpOutSetRequests (27) snmpOutGetResponses (28) snmpOutTraps (29) snmpEnableAuthenTraps (30)

7.

CMO
0. 1. 2. 3. 4.

OPERA

SNMPV1 (RFC 1157)

Las PDUs usadas en SNMPv1 son: GetRequest GetNextRequest GetResponse SetRequest Trap

Cuando una entidad de protocolo enva una PDU GetRequest, GetNextRequest, o SetRequest, la respuesta es una PDU GetResponse. Cuando hay errores o casos especiales, se envan Traps de una entidad de protocolo a la otra. Los Traps son anlogos a las notificaciones de OSI.
(Fig. 8.22) PDUS DEL PROTOCOLO DE ADMINISTRACIN SNMPV1:
GetRequest GetNextReque st SetRequest

Entidad SNMPv1 (Manager )

GetRespons e Trap

Entidad SNMPv1 (Agente)

Formato de las PDUs SNMPv1: Las PDUs GetRequest, GetNextRequest, SetRequest y GetResponse tienen los siguientes campos: 1. Tipo de PDU: nmero identificador de cada tipo de PDU (VER PDUs usadas en SNMPv1). Ej: 0 =
GetRequest. duplicadas.

2. Request-id: usado como identificador para correlacin de las respuestas, o para identificar respuestas 3. Error-Status: indica el tipo de error (VER Errores posibles). Ej: 1 = tooBig 4. Error-Index: da la posicin de la variable responsable del error. 5. Variable-Bindings: combinacin de nombre y valor de una variable (instancia). Puede ser una lista de
variables.

- 10 -

Federico D. R. Navarro

Administracin de Redes

(Fig. 8.23) FORMATO DE LOS MENSAJES SNMPV1 Y DE LAS PDUS SNMPV1:

Mensaje SNMPv1:

Version

Communida d

Datos

OR PDUs GetRequest, GetNextRequest, GetResponse y SetRequest de SNMPv1:

Tipo PDU Request-Id

ErrorStatus

ErrorIndex

Variable-bindings

PDUTrap de SNMPv1:

Enterpris e

AgentAddress

GenericTrap

SpecificTrap

Timestamp

Variable-bindings

Campo Variable-bindings: Nombre 1 Valor1 ... ... Nombre N Valor N

La PDU Trap, en cambio, debe tener lo siguiente: 1. Tipo de PDU: nmero identificador del tipo de PDU = 4. 2. Enterprise: OBJECT IDENTIFIER del tipo de objeto generador del trap. 3. Agent-Addr: direccin de red del objeto generador del trap. 4. Generic-Trap: tipo de trap genrica. (VER Traps Genricas). Ej: 2 = linkDown. 5. Specific-Trap: cdigo especfico, presente aunque Generic-Trap no sea enterpriseSpecific. 6. Time-stamp: TimeTicks del tiempo transcurrido entre la ltima (re)inicializacin de la entidad de red y
la generacin del trap.

7. Variable-Bindings: informacin relevante. Traps Genricas: 0. coldStart: cuando un agente se reinicializa y los detalles de configuracin e implementacin podran
cambiar.

1. warmStart: cuando se reiniciliza no hay cambios en los detalles de configuracin e implementacin. 2. linkDown: cuando los enlaces de comunicacin usados se afectan (se refiere a una interface), y el
nombre y el valor del enlace afectado se suministra en variable bindings.

3. 4. 5. 6.

linkUp: dem linDown. authenticationFailure: cuando un mensaje de protocolo falla en la autenticacin. egpNeighborLoss: cuando un vecino EGP ya no est disponible. enterpriseSpecific: cuando los traps no pueden clasificarse especficamente en ninguno de los otros
traps.

Errores que pueden ocurrir usando SNMPv1 (valores que puede tomar el parmetro Error-Status) 0. 1. 2. 3. 4. 5. noError tooBig (Demasiado grande) = La respuesta no entra en el mensaje. noSuchName = La operacin especifica una variable que no existe. badValue = El valor dado en SetRequest no corresponde con el tipo, longitud o variable. readOnly = Se quiere modificar una variable de slo lectura. genErrs para cualquier otro tipo de error.

Cuando hay un error, se enva un trap de un agente a una NMS; una vez que este trap es recibido, la NMS debe enviar una respuesta. Luego, usando polling, se recupera informacin ms detallada.

Para recuperar informacin de administracin, SNMP usa una combinacin de traps y polling.

- 11 -

Federico D. R. Navarro

Administracin de Redes

Funcionamiento de las PDUs SNMP: SNMP se usa para transportar mensajes de una ENTIDAD DE PROTOCOLO (PE) a otra. Una PDU se construye en formato ASN.1 y es enviada a un autenticador, junto con el nombre de comunidad y las direcciones de origen y transporte . El autenticador chequea si las entidades de protocolo emisoras y receptoras realmente pueden intercambiar mensajes. El resultado del chequeo, que puede ser una falla de autenticacin o un objeto ASN.1, se enva de vuelta a la PE. Si el mensaje pasa la autenticacin, es formateado usando BER y enviado por el mecanismo de transporte a la PE receptora.
(Fig. 8.24) GENERACIN DE UN MENSAJE SNMPV1 - Construir PDU (objeto ASN.1)
- Agregar Nombre de Comunidad. - Agregar Direcciones de Transporte de Origen y Destino. - Chequear Autenticacin. - Construir otro Objeto ASN.1. - Construir mensaje ASN.1 (usando objeto ASN.1 y nombre de comunidad). - Serializar mensaje ASN.1 (usando BER).

(Fig. 8.25) RECEPCIN DE UN MENSAJE SNMPV1 ASN.1 - Parsear Mensaje ASN.1. - Parseado correcto? Serializar Mensaje

No

- Verificar Nmero de Versin. - Nmero de Versin S correcto? - Autenticar Mensaje. - Autenticacin correcta?

No

Descartar Datagrama.

No

- Generar trap (si es requerido).

- Parsear Objeto ASN.1. No - Parseado correcto?

- Enviar mensaje ASN.1 a la entidad SNMPv1 par.

S - Procesar PDU. - Generar respuesta (si se requiere).

En el lado del receptor, la PE receptora parsea los datos recibidos y chequea el nmero de versin. Si la PDU falla durante esta accin, el datagrama se descarta. Si no, los datos del usuario, el nombre de comunidad, y las direcciones de origen y destino van al autenticador. ste chequea si la PE receptora actualmente puede recibir datos de la PE emisora. El resultado puede ser una falla de autenticacin, en cuyo caso puede generarse un trap y se enva a la PE emisora. O bien, si el autenticador pasa el proceso de autenticacin, la PE receptora procesa el mensaje y toma la accin apropiada y enva la respuesta de vuelta al emisor.
Algunas aplicaciones de administracin pueden no necesitar la seguridad provista por la autenticacin. En tales implementaciones, pueden saltearse completamente los pasos de autenticacin. Adems, en algunos casos, pueden necesitarse pasos de seguridad adicionales , como funciones de control de acceso extras ; aqu la autenticacin requerida se gua por consideraciones de la implementacin .

Cuando se enva una PDU GetRequest, la PE receptora chequea si el nombre de objeto es correcto. Si no es correcto, el errorStatus es noSuchName. Una respuesta para GetRequest se enva en la forma de una PDU GetResponse, y debe hacerse con la capacidad de la PE local. Si no es posible generar respuestas, el errorStatus se pone a tooBig. Cuando se procesa un GetRequest, podran haber errores; entonces el errorStatus se establece a genError. Si no hay errores, errorStatus se pone a noError. GetNextRequest es similar a la GetRequest, excepto que se recupera el siguiente valor, en vez de uno suministrado. Se asume que la MIB tiene los nombres de objetos en orden lexicogrfico. Si un sucesor lexicogrfico no est disponible, errorStatus es puesto a genError.

- 12 -

Federico D. R. Navarro

Administracin de Redes

En SetRequest tambin, si un nombre de variable no est disponible, el errorStatus es puesto a noSuchName. Si el valor de una variable que debe ser cambiado al valor suministrado en SetRequest no est en conformidad con ASN.1, el errorStatus es puesto a badValue. Si el valor de una variable no puede cambiarse, este error se clasifica como genError. Sin embargo, si se cambia el valor de una variable al valor mencionado en SetRequest, la PDU GetResponse tiene errorStatus puesto a noError. Un Trap se usa para presentar problemas o cambios en Internet.

8.

PROXY

Es posible que una estacin de administracin no sea capaz de administrar un dispositivo, si responde a comandos propietarios. En tales casos, se usa un AGENTE PROXY. Entre un administrador y un agente proxy se usan protocolos estndares, y entre el agente proxy y los dispositivos administrados se usan protocolos propietarios. El proxy asume el rol de un agente con respecto al administrador, y acta como administrador para los dispositivos administrados.
(Fig. 8.26) CONCEPTO DE PROXY NMS
Protocolos Estndares

Prox y
Protocolos Nativos

Disp. Administrado

Disp. Administrado

Una de las principales funciones de un agente proxy es la conversin de protocolos. La conversin de protocolos estndares a protocolos propietarios puede hacerse por dos mtodos: 1. Mapeo o traduccin de cada campo de protocolos estndares a cada campo de protocolos propietarios. Sin embargo, en algunos casos no es posible el mapeo uno-a-uno de campos, ya que pueden no ser similares. Encapsulamiento de los protocolos estndares dentro de los campos de datos de los protocolos propietarios.

2.

La introduccin de un agente proxy agrega complejidad: requiere recursos, un nivel ms de comunicacin entre la estacin administradora y los dispositivos administrados, adems de backups adicionales para casos de fallas. Adems, un agente proxy provee la flexibilidad de hacer cumplir polticas de acceso. Un agente proxy puede usarse tambin para el reenvo selectivo de informacin a una estacin administradora.

- 13 -