Gabriel Tolosa Fernando Lorge Protocolo SNMP Simple Network

Administración y Gestión de Redes
Lic. en Sistemas de Información
Laboratorio de REDES
Recuperación de Información
y Estudios de la Web
Protocolo SNMP
Simple Network Management Protocol
Gabriel Tolosa
tolosoft@unlu.edu.ar
Fernando Lorge
florge@unlu.edu.ar
- 2015 -
Estándares
CMIP
SNMP
(OSI)
(IETF)
Common Management
Information Protocol
Simple Network
Management Protocol
Recomendaciones ITU-T
X.700, ISO/IEC 9596-1
RFC's
Diseñado en los '80 como el Inicialmente standard
standard para gestión de
simple mientras se
redes
desarrollaban alternativas
mejores
Estandarización muy lenta
Desplegado y adoptado
rápidamente
Complejo y requiere mas
recursos que snmp
Standard de facto
SNMP
Simple Network Management Protocol
●
Capa de aplicación, de la familia TCP/IP.
Facilita el intercambio de información de administración
entre dispositivos de red.
●
●
SNMP permite crear herramientas de gestión que:
●
Informen del funcionamiento de la red o subred
●
Detecten fallas y funcionamientos incorrectos
●
Permitan actuar sobre dispositivos de la red (por ejemplo,
modificando su configuración, desconectando equipos, etc.)
Arquitectura
agent data
managing
entity
data
managed device
agent data
network
management
protocol
managed device
agent data
agent data
managed device
managed device
Los
“Managed devices”
contienen
“Managed objects”
cuyos datos
son recolectados
dentro de una
“Management
Information Base”
usando un
“Network Management
Protocol”
Arquitectura
Cuatro pilares
●
MIB: Management Información Base.
- Colección de objetos identificados para la gestión, sus tipos y
relaciones en una entidad gestionada.
●
SMI: Structure of Management Information.
- Sintaxis usada para especificar una MIB (SMIv2). Define las reglas
generales para nombrar los objetos, definir sus tipos y codificar sus
valores.
●
SNMP.
- Protocolo para gestión. Sintaxis, semántica y temporización.
Permite leer (y modificar) los valores de las variables de los objetos
gestionados.
●
Seguridad, capacidades de administración
- Mayormente en la versión 3
Evolución
SNMPv1
Diseñado a mediados de los 80.
Idea: Lograr una solución temporal hasta la llegada de
protocolos de gestión mejores y más completos.
●
Basado en el intercambio de información de red a través
de mensajes (get y set), en texto plano.
●
Agentes y entidad administradora asociados a un grupo
denminado “comunidad”
● Read-Only, Read-and-write, Trap
●
●
No estaba pensado para poder gestionar
muchas redes (ni muy grandes)
Evolución
SNMPv2
Diseñado en 1993 y revisado en 1996 (SNMPv2c)
●
Incorpora:
●
Mensajes get-bulk-request (múltiples variables)
●
Mayor detalle en la definición de las variables.
●
Estructuras para facilitar el manejo de los datos.
No fue más que un parche, las innovaciones (como los
mecanismos de seguridad) no se llegaron
a implementar.
Evolución
SNMPv3
Año 2002 - Internet Standard
●
Énfasis en los mecanismos de seguridad.
●
●
●
Integridad del Mensaje: Asegura que el paquete no haya
sido alterado durante la transmisión.
Autenticación: Asegura la identidad del emisor del
mensaje. (Username, HMAC-MD5 y HMAC-SHA.)
Cifrado: Asegurar que el contenido del mensaje sólo sea
visible para las partes autorizadas.
(DES, 3DES, AES128, AES192, AES256)
Componentes
Estructura de la MIB
La ISO define una estructura jerárquica (niveles), donde se
identifican los objetos.
●
La MIB y los objetos contenidos en estas son situados en este
árbol siguiendo las normas determinadas.
●
Cada nivel, subnivel y objeto son representados con un nombre y
un número dentro del árbol (OID).
●
Se puede hacer referencia a un objeto empleando una secuencia
de nombres o de números.
●
Esta secuencia de nombres o números contiene la ruta que se
sigue desde la “raiz” del árbol hasta la “hoja”.
●
●
La hoja hace referencia al objeto que es
la última entidad posible.
Jerarquía
OIDs
OID (Object identifier)
● Se define a cada objeto de acuerdo a la posición que ocupa
dentro del árbol ISO.
Siguiendo la secuencia desde la raíz se localiza e identifica a
cada objeto. Dos formas de expresar un OID:
Composición textual de la localización.
OID del objeto (numéricamente).
●
Ejemplo: para hacer referencia al objeto sysName
MIB-II
RFC 1213
MIBs
ipForwarding OBJECT-TYPE
SYNTAX INTEGER {
forwarding(1),
-- acting as a gateway
not-forwarding(2) -- NOT acting as a gateway
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The indication of whether this entity is acting
as an IP gateway in respect to the forwarding of
datagrams received by, but not addressed to, this
entity. IP gateways forward datagrams. IP hosts
do not (except those source-routed via the host).
Note that for some managed nodes, this object may
take on only a subset of the values possible.
Accordingly, it is appropriate for an agent to
return a `badValue' response if a management
station attempts to change this object to an
inappropriate value."
::= { ip 1 }
ipDefaultTTL OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The default value inserted into the Time-To-Live
field of the IP header of datagrams originated at
this entity, whenever a TTL value is not supplied
by the transport layer protocol."
::= { ip 2 }
ipInReceives OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of input datagrams received from
interfaces, including those received in error."
::= { ip 3 }
Para definir los objetos en
la MIB se usa SMI, que
establece reglas para:
●
●
●
●
●
Nombrar cada objeto
Definir el tipo de valor
Control de acceso
Tipo de respuesta
Descripción
(Se definen usando
ASN.1)
Árbol de MIB
Ejemplo
MIBs
Ejemplo
udpTable OBJECT-TYPE
SYNTAX SEQUENCE OF UdpEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A table containing UDP listener information."
::= { udp 5 }
udpEntry OBJECT-TYPE
SYNTAX UdpEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Information about a particular current UDP
listener."
INDEX
{ udpLocalAddress, udpLocalPort }
::= { udpTable 1 }
UdpEntry ::=
SEQUENCE {
udpLocalAddress
IpAddress,
udpLocalPort
INTEGER (0..65535)
}
udpLocalAddress OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The local IP address for this UDP listener. In
the case of a UDP listener which is willing to
accept datagrams for any IP interface associated
with the node, the value 0.0.0.0 is used."
::= { udpEntry 1 }
udpLocalPort OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The local port number for this UDP listener."
::= { udpEntry 2 }
Ejemplo Snmpbulkwalk:
iso.3.6.1.2.1.7.5.1.1.10.0.0.204.123 = IpAddress: 10.0.0.204
iso.3.6.1.2.1.7.5.1.2.10.0.0.204.123 = INTEGER: 123
MIB-II, en detalle
System Group
● sysDescr - Full description of the system (version, HW, OS)
● sysObjectID - Vendor's object identification
● sysUpTime - Time since last re-initialization
● sysContact - Name of contact person
● sysServices - Services offered by device
Interfaces Group
● ifIndex - Interface number
● ifDescr - Interface description
● ifType - Interface type
● ifMtu - Size of the largest IP datagram
● ifAdminisStatus - Status of the interface
● ifLastChange - Time the iface entered in the current status
● ifINErrors - Number of inbound packets with errors
● ifOutDiscards - Number of outbound packets discarded
MIB-II
Address Translation Group
● atTable - Table of address translation
● atEntry - Each entry containing one network address to
physical address equivalence
● atPhysAddress - The media-dependent physical address
● atNetAddress - The network address corresponding to the
media-dependent physical address
IP Group
● ipForwarding - Indication of whether this entity is an IP gw
● ipInHdrErrors - No of input datagrams discarded due to
errors in their IP headers
● ipInAddrErrors - No of input datagrams discarded due to
errors in their IP address
● ipInUnknownProtos - No of input datagrams discarded
due to unknown or unsupported protocol
● ipReasmOKs - Number of IP datagrams re-assembled
● ipRouteMask - Subnet-mask for route
MIB-II
ICMP Group
● icmpInMsgs - No of ICMP messages received
● icmpInDestUnreachs - No of ICMP dst-unreachable recv
● icmpInTimeExcds - No of ICMP time-exceeded msg recv
● icmpInSrcQuenchs - No of ICMP source-quench msg recv
● icmpOutErrors - No of ICMP msg not sent (ICMP problems)
TCP Group
● tcpRtoAlgorithm - Algorithm to determine the timeout for
retransmitting unacknowledged octets
● tcpMaxConn - Limit on the no of TCP connections
● tcpActiveOpens - No of times TCP conns have made a
direct transition to the SYN-SENT state from CLOSED state
● tcpInSegs
- No of segments received, including those
received in error
● tcpConnRemAddress - Remote IP address for this conn.
● tcpInErrs - No of segments discarded due to format error
● tcpOutRsts - No of resets generated.
MIB-II
UDP Group
● udpInDatagrams - No of UDP datagrams delivered to UDP
users
● udpNoPorts - No of received UDP datagrams for which
there was no application at the destination port
● udpInErrors - No of received UDP datagrams that could not
be delivered for reasons other than the lack of an
application at the destination port
● udpOutDatagrams - No of UDP datagrams sent from this
entity
Modos de Operación
managing
entity
request
managing
entity
trap msg
response
agent data
Managed device
request/response mode
agent data
Managed device
trap mode
Ejemplos
SetRequest: modifica el valor de un objeto dentro del dispositivo,
tras la modificación el Agente SNMP confirma la operación con un
GetResponse.
TRAPs
Trap: es una comunicación asíncrona que parte desde el Agente
hacia el Administrador SNMP.
Tiene como objeto emitir una alerta al administrador ante un evento
sucedido en el dispositivo.
Hay seis tipos de trap estandarizados y se ha reservado un espacio
para poder definir nuevos traps (propietarias).
Operación
Primitivas
Mensajes SNMP
Operación
Función
get-request
Solicita el valor de una variable específica
get-next-request
Solicita el valor de una variable sin especificar su nombre.
Utilizada para navegar un subárbol en órden lexicográfico
set-request
Solicita la modificación del valor de una variable
get-bulk-request (v2 y 3)
Solicita un conjunto de valores en una sola operación
get-response
Respuesta a una petición get-reques, get-next-request o setrequest
Inform (v2 y 3)
Permite el envío de traps con confirmación
report (v3)
Permite la comunicación entre administradores
trap
Mensaje asíncrono enviado por los agentes a la NMS para
informar alguna condición especial
Códigos del Protocolo
Tipos de PDUs
Tipo
Tag (Binario)
Tag (Hex)
get-request
10100000
A0
get-next-request
10100001
A1
get-response
10100010
A2
set-request
10100011
A3
get-bulk-request (v2 y 3)
10100101
A5
Inform (v2 y 3)
10100110
A6
trap
10100111
A7
report (v3)
10101000
A8
PDU SNMP
Formato Mensajes (Get, Get-next, Set, Response)
Nro Entero que identifica
versión del protocolo
Version
Community
String en texto plano (usada
como password)
Entero que indica tipo
(función) de la PDU
Idenftificador único para vincular
consultas-respuestas
SNMP PDU
PDU Type
Request ID
Error Status
Error Index
Utilizado en respuestas para indicar estado
Object1, value 1
Apuntador al objeto que generó el error
Object2, value 2
Secuencia de pares nombre-valor
Objectn, value n
PDU SNMP
Formato Mensajes SNMPv3
Version
ID
Max Size
Flags
Security Model
Authoritative
EngineID
Authoritative
EngineBoots
Authoritative
EngineTime
User Name
Security
Parameters
Context
Engine ID
Context
name
PDU
Cifrado si se aplica
Formato igual a SNMPv2
Códigos del Protocolo
Tipos de errores (snmp v1)
Estado
Nombre
Significado
0
noError
Sin error
1
tooBig
Respuesta demasiado larga para un mensaje
2
noSuchName
Variable inexistente
3
badValue
El valor a almacenar es inválido
4
readOnly
El valor no puede ser modificado
5
genErr
Otros errores
Snmp v2 define tipos de errores con mayor especificidad (6-18)
TRAPs
Tipos genéricos de TRAPs:
●
0-Cold start: El agente ha sido inicializado/reinicializado
●
1-Warm start: La configuración del agente ha cambiado
●
2-Link down: Una interfaz se encuentra fuera de servicio
●
3-Link up: Una interfaz se encuentra en servicio
4-Authentication failure: El agente ha recibido un requerimiento de un NMS no
autorizado
●
5-EGP neighbor loss: Cuando los routers usan EGP, un equipo adyacente se
encuentra fuera de servicio
●
6-Enterprise: En esta categoría se encuentran todos los nuevos traps incluidos
por los vendedores
●
TRAPs
Ejemplos
●
Se “cae” una interfaz
●
Se estropea el ventilador de un router
●
La carga de procesos excede un límite
●
Se llena una partición de disco
●
Un UPS cambia de estado
●
Intento de acceso no autorizado
●
...
RMON
Remote Monitoring
Define una MIB de monitorización remota ampliando
su funcionalidad.
• Objetivos:
- Operación off-line
- Detección y notificación de problemas
- Datos de valor añadido
- Gestores múltiples
• Control de monitores remotos
– El monitor remoto es configurado para captura de datos
(especificando tipo de datos y forma de recolección):
• Tabla de control: describe la configuración del monitor RMON
especificando la información que captura
• Tabla de datos: almacena la información recogida.
RMON
Invocación de una acción
– Mediante SNMP se puede enviar un comando (usando un objeto para
representar un comando). Cambio → Acción!
• La MIB RMON se divide en nueve grupos:
• Estadísticas: cantidad de bytes, paquetes, errores...
• Historia:Muestras periódicas del grupo estadisticas.
• Alarma: Intervalo de muestreo y umbral de alarma para cualquier dato
grabado por el agente RMON.
• Host: Datos sobre cada nodos de la red.
• HostTopN: Lista ordenada pro parámetros de la tabla "host".
• Matriz: Información sobre tráfico y errores entre dos nodos.
• Filtro: Observar paquetes que “matchean” con un filtro.
• Captura de paquetes: Almacena paquetes que matchean con un filtro.
• Evento: Controla los eventos generados por alarmas.
Bibliografía
Bibliografía:
Essential SNMP (2da Ed.), Douglas R. Mauro and Kevin J. Schmidt. O’Reilly Media, 2005
The Illustrated Network: How TCP/IP Works in a Modern Network. Walter Goralski.
Morgan Kaufmann, 2008
Próxima: Laboratorio