4comunicaciones

5/11/2018 4Comunicaciones - slidepdf.com

http://slidepdf.com/reader/full/4comunicaciones 1/42

Bernardo Alarcos Alcázar

[email protected]

http://it.aut.uah.es/alarcos

it

Gestión en Internet:

modelo de Comunicaciones



it Gestión en Internet: modelo de

comunicaciones 2

1. Introducción.2. Formato del mensaje.3. Procesado de mensajes.4. Codificación del mensaje.




comunicaciones 3

Proceso Gestor

SNMP

UDP

............

IPEthernet, PPP.....

Proceso Agente

SNMP

UDP

............

IPEthernet, PPP.....

RedTCP/IP

161get getNext

set

Interfazusuario

162traps

Arquitectura

UDP: servicio no fiable.

Sobre UDP se establece un diálogo entre gestor y el agentesiguiendo el modelo pregunta/respuesta (excepto en el trap).

Si se pierde un mensaje SNMP lo repite hasta un númerodeterminado de veces. Si no se recupera avisa con una excepción.

diálogo




comunicaciones 4

Operaciones

GetRequest: el gestor realiza una petición de valores específicos de la MIB delagente.

GetNextRequest: el gestor realiza una petición del objeto siguiente a uno dadoen la MIB del agente, siguiendo un orden lexicográfico . GetResponse: el agente devuelve los valores solicitados por la operaciones

anteriores del gestor. Es la respuesta a un SetRequest, GetRequest oGetNextRequest.

SetRequest: el gestor permite asignar un valor a una variable en el sistema delagente.

Traps: el agente informa de un suceso inusual predefinido.

GestorAgente

GetRequest, GetNextRequest, SetRequest

GetResponse

Trap




comunicaciones 5





comunicaciones 6

Formato del mensaje SNMP

Version Comunity SNMP pdu

type request-id

error-statuserror-index variablebindings

name 1 value 1 name 2 value 2

............ name n value n

type enterprise agent-addr generic-trap specific-trap time-stamp variablebindings

Mensaje SNMP

PDUs: GetRequest, GetNextRequest, SetRequest:

error-status e error-index valen 0.

GetResponse

PDU trap


http://slidepdf.com/reader/full/4comunicaciones 7/42it Gestión en Internet: modelo de

comunicaciones 7

Significado de los campos del mensaje

Versión: versión del protocolo SNMP. Comunity: comunidad que permite la autenticación del gestor

ante el agente y el control de acceso. Request-id: identificador único para cada petición, es el mismo

en la respuesta correspondiente. Error-status: indica si ha ocurrido un error cuando procesa una

petición. Los código son: noError (0), tooBig (1), noSuchName (2),

badValue (3), readOnly (4), genErr (5). Vale 0 en caso degetRequest, getNextRequest y setRequest. Error-index: cuando se ha producido un error, puede aportar

información, indicando que instancia de la lista devariablebindings ha producido el error. Vale 0 en caso degetRequest, getNextRequest y setRequest.

Variablebindings: lista de nombres de variables (OIDs) y suscorrespondientes valores. Los valores son nulos (NULL) en casoscomo GetRequest, GetNextRequest o GetResponse con error.Permite múltiples operaciones en el mismo mensaje.



comunicaciones 8

Significado de los campos del mensaje

Enterprise: tipo de sistema que genera el trap, basado en

sysObjectID. Agent-addr: dirección IP del agente que genera el trap.

Generic-trap: código de trap genérico.

Specific-trap: código de trap específico.

Time-stamp: tiempo desde la última (re)inicialización del agente y la generación del trap (valor de sysUpTime).



comunicaciones 9




comunicaciones 10

Proceso de Transmisión de un mensaje.

Proceso realizado por una entidad SNMP para enviar uno de los

cinco tipos de mensajes: Generación de PDU: construye la PDU SNMP utilizando la

estructuras ASN.1 definida en RFC 1157.

Autenticación: (en la práctica no se suele invocar este proceso)

Se pasa a un proceso de autenticación: PDU, puerto fuente,

puerto destino, comunidad. El servicio de autenticación realiza tareas como cifrado o

generación de autenticación.

Generación del mensaje: la entidad del protocolo construye elmensaje: versión, comunidad y salida del proceso anterior (PDU).

Codificación: se codifica todo utilizando BER y se pasa al servicio detransporte.




comunicaciones 11

Proceso de recepción de un mensaje.

Proceso realizado por una entidad SNMP una vez recibido un

mensaje: Chequeo de sintaxis del mensaje: descartándolo si este falla. Verificación de versión: descarta si no es correcta. Autenticación:

La entidad de protocolo pasa al servicio de autenticación: PDU,nombre de comunidad y puertos de origen y destino.

Si falla la autenticación se le comunica la entidad de protocolo;ésta genera un trap y descarta el mensaje.

Si es autentico la entidad de autenticación devuelve a laentidad de protocolo la PDU con el formato ASN.1 de RFC 1157.

En la práctica el servicio de autenticación comprueba que el

nombre de la comunidad autoriza la recepción del mensaje desdela entidad SNMP fuente. La entidad del protocolo:

Chequea la sintaxis de la PDU descartando la PDU si falla. Selecciona la política de acceso adecuada según la comunidad.




comunicaciones 12

Petición de información

GetRequest (gestor-agente) - GetResponse (agente-gestor).

Request-id permite correlar petición con respuesta y detectarduplicados (udp no fiable).

Variablebindings permite multiplexar varias peticiones en unmismo mensaje.

La respuesta debe ser atómica, es decir, si una petición falla: No se devuelve el resultado de ninguna.

Error-index apunta al name (varible-bindings) que ha producido elfallo. Ejem: si falla el segundo name, error-index = 2.

Errores en la respuesta (error-status):

noSuchName: OID no referencia a una instancia o no se encuentraen la vista.

tooBig: el tamaño del mensaje de respuesta no cabe en el tamañomáximo de datos UDP impuesto por el sistema.

genErr: cualquier otro motivo.




comunicaciones 13

Navegación por las MIBs

GetNextRequest (gestor-agente) - GetResponse (agente-gestor)

Se procesa igual que GetRequest. Operación atómica. Devuelve el valor de la siguiente instancia en orden lexicográfico:

OID, no instancia: ejemplo (1.3.6.1.2.1.4.3) Si existe en la vista devuelve la instancia OID.0 Si no existe, valor de la siguiente instancia NextOID.0

Instancia OID: ejemplo (1.3.6.1.2.1.4.3.0) Valor de la siguiente instancia: NextOID.0

OID de tabla o Entry de tabla: ejemplo (ifTable o ifTable.1) Valor de la primera instancia de la tabla.

OID columnar: ejemplo (ifTable.1.1) Valor de la primera instancia de la columna de la tabla.

Instancia OID columnar: ejemplo (ifTable.1.1.1) Valor de la siguiente instancia en la vista (puede ser de la misma columna,

otra columna o fuera de la tabla).

Si no existe la siguiente instancia devuelve NoSuchName.




comunicaciones 14

Modificación de información

SetRequest (gestor-agente) - getResponse (agente-gestor) VariableBindings:

En Set contiene name y value de todas las instancias cuyo valor sequiere modificar.

En response: Contiene name y value tras la modificación.

Si se produce error en alguna de las peticiones del mensaje, no

se modifica ninguna y no se devuelve ningún valor. Códigos de error: noSuchName, TooBig, genErr: mismos casos que GetRequest. badValue: si tiene algún (name,value) inconsistente (tipo o longitud

del valor no válidos, fuera de rango...). En el caso de noSuchName el error puede indicar que el objeto no

puede (control de acceso) ser modificado (aunque exista). Si el objeto es de sólo lectura devuelve noSuchName. No se utiliza

readOnly. En SNMPv2 se utiliza un nuevo código denominadonotWritable.




comunicaciones 15

Modificación de tablas

La norma no especifica si crear nuevas filas en una tablamediante el comando set, entra dentro de la política del agente.

Crear fila: ante esta llamada

setRequest (ipRouteDest.130.1.3.3= 130.1.3.3,

ipRouteMetric. 130.1.3.3= 1,

ipRouteNextHop.130.1.3.3= 130.1.3.5)

el agente podría crear una nueva entrada en la tabla o devolverun mensaje de error.

Borrar fila: para borrar (o invalidar) una fila de una tabla seutiliza el comando (en las tablas en las que esté permitido):

setRequest(ipRouteDest.130.1.3.3= invalid)

Modificar: algunas tablas tienen instancias columnares quepueden ser modificadas con SetRequest (definido en las MIBs).




comunicaciones 16

Notificación de eventos

Trap (agente-gestor).

No requiere confirmación: problema si se pierde el mensaje. Motivos de trap:

coldStart (0): reinicio inesperado debido a algún tipo de fallo.

warmStart (1): reinicio en caliente, normalmente programado.

linkDown (2): fallo en uno de los enlaces del sistema. El primerelemento en variablebindings , contiene el valor ifindex del interface.

linkUp (3): uno de los enlaces se ha iniciado. El primer elemento envariablebindings , contiene el valor ifindex del interface.

authenticationFailure (4): se ha recibido un mensaje SNMP conerror de autenticación.

egpNeighborLoss (5): se ha perdido la relación con un vecino EGP. enterpriseSpecific (6): se ha producido algún evento específico de

empresa especificado en specific-trap.




comunicaciones 17





comunicaciones 18

Codificación del mensaje

El formato está declarado en ASN.1 (RFC1157).

El mensaje se codifica con BER antes de enviarlo.




comunicaciones 19

Reglas de codificación BER

BER (Basic Encode Rules) define cómo codificar los valores definidos en

ASN.1 para ser transmitidos. La codificación de cada campo consta de tres o cuatro campos:

Tipo: etiqueta que identifica el valor. Longitud: del valor en octetos. Valor: (OPCIONAL) codificado según el tipo. Marca de fin de valor (OPCIONAL): si la longitud es indefinida.

Se utiliza la siguiente notación: valores expresados en hexadecimal,cada octeto se separa por un espacio en blanco.TT LL comentario

VV VV VV VV comentario

Se pueden dar codificaciones de tipos construidos (estructuras oetiquetas explicitas).

TT LL tipo construido, después se codifica otro tipoTT LL tipo primitivo, después viene el valor

VV VV VV VV

TT LL tipo primitivo, después viene el valor

VV VV




comunicaciones 20

0 n n n n n n n

1 n n n n n n n

1 n n n n n n n

Codificación de tipo

clase C/P etiqueta

00 UNIVERSAL

01 APPLICATION10 Específica de contexto11 PRIVATE

0 Primitivo1 Construido

1 00001BOOLEAN

2 00010INTEGER

3 00011BIT STRING

4 00100OCTET STRING

5 00101NULL

6 00110OBJECT IDENTIFIER

7 00111ObjectDescriptor

8 01000EXTERNAL

9 01001REAL

10 01010ENUMERATED

16 10000SEQUENCE [OF]

17 10001SET [OF]

18 10010NumericString

19 10011PrintableString

20 10100TeletextString

21 10101VideoString

22 10110IA5String

23 10111UTCTime

24 11000GeneralizedTime

25 11001GraphicString

26 11010VisibleString

27 11011GeneralString

Etiquetas Universales

clase C/P

1 1 1 1 1

etiquetaFormato Largo: etiquetas > 30

Formato Corto

Etiqueta = nnnn..............nnnn




comunicaciones 21

Datos

Codificación de longitud

Formato Corto.

Datos de LLL..L octetos.

Formato Largo.

L L L L L L L L. . . . . . . .L L L L L L L L

Los siguientes nn..n octetosindican la longitud.

Formato Indefinido.

0 0 0 0 0 0 0 00 0 0 0 0 0 0 0

Datos1 0 0 0 0 0 0 0

Marca de fin de datos.(no debe estar contenida en los datos)

1 n n n n n n n

Datos0 L L L L L L L

Datos de LLL..L octetos.

n..nn octetos que contienenla longitud de los datos




comunicaciones 22

0 0 0 0 0 0 0 00 0 0 0 0 0 0 1

Codificación de BOOLEAN

Se codifica en un octeto:

FALSE: 0 TRUE: cualquier otro valor

Ejemplo: codificación del valor FALSE

0 0 0 0 0 0 0 1Tipo

Longitud

Valor

01 01 [UNIVERSAL 1], LONGITUD 100 valor FALSE




comunicaciones 23

Codificación de INTEGER

1 1 1 0 0 0 0 10 0 0 0 0 0 0 1

Se codifica en complemento a dos utilizando tantos octetos

como sea necesario. Ejemplo: codificación del valor –31 (11100001).

0 0 0 0 0 0 1 0Tipo

Longitud

Valor

02 01 [UNIVERSAL 2], LONGITUD 1

E1 valor -31

ENUMERATED se codifica como un entero, aunque utiliza supropia etiqueta [UNIVERSAL 10].




comunicaciones 24

v v v v v v v v. . . . . . . .v v v v v v v v

Codificación de REAL

0 0 0 0 0 0 0 0

Si el valor es 0 no se codifica, el campo de longitud vale 0.

0 0 0 0 1 0 0 1Tipo

Longitud

0 0 - - - - - -L L L L L L L L0 0 0 0 1 0 0 1Tipo

Longitud

Valor

Para el resto de casos el primer byte de valor indica el esquemade codificación: Comienza con 00: codificación en base 10 según ISO 6093.

Longitud 0

Codificación Base 10

Comienza con 01: codificación de valores especiales.

0 1 v v v v v vL L L L L L L L0 0 0 0 1 0 0 1Tipo

Longitud

Valor

000000 PLUS-INFINITY000001 MINUS-INFINITYVVVVVV .................................




comunicaciones 25

N N N N N N N N. . . . . . . .

N N N N N N N NE E E E E E E E. . . . . . . .E E E E E E E E1 S B B F F Q QL L L L L L L L0 0 0 0 1 0 0 1Tipo

Longitud

Valor

Comienza con 1: codificación en base 2, 8, ó 16.

Longitud 0

Codificación de REAL (cont)

S: signo de la mantisa, 0 positivo y 1 negativo.B: base, 00 = 2, 01=8 y 10 = 16.F: factor para calcular la mantisa, 00 = 0, 01 = 1, 10 = 2 y 11 =

3.Q: tamaño del campo E en octetos, 00 = 1, 01 = 2, 10 = 3 y 11 =en el siguiente octeto.E: exponente codificado como entero en complemento a 2.N: número para calcular la mantisa.

El valor se forma con la expresión:S*N*2F* BE

Donde N*2F es la mantisa.




comunicaciones 26

1 1 0 0 0 0 0 0

Codificación de BIT STRING

0 0 0 0 0 1 0 10 0 0 0 0 0 1 0

La longitud debe ser multiplo de 8 bits, por lo tanto incluye un

campo que indica los bits que son de relleno. Ejemplo: codificación del valor 110.

0 0 0 0 0 0 1 1Tipo

Longitud

Valor


05 C0 valor 110

Relleno: últimos 5 bits

Relleno puede tomar cualquier valor




comunicaciones 27

0 0 1 1 1 1 1 1

Codificación de OCTET STRING y derivados

0 0 1 0 0 1 0 10 0 0 0 0 0 1 0

Se codifican los octetos tal como son definidos.

Ejemplo: codificación del valor 25 3F.

0 0 0 0 0 1 0 0Tipo

Longitud

Valor


25 3F valor 25 3F

Los tipos predefinidos derivados deOCTET STRING (IA5String, NumericString,PrintableString...) se codifican de la mismaforma, lo único que cambia es el valor de laetiqueta.




comunicaciones 28

Codificación de NULL

0 0 0 0 0 0 0 0

No tiene valor, por lo tanto se codifica con longitud 0.

0 0 0 0 0 1 0 1Tipo

Longitud





comunicaciones 29

Codificación de OBJECT IDENTIFIER

Secuencia de enteros: N1...Nk que se codifican:N1 y N2 se codifican como el entero: 40*N1+N2

El resto N3......Nk se codifica cada entero por separado. La codificación de cada entero se realiza:

Se codifica en octetos por orden de mayor a menor peso. El bit de mayor peso de cada octeto indica:

0 = último octeto del entero.

1 = vienen más enteros. Ejemplo: 1.3.6.1.4.1.1243.1.0

40*1+3=43: 00101011

6: 00000110

1: 00000001

4: 00000100

1: 00000001

1243: 10001001 01011011

1 : 00000001

0 : 00000000

0 0 0 0 0 0 0 00 0 0 0 0 0 0 10 1 0 1 1 0 1 1

1 0 0 0 1 0 0 10 0 0 0 0 0 0 10 0 0 0 0 1 0 00 0 0 0 0 0 0 10 0 0 0 0 1 1 00 0 1 0 1 0 1 10 0 0 0 1 0 0 1

0 0 0 0 0 1 1 0

06 09

2B 06 01 04 01 89 5B 01 00




comunicaciones 30

Codificación de ESTRUCTURAS

SEQUENCE, SEQUENCE OF: se codifica cada uno de los campos

dentro del tipo construido de etiqueta 16. SET, SET OF: igual con etiqueta 17 (sin orden determinado). CHOICE: no tiene asignada etiqueta ya que se codifica sólo el tipo

seleccionado. Ejemplo:

Sintaxis:DatosPersonales ::= SEQUENCE {

nombre IA5String,

dni NumericString

}

Valores:DatosPersonales ::= {

nombre "Narciso Yepes",

dni "19135467"

}

30 19 [UNIVERSAL 16], construido, longitud 25

16 0D [UNIVERSAL 22], primitivo, longitud 13

4E 61 72 63 69 73 6F 20 59 65 70 65 73

12 08 [UNIVERSAL 18], primitivo, longitud 8

31 39 31 33 35 34 36 37




comunicaciones 31

1. Introducción

2. Sintaxis

3. Ejemplos




comunicaciones 32

Ejemplo 1

Sintaxis:

DatosPersonales ::= SEQUENCE {nombre IA5String,

domicilio IA5String,

edad INTEGER

}

Valores:

DatosPersonales ::= {nombre “Antonio Sanz",

dni “C/ Santa Cruz“

Edad 25

}

30 20 [UNIVERSAL 16], construido, longitud 32

16 0C [UNIVERSAL 22], primitivo, longitud 12

“Antonio Sanz”

16 0D [UNIVERSAL 22], primitivo, longitud 13“C/ Santa Cruz”


19




comunicaciones 33

Ejemplo 2

Le ponemos etiquetas explicitas al ejercicio anterior

DatosPersonales ::= [APPLICATION 1] SEQUENCE {

nombre [0] IA5String,

domicilio [1] IA5String,

edad [2] INTEGER

}

61 28 [APPLICATION 1], construido, longitud 4030 26 [UNIVERSAL 16], construido, longitud 38

A0 0E [0], construido, longitud 14

16 0C [UNIVERSAL 22], primitivo, longitud 12

“Antonio Sanz”

A1 0F [1], construido, longitud 15

16 0D [UNIVERSAL 22], primitivo, longitud 13“C/ Santa Cruz”

A2 03 [2], construido, longitud 3


19




comunicaciones 34

Ejemplo 3

Añadimos IMPLICIT en el ejercicio anterior.

DatosPersonales ::= [APPLICATION 1] IMPLICIT SEQUENCE {

nombre [0] IMPLICIT IA5String,

domicilio [1] IMPLICIT IA5String,

edad [2] IMPLICIT INTEGER

}

61 20 [APPLICATION 1], construido, longitud 3280 0C [0], primitivo, longitud 12

“Antonio Sanz”

81 0D [1], primitivo, longitud 13

“C/ Santa Cruz”

82 01 [2], primitivo, longitud 1

19




comunicaciones 35

Declaración del formato del mensaje SNMP

El formato está declarado en ASN.1 (RFC1157).

El mensaje se codifica con BER antes de enviarlo.

RFC1157-SNMP DEFINITIONS ::= BEGIN

IMPORTS

ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks

FROM RFC1155-SMI;

Message ::= SEQUENCE {version INTEGER {version-1(0)}, -- Version-1 for this RFCcommunity OCTET STRING, -- Community namedata ANY -- E.g., PDUs if trivial authentication is being used}




comunicaciones 36


PDUs ::= CHOICE {get-request GetRequest-PDU,

get-next-request GetNextRequest-PDU,get-response GetResponse-PDU,set-request SetRequest-PDU,trap Trap-PDU}

GetRequest-PDU ::= [0] IMPLICIT PDU

GetNextRequest-PDU ::= [1] IMPLICIT PDUGetResponse-PDU ::= [2] IMPLICIT PDUSetRequest-PDU ::= [3] IMPLICIT PDU

PDU ::= SEQUENCE {request-id INTEGER,error-status INTEGER {noError(0), tooBig(1), noSuchName(2),

badValue(3), readOnly(4), genErr(5)},error-index INTEGER, -- Sometimes ignoredvariable-bindings VarBindList -- Values are sometimes ignored}




comunicaciones 37


Trap-PDU ::= [4] IMPLICIT SEQUENCE {

enterprise OBJECT IDENTIFIER, -- Type of object generating-- trap, see sysObjectID in [5]agent-addr NetworkAddress, -- Address of object generating trapgeneric-trap INTEGER { -- Generic trap type

coldStart(0), warmStart(1), linkDown(2), linkUp(3),authenticationFailure(4), egpNeighborLoss(5),enterpriseSpecific(6)

},

specific-trap INTEGER, -- Specific code, present even if generic-trap-- is not enterpriseSpecific

time-stamp TimeTicks, -- Time elapsed between the last(re)initialization-- of the network entity and the generation of-- the trap

variable-bindings VarBindList -- "interesting" information

}




comunicaciones 38


VarBind ::= SEQUENCE {name ObjectName,

value ObjectSyntax}

VarBindList ::= SEQUENCE OF VarBindEND




comunicaciones 39

Ejercicio

Decodifique la siguiente secuencia correspondiente a un mensaje SNMP:

30 82 00 32 02 01 00 04 06 70 75 62 6C 69 63 A2 82 00 23 02 04 5957 65 EF 02 01 00 02 01 00 30 82 00 13 30 82 00 0F 06 08 2B 06 01 0201 04 09 00 41 03 01 92 7C




comunicaciones 40

Solución

30 82 00 32 -- UNIVERSAL SEQUENCE, constru, long 5002 01 --UNIVERSAL INTEGER, primitivo, long 1

00 --valor 0 (versión SNMP 1)04 06 -- UNIVERSAL OCTECT STRING, primitivo, long 670 75 62 6C 69 63 –- valor “public”

A2 82 00 23 –- [2] long 35,constru, get-response02 04 – UNIVERSAL INTEGER , long 4,

59 57 65 EF -- request-id 149889995102 01 –- UNIVERSAL INTEGER , long 1

00 -- error-status = noError02 01 –-UNIVERSAL INTEGER , long 1

00 –- error-index = 030 82 00 13 –- UNIVERSAL SEQUENCE, constru, long 19

30 82 00 0F -- UNIVERSAL SEQUENCE, constru, long 1506 08 -- UNIVERSAL OBJECTS IDENTIFIER, long 8

2B 06 01 02 01 04 09 00 --1.3.6.1.2.1.4.9.04103 –- [APPLICATION 1], primitivo, long 3

01 92 7C –- Counter 103036 ver RFC 1155-SMI

Respuesta a una petición del valor de ipInDelivers




comunicaciones 41

Ejercicio

Codifique la petición de un mensaje SNMPv1 snmpget con los

siguientes parámetros: Comunidad: publica.

Request-id: 33 46 2A 3B en hexadecimal.

OIDs: icmpInMsgs, icmpInErrors, icmpInDestUnreachs.



it

Solución

30 46 –-long 70

02 01 --versión00

04 07 -- Comunidad

70 75 62 6C 69 63 61

A0 38 –- GetRequest02 04 –-request-id

33 46 2A 3B

02 01 –-error-status

00

02 01 -- error-index00

30 2A -- SEQUENCE OF VarBinds

30 0C -- VarBinds06 08 -- OID2B 06 01 02 01 05 01 00

05 00 --NULL30 0C -- VarBinds

06 08 -- OID2B 06 01 02 01 05 02 00

05 00 --NULL30 0C -- VarBinds

06 08 -- OID2B 06 01 02 01 05 03 00

05 00 --NULL

4comunicaciones

Documents