GAR Temas4y5

TEMA 4
CONTROL Y GESTION DE
REDES CON SNMP
GAR 4-1
Contenidos
1. Introducción
2. Protocolo SNMP (v1)
3. SMI
4. La MIB-II
5. Ejemplos de MIBS estandarizadas
6. Protocolos SNMP (v3)
7. Ejemplos de herramientas
GAR 4-2
3.1 Introducción
 Inicialmente no se pensó incluir soporte para la gestión de redes

en TCP/IP
◦ Los expertos en protocolos solucionaban los problemas
◦ La única “herramienta” disponible era ICMP (mensajes de ECHO).
◦ Se diseñaron las utilidades PING y traceroute basadas en ICMP
 Con el incremento de la implantación de las redes:

◦ Las herramientas ping y traceroute eran insuficientes.
◦ Se diseñó un nuevo protocolo muy sencillo denominado SNMP
(Simple Network Management Protocolo), cuyo fin era facilitar la
gestión de las redes basadas en TCP/IP.
◦ Posteriormente, se amplió la funcionalidad de SNMP definiendo
nuevas versiones (SNMP-v2 y SNMP-3)
GAR 4-3
3.2 SNMP
Elementos de SNMP
- Agentes
- Base de datos
- Estación de gestión
- Protocolo
GAR 4-4
SNMP
Elementos: Agentes
 Agente:
◦ Módulo software integrado en el sistema operativo de un
sistema (host, router, switch, etc) que proporciona acceso a
sus datos de gestión.
◦ Cada dispositivo gestionable, debe disponer de un agente
 Un agente SNMP soporta dos tipos de transacciones:
Agente
Gestor
 POLL: Recibe peticiones y POLL
responde a ellas
Agente
 TRAP: Envía notificaciones no
solicitadas Gestor TRAP
GAR 4-5
SNMP
Elementos: Base de datos de gestión (MIB)
 La MIB (Management Information Base) es un conjunto

estructurado de objetos que representan los recursos del
dispositivo gestionado.
◦ Los objetos están estandarizados para cada clase concreta
◦ La MIB se almacenan en los dispositivos gestionados y se
accede a ellos a través de los agentes
MIB
POLL / TRAP
AGENTE
GAR 4-6
SNMP
Elementos: Estación de gestión
 Estación de gestión:
◦ Interfaz entre el gestor humano y el SGR
◦ Incluye:
 Interfaz (gráfico) para monitorizar y controlar la red.
 Aplicaciones de gestión para análisis de datos, recuperación
de fallos, etc.
 Capacidad de traducir los requerimientos del gestor en
órdenes concretas de monitorización y control de los
elementos remotos de la red
 Base de datos de información extraída de las MIBs de todas
las entidades gestionadas en la red
GAR 4-7
SNMP
Elementos: Protocolo de gestión SNMP
 Es un protocolo de capa de aplicación que realiza la comunicación entre

la estación de gestión y los agentes.
 Incluye las siguientes capacidades:
 GET: permite a la estación de gestión solicitar a un agente el valor
de un objeto. Se implementa con tres servicios
 GetRequest: El gestor pide al agente el valor de un dato.
 GetNextRequest: Es similar a GetRequest, pero permite extraer datos
de una tabla.
POLL
 GetResponse: Es la respuesta. Incluye los datos pedidos o un código de

TRANSACCIONES
error, para las operaciones Get

 SET: permite a la estación de gestión modificar (escribir) el valor
de un objeto de un agente. Se implementa con dos servicios
 SetRequest: El gestor pide al agente que modifique los valores de las
variables que especifica. Se confirma con GetResponse
 TRAP: permite al agente notificar a la estación de gestión la
TRAP
ocurrencia de eventos. Se implementa con un servicio.

GAR 4-8  Trap: El agente informa al gestor
SNMP
Procesos
SNMP usa UDP y se implementa con dos procesos:

 Proceso gestor:
◦ Actúa como cliente SNMP, cuando envía peticiones SNMP
◦ Escucha los traps en el puerto 162
 Proceso agente:
◦ Debe interpretar los mensajes SNMP y controlar la MIB del agente
◦ Actúa como “servidor” SNMP, escuchando las peticiones del gestor
en el puerto 161
◦ Envía los traps al gestor
POLL (UDP,161)
PROCESO PROCESO
GESTOR AGENTE
TRAP (UDP,162)
GAR 4-9
SNMP
Sondeo a dispositivos
 Una estación de gestión puede realizar sondeos a los agentes para

verificar su estado y comprobar si alguno necesita atención.
 Hay tres posibilidades:
◦ Sondeo circular: Puede ser poco eficiente si la estación de gestión
controla un gran número de agentes.
◦ Sondeo dirigido por trap: Sólo se sondea a un agente cuando éste
emite un trap. El principal inconveniente es que los traps no se
confirman y el transporte es ‘no fiable’ (UDP).
◦ Sondeo dual: Se hace un sondeo circular con un tiempo de ciclo
elevado y a la vez, se atiende un sondeo dirigido por traps.
GAR 4-10
SNMP
Utilización de un agente proxy
 SNMP puede usar un agente proxy, para interactuar con

dispositivos que no implementen SNMP
Agente proxy
Estación de Función de adaptación Dispositivo
gestión no SNMP
Proceso
Agente Arquitectura
Proceso Gestor del protocolo
SNMP usado por el Arquitectura del
SNMP protocolo usado
dispositivo
UDP UDP no SNMP por el dispositivo
IP IP
Acceso a Acceso a la
Acceso a la red la red red Acceso a la red
GAR 4-11
SNMP
Agentes y subagentes
 Un agente SNMP puede comunicarse con subagentes. El agente

actúa como maestro y los sub-agentes, disponen de la MIB asociada
a los dispositivos.
 La estación de gestión se comunica con el agente maestro, y éste,

con los subagentes. En todos los casos se usa SNMP
GAR 4-12
SNMP
Perfil de comunidad y política de acceso
 SNMP-v1 implementa un mecanismo de seguridad basado en:
◦ Comunidad
◦ Vista
◦ Modo de acceso
 Comunidad: Es una relación entre un agente SNMP y un

conjunto de estaciones de gestión, que define características de
autentificación y control de acceso.
◦ Las estaciones de gestión pertenecientes a una comunidad deben
emplear ese nombre en todas las operaciones get y set
◦ Un agente puede responder a varias comunidades
◦ Una estación de gestión puede pertenecer a varias comunidades
◦ Una estación debe almacenar los nombres de comunidad asociados a
cada agente
GAR 4-13
SNMP
 Se puede limitar el acceso a la MIB de un agente en dos formas:

◦ Vista de la MIB: subconjunto de los objetos de la MIB que serán accesibles
◦ Modo de acceso: READ-ONLY (RO) o READ-WRITE (RW)
 Perfil de comunidad = Vista MIB + Modo de acceso
 Política de acceso: Perfil de comunidad + Comunidad
 Un agente sólo atiende una petición si la política de acceso es adecuada

(comunidad + vista MIB + modo de acceso)
 El uso de políticas de acceso es un esquema de seguridad muy limitado

(muy poco seguro)
GAR 4-14
SNMP
Agente SNMP
Comunidad SNMP
Conjunto de estaciones
de gestión SNMP
Política de
acceso
Vista de MIB SNMP
Perfil de
Modo de acceso comunidad SNMP
 Ejemplos de políticas de acceso: Cualquier gestor puede leer

objetos de toda la MIB
◦ {Vista: toda la MIB, Acceso: RO, Comunidad: public} especificando el nombre de
comunidad public
Cualquier gestor puede escribir

◦ {Vista: .system, Acceso: RW, Comunidad: private}
objetos en la rama .system
especificando el nombre de
comunidad private
GAR 4-15
SNMP
Formato de las PDUs
 Todos los paquetes (PDU) de SNMP comienzan por dos

campos: Número de versión y Nombre de comunidad
◦ El resto del paquete depende del tipo del mismo
VER COM PDU de SNMP
PDUs de Ge tReq u est, GetNextR eq u est y Se tRe ques t
Tipo PDU R equest ID 0 0 Asignac iones de variables
PDU d e GetR esp o ns e

T ipo PD U R eques t ID C ód. error Índic e error Asignaciones de v ariables
PDU d e Trap
T ipo PD U Empresa Dir. agente T rap Trap Tim e stamp Asig. de
genéric a es pecífic a vbles.
Asig na ción d e variab les

N ombre 1 Valor 1 Nombre 2 V alor 2 ... Nombre N Valor N
GAR 4-16
SNMP
Formato de los paquetes del protocolo
 Request ID: Es un identificador secuencial único por cada petición/respuesta
 Código de error: indica que ha ocurrido una excepción al procesar una petición
◦ Posibles valores: noError (0), tooBig(1), noSuchName(2), badValue(3),
readOnly(4), genErr(5)
 Índice de error: indica qué variable de la lista causó la excepción, cuando el
código de error no es 0
 Asignación de variables: lista de nombres de variables y sus correspondientes
valores
◦ Los nombres se especifican como identificadores de objetos (OIDs)
◦ En GetRequest, los valores son null
 Enterprise: Valor de objeto sysObjectID del agente que genera el trap

 Dirección de agente: Dirección IP del agente que genera el trap
 Trap genérica: Tipo de trap genérico
 Trap específico: Código de trap específico
 Time stamp: Tiempo transcurrido entre la última reinicialización de la entidad y
la generación del trap (valor de sysUpTime)
GAR 4-17
SNMP
Ventajas e inconvenientes de SNMP (v1)
 Es un protocolo maduro, estándar de facto aceptado por la industria.
 Está disponible en gran cantidad de productos.
 Es fácil de implementar y requiere pocos recursos del sistema.
 Falta de seguridad:
◦ Cualquier estación puede reiniciar variables con SetRequest, por lo que
muchos fabricantes no implementan este comando
◦ No hay control de acceso: al recibir un PDU un agente no comprueba si ha
sido enviado por una estación autorizada
◦ La identificación de comunidad viaja sin encriptar.
 Mala utilización del ancho de banda:
◦ No existe la posibilidad de transferir información por bloques
 Limitaciones en el mecanismo de traps:
◦ Sólo se puede informar de algunos eventos previstos
◦ No son reconocidas
 No es apropiado para gestionar redes muy grandes (por el sondeo)
GAR 4-18
3.3 SMI
Introducción
 La MIB (Management Information Base) es una base de datos que

contiene los objetos a gestionar por un agente
◦ Cada recurso se representa mediante un objeto que debe tener un
nombre único
◦ La MIB es un conjunto estructurado de objetos
◦ Cada agente dispone de una MIB
GAR 4-19
SMI
Introducción
 La SMI (Structure of Management Information) describe cómo se definen

los objetos gestionados que están contenidos en la MIB (RFC 1155)
 La estructura del SMI se define según el estándar ASN.1 (Abstract
Syntax Notation One) de ITU.
 BER(Basic Encoding Rules), especifica cómo se debe codificar cada
objeto de la MIB, de acuerdo con ASN.1
 Un mensaje SNMP debe estar compuesto por tipos de datos válidos de
ASN.1, codificados según las reglas BER
BER
(ASN.1)
MIB SMI
Objetos
GAR 4-20
SMI
Tipos de datos
 En la SMI se utilizan cuatro clases de tipos de datos:
◦ UNIVERSAL: tipos básicos, independientes de la aplicación (ASN.1)
◦ APPLICATION: relevantes a una aplicación particular (por ejemplo
SNMP)
◦ CONTEXT-SPECIFIC: relevantes a una aplicación particular, pero
aplicables en un contexto limitado
◦ PRIVATE: definidos por los usuarios; no están estandarizados
 Los tipos de datos tienen una etiqueta asociada

◦ Etiqueta = nombre de la clase + número no negativo
GAR 4-21
SMI
Tipos de datos universales
Algunos tipos de datos universales:
 INTEGER32 / INTEGER64
◦ Entero de 32 bits (64 bits) en complemento a 2
◦ Se puede limitar el rango de valores
 Ejemplo: cuenta::= INTEGER{0..10}
 Ejemplo: estado::=INTEGER{up(1), down(2),uknown(3)}
 OBJECT IDENTIFIER
◦ Identificador de objetos
 Secuencia de números que determina la posición de un objeto dentro de la
estructura en árbol
 Ejemplo: el identificador del objeto tcpConnTable es 1.3.6.1.2.1.6.13
 SEQUENCE OF
◦ Vector unidimensional de un solo tipo
 Ejemplo: SEQUENCE OF INTEGER32
GAR 4-22
SMI
Tipos de datos dependientes de la aplicación
Algunos tipos de datos dependientes de la aplicación:
 ipAddress
◦ Direcciones IP (32 bits)
◦ Definido como OCTETSTRING de 4 bytes
 counter32 /counter 64
◦ Entero no negativo de 32 bits / 64 bits
◦ Se puede incrementar, pero no decrementar
◦ Cuando el contador llega al máximo, vuelve a cero
 gauge32 / gauge 64
◦ Entero no negativo de 32 bits Se puede incrementar y decrementar
◦ Cuando el contador llega al máximo, se queda bloqueado en ese valor
 timeticks
◦ Entero no negativo de 32 bits (máx=232 - 1)
GAR 4-23 ◦ Cuenta el tiempo en centésimas de segundo (Valor máximo: 497 días)
SMI
Estructura
 En la MIB se utiliza un esquema jerárquico de nombres que forma un

árbol con una raíz conectada a un conjunto de nodos etiquetados
◦ Etiqueta = {breve descripción textual + entero} (ejemplo: iso(1))
◦ Los nodos se agrupan por ramas de objetos relacionados
 Identificador de objeto (OID):

◦ Es la secuencia de enteros de las etiquetas de cada nodo, desde la raíz
hasta el nodo en cuestión
◦ El identificador es único para cada objeto
◦ La parte textual sólo se emplea por las personas, nunca se transmite
 Cada nodo representa un recurso, actividad o información

relacionada
GAR 4-24
SMI
Estructura de la MIB
Ejemplo:
Ejemplo: Objeto ip
ip OBJET IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) management(2) mib-2(1) 4}
GAR 4-25 OID  1.3.6.1.1.2.1.4
SMI
 La raíz no se etiqueta y de ella cuelgan tres nodos: iso(1), ccitt(2)
y joint-iso-ccitt(3)
 De iso cuelgan nodos para distintas organizaciones (org (3)).

Entre ellas está el DoD (dod(6))
 En dod hay un nodo administrado por el IAB (internet (1)):

Así, el nodo internet tiene el identificador de objeto 1.3.6.1
Todos los objetos de interés para SNMP cuelgan del nodo
internet, y por tanto tienen el prefijo 1.3.6.1 en sus
identificadores de objeto
GAR 4-26
SMI
 Dentro del nodo internet, se

definen cuatro nodos:
root
◦ directory(1): directorio X.500
iso(1)
◦ mgmt(2): objetos definidos en ccitt(0)
org(3)
joint(2)
documentos aprobados por el IAB dod(6)

internet(1)
 Como la mib-2 (1) experimental(3) private(4)
mgmt(2)
◦ experimental(3): identificadores de mib-2(1) enterprises(1)
objetos experimentales. system(1) snmp(11)

interfaces(2) udp(7)
◦ private(4): identificadores de objetos at(3) ip(4) icmp(5) tcp(6)
definidos por empresas

(http://www.iana.org/assignments/enterprise-numbers)
 Ejemplo: MIBs específicas de una impresora HP: 1.3.6.1.4.1.11

 Ejemplo: MIBs específicas de Microsoft: 1.3.6.1.4.1.311
GAR 4-27
 Ejemplo: MIBs específicas de Apple: 1.3.6.1.4.1.63
SMI
Estructura de los grupos de objetos de MIB-2
(RFC 1155)
Definido por SMI
Definido en MIB-II
(RFC 1213)
GAR 4-28
SMI
Adición de nuevos objetos a la MIB
 Alternativas para añadir nuevos objetos en la MIB:

◦ Expansión o reemplazamiento del subárbol mib-2: Por
ejemplo, con una versión posterior (mib-3) o añadiendo sub-
árboles a mib-2, como la base de monitorización remota de la red
(RMON)
◦ Construcción de una MIB experimental, para una aplicación

particular
 Primero se incluyen los objetos en el subárbol experimental, y cuando
el IAB los aprueba, pasan al mgmt
◦ Extensiones privadas en el subárbol private: Dentro de

private existe el nodo enterprises, donde se asigna una rama a
cada fabricante que registra un identificador de objeto.
GAR 4-29
SMI
Definición de objetos
 Cada objeto dentro de la MIB tiene una definición formal que

especifica:
◦ El tipo de datos del objeto
◦ El rango de valores que puede tomar
◦ Modo de acceso
◦ Tipo de definición
◦ Descripción
◦ Su relación con otros objetos de la MIB (es decir, su posición
dentro del árbol).
 Se emplea la sintaxis ASN.1 y en la codificación, las reglas de

BER
GAR 4-30
SMI
Definición de objetos: ejemplo
 Ejemplo: objeto tmpMaxConn.
GAR 4-31
SMI
Definición de objetos: Ejemplo
 Ejemplo:
tcpMaxConn OBJECT-TYPE
SYNTAX INTEGER
Define si el objeto ha de ser necesariamente
ACCESS read-only
incluido en la implementación de la MIB
STATUS mandatory {mandatory, optional, obsolete, deprecated}
DESCRIPTION
"The limit on the total number of TCP connections
the entity can support. In entities where the
maximum number of connections is dynamic, this
object should contain the value -1.“
::= { tcp 4 }
GAR 4-32
SMI
Definición de tablas
 SMI sólo permite estructurar los datos como tablas

bidimensionales con valores escalares
 Ejemplo: Tabla con las conexiones TCP de un dispositivo

◦ Objeto tcpConnTable (1.3.6.1.2.1.6.13)
◦ Para cada conexión, se almacena en la tabla:
 State: estado de la conexión TCP
 Local Address: dirección IP local
 Local Port: puerto local
 Remote Address: dirección IP remota
 Remote Port: puerto remoto
GAR 4-33
SMI
 Definición del objeto tabla:

OJO: T mayúscula
tcpConnTable OBJECT-TYPE
SYNTAX SEQUENCE OF TcpConnEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A table containing TCP connection-specific
information."
::= { tcp 13 }
GAR 4-34
SMI
 Definición del objeto fila: INDEX { tcpConnLocalAddress,
Índices
tcpConnEntry OBJECT-TYPE tcpConnLocalPort,
SYNTAX TcpConnEntry tcpConnRemAddress,
OJO: t minúscula
ACCESS not-accessible tcpConnRemPort }

STATUS mandatory OJO: T mayúscula::= { tcpConnTable 1 }
DESCRIPTION
TcpConnEntry ::= SEQUENCE {
"Information about a particular current
TCP tcpConnState INTEGER,
tcpConnLocalAddress IpAddress,
connection. An object of this type is
transient, in that it ceases to exist when tcpConnLocalPort INTEGER (0..65535),
(or soon after) the connection makes the tcpConnRemAddress IpAddress,
transition to the CLOSED state” tcpConnRemPort INTEGER (0..65535)
}
GAR 4-35
SMI
 Definición de los tcpConnLocalAddress OBJECT-TYPE
campos (columnas): SYNTAX IpAddress
ACCESS read-only
tcpConnState OBJECT-TYPE STATUS mandatory
SYNTAX INTEGER { DESCRIPTION
closed(1), listen(2), synSent(3), "The local IP address for this TCP connection.
synReceived(4), established(5), ...."
finWait1(6), finWait2(7), closeWait(8), ::= { tcpConnEntry 2 }
lastAck(9), closing(10), timeWait(11), tcpConnLocalPort OBJECT-TYPE
deleteTCB(12) } SYNTAX INTEGER (0..65535)
ACCESS read-write ACCESS read-only
STATUS mandatory STATUS mandatory
DESCRIPTION DESCRIPTION
"The state of this TCP connection.....” "The local port number for this TCP connection."
::= { tcpConnEntry 1 } ::= { tcpConnEntry 3 }
GAR 4-36
SMI
 Definición de los campos

(columnas):
tcpConnRemPort OBJECT-TYPE
SYNTAX INTEGER (0..65535)
tcpConnRemAddress OBJECT-TYPE
ACCESS read-only
SYNTAX IpAddress STATUS mandatory
ACCESS read-only DESCRIPTION
STATUS mandatory "The remote port number for this TCP
DESCRIPTION connection."
"The remote IP address for this TCP ::= { tcpConnEntry 5 }
connection."
::= { tcpConnEntry 4 }
GAR 4-37
SMI
Estructura TcpConnEntry
Objetos “columna”
Objetos escalares
GAR 4-38
SMI
Instancias de objetos
Escalares
 La instancia de un objeto escalar se forma añadiendo un 0 al identificador
del objeto
 Ejemplo:
◦ El objeto tcpRtoAlgorithm tiene el identificador (OID) 1.3.6.1.2.1.6.1
◦ El identificador de una instancia es 1.3.6.1.2.1.6.1.0
Tablas
 SNMP permite estructurar los datos en tablas (filas y columnas)
 Se puede ver como una lista de registros
◦ Una fila → un registro
◦ Campos del registro → columnas en la fila
 Las operaciones SNMP se aplican únicamente a objetos escalares
individuales y sólo se pueden realizar operaciones sobre entradas
individuales de la tabla
GAR 4-39
SMI
Instancias en tablas
Tablas
 Cada entrada se direcciona concatenando información de la
instancia al final del identificador de objeto del campo al que se
desea acceder
 La primera parte identifica la fila, y la segunda, la columna
 Ejemplo: en la tabla tcpConnTable (OID=1.3.6.1.2.1.6.13)
◦ El identificador 1.3.6.1.2.1.6.13.1 designa una fila (objeto
tcpConnEntry)
◦ Los identificadores 1.3.6.1.2.1.6.13.1.1 ... 1.3.6.1.2.1.6.13.1.5 designan
cada una de las cinco entradas de cada fila, respectivamente
GAR 4-40
SMI
Tablas
 El índice de la fila lo define el diseñador de la tabla
◦ Está formado por valores de campos dentro de la tabla
 Ejemplo: para tcpConnTable, el índice está formado por el

siguiente conjunto ordenado de valores:
{tcpConnLocalAddress, tcpConnLocalPort,
tcpConnRemAddress, tcpConnRemPort}
GAR 4-41
SMI
Tablas
 Si la tabla tcpConnTable contiene los siguientes datos:
tcpConn- tcpConn- tcpConn- tcpConn-

tcpConnState
LocalAddress LocalPort RemAddress RemPort
2 0.0.0.0 9 0.0.0.0 0
2 0.0.0.0 19 0.0.0.0 0
6 158.42.160.18 1028 158.42.160.21 6000
 La instancia del objeto tcpConnState de la última fila es:

1.3.6.1.2.1.6.13.1.1.158.42.160.18.1028.158.42.160.21.6000
GAR 4-42
SMI
Acceso a tablas
Tablas
 Acceso directo:
◦ Se especifica la instancia completa
◦ Se emplea la operación GET
◦ Ejemplo:
 GET(1.3.6.1.2.1.6.13.1.1.158.42.160.18.1028.158.42.160.21.6000) 6
 Acceso secuencial:
◦ Se emplea GETNEXT, especificando una instancia de un OID que actúa como
punto inicial de consulta. Se devuelve el valor del objeto y el OID del siguiente
de la tabla, de acuerdo con un orden preestablecido.
◦ En los sucesivos GETNEXT, se usa la instancia del identificador de objeto
entregada, para recorrer las tablas secuencialmente, sin necesidad de conocer
el valor de los índices
GAR 4-43
SMI
Manipulación de tablas
 Inserción de filas:
◦ Para añadir una nueva fila a una tabla, la estación de gestión envía una PDU
de tipo SET, refiriéndose a una instancia de objeto no existente
◦ El agente crea la fila completa que contiene esa instancia del objeto,
proporcionando los valores por defecto que sean necesarios
 Borrado de filas:
◦ Mediante SET también se puede eliminar una fila de una tabla
 Hay que especificar un valor especial del objeto establecido al efecto (invalid o algo
similar)
◦ Ejemplo: En el caso de tcpConnTable, si se asigna a tcpConnState el valor
deleteTCB(12) se provoca que se elimine la entrada de la tabla, y que la
conexión termine:
SetRequest(1.3.6.1.2.1.6.13.1.1.0.0.0.0.9.0.0.0.0.0 = deleteTCB)
Hace que la primera fila de tcpConnTable se borre; el agente responde con
GetResponse(1.3.6.1.2.1.6.13.1.1.0.0.0.0.9.0.0.0.0.0 = deleteTCB)
◦ Depende de la implementación si la entrada se elimina físicamente de la
tabla, o simplemente se marca como NULL
GAR 4-44
3.4. MIB-II
Características de la MIB-II
 La MIB-II es una rama estandarizada de la MIB que se define en el RFC
1213.
 Los nodos deben implementar todos los objetos del mismo grupo o
ninguno
MIB-II  1.3.6.1.2.1
(RFC 1155)
Definido por SMI
Definido en MIB-II
(RFC 1213)
GAR 4-45
MIB-II
Características de la MIB-II
Grupo Nombre Descripción
System system Descripción del sistema
Interfaces interfaces Descripción de los interfaces del sistema
Internet Protocol ip Estadísticas del protocolo IP
Internet Control Message Protocol icmp Estadísticas del protocolo ICMP
TransmisiónControl Protocol tcp Estadísticas del protocolo TCP
User Datagram Protocol udp Estadísticas del protocolo UDP
Exterior Gateway Protocol egp Estadísticas del protocolo EGP
Transmisión transmission MIB de los medios de transmisión
SNMP snmp Estadísticas del propio protocolo SNMP
GAR 4-46
MIB-II
Grupo System
 Proporciona información general sobre el sistema gestionado
◦ Muchos de estos objetos son útiles para la gestión de fallos y de la
configuración
 Objetos para la gestión de fallos
◦ sysObjectID: Información sobre el fabricante del dispositivo (identificador de
objeto para la empresa en el subárbol enterprises)
◦ sysServices: Código de 7 bits que indica los niveles del protocolo de red que
soporta el dispositivo
◦ sysUptime: Tiempo total que ha transcurrido desde la última reinicialización
del sistema
 Objetos para la gestión de la configuración
◦ sysDescr: Descripción textual de la entidad (versión S.O.,
hardware...)
◦ sysLocation: Ubicación física del sistema
◦ sysContact: Persona responsable del sistema
◦ sysName: Nombre del sistema
GAR 4-47
MIB-II
Grupo Interfaces
 Contiene datos genéricos relativos a cada interfaz específico del
sistema. Son útiles en gestión de fallos, de la configuración, de
prestaciones y de contabilidad
 Objetos ifNumber e ifTable

◦ ifNumber: Número de interfaces del sistema (número de entradas en
la tabla)
◦ ifTable: Contiene la información de cada interfaz:
 Para cada interfaz proporciona información sobre:

 Contabilidad y prestaciones:
 Información estadística: número de paquetes enviados, recibidos,
descartados, multicast, erróneos, tamaño de colas ...
GAR 4-48
MIB-II
Grupo Interfaces
 Configuración:
• ifIndex: índice del interfaz
• ifDescr: descripción textual
• ifType: tipo de hardware que hay bajo la capa de red
• ifMTU: tamaño de MTU para el interfaz
• ifPhysAddress: dirección física del interfaz
• ifSpeed: ancho de banda del interfaz (bits/seg)
 Información para la gestión de fallos:

 ifAdminStatus, ifOperStatus: estado deseado y actual del interfaz
(activo, inactivo o en modo de pruebas)
ifAdminStatus ifOperStatus significado
Up up interfaz operativo
Up down error
Down down deshabilitado por el gestor
testing testing pruebas
GAR 4-49
MIB-II
Grupo Interfaces
GAR 4-50
MIB-II
Grupo IP
 Proporciona datos sobre el funcionamiento del protocolo IP
 Configuración:
• ipForwarding, ipDefaultTTL
 Estadísticas:
 Número de datagramas recibidos y enviados, errores, datagramas
reensamblados y fragmentados, etc.
 Tabla de direcciones: ipAddrTable
 Información de las direcciones IP asignadas a esta entidad
 Útil para monitorizar la configuración de la red
 Tabla de encaminamiento: ipRoutingTable
 Información de encaminamiento
 Tabla de traducción de direcciones: ipNetToMediaTable
 Tabla ARP
GAR 4-51
MIB-II
Grupo IP
GAR 4-52
MIB-II
Grupo ICMP
 Proporciona datos estadísticos

relativos al funcionamiento del
protocolo ICMP:
◦ Diversos contadores sobre
tipos de mensajes ICMP
enviados y recibidos
GAR 4-53
MIB-II
Grupo TCP
 Proporciona información
sobre:
 Configuración del protocolo:
◦ tcpRtoAltorithm: algoritmo de cálculo
del timeout para retransmisiones
◦ tcpRtoMin, tcpRtoMax: valores mínimo
y máximo para el timeout
 Estadísticas de conexiones: activas,

pasivas, intentos fallidos de conexión...
 Estadísticas sobre envío y

recepción de segmentos
 Tabla de conexiones TCP:

tcpConnTable
GAR 4-54
MIB-II
Grupo UDP
 Proporciona información
sobre el protocolo UDP:
 Estadísticas sobre envío y

recepción de datagramas UDP
 Tabla de puertos para los que

hay una aplicación aceptando
datagramas en la entidad:
udpTable. Cada entrada es un
par {udpLocalAdress,
udpLocalPort}
GAR 4-55
MIB-II
Grupo EGP
 Proporciona datos
estadísticos sobre envío y
recepción de mensajes EGP
(External Gateway Protocol)
 Tabla egpNeighTable:
Información sobre los
encaminadores vecinos
conocidos
GAR 4-56
MIB-II
Grupo transmission
 Contiene objetos que proporcionan información sobre el medio
de transmisión subyacente para cada interfaz del sistema.
 Existen varias MIBs definidas para cada tipo de interfaz

◦ Algunas están en fase experimental (rama experimental); y cuando se
estandaricen, se moverán al grupo transmission
 Algunos ejemplos:
◦ MIB para IEEE 802.4 Token Bus (RFC 1230)
◦ MIB para IEEE 802.5 Token Ring (RFC 1231)
◦ MIB para FDDI (RFC 1285)
◦ MIB para Ethernet (RFC 1643)
◦ ...
GAR 4-57
MIB-II
Grupo SNMP
 Proporciona estadísticas sobre paquetes SNMP enviados

y recibidos, errores en la sintaxis ASN.1, número de GETs,
SETs y TRAPs...
 Algunas implementaciones se optimizan para ser agentes

o gestores
◦ Devuelven 0 en aquellos objetos que no tienen sentido para ellas
 Objeto snmpEnableAuthenTraps
◦ Indica a un agente si debe enviar un trap de error de
autentificación, al recibir un mensaje con nombre de comunidad
erróneo
GAR 4-58
MIB-II
Grupo SNMP
GAR 4-59
3.5 Ejemplos de MIBS

HOST-MIB
 Los Sistemas Operativos llevan asociadas MIBS que permiten

obtener información de sus recursos (físicos o lógicos) y
gestionarlos remotamente como si se tratara de un dispositivo
de red.
 La principal ventaja es que se pueden integrar en un SGR y ser

gestionados con la misma herramienta que se está usando para
los dispositivos de red.
 Es posible usar MIBS estándar o propietarias de fabricantes.

◦ Host Resources MIB (RFC 2790)
◦ Propietarias
GAR 4-60
HOST-MIB
 RFC 2790 - Host Resources MIB

◦ Sustituye a la RFC 1514 (Host Resources MIB)
host OBJECT IDENTIFIER ::= { mib-2 25}
hrSystem OBJECT IDENTIFIER :.= {host 1}

hrStorage OBJECT IDENTIFIER :.= {host 2}
hrDevice OBJECT IDENTIFIER :.= {host 3}
hrSWRun OBJECT IDENTIFIER :.= {host 4}
hrSWRunPerf OBJECT IDENTIFIER :.= {host 5}
hrSWInstalled OBJECT IDENTIFIER :.= {host 6}
hrMIBAdminInfo OBJECT IDENTIFIER :.= {host 7}
GAR 4-61
HOST-MIB
Grupo System
 Proporciona información general del sistema operativo.
GAR 4-62
HOST-MIB
Grupo Storage
 Proporciona información sobre sistemas de almacenamiento

(memoria, discos, etc.)
 Dispone de un objeto que hace referencia a la memoria central
y una tabla con información sobre el resto de sistemas de
almacenamiento
◦ hrMemorySize { hrStorage 2 }
◦ hrStorageTable { hrStorage 3 }
 hrStorageEntry { hrStorageIndex }
 hrStorageIndex
 hrStorageType
 hrStorageDescr
 hrStorageAllocationUnits
 hrStorageSize
 hrStorageUsed
 hrStorageAllocationFailures
GAR 4-63
HOST-MIB
Grupo Storage
 Memoria central
 Otros:
GAR 4-64
HOST-MIB
Grupo Devices
 Permite identificar y diagnosticar dispositivos del sistema

◦ Los tipos de dispositivos están definidos en HOST-
RESOURCES-TYPES
 Proporciona varias tablas: Dispositivos, procesadores, red,

impresoras, discos, particiones y sistemas de ficheros
GAR 4-65
HOST-MIB
Grupo Devices
 Devices
GAR 4-66
HOST-MIB
Grupo Devices
 Procesadores
 Red
 Impresoras
GAR 4-67
HOST-MIB
Grupo Devices
 Discos
 Particiones
 Sistemas de ficheros:
GAR 4-68
HOST-MIB
Grupo SWRun
 Proporciona información sobre procesos que se están

ejecutando o están cargados en la memoria física o virtual
 Incluye los procesos del sistema operativo, drivers y aplicaciones
 Proporciona:
 Objeto que identifica al sistema operativo que se ejecuta
 Tabla con valores de los procesos
GAR 4-69
HOST-MIB
Grupo SWRun
 Grupo SWRun
GAR 4-70
HOST-MIB
Grupo SWRunPerf
 Proporciona datos sobre los procesos que se están ejecutando
 Proporciona una tabla que da información sobre:

 Centésimas de seg del tiempo total de CPU consumidos
por el proceso
 Cantidad de memoria que tiene localizada el proceso
GAR 4-71
HOST-MIB
Grupo SWRunPerf
GAR 4-72
HOST-MIB
Grupo SWInstaled
 Proporciona información sobre las aplicaciones instaladas
GAR 4-73
Otros ejemplos de MIBS
 Ejemplo MIB
◦ microsoft.software.systems.os.winnt.performance.memory (1.3.6.1.4.1.311.1.1.3.1.1.1)
GAR 4-74
Otros ejemplos de MIBS
 Ejemplo MIB
GAR 4-75
3.6 SNMPv3
Introducción
 SNMP (v1) presenta algunas deficiencias. Entre otras:

◦ Escasa seguridad
◦ Bajo rendimiento
◦ Funcionalidad reducida
 Con objeto de mejorar esas deficiencias se desarrollan nuevas

versiones. En general:
◦ SNMP-v2  Incorpora mejoras de funcionalidad y rendimiento
◦ SNMP-v3  Incorpora mejoras de seguridad sobre SNMP-v2
GAR 4-76
SNMPv3
Principales características
 Se amplia la macro de definición de los tipos de datos, con nuevos tipos

ampliados.
 Se añaden nuevas convenciones para la creación y eliminación de filas
en una tabla.
 Se permite usar cadenas de tamaño variable como índices de una tabla.
 Se incorpora una nueva PDU (GetBulkRequest) que permite transferir
bloque de datos de tablas.
 Se definen nuevas ramas de la MIB que proporciona más conjuntos de
datos estadísticos.
 Se amplia la definición de los TRAPs.
 Se posibilita que dos o más estaciones de gestión cooperen entre si.
 Se proporciona un soporte de seguridad elevado.
GAR 4-77
SNMPv3
Agente proxy y gestor bilingüe
Entorno SNMPv2/3 Entorno SNMP
GetRequest GetRequest
Gestor
GetNextRequest GetNextRequest
SNMPv2/3
InformRequest
SetRequest SetRequest GetRequest,
InformRequest GetNextRequest,
GetBulkRequest GetNextRequest SetRequest
Gestor Agente
Response, bilingüe SNMP
Gestor
Agente
Agente SNMPv2/3- GetResponse,
SNMPv2/3 y
SNMPv2/3 proxy SNMP T Trap
GetRequest,
Agente
SNMPv2/3 GetNextRequest,
Response GetResponse GetBulkRequest,
SNMPv2/3 Trap Trap
SetRequest
GAR 4-78
SNMPv3
Arquitectura
 SNMPv3 define una arquitectura de gestión de red:

◦ Arquitectura de gestión: Colección de entidades SNMP que
interaccionan entre sí
◦ Cada entidad incorpora un conjunto de módulos y cada uno
de ellos proporciona unas capacidades de SNMP
◦ Según los módulos que tenga una entidad, esta podrá actuar como
gestor, agente o como ambos simultáneamente.
◦ Cada entidad incluye un motor SNMP, que implementa funciones

para enviar y recibir mensajes, autentificar y encriptar / desencriptar
mensajes, y controlar el acceso a los objetos gestionados
GAR 4-79
SNMPv3
Arquitectura
Aplicaciones
ENTIDAD
Generador de Receptor de Reenviador
comandos notificaciones proxy
Respondedor de Originador de
comandos notificaciones
Otros MÓDULOS
Motor SNMP
(se identifica por snmpEngineID)
Subsistema de Subsistema de
Subsistema de
Despachador procesamiento seguridad control de
de mensajes acceso
GAR 4-80
SNMPv3
Principales módulos de la arquitectura
 Generador de comandos
◦ Inicia la generación de PDUs Get, GetNext, GetBulk y/o Set, y
procesa sus respuestas
 Respondedor de comandos
◦ Recibe las PDUs Get, GetNext, GetBulk y/o Set dirigidas al
motor local, las atiende, y genera la correspondiente respuesta
 Originador de notificaciones
◦ Monitoriza en un sistema la ocurrencia de eventos o condiciones
particulares y genera PDUs Trap y/o Inform en función de ellos
 Receptor de notificaciones
◦ Permanece a la escucha de mensajes de notificación, y genera la
respuesta a los PDUs Inform
 Reenviador proxy (proxy forwarder)
◦ Reenvía mensajes SNMP
GAR 4-81
SNMPv3
Principales módulos de la arquitectura (motor)
 Despachador (dispatcher): Realiza el envío y recepción de
mensajes y PDUs con la red.
 Subsistema de procesamiento de mensajes: Prepara las

PDU para su envío/recepción.
 Subsistema de seguridad: Proporciona los servicios de

seguridad (autentificación, encriptado) al subsistema de
procesamiento de mensajes (USM: User-based Security Model)
 Subsistema de control de acceso: Proporciona un conjunto

de servicios de autorización para comprobar los derechos de
acceso a la MIB de una entidad. Implementa el modelo de
control de acceso basado en vistas (VACM: View-based Access
Control Model).
GAR 4-82
SNMPv3
Arquitectura de un gestor
GAR 4-83
SNMPv3
Arquitectura de un agente
GAR 4-84
SNMPv3
Seguridad
 Una de las principales ventajas de SNMP-v3 frente a las
versiones previas es que incorpora mecanismos de seguridad
frente a modificación y enmascaramiento (principalmente).
 Además, SNMP usa un servicio de transporte no orientado a la

conexión (UDP) por lo que cada paquete puede seguir una ruta
distinta, con lo que podría alterarse el flujo de paquetes.
 SNMPv3 proporciona tres servicios:

◦ autenticación,
◦ privacidad
◦ control horario
GAR 4-85
SNMPv3
Seguridad: PDUs
 Los paquetes SNMP-v3 pueden incorporar:
◦ Encriptación parcial
◦ Autenticación
◦ msgFlags:
 reportableFlag: igual a 1 si hay que generar una PDU de respuesta a la
recepción de este mensaje (servicio confirmado)
 privFlag: aplica encriptación msgVersion
 authFlag: aplica autentificación msgID

Alcance de la
msgMaxSize msgGlobalData
autentificación
msgFlags
◦ Niveles de seguridad: msgSecurityModel
 noAuthNoPriv msgSecurityParameters
Definido y usado por el
Modelo de Seguridad
 authNoPriv contextEngineID
 authPriv contextName
Alcance de la
“Scoped PDU”
encriptación
PDU
GAR 4-86
SNMPv3
Seguridad
 Se definen dos capacidades relacionadas con la seguridad:

◦ Modelo de seguridad basado en el usuario (USM, User-based
Security Model) (RFC 2274)
 Subsistema de seguridad
 Proporciona funciones de autentificación y privacidad (encriptado)
 Opera a nivel de mensaje (PDU)
◦ Modelo de control de acceso basado en vistas (VACM, View-

based Access Control Model)
 Subsistema de control de acceso a los objetos de una MIB
 Determina si una entidad puede acceder ciertos objetos de la MIB, y en
su caso, qué puede hacer.
GAR 4-87
SNMPv3
Seguridad USM
 USM se basa en el concepto tradicional de usuario/password
 USM incluye varios aspectos:

◦ Autentificación: proporciona integridad a los datos y autentificación
de su origen (mediante HMAC-MD5-96 ó HMAC-SHA-96)
◦ Temporización (timeliness): protege contra mensajes retardados o
duplicados
◦ Privacidad: protege contra la revelación de la carga del mensaje
(encriptación mediante DES)
◦ Descubrimiento: define procedimientos para que un motor SNMP
obtenga información acerca de otro motor SNMP
◦ Gestión de claves: define procedimientos para la generación,
actualización y uso de claves
GAR 4-88
SNMPv3
Seguridad USM
 Motor autorizado (authoritative engine): Es el motor responsable de la
exactitud de las marcas de tiempo y de los identificadores únicos en cada
mensaje.
 Cada motor SNMP no autorizado debe mantener una tabla con los
tiempos e identificadores de los motores SNMP autorizados con los que
se comunica.
 Para la autenticación, se añade a cada mensaje un identificador único
asociado con un motor SNMP autorizado
 Los relojes se emisor y receptor se sincronizan con el motor autorizado
 Dadas dos entidades SNMP-v3:
◦ En mensajes GetRequest,
GetNextRequest, GetBulkRequest,
SetRequest e Inform, el motor
autorizado es el receptor
◦ En mensajes Trap, GetResponse y Report,
GAR 4-89
el motor autorizado es el emisor
SNMPv3
Seguridad VACM
 El modelo de seguridad VACM se utiliza para controlar el acceso a la MIB

de los agentes. El RFC 2275 define los cinco elementos del modelo VACM:
◦ (1) Nivel de seguridad: Nivel de seguridad del usuario
 noAuthNoPriv
 authNoPriv
 authPriv
GAR 4-90
SNMPv3
Seguridad VACM
◦ (2) Vistas: Vistas aplicable a distintas operaciones

 notify-view: Notificaciones (Traps)
 read view: Operaciones de lectura
 write-view: Operaciones de escritura
◦ (3) Grupo: Especifica el nivel de seguridad que se va a utilizar y al cual

se le asignan las vistas creadas anteriormente para permitir / restringir
el acceso a ciertos MIBs/OIDs.
 Un grupo se define como <modelo_de_seguridad , nombre_de_seguridad>
 A un grupo se le asocian usuarios
 Un grupo es equivalente a una ‘comunidad’ en SNMPv1
GAR 4-91
SNMPv3
Seguridad VACM
◦ (4) Contexto: Subconjunto de instancias de la MIB local (subconjunto

de información de mantenimiento disponible para una entidad SNMP)
◦ (5) Política de acceso: Determina los derechos de acceso a objetos

(RW, RO, Notify, …)
 Proceso VACM: Comprobaciones

◦ (1) Who are you? (¿el grupo del solicitante es válido?)
◦ (2) Where do you want to go? (¿dónde quiere acceder?)
◦ (3) How secure you? (¿nivel de seguridad?
◦ (4) Why do you want to Access the information? (to read, to rw, …)
◦ (5) What object do you want to Access? (tipo de objeto)
◦ (6) Which object? (OID)
GAR 4-92
SNMPv3
Seguridad VACM
1 2 3 4 5 6
GAR 4-93
TEMA 1
INTRODUCCION A LA GESTION
Y ADMINISTRACION DE REDES
Contenidos
1. Introducción
2. Sistemas de Gestión de Red
3. Áreas de la Gestión de Red
4. Estándares de Gestión de Redes
GAR 1-2
Introducción
¿Qué abarca la Gestión y Administración de Redes?
 Red de transmisión de datos: Conjunto de dispositivos

conectados entre si que permiten el transporte de datos la
transferencia de información entre dos lugares
◦ Cada dispositivo de red dispone de un hardware y un sistema
operativo
◦ La interconexión de los dispositivos se realiza a través de un medio
de transmisión
◦ La coordinación entre los dispositivos se realiza usando protocolos
de red
Dispositivos Hardware Router. Switch, punto acceso, etc.
Red de transmisión
de red Sistema operativo IOS, propietario.

de datos
Medio de transmisión Par trenzado, Fibra óptica, Wireless, Etc.
Protocolos ARP, IP, ICMP, etc..
GAR 1-3
Introducción
 Red de computadores: Conjunto de dispositivos terminales

interconectados por una red de transmisión de datos.
◦ Los dispositivos terminales pueden ser muy variados (ordenadores,

periféricos, …) y cada uno dispone de hardware y un sistema
operativo
◦ La coordinación entre los dispositivos terminales se realiza usando
protocolos extremo-extremo
Red de transmisión de datos

computadores
Servidor, PC, impresora, etc.

Hardware
Terminales
Red de
Sistema operativo Windows, Linux, etc
Protocolos
TCP, SMTP, etc.
Servicios DNS, NFS, etc.
GAR 1-4
Introducción
1
Dispositivos Hardware Router. Switch, etc.
Red de transmisión
de red Sistema operativo IOS, propietario.
2
de datos
3
Red de computadores
Medio de transmisión Par trenzado, Fibra óptica, Wireless, etc.
4
Protocolos enlace de datos ARP, IP, ICMP, etc..
5
terminales
Hardware
Equipos
Servidor, PC, impresora, etc.
6
Sistema operativo Windows, Linux, etc
7
Protocolos de alto nivel TCP, SMTP, etc.
8 DNS, NFS, etc.

Servicios
GAR 1-5
Introducción
Herramientas de Gestión de red
 Las redes de computadores actuales son muy complejas:
◦ Muy grandes con muchos dispositivos
◦ Componentes heterogéneos de distintos fabricantes (distintos
sistemas operativos)
◦ Muchos usuarios
◦ Muchas aplicaciones en red
 La administración manual se hace inviable. Es necesario contar

con herramientas de gestión de red para controlar posibles
fallos o degradaciones en las prestaciones de la red.
 Existen numerosas herramientas (comerciales y basadas en

software libre) que facilitan la gestión de la red.
GAR 1-6
Introducción
Dimensiones de gestión
 La gestión de red se puede ver desde varios puntos de vista
Cableado
Componentes
a gestionar
Dispositivos de red
Protocolos
Gestión y Administración de Redes
Servidores/terminales
Arquitectura Servicios
Centralizada
de gestión
Semidistribuida
Distribuida
Fallos
Áreas de
Configuración
gestión
Contabilidad
Rendimiento
Seguridad
Estándares
de gestión
OSI (CMOT)
TCP/IP (SNMP/RMON)
GAR 1-7
Introducción
Objetivos de la gestión de redes: Niveles de servicio
Objetivo general: Asegurar que los usuarios de la red reciben

servicio que ésta proporciona, con la calidad esperada.
 Se establece un SLA (Service Level Ageement) con los usuarios
y la red debe proporcionarlo.
Para ello, se pueden considerar tres niveles de servicio:

 Nivel 1 (Supervivencia): La red debe proporcionar un servicio
mínimo, aunque sea en modo degradado. Al menos, debería dar
servicio a aplicaciones críticas
 Nivel 2 (Eficacia): La red debe proporciona un servicio aceptable
 Nivel 3 (Eficiencia): La red proporcione el mejor servicio posible
(el nivel de servicio para el que fue diseñada)
GAR 1-8
Introducción
Niveles de gestión: OAM&P
Las tareas de gestión pueden estructurarse a cuatro niveles: OAM&P (Operations,
Administration, Maintenance and Provisioning)
 Grupo de operación y administración:
◦ Operación: Tareas de control diario de los dispositivos (recogida de
información, diagnóstico, evaluación de alarmas, control de configuraciones,
etc.).
◦ Administración: Procedimientos necesarios para que el grupo de
operaciones pueda realizar sus tareas (gestión de passwords, control de acceso
a dispositivos, establecimiento de políticas, etc.)
 Grupo de mantenimiento:
◦ Mantenimiento: Tareas que no afectan al estado operativo de la red y no
son consecuencia de fallos (cambios de configuración por degradación de
servicios, cambios de políticas de seguridad, cambios de hardware, etc.)
 Grupo de aprovisionamiento
◦ Provisioning: Tareas de planificación y diseño (introducir nuevos servicios,
rediseñar parte de la red, instalar nuevo hardware, etc.)
GAR 1-9
Introducción
1 Operación y administración
2 Mantenimiento
3 Aprovisionamiento
3 1 2
GAR 1-10
Introducción
 Flujo de tareas habituales

1 Operación y administración
2 Mantenimiento
3 Aprovisionamiento
3 1 2
GAR 1-11
1.2 Sistemas de Gestión de Red

Arquitectura
 Un Sistema de Gestión de Red (SGR, o NMS (Network
Management System) es una combinación de hardware y
software usado para administrar y monitorizar una red de
computadores (dispositivos de red y dispositivos finales)
 Componentes de un sistema de gestión de red (SGR):

◦ Elementos de Red (NE: Network Element): hardware/software
en el que se ejecutan procesos que ofrecen uno o más servicios (un
dispositivo de red puede tener uno o más elementos de red).
◦ Gestor de elemento de red (EM: Element Manager): servicio
que recopila datos de un o más elementos de red.
◦ Sistema gestor de elementos de red (EMS: Element
Management System): Es un servicio que gestiona uno o más
gestores de elementos de red.
GAR 1-12
1.2 Sistemas de Gestión de Red
Arquitectura
 Cada gestor de elemento de red (EM) implementa un agente software que
debe ser compatible con los elementos de red (NE) (hardware/software) que
controla. Los EM suele proporcionarlos el propio fabricante del hardware.
 Dependiendo de la red, puede haber uno o más EMSs.
NMS Sistema de gestión de red
EMS EMS Agentes software
EM-a EM-b EM-c Agentes software

en dipositivos
Hardware/software
NE-a1 NE-a2 NE-b1 NE-c1 NE-c2 gestionado
 Para cada dispositivo gestionado (NE), el agente del dispositivo (EM) define un
conjunto de objetos que representan las características que se desean
GAR 1-13
gestionar y almacena su contenido, que es usado por los EMS.
Sistemas de Gestión de Red

Arquitectura
EM EM
NE NE
 En un sistema de gestión de red EM
EM
pueden existir varias arquitecturas: NE
NE
NMS
◦ Centralizada: Sólo existe un EMS
EM
EMS que gestiona todos los EMs EM EM EM EM EM EM
desde una sola ubicación NE NE NE NE NE NE

NE
EMS / EM EMS / EM
NE NE
◦ Jerárquica: Existen varios EMSs EM
EM
distribuidos y cada uno gestiona NE
NE
los EMs de su ámbito geográfico. NMS
Todos los EMSs se gestiona desde EM EM EM EM EM EM EM
un solo NMS NE NE NE NE NE NE NE
EMS EM EMS EM
◦ Distribuida: Usa varios EMSs NE NE
distribuidos espacialmente y varios EM
EM
NMSs que cooperan entre si NE
NE
NMS
NMS EM
EM EM
EM EM EM EM
GAR 1-14 NE NE NE NE NE NE NE
Arquitectura software
 Desde el punto de vista software, la arquitectura de un SGR/NMS
puede verse:
Interfaz de usuario unificada
Presentación de la información de
gestión de red a los usuarios
Aplicación de Aplicación de
Capa de gestión de red gestión de red
aplicación
elemento elemento elemento
aplicación aplicación aplicación
gestionadas
Servicio de transporte de datos de gestión de la red
Redes
Módulo de Pila de protocolos
MIB acceso a MIB de comunicación
Capa de
GAR 1-15 transporte

Componentes
 Un SGR está compuesto por tres componentes:
◦ Dispositivos gestionados:
 Son dispositivos (físicos o lógicos) situados a lo largo de la red, que
proporcionan conectividad (dispositivos de red) o servicio al usuario
(servidores, terminales, periféricos, etc.).
 Suelen incorporar un agente de gestión (software) y una pequeña base
de datos con información de gestión.
◦ Estación de Gestión de red (gestor):
 Es el equipo informático (PC) desde el que se gestiona la red.
 Es un ordenador normal, al que se le añade un software de gestión,
generalmente con un interfaz gráfico (consola).
◦ Protocolo de gestión de red:
 Es el protocolo que comunica a los dispositivos gestionados con la
estación de gestión.
 Está situado en la capa de aplicación de OSI / DoD
GAR 1-16
Componentes: ejemplo consola SGR
 Ejemplo de consola: PHP Network Weathermap
http://www.rediris.es/conectividad/weathermap/
GAR 1-17

 Ejemplo: PHP Network Weathermap
https://tools.geant.net
GAR 1-18
 Ejemplo: MRTG
GAR 1-19

 Ejemplo: Consola integrada (nagios)
GAR 1-20
1.3 Áreas de la Gestión de Red
OSI Management Framework
 Existen varios modelos de SGR. Uno de ellos es el TMN
(Telecommunications Management Network) se basa en la arquitectura
OSI de ISO y define un marco de trabajo para mantenimiento de redes
y servicios.
 TNM define, entre otras cosas, que las entidades de mantenimiento
estarán en lo alto de la capa de aplicación. Por ello, tendrán acceso a
todos los servicios aportados por las capas inferiores.
APLICACIÓN DE GESTION
(ENTIDAD) PROTOCOLO (AGENTE)

APLICACION DE GESTION APLICACIÓN
PRESENTACION PRESENTACION
SESION SESION
TRANSPORTE TRANSPORTE
RED RED
ENLACE DATOS ENLACE DATOS
FISICA FISICA
GAR 1-21
Áreas de la Gestión de Red

FCAPS
 TNM también define 5 áreas funcionales relacionadas con el
mantenimiento de redes (FCAPS)
1. Fault (fallos)
2. Configuration (configuración)
3. Accounting (contabilidad)
4. Performance (rendimiento)
5. Security (seguridad)
5
3
1
4
2
GAR 1-22
Gestión de configuración
 Está orientada a conocer la configuración de los dispositivos de
red, su posible modificación, así como a facilitar la
configuración remota.
 Incluye:
◦ Gestión de la configuración de dispositivos y servicios
◦ Inicio y desconexión ordenada de la red o de parte de ella.
◦ Mantenimiento y reconfiguración de componentes
◦ Almacenaje de los parámetros de configuración de los
dispositivos en una base de datos (Inventory Data Base).
GAR 1-23

 Un elemento importante de la gestión de configuración es la base de
datos de gestión de configuración (CMDB: Configuration
Management DataBase).
◦ Es una base de datos que contiene información relevante sobre todos los
“elementos de configuración” (CI: Configuration Item) de la red (atributos,
configuraciones, relaciones, etc.).
◦ La CMDB contiene las relaciones entre los elementos.
◦ En caso de fallos, se puede localizar el origen a través de las relaciones.
◦ Las relaciones se pueden ir creando de forma automática mediante una
herramienta de autodescubrimiento.
◦ La información puede usarse para detectar cambios en la configuración y
restaurar los dispositivos a su estado ‘normal’.
GAR 1-24
 Principales ventajas:
◦ La configuración de todos los dispositivos estará almacenada en una
base de datos.
◦ Se puede gestionar la configuración de todos los dispositivos desde
una única consola. Si un dispositivo se desconfigura, es posible
configurarlo automáticamente a partir de la información almacenada
en la base de datos de inventario.
◦ Se mejora el mantenimiento de la red, al poder actuar sobre toda la
red desde un punto localizado.
◦ Si se producen errores, o hay dispositivos que fallan, se podrán
reconfigurar o desactivar desde un lugar remoto.
◦ Se pueden detectar fácilmente cambios no autorizados de la
configuración.
GAR 1-25

 Ejemplo herramienta monitorización de configuraciones: RANCID
GAR 1-26
Gestión de fallos
 Objetivo: Localización fallos (o incidencias) en la red, así como su
aislamiento y recuperación.
◦ Incidencia: acontecimiento extraordinario que ocurre en la red, que afecta al
servicio que proporciona
 Principales tareas:
◦ 1: Determinar dónde está el fallo con exactitud.
◦ 2: Si es posible, aislar al resto de la red, para que pueda seguir funcionando
sin interferencias.
◦ 3: Recuperar el dispositivo que falla (reinicio, reconfiguración, etc.) o
sustitución de componentes averiados.
 Problemas:
◦ A veces no es fácil localizar la causa de un fallo. Puede haber múltiples fallos
por una sola causa.
◦ A veces, un fallo en una capa provoca fallos en todas las superiores
 La gestión de fallos puede apoyarse en la gestión de configuración,
GAR 1-27
haciendo uso de la base de datos de inventario.

Gestión de fallos
SI
DOCUMENTACION
INVESTIGACION Y
DETECCION DEL
RECUPERACION
CLASIFICACION
RESOLUCION Y
DIAGNOSIS
¿REGISTRADO?
EXTERNO?
¿SERVICIO
CIERRE
NO
FALLO
NO
SI
Clasificación:
• Área de impacto: ¿a quien afecta?
• Nivel de impacto: ¿Cómo afecta a los usuarios?
• Nivel de urgencia: ¿Es prioritaria la resolución?
• …..
GAR 1-28
Gestión de fallos
 Priorización de fallos: Es habitual que la gestión de un fallo
afecte a otras tareas cotidianas de la red, por lo que es
importante priorizarlo:
◦ Impacto: Mide el efecto que tiene el fallo en la red
◦ Urgencia: Mide el tiempo que tarda en tener un efecto negativo en la red
 Es posible tener un fallo de alto impacto, con baja urgencia de resolución
(por ejemplo: en diciembre se detecta un fallo en la aplicación de
preinscripción)
 Cuestiones a tener en cuenta para determinar la urgencia:

◦ Concurrencia: Cuando se detecta el fallo, ¿se están produciendo otros?
◦ Recursos disponibles: ¿Tengo los recursos humanos y materiales
necesarios para resolverlo?
◦ Problemas derivados: ¿Si no lo soluciono rápido, van a aparecer otros
GAR 1-29 fallos?

Gestión de fallos
 La detección de un fallo puede ser manual o automática:
◦ Manual: Un usuario llama e indica que algo falla.
◦ Automática: Existe un procedimiento automatizado: Para
detectar a existencia de un fallo. Pueden usarse varios métodos:
1. Sondeo periódico: Se seleccionan varios parámetros de cada
dispositivo y se sondean periódicamente, detectando valores
inadecuados (monitorizar). Puede usarse la base de datos de
inventario
2. Generación de eventos (traps): Cuando un dispositivo tiene
una situación crítica, genera un evento que llega a la consola del
SGR. Es posible que el propio fallo impida que lleguen.
 Generalmente, se implementan las tres posibilidades: Manual mediante

un sistema de CAU y automática con sondeo periódico y TRAPS
GAR 1-30
Gestión de fallos
 Los fallos detectados deben registrarse también en la consola del
SGR para informar de su ocurrencia y mantener un histórico
 Periódicamente se obtienen estadísticas sobre los fallos (o incidentes)

registrados. Se pueden obtener:
◦ Número de incidentes que han provocado degradación del servicio
◦ Tiempo acumulado con servicio degradado
◦ Tiempo medio de resolución de incidentes
◦ Número de incidentes resueltos en el plazo acordado (SLA)
◦ Coste económico de la resolución de los incidentes (equipos, horas
de personal técnico…)
◦ Número de incidentes reabiertos
GAR 1-31

Gestión de fallos
 Para facilitar la gestión de fallos, es útil usar SysLog
◦ Es un protocolo muy básico, definido en la RFC 5424 (The Syslog protocol)
que permite enviar mensajes de texto emitidos por dispositivos, a una
localización centralizada
◦ Para cada mensaje, se registra la hora de emisión, origen, texto, etc.
◦ SysLog permite registrar en un único lugar, todos los mensajes de consola
generados por los dispositivos de red.
 Para que los mensajes se almacenen adecuadamente, es necesario que

los dispositivos que los generan tengan sus relojes sincronizados (con
NTP, por ejemplo).
GAR 1-32
Gestión de fallos
 Si se dispone de un SGR, se puede tener un registro automático de fallos
GAR 1-33

Gestión de fallos
 Una herramienta muy útil para gestionar los fallos/incidencias es el
diagrama causa-efecto:
 Componentes:
◦ Problema a analizar: Se indica a la derecha
◦ Línea principal: Línea horizontal que llega hasta el problema a analizar
◦ Causas primarias: Líneas oblicuas que parten de una caja en la que se indica la
causa y llegan a la línea principal
◦ Causas secundarias: Líneas horizontales que salen del nombre de la causa y
llegan a las líneas oblicuas de las causas primarias
◦ Causas menores: Líneas oblicuas que salen de la causa menor y llegan a la
línea horizontal de la causa secundaria
Problema a analizar
GAR 1-34
Gestión de fallos
 Diagrama causa-efecto:
Causa menor
Causa primaria Causa primaria Causa menor
Causa secundaria
Causa secundaria
Causa secundaria Causa secundaria
Problema a analizar
Causa secundaria
Columna vertebral
Causa secundaria
Espina
Espina menor
Causa primaria
GAR 1-35

Gestión de contabilidad
 Objetivo: Realizar el seguimiento del uso de recursos de la red
por parte de los usuarios.
 Puede ser útil por varios motivos:

◦ Facturación. Cobrar por tiempo de uso, por tráfico, etc.
◦ Vigilancia de abusos. Usuarios que intentan monopolizar los
recursos y pueden dar lugar a sobrecargas en la red y prejuicios a
otros usuarios
◦ Control del fairness (uso equitativo de los recursos de la red entre
los usuarios)
◦ Control de calidad de servicio (o calidad de experiencia)
◦ Planificación del crecimiento de la red
◦ Etc.
GAR 1-36
 Ejemplo de control del fairness
1 3
150
1 150
150
3
2 4
4 2
1-> 50 3->75 4->150
2-> 50 4->75
3-> 50
1 3
150
1 150
150
3
2 4
4 2
1-> 50 4->150
3->50
2-> 50 4->100
3-> 50
GAR 1-37

 Algunas limitaciones típicas que pueden imponerse son:
◦ Espacio máximo de almacenamiento en discos de los nodos.
◦ Uso máximo de los recursos de red (ancho de banda…).
◦ Tiempo máximo de conexión.
◦ Caudal sostenido de la red y caudal pico
◦ Etc.
 También es necesario especificar los algoritmos a emplear para

evaluar el consumo:
◦ Por tiempo, paquetes transmitidos, bytes transmitidos, ...
GAR 1-38
 Los sistemas operativos permiten establecer límites de uso de
algunos recursos, siendo su valor, un parámetro gestionado por
el SGR
 Los dispositivos de red también permiten especificar niveles de
calidad de servicio, limitación de caudal, etc.
GAR 1-39

Gestión de seguridad
 La gestión de la seguridad tiene relación con:
◦ Seguridad física de los dispositivos de la red: Sólo las personas
autorizadas deben tener acceso a los recintos donde están los
dispositivos de la red.
◦ Seguridad de los sistemas operativos: Deben configurarse

adecuadamente para evitar el acceso de usuarios nos autorizados,
modificación de configuraciones, manipulación de servicios, etc.
◦ Seguridad en el acceso a la red: Deben implementarse

mecanismos que impidan el acceso a la red de personas no
autorizadas (cortafuegos, seguridad en el acceso, etc.).
GAR 1-40
 Control de acceso a la red: Hay que dar el mínimo privilegio posible.
Hay que controlar que pueden hacer los usuarios, a que recursos pueden
acceder y que pueden hacer con esos recursos (AAA):
◦ Authentication: Antes de acceder al sistema, hay que comprobar la
identidad del usuario.
◦ Authorization: Para los usuarios autenticados, se debe autorizar
explícitamente el uso de recursos.
◦ Accountability: Todo lo que se haga en el sistema debe ser registrado
GAR 1-41

 La información de un sistema informático será segura si se garantiza su:
◦ Confidencialidad: Sólo se puede acceder a la información mediante
autorización y de forma controlada.
◦ Integridad: Sólo se pueden modificar la información previa autorización.
◦ Disponibilidad: La información debe permanecer accesible previa
autorización.
◦ Autenticación: Cada una de las partes debe tener garantías sobre la
identidad de la otra parte
◦ No repudio: Debe quedar constancia de que las dos partes han intervenido
en la comunicación
GAR 1-42
 Principales tipos de ataques que se pueden producir:
◦ Interrupción de servicio:
 Un ente no autorizado interrumpe la comunicación
 Afecta a la disponibilidad de la red E R
 No afecta a la confidencialidad e integridad
 Ejemplo: Cortar un cable, destruir un elemento de red
◦ Intercepción:
 Un ente no autorizado (persona, programa, ordenador) accede a
recursos de la red. E R
 Afecta a la confidencialidad
 No afecta a disponibilidad e integridad
 Ejemplo: Uso de un analizador de protocolos, copia de datos, etc.
GAR 1-43

◦ Modificación:
 Un ente no autorizado realiza una intercepción y modifica datos,
dejándolos en la red E R
 Afecta a la integridad y confidencialidad
 No afecta a la disponibilidad
 Ejemplo: Alteración de un archivo de configuración, cambiar el
contenido de mensajes, etc.
◦ Fabricación:
 Un ente no autorizado crea nuevos mensajes en la red
 No afecta a la confidencialidad, integridad y disponibilidad
 Ejemplo: Mensaje obligando a cambiar la clave de usuarios
E R
GAR 1-44
GAR 1-45

Gestión de rendimiento
 Su objetivo es asegurar que la capacidad y prestaciones de la red y
sus equipos terminales corresponde con las necesidades de los
usuarios
 Es muy importante saber evaluar el rendimiento de la red en
conjunto y de sus componentes individualizados.
 Cuestiones importantes:
◦ ¿Qué medir?  Selección de un conjunto de parámetros (métrica)
◦ ¿Cómo obtener las medidas?  Modo (intrusivo, no intrusivo),
protocolo…
◦ ¿Qué hacer con las medidas?  Análisis y acciones a tomar
 Lleva asociadas las siguientes fases:
◦ Monitorización de los dispositivos de la red y sus enlaces para
determinar su utilización y ratios de error.
GAR 1-46 ◦ Ayudar a que la red proporcione el nivel de servicio óptimo.
 En la gestión del rendimiento, es muy importante disponer de
información, que se obtiene de los propios dispositivos de la red.
 Tipos de información:
◦ Estática: Hace referencia a elementos de la red y su configuración (por
ejemplo, número de puertos de un router)
◦ Dinámica: Está relacionada con sucesos (por ejemplo, número de
conexiones TCP, estado administrativo del puerto de un switch)
◦ Estadística: Obtenida en intervalos de tiempo (bits por segundo en
interfaz)
 Tipos de medidas
◦ Medidas pasivas: Se toman las medidas sin afectar al tráfico
◦ Medidas activas: Se genera tráfico artificial y se toman las medidas,
analizando cómo afecta este tráfico conocido.
GAR 1-47

 Técnicas de evaluación:
◦ Monitorización: Se utilizan herramientas de medición para obtener
medidas reales de un sistema en funcionamiento, con cargas de trabajo
reales.
◦ Modelado: Se usa cuando hay elementos
del sistema que no están instalados. Puede
ser de dos tipos:
 Técnicas analíticas: Se utilizan
Técnicas de
modelos matemáticos para definir el evaluación
sistema.
 Técnicas de simulación: Se utilizan
Monitorización Modelado Benchmark
herramientas que representan ciertas
características del sistema.
Métodos
◦ Benchmark: Se utilizan cargas de trabajo analíticos
estandarizadas y se monitoriza el sistema
con ellas. De esta forma, se pueden hacer Simulación
comparaciones entre sistemas.
GAR 1-48
 En la gestión del rendimiento, es frecuente establecer alarmas que se
activarán de acuerdo con umbrales predefinidos.
 Tipos de umbrales:
◦ Valor absoluto: Se toman muestras y su valor se compara con un valor
fijo que se mantiene invariable (por ejemplo, número de usuarios de un
servidor).
◦ Valor relativo: Se toman muestras y su valor se compara con un valor
definido de acuerdo con una referencia (por ejemplo, porcentaje de uso
de un canal)
◦ Delta: Se toman muestras y su variación (muestra actual relativa a la
anterior) se compara con un valor fijo o relativo (por ejemplo, incremento
del número de usuarios por minuto).
 Los umbrales de tipo Delta son muy útiles cuando las muestras se
obtienen de una variable de tipo contador
GAR 1-49

 Métricas e Indicadores:
◦ Métrica: Es el valor asociado a una determinada característica de un
objeto.
 Para crear una métrica, se toman datos de una fuente.
◦ Indicador: Es una o más métricas que proporciona información profunda
de un objeto.
◦ Indicador clave de desempeño (KPI: Key Performance Indicator):
Indicadores que ayudan a medir el progreso en la consecución de un
objetivo
 Ejemplo métricas (youtube) Ejemplo indicadores:

◦ Total de reproducciones en un canal % de reproducciones que provienen de redes sociales
◦ Nuevas reproducciones en un canal Tipo de contenido por fuente de tráfico
◦ Total de suscriptores de un canal Total suscriptores activos (> 1 conexión por día)
◦ Nuevos suscriptores de un canal ……
◦ Fuente de tráfico
GAR 1-50 ◦ ….
 En muchas métricas e indicadores se puede evaluar su valor actual,

valor máximo, valor medio, o el valor con un percentil.
◦ Valor con un percentil n: El n% de las muestras están por debajo del valor
indicado. Ejemplo: utilización de un canal
 Ejemplo:
Umax 8,15 Gbps
Up95 5,5 Gbps
Um 3,7 Gbps
◦ UP95 (utilización con un percentil del 95%): El 95% de las muestras tiene un
GAR 1-51 valor inferior a 5,5 Gbps

 Ejemplo de indicadores relacionados con el rendimiento de una red:
◦ Capacidad nominal del canal: Máxima capacidad teórica del medio de
transmisión (b/s).
◦ Capacidad efectiva de un canal: Capacidad máxima real del medio de
transmisión (b/s).
◦ Utilización de un canal: Fracción de la capacidad nominal de un canal que
se está usando.
◦ Retardo extremo-extremo: Tiempo transcurrido desde que se envía un
paquete en origen, hasta que llega a destino.
◦ Variación del retardo (jitter): Fluctuación del retardo extremo-extremo.
◦ Paquetes perdidos o erróneos: (PER: Packet Error Rate): Paquetes que ha
sido necesario retransmitir.
◦ …(otros)……….
LATENCIA
MINIMA
LATENCIA
LATENCIA DESCARTE
GAR 1-52 MAXIMA
 Ejemplo de indicadores relacionados con el rendimiento de un sistema:
◦ Disponibilidad: Tiempo que el sistema ha estado disponible, proporcionando
el servicio para el que fue diseñado.
◦ Utilización:
◦ Tiempo de respuesta: Fracción de tiempo desde que se realiza una
petición, hasta que llega el resultado.
◦ Carga: Nivel de capacidad de trabajo que tiene ocupado el sistema.
◦ Frecuencia de fallo de página: Número de fallos de página en un periodo
determinado (en un sistema de memoria virtual paginada)
◦ …(otros)…………
GAR 1-53
1.4 Estándares de gestión de red

1234
 Inicialmente, se especificó el modelo de arquitectura OSI y se definió

una arquitectura de mantenimiento, adecuada.
 Simultáneamente, la arquitectura DoD (TCP/IP) se fue estableciendo

como estándar de facto, desarrollándose protocolos para abordar el
mantenimiento.
 Ello da lugar a dos estándares de mantenimiento:

◦ OSI Systems Management: Definida en el contexto de la arquitectura
OSI de ISO. Hoy día en desuso.
◦ Internet Network Management: Definida en el contexto de la
arquitectura DOD (TCP/IP).
GAR 1-54
Estándares de la gestión de red
OSI Systems Management 1234
 El OSI Management systems recoge un conjunto de estándares de la

ISO orientados al mantenimiento de los sistemas abiertos
interconectados.
 Incluye la definición de los servicios, protocolos, información
intercambiada y funcionalidades
 Modelo general:
Sistema de Sistema
mantenimiento
mantenido
mantenidos
Objetos
Manager Intercambio de
información de Agente
mantenimiento
GAR 1-55

 Existe una base de datos (Management Information Base: MIB) que almacena
información de los objetos mantenidos y sus atributos. Para acceder a ella se
usa el protocolo CMIP (Common Managenent Information Protocol)
Systems management application process

Systems-management
interface
System-management
LME
application entity
LME Presentation layer CMIP
LME Session layer

Management
information LME Transport layer
base LME Network layer
LME Data-link layer
LME Physical layer

Layer-management
interface
GAR 1-56 Layer-management entity
 CMIP (Common Managenent Information Protocol) Es el protocolo de

aplicación.
 Principales características de CMIP:

◦ Es un protocolo orientado a la conexión. La comunicación con los agentes se realiza
sobre una conexión previamente establecida
◦ Es un protocolo confirmado: El protocolo asegura que los mensajes llegan a su destino
◦ El agente es responsable de monitorizar los recursos que controla
◦ El agente notifica la existencia de errores o incidencias en los recursos que gestiona.
 Tipos de servicio: CMIP proporciona tres tipos de servicio:

◦ Manejo de datos
◦ Informe de sucesos
◦ Control
GAR 1-57

 Los tres tipos de servicio se implementan con los siguientes elementos

de servicio:
◦ M-CREATE: Crea una instancia de un objeto gestionado.
◦ M-DELETE: Elimina una instancia de un objeto gestionado.
◦ M-GET: Solicita el valor de un atributo de una instancia de un objeto
gestionado.
◦ M-SET: Fija el valor de un atributo de una instancia de un objeto gestionado.
◦ M- ACTION: Solicita una acción en el objeto gestionado.
◦ M-EVENT_REPORT: El agente informa de un error o notificación.
Recursos
Managing process Agent process gestionados
CMIP
Capa 7 OSI Capa 7 OSI
OSI OSI MIB

GAR 1-58
Arquitectura TCP/IP 1234
 El modelo DoD lleva asociado un protocolo de gestión, denominado SNMP

(Simple Network Management Protocol), que incluye:
◦ Estación de mantenimiento
◦ Agente de mantenimiento
◦ Base de datos de información de mantenimiento (MIB)
◦ Protocolo de mantenimiento
 SNMP se tratará con detalle en temas posteriores
GAR 1-59
TEMA
MEJORA DE LA
DISPONIBILIDAD DE SISTEMAS
Contenidos
 Tema 2: Mejora de la disponibilidad de sistemas

1. Introducción
2. Disponibilidad de sistemas
3. Protocolos de red
 Prácticas:
◦ Práctica 1: Mejora de la disponibilidad con ST
◦ Práctica 2: Mejora de la disponibilidad con HSRP
GAR 2-2
2.1
Introducción
 El funcionamiento de un dispositivo puede verse alterado por fallos en

cualquier componente y el fallo de un dispositivo puede afectar a la red
completa.
 Por tanto, es fundamental que los sistemas más críticos tengan una alta
disponibilidad, de forma que se minimice su probabilidad de fallo.
 Para mejorar la disponibilidad de un sistema, se pueden usar:

◦ Equipos redundantes, de forma que si uno falla, otro tome el control.
◦ Protocolos que detecten el fallo y reconfiguren la red para aislarlo
◦ Generalmente, se usan ambas
Patrón típico de fallos de un sistema:
GAR 2-3
Introducción
Los principales riesgos que pueden provocar fallos son

 Accidentales:
◦ Desastres naturales: vendavales, sismos, rayos, etc.
◦ Incendios.
◦ Inundaciones.
◦ Averías en los equipos.
◦ Averías en las instalaciones eléctricas o de suministro.
◦ Averías en la climatización.
◦ Errores de explotación.
 Intencionados:
◦ Robo de elementos del equipo.
◦ Robo de información.
◦ Sabotajes y atentados
 Mediante la implantación de dispositivos y equipos redundantes (en el

mismo local u otro), es posible mejorar la disponibilidad y reducir el riesgo
GAR 2-4
2.2 Disponibilidad
Cálculo de la disponibilidad
La disponibilidad de un sistema según porcentaje, puede definirse como:
𝑇𝑖𝑒𝑚𝑝𝑜_𝑓𝑢𝑛𝑐𝑖𝑜𝑛𝑎𝑚𝑖𝑒𝑛𝑡𝑜
𝐷 %
𝑇𝑖𝑒𝑚𝑝𝑜_𝑚𝑒𝑑𝑖𝑑𝑜
Número Disponibilidad Minutos Minutos no Tiempo
de ‘9’ (%) Disponible disponible anual no
(año) (año) disponible
1 90,0000% 473.364 52.596 36,5 días
2 99,0000% 520.700,4 5.259,6 3,5 días
3 99,9000% 525.434,0 525,96 8,5 horas
4 99,9900% 525.907,4 52,596 1 hora
5 99,9990% 525.954,7 5,2596 5 minutos
6 99,9999% 525.959,5 0,52596 32 segundos
* ( 1 año = 525.600 minutos)

GAR 2-5
Disponibilidad
La disponibilidad de un sistema según el tiempo medio entre fallos (MTTF:

Mean Time To Failure) se define como:
𝑀𝑇𝐵𝐹
𝑀𝑇𝑇𝐹 𝐴
𝑀𝑇𝐵𝐹 𝑀𝑇𝑇𝑅
Dónde:
◦ MTBF (Mean Time Between Failure): Tiempo medio que transcurre entre dos
fallos de un sistema
◦ MTTR (Mean Time To Repair): Tiempo medio de reparación del sistema
Ejemplo: Un sistema tiene un tiempo medio entre fallos (MTBF) de

20.000 horas y cuando falla, el tiempo medio de reparación es de 6 horas.
¿Cuál es sus disponibilidad?
∗
𝐴 0,9997  99,97%
∗
GAR 2-6
Disponibilidad
La confiabilidad de un sistema (reliability) es la probabilidad de que pueda

realizar sus funciones en un tiempo establecido.
La confiabilidad puede obtenerse a partir del tiempo medio entre fallos

(MTBF) de la forma
𝑅𝑒𝑙𝑖𝑎𝑏𝑖𝑙𝑖𝑡𝑦 𝑒
GAR 2-7
Disponibilidad
Incremento de la disponibilidad
¿Cómo puedo incrementar la disponibilidad?:

◦ Introduciendo redundancia:
 Si un componente falla, otro puede asumir sus tareas hasta que se repare.
 En la mayoría de los casos, es necesario un protocolo que gestione la
redundancia.
◦ Realizando un diseño modular:
 Si un componente falla, reduzco el tiempo de reparación (MTTR)
sustituyendo módulos completos.
 El diseño modular es efectivo hasta un cierto límite.
GAR 2-8
Disponibilidad
Sistemas compuestos
Disponibilidad de ‘n’ componentes en serie de disponibilidad Aci:
A1 A2 An 𝐴 𝐴
 Si todos tiene la misma disponibilidad (A):

𝐴 𝐴
Disponibilidad de ‘n’ componentes en paralelo de disponibilidad Aci:

A1
A2
An
𝐴 1 1 𝐴
◦ En el caso de dos componentes en paralelo con la misma disponibilidad (A):

𝐴 1 1 𝐴 1 𝐴 𝟐𝑨 𝑨𝟐
◦ En el caso de tres componentes en paralelo con la misma disponibilidad (A)
GAR 2-9 𝐴 1 1 𝐴 𝑨𝟑 𝟑𝑨𝟐 𝟐𝑨
Disponibilidad
Sistemas compuestos
Pasos para calcular la disponibilidad de un sistema complejo:

1. Reducir la complejidad, obteniendo la disponibilidad de los componentes
en paralelo
2. Obtener la disponibilidad de todos los componentes serie
A1 A3
A1||1 A2 A3||3
A1 A2 A3
𝐴 2𝐴 𝐴 ∗ 𝐴 ∗ 2𝐴 𝐴
Como A≤1:
 Añadir componentes en serie disminuye la disponibilidad
 Añadir componentes en paralelo incrementa la disponibilidad
GAR 2-10
Disponibilidad
Sistemas compuestos
Ejemplo: Considerar un switch modular compuesto por:

◦ 2 fuentes de alimentación (cada una con disponibilidad AF)
◦ 1 tarjeta supervisora (con disponibilidad As)
◦ 2 tarjetas con interfaces de comunicaciones (Cada una con Ai)
¿Cual es la disponibilidad del dispositivo?
AF AF Fuente de alimentación con disponibilidad AF
As Supervisora y resto de componentes con disponibilidad As
AI AI Interfaces de comunicaciones con disponibilidad AI
AF
AF As Ai Ai 𝐴 1 1 𝐴 1 𝐴 ∗𝐴 ∗𝐴
GAR 2-11
Disponibilidad
Sistemas compuestos
En los sistemas compuestos reales, es habitual que exista dependencia

entre componentes, de forma que si uno falla, el resto no funciona.
Ejemplo de dependencia típica en un dispositivo de red:
GAR 2-12
Disponibilidad
Redes
Para calcular la disponibilidad de una red, se pueden usar los mismos

criterios vistos anteriormente, teniendo en cuenta que los componentes
son los terminales, dispositivos de red y los enlaces.
 Es importante tener en cuenta que puede haber múltiples escenarios,

según el par origen-destino y la ruta de datos
 Ejemplo: La disponibilidad de una conexión entre T1 y T2 es distinta que
entre T1 y T3
C1 PC2 C2 PC2
OT T3
T1
T2
S1 R1 R2 S2
GAR 2-13
Disponibilidad
Redes
 Ejemplo:
C1 PC2 C2 PC2
OT T3
T1
T2
S1 R1 R2 S2
T4
 Establecimiento de comunicación entre dos extensiones del mismo edificio de
la empresa (T1 y T2)
T1 S1 C1 T2 𝐴 𝑇 ∗𝑆 ∗𝐶 ∗𝑇
 Establecimiento de comunicación entre dos extensiones del mismo edificio de

la empresa (T1 y T2). Se considera que C1 y C2 son redundantes. Si falla C1,
controla la comunicación C2
C1
T1 S1 T2
R1 R2 S2 C2
GAR 2-14
2.3 Protocolos
Introducción
 En una red, no basta con añadir redundancia en algunos dispositivos
físicos o en algunos enlaces. También es importante incorporar
protocolos que gestionen los recursos replicados, en caso de fallos.
 En la capa 3, los procedimientos de encaminamiento dinámico ayudan a

evitar errores en la red
GAR 2-15
2.3 Protocolos
Introducción
 En una red conmutada (de capa 2), para que los dispositivos se
comuniquen con otra VLAN o con otra subred necesitan la existencia
de un dispositivo de capa 3 que actúe como puerta de enlace (gateway
por defecto). Además, todo los terminales necesitan conocer la
dirección IP del Gateway por defecto.
 Si el dispositivo que implementa la puerta de enlace falla, toda la subred
quedará desconectada.
 Por tanto, será necesario replicar la puerta de enlace y disponer de

algún protocolo que gestione la existencia de varias puertas de enlace
de forma transparente a los terminales.
GAR 2-16
Protocolos
STP
 En la capa 2, el procedimiento de encaminamiento de los puentes
(switch) no permite la existencias de bucles en la red, por lo que el fallo
en un enlace puede provocar que parte de la red quede desconectada.
 Una solución es disponer de enlaces redundantes y mantenerlos

desactivados mientras que no sean necesarios. Cuando se produzca un
error, se reconfigurará la red haciendo uso de los que tenia
desactivados. Eso lo hace el protocolo spanning tree
GAR 2-17
Protocolos
STP
 En una red de capa 2, es interesante poner enlaces redundantes para
mejorar la fiabilidad, pero el encaminamiento en la capa 2 puede fallar si
hay bucles en la red.
Destino Puerto Destino Puerto
F P1 F P1
F P2 F P2
p2 p2
…… …… …… ……
p1 p1
 Para evitar los bucles en la capa 2, se puede usar el protocolo

Spanning-tree Protocol (STP), normalizado en IEEE 802.1D
 STP bloquea algunos puertos de los dispositivos de capa-2 para eliminar
bucles.
 Si hay bucles controlados por STP, en caso de fallo de un enlace, el
protocolo reconfigura la red automáticamente para ofrecer una ruta a la
GAR 2-18 que no le afecte el fallo.
Protocolos
STP
 Por tanto, STP es un protocolo que elimina los bucles a nivel de capa
2 para que el procedimiento de encaminamiento correctamente.
 Posibles topologías sin bucles (hay más)
GAR 2-19
Protocolos
STP
Funcionamiento de STP:
 Todo switch tiene un BID (Bridge Identificator) de 8 bytes (2 bytes de
prioridad y 6 de MAC). La prioridad por defecto es 32788 (8014H).
 El switch con BID menor se convierte en raíz del árbol
 Se puede averiguar el BID de un switch con #show spanning-tree
 Se puede modificar el valor del BID alterando la prioridad, mediante el

comando (config)#spanning-tree vlan n priority p
GAR 2-20
Protocolos
STP
 Todo puerto tiene un costo por defecto, según su velocidad. Puede ser
modificado con $(config-if)#spanning-tree cost nn)
 El costo de una ruta es la suma de los costos de puerto de todos los

enlaces, de un switch a otro.
 En cada switch no raíz siempre habrá puerto raíz que está en la ruta
de menor costo para llegar al switch raiz
 En cada enlace, siempre habrá un puerto designado, que será el que
esté en el switch que tenga la ruta de coste más bajo hacia el switch
raíz.
 El árbol de expansión estará formado por las rutas de menos costo,
tomando como raíz el dispositivo con menor BID
 Periódicamente, STP comprueba que el árbol es correcto
GAR 2-21
Protocolos
STP
 Usando el comando #show spanning-tree, es posible conocer cual es la

MAC del switch que actúa como raíz y el costo de la ruta actual para
llegar a él. También el estado de los puertos del dispositivo
GAR 2-22
Protocolos
STP
SW0
SW1 SW2 SW3
GAR 2-23
Protocolos
STP
 Ejemplo típico de uso de STP: incorporar redundancia en la red de capa
2 y así mejorar la fiabilidad, siendo STP responsable de reconfigurar la
red en caso de fallo
X
X
X
GAR 2-24
Protocolos
RSTP / MSTP
 Una evolución de Spanning Tree es RSTP (Rapid Spanning Tree

Protocol). La principal diferencia respecto de ST es que la convergencia
de la red frente a un cambio de topología es mucho más rápida. La
selección del nodo raíz y el cálculo del coste de rutas es igual que en
ST.
 RSTP está definido en IEEE 802.1W y es compatible con IEEE 802.1D.

La principal diferencia está en la implementación del protocolo de
reconfiguración
 Otra evolución de Spanning Tree es MSTP (Multiple Spanning Tree

Protocol). Se trata de realizar un ST sobre cada VLAN, generándose
tantos árboles de expansión como VLANs existan en la red.
 MSTP Está normalizado en IEEE 802.1s (añadido a IEEE 802.1q)

GAR 2-25
Protocolos
MSTP
Permit VLAN10 VLAN20
VLAN all
Permit
Permit VLAN 20,30,40
VLAN 10,20
Permit
VLAN 20,40
VLAN30 VLAN40
GAR 2-26
Protocolos
Redundancia en la puerta de enlace
 Un elemento crítico de una red es la puerta de enlace (gateway de la
subred). Si el dispositivo que la implementa falla, toda la subred
quedará desconectada.
• Por tanto, para mejorar la

disponibilidad de la red es muy
importante introducir
redundancia en la puerta de
enlace.
 Los protocolos First Hop Redundancy Protocol (FHRP) permiten

gestionar varias puertas de enlace de forma transparente a los
dispositivos de capa 2 a los que les dan servicio, gestionando una MAC
virtual que nos representa. Los principales son:
◦ HSRP (Hot Standby Router Protocol)
◦ VRRP (Virtual Router Redundancy Protocol)
◦ GLBP (Gateway Load Balancing Protocol)
GAR 2-27
Protocolos
FHRP
 Los protocolos First Hop Redundancy Protocol (FHRP) permiten gestionar
varias puertas de enlace de forma transparente a los dispositivos de capa
2 a los que les dan servicio, gestionando una MAC virtual que nos
representa
 En algunos casos, también pueden gestionar el uso simultáneo de varias

puertas de enlace
 Algunos protocolos FHRP son:

◦ HSRP (Hot Standby Router Protocol)
◦ VRRP (Virtual Router Redundancy Protocol)
◦ GLBP (Gateway Load Balancing Protocol)
GAR 2-28
Protocolos
HSRP
 HSRP (Hot Standby Router Protocol)
◦ Proporciona un mecanismo para disponer de un router lógico (o sw-l3)
por defecto, usando un grupo de router físicos.
◦ Se basa en que un grupo de routers físicos comparten una dirección IP
virtual y una MAC virtual
◦ Uno de los dispositivos físicos permanece activo, respondiendo a la
IP/MAC virtuales y el resto permanecen a la espera, por si falla el activo,
sustituirlo.
Routers
Router reserva
activo
GAR 2-29
Protocolos
HSRP
◦ Los clientes configuran como puerta de enlace al dispositivo virtual
◦ Estado en que pueden estar los routers:

 Activo: Es el router físico que tiene asignada la IP/MAC virtual y que está
actuando como puerta de enlace
 Espera (Standby): Está preparado para asumir el papel de activo, si éste falla.
 Escucha (Listen): Si hay más de 2 routers, el resto están escuchando los
mensajes de control (estado listen), por si falla el standby, asumir su rol
GAR 2-30
Protocolos
HSRP
◦ Cuando varios routers forman parte de un grupo HSRP, participan en
un proceso de elección, asumiendo el rol de ‘activo’ el que tenga
mayor prioridad y si hay varios con la misma prioridad, se selecciona
como activo el que tenga la IP mayor (la prioridad por defecto es 100)
◦ Periódicamente, se envían mensajes de control (Hello), para
comprobar que existe un router activo y uno en espera (standby)
◦ Cuando el router activo desaparece, el que está en espera (standby)
pasa a ser el activo y se inicia un proceso de elección para elegir un
nuevo standby, entre el resto disponible (que están en estado listen)
◦ El comportamiento puede cambiar con la opción de preferencia
(preempt).
GAR 2-31
Protocolos
HSRP
 También es posible tener más de un grupo HSRP (multigrupo) y que
cada grupo tenga un dispositivo activo. De esa forma, se balancea la
carga entre las puertas de enlace y a su vez, mantienen la redundancia
por si hay fallos.
El router A es el activo para la VLAN2

y el router B es el activo para la VLAN3
El router B es el standby para la VLAN2

Y el router A es el standby para la VLAN 3
 VRRP (Virtual Router Redundancy Protocol) es similar a HSRP, que está

GAR 2-32 definido en la RFC 2338.
Protocolos
HSRP
 Ejemplo de configuración de HSRP en dispositivos CISCO
◦ Se desea que los tres routers formen un grupo HSRP que reconozca la
dirección IP 192.168.1.1; que el router 1 asuma el rol de activo
◦ Es necesario configurar los interfaces de cada router, pero añadiendo la
asignación a un grupo HSRP y el rol que juega ese interfaz dentro del grupo.
GAR 2-33
Protocolos
HSRP
 Router 1
Router1(config)#interface g0/0
Router1(config-if)#ip address 192.168.1.2 255.255.255.0 Router1(config)#interface g0/1
Router1(config-if)#standby 1 ip 192.168.1.1 Router1(config-if)#ip address 192.168.2.2 255.255.255.0
Router1(config-if)#standby 1 priority 120 Router1(config-if)#standby 2 ip 192.168.2.1
Router1(config-if)#standby 1 preempt Router1(config-if)#standby 2 priority 120
Router1(config-if)#no shutdown Router1(config-if)#standby 2 preempt
Router1(config-if)#no shutdown
 Router 2:
Router2(config)#interface g0/0 Router2(config)#interface g0/1
Router2(config-if)#ip address 192.168.1.3 255.255.255.0 Router2(config-if)#ip address 192.168.2.3 255.255.255.0
Router2(config-if)#standby 1 ip 192.168.1.1 Router2(config-if)#standby 2 ip 192.168.2.1
Router2(config-if)#no shutdown Router2(config-if)#no shutdown
 Router 3:
Router3(config)#interface g0/0 Router3(config)#interface g0/1
Router3(config-if)#ip address 192.168.1.4 255.255.255.0 Router3(config-if)#ip address 192.168.2.4 255.255.255.0
Router3(config-if)#standby 1 ip 192.168.1.1 Router3(config-if)#standby 2 ip 192.168.2.1
Router3(config-if)#no shutdown Router3(config-if)#no shutdown
GAR 2-34 (el comando ‘#standby 1 preempt’ es necesario para que se lance un proceso de comprobación de prioridades)
Protocolos
HSRP
GAR 2-35
Protocolos
HSRP
GAR 2-36
Protocolos
GLBP
GLBP (Gateway Load Balancing Protocol)

 Un grupo de routers o sw-L3 comparte una dirección IP virtual y múltiples MACs
virtuales
 Todos los dispositivos permanecen activos y encaminan paquetes, de acuerdo con el
tráfico que les llega, según la MAC asignada
 La MAC virtual puede asignarse con tres criterios:
◦ Round Robin
◦ Pesos
◦ Según MAC del host
 Los clientes ven una IP virtual
y varias MACs virtuales
GAR 2-37
Protocolos
GLBP
GLBP (Gateway Load Balancing Protocol)

Paso 1: Paso 2:
Paso 3: Paso 4:
GAR 2-38
Protocolos
IP SLA
 SLA (Service Level Agreement) es una característica que incorporan algunos
dispositivos de red mediante la cual, es posible obtener de forma
automatizada información sobre algunos parámetros de rendimiento de la
red.
 CISCO implementa IP-SLA que genera tráfico IP y analiza su
comportamiento en la red, dando información sobre conectividad o
rendimiento.
 Ejemplo:
GAR 2-39
Protocolos
IP SLA
 La funcionalidad de IP SLA depende del nivel de implementación de cada
dispositivo. Por ejemplo, en los switch CISCO 3750 (lab Hardware-2)
puede proporcionar información sobre:
◦ DHCP PATH-ECHO
◦ DNS JITTER-ECHO
◦ FTP TCP-CONNECT
◦ HTTP UDP-ECHO
◦ ICMP-ECHO UDP-JITTER
 Configuración de IP SLA:
1. Habilitar el respondedor IP SLA, si fuera necesario
2. Configurar el tipo de operación y opciones
3. Configurar opciones de umbrales, si fueran necesarias
4. Planificar la operación
5. Visualizar e interpretar los resultados
GAR 2-40
Protocolos
IP SLA
 Ejemplo: Se desea comprobar cada 30 segundos que el dispositivo
remoto 192.168.139.134 está activo
Switch(config)# ip sla 12
Switch(config-ip-sla)# icmp-echo 192.168.139.134
Switch(config-ip-sla-echo)# frequency 30
Switch(config-ip-sla-echo)# exit
Switch(config)# ip sla schedule 5 start-time now life forever
Switch(config)# end
 Ejemplo: Se desea controlar el jitter en una conexión UDP con un
equipo remoto
Switch(config)# ip sla 1
Switch(config-ip-sla)# udp-jitter 192.168.1.2 65000 num-packets 20
Switch(config-ip-sla-jitter)# request-data-size 160
Switch(config-ip-sla-jitter)# frequency 30
Switch(config-ip-sla-jitter)# exit
Switch(config)# ip sla schedule 1 start-time after 00:05:00
Router(config)# ip sla responder
 Es posible comprobar la configuración de IP SLA y obtener

estadísticas de su ejecución con los comandos
◦ albacete#show ip sla configuración num
◦ albacete#show ip sla statistics
GAR 2-41
Protocolos
IP SLA
 En el cliente se almacenan los resultados, que pueden recuperarse
mediante comandos CLI o de forma remota
 También hay aplicaciones (monitores IP SLA) que representan los

resultados obtenidos
GAR 2-42
TEMA 3
ADMINISTRACION DE
RECURSOS Y DISPOSITIVOS DE
RED
Contenidos
 2.1 Introducción
 2.2 Tareas básicas de administración de recursos
 2.3 Administración de servicios: directorio
 2.4 Administración global
 2.5 Administración de dispositivos de red
GAR 3-2
1. Introducción
 Una red de computadores está compuesta por :

◦ Una red de comunicaciones (dispositivos de red y medios de
transmisión)
◦ Equipos terminales (ordenadores, periféricos, sensores, actuadores,…).
Algunos de ellos pueden proporcionar servicios a otros dispositivos de red.
Dispositivos de red
Medios de transmisión
Terminales
Terminales
Servicios
Servidores
 Generalmente, la administración de redes incluye a todos ellos.
GAR 3-3
2. Tareas básicas de administración de recursos

Tareas más habituales
 Algunas tareas de administración habituales son:

◦ Instalar y configurar nuevos equipos (ordenadores, dispositivos de red, etc.)
◦ Administrar los sistemas operativos de los dispositivos conectados
◦ Configurar y administrar las aplicaciones y/o servicios
◦ Monitorizar el funcionamiento de los dispositivos y servicios
◦ Proporcionar soporte al usuario (CAU).
◦ Administrar los espacios de almacenamiento (discos locales, espacios
compartidos, etc.) y mantener copias de respaldo.
◦ Etc.
GAR 3-4
Tareas básicas de administración de recursos
Soporte al usuario
 El soporte al usuario puede proporcionarse por distintos canales
(telefónico, web, etc.).
 El Centro de Atención a Usuario (CAU) es un portal (canal web) en el
que se solicita e informa sobre los servicios que proporciona una red
corporativa.
◦ Proporciona al usuario un canal para notificar incidencias, comunicar quejas, etc.
◦ Permite al usuario conocer el estado de resolución de sus incidencias.
◦ Facilita la gestión de las incidencias, al estar todas centralizadas
◦ Facilita el archivo de las incidencias y su procedimiento de resolución, al estar
todas almacenadas.
 El CAU se organiza internamente en varios niveles.
GAR 3-5

Soporte al usuario
◦ Primer nivel:
 Se registra la incidencia.
 Si ha ocurrido previamente y está documentada, se aplica la misma solución y se cierra.
 Si no ha ocurrido previamente y se puede resolver, se resuelve y se documenta.
 Si no pueden resolver, se escala al nivel superior.
 Ejemplo: me ha caducado la contraseña y no puedo acceder a mi email
◦ Segundo nivel:
 Se atienden incidencias más complejas, escaladas desde el primer nivel
 Si dependen del equipo del usuario, si es posible se resolverán por control remoto para evitar
el desplazamiento de los técnicos
 Si no se puede resolver a este nivel, se escala al nivel superior.
◦ Tercer nivel:
 Se atienden las incidencias que afectan a un servicio completo (no a un usuario). Suelen ser atendidas
por el responsable del servicio.
 Si el servicio es externo y está subcontratado, se remite la incidencia al proveedor.
 Ejemplo: Distintos usuarios indican que el campus virtual se interrumpe periódicamente.
◦ Periódicamente se debe supervisar el estado de ejecución de todas las incidencias,

GAR 3-6 emitiendo informes semanales o mensuales, que deberían ser públicos.
Soporte al usuario
 Existen muchas herramientas (comerciales y basadas en software libre)

para gestionar incidencias. Por ejemplo:
 Ejemplo UCLM
GAR 3-7

Administración de recursos en red
 Hay varios aspectos muy importantes

◦ Los recursos deben ser monitorizados para registrar el nivel de servicio que
proporcionan (SLA: Service Level Agreement)
◦ Los recursos deben estar organizados lógicamente, para facilitar las gestión en
grupos, roles, etc (Servicios de directorio)
◦ La gestión de los recursos debe ser en grupo y automatizada, siempre que sea
posible
• Despliegue de aplicaciones
• Gestión centralizada de
aplicaciones y recursos
• Impresión corporativa
• Control de acceso centralizado
• …
• Etc.
GAR 3-8
Rendimiento y confiabiliad
 Los sistemas operativos de los dispositivos incorporan un conjunto de
herramientas propias que permiten administrar sus distintos
componentes hardware y software.
 Para evaluar su funcionamiento, se suele distinguir entre rendimiento y

confiabilidad:
◦ Rendimiento: Es un indicador del nivel de servicio proporcionado por
un sistema, relativo al máximo servicio que puede proporcionar según sus
características.
◦ Confiabilidad: Es un indicador que hace referencia al % de tiempo que un
sistema funciona de acuerdo con su configuración, proporcionando el
rendimiento esperado.
 En un servidor en red, es muy importante supervisar ambos aspectos en

todos los componentes fundamentales, para que proporcione el servicio
esperado durante el máximo de tiempo posible (máximo rendimiento
GAR 3-9 con máxima confiabilidad).

Rendimiento y confiabilidad
 La supervisión del rendimiento y de la confiabilidad puede hacerse de
distintas formas:
 En cuanto al uso de herramientas:

 Propias del sistema operativo del dispositivo
 De terceros
 En cuanto a localidad:
 Monitorización local
 Monitorización remota
 También facilitan la monitorización de los sistemas, los archivos del

registro de eventos (logs) generados por los propios sistemas.
GAR 3-10
 Ejemplo Windows: La herramienta “administrador de tareas” proporciona
parámetros de rendimiento de CPU, memoria, disco, red, GPU en un servidor
conectado a red
GAR 3-11

 Ejemplo Windows: La herramienta Monitor de recursos proporciona
información más detallada sobre uso de procesador, memoria, disco y red),
pudiendo desagregarla por proceso.
GAR 3-12
 Ejemplo Windows: El Monitor de rendimiento permite agregar variables
que se desean monitorizar del equipo local o de uno remoto, haciendo
un seguimiento de ellas.
GAR 3-13

 Al usar el monitor de rendimiento de Windows, puede definirse un conjunto
de recopiladores de datos, que van obteniendo datos que se almacenan en
archivos log para ser analizados posteriormente.
 Windows tiene predefinidos dos conjuntos de recopiladores de datos por

defecto: system diagnostics y system performance.
GAR 3-14
 Ejemplos de otros conjuntos de recopiladores útiles:
◦ Supervisión de la utilización de la memoria :
 Memoria/kBytes disponibles El número de bytes confirmados no debería ser
 Memoria/Bytes confirmados superior al 75% del total de memoria física
 Memoria/Errores de páginas
 Memoria/Entrada de páginas Si el número de errores es alto, sería recomendable
aumentar memoria o disminuir cache
 Memoria/Salida de páginas
 Memoria/Bytes de bloque paginado Si el tamaño del bloque paginado es grande

 Memoria/Bytes de bloque no paginados comparado con la memoria física, sería recomendable
añadir memoria
◦ Supervisión de uso del procesador:
Si es mayor que 2 de forma constante, es
 Cola de subprocesos
recomendable actualizar los procesadores o añadir más.
Si es alto mientras que el trafico de red o de E/S es
 Procesador/% de uso del procesador relativamente bajo, es recomendable actualizar los procesadores
◦ Supervisión de general de las unidades: o añadir más.
 Disco físico/%de tiempo de disco Si %de tiempo de disco es elevado mientras que %de tiempo
 Procesador/% de tiempo de procesador de procesador no lo es, hay cuello de botella en discos
 Interfaz de red/Total de bytes
◦ Supervisión de E/S:
 Disco físico/Escrituras en disco/s
 Disco físico/Lecturas en disco/s
 Disco físico/Longitud promedio de la cola de escritura en disco
 Disco físico/Longitud promedio de la cola de lectura en disco
 Disco físico/Longitud de la cola actual de disco
GAR 3-15

 En el monitor de rendimiento, también es posible crear alertas basadas en
parámetros, de forma que se generará un evento cuando se cumpla la
condición especificada (por ejemplo, uso del procesador superior al 80%
durante 10 minutos)
GAR 3-16
 Ejemplo Windows: El monitor de confiabilidad calcula la confiabilidad del
sistema, registrando los principales eventos que han afectado a la
misma. Representa el histórico del índice de estabilidad o confiabilidad)
GAR 3-17

 También existen numerosas herramientas de terceros. Por ejemplo
NAGIOS (monitorización de servidor windows, servidor Linux,
impresora y switch)
GAR 3-18
 También existen herramientas y/o tecnologías especificas para cada componente.

Por ejemplo: discos duros
 SMART (Self Monitoring Analysis and Reporting Technology) es una tecnología que
incorpora la mayoría de los discos duros mecánicos, que permite monitorizar un
conjunto de parámetros relacionados con su rendimiento y fiabilidad. Por ejemplo:
◦ Temperatura del disco  Un aumento puede ser indicador de fallo interno
◦ Velocidad de lectura de datos  Una reducción puede ser indicador de fallo interno
◦ Tiempo de partida (spin-up)  Variaciones de este tiempo puede ser indicador de fallo
interno
◦ Contador de sectores reasignados:  Un incremento puede ser indicador de que el disco va
a fallar
◦ Velocidad de búsqueda (seek time)  Una reducción puede ser indicador de fallo interno
◦ Altura de vuelo del cabezal  Una reducción puede ser indicador de fallo interno
◦ Uso de error-correcting code (ECC)  Un aumento puede ser indicador de un próximo
fallo.
GAR 3-19

 En Windows hay numerosas herramientas de terceros que permiten
monitorizar discos duros usando SMART.
GAR 3-20
Administración de almacenamiento local
 Los sistemas RAID (Redundant Array of Independent Disk) tienen dos
ventajas principales:
◦ Mejoran el rendimiento: En algunas configuraciones, los datos están distribuidos entre
varios discos, por lo que se pueden leer bloques en paralelo
◦ Mejoran la disponibilidad: En algunas configuraciones los datos están replicados en varios
discos, o bien existen bloques de paridad, que permiten recuperar datos dañados.
 Existen distintas configuraciones:
◦ RAID 0 (Stripping): Los datos se distribuyen por bloques en varios discos.
 La lectura de datos es más rápida. La escritura de datos es más rápida
 Si un disco falla, se pierden los datos. No aumenta la fiabilidad
◦ RAID 1 (Mirroring): Un disco es espejo del otro..
 La lectura de datos es más rápida. La escritura de datos no se incrementa
 Si un disco falla, se continúa teniendo acceso a todos los datos
Bloque 1 Bloque 2 Bloque 1 Bloque 1


GAR 3-21 RAID 0 RAID 1

◦ RAID 1+0 (también conocido como RAID 10). Es una combinación de los dos
anteriores. Los datos se replican en varios discos y su vez, se distribuyen.
 La lectura de datos es más rápida. La escritura de datos es más rápida
 Si un disco falla, no se pierden los datos.
◦ RAID 2: Un bloque se distribuye entre varios discos distintos (stripping) y existe un

bloque de paridad por bloque. Todos los bloques de paridad se almacenan en el mismo
disco
Bloque 1a Bloque 1b Bloque 1c Paridad b1

GAR 3-22
bloque de paridad, que se distribuye entre los discos.
 La lectura de datos es más rápida
 Si un discos falla, se continúa teniendo acceso a todos los datos

Bloque 2a Bloque 2b Paridad b2 Bloque 2c
Bloque 3a Paridad b3 Bloque 3b Bloque 3c
Paridad b4 Bloque 4a Bloque 4b Bloque 4c

doble bloque de paridad, que se distribuye entre los discos.
 La lectura de datos es más rápida
 Si dos discos fallan, se continúa teniendo acceso a todos los datos
Bloque 1a Bloque 1b Paridad b1 Paridad b1

Bloque 2a Paridad b2 Paridad b2 Bloque 2b
Paridad b3 Paridad b3 Bloque 3a Bloque 3b

Paridad b4 Bloque 4a Bloque 4b Paridad b4
GAR 3-23

Protección de datos y copias de seguridad
 Copias de seguridad: Aunque se disponga de un sistema RAID, es necesario
disponer de copias de seguridad (backup) por varios motivos:
◦ Recuperar los datos en caso de desastres:
 Pérdida masiva de datos (por ejemplo, fallos hardware)
 Pérdida de datos de un usuario (por ejemplo, borrado accidental)
◦ Disponer de copias operacionales
 Mantener instantáneas periódicas del sistema, por si hay que revertir el
sistema a un estado previo (por ejemplo, cuando se actualiza software
crítico)
◦ Mantener copias reguladas para cumplir con normativas legales
 Cumplir leyes que exigen mantener almacenados datos históricos por
cierto tiempo (la LOPD, por ejemplo)
GAR 3-24
Métricas de recuperación:
 RPO (Recovery Point Objective): Instante temporal a partir del cual se dispone de
información y se puede recuperar. Mide la cantidad de datos (en tiempo) que
pueden perderse por una interrupción.
 RTO (Recovery Time Objective): Es el tiempo objetivo (máximo) que un equipo

estará fuera de servicio después de producirse un fallo o desastre.
◦ RTO es la suma de:
 T1: Tiempo que tarda en detectarse el fallo
 T2: Tiempo que se tarda en activar el tiempo de recuperación
 T3: Tiempo desde que se activa el plan de recuperación hasta que se
recupera totalmente.
GAR 3-25

 Los valores de RTO y RPO dependen, entre otras cosas, de la tecnología de
copia de seguridad
http://www.mainstream-tech.com/articles/protecting-data/
GAR 3-26
 Las copias de seguridad pueden realizarse de forma:
◦ Asíncrona: Se copian ficheros en ciertos instantes de tiempo.
 Uso de un soporte físico de copia de seguridad de una ubicación a otra.
Incrementa la seguridad ante un desastre de la ubicación local, pero el
tiempo de recuperación es elevado. Se pueden mantener dos juegos de
la misma copia: uno local y uno remoto
 Uso de la red para replicar los datos entre sedes (no en tiempo real).
 Uso de un centro de datos de seguridad externo.
◦ Síncrona (CDP, Continous Data Protection): Se mantiene en otro soporte

una copia sincronizada en tiempo real de los datos originales.
 Datos replicados en dispositivo local
 Datos replicados entre distintas sedes
 Datos replicados en un centro de datos de seguridad externo
GAR 3-27

 Granularidad de las copias de seguridad:
Copia(a=0/1)
◦ Completa: Se hace una copia de todos los archivos. a0
Diferencial: Sólo se hace una copia de los archivos que han sido Copia(a=1)
modificados desde la última copia de seguridad completa. Mantiene a
Incremental: Sólo se hace una copia de los archivos que han sido Copia(a=1)
modificados desde la última copia de seguridad completa o diferencial a0
GAR 3-28
 Modos de realización de la copia de seguridad:
◦ En frio (off-line):
 Las aplicaciones se detienen durante el proceso de copia de seguridad
◦ En caliente (on-line):
 Las aplicaciones continúan ejecutándose mientras se realiza la copia de
seguridad.
 Se establece un instante de tiempo y a partir de él se registran las
transacciones del sistema, pero no se materializan en los datos a
salvaguardar. Cuando finaliza la copia, se ejecutan las transacciones en el
orden de llegada
 Mientras se realiza la copia de seguridad, hay operaciones que no se
admiten en el sistema (por dependencia de datos, por ejemplo)
GAR 3-29

 Recuperación de datos a partir de una copia de seguridad incremental
◦ Es necesario restaurar el backup completo y todos los incrementales
posteriores
Dia Tipo
Lunes Completa
DATOS
Martes Incremental
Miércoles Incremental
Jueves Incremental
Viernes Incremental
 Recuperación de datos a partir de una copia de seguridad diferencial

◦ Es necesario restaurar el backup completo y el último diferencial
Dia Tipo
Lunes Completa
DATOS
Martes Diferencial
Miércoles Diferencial
Jueves Diferencial
Viernes Diferencial
GAR 3-30
 Las copias de seguridad importante guardarlas en ubicaciones
distintas de la que tiene el equipo (externalizarlas):
◦ Externalización física: Se usan soportes físicos y se guardan en
un lugar distinto del que se encuentra el servidor (custodia
externa de soportes).
◦ Externalización lógica: Se usa una red para llevar los datos a
un soporte físico remoto (cloud).
 En muchos casos, es habitual usar una solución mixta.
GAR 3-31

 ¿Qué dice la LOPD?
Art 94: Copias de seguridad y respaldo

1. Deberán establecerse procedimientos de actuación para la realización como mínimo semanal de copias
de respaldo, salvo que en dicho período no se hubiera producido ninguna actualización de los datos.
2. Asimismo, se establecerán procedimientos para la recuperación de los datos que garanticen en todo
momento su reconstrucción en el estado en que se encontraban al tiempo de producirse la pérdida o
destrucción.
3. Únicamente, en el caso de que la pérdida o destrucción afectase a ficheros o tratamientos parcialmente
automatizados, y siempre que la existencia de documentación permita alcanzar el objetivo al que se
refiere el párrafo anterior, se deberá proceder a grabar manualmente los datos quedando constancia
motivada de este hecho en el documento de seguridad.
4. El responsable del fichero se encargará de verificar cada seis meses la correcta definición, funcionamiento
y aplicación de los procedimientos de realización de copias de respaldo y de recuperación de los datos.
5. Las pruebas anteriores a la implantación o modificación de los sistemas de información que traten
ficheros con datos de carácter personal no se realizarán con datos reales, salvo que se asegure el nivel de
seguridad correspondiente al tratamiento realizado y se anote su realización en el documento de
seguridad.
Si está previsto realizar pruebas con datos reales, previamente deberá haberse realizado una copia de
seguridad.
GAR 3-32
 Arquitecturas de un sistema de backup
◦ DAS (Direct Attached Storage): Los dispositivos de almacenamiento se
conectan directamente al servidor
◦ NAS (Network Attached Storage): Existe un dispositivo compartido
de almacenamiento, compuesto por un servidor de backup y los
dispositivos físicos de almacenamiento
◦ SAN (Storage Area Network): Existe una red de altas prestaciones
que interconecta los dispositivos de almacenamiento con los
servidores
SAN
Clientes Servidor de backup Clientes Servidor de backup
GAR 3-33 Dispositivos de almacenamiento Dispositivos de almacenamiento

Arranque remoto
 A veces es necesario arrancar equipos remotos, conectados a la red.
Para ello, es posible usar WOL (Wake On LAN)
◦ Para usar WOL hay que configurar el equipo remoto para que admita
peticiones de arranque remoto y desde un cliente, enviarle un paquete
mágico WOL.
◦ Un paquete mágico WOL es un paquete de UDP dirigido al puerto 7 (ECHO),
enviado la dirección de difusión de nuestra subred, que contiene en el campo
de datos la dirección MAC (repetida 16 veces) del adaptador del ordenador
que se quiere arrancar. Este paquete IP se introduce en una trama enviada a
la dirección de difusión ff:ff:ff:ff:ff:ff:ff:ff.
◦ Cuando un adaptador de red está en modo standby y recibe un paquete
mágico cuya dirección MAC del campo de datos coincide con la suya propia,
activa una señal que comunica al sistema eléctrico que se inicie el ordenador
◦ Para usar WOL es necesario activarlo en la BIOS / UEFI
GAR 3-34
Congelación de equipos
 La congelación hace que cada vez que arranque el equipo, cargue una
imagen limpia preestablecida.
 Sus principales ventajas son:
◦ Reduce el mantenimiento de los equipos, pues siempre arrancan con una
imagen bien configurada.
◦ Evita que los cambios de configuración que haga el usuario sean permanentes.
◦ Elimina todo el software que instale el usuario.
◦ Etc.
 Estas herramientas:
◦ Pueden combinarse con almacenamiento de datos el usuario en la nube
◦ Pueden ser distribuidas (existe un servidor de imágenes que mantiene las que
usan los dispositivos)
 Son muy útiles el aulas de estudiantes, ordenadores de uso público, etc.
 Ejemplo: Deep Freeze
GAR 3-35

Congelación de equipos
GAR 3-36
3. Administración de servicios
Servicios de directorio
 Ejemplo: Una empresa dispone de 50 ordenadores y 40 empleados que usan varios

ordenadores y tipos de aplicaciones.
◦ Opción 1 (configuración/administración local): Los 50 ordenadores
tienen un usuario genérico y todas las aplicaciones instaladas
 No existe privacidad de datos
 No es posible identificar a los usuarios en el sistema (todos usan el mismo
usuario)
 La gestión es inviable
◦ Opción 2 (servicio de directorio): Desvincular usuarios, datos y

aplicaciones del ordenador
 La identidad digital (usuario, datos, aplicaciones, etc.) de los usuarios se
centraliza, haciéndola accesible desde cualquier equipo de la red.
 Cada usuario tiene acceso a sus recursos y configuraciones.
independientemente del ordenador que use para accede r a la red
 La administración se simplifica, pues sólo es necesario actuar sobre los
GAR 3-37 datos centralizados.
Introducción
 Un servicio de directorio añade en el plano de gestión, una capa sobre los recursos
físicos/lógicos de la red, de forma que el gestor se comunica con el directorio y éste
envía las órdenes de gestión a los dispositivos físicos implicados.
Servicio directorio
Gestión
Recurso Recurso Recurso

físico/lógico físico/lógico físico/lógico
 Cada recurso gestionable (físico o lógico) se representará mediante un objeto del

directorio.
 Los ordenadores/servicios acceden al directorio para obtener sus configuraciones,
espacios de almacenamiento, etc.
GAR 3-38
Introducción
 Un servicio de directorio (DS) es una estructura distribuida que almacena

información acerca de los recursos o entidades existentes en la red (usuarios,
aplicaciones, archivos, periféricos, etc.).
 Un DS está compuesto por el directorio que almacena la información de forma
jerárquica, y un protocolo que implementa los servicios necesarios para acceder a
ella y manipularla.
 El directorio puede ser centralizado o distribuido, pudiendo existir réplicas su
información en distintos sistemas físicos.
 Los usuarios podrán leer, modificar o crear información en el directorio, siempre que
estén autorizados, haciendo uso del protocolo, que permitirá interactuar con la
información almacenada en el directorio.
 La principal utilidad de los DS es que facilitan la administración de la red, pues
permiten:
◦ Realizar la gestión de los recursos de la red desde un único punto
◦ Desvincular a los usuarios de los equipos
◦ Gestionar los recursos en grupo, por tipo, etc.
◦ Gestionar el acceso de los usuarios a los recursos de la red.
◦ Etc.
GAR 3-39
Objetos
 Según la norma X.500, un directorio está compuesto por un conjunto de

objetos, cada uno de los cuales podrá tener información sobre un recursos
físico o lógico de la red.
 Los objetos del directorio se organizan en estructura de árbol. Existe un

nodo raíz, objetos contenedores que dan forma al árbol y un conjunto
de objetos hoja que representan a los recursos, o que actúan de alias a
otros objetos. La estructura del árbol se conoce como DIT (Directory
Information Tree)
 Cada objeto hoja dispone de un conjunto de atributos (que dependerán

de su tipo) y cada atributo podrá tener uno o más valores.
 Cada objeto tiene un nombre distinguido, que lo identifica de forma

inequívoca en todo el directorio.
GAR 3-40
Objetos
 Los objetos contenedores pueden ser de distintos niveles:

◦ País: Está siempre un nivel por debajo de la raíz del árbol y designa el país
en que está la red. Este objeto es opcional y no tiene mayor utilidad.
◦ Organización: Tiene que estar siempre por debajo del objeto ROOT y de
PAIS (si existe). Permite organizar el árbol
◦ Unidad Organizativa: Está siempre por debajo de un objeto ‘organización’
y permite organizar el árbol. Un objeto UNIDAD ORGANIZATIVA puede
contener a otros iguales
 Los objetos hoja pueden ser de muchos tipos: usuario, grupo, servidor,
impresora, proceso, disco, perfil, etc. Dependiendo de la implementación
del directorio, podrán existir unos u otros y tendrán unos atributos u
otros.
GAR 3-41
Objetos
 Ejemplo
raíz
contenedor contenedor
contenedor
hoja
valor
atributos
 Ejemplo de nombre distinguido:

◦ O=IBM; OU=Marketing; CN=Klaus
GAR 3-42
Esquema
 Un esquema (Schema) es un conjunto de reglas que definen la forma en
que está construido el árbol de directorio. Define tipos específicos de
información y la forma en que se almacena en la base de datos
 El esquema define:
◦ Información de atributo: Describe qué tipo de información adicional
puede tener asociado un objeto.
◦ Herencia: Determina qué objetos heredarán propiedades y derechos de
otros objetos.
◦ Denominación: Determina la estructura del árbol de directorio,
identificando de este modo y mostrando el nombre de referencia de un
objeto en el árbol de directorio.
◦ Subordinación: Determina la ubicación de objetos en el árbol del
directorio, mostrando la ubicación del objeto en dicho árbol
 Generalmente existe un esquema base (conjunto de clases de objetos
definidos inicialmente), que puede modificarse y ampliarse.
GAR 3-43
Esquema
 Para identificar la ubicación de cada objeto en el árbol, se utilizan
identificadores únicos denominados OID (Object identifiers). También
pueden usarse para identificar objetos unívocamente en otros
protocolos, como SNMP
 Los OIDs de X.500 pueden encontrarse en la MIB, en:

◦ directory (1.3.6.1.1)
◦ private (1.3.6.1.4)
GAR 3-44
Esquema
 En algunas implementaciones de servicios de directorio, existen herramientas

(gestores de esquema) que permiten la extensión del esquema según sea
necesario.
 Por ejemplo, en el directorio que contiene los objetos asociados a los usuarios de
alumnos, se puede extender el esquema para que los objetos usuario tengan una
nueva propiedad que sea las asignaturas en que se encuentran matriculados. Para
ello, el gestor de esquema puede crear un nuevo atributo denominado asignatura y
luego añadirlo a la clase Usuario.
 Los gestores de esquema también incluyen facilidades para visualizar una lista de
todas las clases y atributos del esquema; visualizar información de un atributo;, etc.
GAR 3-45
Particiones
 Cada localización física de un

directorio se denomina
partición
 Una partición tiene que estar

localizada en un único servidor,
pero una partición puede tener
información de varios servidores.
 El directorio puede estar

compuesto por varias particiones
almacenadas en distintos
servidores
GAR 3-46
Particiones
 Una réplica es una copia de una partición que se encuentra localizada

en un contexto distinto del que contiene la original. Pueden ser de tres
tipos:
◦ Maestra: Es la copia principal de la partición
◦ Lectura/escritura: Es una copia que puede ser leída y escrita. Si es escrita,
el sistema operativo se encarga de enviar la actualización al resto
◦ Sólo lectura: Sólo puede ser leída, pero no puede modificarse. Sólo se
modifica cuando hay un cambio de información en la partición maestra.
 Las réplicas se utilizan para aumentar la

seguridad del directorio, ya que si se
daña la partición principal, la información
que contenía podrá ser recuperada a
partir de una réplica.
GAR 3-47
Particiones
 Ejemplo de configuraciones multisede
GAR 3-48
Servicio de directorio
 Un servicio de directorio está compuesto por un directorio y un
protocolo que permite gestionar los objetos contenidos en el mismo.
 Las principales funcionalidades del protocolo serán:
◦ Gestión de la estructura del directorio
◦ Creación y borrado de objetos
◦ Gestión de los objetos existentes (lectura, comparación, etc.)
◦ Gestión del control de acceso a los objetos y autenticación de las partes
◦ Gestión del directorio distribuido o de las posibles réplicas existentes.
 Para acceder al directorio, la recomendación X.509 especifica los
protocolos:
◦ DAP (Directory Access Protocol): Intercambio de información entre el agente de
usuario y directorio
◦ DSP (Directory System Protocol): Intercambio de información entre dos
directorios.
GAR 3-49
Principales ventajas
 Las principales ventajas que aporta un servicio de directorio a una red

son:
◦ Administración única: Es posible administrar el todos los objetos de la
fred (todos los recursos) desde un único lugar
◦ Seguridad avanzada: Los servicios de directorio implementan mecanismos
de seguridad avanzados (ACLs sobre los objetos, encriptación, etc.)
◦ Funcionalidad: La jerarquía de diseño reduce el tráfico en la red; y permite
buscar más fácilmente objetos en toda la red
◦ Fiabilidad: Aumenta la fiabilidad de la red, pues existen réplicas del
directorio y existen mecanismos de sincronización automática.
◦ Escalabilidad: El directorio es fácilmente escalable, permitiendo adaptarse a
los cambios de la organización.
◦ Internacionalidad: Existen implementaciones de directorio compatibles
con distintos sistemas operativos, lo que permite gestionar redes
heterogéneas.
GAR 3-50
Ejemplos de Servicios de directorio
 Los protocolos DAP y DSP demostraron ser muy pesados e iban
asociados al modelo OSI que no se implantó. Por ello, se desarrollaron
otras implementaciones más ligeras, entre las que se encuentran:
◦ LDAP (Lightweight Directory Access), especificado en los RFC2251 y RFC2256
(entre otros), que es una versión simplificada de DAP. Una de las distribuciones
multiplataforma más extendida es openLDAP.
◦ NIS (Network Information Service) desarrollado por Sun Microsystems para
sistemas unix.
◦ e-directory de Novell (antes denominado NDS, Network Directory System).
NDS fue desarrollado para contener información de recursos en redes locales
Novell Netware, caracterizándose porque la información contenida en el
directorio no era solo de personas, sino de recursos de la red.
◦ Active Directory (AD) desarrollado por Microsoft. AD contiene objetos que
representan a recursos de la red (como NDS) y permite la gestión centralizada
de los recursos físicos y lógicos distribuidos por la red. Se basa en LDAP
◦ Otras…
GAR 3-51
LDAP
 LDAP (Lightweight Directory Access) se basa en la norma x.500 de la IUT

y permite el acceso a los datos de un directorio distribuido para
localizar o manipular información. Es una implementación ligera de DAP,
que usa en TCP/IP.
 LDAP utiliza por defecto el puerto 389 y soporta el directorio X.500
GAR 3-52
LDAP
 El directorio al que accede LDAP cumple la norma X.500, siendo una

jerarquía de objetos con estructura de árbol. Su raíz es el ‘DN base’,
pudiendo especificarse de tres formas:
◦ Formato ORGANIZACIÓN, PAÍS Ejemplo  O=“uclm”, C=“es”
◦ Formato URL Ejemplo  O=“uclm.es”
◦ Formato DNS Ejemplo dc=“uclm”, dc=“es”
 Cada objeto hoja representa a un recursos físico o lógico y tiene un

conjunto de atributos.
 Cada atributo tiene:

◦ Un nombre global distinguido (DN) único.
◦ Un tipo
◦ Uno o más valores.
GAR 3-53
LDAP
dc=empresa, dc=es Raíz en formato DNS

Objeto contenedor
ou=Marketing Objeto hoja
Atributo / valor
Cn=Juan Ruiz
Telefono=444111111
Despacho=1A1
ou=ventas
cn=Ana Perez
Telefono=444111112
Despacho=1A2
ou=Ingenieria
Cn=Luis García
Telefono=444111113
Despacho=1A3
Cn=Maria Sanchez
Telefono=444111114
Despacho=1A4
GAR 3-54 dn (Maria Sanchez)  cn=‘Maria Sanchez’, ou=‘Ingenieria’, dc=empresa’, dc=‘es’
LDAP
 LDIF (LDAP Data Interchange Format) es un formato de archivo de texto

ASCII que permite la importación o exportación de datos con LDAP.
 El formato de LDIF es: Directorio
Servidor LDAP
dn: <nombre distinguido> X.500
<nombre_atributo>: <valor>
<nombre_atributo>: <valor> LDIF
<nombre_atributo>: <valor>
 En LDIF cada objeto debe separarse con una línea en blanco
GAR 3-55
LDAP
dn: ou=Marketing,dc=empresa,dc=es dn: cn=Ana Perez,ou=Ventas,dc=empresa,dc=es
objectClass: organizationalUnit objectClass: inetOrgPerson
ou: Marketing cn: Ana Perez
givenName: Ana
dn: ou=ventas,dc=empresa,dc=es sn: Perez
objectClass: organizationalUnit telephoneNumber: 444111112
ou: Ventas roomNumber: 1A2
dn: ou=Ingenieria,dc=empresa,dc=es dn: cn=Luis Garcia,ou=Ingenieria,dc=empresa,dc=es

objectClass: organizationalUnit objectClass: inetOrgPerson
ou: Ingenieria cn: Luis Garcia
givenName: Luis
dn: cn=Juan Ruiz ,ou=Marketing,dc=empresa,dc=es sn: Garcia
objectClass: inetOrgPerson telephoneNumber: 444111113
cn: Juan Ruiz roomNumber: 1A3
givenName: Juan
sn: Ruiz ( …. Continua ….)
telephoneNumber: 444111111
GAR 3-56 roomNumber: 1A1
Protocolo LDAP
 El protocolo LDAP gestiona la comunicación entre un cliente y un servidor

LDAP, posibilitando el acceso al directorio
Protocolo Directorio
Cliente LDAP Servidor LDAP
LDAP X.500
TCP TCP
Principales operaciones que puede realizar un cliente LDAP:
Bind: Inicia la autenticación para abrir una conexión

Autenticación
Unbind: Cerrar la conexión existente
Consulta
Search: Buscar y obtener entradas del directorio
Compare: Comprobar si una determinada entrada tiene un cierto valor
Add: Añadir una nueva entrada
Delete: Borrar una nueva entrada
Actualización Modify: Modificar una entrada existente
Abandon: Abandonar una petición previa
Extended Operation: Es una operación que permite definir otras operaciones
GAR 3-57
Protocolo LDAP
 Una de las implementaciones más extendidas es openLDAP que implementa un

servidor LDAP (denominado SLAPD).
 También existen muchas herramientas para facilitar la creación y administración

del directorio, como por ejemplo Jxplorer, o phpldapadmin
 Ejemplo: Para gestionar el control de acceso a terminales mediante la

autenticación de LDAP sería necesario:
◦ Instalar un servidor LDAP (openLDAP por ejemplo)
◦ Crear el directorio (con su información)
◦ Instalar los clientes que accedan al directorio y configurarlos para que
busquen la información en el directorio
GAR 3-58
4. Administración global
 Cuando la red es grande, la administración de equipos de forma local se hace

inviable, por lo que hay que hay que usar herramientas que permitan realizar
una administración global. Por ejemplo:
◦ Uso de servicios de directorio para gestionar recursos.
◦ Uso de directivas de sistema, grupo o usuario
◦ Despliegue y gestión centralizada de aplicaciones
◦ Etc.
 Situaciones típicas en una empresa:

◦ Un trabajador cambia de puesto de trabajo…
◦ Un trabajador necesita los mismos recursos que otro…
◦ Un trabajador abandona la empresa y es necesario eliminar sus datos…
◦ Varios trabajadores usan la misma aplicación…
◦ Actualización de equipos de trabajadores
GAR 3-65
Administración global
Introducción
 La administración global de servidores implica:
◦ Administración de recursos: A qué puede (o no) acceder el usuario.
◦ Distribución software: Qué aplicaciones están disponibles para el usuario.
◦ Mantenimiento remoto de equipos: Instalación y configuración de nuevos
equipos.
◦ Administración de datos: A que datos puede acceder cada usuario o
dispositivo.
◦ Listas de distribución de correo: A que listas pertenece el usuario.
◦ Etc.
 Existen herramientas que facilitan la administración global de una red.
GAR 3-66
Gestión de puestos de trabajo: Ciclo de vida
 La gestión de los puestos de trabajo es una de las tareas más laboriosas de una
red, e implica:
◦ La definición de patrones de configuración, según roles de los usuarios
◦ La configuración inicial de los nuevos equipos que se incorporan a la red
◦ La gestión diaria de los dispositivos (corrección de errores, actualización, etc. )
 En redes grandes, es necesario automatizar

todas esas tareas, pues:
◦ Es inviable realizar una gestión individualizada
de cada equipo
◦ Es necesario aplicar políticas comunes de
seguridad, de acceso, etc.
 Existen herramientas que automatizan estas

tareas, como por ejemplo Configuration Manager
o InTune de Microsoft (integradas en EndPoint
Manager)
GAR 3-67
Ejemplo: EndPoint Manager
 EndPoint Manager: Es un conjunto de herramientas que centralizan la

administración y control de los dispositivos conectados en red.
 Principales funcionalidades:
◦ Gestión integral y administración de dispositivos multiplataforma (Windows, Android,
ios, etc.)
◦ Inventario hardware y software
◦ Despliegue de aplicaciones
◦ Despliegue y provisionamiento de dispositivos
◦ Control de acceso a los recursos corporativos
◦ Mantenimiento de las políticas de seguridad en los dispositivos
◦ Borrado remoto de aplicaciones y/o dispositivo
◦ Soporte remoto
◦ Etc.
GAR 3-68
 EndPoint Manager integra:

◦ Las dos soluciones principales de administración y gestión de dispositivos
remotos:
 ConfigurationManager: Facilita la administración de equipos de
escritorio y servidores de la empresa (Windows, Linux, mac etc.)
 InTune: Facilita la administración de dispositivos móviles y de aplicaciones
móviles desde la nube. Permite controlar características y parámetros de
configuración en dispositivos Android, mac y Windows 10
◦ Una solución orientada a la preconfiguración de dispositivos:
 Autopilot: Realiza la preconfiguración de dispositivos y los inscribe
automáticamente para que sean gestionados por Intune.
GAR 3-69
GAR 3-70
Visión general autopilot
 Automatización con autopilot:
◦ El vendedor suministra el nuevo equipo con un SSOO OEM y sube a la nube un ID
único del mismo (hash del equipo)
◦ El gestor crea configuraciones, según tipos de equipos/roles y las sube a la nube.
◦ El gestor asocia IDs de equipos a grupos de configuraciones.
◦ El equipo llega al trabajador y al arrancarlo, sube su ID a la nube y ésta le entrega su
configuración especifica.
• Desde el unto de vista del usuario, solo son necesarias algunas operaciones para
que el dispositivo esté listo para usarse.
• Desde el punto de vista del gestor de la red, sólo es necesario que el usuario se
GAR 3-71 conecte a la red e introduzca sus credenciales. Todo lo demás está automatizado.
Visión general inTune
 En un organización, existen equipos móviles (portátiles, móviles, etc.) que

usan los empleados, tanto desde dentro de la empresa como desde el
exterior (teletrabajo, por ejemplo)
 Los equipos móviles son muy críticos, ya que acceden a información de la
empresa, se conectan a su red y a la vez, se conectan a redes externas,
posiblemente poco seguras.
 inTune proporciona funciones de administración y gestión de equipos
móviles de la empresa, desde la nube
 inTune permite:
◦ Desplegar aplicaciones
◦ Gestionar de forma remota los dispositivos (borrado de datos, configuración,
etc.)
GAR 3-72
Visión general inTune
 Principales funcionalidades:
◦ Administración de Dispositivos Móviles (MDM):
 Los dispositivos móviles se inscriben en un portal (individualmente o en grupo)
 Se le aplican configuraciones por defecto y/o personalizadas al equipo o al usuario que acceda al
equipo
 Ofrece una administración completa del dispositivo móvil, de forma remota.
◦ Administración de Aplicaciones Móviles (MAM):

 Controla que aplicaciones podrán ser utilizadas por cada usuario
 Asegura la transferencia de datos cuando los dispositivos están fuera de la empresa
 Controla que cuando un equipo se desinscriba, deje de de tener acceso a las aplicaciones
 Impide la ejecución de aplicaciones no inscritas, aplica filtrado de URLs, etc. (
◦ Administración de equipos (ordenadores fijos)

 Integra equipos fijos de la empresa y de los usuarios, que usan en el trabajo.
 En equipos de usuarios, se gestionan sólo cuestiones de seguridad (antivirus, actualizaciones, etc.)
 Integra en inTune otras plataformas de mantenimiento de equipos de empresa
GAR 3-73
5. Administración de dispositivos de red
 La administración de los dispositivos de red tiene que ver principalmente

con la gestión de la configuración de los dispositivos (switch, router, etc.)
para que tengan una disponibilidad lo más próxima al 100% y para que
proporcionen el mejor rendimiento posible.
 Como en el caso de los servidores, existen varias posibilidades de
monitorización:
◦ En cuanto al uso de herramientas:
 Propias del sistema operativo del dispositivo
 De terceros
◦ En cuanto a localidad:
 Monitorización local
 Monitorización remota
 Es muy importante integrar en un mismo sistema la administración y
monitorización de todos los recursos de la red (servidores y dispositivos
de red)
GAR 3-74
Administración de dispositivos de red
Principales componentes de un router
 Los principales componentes de un router (CISCO) son:
◦ POST (Power On Self Test): Microcódigo que implementa varios test que
chequean la funcionalidad del dispositivo, durante el arranque. Se almacena
en la ROM.
◦ Bootstrap: Microcódigo que se utiliza en primera instancia para cargar el
sistema operativo del router. Se almacena en la memoria ROM.
◦ ROMMonitor: Sistema operativo reducido que permite ejecutar
◦ ROM: Memoria de solo lectura que contiene el bootstrap y POST
◦ NVRAM: Memoria no volátil que almacena el registro de configuración y el
archivo de configuración.
◦ FLASH: Memoria no volátil que Almacena las imágenes del IOS. Puede ser
externa (PCMCIA) o interna.
◦ RAM: Memoria volátil en la que se almacena, el sistema operativo cargada
desde la memoria flash y la configuración actual. También una parte de la
RAM se usa para implementar los buffers de los puertos, tablas de
encaminamiento, etc.
GAR 3-75

Estructura general de un router
 Estructura general de un router
GAR 3-76
Secuencia de arranque
 Secuencia de arranque:
1. Se ejecuta desde la ROM el POST (Power On Self Test): Chequeo del
hardware para comprobar que todos los componentes funcionan
correctamente.
2. Se ejecuta desde la ROM el bootstrap para buscar y cargar el sistema
operativo (IOS). Es un pequeño software que ayuda a la carga del sistema
operativo (ROM MONITOR)
3. El sistema operativo busca en la NVRAM el archivo de configuración
(startup-config), lo copia en la RAM (running-config) y lo interpreta.
 En los pasos 2 y 3, mediante el registro de configuración se indica, entre

otras cosas, dónde se debe buscar la imagen del sistema y el archivo de
configuración.
GAR 3-77
bootstrap
GAR 3-78
ROMMON
 En un router, es posible acceder al ROM Monitor (ROMMON)
pulsando Ctrl-C durante el arranque.
Cambiar registro de configuración

Ver contenido de la NVRAM
Reiniciar router
Recuperar imagen desde servidor TFTP
 En un switch, pulsando el botón MODE durante el arranque

GAR 3-79

Registro de configuración
 El registro de configuración puede utilizarse para indicarle al
bootstrap cómo debe cargar la imagen del sistema operativo
 Valores más utilizados:

◦ 0x2102: (valor por defecto): Arranque normal
◦ 0x2142: No lee el archivo de configuración
GAR 3-80
 El registro de configuración es un registro de 16 bits escrito en la
NVRAM que permite configurar la carga del sistema operativo. Su
valor normal es 0x2102 (0010-0001-0000-0010)
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CAMPO DE ARRANQUE
GAR 3-81

 ¿Cómo modificar el registro de configuración?
◦ Desde IOS:
◦ Desde el ROMMON:
GAR 3-82
Obtención de información
 Se puede utilizar el comando show, con alguna de las opciones posibles
GAR 3-83

Procedimientos básicos de administración
Realización de copias de seguridad de los archivos del dispositivo
(configuración, imagen, etc.).
 Hay dos posibilidades: RAM

◦ Copias dentro del propio dispositivo NVRAM
FLASH
◦ Copias con un ordenador exterior Equipo remoto
 Ejemplos de comandos para copia dentro del mismo dispositivo:

#copy running-config startup-config
#copy startup-config running-config
#erase (borra completamente)
#delete partición:archivo (borra un solo archivo)
GAR 3-84
Copia de seguridad de la imagen y archivo de configuración de un
switch en un dispositivo externo
 Se debe usar un servidor externo TFTP ubicado en la misma subred que
el switch.
 Para que el switch pueda comunicarse con el servidor TFTP, debe tener
conectividad. Para ello hay que configurarle una VLAN por defecto y
asociarle una dirección IP.
Switch(config)#interface vlan1
Switch(config-if)#ip address xxx.xxx.xxx.xxx 255.255.248.0
Switch(config-if)#no shutdown
Switch(config)#ip default-gateway xxx.xxx.xxx.xxx
Switch(config)#exit
 En un PC de la misma subred, activar un servidor TFTP
 Ejecutar el comando para realizar la copia remota
Switch#copy flash:archivo tftp
GAR 3-85

Copia de seguridad de la imagen y archivo de configuración de un
router en un dispositivo externo
 Se debe usar un servidor externo TFTP ubicado en la misma subred que
el switch.
 Para que el router pueda comunicarse con el servidor TFTP, debe tener
conectividad. Para ello hay que asegurarse que tiene configurado el
interfaz que lo conecta con la subred. En caso de no estarlo:
Router(config)#interface eth0/0
Switch(config-if)#ip address xxx.xxx.xxx.xxx 255.255.248.0
Switch(config-if)#no shutdown
Switch(config)#ip default-gateway xxx.xxx.xxx.xxx
Switch(config)#exit
 En un PC de la misma subred, activar un servidor TFTP
 Ejecutar el comando para realizar la copia remota
Switch#copy flash:archivo tftp
GAR 3-86
Actualización de la imagen del sistema operativo de un switch. El
switch arranca correctamente y se le quiere actualizar la imagen del sistema
 Configurar la VLAN 1 como se ha indicado anteriormente
 Realizar la copia del archivo con la nueva imagen
switch#copy tftp flash:
 Arrancar el switch desde la nueva imagen
switch(config)#boot system flash:<nuevo-archivo-imagen>
switch(config)#exit
 Guardar la nueva configuración y reiniciar el switch:
switch#write memory
switch#reload
Actualización de la imagen del sistema operativo de un router. El
router arranca correctamente y se le quiere actualizar la imagen del sistema
 Configurar el interface que lo conecta con la subred
 Realizar la copia del archivo con la nueva imagen
GAR 3-87 switch#copy tftp flash:

Transferencia del archivo de configuración a un switch que no lo
tiene (o es inválido). El switch arranca pero no tiene ninguna configuración.
 Es necesario configurar desde el IOS los parámetros básicos para que se
pueda comunicar con el servidor TFTP remoto y después transferirle el
archivo.
◦ Configurar la VLAN1 del switch asignándole una dirección IP, como se ha
indicado anteriormente.
◦ Realizar una prueba de conectividad (ping) entre el switch y el servidor TFTP
◦ Transferir el archivo de configuración
◦ Reiniciar el switch
Transferencia del archivo de configuración a un router que no lo

tiene (o es inválido). El router arranca pero no tiene ninguna configuración.
 Seguir los pasos anteriores, pero configurando un interfaz en vez de una
VLAN
GAR 3-88
Transferencia del archivo de imagen a un switch que no lo tiene (o
es inválido). El switch no puede arrancar y se queda en el ROMMON con el
prompt switch:
 Como el switch es de nivel 2 y no tiene cargada la imagen, hay que transferirle
el archivo desde el puerto de consola. Se pueden seguir los siguientes pasos:
◦ Configurar la velocidad del puerto de consola
switch: set BAUD 57600
◦ Iniciar la flash y cargar el helper
switch:flash_init
switch:load_helper
◦ Transferir el archivo desde el terminal:
switch:copy xmodem: flash:<nombre de la imagen>
◦ Reiniciar el switch:
boot flash:<nombre imagen>
GAR 3-89

Transferencia del archivo de imagen a un router que no lo tiene (o
es inválido). El router no puede arrancar y se queda en el ROMMON con el
prompt rommon:
◦ Configurar manualmente la interfaz del router que lo conecta con la subred
rommon 1 > SET (indica los parámetros que tiene configurado el interfaz)
IP_ADDRESS=xxxxxx (la IP del router)
IP_SUBNET_MASK=255.255.248.0
DEFAULT_GATEWAY=xxxx (la IP del router)
TFTP_SERVER=xxxx la IP del servidor TFTP)
TFTP_FILE=(nombre del archivo a transferir en el servidor TFTP)
◦ Preparar los archivos en el servidor tftp
◦ Ejecutar tftpdnld
◦ Reiniciar el router
GAR 3-90
El switch tiene una clave para acceder al modo privilegiado, pero
desconocemos cual es.
 Como no se puede acceder al modo privilegiado, no se puede modificar
su archivo de configuración. Habría que realizar los siguientes pasos:
◦ Pasar el modo ROMMON (Presionar el botón MODE del switch y
mantenerlo presionado mientras se conecta el switch)
◦ Inicializar la flash y cargar el sistema operativo
◦ Comprobar los archivos que hay en la flash y cambiar el nombre al que
tiene la configuración
◦ Reiniciar el switch (arranca sin leer el archivo de configuración)
◦ Volver a renombrar el archivo de configuración
◦ Cambiar la contraseña
◦ Guardar los cambios
◦ Reiniciar el switch
GAR 3-91

 El router tiene una clave para acceder al modo privilegiado,
pero desconocemos cual es.
 Como no se puede acceder al modo privilegiado, no se puede modificar
su archivo de configuración. Habría que realizar los siguientes pasos:
◦ Iniciar el router en el modo ROMMON (pulsar ctrl-c al arrancar)
◦ Modificar el registro de configuración
 ROMMON 1>confreg 0x2142
◦ Reiniciar el router. Arrancará correctamente pero sin cargar la
configuración
◦ Seguir los pasos anteriores para transferirle un nuevo archivod e
configuración
GAR 3-92
Verificar el estado de la Flash
 Para verificar el estado de la flash, se puede usar el comando show flash
GAR 3-93

Herramientas de administración
 También es posible utilizar software del propio fabricante para disponer
de un entorno más amigable, que permita realizar la configuración y
administración de los dispositivos.
 En el caso de CISCO, hay varias herramientas (Cisco Configuration
Professional, Cisco Professional Express, SDM, DNA…). Cada una de ellas
requiere que la imagen del sistema operativo del dispositivo sea igual o
superior a una cierta versión.
GAR 3-94
 Ejemplo CCP:
◦ Agrupa los dispositivos a administrar por comunidades. Por tanto, en primer lugar hay
que indicar que dispositivos hay en cada comunidad.
◦ Seguidamente los dispositivos se descubren
◦ Ejemplo: Configuración de interfaces
GAR 3-95

 Ejemplo:
◦ Manejo de archivos en un router
GAR 3-96
 Ejemplo: Monitorización de rendimiento
GAR 3-97
TEMA 5
MONITORIZACION DE REDES
Contenidos
1. Introducción
2. Monitorización remota con RMON
3. Monitorización de trafico IP con NetFlow
GAR 5-2
4.1 Monitorizacion
Introducción
 La monitorización de una red consiste en consultar periódicamente el

estado de sus componentes y del tráfico que circula por ella.
 Para monitorizar, se utilizan agentes de monitorización que se sitúan

estratégicamente en la red y obtienen la información, que posteriormente
es analizada y/o almacenada.
 Principales usos de la monitorización:

◦ Prevención de fallos
◦ Mejora de rendimiento
◦ Registro de eventos
◦ Contabilidad y uso de recursos
GAR 5-3 ◦ Seguridad
4.2 Monitorización con RMON

Introducción
 RMON (Remote network MONitoring) es una extensión de SNMP.

Básicamente es una ampliación de la MIB-II con información útil para
monitorización. Se basa en el uso de objetos tabla de una MIB.
 RMON no modifica el protocolo SNMP. Amplia su funcionalidad

añadiendo la capacidad de monitorizar una red de área local (LAN)
como un todo.
 RMON se ejecuta en un Agente RMON (también conocido como

monitor de red). Debe haber uno por subred.
GAR 5-4
4.2 Monitorización con RMON
Introducción
 Ámbito de actuación de SNMP, RMON y RMON2:

◦ SNMP proporciona información sobre los nodos de la red, ya que la
información que se obtiene con la MIB-II es local a cada dispositivo.
◦ RMON proporciona información más global sobre la red (sólo capas 1 y 2).
◦ RMON2 proporciona información más global de la capa 3 y superiores.
SNMP
GAR 5-5
Monitorización con RMON

Introducción
 La especificación de RMON
incluye la definición de una
nueva rama de la MIB
 Por tanto, cualquier plataforma

que se vaya a emplear como
monitor de RMON debe
soportar SNMP.
RMON 1.3.6.1.2.1.16
GAR 5-6
Ubicación de sondas
 Para gestionar una red con SNMP es necesario un agente en cada
dispositivo gestionado
 Para monitorizarla con RMON, es necesario un agente RMON por
dominio de difusión, ubicado en el lugar adecuado.
SNMP
RMON
GAR 5-7

Ubicación de sondas
 Ejercicio: La figura muestra la estructura de la red de un centro de
enseñanza. Se desea implantar un sistema de gestión de red (SGR)
que permita gestionar con SNMP todos los dispositivos informáticos
(elementos de red y PCs) y que permita monitorizar con RMON
toda la red. Indica qué agentes serían necesarios y donde se
ubicarían. La consola del SGR está ubicada en PC-PT adm-2..
Agente SNMP
Agente RMON
GAR 5-8
Objetivos de RMON
 Operación off-line: El monitor recoge información sobre fallos, rendimiento y

configuración continuamente, aunque el gestor de red no la esté solicitando.
 Monitorización anticipada: Si el monitor tiene recursos suficientes puede

realizar diagnósticos y registrar el funcionamiento de la red
◦ En caso de fallos, el monitor puede comunicárselo al gestor, junto con
información útil para su diagnóstico
 Datos de valor añadido: El monitor puede realizar ciertos análisis específicos

de los datos recogidos en su subred. Por ejemplo: Determinación de los host
que generan la mayor parte del tráfico en la red, porcentaje de errores...
 Múltiples gestores: Un monitor se puede configurar para tratar con más de

un gestor a la vez
GAR 5-9

Configuración
 Para configurar el agente RMON, se utilizan tablas de SNMP.
 La MIB de RMON puede tener tablas de control y de datos:

◦ Tabla de control: contiene parámetros que definen la función de
monitorización. Los datos que se obtienen, se almacenan en la tabla de datos.
◦ La tabla de datos contiene los datos obtenidos con la monitorización.
◦ La tabla de control suele ser de lectura/escritura y la de datos de sólo lectura.
F1 F1
Funciones de F2 F2
monitorización F3 F2
F4 F3
TABLA DE CONTROL TABLA DE DATOS

(ESTRUCTURA GENERAL)
GAR 5-10
Múltiples gestores
 Un agente RMON puede recibir órdenes de varios gestores, por lo

que pueden existir conflictos o dificultades, al intentar acceder varios a
la vez a un mismo recurso. Por ejemplo:
◦ Peticiones simultáneas de recursos, pueden exceder la capacidad del
monitor para abastecerlos.
◦ Un gestor puede mantener recursos del agente durante un largo periodo
de tiempo, impidiendo que el agente pueda atender peticiones de otros
gestores.
◦ Un agente puede tener recursos asignados a un gestor y éste puede
caerse sin liberarlos.
 Para controlar estos aspectos (y otros), en cada tabla de control

siempre hay una columna que identifica al dueño de cada fila de la tabla
(y por tanto, de la función de monitorización que está ejecutando): la
etiqueta de propietario (OwnerString).
GAR 5-11

Múltiples gestores
 La etiqueta de propietario (OwnerString) es necesaria para que:
◦ Una estación de gestión pueda reconocer recursos que posee en un
agente (y que ya no necesita.
◦ Un operador de red pueda identificar al gestor que posee un recurso o
función de monitorización en un agente y negociar su liberación.
◦ Un operador de red puede tener autoridad para liberar recursos que tenga
reservados otro operador de red.
◦ Si una estación de gestión se reinicializa, puede reconocer recursos que
había reservado en el pasado y liberar aquellos que no vaya a usar.
 En la especificación de RMON se recomienda que la etiqueta de propietario

incluya esta información:
◦ Dirección IP, nombre de la estación de gestión, nombre del administrador
de red, localización o número de teléfono
 Una fila de una tabla de control sólo debe ser modificada o borrada por su
GAR 5-12 dueño, permaneciendo en modo de sólo lectura para el resto.
Gestión de tablas
 Por tanto, en una tabla de control siempre deben existir estos tres
campos (columnas)
OwnerString ::= DisplayString
EntryStatus ::= INTEGER {valid(1), createRequest(2), underCreation(3), invalid(4)}
Index := Integer
 Ejemplo de tabla de control (HostControlEntry):

HostControlEntry ::= SEQUENCE {
hostControlIndex INTEGER (1..65535),
hostControlDataSource OBJECT IDENTIFIER,
hostControlTableSize INTEGER,
hostControlLastDeleteTime TimeTicks,
hostControlOwner OwnerString,
hostControlStatus EntryStatus
GAR 5-13 }

Gestión de tablas
 En cada función de monitorización (fila de la tabla de control), siempre

debe existir un campo (EntryStatus) que codifica el estado de la función
y permite su creación ordenada.
EntryStatus ::= INTEGER {valid(1), createRequest(2), underCreation(3), invalid(4)}
 Usando este campo (EntryStatus), se posible implementar un procedimiento

ordenado de creación de filas en la tabla de control.
NO EXISTE createRequest underCreation valid
Gestor invalid
Agente
GAR 5-14
Gestión de tablas
 Ejemplo de tabla de datos asociada a la tabla de control y relación

mediante el campo índice
hostControlTable
hostControlIndex hostControlDataSource . . . hostControlOwner hostControlStatus
1 IfIndex.1 . . . manager alpha valid(1)
2 IfIndex.2 . . . manager beta valid(1)
3 IfIndex.3 . . . manager gamma valid(1)
hostTable
hostAddress hostCreationOrder hostIndex . . .
MAC addrA 1 1 . . .
MAC addrB 2 1 . . .
MAC addrC 3 2 . . .
MAC addrD 4 3 . . .
MAC addrE 5 3 . . .
Índices
GAR 5-15

MIB RMON
 La MIB de RMON cuelga del nodo mib-2, con el

identificador 16.
 La MIB RMON define un conjunto de objetos
gestionados, útiles para realizar la monitorización
remota.
 RMON utiliza el protocolo SNMP para
gestionar los objetos de la MIB.
GAR 5-16
Grupos de la MIB
 Grupos de RMON:
◦ statistics(1): Obtiene estadísticas del tráfico y de errores para cada subred
monitorizada por el agente.
◦ history(2): Almacena muestras periódicas de estadísticas de la información
disponible en el grupo statistics.
◦ host(4): Contiene contadores para varios tipos de tráfico hacia o desde los
hosts conectados en la subred, y mantienen información de hosts (errores
recibidos, paquetes enviados o recibidos...).
◦ hostTopN(5): Contiene estadísticas ordenadas que informan de los hosts que
encabezan una lista basada en algún parámetro. Ejemplo: los N hosts que
han recibido más errores.
◦ matrix(6): Almacena la información de utilización y de errores en forma
matricial. Así, el administrador puede solicitar información respecto a
cualquier par de direcciones de red.
GAR 5-17

Grupos de la MIB
◦ alarm(3): Permite establecer intervalos de muestreo y umbrales de alarma
para cualquier contador o entero registrado por el agente RMON.
◦ filter(7): Permite definir filtros que facilitan la observación de paquetes que
cumplen ciertas condiciones. El agente RMON puede capturar todos los
paquetes que pasen el filtro, o almacenar estadísticas sobre ellos.
◦ packet capture(8): Define unos buffers ellos que se pueden almacenar los
paquetes que han superado el filtro anterior.
◦ event(9): Mantiene una tabla de eventos que puede generar el agente RMON
y una tabla log para almacenarlos.
 Todos los grupos son opcionales, aunque existen las siguientes
dependencias:
◦ El grupo hostTopN requiere la implementación del grupo host.
◦ El grupo alarm requiere la implementación del grupo event.
◦ El grupo packet-capture requiere la implementación del grupo filter.
GAR 5-18
Grupo statistics
 Contiene las estadísticas

básicas para cada subred
monitorizada.
 Actualmente, solo contiene

objetos definidos para interfaces
Ethernet.
 Consta de una tabla con una

entrada (fila) para cada interfaz
del monitor monitorizada
(subred).
GAR 5-19

Grupo history
 Se emplea para definir funciones de muestreo para una o varias
interfaces del monitor.
 Consta de dos tablas:
◦ historyControlTable: especifica el interfaz y los detalles de la función de
muestreo.
◦ etherHistoryTable: registra los datos.
 Para cualquier subred puede haber más de un proceso de muestreo
◦ Cada uno debe tener un período de muestreo diferente.
 La especificación de RMON recomienda tener al menos dos entradas en
historyControlTable:
◦ Una con período de muestreo de 30 seg., para detectar cambios repentinos
en modelos de tráfico.
◦ Otra con período de muestreo de 30 min., para monitorizar el régimen
permanente del interfaz.
GAR 5-20
Grupo history
historyControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF
HistoryControlEntry
HistoryControlEntry ::= SEQUENCE {
STATUS mandatory
historyControlIndex INTEGER (1..65535),
DESCRIPTION
"A list of history control entries." historyControlDataSource OBJECT IDENTIFIER,
::= { history 1 } historyControlBucketsRequested INTEGER (1..65535),
historyControlEntry OBJECT-TYPE historyControlBucketsGranted INTEGER (1..65535),
SYNTAX HistoryControlEntry historyControlInterval INTEGER (1..3600),
ACCESS not-accessible historyControlOwner OwnerString,
STATUS mandatory historyControlStatus EntryStatus
DESCRIPTION }
"A list of parameters that set up a
periodic sampling of statistics. As an
example, an instance of the
historyControlInterval object might be
named historyControlInterval.2"
INDEX { historyControlIndex }
::= { historyControlTable 1 }
GAR 5-21

Grupo history
etherHistoryTable OBJECT-TYPE EtherHistoryEntry ::= SEQUENCE {
SYNTAX SEQUENCE OF EtherHistoryEntry etherHistoryIndex INTEGER (1..65535),
ACCESS not-accessible etherHistorySampleIndex INTEGER
(1..2147483647),
STATUS mandatory
etherHistoryIntervalStart TimeTicks,
DESCRIPTION
etherHistoryDropEvents Counter,
"A list of Ethernet history entries."
etherHistoryOctets Counter,
::= { history 2 }
etherHistoryPkts Counter,
etherHistoryBroadcastPkts Counter,
etherHistoryEntry OBJECT-TYPE
etherHistoryMulticastPkts Counter,
SYNTAX EtherHistoryEntry
etherHistoryCRCAlignErrors Counter,
etherHistoryUndersizePkts Counter,
STATUS mandatory
etherHistoryOversizePkts Counter,
DESCRIPTION
etherHistoryFragments Counter,
"An historical sample of Ethernet statistics
on a particular Ethernet interface. ……. " etherHistoryJabbers Counter,
INDEX { etherHistoryIndex , etherHistoryCollisions Counter,
etherHistorySampleIndex } etherHistoryUtilization INTEGER (0..10000)
::= { etherHistoryTable 1 } }
GAR 5-22
Grupo history
 Ejemplo de configuración del grupo History de RMON
Albacete> enable
Albacete# configure terminal
Albacete(config)# interface GigabitEthernet0/1
Albacete(config-if)# rmon collection history 230 buckets 100 interval 60 owner GAR
Albacete(config-if)#
(** Se activa el monitor **)
Albacete# show rmon history

Event 234 is active, owned by ownerA
Monitors ifIndex.10101 every 120 second(s)
Requested # of time intervals, ie buckets, is 100,
Sample # 1 began measuring at 18:30:00
Received 156770403980 octets, 3271310513 packets,
0 broadcast and 0 multicast packets,
0 undersized and 0 oversized packets,
0 fragments and 0 jabbers,
0 CRC alignment errors and 0 collisions,
# of dropped packet events is 1
Network utilization is estimated at 40
Sample # 2 began measuring at 18:31:30
GAR 5-23

Grupo host
 Se emplea para recoger estadísticas sobre hosts específicos en una LAN.
 El monitor descubre nuevos hosts en la LAN observando las direcciones MAC

fuente y destino en los paquetes. El monitor añade una fila por cada host que
descubre.
 La tabla de control (hostControlTable) determina sobre qué interfaces (subredes)

se realiza esta función.
 Hay dos tablas de datos:

◦ hostTable almacena los datos de los hosts indexados por su dirección MAC.
◦ hostTimeTable los indexa por orden de creación de la fila (es decir, según el
orden en que los descubrió el monitor).
 En caso de falta de recursos, se elimina la fila más antigua asociada al interfaz.
GAR 5-24
Grupo host
hostControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF HostControlEntry
STATUS mandatory HostControlEntry ::= SEQUENCE {
DESCRIPTION hostControlIndex INTEGER (1..65535),
"A list of host table control entries." hostControlDataSource OBJECT
::= { hosts 1 } IDENTIFIER,
hostControlTableSize INTEGER,
hostControlEntry OBJECT-TYPE hostControlLastDeleteTime TimeTicks,
SYNTAX HostControlEntry hostControlOwner OwnerString,
ACCESS not-accessible hostControlStatus EntryStatus
STATUS mandatory }
DESCRIPTION
"A list of parameters that set up the discovery
……"
INDEX { hostControlIndex }
::= { hostControlTable 1 }
GAR 5-25

Grupo host
hostTable OBJECT-TYPE
SYNTAX SEQUENCE OF HostEntry
STATUS mandatory HostEntry ::= SEQUENCE {
DESCRIPTION hostAddress OCTET STRING,
"A list of host entries." hostCreationOrder INTEGER (1..65535),
::= { hosts 2 } hostIndex INTEGER (1..65535),
hostEntry OBJECT-TYPE hostInPkts Counter,
SYNTAX HostEntry hostOutPkts Counter,
ACCESS not-accessible hostInOctets Counter,
STATUS mandatory hostOutOctets Counter,
DESCRIPTION hostOutErrors Counter,
"A collection of statistics for a particular host hostOutBroadcastPkts Counter,
that has been discovered on an interface of this hostOutMulticastPkts Counter
device. For example, an instance of the }
hostOutBroadcastPkts object might be named
hostOutBroadcastPkts.1.6.8.0.32.27.3.176"
INDEX { hostIndex, hostAddress }
::= { hostTable 1 }
GAR 5-26
Grupo host
hostTimeTable OBJECT-TYPE
SYNTAX SEQUENCE OF HostTimeEntry
STATUS mandatory
HostTimeEntry ::= SEQUENCE {
DESCRIPTION
hostTimeAddress OCTET STRING,
"A list of time-ordered host table entries."
hostTimeCreationOrder INTEGER (1..65535),
hostTimeIndex INTEGER (1..65535),
::= { hosts 3 }
hostTimeInPkts Counter,
hostTimeOutPkts Counter,
hostTimeEntry OBJECT-TYPE
hostTimeInOctets Counter,
SYNTAX HostTimeEntry
hostTimeOutOctets Counter,
hostTimeOutErrors Counter,
STATUS mandatory
hostTimeOutBroadcastPkts Counter,
DESCRIPTION
hostTimeOutMulticastPkts Counter
"A collection of statistics for a particular host
}
that has been discovered on an interface of this
device. This collection includes the relative
ordering of the creation time of this object. For
example, an instance of the
hostTimeOutBroadcastPkts object might be named
hostTimeOutBroadcastPkts.1.687"
INDEX { hostTimeIndex, hostTimeCreationOrder }
::= { hostTimeTable 1 }
GAR 5-27

Grupo hostTopN
 Mantiene estadísticas sobre los hosts de una subred que encabezan una lista
basada en algún parámetro. Ejemplo: lista de los 10 hosts que transmiten la
mayor parte del tráfico en un día en particular.
 La estadísticas de este grupo se obtienen a partir de los datos del grupo host
 Al conjunto de estadísticas recogidas durante un intervalo de muestreo para un

objeto del grupo host en un interfaz o subred se le denomina informe (report)
◦ Cada informe (report) contiene resultados para una sola variable.
◦ El informe lista los hosts de una subred con la mayor tasa de cambio en una
variable particular.
GAR 5-28
Grupo hostTopN
 Este grupo consta de una tabla de control (hostTopNControlTable) y una

de datos (hostTopNTable)
◦ Un gestor crea una nueva fila en la tabla de control para especificar un
nuevo informe.
◦ Esta entrada de control hace que el monitor mida la diferencia entre los
valores inicial y final de una variable particular del grupo host durante un
período específico de muestreo.
◦ Una vez generado el informe, queda disponible para la estación de gestión
como datos de solo lectura.
GAR 5-29

Grupo hostTopN
hostTopNControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF HostTopNControlEntry HostTopNControlEntry ::= SEQUENCE {
ACCESS not-accessible hostTopNControlIndex INTEGER (1..65535),
STATUS mandatory hostTopNHostIndex INTEGER (1..65535),
DESCRIPTION hostTopNRateBase INTEGER,
"A list of top N host control entries." hostTopNTimeRemaining INTEGER,
::= { hostTopN 1 } hostTopNDuration INTEGER,
hostTopNControlEntry OBJECT-TYPE hostTopNRequestedSize INTEGER,
SYNTAX HostTopNControlEntry hostTopNGrantedSize INTEGER,
ACCESS not-accessible hostTopNStartTime TimeTicks,
STATUS mandatory hostTopNOwner OwnerString,
DESCRIPTION hostTopNStatus EntryStatus
"A set of parameters ….. " }
INDEX { hostTopNControlIndex }
::= { hostTopNControlTable 1 }
GAR 5-30
Grupo hostTopN
hostTopNTable OBJECT-TYPE
SYNTAX SEQUENCE OF HostTopNEntry
STATUS mandatory HostTopNEntry ::= SEQUENCE {
hostTopNReport INTEGER (1..65535),
DESCRIPTION
hostTopNIndex INTEGER (1..65535),
"A list of top N host entries."
hostTopNAddress OCTET STRING,
::= { hostTopN 2 }
hostTopNRate INTEGER
hostTopNEntry OBJECT-TYPE
}
SYNTAX HostTopNEntry
STATUS mandatory
DESCRIPTION
"A set of statistics for a host that is part of
a top N report. ….” INDEX {
hostTopNReport, hostTopNIndex }
GAR 5-31 ::= { hostTopNTable 1 }

Grupo matrix
 Este grupo se emplea para almacenar información sobre el tráfico entre

pares de hosts en una subred.
 La información se almacena de forma matricial, y se organiza en tres

tablas:
◦ matrixControlTable: matriz de control; cada una de sus filas identifica
conversaciones sobre una subred (un interfaz particular), almacenando las
estadísticas sobre ellas en las dos tablas de datos
◦ matrixSDTable y matrixDSTable: ambas contienen la misma información (un
par de entradas por cada par de hosts que intercambian información), pero
organizada de dos formas distintas:
 matrixDSTable almacena información indexada por el host origen
 Permite conocer fácilmente el tráfico originado en un host hacia los demás
 matrixSDTable la indexa por el host destino
 Permite conocer fácilmente el tráfico desde todos los hosts hacia un host en
particular
GAR 5-32
Grupo matrix
matrixControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF MatrixControlEntry
STATUS mandatory
MatrixControlEntry ::= SEQUENCE {
DESCRIPTION
matrixControlIndex INTEGER (1..65535),
"A list of information entries for the
matrixControlDataSource OBJECT IDENTIFIER,
traffic matrix on each interface."
::= { matrix 1 }
matrixControlTableSize INTEGER,
matrixControlEntry OBJECT-TYPE matrixControlLastDeleteTime TimeTicks,
SYNTAX MatrixControlEntry matrixControlOwner OwnerString,
ACCESS not-accessible matrixControlStatus EntryStatus
STATUS mandatory }
DESCRIPTION
"Information about a traffic matrix ….”
INDEX { matrixControlIndex }
::= { matrixControlTable 1 }
GAR 5-33

Grupo matrix
matrixSDTable OBJECT-TYPE MatrixSDEntry ::= SEQUENCE {
SYNTAX SEQUENCE OF MatrixSDEntry matrixSDSourceAddress OCTET STRING,
ACCESS not-accessible matrixSDDestAddress OCTET STRING,
STATUS mandatory matrixSDIndex INTEGER (1..65535),
DESCRIPTION matrixSDPkts Counter,
"A list of traffic matrix entries …." matrixSDOctets Counter,
::= { matrix 2 } matrixSDErrors Counter
matrixSDEntry OBJECT-TYPE }
SYNTAX MatrixSDEntry
 La tabla matrixDSTable se define
exactamente igual que matrixSDTable,
STATUS mandatory
pero se indexa por los campos
DESCRIPTION {matrixDSIndex, matrixDSDestAddress,
"A collection of statistics …. " matrixDSSourceAddress }
INDEX { matrixSDIndex, matrixSDSourceAddress,
matrixSDDestAddress }
::= { matrixSDTable 1 }
GAR 5-34
Grupo alarm
 Este grupo se emplea para definir un conjunto de umbrales sobre el

rendimiento de la red. Si se atraviesa el umbral en la dirección
apropiada se genera una alarma, y se envía a la consola central del SGR
 Consta de una única tabla alarmTable. En ella, Cada entrada de la

tabla especifica una variable particular a monitorizar, información de
control del proceso de muestreo y el valor muestreado más reciente.
GAR 5-35

Grupo alarm
alarmTable OBJECT-TYPE AlarmEntry ::= SEQUENCE {
SYNTAX SEQUENCE OF AlarmEntry alarmIndex INTEGER (1..65535),
ACCESS not-accessible alarmInterval INTEGER,
STATUS mandatory alarmVariable OBJECT IDENTIFIER,
DESCRIPTION alarmSampleType INTEGER,
"A list of alarm entries." alarmValue INTEGER,
::= { alarm 1 } alarmStartupAlarm INTEGER,
alarmEntry OBJECT-TYPE alarmRisingThreshold INTEGER,
alarmFallingThreshold INTEGER,
SYNTAX AlarmEntry
alarmRisingEventIndex INTEGER (0..65535),
alarmFallingEventIndex INTEGER (0..65535),
STATUS mandatory
alarmOwner OwnerString,
DESCRIPTION
alarmStatus EntryStatus
"A list of parameters…."
}
INDEX { alarmIndex }
::= { alarmTable 1 }
GAR 5-36
Grupo alarm
 ¿Cómo se define una alarma en RMON?

◦ Intervalo de muestreo (alarmInterval): Especifica el intervalo (seg) en que
evaluará la alarma.
◦ Variable a muestrear (alarmVariable): identificador de objeto de la variable

a muestrear. Puede ser cualquier variable de la MIB de tipo entero, counter,
gauge o TimeTicks.
◦ Tipo de muestreo (alarmSampleType): Fija el modo de muestreo, que

se comparatá con los umbrales. Puede ser:
 Absoluto (absoluteValue): Se compara el valor de la variable
 Delta (deltaValue): se compara la variación de la variable (diferencia entre el
valor actual y el del último muestreo).
GAR 5-37

Grupo alarm
 ¿Cómo se define una alarma en RMON?

◦ Valor (alarmValue): es el valor muestreado más reciente (lo escribe el
agente).
◦ Tipo de alarma (alarmStartupAlarm): Establece cuando se genera la
alarma.
 risingAlarm(1): cuando es mayor o igual que el umbral de subida.
 fallingAlarm(2): cuando es menor o igual que el umbral de bajada.
 risingOrFallingAlarm(3): en ambos casos.
◦ Umbral de subida (alarmRisingThreshold): Es el umbral de subida.
◦ Umbral de bajada (alarmFallingThreshold): es el umbral de bajada.
◦ Evento de subida (alarmRisingEventIndex): evento que se llamará (índice en
la tabla de eventos) cuando se atraviesa el umbral de subida.
◦ Evento de bajada (alarmFallingEventIndex): evento que se llamará (índice en
la tabla de eventos) cuando se atraviesa el umbral de bajada.
GAR 5-38
Grupo alarm
 Para evitar la activación de las alarmas con pequeñas fluctuaciones de la
variable muestreada, se implementa un mecanismo de histéresis.
◦ Sólo se podrá generar una alarma de subida, si previamente se ha superado
el umbral de bajada
◦ Sólo se podrá generar una alarma de bajada, si previamente se ha superado
el umbral de subida
 Ejemplo (alarmStartupAlarm = risingAlarm o risingOrFallingAlarm):
V a lo r = E v e n t o d e a la r m a
m u e s tre a d o
U m b ra l d e
s u b id a
U m b ra l d e
b a ja d a
GAR 5-39 T ie m p o

Grupo alarm
 Ejercicio: La variable cuyo comportamiento se muestra en la figura
adjunta se monitoriza empleando el grupo alarm de RMON. Indica
cuándo se generarán las alarmas si el objeto alarmStartupAlarm tiene el
valor risingOrFallingAlarm(3).
GAR 5-40
Grupo event
 Este grupo realiza la definición de eventos que serán llamados desde
otros grupos (alarm, filter).
 Un evento puede consistir en el envío de un TRAP, o el registro en una
tabla log (logTable).
 El grupo evento consta de una tabla de control (eventTable) y una de
datos (logTable)
 Cada fila de la tabla de control contiene una definición de evento:
◦ eventIndex: Número de evento
◦ eventType: qué acción se realiza ante la ocurrencia del evento
(ninguna, registrarlo en la tabla logTable, generar un trap SNMP, o
ambas cosas).
◦ eventText: Texto descriptivo del evento
 La tabla de datos contiene información acerca de cuándo ha ocurrido el
evento, y una descripción textual, dependiente de la implementación
GAR 5-41

Grupo event
eventTable OBJECT-TYPE EventEntry ::= SEQUENCE {
SYNTAX SEQUENCE OF EventEntry eventIndex INTEGER (1..65535),
ACCESS not-accessible eventDescription DisplayString (SIZE (0..127)),
eventType INTEGER,
STATUS mandatory
eventCommunity OCTET STRING (SIZE (0..127)),
DESCRIPTION
eventLastTimeSent TimeTicks,
"A list of events to be generated." eventOwner OwnerString,
::= { event 1 } eventStatus EntryStatus
eventEntry OBJECT-TYPE }
SYNTAX EventEntry
STATUS mandatory
DESCRIPTION
"A set of parameters that describe..”
INDEX { eventIndex }
::= { eventTable 1 }
GAR 5-42
Grupo event
logTable OBJECT-TYPE
SYNTAX SEQUENCE OF LogEntry LogEntry ::= SEQUENCE {
ACCESS not-accessible logEventIndex INTEGER (1..65535),
logIndex INTEGER (1..2147483647),
STATUS mandatory
logTime TimeTicks,
DESCRIPTION
logDescriptionDisplayString (SIZE (0..255))
"A list of events that have been logged." }
::= { event 2 }
logEntry OBJECT-TYPE
SYNTAX LogEntry
STATUS mandatory
DESCRIPTION
"A set of data describing an event …"
INDEX { logEventIndex, logIndex } (*)
::= { logTable 1 }
GAR 5-43
(*) Tiene dos índices: Número de evento y numeración de ese evento

Grupo alarm/event (ejercicio)
 Ejercicio: Se quiere controlar el número de paquetes de broadcast que
circulan por un segmento de red mediante un agente RMON. Para ello puede
usarse la variable EtherStatsBoradcastPkts (que es de tipo Counter) del grupo
statistics. Haciendo uso de los grupos alarm y evento.
Indica cómo debería configurarse el agente RMON para que se genere:
◦ el aviso “Broadcast elevado” cuando se supere el umbral de 1000 paquetes
de broadcast cada 10 segundos, y
◦ el aviso de “Broadcast excesivo” cuando se supere el umbral de 2000
broadcast cada 10 segundos.
Se considera que un valor aceptable es de 500 paquetes de broadcast cada 10
segundos. El aviso debe realizarse mediante el envío de un trap con la
comunidad “micomunidad”
GAR 5-44
 Hay que configurar adecuadamente los objetos de los grupos alarm y event
 Hay que definir dos alarmas y dos eventos, ya que se pide que generemos dos
eventos por acción de subida y eso no se puede hacer con una sola alarma (una
sola alarma puede definir como máximo, una de subida y una de bajada).
 Un ejemplo de definición es la siguiente:
Definición de la alarma 1 Definición de la alarma 2:
 alarmIndex= 1  alarmIndex= 2
 alarmInterval= 10  alarmInterval= 10
 alarmVariable: EtherStatsBoradcastPkts  alarmVariable: EtherStatsBoradcastPkts
 alarmSampleType: deltaValue  alarmSampleType: deltaValue
 alarmValue: --  alarmValue: --
 alarmStartupAlarm: risingAlarm  alarmStartupAlarm: risingAlarm
 alarmRisingThreshold: 1000  alarmRisingThreshold: 2000
 alarmFailingThreshold: 500  alarmFailingThreshold: 1000
 alarmRisingEventIndex: 1  alarmRisingEventIndex: 2
 alarmFailingEventIndex: 0  alarmFailingEventIndex: 0
 alarmOwner: gar  alarmOwner: gar
 alarmStatus: --  alarmStatus: --
GAR 5-45

Definición del evento 1: Definición del evento 2:
 eventIndex: 1  eventIndex: 2
 eventDescription: “Broadcast  eventDescription:”Broadcast
elevado” excesivo”
 eventType: snmptrap  eventType: snmptrap
 eventCommunity:comunidad  eventCommunity: micomunidad
 eventLastTimeSent: --  eventLastTimeSent: --
 eventOwner: gar  eventOwner: gar
 eventStatus: 1  eventStatus: 1
GAR 5-46
Grupo alarm/event
 Ejemplo de configuración: Configurar en un router CISCO la alarma
número 10. Debe monitorizar la variable de la MIB-II ifEntry.20.1 cada 20
segundos y comprobar la variación en el valor de la variable. Si el valor del
objeto ifEntry.20.1 se incrementa en un valor superior a 15, la alarma debe
dispararse, llamando al evento número 1, que debe enviar un TRAP a la
estación de gestión. Si la alarma se incrementa en cantidad 0 (valor de falling-
threshold), la alarma se resetea y puede ser generada de nuevo:
Albacete(config)# rmon alarm 10 ifEntry.20.1 20 delta rising-threshold

15 1 falling-threshold 0 owner gestor1
Albacete(config)# rmon event 1 trap comunidad “Alarma activada” owner

GAR
GAR 5-47

Grupo filter
 Permite definir filtros que se le aplicarán a los paquetes que curculen
por un interfaz particular.
 Se definen dos tipos de filtros, que se pueden combina con AND, OR…:
◦ Filtro de datos: se compara el contenido total o parcial del paquete.
◦ Filtro de estados: se compara el estado del paquete (válido, error CRC...).
 A la secuencia de paquetes que pasa el filtro se le denomina canal
 Además, se puede configurar el canal para:

◦ Generar un evento (definido en el grupo event) cuando ingrese un paquete.
◦ Almacenar los paquetes en el grupo RMON PacketCapture.
GAR 5-48
Grupo filter
 Este grupo consta de dos tablas:
◦ filterTable: define los filtros asociados a los canales
◦ channelTable: Cada fila define un único canal. Para cada canal hay una o más
filas de la tabla de filtros.
filterTable OBJECT-TYPE FilterEntry ::= SEQUENCE {
SYNTAX SEQUENCE OF FilterEntry filterIndex INTEGER (1..65535),
ACCESS not-accessible filterChannelIndex INTEGER (1..65535),
STATUS mandatory filterPktDataOffset INTEGER,
DESCRIPTION filterPktData OCTET STRING,
filterPktDataMask OCTET STRING,
"A list of packet filter entries."
filterPktDataNotMask OCTET STRING,
::= { filter 1 } filterPktStatus INTEGER,
filterEntry OBJECT-TYPE filterPktStatusMask INTEGER,
SYNTAX FilterEntry filterPktStatusNotMask INTEGER,
ACCESS not-accessible filterOwner OwnerString,
STATUS mandatory filterStatus EntryStatus
DESCRIPTION }
"A set of parameters for a packet filter …. “
INDEX { filterIndex }
GAR 5-49 ::= { filterTable 1 }

Grupo filter
channelTable OBJECT-TYPE ChannelEntry ::= SEQUENCE {
SYNTAX SEQUENCE OF ChannelEntry channelIndex INTEGER (1..65535),
ACCESS not-accessible channelIfIndex INTEGER (1..65535),
STATUS mandatory channelAcceptType INTEGER,

channelDataControl INTEGER,
DESCRIPTION
channelTurnOnEventIndex INTEGER (0..65535),
"A list of packet channel entries."
channelTurnOffEventIndex INTEGER (0..65535),
::= { filter 2 }
channelEventIndex INTEGER (0..65535),
channelEntry OBJECT-TYPE
channelEventStatus INTEGER,
SYNTAX ChannelEntry channelMatches Counter,
ACCESS not-accessible channelDescription DisplayString (SIZE (0..127)),
STATUS mandatory channelOwner OwnerString,
DESCRIPTION channelStatus EntryStatus
"A set of parameters for a packet channel }
..” INDEX { channelIndex }
::= { channelTable 1 }
GAR 5-50
Grupo filter
 Funcionamiento de un filtro:
◦ Se compara el paquete (desplazado según el valor de filterPktDataOffset)
con filterPktData
 Cada bit a 1 en filterPktDataMask indica la posición de los bits que
son relevantes para el test
 Cada bit a 0 en filterPktDataNotMask indica la posición de los bits que
deben coincidir para pasar el test
◦ Cada bit a 1 en filterPktDataNotMask indica la posición de los bits que
NO deben coincidir para pasar el test.
GAR 5-51

Grupo filter
filterPktDataOffset
Input Packet
1 filterPktData filterPktDataMask 3
Bitwise XOR
2
Bitwise AND 5 filterPktDataNotMask
Bitwise NOT
6 Bitwise AND 7 Bitwise AND
Pasa si todos los bits son0 Pasa si todos los bits son 1
(pass if match) (pass if mismatch)
GAR 5-52
Grupo filter
 Ejercicio 1: Se desea filtrar todos los paquetes cuya dirección destino termine
en A5 y cuya dirección origen no termine en BB
filterPktDataOffset Input Packet
Bitwise XOR
2
Bitwise NOT
GAR 5-53

Grupo filter
Bitwise XOR
2
Bitwise NOT
GAR 5-54
Grupo filter
Bitwise XOR
2
Bitwise NOT
GAR 5-55

Grupo packet capture
 Este grupo implementa buffers en los que se pueden almacenar los
paquetes que lleguen al canal.
 Consta de dos tablas:

◦ bufferControlTable: especifica los detalles de la función de buffering.
Cada fila de esta tabla define un buffer
◦ captureBufferTable: almacena los datos del buffer
bufferControl
Table
DEFINICION
DEL FILTRO
PACKET capureBufferTable
CAPTURE
FILTER CANAL
DATOS DATOS
GAR 5-56
bufferControlTable OBJECT-TYPE BufferControlEntry ::= SEQUENCE {
SYNTAX SEQUENCE OF BufferControlEntry bufferControlIndex INTEGER (1..65535),
ACCESS not-accessible bufferControlChannelIndex INTEGER (1..65535),
STATUS mandatory bufferControlFullStatus INTEGER,
bufferControlFullAction INTEGER,
DESCRIPTION
bufferControlCaptureSliceSize INTEGER,
"A list of buffers control entries."
bufferControlDownloadSliceSize INTEGER,
::= { capture 1 }
bufferControlDownloadOffset INTEGER,
bufferControlEntry OBJECT-TYPE
bufferControlMaxOctetsRequested INTEGER,
SYNTAX BufferControlEntry bufferControlMaxOctetsGranted INTEGER,
ACCESS not-accessible bufferControlCapturedPackets INTEGER,
STATUS mandatory bufferControlTurnOnTime TimeTicks,
DESCRIPTION bufferControlOwner OwnerString,
"A set of parameters that control…” bufferControlStatus EntryStatus
INDEX { bufferControlIndex } }
::= { bufferControlTable 1 }
GAR 5-57

captureBufferTable OBJECT-TYPE
CaptureBufferEntry ::= SEQUENCE {
SYNTAX SEQUENCE OF CaptureBufferEntry
captureBufferControlIndex INTEGER (1..65535),
captureBufferIndex INTEGER (1..2147483647),
STATUS mandatory
captureBufferPacketID INTEGER,
DESCRIPTION
captureBufferPacketData OCTET STRING,
"A list of packets captured off of a channel."
captureBufferPacketLength INTEGER,
::= { capture 2 }
captureBufferPacketTime INTEGER,
captureBufferEntry OBJECT-TYPE
captureBufferPacketStatus INTEGER
SYNTAX CaptureBufferEntry
}
STATUS mandatory
DESCRIPTION
"A packet captured off …."
INDEX { captureBufferControlIndex,
captureBufferIndex }
::= { captureBufferTable 1 }
GAR 5-58
RESUMEN
statistics
host
ESTADISTICAS hostTopN
Matrix
MONITORIZACION
PUERTO
ETHERNET HISTORICOS history
RMON
Log
MONITORIZACION
Alarm Event Trap
VARIABLES
Log + trap
MIBs
Filter packet cature
Alarma 1 Evento 1 Trap
Alarma 2 Evento 2 Log
Alarma 3 Evento 3
GAR 5-59 Alarma 4 Evento 4

RMON2
 RMON2 es una extensión de la MIB de RMON para contemplar la
monitorización del tráfico de protocolos por encima del la capa 2
(enlace de datos). Por tanto RMON2 es papaz de:
◦ Monitorizar información de la red extremo-extremo (capa de red).
◦ Monitorizar información de las aplicaciones (capa de aplicación).
 RMON2 añade 9 grupos nuevos a la rama MIB de RMON

◦ protocolDir: relación de protocolos que puede interpretar este agente.
◦ protocolDist: estadísticas de tráfico por protocolo en cada segmento LAN.
◦ addressMap: Asocia dirección MAC con dirección de red.
◦ nlHost: Estadísticas de tráfico por host en la capa de red.
◦ nlMatrix: Estadísticas de tráfico por parejas de host en la capa de red.
◦ alHost: Estadísticas de tráfico por aplicación desde un host.
◦ alMatrix: Estadisticas de tráfico por aplicación entre pares de hosts.
◦ usrHistory: Muestrea variables y genera alarmas en capa de red.
GAR 5-60 ◦ probeConfig: Define la capacidad del agente (grupos que implementa).
RMON2
RMON RMON2
GAR 5-61
4.3 Monitorización de flujos
 El tráfico de una red está compuesto por flujos de datos (un flujo es una
secuencia unidireccional de paquetes pertenecientes a una misma
conexión).
 Mediante SNMP es posible obtener información en interfaces de
dispositivos de la red y mediante RMON es posible obtener datos
estadísticos en subredes, pero de forma agregada, ya que ambos se basan
en el análisis de paquetes individuales y no consideran la relación
existentes entre distintos paquetes.
 Por tanto, es importante disponer de otros mecanismos que nos
permitan monitorizar flujos de datos, ya que SNMP y RMON no pueden
hacerlo.
GAR 5-62
Monitorización de flujos
NetFlow
 NetFlow es un protocolo desarrollado por CISCO que recopila

información de flujos de tráfico IP
 Para Netflow, un flujo es una secuencia unidireccional de paquetes que
comparten:
◦ Dirección IP origen.
◦ Dirección IP destino.
◦ Puerto de origen para UDP o TCP, ó “0” para otros protocolos.
◦ Puerto de destino para UDP o TCP, ó “0” para otros protocolos
◦ Protocolo IP
◦ Interfaz de Ingreso (SNMP ifIndex)
◦ Tipo de Servicio (ToS) IP
GAR 5-63
NetFlow
 NetFlow recopila información de los distintos flujos que atraviesan un

dispositivo de red. Entre otra:
◦ Identificación del flujo: protocolo, IP origen/destino, puerto, etc.
◦ Número de paquetes, bytes, etc.
◦ Tiempos de inicio y finalización del flujo.
◦ Información adicional
 Netflow sólo registra datos del volumen de trafico, no observa el
contenido de los paquetes.
 Netflow ofrece al administrador información sobre:
◦ El tráfico en la red (que protocolos se usan más en la red, quién carga
más la red, que tamaños de paquete circulan por la red, etc.)
◦ Anomalías (ayuda a su localización y caracterización)
GAR 5-64 ◦ Etc.
NetFlow
 Una arquitectura NetFlow está compuesta por tres componentes:

◦ Exportador (exporter): Obtiene datos del tráfico IP y los envía al colector
mediante el protocolo Netflow. Muchos routers soportan esta capacidad en
su sistema operativo.
◦ Colector (collector): Almacena y procesa los datos enviados por el
explorador.
◦ Analizador (analyzer): Analiza los datos almacenados, generando estadísticas
e informes. Hay muchas herramientas que realizan estos análisis
GAR 5-65
NetFlow
 Ejemplo de configuración (cisco) con un router exportador que obtiene
datos bidireccionales de dos interfaces y un colector.
Serial0/1 Serial0/2
Exportador
Colector
192.168.1.26
Router2(config)#interface serial0/1
Router(config-if)# ip flow ingress
Router(config-if)# ip flow egress
Router(config-if)# exit
Router(config)# interface serial0/2

Router(config-if)# ip flow ingress
Router(config-if)# ip flow egress
Router(config-if)# exit
Router(config)# ip flow-export destination 192.168.1.26 9996

GAR 5-66 Router(config)# ip flow-export versión 9
NetFlow
 Existen numerosas herramientas que analizan los datos de NetFlow
almacenados en el colector.
◦ Ejemplo: ManageEngine NetFlow Analyzer (https://www.manageengine.com/products/netflow)
GAR 5-67

GAR Temas4y5

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

GAR Temas4y5

Cargado por

Copyright:

Formatos disponibles

TEMA 4

 Inicialmente no se pensó incluir soporte para la gestión de redes

 Con el incremento de la implantación de las redes:

 Un agente SNMP soporta dos tipos de transacciones:

 La MIB (Management Information Base) es un conjunto

 Es un protocolo de capa de aplicación que realiza la comunicación entre

 GetResponse: Es la respuesta. Incluye los datos pedidos o un código de

error, para las operaciones Get

ocurrencia de eventos. Se implementa con un servicio.

SNMP usa UDP y se implementa con dos procesos:

 Una estación de gestión puede realizar sondeos a los agentes para

 SNMP puede usar un agente proxy, para interactuar con

 Un agente SNMP puede comunicarse con subagentes. El agente

 La estación de gestión se comunica con el agente maestro, y éste,

 Comunidad: Es una relación entre un agente SNMP y un

 Se puede limitar el acceso a la MIB de un agente en dos formas:

◦ Modo de acceso: READ-ONLY (RO) o READ-WRITE (RW)

 Perfil de comunidad = Vista MIB + Modo de acceso

 Política de acceso: Perfil de comunidad + Comunidad

 Un agente sólo atiende una petición si la política de acceso es adecuada

 El uso de políticas de acceso es un esquema de seguridad muy limitado

 Ejemplos de políticas de acceso: Cualquier gestor puede leer

Cualquier gestor puede escribir

 Todos los paquetes (PDU) de SNMP comienzan por dos

PDU d e GetR esp o ns e

Asig na ción d e variab les

 Enterprise: Valor de objeto sysObjectID del agente que genera el trap

 La MIB (Management Information Base) es una base de datos que

◦ Cada agente dispone de una MIB

 La SMI (Structure of Management Information) describe cómo se definen

 Los tipos de datos tienen una etiqueta asociada

 En la MIB se utiliza un esquema jerárquico de nombres que forma un

 Identificador de objeto (OID):

 Cada nodo representa un recurso, actividad o información

 De iso cuelgan nodos para distintas organizaciones (org (3)).

 En dod hay un nodo administrado por el IAB (internet (1)):

 Dentro del nodo internet, se

documentos aprobados por el IAB dod(6)

objetos experimentales. system(1) snmp(11)

definidos por empresas

 Ejemplo: MIBs específicas de una impresora HP: 1.3.6.1.4.1.11

 Alternativas para añadir nuevos objetos en la MIB:

◦ Construcción de una MIB experimental, para una aplicación

◦ Extensiones privadas en el subárbol private: Dentro de

 Cada objeto dentro de la MIB tiene una definición formal que

 Se emplea la sintaxis ASN.1 y en la codificación, las reglas de

 Ejemplo: objeto tmpMaxConn.

 SMI sólo permite estructurar los datos como tablas

 Ejemplo: Tabla con las conexiones TCP de un dispositivo

 Definición del objeto tabla:

 Definición del objeto fila: INDEX { tcpConnLocalAddress,

ACCESS not-accessible tcpConnRemPort }

 Definición de los campos

 Ejemplo: para tcpConnTable, el índice está formado por el

tcpConn- tcpConn- tcpConn- tcpConn-

 La instancia del objeto tcpConnState de la última fila es:

 Objetos ifNumber e ifTable

 Para cada interfaz proporciona información sobre:

 Información para la gestión de fallos:

 Proporciona datos estadísticos

 Estadísticas de conexiones: activas,

 Estadísticas sobre envío y