Modelo de Comunicaciones SNMP Arquitectura UDP: servicio no fiable. Se sigue el modelo de comunicación de sondeo (salvo para la operación Trap ) Aunque nos centraremos en redes IP, se puede implantar SNMP sobre otras torres de protocolos (IPX, OSI, CLNS, )
Operaciones GetRequest: el gestor realiza una petición de valores específicos de la MIB del agente. GetNextRequest: el gestor realiza una petición del objeto siguiente a uno dado en la MIB del agente, siguiendo un orden lexicográfico. GetResponse: el agente devuelve los valores solicitados por las operaciones anteriores al gestor. Es la respuesta a un GetRequest, GetNextRequest o SetRequest. SetRequest: el gestor permite asignar un valor a una variable en el sistema del agente. Traps: el agente informa de un suceso inusual predefinido mediante informe de eventos. Formato del mensaje SNMP
Significado de los campos del mensaje Version: Versión del protocolo SNMP. Comunity: comunidad que permite la autenticación del gestor ante el agente y el control de acceso (autorización) Request-id: Identificador único para cada petición. Es el mismo en la respuesta correspondiente. Error-status: indica si ha ocurrido un error cuando procesa una petición. Los código son: noerror (0), toobig (1), nosuchname (2), badvalue (3), readonly (4), generr (5). Vale 0 en caso de getrequest, getnextrequest y setrequest. Error-index: cuando se ha producido un error, puede aportar información, indicando que instancia de la lista de variablebindings ha producido el error. Vale 0 en caso de getrequest, getnextrequest y setrequest. Variablebindings: lista de nombres de variables (OIDs) y sus correspondientes valores. Los valores son nulos (NULL) en casos como GetRequest, GetNextRequest o GetResponse con error. Permite múltiples operaciones en el mismo mensaje. Significado de los campos del mensaje (cont) Enterprise: tipo de sistema que genera el trap, basado en sysobjectid. Agent-addr: dirección IP del agente que genera el trap. Generic-trap: código de trap genérico. Specific-trap: código de trap específico. Time-stamp: tiempo desde la última (re)inicialización del agente y la generación del trap (valor de sysuptime).
Operación de petición de información GetRequest (gestor-agente) - GetResponse (agente-gestor). Request-id permite correlar petición con respuesta y detectar duplicados (udp no fiable). Variablebindings permite multiplexar varias peticiones en un mismo mensaje. La respuesta debe ser atómica, es decir, si una petición falla: No se devuelve el resultado de ninguna. Error-index apunta al name (varible-bindings) que ha producido el fallo. Ej.: si falla el segundo name, erro-index = 2. Errores en la respuesta (error-status): nosuchname: OID no referencia a una instancia o no se encuentra en la vista. toobig: el tamaño del mensaje de respuesta no cabe en el tamaño máximo de datos UDP impuesto por el sistema. generr: cualquier otro motivo. Operación de navegación por la MIB GetNextRequest (gestor-agente) - GetResponse (agente-gestor) Se procesa igual que GetRequest. Operación atómica. Devuelve el valor de la siguiente instancia en orden lexicográfico: OID, no instancia: ejemplo (1.3.6.1.2.1.4.3) Si existe en la vista devuelve la instancia OID.0 Si no existe, valor de la siguiente instancia NextOID.0 Instancia OID: ejemplo (1.3.6.1.2.1.4.3.0) Valor de la siguiente instancia: NextOID.0 OID de tabla o Entry de tabla: ejemplo (iftable o iftable.1) Valor de la primera instancia de la tabla. OID columnar: ejemplo (iftable.1.1) Valor de la primera instancia de la columna de la tabla. Instancia OID columnar: ejemplo (iftable.1.1.1) Valor de la siguiente instancia en la vista (puede ser de la misma columna, otra columna o fuera de la tabla). Si no existe la siguiente instancia devuelve NoSuchName.
Operación de modificación de información SetRequest (gestor-agente) - getresponse (agente-gestor) VariableBindings: En Set contiene name y value de todas las instancias cuyo valor se quiere modificar. En response: Contiene name y value tras la modificación. Si se produce error en alguna de las peticiones del mensaje, no se modifica ninguna y no se devuelve ningún valor. Códigos de error: nosuchname, TooBig, generr: mismos casos que GetRequest. badvalue: si tiene algún (name,value) inconsistente (tipo o longitud del valor no válidos, fuera de rango...). En el caso de nosuchname el error puede indicar que el objeto no puede (control de acceso) ser modificado (aunque exista). Si el objeto es de sólo lectura devuelve nosuchname. No se utiliza readonly. En SNMPv2 se utiliza un nuevo código denominado notwritable. Operación de notificación de eventos Trap (agente-gestor). No requiere confirmación: problema si se pierde el mensaje. Motivos de trap: coldstart (0): reinicio inesperado debido a algún tipo de fallo. warmstart (1): reinicio en caliente, normalmente programado. linkdown (2): fallo en uno de los enlaces del sistema. El primer elemento en variablebindings, contiene el valor ifindex del interface. linkup (3): uno de los enlaces se ha iniciado. El primer elemento en variablebindings, contiene el valor ifindex del interface. authenticationfailure (4): se ha recibido un mensaje SNMP con error de autenticación. egpneighborloss (5): se ha perdido la relación con un vecino EGP. enterprisespecific (6): se ha producido algún evento específico de empresa especificado en specific-trap.
SNMPv2 Bibliografía (RFCs) 1901 - Introducción 1902 - SMI 1903 Nomenclatura 1905 - Protocolo 1907 - MIB 1908 - Coexistencia v1/v2
Principales novedades Soporte de comunicación gestor-gestor (PDU informrequest) Lectura de tablas completas en una sola operación (PDU getbulkrequest) Seguridad: fracaso total, sigue basada en comunidades hasta la v3 Simple? SMI Basicamente una ampliación de la versión v1 Amplía el árbol de OIDs: directory (1) mgmt(2) expmt (3) private (4) security (5) snmpv2 (6)
SMI (cont) Se definen nuevos tipos de datos: enumerados Counter32 Counter64 Gauge32 BITS Se redefinen los tipos de acceso que se asocian a los atributos: Desaparece write-only Aparecen: accessble-for-notify read-create read-write-create SMI (cont) En cuanto a las tablas se dividen en dos categorías: Controladas por el agente: el gestor no puede crear/eliminar filas Controladas por el gestor: el gestor puede crear/eliminar filas, y se soporta la modificación de la estructura de la tabla desde el gestor.
Protocolo Básicamente dos cambios respecto a la versión v1: Se añaden nuevas primitivas Se unifica el formato de las PDUs (en la versión v1 el de trap era diferente al resto Protocolo - PDUs get-request get-next-request get-bulk-request response set-request inform-request snmpv2-trap report (apareciá en los documentos de seguridad y después se eliminó junto con ellos)
Protocolo Formato de PDUs data1 data2 Protocolo Formato de PDUs El significado de data1 y data2 y variablebindings depende del tipo de PDU, por ejemplo: response devuelve error-status y error-index en data1/data2 getbulkrequest devuelve non-repeaters y maxrepetitions en data1/data2 variablebindings puede incluir: OIDs y NULL en peticiones de información nosuchobject, nosuchinstance, endofmibview,
Protocolo get-request y get-next-request Similar a v1, pero en v1 las peticiones múltiples son atómicas (se reciben todas o ninguna) en v2 pueden ser incompletas Es posible devolver nosuchobject, nosuchinstance, endofmibview para elementos individuales Protocolo set-request La única diferencia con v1 está en las respuestas Sigue siendo átómica (se modifican todas las variables o ninguna) Básicamente existen más códigos de error posibles Protocolo get-bulk-request Permite leer tablas accediendo fila a fila y optimizando la transacción global (de una tabla completa) Es similar a get-next-request en el sentido de que utiliza un orden lexicográfico Devuelve una lista de variables con contenidos de la tabla en variablebindings y dos contadores en data1/data2 (non-repeaters y max-repetitions) que controlan el acceso a esas variables
Protocolo snmpv2-trap Utiliza un formato diferente de v1, pero Se unifica en cuanto a formato con las demás primitivas de la v2. variablebindings incluye: sysuptime.0 snmptrapoid.0 (qué trap) Información de interés sobre la trap concreta (varía de trap a trap) Protocolo inform-request Permite la comunicación de datos entre un gestor y otro. Funcionalidad básica: X le puede decir algo sobre Y a Z (X y Z son gestores) No muy utilizado
Interoperabilidad con v1 Los agentes pueden hablar v1 y/o v2. Los gestores deben hablar v2 Y también v1 para hablar con agentes v1 El gestor intentará primero hablar v2 con un agente Si el agente habla v2 le contestará Si el agente habla v1 responderá con un mensaje de error y el gestor lo intentará con v1 Para ello puede tener que hacer conversiones (por ejemplo, convertir getbulk en getnext SNMPv3
Bibliografía (RFCs) 2271 Arquitectura 2272 Procesado de mensajes 2273 Aplicaciones v3 (partes funcionales) 2274 Modelo de seguridad basado en usuario 2275 Modelo de control de acceso basado en vistas SNMPv2+ SNMP v3 Seguridad a nivel de protocolo: Autentificación, confidencialidad y gestión de claves Es decir, el Modelo de seguridad basado en usuario. (La confidencialidad se denomina privacidad) Un modelo de control de acceso mejorado Basado en vistas de la MIB Basado en grupos Es decir, el Modelo de control de acceso basado en vistas.
Formato básico Encapsulado de las PDUs v1/v2. Parte SNMPv3 Cabecera global Cabecera del modelo de seguridad Cabecera de PDU PDU SNMP v1/v2 Parte cifrada La parte de PDU se puede autentificar o autentificar/cifrar. RMON
Introducción RMON: ampliación de SNMP, SMI, MIB para monitorización remota. Documentos: RFC2819: RMON-1 de monitorización remota. RFC2021: RMON-2 de monitorización remota. Otros: SMON, TPM, APM, RAQMON, DSMON MIB que define funciones de monitorización e interfaz. Utiliza el protocolo SNMP. Permite definir monitorizaciones desde una gestor e implementarlas en una sonda RMON. Control de monitorización remota Monitor remoto puede ser: Un dispositivo dedicado. Una función disponible en un sistema con recursos (memoria y procesador) dedicados. Puede realizar tareas más complejas que un agente. Control del gestor sobre el monitor remoto. Dos categorías: Configuración: Especifica el tipo de información monitorizada y la forma de hacerlo. MIB se organiza en grupos. Cada grupo tiene tablas de control (RW) y tablas de datos (RO) asociadas. Los parámetros de cada monitorización se especifican en una fila de la tabla de control. Los datos recopilados se guardan en filas de la tablas de datos. Modificar parámetro en tabla de control: borrar y crear uno nuevo. En casos sencillos datos y control pueden estar en la misma tabla. Invocación de acción: hay objetos de RMON que representan estados y se invoca un determinado proceso cuando se cambia de estado (setrequest())
MIB RMON statistics: contadores de paquetes con algún tipo de error, octetos y paquetes de distintos tipos. history: toma muestras para ver la evolución de contadores de statictics con el tiempo. alarm: monitorización y definición de umbral de alarma de algún OID de las MIBs RMON (requiere event). host: contadores de tipos de tráfico por cada host de la subred. hosttopn: los N hosts que tienen un contador con mayor valor (requiere host). matrix: información de tráfico entre parejas de hosts. filter: define filtros para capturar o hacer estadísticas de paquetes. capture: captura paquetes definidos por un filtro (requiere filter). event: tabla de eventos generados ante condiciones de alarma o contador de filtros que supera un umbral. tokenring: estadísticas y configuración de subred TokenRing. Grupo Statistics Estadísticas sobre una subred Ethernet en forma de contadores de eventos. Tabla etherstatstable con una fila por cada interfaz. Algunos eventos de la tabla: Bytes recibidos y paquetes recibidos. Paquetes recibidos dentro de cada uno de los siguientes grupos de tamaño: 64, 65..127, 128..255, 256..511, 512..1023, 1024..1518. Paquetes broadcast y multicast recibidos. Distintos tipos de errores: Pérdidas de paquetes por falta de recursos en la sonda. Error CRC o de alineamiento (nº incorrecto de bytes). Tamaño correcto. Tamaño menor de 64 bytes. Tamaño mayor de 1518 bytes. Tamaño menor de 64 bytes y error de CRC o alineamiento. Tamaño mayor de 1518 y error de CRC o alineamiento. Estimación del nº total de colisiones. Objetos no contadores: Índice de la tabla, identificador del interfaz (OID del interfaz en interfaces.ifindex.valor), propietario y estado de la fila.
Grupo History Define funciones de muestreo de estadísticas sobre los interfaces. Dos tablas. Control y datos: historycontroltable: especifica el interfaz y detalles de la función de muestreo: historycontrolindex: índice de la fila. historycontrolsourcedata: identificador de la fuente de datos (interfaz). historycontrolbucketrequested: número de muestras que se solicita tener guardadas. historycontrolbucketgranted: número de muestras guardadas (buffer circular). El monitor intenta que se acerque a BucketRequested lo máximo posible. historycontrolinterval: intervalo de muestreo (1..3600) segundos. Por defecto una muestra cada 1800 seg. historycontrolowner y historycontrolstatus. etherhistorytable: guarda los datos de las muestras (en cada fila una muestra): etherhistoryindex: índice correspondiente en la tabla de control. etherhistorysampleindex: identifica cada muestra de forma única. etherhistoryintervalstart: (sysuptime) comienzo del intervalo de muestreo. Contadores con la muestra pertenecientes a eventos de etherstatstable: dropevents, octets, pkts, broadcastpkts, multicastpkts... Diferencia del valor correspondiente entre el principio y el final del intervalo. Entero que indica la utilización calculada a partir de etherstatsoctets y etherstatspkts medidos en un intervalo de tiempo. Grupo Host Descubre los hosts en la LAN por direcciones MAC de origen y destino que ve en las tramas (sin error). Tres tablas: control (hostscontroltable) y datos (hosttable y hosttimetable). Estructura de hostscontroltable: hostscontrolindex: índice de la tabla. Cada fila identifica un interfaz del monitor. El valor se usa en las otras tablas. hostscontroldatasource: identifica el interfaz por el que se reciben datos de la LAN. hostscontroltablesize: nº de filas en hosttable que referencian esta fila. hostscontrollastdeletetime: valor de sysuptime correspondiente a la última vez que una fila de hosttable que referencia a esta fila fue borrada. (0 si no fue borrada ninguna fila). hostscontrolowner y hostscontrolstatus.
Grupo Host Por cada entrada (fila) en la tabla de control hay entradas en la tabla de datos hosttable, una por cada MAC encontrada en el interfaz (LAN). Estructura de hosttable: indexada por hostindex y hostaddress hostaddress: dirección MAC del host hostcreationorder: orden (temporal) de creación del host capturado hostindex: valor de hostcontrolindex Contadores: hostin(out)pkts: paquetes transmitidos a/desde el host hostin(out)octets: octetos transmitidos a/desde el host hostouterrors: paquetes no válidos transmitidos por el host hostoutbroadcastpkts: paquetes difusión transmitidos por el host. hostoutmulticastpkts: paquetes multicast transmitidos por el host. Estructura de hosttimetable: misma información que la anterior pero indexada por hostindex y hostcreationorder. Grupo hosttopn Mantiene una lista (informe) de los N hosts de una LAN que alcanzan mayor incremento de una variable determinada durante un tiempo de observación. Dos tablas: control (hosttopncontroltable) y datos (hosttopntable). Estructura de la tabla de control hosttopncontroltable: hosttopncontrolindex: identifica un informe sobre un interfaz. Se define en una fila de la tabla. hosttopnhostindex: valor de hostindex en la tabla de datos del grupo host. Identifica por lo tanto una LAN. hosttopnratebase: especifica uno de los siete contadores en la tabla de datos del grupo host. hosttopntimeremaining: tiempo que queda para finalizar el informe (seg). hosttopnduration: duración del intervalo de muestreo del informe (seg). hosttopnrequestedsize: máximo número de hosts solicitado en el informe. hosttopngrantedsize: máximo número de hosts en el informe. hosttopnstarttime: hora (sysuptime) en que se inicializó el informe la última vez. hosttopncontrolowner y hosttopncontrolstatus.
Grupo hosttopn Estructura de la tabla de datos hosttopntable: HostTopNReport: identificador del informe. Mismo valor que HostTopNControlIndex. HostTopNIndex: índice que identifica una fila de un informe. HostTopNAddress: Dirección MAC del host. HostTopNRate: diferencia del valor seleccionado en HostTopNRateBase desde que se inició el informe. Proceso de inicio de un informe: Crear una fila en la tabla de control en la que selecciona un contador. hosttopntimeremaining inicia cuenta descendente hasta que alcanza el valor 0 (fin de intervalo). Mide la diferencia entre el valor del contador al principio y final del intervalo. Para cada host de la LAN seleccionada. Lista los hosttopngrantedsize hosts que tienen mayor el valor medido en orden decreciente. Para reiniciar el proceso, el gestor debe actualizar hosttopntimeremaining con el valor de hosttopnduration. Grupo Matrix Almacena información sobre tráfico entre cada par de hosts en una LAN. Tres tablas: control (matrixcontroltable) y datos(matrixsdtable y matrixdstable). Estructura de la tabla de control matrixcontroltable: matrixcontrolindex: identifica una fila de la tabla que define la comunicación observada en un interfaz. matrixcontroldatasource: interfaz o LAN que observa el monitor. matrixcontroltablesize: número de entradas en las tablas de datos que se refieren a esta entrada en la tabla de control. matrixcontrollastdeletetime: valor de sysuptime de la última vez que se borro una entrada en las tablas de datos (0 si no se ha borrado). matrixcontrolowner y matrixcontrolstatus.
Grupo Matrix Estructura de la tablas de datos matrixsdtable: matrixsdsourceaddress: dirección MAC fuente. matrixsddestaddress: dirección MAC destino. matrixsdindex: identificador. Mismo valor que matrixcontrolindex. matrixsdpkts: paquetes transmitidos de fuente a destino. matrixsdoctets: octetos transmitidos de fuente a destino. matrixsderrors: paquetes transmitidos de fuente a destino, con error. Indexada con matrixsdindex, matrixsdsourceaddress y matrixsddestaddress. Se ve ordenada la información que va desde una fuentes a varios destinos. Estructura de la tabla matrixdstable: Tiene la misma información. Indexada con matrixdsindex, matrixdsdestaddress y matrixdssourceaddress. Se ve ordenada la información que va desde varias fuentes a un mismo destino. Grupo Alarms Permite definir umbrales que disparan una alarma si se rebasan. Una tabla única (alarmtable). Cada entrada programa una alarma con los siguientes parámetros: alarmindex: índice de la tabla. alarminterval: intervalo de muestreo en segundos (toma muestra y compara). alarmvariable: OID de la variable de la MIB RMON que se monitoriza, puede ser (INTEGER, counter, gauge o TimeTicks). alarmsampletype: el método de cálculo del valor que se compara con el umbral, puede ser absoluto (absolutevalue) o diferencial (deltavalue). alarmvalue: valor de la variable en el último periodo de muestreo. alarmstartupalarm: si se dispara por subida (risingalarm), bajada (fallingalarm) o ambos (risingorfallingalarm). alarmrisingthreshold: umbral para disparo de alarma por subida. alarmfallingthreshold: umbral para disparo de alarma por bajada. alarmrisingeventindex/alarmfallingeventindex: índice del evento llamado (tabla de eventos) cuando se cruza el umbral. alarmowner y alarmstatus. Se puede programar alarmas con ciclos de histéresis para evitar disparos ante pequeñas fluctuaciones alrededor del umbral.
Grupo Filters Observa paquetes seleccionados de un interfaz de red. Dos tipos de filtros: Filtro de datos: paquetes que tienen un determinado patrón de bits que no tienen un determinado patrón. Filtro de estado: paquetes con un determinado estado (error CRC, longitud menor de 64 bytes o mayor de 1518 bytes...). Podemos construir un test con la combinación de varios filtros mediante operaciones lógicas AND y OR. Un canal es el flujo de paquetes que pasan un test, hay un contador del número de paquetes del canal. Se puede poner un evento si el contador pasa de un determinado valor (grupo event). Se pueden capturar los paquetes de un canal (grupo capture). Hay dos tablas de control: filtertable y channeltable. Grupo Capture Captura paquetes de un determinado canal del grupo filtros. Tablas de control (buffercontroltable) y de datos (capturebuffertable). Estructura de la tabla de control: buffercontrolindex: identifica una entrada que define la captura de un canal. buffercontrolchannelindex: índice del canal fuente de los datos channelindex. buffercontrofullstatus: dice si el buffer está lleno o le queda espacio. buffercontrolfullaction: comportamiento con buffer lleno (bloqueado/circular). buffercontrolcaptureslicesize:número de octetos capturados por paquete. buffercontroldownloadslicesize/buffercontroldownloadoffset: número de octetos/offset devueltos ante una petición snmp. buffercontrolmaxoctectsrequested: máximo tamaño del buffer solicitado. buffercontrolmaxoctectsgranted: máximo tamaño del buffer garantizado. buffercontrolcapturedpackets: nº de paquetes en el buffer actualmente. buffercontrolturnontime: valor de sysuptime cuando el buffer se inició por primera vez.
Grupo Capture Estructura del buffer de datos: capturebuffercontrolindex: mismo valor que buffercontrolindex. capturebufferindex: índice de la tabla, identifica un paquete capturado. capturebufferpacketid: índice que describe el orden en el que el paquete fue recibido en un interfaz particular. capturebufferpacketdata: datos del paquete. capturebufferpacketlength: longitud del paquete capturado o porción de éste. capturebufferpackettime: tiempo de captura referido al inicio del buffer. capturebufferpacketstatus: estado de error del paquete. Grupo Event Soporta la definición de eventos que pueden ser disparado por una condición definida en la MIB (alarma, captura de un filtro). Un evento puede a su vez disparar una acción definida en la MIB: Guardar información en un log. Envío de un trap. Una tabla de control (eventtable) y una de datos (logtable). Estructura de la tabla de control: eventindex:indice. eventdescription: descripción textual. eventtype: puede tomar los valores none, log, snmp-trap o log-and-trap. eventcommunity: comunidad para enviar el trap si es de tipo trap. eventlasttimesent: valor sysuptime del último evento de esta entrada generado. eventowner y eventstatus.
Grupo Event Estructura de la tabla de datos (asociada con eventos de tipo log): logeventindex: índice del evento asociado (eventindex). logindex: índice de la tabla. logtime: valor de sysuptime cuando se creo la entrada en la tabla. logdescription: descripción dependiente de la implementación. RMON2 Decodifica paquetes de las capas 3 a 7 del modelo OSI. Visibilidad a nivel de red. Observa cabeceras nivel de red (normalmente IP) para detectar cosas como: Sobrecarga de LAN por tráfico externo entrante y su origen. Sobrecarga de router por trafico interno saliente y su origen. Sobrecarga por tráfico que atraviesa la red y su origen. Visibilidad a nivel de aplicación. Observa cabeceras de niveles altos (tcp, http, ftp, e-mail ).
MIB de RMON2 RMON2 es una extensión de RMON que añade nuevos grupos: Directorio de protocolos (protocoldir): directorio de los protocolos que la sonda puede interpretar. Distribución de protocolos (protocoldist): estadísticas de tráfico generado por protocolo en la LAN. Mapa de direcciones (addressmap): asocia cada dirección de red con MAC y puerto de dispositivo. Host de nivel de red (nlhost): estadísticas de tráfico en hosts identificados por la dirección de red. Matriz de nivel de red (nlmatrix): estadísticas de tráfico entre pares de hosts identificados por dirección de red. Host de aplicación (alhost): estadísticas de tráfico en hosts identificados por dirección de aplicación (protocolos de capas entre 4 y 7). Matriz de Aplicación (almatrix): estadísticas de tráfico en pares de hosts identificados por la dirección de aplicación. Historial de usuario (usrhistory): periódicamente muestrea parámetros de variables y logs definidos de usuario. Configuración (probeconfig): define parámetros de configuración estándar para la sonda. Nuevas características funcionales Indexación de tablas con objetos externos. En RMON1 las tablas de datos se indexan con: Un índice local que coincide con el de la tabla de control correspondiente. Y después el índice particular de esta tabla. En RMON2 las tablas de datos se indexan: El índice de la tabla de control correspondiente (externo). Y después el índice particular de esta tabla. Indexación de tablas por filtro de tiempo. El gestor hace un sondeo periódicamente a las sondas para obtener valores de las tablas (monitorización). Con un filtro de tiempo se devuelve únicamente los valores que han cambiado desde un instante determinado en la misma petición GetRequest. Para implementar esto se crea un índice en la tabla de datos formado por: Timestamp: marca de tiempo (sysuptime) de la última vez que se actualizó un determinado parámetros (entrada en la tabla). Index: índice que identifica de forma única el parámetros que se monitoriza.