Gestion de redes

1,679 views
1,533 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,679
On SlideShare
0
From Embeds
0
Number of Embeds
33
Actions
Shares
0
Downloads
131
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Gestion de redes

  1. 1. IntroducciónPlanificación de la Gestión de RedFuncionalidad de la Gestión de RedArquitectura TMNModelo de Gestión de Red OSIModelo de Gestión de Red de InternetSistemas de Gestión IntegradaPlataformas de Gestión
  2. 2. Introducción Planificación de la Gestión de Red Funcionalidad de la Gestión de Red Arquitectura TMN Modelo de Gestión de Red OSI Modelo de Gestión de Red de Internet Sistemas de Gestión Integrada Plataformas de Gestión
  3. 3. Planificación, organización, supervisión ycontrol de elementos de comunicacionespara garantizar un nivel de servicio, deacuerdo a un coste y a un presupuesto,utilizando los recursos de forma óptima yeficaz.
  4. 4. Contol de activos estratégicos corporativosControl de complejidadMejorar el servicioEquilibrar necesidadesReducir indisponibilidadControl de costes
  5. 5. Para qué se usa la red? • E-Commerce = • VPNs / Voice over IP • Carrier Hosted Applications Qué lo hace funcionar? • Gestión de red = • Directory Enabled, Policy-based • QoS & SLAs Preside Sobre qué funciona? • Passport, Optera, etc. = • Next Generation Switches • High Speed Access PP 15000El sistema de gestión debe permitir crear, OPTera Packet gestionar y entregar servicios de valor Core añadido
  6. 6. Indisponibilidad evitable Falta de rendimiento Indisponibilidad inevitable 1 2 Capacidad Total Utilización Real1. Mejorar la disponibilidad2. Incrementar la efectividad
  7. 7.  Introducción Planificación de la Gestión de Red Funcionalidad de la Gestión de Red Arquitectura TMN Modelo de Gestión de Red OSI Modelo de Gestión de Red de Internet Sistemas de Gestión Integrada Plataformas de Gestión
  8. 8. Recursos humanos Operadores Administradores Analistas PlanificadoresProcesos y ProcedimientosHerramientas
  9. 9. Recursos humanos Operadores Administradores Analistas PlanificadoresProcesos y ProcedimientosHerramientas
  10. 10. Soporte a usuarios (help desk)Soporte técnicoRecogida y evaluación de alarmasRecogida de datos sobre prestaciones yutilizaciónArranque y parada de los componentes deredEjecución programada de pruebaspreventivasModificación de configuracionesCarga de nuevas versiones de software
  11. 11. Gestión de inventario Gestión de configuraciones Gestión de contabilidad Gestión de seguridad: control de acceso, etc. Mantenimiento de registro histórico de problemas Evaluación de tráfico y calidad de servicioControl de operadores: Herramientas de seguimiento de actualesincidencias que permitan conocer el estado actual deincidencias y elaborar informes de actividad operacional parasu posterior análisis
  12. 12. Definición de indicadores deprestaciones: calidad de servicioAnálisis global de la calidad de servicioToma de decisiones para corregirdesviaciones de la calidad de servicioPreparación de procedimientos deoperadores y administradores Su objetivo es garantizar la calidad de servicio
  13. 13. Análisis de informes técnico-económicos(anuales)Establecimiento de política detelecomunicacionesAsignación de presupuestoSelección de criterios de distribución decostes o facturación Decisiones dependientes del negocio al que se dedica la empresa
  14. 14. Recursos humanos Operadores Administradores Analistas PlanificadoresProcesos y ProcedimientosHerramientas
  15. 15. Procesos y procedimientos: Cinco grandesáreas funcionales (FCAPS) Gestión de Fallos y Supervisión Gestión de Configuración Gestión de Contabilidad Gestión de Prestaciones Gestión de Seguridad
  16. 16. Recursos humanos Operadores Administradores Analistas PlanificadoresProcesos y ProcedimientosHerramientas
  17. 17. Herramientas: Elementos de red Gestores de elementos Sistemas de gestión integrada
  18. 18.  Introducción Planificación de la Gestión de Red Funcionalidad de la Gestión de Red Arquitectura TMN Modelo de Gestión de Red OSI Modelo de Gestión de Red de Internet Sistemas de Gestión Integrada Plataformas de Gestión
  19. 19. No existe funcionalidad común. Dependede: Tipo de red gestionada Tipo de equipos gestionados Objetivos específicos de la gestión de redA bajo nivel, todos los métodos se basanen: Monitorización de red:  Gestión de prestaciones  Gestión de fallos  Gestión de contabilidad  Gestión de configuraciones Control de red:
  20. 20. 4 fases para la monitorización de unared: Definición de la información de gestión que se monitoriza Acceso a la información de monitorización Diseño de mecanismos de monitorización Procesado de la información de monitorizaciónControl de red: fases de definición yacceso.
  21. 21. De acuerdo a su naturaleza, existen lossiguientes tipos: Información estática: no cambia con la actividad de la red. Información dinámica: evoluciona con la propia actividad de la red Información estadística: postprocesado de la información dinámica que proporciona un mayor significado de gestión
  22. 22. ¿Qué información monitorizar? Dependede la aplicación: Para gestión de prestaciones: información estadística, generada a partir de información dinámica (tráfico, retardo, etc.) Para gestión de fallos: información dinámica (cambios de estados) Para gestión de configuraciones: información estática (inventario de la red)
  23. 23. Objetivo: monitorización remota de losrecursos desde el centro de gestiónNecesita una cooperación entre losgestores y los equipos gestionados Los equipos deben “querer ser gestionados”: instalación del software de gestión adecuadoMétodo común de acceso a lainformación de gestión,independientemente de la tecnología ofabricante del equipo monitorizadoModelos de gestión de red integrada: proporcionan la interoperabilidad
  24. 24. Sondeo o polling: acceso periódico a lainformación de gestión. Ventaja: Los objetos solo deben estar preparados para responder: simplicidadEvent Reporting o notificaciones: lospropios recursos envían notificacionessbajo ciertas condiciones. Ventaja: se minimiza el tráfico de gestión por la red. Dos filosofías de gestión: Descargar la complejidad hacia los gestores Balancear complejidad entre gestores y equipos gestionados
  25. 25. Monitorización de una red: Definición de la información de gestión que se monitoriza Acceso a la información de monitorización Diseño de mecanismos de monitorización Procesado de la información de monitorización: Aplicaciones de Gestión asociadas  Gestión de Configuración  Gestión de Fallos  Gestión de Prestaciones  Gestión de Contabilidad  Gestión de Seguridad
  26. 26. Gestión de configuración de los elementos dered: Herramientas de configuración gráficas y CLI Herramientas de configuración masiva y nodalGestión de Inventario: Herramientas de autodescubrimiento Combinación con herramientas CAD de gestión de cableado. Base de datos utilizable por el resto de funcionesGestión de Topología Herramientas de autotopología Necesidad de distintas vistas topológicasGestión de Servicios de Directorio
  27. 27. Gestión de SLAs (Service LevelAgreements): Contrato entrecliente/proveedor o entre proveedoressobre servicios a proporcionar ycalidades asociadas. Identificación de las partes contractuales Identificación del trabajo a realizar Objetivos de niveles de servicio Niveles de servicio proporcionados Multas por incumplimiento Fecha de caducidad Cláusulas de renegociación Prestaciones actuales proporcionadas
  28. 28. Gestión de Proveedores Externos (órdenes deprocesamiento / aprovisionamiento)Gestión de Cambios (reconfiguraciones) NOPetición Estudio Plan de Aprobaciónusuario impacto Cambio SI Planificación Inventario Documentación Ejecución
  29. 29. Objetivo: mantener dinámicamente elnivel de servicioGestión proactiva: evitar fallosdetectando “tendencias” hacia fallos Caracterización de tendencias: determinación de umbrales de ciertos parámetros Objetivo: monitorizar estos umbrales o programar notificaciones automáticasGestión reactiva: asumir que existenfallos inevitables Detectar lo antes posible el fallo Monitorización periódica (no es posible notificación)
  30. 30. Gestión del ciclo de vida de incidencias Detección de problema  Alarma de usuarios  Alarma de herramientas Determinación del problema  La información sobre el fallo puede no ser fiable en cuanto a la fuente del fallo Diagnosis del problema: procedimentado Resolución del problema  Por operadores de help-desk (80-85%)  Por operadores técnicos (5-10%)  Por especialistas en comunicaciones (2-5%)  Por especialistas en aplicaciones (1-3%)  Por fabricantes (1-2%)
  31. 31. Gestión de incidencias: TTS (TroubleTicket Systems) Fecha / Hora de:  Informe de incidencia  Resolución de incidencia Usuario / localización Equipo afectado Descripción problema ESTADO Operador (es) Grado de severidad Historial de incidencia Comentarios
  32. 32. Gestión de Pruebas preventivas Pruebas de conectividad Pruebas de integridad de datos Pruebas de integridad de protocolos Pruebas de saturación de datos Pruebas de saturación de conexiones Pruebas de tiempo de respuesta Pruebas de bucle Pruebas de diagnóstico
  33. 33. Definición de indicadores deprestaciones: Orientados a servicio  Disponibilidad  Tiempo de Respuesta  Fiabilidad Orientados a eficiencia  Throughput  Utilización Monitorización de indicadores de prestaciones Análisis y refinamiento
  34. 34. Parámetro necesario: disponibilidad de losserviciosEs necesario traducirlo a disponibilidad decomponentes individualesObjetivo: maximizar (cumplir) la disponibilidadde los equipos MTBF MTBF: Mean Time Between Failures D= MTTR: Mean Time To Repair MTBF + MTTR MTBF: Indicador de la calidad del equipo MTTR: Influye: Tiempo de detección del fallo Política de mantenimiento utilizada
  35. 35. Tiempo de Respuesta: rangos. >15 s: inaceptable para servicios interactivos >4 s: dificultan servicios interactivos encadenados (con memoria del usuario) 2 a 4 s: dificultan servicios interactivos que requieren concentración del usuario 2 s: límite aceptable normalmente Décimas de segundo: para aplicaciones de tipo gráfico <0.1 s: servicios de ecoComponentes: Tiempo de transmisión (ida y vuelta) Tiempo de proceso de servicio
  36. 36. Fiabilidad: Monitorización de errores: síntomas de fallos.Throughput: Medida de eficiencia de servicio Ej: número de transacciones por minuto, número de llamadas cursadas, etc.Utilización: Porcentaje de uso de un recurso durante un periodo de tiempo. Ej: Utilización de una línea serie, utilización de una Ethernet, etc.
  37. 37. Monitorización de Indicadores dePrestaciones Disponibilidad: sondeos de estado Tiempo de respuesta:  Tiempo de transmisión: utilización de ecos remotos  Tiempo de procesamiento: trazado por aplicaciones Fiabilidad: umbrales de porcentajes de error Utilización: trazado por aplicaciones Throughput: sondas de tráfico, etc.Análisis y Refinamiento
  38. 38. Identificación de Componentes de CosteEstablecimiento de políticas de tarificaciónDefinición de procedimientos paratarificaciónGestión de facturasIntegración con la contabilidadempresarial.
  39. 39. Funciones que proporcionan proteccióncontinuada de la red y sus componentesen los distintos aspectos de seguridad: Acceso a las redes Acceso a los sistemas Acceso a la información en tránsitoFunciones de la gestión de seguridad: Definición de análisis de riesgo y política de seguridad Implantación de servicios de seguridad e infraestructura asociada Definición de alarmas, registros e informes de seguridad
  40. 40.  Introducción Planificación de la Gestión de Red Funcionalidad de la Gestión de Red Arquitectura TMN Modelo de Gestión de Red OSI Modelo de Gestión de Red de Internet Sistemas de Gestión Integrada Plataformas de Gestión
  41. 41. ITU – T Arquitectura TMN ISO Modelo de Gestión OSI Internet Modelo de Gestión InternetOrígenes: TMN: Gestión de las redes de telecomunicación Gestión OSI: Gestión de la torre de protocolos OSI Gestión Internet: Gestión de routers
  42. 42. Heterogeneidad en la tecnología de redesde telecomunicación: Redes analógicas Redes digitales banda estrecha Redes digitales banda ancha.......Demandas sobre: Posibilidad de introducir nuevos servicios Alta calidad de servicios Posibilidad de reorganizar las redes Métodos eficientes de trabajo para operar las redes Competencia entre empresas operadoras privadas.
  43. 43. Proporcionar una estructura de red organizada paraconseguir la interconexión de los diversos tipos deSistemas de Operación y equipos detelecomunicación usando una arquitectura estándare interfaces normalizadas. Arquitectura física: estructura y entidades de la red Modelo organizativo: Niveles de gestión Modelo funcional: servicios, componentes y funciones de gestión Modelo de información: definición de recursos gestionados
  44. 44. TMN OS OS OS DCN EXCH TRANS EXCH TRANS EXCH Red de Telecomunicación
  45. 45. Objetivo: diseñar una red que permitainterconectar sistemas de operación conelementos de red.Requisitos: Todos los sistemas de operación deberán usar el mismo método para acceder a los recursos Se debe respetar la heterogeneidad y capacidad de los recursos de telecomunicaciones Interconexión con:  Otros dominios de gestión  Estaciones de trabajo de operadores
  46. 46. Interfaces Q: Comunicación entreentidades internas de TMN Interfaces Qx: MD MD,NE,QA Interfaces Q3: OS MD,NE,QA,OSInterfaz F: WS OS,MDInterfaz X: TMN TMN
  47. 47. TMN Sistemas de operación Q3/F/X Estaciones de trabajo Red de comunicación FX de datos Q3/F Dispositivos de mediación Q3 Q3 QX Red de comunicación de datos Adaptadores a QX QX QX Interfaz Q Elementos de red
  48. 48. Elementos de redGestión de elementos de redGestión de redGestión de serviciosGestión empresarial (negocio, comercio)
  49. 49. Gestión de elementos de red: Control y Coordinación de un subconjunto de elementos de red. Mantenimiento de datos estadísticos, registros y otros datos acerca de un conjunto de elementos de redGestión de red: Control y coordinación desde el punto de vista de la red. Suministro, cese o modificación de capacidades de red. Mantenimiento de capacidades de red Mantenimiento de datos estadísticos y registros de red
  50. 50. Gestión de servicios: Relaciones con el cliente e interfaz con otras administraciones Interacción con proveedores de servicio Mantenimiento de datos estadísticos (ej: QoS) Interacción entre serviciosGestión empresarial: Soporte para proceso de toma de decisiones de inversión y utilización óptima Soporte de gestión de presupuesto de telecomunicaciones Soporte de suministro y demanda de mano de obra
  51. 51. Capa de gestión OS OS empresarial empresarialCapa de gestión OS OS de servicios de serviciosCapa de gestión OS OS de red de red Capa de gestión MD OS de elementosde elementos de de red red Capa de NE Elementos de redelementos de red
  52. 52. Servicio de Servicio de Servicio de gestión gestión gestiónConjunto de Funciones Conjunto de Funciones de Gestión de GestiónFunción de Función de Función gestión gestión Función de Función de de gestión gestión gestiónFunción de Función de gestión gestión Funciones de Gestión de Sistemas OSI (MF)
  53. 53. Administración de abonadosAdministración de provisión de redGestión de PersonalGestión de Tarificación y ContabilidadAdministración de Calidad de Servicio yPrestaciones de RedAdministración de medidas y análisis detráficoGestión de seguridadGestión de TráficoGestión de mantenimiento
  54. 54. Tareas necesarias para proporcionar unservicio de gestiónEjemplo: Servicio de monitorización deprestaciones Establecimiento de objetivo de prestaciones de QoS Comprobación de prestaciones de QoS Establecimiento de objetivos de prestaciones de red Comprobación de prestaciones de red Criterios de calidad de servicio del cliente Comprobación de prestaciones de Elementos de Red
  55. 55. Garantiza la interoperabilidad entre lossistemas de operación y los elementos dered.Está compuesto por: Protocolo de comunicaciones : CMIP Conocimiento de Gestión Compartida (SMK) entre los extremos del interfaz: MIBs GDMO
  56. 56.  Introducción Planificación de la Gestión de Red Funcionalidad de la Gestión de Red Arquitectura TMN Modelo de Gestión de Red OSI Modelo de Gestión de Red de Internet Sistemas de Gestión Integrada Plataformas de Gestión
  57. 57. Origen: Diseñado para realizar la gestión dela torre de protocolos OSI El agente reside en un ordenadorLa complejidad de gestión se traslada alagente: Se descargan responsabilidades de gestión sobre los agentes (notificaciones) El protocolo de gestión permite realizar operaciones complejas El modelo de información es también complejoEvolución: Soporte para realizar gestiónintegrada en entornos heterogéneos
  58. 58. PROCESO PROCESOGESTOR AGENTE Operaciones RemotasNIVEL 7 NIVEL 7 NotificacionesNIVEL 6 NIVEL 6NIVEL 5 NIVEL 5 Protocolo de GestiónNIVEL 4 NIVEL 4NIVEL 3 NIVEL 3NIVEL 2 NIVEL 2NIVEL 1 NIVEL 1 Objetos Gestionados (MIB)
  59. 59. Las necesidades de normalización de lagestión de sistemas se exponen en 4modelos: Modelo de comunicaciones: se detalla el protocolo de gestión y el servicio que proporciona Modelo de información: se definen los recursos de red usando una sintaxis abstracta Modelo funcional: se definen las funciones de gestión que proporcionan una interfaz a la aplicación de gestión Modelo de organización: se exponen los posibles subdivisiones de la red en dominios de gestión.
  60. 60. Las normas ISO sobre gestión de red OSIse agrupan en 4 conjuntos: Normas sobre el entorno global de gestión OSI y su subdivisión en modelos Normas sobre el modelo de comunicaciones Normas sobre las funciones de gestión de sistemas Normas sobre la definición del modelo de información
  61. 61. Sobre gestión OSI en general: ISO 7498-4: OSI Basic Reference Model. Part 4: Management Framework (X.700) ISO 10040: Systems Management Overview (X.701)Sobre el modelo de comunicaciones: ISO 9595: Common Management Information Service (CMIS) Definition (X.710) ISO 9596: Common Management Information Protocol (CMIP) Specification (X.711)
  62. 62. Sobre el modelo de información: ISO 10165-1: Structure of Management Information. Part 1: Management Information Model (X.720) ISO 10165-2: Structure of Management Information. Part 2: Definition of Management Information (X.721) ISO 10165-4: Structure of Management Information. Part 4: Giudelines for the definition of Management Information (X.722) ISO 10165-5: Structure of Management Information. Part 5: Generic Management Information (X.723)
  63. 63. Sobre el modelo funcional: Definiciones defunciones de gestión: ISO 10164-1: Object management function (X.730) ISO 10164-2: State management function (X.731) ISO 10164-3: Attributes for representing relationships (X.732) ISO 10164-4: Alarm reporting function (X.733) ISO 10164-5: Event report management function (X.734) ISO 10164-6: Log control function (X.735) ISO 10164-7: Security alarm reporting function (X.736) ISO 10164-8: Security audit trail function (X.740) etc
  64. 64. Existen 5 áreas en las que tradicionalmentese ha dividido la gestión (FCAPS): Gestión de Fallos Gestión de Configuración Gestión de contAbilidad Gestión de Prestaciones Gestión de Seguridad
  65. 65. Las áreas  Object management functionfuncionales se  State Management functionrefinan en  Attributes for representingfunciones de relationshipsgestión  Alarm Reporting Function  Event Management Function  Log Control FunctionISO ha  Security Alarm Reporting Functionnormalizado  Security Audit Trail Functiondiversas funciones  Objects and Attributes for Accessde gestión Control  Accounting Meter Function  Workload Monitoring Function  Test Management Function  Measurement Summarization
  66. 66. Proceso Proceso Gestor Gestor MF MF MF MF MFMF MF MF Protocolo de Gestión Gestión de Gestión de Fallos Contabilidad
  67. 67. Dominios de Gestión: necesidad de dividir elentorno en base a dos motivos principales: Políticas funcionales (Ej: Dominios con una misma política de seguridad, contabilidad, etc...) Otras políticas: dominios geográficos, tecnológicos, etc...Dominio Administrativo: necesidad deestablecer y mantener las responsabilidadesde cada dominio.
  68. 68. Se define dentro del nivel de aplicación de OSIEntidad de Aplicación de Gestión de Sistemas(SMAE) SMASE: Specific Management Application SMASE Service Element CMISE: Common CMISE Management Information Service Element ACSE: Association Control ACSE ROSE Service Element ROSE: Remote Operations Service Element
  69. 69. Establece y finaliza asociaciones para elintercambio de información de gestiónCampo Application Context, especifica el tipode conexión solicitada. Para gestión de red: Manager: Gestor hacia Agente Agent: Agente hacia Gestor (para notificaciones)Usado directamente por el usuario de gestiónServicios utilizados: A-ASSOCIATE: Solicitud de conexión A-RELEASE: Liberación Normal de conexión A-ABORT: Liberación Anormal de conexión
  70. 70. Usado solo por CMISE para la solicitud deejecución de operaciones remotasEl gestor solicita una operación remota; el agentelo intenta ejecutar y devuelve el resultado delintentoUsado por aplicaciones tipo cliente-servidor.Servicios utilizados:  RO-INVOKE: Transporte de una petición de operación  RO-RESULT: Transporte del resultado de una operación  RO-ERROR: Transporte de error de una operación  RO-REJECT: Rechazo de la petición
  71. 71. CMISE: Common Management InformationService ElementProporciona tres tipos de servicio: Manejo de datos: usado por el gestor para solicitar y alterar información de los recursos del agente Informe de sucesos: usado por el agente para informar al gestor sobre diversos sucesos de interés Control Directo: usado por el gestor para solicitar la ejecución de diversas acciones en el agenteHace uso del servicio de operacionesremotas proporcionado por ROSE.
  72. 72. Servicios de manejo de datos:  M-GET: Servicio de monitorización  M-SET: Servicio de control  M-CANCEL-GET: Servicio de cancelación de monitorizaciónServicios de notificación:  M-EVENT-REPORT: Servicio de notificaciónServicios de Control Directo:  M-ACTION: Servicio de solicitud de acciones por parte del agente  M-CREATE: Servicio de solicitud de creación de “objetos”  M-DELETE: Servicio de solicitud de borrado de “objetos”
  73. 73. Componentes comunes de las primitivas delservicio Invoke Identifier (II) Mode (M) Base Object Class (BC) Base Object Instance (BI) Scope (S) Filter (F) Synchronization (Y) Attribute Identifier List (AI) Access Control (AC)
  74. 74. Ejemplo de utilización del servicio M-GETde Monitorización M-GET request M-GET indication (II,BC,BI,S,F,Y,AI) (II,BC,BI,S,F,Y,AI) M-GET confirm M-GET response (II,MC,MI,AL) (II,MC,MI,AL) II=Invoke Identifier Y =Synchronization BC=Base Object Class AI=Attribute Identifier List BI=Base Object Instance MC=Managed Object Class S=Scope MI=Managed Object Instance F=Filter AL=Attribute List
  75. 75. No todas las funcionalidades tienen queestar soportadas por todos los CMISE  Unidad funcional Kernel (básica, siempre presente)  M-EVENT-REPORT, M-CREATE, M-DELETE  M-GET, M-SET, M-ACTION  Sin peticiones enlazadas, ni scope, filtrado o sincronización  Selección múltiple de objetos (scope y sincronización)  Filtrado  Respuestas múltiples  Cancel-Get
  76. 76. Procedimientos para la transmisión de información de gestión y sintaxis de los servicios de CMISE Definido en Unidades de Datos de Protocolo (PDU) intercambiadas para un servicio  PDU de petición de servicio no confirmado  PDU de petición de servicio confirmado y respuesta de servicio  PDU de respuesta enlazada M-Set M-GetM-SET: M-Set Confirmed M-GET: M-Get M-Set-Confirmed M-Linked-Reply M-Linked-Reply
  77. 77. Objetivo: Modelar los aspectos de gestión de los recursos reales. Definir una estructura para la información de gestión que se transmite entre sistemasComponente principal: Objeto gestionado Abstracción de un recurso que representa sus propiedades para el propósito de su gestión Solo es necesario definir los aspectos del recurso útiles para su gestión No se define la relación entre el recurso y su abstracción como objeto gestionado
  78. 78. El modelo de información hace uso de losprincipios de diseño orientado a objetos Capacidad de estandarizar especificaciones de una manera modular Fácil capacidad de extensión Reutilización de especificaciones anterioresPrincipales consecuencias: Concepto de Objeto: Encapsulamiento  No es visible la operación interna del objeto, solo su interfaz Diferenciación entre aspectos de definición (CLASES) y de implantación (EJEMPLARES o INSTANCIAS)
  79. 79. Se diferencia entre la definición de losobjetos y la implementación de estosobjetosDefinición de objetos: Clases de Objetos Resultado: Texto con definiciones de clasesImplementación de objetos: Ejemplares(o instancias) de las clases Resultado: Ejemplares existentes en un equipo en un momento dado
  80. 80. CLASE 2 AgenteCLASE 1 CLASE 3 Equipo
  81. 81. Posición del objeto en la jerarquía deherenciaAtributos y operaciones permitidas sobreatributosAtributos de grupoComportamientoAcciones que se pueden solicitar sobre elobjetoNotificaciones que puede enviarPaquetes condicionalesClases de objetos alomórficas con su clase
  82. 82. Objetivo: reutilización de definiciones declases de objetos ya existentesEspecialización de clases: definición deuna nueva clase por extensión de otra yaexistente añadiendo nuevas propiedades: Sólo es necesario definir los aspectos nuevos de mi clase Introduce una relación de herencia: la nueva clase hereda las propiedades de su(s) padre(s).
  83. 83. topsystem network equipment Ip network modem router
  84. 84. TOP: superclase superior con laspropiedades comunes o todos los objetosgestionadosSe permite solo la herencia estricta de laspropiedades: Ampliación con nuevos atributos Extensión/Restricción de los rangos de atributos Ampliación con nuevas acciones o notificaciones Ampliación de los argumentos de acciones y notificacionesSe permite herencia múltiple: Mayor reutilización de las definiciones de clases Mejora la capacidad de un sistema gestor para
  85. 85. Sintaxis utilizada: GDMO - Guidelines forthe Definition of Managed ObjectsmiEquipo MANAGED OBJECT CLASS Nombre de la clase DERIVED FROM Equipo Clase de la que hereda
  86. 86. PAQUETE: Conjunto de: Atributos y operaciones Notificaciones y acciones ComportamientosTipo de paquete: Obligatorio: todos los ejemplares poseen las propiedades de este paquete Condicional: algunos ejemplares pueden implementar las propiedades de ese paquete y otros no  Condición de presencia: capacidades del recursoAtributo Packages: paquetes condicionalesque soporta el objeto
  87. 87. miEquipo MANAGED OBJECT CLASS DERIVED FROM Equipo Paquete Obligatorio CHARACTERIZED BY paquete1 PACKAGE CONDITIONAL PACKAGE paquete2 Paquete Condicional
  88. 88. Representan las propiedades de un objetogestionadoTienen un valor asociado que puede ser un conjuntoo secuencia de elementosComponentes de la definición de un atributo: Herencia de otra definición de atributo Sintaxis: todas las permitidas  Simples  Multivaluados Reglas de filtrado que se pueden aplicar sobre el atributoDefinición detallada fuera de la definición de la clase En la clase solo se pone el nombre que se definirá luego.
  89. 89. Especificación de operaciones realizables sobre atributos:  Get: lee el valor de un atributo  Replace: altera el valor de un atributo  Replace with default: reinicializa el valor del atributo a un valor por defecto especificado en la definición de la clase  Add: Añade un componente a un atributo multivaluado  Remove: Elimina un componente de un atributo multivaluadoSe pueden poner constricciones a los atributos:  DEFAULT-VALUE  INITIAL-VALUE  PERMITTED VALUES / REQUIRED VALUES
  90. 90. Un conjunto determinado de atributosPermite realizar una operación sobre todossus componentes como un grupoComponentes de la definición de unatributo de grupo: Elementos del grupo Descripción
  91. 91. Operaciones sobre un objeto que no sonmonitorización o alteración de unatributoÚtiles para modelar la ejecución remotade comandos.Componentes de una acción (opcionales): Parámetros pasados a la acción Parámetros esperados en la confirmación de la acción
  92. 92. Notificaciones que pueden ser emitidas por elobjetoComponentes de una notificación  Información y atributos pasados en la notificación  Parámetros esperados en la confirmación de la notificaciónFuncionamiento:  El objeto siempre emite la notificación cuando se cumple los requisitos  La notificación es comprobada frente a objetos EFD (Event Forwarding Discriminators) registrados por gestores  Si pasa la condición del EFD, se envía el
  93. 93. miEquipo MANAGED OBJECT CLASS DERIVED FROM Equipo Atributos CHARACTERIZED BY paquete1 PACKAGE ATTRIBUTES Operaciones status GET sobre atributos octectsTxGET operationalMode DEFAULT VALUE null GET_REPLACE; ATTRIBUTE-GROUPS Atributo de Grupo Traffic octects Tx,octetsRx; ACTION reset; Acción NOTIFICATION CPUOverload: Notificación CONDITIONAL PACKAGE paquete2
  94. 94. Todas las definiciones de un modelo deinformación pueden tener“Comportamiento”En la práctica, es el campo donde seespecifica un comentario sobre la definiciónPor ejemplo, el comportamiento de unaclase de objetos debería incluir: Semántica de atributos, operaciones y notificaciones Respuesta a operaciones de gestión sobre el objeto Circunstancias bajo las que se emiten las notificaciones
  95. 95. miEquipo MANAGED OBJECT CLASS DERIVED FROM Equipo CHARACTERIZED BY paquete1 PACKAGE BEHAVIOR Comportamiento Definición de la gestión de miEquipo ATTRIBUTES status GET octectsTxGET operationalMode DEFAULT VALUE null GET_REPLACE; ATTRIBUTE-GROUPS Traffic octects Tx,octetsRx; ACTION reset; NOTIFICATION CPUOverload: CONDITIONAL PACKAGE paquete2
  96. 96. Se necesita para posibilitar la migración deversiones de los equipos sin modificar a lavez los gestoresCapacidad de un ejemplar de una subclasede simular el comportamiento de susuperclaseFuncionamiento: La nueva versión del equipo es una especialización (subclase) de la clase de la versión antigua Los ejemplares de la subclase de la nueva versión saben comportarse como si perteneciesen a la clase padre (versión antigua): Comportamiento Alomórfico
  97. 97. Determinación del comportamiento alomórfico:  Como argumento en la petición de la operación  Se proporciona una lista ordenada de clases conocidas por el sistema gestor  La clase que se le aplica es aquella que sea superclase alomórfica permitida y que aparezca primera en la listaGestor Equipo v2 CLASE Equipo v2 Equipo v2 GET CLASE Equipo v3 Equipo v3 (...,ClassAlom=Equipov2...) Alomorfismo!!
  98. 98. miEquipo MANAGED OBJECT CLASS DERIVED FROM Equipo CHARACTERIZED BY paquete1 PACKAGE BEHAVIOR Definición de la gestión de miEquipo ATTRIBUTES status GET octectsTxGET operationalMode DEFAULT VALUE null GET_REPLACE; ATTRIBUTE-GROUPS Traffic octects Tx,octetsRx; ACTION reset; Superclases NOTIFICATION CPUOverload: Alomórficas CONDITIONAL PACKAGE paquete2 ALOMORPHIC SET Equipo
  99. 99. miEquipo MANAGED OBJECT CLASS DERIVED FROM Equipo CHARACTERIZED BY paquete1 PACKAGE BEHAVIOR Definición de la gestión de miEquipo ATTRIBUTES status GET octectsTxGET operationalMode DEFAULT VALUE null GET_REPLACE; ATTRIBUTE-GROUPS Traffic octects Tx,octetsRx; ACTION reset; Registro de NOTIFICATION CPUOverload: la clase en CONDITIONAL PACKAGE paquete2 el arbol de ALOMORPHIC SET Equipo OID
  100. 100. Se requiere una forma de especificarnombres (de objetos) de forma universal ¿Valdría un árbol de clases único y estándar? No, porque no es un árbolISO define un árbol de nombrado deobjetos
  101. 101. Posición en la jerarquía de herenciaPaquetes y paquetes condicionales Atributos Atributos de grupo Comportamiento Acciones NotificacionesClases AlomórficasRegistro en el árbol de OID
  102. 102. Refleja la relación de contención entreinstancias de objetosSe establece una jerarquía de agregaciónUna instancia subordinada está contenidaen una única instancia superiorUso: Estructuración de instancias de objetos en los agentes  Usado por los parámetros de filtrado y ámbito de CMIP  Permite realizar operaciones con una gran potencia Nombrado de los ejemplares desde el gestor
  103. 103. root Sistema Sistema PC Workstation PCUnidad Disco Placa Red Unidad Disco
  104. 104. Cada clase de objetos gestionados debetener al menos un atributo que proporcioneun nombre distintivo a los ejemplares de esaclaseEste atributo es el Relative DistinguishedName (RDN)El nombre de una instancia es laconcatenación de RDN de sus antecesoresen la jerarquía de agregaciónEjemplo de nombre completo de instancia:SistemaId=DEPART3@PCId=PCMarketing@UnidadID=DiscoA
  105. 105. root Sistema Sistema SisID=ST5 SisID=ST8 PC Workstation PC PCId=PC7 WSId=Sun5 PCId=PC2Unidad Disco Placa Red Unidad Disco UnId=B PlacaId=Eth1 UnId=C SistId=ST5@PCId=PC2@UnID=C
  106. 106. Conjunto de definiciones de uno o variosrecursos: Clases de objetos gestionados Acciones, notificaciones, atributos, sintaxis, etc.No tiene que ser autocontenida, permitereferencias a otras MIBsSintaxis de MIB: GDMOGran variedad de MIBs definidas ynormalizadas actualmente
  107. 107. Hemos visto que en gestión OSI seutilizan tres árboles: resuelvenproblemas distintosÁrbol de registro ISO Nombrar objetos de forma únicaÁrbol de herencia Definir y derivar clases de forma conveniente No es estrictamente un árbol (herencia múltiple)Árbol de agregación Organizar instancias en una MIB concreta
  108. 108. Guidelines for the Definition of ManagedObjectsProporciona las pautas para la definiciónde MIBs.Se definen mediante macros ASN.1La norma proporciona además normasútiles para diseñar MIBS: Agrupamientos de datos Uso de herencia Definición de relaciones .....
  109. 109. Macros para la definición de: MANAGED OBJECT PACKAGES PARAMETER ATTRIBUTE ATTRIBUTE GROUP BEHAVIOR ACTION NOTIFICATION
  110. 110.  Introducción Planificación de la Gestión de Red Funcionalidad de la Gestión de Red Arquitectura TMN Modelo de Gestión de Red OSI Modelo de Gestión de Red de Internet Sistemas de Gestión Integrada Plataformas de Gestión
  111. 111. Axioma fundamentalSi la gestión de red es esencial, entonces debe serimplantada en todos los recursos de una red Consecuencias:  El impacto de añadir gestión de red en los nodos debe ser el mínimo posible  La complejidad algorítmica y de comunicaciones debe recaer en los procesos gestores
  112. 112. Primera aproximación (Marzo 1987):  SGMP: Simple Gateway Monitoring Protocol  HEMS: High-level Entity Management System  CMOT: CMIP over TCPRevisión (Febrero 1988)  Corto plazo: SGMP actualizado (SNMP)  Largo Plazo: CMOTPrimeras recomendaciones: SNMP, SMI, MIB(Agosto 1988)Nuevas revisiones: SNMP, MIB-II (Marzo 1991)Desarrollo de MIBs particulares (1991-....)SNMPv2 (Mayo 1993): rechazo sin consensoposterior
  113. 113. El marco de trabajo está basado en tresdocumentos: Structure of Management Information (SMI) rfc 1155 Management Information Base (MIB) rfc 1156, rfc 1213 Simple Network Management Protocol (SNMP) rfc 1157Documentos adicionales: Concise MIB definitions rfc 1212
  114. 114. Objetivo: referenciar un recurso en un sistema remoto Protocolo IP: permite llegar al sistema remoto Protocolo SNMP: permite llegar al proceso de gestión de red del sistema remoto.¿Cómo llegar a los recursos del sistema remoto? Método común para nombrar a los objetos. Se usan los Object Identifiers (OID)
  115. 115. OIDs: Nos permiten alcanzar (nombrar)objetos mediante SNMP¿Cómo devolvemos los valores de losobjetos (respuesta a un get)?Es necesario: Conocer la estructura de los valores que nos pueden llegar desde los objetos (Macro OBJECT-TYPE) Usar una codificación por línea conocida de estos valores (Sintaxis de transferencia)
  116. 116. EjemploOBJECT-TYPE MACRO::=BEGIN sysDescr OBJECT-TYPETYPE NOTATION::= ‘SYNTAX’ type SYNTAX OCTET- STRING ‘ACCESS’ Access ACCESS read-only ‘STATUS’ Status STATUS mandatoryVALUE NOTATION::= value ::= {system 1}Access::= ‘read only’ | ‘read write’ | ‘write only’ | ‘not- accessible’Status::= mandatory’|’optional’|’obsolete’END
  117. 117. Access: Define el nivel de acceso alobjeto Read-only Read-write Write-only Not-accessibleStatus: Define los requisitos deimplementación del objeto: Mandatory Optional Obsolete
  118. 118. Está definido como un OBJECT IDENTIFIEREs usado para nombrar a los objetosgestionadosPueden estar 3 tipos de MIBs: MIB Standard de Internet Mib OBJECT IDENTIFIER ::={internet mgmt(2) 1} MIBs experimentales Experimental OBJECT IDENTIFIER ::={internet 3} MIBs privadas Enterprises OBJECT IDENTIFIER ::={internet private (4) 1}
  119. 119. Syntax: define el tipo de datos quemodela el objetoTipos permitidos para los objetos: Tipos simples (Integer, Octet String, Object Identifier) Tipos etiquetados Tipos estructurados (Sequence, Sequence of) Subtipos (IP Address, counter, gauge,...)
  120. 120. INTEGER: números cardinales.Status::= INTEGER {up(1), down(2),testing(3)}OCTET STRING: 0 o más octetos. Cadabyte puede tomar valores entre 0 y 255.OCTET IDENTIFIER: Identificación deobjetos.NULL: Tipo nulo. No se usa en el marcode gestión
  121. 121. MIB: Conjunto de objetos gestionados deun recurso que se publican para ofrecerinteroperabilidad de gestión.Los objetos se organizan en gruposLos nodos deben soportar gruposenterosTipos de MIBs: Estándares: MIB-I y MIB-II Experimentales Privadas
  122. 122. Primera MIB normalizada: Objetos de losprotocolos de TCP/IP: Grupo No. Propósito System 3 El propio sistema Interfaces 22 Interfaces de red At 3 Correspondencia de direcciones IP Ip 33 Internet Protocol Icmp 26 Internet Control Message Protocol Tcp 17 Transmission Control Protocol Udp 4 User Datagram Protocol Egp 6 Exterior Gateway Protocol 114
  123. 123. Grupo No. ComentariosSystem 7 Nuevos parámetrosInterfaces 23 1 objeto nuevoAt 3 Se desestima su usoIp 38 5 objetos nuevosIcmp 26 Sin cambioTcp 19 2 objetos nuevosUdp 7 Nueva tablaEgp 18 Expansión de tablaTransmissi 10 Nuevo: contenedor de MIBs de protocolosonSnmp 30 Nuevo: gestión del protocolo SNMP 171
  124. 124. Ejemplo: MIB-2 . ipConfiguración de los parámetros de IP ipForwarding ipDefault TTl: DESCRIPTION “The default value inserted into the Time-To_Live field of the IP header of datagrams originated at this entity, whenever a TTL value is not supplied by the transport layer protocol”. ....Estadísticas sobre paquetess: ipInReceivesErrores: ipInAddrErrors,........Tablas De direcciones (interfaces) De enrutamiento .......
  125. 125. MIBs en desarrollo por los grupos detrabajo de Internet.Se estandarizarán complementando a laMIB-IIEjemplo de MIBs ya estándares: IEEE 802.4 Token Bus (rfc 1230) IEEE 802.5 Token Ring (rfc 1231) IEEE 802.3 Repeater Devices (rfc 1368) Ethernet (rfc 1398) FDDI (rfc 1285) RMON (rfc 1271) Bridges (rfc 1286) ........
  126. 126. MIBs de productos específicos, queañaden funcionalidad a las MIB estándar.Los fabricantes las hacen públicas: Antiguamente: depósito común en ftp://venera.isi.edu Actualmente: servidores WWW del fabricante, diskette proporcionado con el producto, etc.Necesarias para integrarlas en unaplataforma de gestión de red general.
  127. 127. RFC 1157: surge a partir del protocolo SGMPpara gestión de routers IP.Arquitectura de un sistema de gestiónSNMP: Estación de gestión de red SNMP SNMP SNMPConjunto de Conjunto de Conjunto de MIBs MIBs MIBsOrdenador Router Servidor de terminales
  128. 128. SNMP – RFC 1157 Nivel 7UDP – RFC 768 Nivel 4 IP – RFC 1157 Nivel 3ICMP – RFC 782Ethernet Token FDDI Niveles 1 y 2 Ring
  129. 129. Proceso Gestor Proceso Agente GetNextRequest GetNextRequest Get Response Get Response Get Request Get Request MIB del Set Request Set RequestMIB Central Agente Trap Trap SNMP RED SNMP UDP UDP IP IP Protocolos Protocolos dependientes de dependientes de la red la red
  130. 130. Marco administrativo: determina políticasde autenticación y autorización Comunidad: relación entre un agente, una vista de sus MIB y un conjunto de gestores Nombre de comunidad: cadena de octetos transmitida en los mensajes SNMP. Autenticación:  Trivial: el nombre de comunidad se transmite en claro !! (Y además se transmite en todas las operaciones, ya que no hay sesiones) Autorización:  La comunidad tiene asociado una vista (conjunto de objetos)  Para cada objeto se define un modo de acceso: read- only, read-write
  131. 131. En la práctica Comunidad pública  Agente con todos sus MIB con acceso read / only  Todos los gestores  Nombre de comunidad: “public” Comunidad privada:  Agente con todas sus MIB con acceso read / write  Todos los gestores  Nombre de la comunidad preacordado y confidencial
  132. 132. Mensaje SNMP datagrama UDP Disminuye procesado de mensajes y complejidad del agenteVersión comunidad datosRequest Error Error Name Value Name Value ........ id status index Los mensajes SNMP son recibidos en el puerto UDP 161
  133. 133. Id.Petición: Permite eliminar duplicados.ErrorStatus: Indica error al procesar unapetición (noError(0), tooBig(1), nosuchName(2), badValue(3), readOnly(4), genErr(5))ErrorIndex: Variable que causó el errorVariable Bindings: Lista de instancias consus valores Los valores van vacíos en los getsEnterprise: tipo de objeto generador delevento/trap (sysObjectId)
  134. 134. Dir.Agente: Dirección del agente quegenera el trapTrap genérico: coldStart(0), warmStart(1), linkDown(2), linkUp(3), authenticationFailure(4), egpNeighborLoss(5), enterpriseSpecific(6)Trap específico: código específico deltrapTimeStamp: tiempo desde la últimareinicialización del agente (sysUpTime)
  135. 135. GetRequest: Petición de valoresespecíficos de la MIBGetNextRequest: Proporciona un mediopara moverse por la MIB. Petición delobjeto siguiente a uno dado de la MIB.GetResponse: Devuelve los valoressolicitados por las operacionesanteriores.SetRequest: Permite asignar un valor auna variableTraps: Permite a los agentes informar desucesos inusuales.
  136. 136. El gestor puede enviar múltiples peticiones sinrecibir respuestaProceso de envío de un mensaje SNMP:Transmisión Se construye PDU Se invoca al servicio de autenticación, con la dirección de transporte y el community Se construye el mensaje SNMP Se codificaRecepción Comprobación sintáctica (eventual descarte) Verificación de la versión utilizada Autenticación: Si falla, trap de autenticación Procesado de la petición
  137. 137. Get-Request: Permite pedir el valor de unobjeto específico en un recurso. El objetodebe existir.EJEMPLOSnmp/>snmpget-h cisco-dit sysDescr.0Value:”GS Software (GS2-BRX), versión 8.2 (3)Copyright© 1986-1991 by Cisco Systems.Inc.Compiled Tue 12-Feb-91 12:02 by Peter Johnson”Respuesta con Get-ResponseAtómica (SNMPv1): o se obtienen todas o no
  138. 138. Get-Next-Request: Proporciona el objetosucesor lexicográficamente siguiente delque se proporciona. Sirve para recorrertablas de routeo
  139. 139. Set Request: Permite alterar el valor de unobjeto que se soliciteHay que identificar específicamente elejemplar que se quiere cambiar: Set (OID.ejemplar,nuevo-valor)Problema: Falta de seguridadEsta operación está deshabilitada enmuchos agentes
  140. 140. Traps: Sirven para informar de sucesosextraordinarios.Son invocadas espontáneamente por el agente.  En algunos casos, se pueden programar escribiendo en variables (ej: snmp, snmpEnableAuthenTraps)No confirmados  Las aplicaciones suelen basarse polling en vez de eventos  ¿Sería apropiado un mecanismo no-confirmado de traps si el servicio de transmisión fuese fiable?Traps definidas:  ColdStart, WarmStart, LinkDown, LinkUp,
  141. 141. Ventajas del SNMP: Simplicidad Requiere menor procesamiento que el CMIP Ampliamente usado y probado Está integrado en muchos productos actualesDesventajas: Aspectos de seguridad Funcionalidad reducida  No facilita la invocación de operaciones, creación de objetos,.... Falta de visión global Poco eficiente  Genera mucho tráfico por la red No facilita el diseño de las MIBs Es poco adaptable para gestión jerárquica.
  142. 142.  Introducción Planificación de la Gestión de Red Funcionalidad de la Gestión de Red Arquitectura TMN Modelo de Gestión de Red OSI Modelo de Gestión de Red de Internet Sistemas de Gestión Integrada Plataformas de Gestión
  143. 143. Interconexión entre equipos: resuelto porarquitecturas de comunicacionesestándares (TCP/IP, X.25, etc.)Interconexión Gestor-Equipo: Fabricantes: Intento de establecer carácter propietario (se aseguran la venta del equipo y de su gestor) Usuarios: entornos heterogéneos, de múltiples fabricantes ¿Aumento imparable del número de gestores?
  144. 144. Un primer paso: Gestión Autónoma. Redes con gestión local en cada nodo Sistema de gestión localSistema degestión local Sistema de Sistema de gestión local gestión local
  145. 145. Siguiente paso: Gestión homogénea. Redeshomogéneas con un único nodo de gestióncentralizado Sistema de gestión centralizado
  146. 146. Situación actual: Gestión heterogénea.Ampliación de las redes con lainterconexión de productosheterogéneos.Ejemplo: Organización que satisface los requisitos de comunicaciones de sus sistemas de información mediante:  Red de datos  Red de telefonía  Transmisión (multiplexores, módem, etc..)
  147. 147. Supuesto que los elementos de cada unade las redes son del mismo fabricante,existirían tres centros de gestión de red. Interfaz de Interfaz de Interfaz de usuario usuario usuario Sistema de gestión Sistema de gestión Sistema de gestión de red propietario de red propietario de red propietario PBX HOST MUX MUX PBX PBX MUX Red 1 Red 2 Red 3
  148. 148. Plano de usuario (operador de red):Multiplicidad de interfaces de usuario.Plano de aplicación (de gestión): distintosprogramas de aplicación con funcionalidadsimilarPlano de información (de gestión):duplicidad y posible inconsistencia de lainformación almacenada en las bases dedatos.Dificulta el cumplimiento de que la gestión de red sea efectiva en coste
  149. 149. Interfaz de Usuario Integrado Sistema de gestión de red integrado PBXHOST MUX MUX PBX PBX MUX Red 1 Red 2 Red 3
  150. 150. Interfaz de Usuario UnificadoServicios de PresentaciónAplicaciones de gestiónBase de DatosServicios de comunicaciones compartidosCapacidad de distribución del sistema
  151. 151. Normalización de las comunicaciones Es necesario especificar un protocolo entre elemento de red y centro de gestiónNormalización de la información. El centro de gestión debe conocer las propiedades de gestión de los elementos de red:  Su nombre  Formato de las respuestas Definición sintácticamente uniforme de los elementos de red
  152. 152.  Introducción Planificación de la Gestión de Red Funcionalidad de la Gestión de Red Arquitectura TMN Modelo de Gestión de Red OSI Modelo de Gestión de Red de Internet Sistemas de Gestión Integrada Plataformas de Gestión
  153. 153. Integración de aplicaciones: si los recursosse gestionan según modelos normalizados: Aplicaciones de gestión genéricas, basadas en el protocolo de gestión directamente. Aplicaciones con el mismo método de acceso: reutilización del software de protocolos de gestión. Plataformas de gestión  Infraestructura de gestión común para las aplicaciones  Funcionalidad básica de gestión de red  Permite integración de aplicaciones a nivel de interfaz de usuario.
  154. 154. Las plataformas más conocidas son:Hewlett-Packard: OpenViewIBM: NetView / 6000 (Tívoli TME)Sun: SunNet ManagerDEC: PolyCenterCabletron: SpectrumBull: ISMNetLabs: OverLordMicromuse: Netcool
  155. 155. La funcionalidad que proporcionan es muybásica, y orientada al protocolo. Noproporcionan transparencia.Aplicaciones más usuales: MIB Browser: interfaz de usuario del protocolo SNMP. Discover: permite “auto-descubrir” equipos y topologías de la red Programación de sondeos de variables de la MIB Programación de acciones ante alarmas Visualizador gráfico de valores de variables de MIB.
  156. 156. Entorno: HP, Sun, MOTIFMúltiples aplicaciones de otros vendedoresintegrablesSoporta comunicaciones por SNMP y CMIPIncorpora la aplicación Network NodeManager para redes TCP / IPUsa la base de datos INGRESS
  157. 157. Network Node Manager SNMP MIB IP Discovery Data Browser and Layout Presentation Tools CONSOLEINGRESS (OSF Motif)Database XMP API SNMP CMIP
  158. 158. Incluye herramientas para desarrollo deaplicaciones de gestión OSI.OPI: Open Protocol Interface. Permite eldesarrollo de dispositivos de mediaciónTMN.Seleccionado por los principalesfabricantes de equipos detelecomunicación para el desarrollo desus aplicaciones de gestión: Nortel Alcatel Ericsson Nokia
  159. 159. 3 tipos de integración entre aplicacionesde gestión: Integración de comunicaciones Integración de interfaces de usuario Integración de informaciónLas dos primeras están solucionadas conel uso de una plataforma de gestión: Comunicaciones : todas las aplicaciones usan los servicios de comunicaciones de la plataforma Interfaz de usuario: las aplicaciones comparten el interfaz de usuario de la plataforma.
  160. 160. Base de datos local de gestión: Lasaplicaciones de gestión necesitanalmacenar datos localmente: datos detopología, datos administrativos.Estos datos pueden formar parte de lasMIBs, pero no es frecuente.Las plataformas y algunas aplicacionesincorporan el uso de bases de datosrelacionales para el almacenamientolocal.Cada aplicación tiene necesidades dealmacenamiento diferentes, pero confrecuencia existen datos comunes entre
  161. 161. Cada aplicación tiene su propia base dedatos.BD BD BD Aplicación Aplicación Aplicación de gestión de gestión de gestión PLATAFORMA DE GESTIÓNBD Protocolos de gestión de red
  162. 162. Las plataformas actuales no permiten unaintegración de la información entre lasaplicacionesDos enfoques diferentes para su solución: Esquema universal de almacenamiento de datos: consorcio MIC fallido Configuración “ad-hoc” por los gestores de red
  163. 163. Gestión integrada: permite acceder ainformación de gestión de los recursos dela misma manera.Plataformas de gestión: ofrecen a otrasaplicaciones infraestructura de acceso arecursos. ¿Qué plataforma elijo para desarrollar mi aplicación? ¿Me tengo que ligar a la plataforma de un fabricante para realizar mi aplicación de gestión?Problema: Heterogeneidad de plataformasUna solución: desarrollo de aplicación para
  164. 164. Convergencia de plataformas NMF (OMNIPoint) OSF(DME) X/Open (XMP)Gestión de ordenadores personales DMTF Gestión basada en Web WBEM JMAPIGestión en Entornos de ProcesamientoDistribuido
  165. 165. DEMO
  166. 166. Preguntas? FIN

×