jueves 25 de febrero de 2010

IOS y configuraciones resistentes a errores

Un cortito mientras estudio el ISCW...

Siempre que tenemos equipos que se acceden desde muchos lugares o bien son usados para hacer laboratorios nos encontramos con que nos modifican las configuraciones o nos borran los sistemas operativos por lo que nuestro trabajo pasa de optimizar la red e inventar nuevos servicios a restaurar funcionalidad básica.

Cisco nos propone un feature llamado IOS Resilient Configuration que el equipo asegure una copia de la imagen de IOS que está corriendo así como también de la configuración actual.

Para esto, guarda una copia de cada uno de esos elementos en la flash en un directorio oculto que no puede ser accedido por los usuarios.

Algunos datos interesantes acerca de este feature son:

  • La configuración que se guarda es una copia de la running-config al momento en que el feature fue habilitado por primera vez.
  • Puede detectar diferencias en la imágen y en la config.
  • Solamente puede usar storage local, por lo que no puede guardar esto en servidores ftp o tftp remotos.
  • La única forma de deshabilitar el feature es mediante acceso por la consola.
 Se activa muy fácil:

Router(config)#
Router(config)# secure ?
  boot-config  Archive the startup configuration
  boot-image   Secure the running image
Router(config)# secure boot-config 
Router(config)# secure boot-image
Feb 25 2010 18:38:19.298 ART: %IOS_RESILIENCE-5-CONFIG_RESIL_ACTIVE: Successfully secured config archive [disk2:.runcfg-20100225-213818.ar]
Feb 25 2010 18:38:35.202 ART: %IOS_RESILIENCE-5-IMAGE_RESIL_ACTIVE: Successfully secured running image

Ahora podemos probar de hacer un listado de los directorios del disco:

Router# dir /all
Directory of disk2:/

    2  -rw-    39399484  Jan 21 2009 10:35:12 -03:00  c7200-advipservicesk9-mz.124-15.T8.bin

255774720 bytes total (176951296 bytes free)

Epa... no aparecen... probemos otra cosa...

Router# show secure bootset
IOS resilience router id 23672497

IOS image resilience version 12.4 activated at 18:38:34 ART Thu Feb 25 2010
Secure archive disk2:cisco2-C7200 type is image (elf) []
  file size is 39399460 bytes, run size is 39565104 bytes
  Runnable image, entry point 0x80008000, run from ram

IOS configuration resilience version 12.4 activated at 18:38:19 ART Thu Feb 25 2010
Secure archive disk2:.runcfg-20100225-213818.ar type is config
configuration archive size 8467 bytes

¿Cómo recupero los archivos se me los borran?

Tento que entrar al rom monitor (el ramón para los amigos) ejecutando la secuencia de control+break durante el arranque del equipo. Desde ahí sí se puede ver el bootset con los archivos.

rommon 1> dir disk2:

Ahi vas a ver la imagen de IOS asegurada que luego vas a poder bootear:

rommon 2> boot disk2:cisco2-C7200

El equipo va a arrancar, pero la configuración inicial no está, por lo que intentará arrancar el modo setup, le ponemos que no y ejecutamos:

Router(config)# secure boot-config restore disk2:.runcfg-20100225-213818.ar
Router(config)# copy disk2:.runcfg-20100225-213818.ar running-config

Voalá y hasta la próxima.

martes 16 de febrero de 2010

Cisco Certified Architect (CCAr™)

Si ustedes pensaban que ser CCIE era lo más top en cuestión de certificaciones de Cisco, se equivocaron.

A partir del 17 de febrero de 2010, se agrega un escalón nuevo a la pirámide de certificaciones que otorga el título de "Arquitecto".

Los usuarios que serán elegibles para obtenerla serán los que posean una certificación válida como experto en diseño (CCDE) que para mi punto de vista es la más dificil de obtener.

El valor del examen para ser arquitecto es de U$D 15.000 y se pagará en dos etapas:

Etapa de presentación:

Se pagarán U$D 3.750 para pedir una audiencia en donde el candidato deberá presentar un currículum y un proyecto diseñado y llevado a cabo por el mismo. Si se aprueba y luego de varios días será entrevistado telefónicamente por el jurado en donde se le harán preguntas acerca de su proyecto..

Etapa de demostración de competencias y examenes:

Se pagarán U$D 11.250 y el candidato recibirá documentación para el armado de un proyecto, que deberá ser terminado en un lapso de 14 días y deberá contener determinados temas tales como:
  • Análisis de los requerimientos del negocio.
  • Análisis de los requerimientos técnicos.
  • Alineamiento de las metas técnicas y del negocio.
  • Estimaciones de los requerimientos de cambio y soluciones a escenarios de tipo "qué pasa si...".
  • Especificaciones funcionales de la red.
  • Análisis de riesgo de negocio.
  • Creación de un plan de migración y estrategia de transición.
  • Documentación para presentar ante una audiencia técnica.
  • Documentación para presentar ante una audiencia de negocios.
  • Demostraciones de dominio de cuestiones técnicas con grado de experto.

Si este proyecto se aprueba, se deberá presentar ante el comité de tres jurados y deberá:

  1. Presentar la solución (60 minutos).
  2. Responder las preguntas del jurado (60 minutos).
  3. Recibir un cambio estructural del tipo "qué pasa si...".
  4. Crear una solución basada en los nuevos requerimientos (165 minutos).
  5. Defender la nueva solución (60 minutos).
Uff.. creo que no voy a hacer comentarios, para no influenciar los de ustedes.

Saludos.

lunes 15 de febrero de 2010

Arrancando el año en la Networking Academy.

Una vez finalizadas las vacaciones volvemos a las tareas habituales, y en lo que respecta a la Cisco Networking Academy, me han asignado para dar el primer semestre de la carrera de CCNA en la academia de Rosario los días lunes.

Si bien el primer semestre de CCNA no es el más interesante en cuanto a prácticas y laboratorios, está bueno porque se centra en los aspectos básicos de las redes y presenta como desafío motivar a los alumnos y lograr afianzar los conocimientos básicos que luego usarán en los siguientes semestres.

Aunque todos queremos dar el semestre 4 para poder usar todas las herramientas generando soluciones complejas de networking, de todas formas estoy contento con tener la posibilidad de compartir conocimientos y de algunua forma devolver todo lo que ese curso me brindó.

Nos vemos en el aula.

domingo 14 de febrero de 2010

CCNP en 45 días

Ayer al volver de mis vacaciones me llegó un mail de Cisco que me da vouchers para rendír gratis los exámenes ISCW y ONT pendientes para finalizar mi CCNP. El problema central es que tengo que hacerlos antes del 31 de marzo de 2010.

Aunque tengo un firme conocimiento de los temas de los dos exámenes, debo admitir que todas las certificaciones son muy duras y realmente se aprueba si es que se tiene un mucho conocimiento acerca de los temas tanto en teoría como en práctica.

Por esto voy a estar dedicándome a dichos exámenes durante los próximos días, con el consecuente atraso de los posts que estoy haciendo sobre multicast. De todas formas prometo que en mis ratos libres voy a ir avanzando con ellos.

Saludos.

viernes 5 de febrero de 2010

Viendo caer nuestros equipos

Uno siempre lee acerca de equipos y sistemas operativos que se cuelgan (no voy a dar nombres) y muchas veces esas situaciones nos parecen totalmente ajenas. Sin embargo, hoy voy a dar un tip que no es del todo útil, dado que no mejora la performance ni seguriza nada, sino todo lo contrario: derriba los equipos.

En el caso de cisco no es muy común ver caer los equipos, pero utilizando una suerte de "comando oculto" podemos ver la forma en que caen y se recuperan de los errores.

Este comando oculto se llama test crash y se puede utilizar de la siguiente forma:

Router#test crash
WARNING: Command selections marked with '(crash router)' will crash
         router when issued. However a selection 'C' will need to
         be issued IMMEDIATELY before these selections to enable them.


Type the number for the selected crash:
--------------------------------------
 1  (crash router) Bus Error, due to invalid address access
 2  (crash router) Bus Error, due to parity error in Main memory
 3  (crash router) Bus Error, due to parity error in I/O memory
 4  (crash router) Address Error, due to fetching code from odd address
 5  (crash router) Jump to zero
 6  (crash router) Software forced crash
 7  (crash router) Illegal read of address zero
 8  (crash router) Divide by zero
 9  (crash router) Corrupt memory
 C  Enable crash router selection marked with (crash router)
 R  (crash router) User enter read bus error address
 U  (crash router) User enter write bus error address
 W  (crash router) Software watchdog timeout (*** Watch Dog Timeout ***)
 w  (crash router) Process watchdog timeout (SYS-2-WATCHDOG)
 d  Disable crashinfo collection
 e  Enable crashinfo collection
 i  Display contents of current crashinfo flash file
 m  Write crashinfo on crashinfo RAM
 n  Change crashinfo flash file name
 q  Exit crash menu
 s  Save crashinfo to current crashinfo flash file
 c  Close current crashinfo flash file
 t  Write crashinfo on console TTY
 x  Exit crash menu
? C                                                                     


Type the number for the selected crash:
-------------------------------------- 
 1  (crash router) Bus Error, due to invalid address access
 2  (crash router) Bus Error, due to parity error in Main memory
 3  (crash router) Bus Error, due to parity error in I/O memory 
 4  (crash router) Address Error, due to fetching code from odd address
 5  (crash router) Jump to zero                                        
 6  (crash router) Software forced crash                               
 7  (crash router) Illegal read of address zero                        
 8  (crash router) Divide by zero                                      
 9  (crash router) Corrupt memory                                      
 C  Enable crash router selection marked with (crash router)           
 R  (crash router) User enter read bus error address                   
 U  (crash router) User enter write bus error address                  
 W  (crash router) Software watchdog timeout (*** Watch Dog Timeout ***)
 w  (crash router) Process watchdog timeout (SYS-2-WATCHDOG)            
 d  Disable crashinfo collection                                        
 e  Enable crashinfo collection                                         
 i  Display contents of current crashinfo flash file                    
 m  Write crashinfo on crashinfo RAM                                    
 n  Change crashinfo flash file name                                    
 q  Exit crash menu                                                     
 s  Save crashinfo to current crashinfo flash file                      
 c  Close current crashinfo flash file                                  
 t  Write crashinfo on console TTY                                      
 x  Exit crash menu                                                     
? 6                                                                     
Causing a software forced crash...                                      


 10:44:18 UTC Fri Feb 5 2010: Breakpoint exception, CPU signal 5, PC = 0x6078406C



--------------------------------------------------------------------
   Possible software fault. Upon reccurence,  please collect        
   crashinfo, "show tech" and contact Cisco Technical Support.      
--------------------------------------------------------------------


-Traceback= 0x6078406C 0x60254650 0x61366294 0x6138C3B4 0x626264B8 0x6262649C 
$0 : 00000000, AT : 654E0000, v0 : 00000049, v1 : 000000A7                    
a0 : 651A5158, a1 : 00000320, a2 : 63D143E8, a3 : 66ED5C38                    
t0 : 66ED5C38, t1 : 6590FE60, t2 : 927C0000, t3 : 00000000                    
t4 : 000008B7, t5 : 00000F3B, t6 : 00000000, t7 : 00000000                    
s0 : 64CA0000, s1 : 0000003C, s2 : 00000036, s3 : 653D0000                    
s4 : 66F08DB0, s5 : 64CA0000, s6 : 6597DAD8, s7 : 64CA0000                    
t8 : 6640BE78, t9 : 0000B798, k0 : BFC003E0, k1 : 0000FF00                    
gp : 65068FA8, sp : 66F08D98, s8 : 648E0000, ra : 60254650                    
EPC  : 6078406C, ErrorEPC : 00000000, SREG     : 3400FF03                     
MDLO : 00000000, MDHI     : 00000000, BadVaddr : 00000000                     
CacheErr : 00000000, DErrAddr0 : 00000000, DErrAddr1 : 00000000               
Cause 00000024 (Code 0x9): Breakpoint exception

File bootflash:crashinfo_20100205-104418 Device Error :Bad device info block
File disk0:crashinfo_20100205-104418 Device Error :Invalid DOS media or no media in slot
File disk1:crashinfo_20100205-104418 Device Error :No device available
File slot0:crashinfo_20100205-104418 Device Error :Bad device info block
File slot1:crashinfo_20100205-104418 Device Error :No such device
File bootflash:crashinfo_20100205-104418 Device Error :Bad device info block
File disk0:crashinfo_20100205-104418 Device Error :Invalid DOS media or no media in slot
File disk1:crashinfo_20100205-104418 Device Error :No device available
File slot0:crashinfo_20100205-104418 Device Error :Bad device info block
File slot1:crashinfo_20100205-104418 Device Error :No such device
File bootflash:crashinfo_20100205-104418 Device Error :Bad device info block

 10:44:18 UTC Fri Feb 5 2010: Breakpoint exception, CPU signal 5, PC = 0x6078406C



--------------------------------------------------------------------
   Possible software fault. Upon reccurence,  please collect
   crashinfo, "show tech" and contact Cisco Technical Support.
--------------------------------------------------------------------


-Traceback= 0x6078406C 0x60254650 0x61366294 0x6138C3B4 0x626264B8 0x6262649C
$0 : 00000000, AT : 654E0000, v0 : 00000049, v1 : 000000A7
a0 : 651A5158, a1 : 00000320, a2 : 63D143E8, a3 : 66ED5C38
t0 : 66ED5C38, t1 : 6590FE60, t2 : 927C0000, t3 : 00000000
t4 : 000008B7, t5 : 00000F3B, t6 : 00000000, t7 : 00000000
s0 : 64CA0000, s1 : 0000003C, s2 : 00000036, s3 : 653D0000
s4 : 66F08DB0, s5 : 64CA0000, s6 : 6597DAD8, s7 : 64CA0000
t8 : 6640BE78, t9 : 0000B798, k0 : BFC003E0, k1 : 0000FF00
gp : 65068FA8, sp : 66F08D98, s8 : 648E0000, ra : 60254650
EPC  : 6078406C, ErrorEPC : 00000000, SREG     : 3400FF03
MDLO : 00000000, MDHI     : 00000000, BadVaddr : 00000000
CacheErr : 00000000, DErrAddr0 : 00000000, DErrAddr1 : 00000000
Cause 00000024 (Code 0x9): Breakpoint exception

-Traceback= 0x6078406C 0x60254650 0x61366294 0x6138C3B4 0x626264B8 0x6262649C


=== Flushing messages (10:44:18 UTC Fri Feb 5 2010) ===

Buffered messages:

*Feb  5 10:42:15.167: %LINEPROTO-5-UPDOWN: Line protocol on Interface VoIP-Null0, changed state to up
*Feb  5 10:42:15.171: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to down
*Feb  5 10:42:15.171: %LINEPROTO-5-UPDOWN: Line protocol on Interface IPv6-mpls, changed state to up
*Feb  5 10:42:16.171: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
*Feb  5 10:42:17.503: %SYS-5-RESTART: System restarted --
Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 12.4(11)T2, RELEASE SOFTWARE (fc4)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Tue 01-May-07 04:19 by prod_rel_team

De más está decir que se debe usar en equipos que no estén en producción... después no me culpen si bajaron su red por usarlo en cualquier lado.

Salute!

jueves 4 de febrero de 2010

Introducción al Multicast (Parte II)

Como vimos en el capítulo anterior, unicast no escala cuando se debe enviar la misma información a muchos destinos dado que el ancho de banda requerido se multiplica por la cantidad de receptores de la información.

Por otro lado si usamos broadcast, los receptores no pueden estar atrás de un router dado que estos no los transmiten. Además estamos generando una carga intensiva en los dispositivos de red y desperdiciando ancho de banda.

Ahora bien, necesariamente tengo que aclarar un par de conceptos que son naturalmente elementales y en una magnitud tal que la mayoría de la gente nunca se detiene a pensar. Estoy hablando de la relación entre el direccionamiento de capa 2 y capa 3.

Conocemos perfectamente que a nivel de capa 3 una dirección IPv4 tiene una longitud de 32 bits y una dirección de capa 2 (MAC) del archifamoso protocolo Ethernet tiene 48 bits.

Es evidente que debemos contar con algo que relacione unívocamente cada una de estas direcciones dado que son de distinto tamaño y no es un requerimiento necesario que sean iguales.

En el caso de IPv4 existe un protocolo llamado ARP que se encarga de armar una "tabla de equivalencias" en cada host, que contiene direcciones IP y sus correspondientes MAC asociadas.

¿Por qué me detengo en este detalle?

Los equipos cuando quieren mandar información a otro host conocen la dirección IP de destino (generalmente obtenida por consultas DNS) y al momento de poner la información  en los cables, deben armar los encabezados de la capa de enlace de datos y por ende, deben conocer la dirección MAC de destino.

En multicast IPv4, existe una relación entre las direcciones MAC y las direcciones de grupo (IP's de clase D).

Supongamos el ejemplo de un servidor que envía un streaming a una LAN:


Cuando el servidor quiere usar Unicast y enviar datos a la PC D, arma los paquetes de la siguiente manera:

Capa 3:
IP Origen: 192.168.1.10
IP Destino: 192.168.1.14

Capa 2:
MAC Origen: aaaa.aaaa.aaaa
MAC Destino: 0000.0000.649a

Ahora imaginemos, que si seguimos el mismo ejemplo con Multicast a la dirección de grupo 239.1.1.10 tendríamos:
Capa 3:
IP Origen: 192.168.1.10
IP Destino: 239.1.1.10

Capa 2:
MAC Origen: aaaa.aaaa.aaaa
MAC Destino: ¿?

¿A qué dirección MAC debe enviar las tramas?

Es evidente que no puede ser ninguna MAC de alguno de los equipos, porque sino la información se transformaría en Unicast, dado que el switch replicaría la trama en un único puerto. Esto me lleva a citar una frase que siempre enfatizo con mis alumnos:

Antes de que exista Unicast, Multicast o Broadcast en capa 3, debe existir en capa 2.

Todos los hosts deben acordar una dirección MAC común que puedan utilizar para recibir las tramas dirigidas al grupo de multicast 239.1.1.10. Y no solo eso, sino que tambien el switch debe comprender que esa dirección MAC no se va a guardar como perteneciente a un solo puerto, sino a varios.

Verán ahora que la MAC en cuestión no se negocia, sino que se calcula según lo que veremos a continuación.

La IEEE registró un OUI que es el prefijo de todas las direcciones MAC relacionadas con direcciones IPv4. Dicho prefijo es: 01:00:5e

Verán el bit marcado en rojo, este es el bit menos significativo del byte más significativo de la dirección MAC (el último bit del primer byte en criollo) y determina que la MAC es de multicast. Cuando los switches ven este bit en 1 en cualquier dirección MAC entienden que no deben almacenar esa dirección en la tabla CAM dado que debe ser reenviada a varios puertos.

Ahora bien, sabemos que se calcula una dirección MAC de multicast en base a un OUI fijo y a la dirección de grupo, pero la problemática a la que nos enfrentamos es que una dirección IP tiene 32 bits y solo nos restan 24 de la dirección MAC, por lo que no podremos directamente pegar los bits de la dirección de grupo en la MAC dado que no nos alcanza el espacio. En cambio, podemos realizar el siguiente análisis:

Las direcciones de clase D se utilizan para multicast comprenden el rango desde la 224.0.0.0 a la 239.255.255.255, por lo que podemos ver que cualquier dirección que está dentro de ese rango tiene la forma:

Dado que los bits 1110 pasados a decimal son 128 + 64 + 32 + 0 = 224 y si el cuerto bit estuviese en 0 se sumarían 16 más y el 240 no está incluído en las clases D.
Si entendemos esto, podemos comprender que como estos bits siempre tienen el mismo valor para direcciones multicast de IPv4, podemos desestimarlos y no incluírlos en nuestra futura dirección  MAC de multicast:
Ahora tenemos 28 bits para almacenar y 24 bits disponibles. Ya nos estamos acercando a nuestra meta.

Lo que la gente de la IEEE pensó es en desestimar los bits 4 a 8 del primer byte y el primer bit del segundo byte y transformarlos en un único bit con valor cero.

En criollo:
  1. Tomar los 5 bits que quedan en el primer byte incluyendo el primero del byte 2.
  2. Reemplazarlos por un solo bit en cero.
Ahora si... transladamos los 24 bits a la dirección MAC de multicast.


En un ejemplo práctico:

Dirección IPv4: 224.0.0.5 (OSPF)

Binariamente es: 11100000.00000000.00000000.00000101

Quito la parte en rojo, que es siempre igual para todas las direcciones
____0000.00000000.00000000.00000101
Ahora transformo los próximos 5 bits en un solo cero:
00000000.00000000.00000101
Paso esto a hexadecimal:
00000000.00000000.00000101 = 00.00.05
Luego agrego el OUI de multicast (01:00:5E) como prefijo:
01:00:5E:00:00:05
Esa será la MAC address de multicast que todos los equipos se pondrán para recibir los datos del grupo.

Vamos a otro ejemplo:

Dirección IPv4: 239.140.125.94
En binario: 11101111.10001100.01111101.01011110
Quito los primeros 4 bits y comprimo los próximos 5: 00001100.01111101.01011110
Paso a hexadecimal:  0C:7D:5E
Agrego el OUI: 01:00:5E:0C:7D:5E

¿Fácil, no?

Ahora probemos con la IP: 231.12.125.194
En binario: 11100111.00001100.01111101.01011110
Quito los primeros 4 bits y comprimo los próximos 5: 00001100.01111101.01011110
Paso a hexadecimal:  0C:7D:5E
Agrego el OUI: 01:00:5E:0C:7D:5E <-- ¡¡¡ES LA MISMA QUE CALCULAMOS ANTES!!!

¿Qué pasó?

Cuando nosotros comprimimos los 5 bits en un solo valor en cero, estamos pisando 2^5 bits, por lo que 32 valores de direcciones IP van a corresponder a una única MAC.

Comenten por favor.

Nos vemos en la próxima.

lunes 4 de enero de 2010

Exámen CCNA en español

Comienzo el primer post del 2010 con una buena noticia:

La semana pasada estuve buscando el precio de los exámenes que me quedan dar para el CCNP y tuve la grata sorpresa de ver que el exámen de certificación CCNA actual (640-802) ya se encuentra disponible en varios idiomas (incluído el español).

En el momento en que lo tuve que rendir a principios de 2009 solo estaba disponible en inglés y japonés sólo en japón.

Mucha gente se va a poner contenta con esto ya que la barrera del idioma sumada a los nervios que se pasan al hacer el exámen son la mayoría de las veces las dificultades más grandes que tienen que atravesar los candidatos.

¡Felíz año para todos!
 
/*Google Analytics*/