El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Esta página proporciona algunas pautas generales sobre el uso de las depuraciones disponibles en las plataformas Cisco IOS®, así como ejemplos para el uso adecuado de la debug ip packet
y depuración condicional.
Nota: Este documento no explica cómo utilizar e interpretar los comandos y salidas debug específicos. Consulte la documentación de Referencia de Comandos Debug de Cisco correspondiente para obtener información sobre debug
comandos.
El resultado de debug
los comandos EXEC privilegiados proporcionan información de diagnóstico que incluye una variedad de eventos de conexión entre redes relacionados con el estado del protocolo y la actividad de red en general.
Cisco recomienda que tenga conocimiento sobre estos temas:
Conexión al router utilizando los puertos de consola, auxiliares y vty
Problemas generales de configuración de Cisco IOS
Interpretación de resultados de depuración de Cisco IOS
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Uso debug
con precaución. En general, se recomienda que estos comandos se utilicen sólo bajo la dirección del representante de soporte técnico de su router cuando se intenta resolver problemas específicos.
La habilitación de la depuración puede interrumpir el funcionamiento del router cuando las redes interconectadas experimentan condiciones de carga elevadas. Por lo tanto, si el registro está activado, el servidor de acceso puede congelarse intermitentemente tan pronto como el puerto de la consola se sobrecargue con mensajes de registro.
Antes de iniciar un debug
, tenga en cuenta siempre el resultado que generará este comando y la cantidad de tiempo que puede tardar. Por ejemplo, si tiene un router con una interfaz de velocidad básica (BRI), debug isdn q931
probablemente no dañará el sistema. Pero si se realiza la misma depuración en un AS5800 con configuración E1 completa, probablemente se genere una gran entrada y el sistema se bloquee y deje de responder.
Antes de la depuración, observe la carga de la CPU con el show processes cpu
comando. Verifique que tenga suficiente CPU disponible antes de comenzar las depuraciones. Consulte Resolución de problemas por uso excesivo de CPU en routers de Cisco para obtener más información. Por ejemplo, si tiene un router Cisco 7200 con una interfaz ATM que realiza puentes, entonces, según la cantidad de subinterfaces configuradas, el reinicio del router puede utilizar demasiada CPU. La causa aquí es que, para cada circuito virtual (VC),se necesita generar un paquete de unidad de datos del protocolo de puente (BPDU). Comenzar con las depuraciones en momentos tan críticos puede hacer que aumente drásticamente la utilización del CPU y resulte en un bloqueo o en una pérdida de conectividad de red.
Nota: Cuando se ejecutan las depuraciones, a menudo no ve el mensaje del router, especialmente cuando la depuración es intensiva. Pero, en la mayoría de los casos, puede utilizar los comandos no debug all o undebug all para detener las depuraciones. Consulte la sección Obtención de Salidas de Debug para obtener más información sobre el uso seguro de debugs.
Además de los puntos mencionados arriba, asegúrese de comprender el impacto de las depuraciones en la estabilidad de la plataforma. Debería considerar también a qué interfaz del router debe conectarse. Esta sección incluye algunas pautas.
Los routers pueden mostrar resultados de depuración para diversas interfaces, dentro de los cuales se encuentran los puertos de consola, auxiliares y vty. Los routers también pueden registrar mensajes a un búfer interno, a un servidor syslog unix externo. Las instrucciones y advertencias para cada método se detallan a continuación:
Si está conectado a la consola, en configuraciones normales, no es necesario realizar ningún trabajo adicional. La salida de debug debería mostrarse automáticamente. Pero, asegúrese de que logging console level
se establece como se desea y el registro no se ha desactivado con el no logging console
comando.
Advertencia: Los debugs excesivos al puerto de consola de un router pueden hacer que se bloquee. Esto se debe a que el router da prioridad automáticamente a la salida de la consola por encima de otras funciones del router. Por lo tanto, si el router procesa una salida grande del depurador al puerto de la consola, puede bloquearse. Por lo tanto, si el resultado de la depuración es excesivo, utilice los puertos vty (telnet) o las memorias intermedias de registro para obtener sus depuraciones. Se proporciona más información a continuación:
Nota: De forma predeterminada, el registro está habilitado en el puerto de consola. Por lo tanto, el puerto de la consola siempre procesa el resultado de la depuración aunque se estuviese utilizando otro puerto u método (como Aux, vty o búfer) para capturar el resultado. Es por ello que Cisco recomienda que, bajo condiciones normales de funcionamiento, tenga habilitado el comando no logging console en todo momento y use otros métodos para capturar depuraciones. En situaciones en las que necesite usar la consola, vuelva a activar temporalmente el registro de consola.
Si está conectado a través de un puerto auxiliar, escriba el terminal monitor
comando. Verifique también que el no logging on
no se ha activado en el router.
Nota: Si utiliza el puerto auxiliar para monitorear el router, tenga presente que, cuando el router se reinicia, el puerto auxiliar no muestra la salida de la secuencia de inicio. Conéctese al puerto de la consola para ver la secuencia de arranque.
Si está conectado a través de un puerto auxiliar o a través de telnet, escriba el terminal monitor
comando. Verifique también que el no logging on
no se ha utilizado.
El dispositivo de registro predeterminado es la consola; todos los mensajes se muestran en la consola, a menos que se indique lo contrario.
Para registrar mensajes en un búfer interno, utilice el logging buffered
comando de configuración del router. Esta es la sintaxis completa de este comando:
logging buffered no logging buffered
logging buffered
copia los mensajes de registro en un búfer interno en lugar de escribirlos en la consola. El búfer es originalmente circular, por lo que los mensajes nuevos sobrescriben a los anteriores. Para mostrar los mensajes que se registran en el búfer, utilice el comando EXEC privilegiado show logging
. El primer mensaje mostrado es el más antiguo del buffer. Puede especificar el tamaño del búfer así como el nivel de gravedad de los mensajes que ingresarán al registro.
Consejo: Asegúrese de que hay suficiente memoria disponible en el cuadro antes de ingresar el tamaño del buffer. Utilice el IOS de Cisco show proc mem
para ver la memoria disponible.
no logging buffered
cancela el uso del búfer y escribe mensajes en la consola (el valor predeterminado).
Para registrar mensajes en el host del servidor Syslog, utilice el comando logging router configuration. La sintaxis completa de este comando es la siguiente:
loggingno logging
logging
identifica un host del servidor syslog para recibir mensajes de registro. El argumento < ip-address> es la dirección IP del host. Si se ejecuta este comando más de una vez, se crea una lista de servidores Syslog que reciben los mensajes de registro.
no logging
elimina el servidor syslog con la dirección especificada de la lista de syslogs.
Configure su software de emulador de terminal (por ejemplo, HyperTerminal) de modo que pueda capturar la salida de debug a un archivo. Por ejemplo, en HyperTerminal, haga clic en Transfer
y, a continuación, haga clic en Capture Text
y elija las opciones adecuadas. Para obtener más información, refiérase a Captura de la Salida de Texto desde Hyper Terminal. Para otro software de emulador de terminal, refiérase a la documentación del software.
Habilitar las marcas de tiempo en milisegundos (msec) mediante el service timestamps
comando:
router(config)#service timestamps debug datetime msec router(config)#service timestamps log datetime msec
Estos comandos agregan sellos de hora a las depuraciones en el formato MMM DD HH:MM:SS, indicando la fecha y hora según el reloj del sistema. Si el reloj del sistema no ha sido configurado, un asterisco (*) precede la fecha y hora para indicar que es probable que estos datos no sean correctos.
Por lo general, es aconsejable configurar sellos de hora en milisegundos, ya que esto brinda un nivel alto de claridad al analizar los resultados de la depuración. Los sellos de fecha y hora en milisegundos proporcionan una mejor indicación de la sincronización de los diversos eventos de debug entre sí. Sin embargo, observe que, cuando el puerto de consola genera muchos mensajes, puede que éstos no se correlacionen con la temporización real del evento. Por ejemplo, si activa debug x25
todos en una caja que tiene 200 VC y el resultado se registra en el búfer (mediante el no logging console
y logging buffered
, la marca de tiempo mostrada en la salida de depuración (dentro del búfer) puede no ser la hora exacta en que el paquete pasa a través de la interfaz. Por lo tanto, no utilice sellos de hora mseg para demostrar problemas de rendimiento sino para obtener información relativa acerca de cuándo tienen lugar los eventos.
Para detener una depuración, utilice el no debug all
or undebug all
comandos. Verifique que las depuraciones se hayan desactivado mediante el comando show debug
.
Recuerde que los comandos no logging console
y terminal no monitor
evitar que la salida se produzca en la consola, Aux o vty respectivamente. No detienen la depuración y por lo tanto agotan los recursos de router.
debug ip packet
genera información sobre los paquetes que el router no conmuta rápidamente. Sin embargo, como genera un resultado para cada paquete, el resultado puede ser amplio y, por lo tanto, ocasionar el bloqueo del router. Por esta razón, utilice únicamente debug ip packet
en los controles más estrictos, como se describe en esta sección.
La mejor manera de limitar el resultado de debug ip packet
es para crear una lista de acceso que enlazó a la depuración. Sólo los paquetes que coincidan con los criterios de la lista de acceso estarán sujetos a debug ip packet
. Esta lista de acceso no necesita aplicarse en ninguna interfaz, sino que se aplica a la operación de debugging.
Antes de usar debugging ip packet
, tenga en cuenta que el router está realizando fast switching de forma predeterminada, o que puede estar haciendo CEF switching si está configurado para hacerlo. Esto quiere decir que, una vez que esas técnicas están en su lugar, no se envía el paquete al procesador y, por lo tanto, la depuración no muestra nada. Para que esto funcione, debe desactivar el fast switching en el router con no ip route-cache
(para paquetes de unidifusión) o no ip mroute-cache
(para paquetes de multidifusión). Esto debería aplicarse en las interfaces en las que se supone que el tráfico fluye. Verifique esto con el show ip route
comando.
La inhabilitación de la conmutación rápida en un router que administra una gran cantidad de paquetes puede causar picos de uso de la CPU de modo que el equipo se cuelgue o pierda la conexión con sus pares.
No inhabilite la opción de conmutación rápida en un router que esté ejecutando la Conmutación de protocolo de identificación múltiple (MPLS). MPLS se utiliza junto con CEF. Por lo tanto, desactivar la conmutación rápida en la interfaz puede tener efectos desastrosos.
Consideremos un escenario de ejemplo:
La Lista de acceso configurada en el router_122 es:
access-list 105 permit icmp host 10.10.10.2 host 13.1.1.1 access-list 105 permit icmp host 13.1.1.1 host 10.10.10.2
Esta lista de acceso permite cualquier paquete Internet Control Message Protocol (ICMP) del router del host_121 (con la dirección IP 10.10.10.2) al router del host_123 (con la dirección IP 13.1.1.1), así como en la dirección contraria. Es importante que permita los paquetes en ambas direcciones, de lo contrario, el router puede perder el paquete ICMP que está regresando.
Retire la conmutación rápida en una sola interfaz en el router 122. Esto significa que solo puede ver las depuraciones de los paquetes destinados a esa interfaz como se ven desde la perspectiva del IOS que intercepta el paquete. De las depuraciones, estos paquetes aparecen con "d=". Dado que aún no ha desactivado el fast switching en la otra interfaz, el paquete de devolución no está sujeto a debug ip packet
. Este resultado muestra la manera de deshabilitar el switching rápido:
router_122(config)#interface virtual-template 1 router_122(config-if)#no ip route-cache router_122(config-if)#end
Debe activar debug ip packet
con la lista de acceso definida anteriormente (access-list 105).
router_122#debug ip packet detail 105 IP packet debugging is on (detailed) for access list 105 router_122# 00:10:01: IP: s=13.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:10:01: ICMP type=0, code=0 ! -- ICMP packet from 13.1.1.1 to 10.10.10.2. ! -- This packet is displayed because it matches the ! -- source and destination requirements in access list 105 00:10:01: IP: s=13.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:10:01: ICMP type=0, code=0 00:10:01: IP: s=13.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:10:01: ICMP type=0, code=0
Ahora, retiremos la conmutación rápida de la otra interfaz (en el router_122). Esto significa que todos los paquetes a través de esas dos interfaces ahora son conmutados por paquetes (lo que es un requisito para debug ip packet
):
router_122(config)#interface serial 3/0 router_122(config-if)#no ip route-cache router_122(config-if)#end router_122# 00:11:57: IP: s=10.10.10.2 (Virtual-Access1), d=13.1.1.1 (Serial3/0), g=172.16.1.6, len 100, forward 00:11:57: ICMP type=8, code=0 ! -- ICMP packet (echo) from 10.10.10.2 to 13.1.1.1 00:11:57: IP: s=13.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:11:57: ICMP type=0, code=0 ! -- ICMP return packet (echo-reply) from 13.1.1.1 to 10.10.10.2 00:11:57: IP: s=10.10.10.2 (Virtual-Access1), d=13.1.1.1 (Serial3/0), g=172.16.1.6, len 100, forward 00:11:57: ICMP type=8, code=0 00:11:57: IP: s=13.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:11:57: ICMP type=0, code=0
Observe que la salida de debug ip packet no muestra ningún paquete que no coincida con los criterios de la lista de acceso. Para obtener más información sobre este procedimiento, refiérase a Comprensión de los Comandos Ping y Traceroute.
Para obtener más información sobre cómo crear listas de acceso, refiérase a Registro de Lista de Acceso IP Estándar.
Cuando se habilita la función Conditionally Triggered Debugging, el router genera mensajes de debugging para los paquetes que entran o salen del router en una interfaz especificada; el router no genera un resultado de la depuración para los paquetes que entran o salen por una interfaz diferente.
Observe una implementación simple de depuraciones condicionales. Tenga en cuenta esta situación: el router que se muestra a continuación (trabol) tiene dos interfaces (serial 0 y serial 3) que ejecutan la encapsulación HDLC.
Puede utilizar la debug serial interface
para observar las señales de mantenimiento HDLC recibidas en todas las interfaces. Puede observar las señales de mantenimiento en ambas interfaces.
traxbol#debug serial interface Serial network interface debugging is on traxbol# *Mar 8 09:42:34.851: Serial0: HDLC myseq 28, mineseen 28*, yourseen 41, line up ! -- HDLC keeplaive on interface Serial 0 *Mar 8 09:42:34.855: Serial3: HDLC myseq 26, mineseen 26*, yourseen 27, line up ! -- HDLC keeplaive on interface Serial 3 *Mar 8 09:42:44.851: Serial0: HDLC myseq 29, mineseen 29*, yourseen 42, line up *Mar 8 09:42:44.855: Serial3: HDLC myseq 27, mineseen 27*, yourseen 28, line up
Habilite las depuraciones condicionales para la interfaz serial 3. Esto significa que solamente se muestran los debugs para la interfaz serial 3. Use el comando debug interface <interface_type interface_number>
comando.
traxbol#debug interface serial 3 Condition 1 set
Use el comando show debug condition
para verificar que la depuración condicional esté activa. Tome en cuenta que está activa una condición para la interfaz serial.
traxbol#show debug condition Condition 1: interface Se3 (1 flags triggered) Flags: Se3 traxbol#
Tenga en cuenta que sólo se muestran las depuraciones para la interfaz de serie 3.
*Mar 8 09:43:04.855: Serial3: HDLC myseq 29, mineseen 29*, yourseen 30, line up *Mar 8 09:43:14.855: Serial3: HDLC myseq 30, mineseen 30*, yourseen 31, line up
Use el comando undebug interface <interface_type interface_number>
para quitar la depuración condicional. Se recomienda desactivar las depuraciones (por ejemplo, con undebug all) antes de eliminar el activador condicional. Esto es así para evitar un aluvión de salidas de depuración cuando se elimina la condición.
traxbol#undebug interface serial 3 This condition is the last interface condition set. Removing all conditions may cause a flood of debugging messages to result, unless specific debugging flags are first removed. Proceed with removal? [yes/no]: y Condition 1 has been removed traxbol
Ahora puede observar que se muestra la depuración de las interfaces serial 0 y serial 3.
*Mar 8 09:43:34.927: Serial3: HDLC myseq 32, mineseen 32*, yourseen 33, line up *Mar 8 09:43:44.923: Serial0: HDLC myseq 35, mineseen 35*, yourseen 48, line up
Advertencia: Algunas operaciones de debugging son condicionales en sí mismas. Un ejemplo es debugging atm. Con depuración ATM debe especificar explícitamente la interfaz para la cual las depuraciones se deben habilitar en vez de permitir las depuraciones en todas las interfaces atm y especificar una condición.
Esta sección muestra la forma correcta de limitar la depuración de paquetes de ATM a una subinterfaz:
arielle-nrp2#debug atm packet interface atm 0/0/0.1 !--- Note that you explicitly specify the sub-interface to be used for debugging ATM packets debugging is on Displaying packets on interface ATM0/0/0.1 only arielle-nrp2# *Dec 21 10:16:51.891: ATM0/0/0.1(O): VCD:0x1 VPI:0x1 VCI:0x21 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:0007 Length:0x278 *Dec 21 10:16:51.891: 0000 FFFF FFFF FFFF 0010 7BB9 BDC4 0800 4500 025C 01FE 0000 FF11 61C8 0A30 *Dec 21 10:16:51.891: 4B9B FFFF FFFF 0044 0043 0248 0000 0101 0600 0015 23B7 0000 8000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0010 7BB9 BDC3 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.895: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.895: arielle-nrp2#
Si intenta habilitar atm debugging
en todas las interfaces (con una condición aplicada), el router puede bloquearse si tiene un gran número de subinterfaces ATM. Se muestra un ejemplo del método incorrecto para depurar el atm.
En este caso, puede ver que se aplica una condición, pero también que ésta no tiene ningún efecto. Aún puede ver el paquete desde la otra interfaz. En este escenario de laboratorio, solo tiene dos interfaces y muy poco tráfico. Si el número de interfaces es elevado, el resultado de la depuración de todas las interfaces es extremadamente alto y puede provocar el bloqueo del router.
arielle-nrp2#show debugging condition Condition 1: interface AT0/0/0.1 (1 flags triggered) Flags: AT0/0/0.1 ! -- A condition for a specific interface. arielle-nrp2#debug atm packet ATM packets debugging is on Displaying all ATM packets arielle-nrp2# *Dec 21 10:22:06.727: ATM0/0/0.2(O): ! -- You see debugs from interface ATM0/0/0/.2, even though the condition ! -- specified ONLY AT0/0/0.1 VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:06.727: 0000 0000 0180 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:06.727: 0002 000F 0000 *Dec 21 10:22:06.727: un a *Dec 21 10:22:08.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:08.727: 0000 0000 0180 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:08.727: 0002 000F 0000 *Dec 21 10:22:08.727: ll *Dec 21 10:22:10.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:10.727: 0000 0000 0080 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:10.727: 0002 000F 0000 *Dec 21 10:22:10.727: *Dec 21 10:22:12.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:12.727: 0000 0000 0080 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:12.727: 0002 000F 0000 *Dec 21 10:22:12.727: *Dec 21 10:22:13.931: ATM0/0/0.1(O): !--- You also see debugs for interface ATM0/0/0.1 as you wanted. VCD:0x1 VPI:0x1 VCI:0x21 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:0007 Length:0x278 *Dec 21 10:22:13.931: 0000 FFFF FFFF FFFF 0010 7BB9 BDC4 0800 4500 025C 027F 0000 FF11 6147 0A30 *Dec 21 10:22:13.931: 4B9B FFFF FFFF 0044 0043 0248 0000 0101 0600 001A 4481 0000 8000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0010 7BB9 BDC3 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.935: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Revisión | Fecha de publicación | Comentarios |
---|---|---|
2.0 |
29-Apr-2022 |
Actualización y eliminación de enlaces rotos. |
1.0 |
02-Dec-2013 |
Versión inicial |