1. IOS

Lo primero de todo para tener una red operativa es crear el procedimiento para el mantenimiento de esta. Dentro de este incluiremos:

   - Documentación: documentar todo

   - Monitorización: proactividad

   - Control de Cambios: Calendario de Ventanas de Mantenimiento

   - Comunicación: ¿qué esta sucediendo?

   - Consistencia en el Diseño: fabricantes, plantillas, backups,etc.

   - Equipos: actualización de dispositivos. ¡¡Cisco recomienda cada 3 años!!




Para el mantenimiento de las IOS de los equipos necesitaremos:


   - Servidores TFTP/FTP/HTTP: para copiar las configuraciones.


          router#copy startup-config tftp://10.0.0.1/backup.cfg



          FTP y HTTP con User/Pwd:

         router#copy startup-config ftp://user:password@10.0.0.1/backup.cfg
         router#copy startup-config htttp://user:password@10.0.0.1/backup.cfg


        Podemos crear un usuario tanto para FTP como para HTTP para que no sea necesario:


         router(config)#ip ftp username paco
         router(config)#ip ftp password lab

         router(config)#ip http client username paco
         router(config)#ip http client password lab


   - Archivo de Configuraciones automáticas: entramos en el modo archive del router


         router(config)#archive

Lo primero es crear la ruta donde se copiarán los backup:

Para copiar en la flash, el uso de las opciones $h (para que registre el hostname del equipos) y el $t (para que registre el momento en que se copia) nos ayudan a completar el comando:

Luego la periodicidad la configuramos con el comando "time-period" en minutos

El comando maximum es para decirle el número de copias a mantener.

El comando write-memory hace que cada vez que alguien guarde la configuración (copy run st o wr) en el equipo, se copiará un backup.



   - Recuperación de configuraciones: para cambiar la configuración a la de backup o restaurarla tendríamos que hacer un erase startup.config y reiniciar. Después copiar la configuración. Esta sigue siendo la forma más segura, pues al arrancar de nuevo el equipo vemos que comandos vamos metiendo y cuales van fallando pero para evitar este proceso usamos el comando configure replace. Directamente coge las configuraciónes y las compara. Sin embargo, no la reemplaza una por otra, sino que si ve un comando diferente en la que está corriendo sobre la que queremos recuperar, primero negará el comando de la activa y luego introducirá el de la que queremos recuperar. Esto puede crearnos problemas. Para recuperar con configure replace:

Y le damos la ruta. Luego hay más opciones lógicas. Comprobadlas.

   - Registro: necesitamos registrar los sucesos del equipo. Para ello es importante también que la hora de los equipos esté sincronizada para facilitarnos el troublshooting.

Lo primero es poner en hora al equipo. Le decimos en que zona horaria está:

Y le añadimos un Servidor NTP (Network Time Protocol). El Servidor será el que sincronize la hora del dispositivo. Podemos hacer contra un NTP privado que esté en nuestra red o contra uno público:

    (config)#ntp server 10.0.0.1

    (config)#ntp server es.pool.ntp.org

Y ahora el registro (logging). Podemos decirle donde registrarlos (local o remoto) y el nivel de registro (registramos en función de la criticidad)

Los mensaje locales del SYSLOG que nos da el router (%SYS-...)  es recomendable mandarlos a un servidor central que los almacena. Programas como Kiwi lo hacen.  Para configurarlo es tan simple como:


(config)logging X.X.X.X - dirección ip del servidord SYSLOG (Kiwi, Cacti, Solarwinds)

(config)logging trap ? - podemos asignar que alertas debe enviar en función de la severidad


Cuando nos enfrentamos a un problema en IT, desde la perspectiva del campo de las redes tenemos que hacer un troubleshooting de abajo (capa 1) hacia arriba (capa 7).

Una buena manera es hacer ping (capa 3). Si no llega el ping, podemos pensar que el problema está de capa 3 para abajo. Si llega, es de capa 3 para arriba (normalmente de capa 7, en aplicación). Hay una excepción en la capa 4, pues nos podemos encontrar un Firewall que descarte el tráfico del ping o del puerto de capa 4 de la aplicación.

El traceroute y el traceroute mac (para este tiene que estar el CDP habilitado) nos ayudarán a localizar dónde está el problema o por lo menos entre que 2 puntos está el problema.

Por último, si queremos evitar que nos salgan continuamente los mensajes del log cuando estamos conectados por consola:

(config)#no logging console



Comandos útiles para el troubleshooting:

Es importante usar filtros. Cuando trabajemos con equipos grandes, la información que nos muestran los comandos show generales es demasiada y no facilita el trabajo

#sh ip route X.X.X.X X.X.X.X longer-prefixes

#sh processes cpu history

#sh processes cpu | incl - filtramos el proceso o un campo

#sh proc cpu | excl 0.00%__0.00%__0.00% - excluye todos los procesos que no tengan nada

1% son los procesos internos y los paquetes procesados.
0% es solo el proceso de los paquetes

Recordad que el switching tanto en switches como en routers se procesa a través de la tecnología ASICS, que le quita todo el trabajo de proceso de paquetes. es muy raro ver un switch con un 30 % por ejemplo.

(config)#alias exec proc sh proc cpu | excl 0.00%__0.00%__0.00% - luego ponemos "proc"

#sh ip inter | excl unassigned - nos muestra interfaces no asignadas

#sh ip inter | incl error|drop- nos muestra interfaces con errores y drops

#sh run | section - nos muestra esa sección de la configuración

#show version - datos sobre el hardware y software

#show tech.support - datos que nos pide el TAC de Cisco. Es un paquete de "shows"

#show memmory - vemos cómo está distribuida la memoria del equipo

#show inventory -  para ver los componentes de hardware que lleva el equipo

#show diag -  parecido al inventory pero más detallado

#telnet X.X.X.X 3356 - para comprobar puerto remotos (show sessions para ver las conexiones)

#ping source -  hacemos ping desde la interface que le digamos

#ping repeat -  número de pings lanzados

#ping size X  - para decirle que tamaño de paquete enviamos

#ping df-bit - no fragmenta el paquete. Comprobamos si se está fragmentando en el algún salto

Imaginemos que tenemos un problema de comunicación entre nuestro proveedor y nosotros: hay comunicación pero va lenta. Hacemos ping y llegamos. Sin embargo, si hacemos un ping con df-bit no llegamos. 

R1#ping 10.0.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/24 ms

R1#ping 10.0.0.2 df-bit Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds: Packet sent with the DF bit set MMMM Success rate is 0 percent (0/5)

¿Qué quiere decir esto? Que los paquetes se están fragmentando porque cuando le mandamos sin fragmentación (df-bit) no llegan. Nosotros sabemos que desde nuestro equipo, al tener una itnerface ethernet estamos mandando los paquetes con una mtu de 1500. Tendríamos que investigar que tamaño tiene la mtu del ISP:

R1#ping 10.0.0.2 size 1499 df-bit Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds: Packet sent with the DF bit set MMMM Success rate is 0 percent (0/5)

R1#ping 10.0.0.2 size 1498 df-bit Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds: Packet sent with the DF bit set MMMM Success rate is 0 percent (0/5)

Así hasta que nos respondiera el ping. Para evitar lanzar uno a uno tenemos este truco donde usamos el ping extendido:

R1#ping Protocol [ip]: Target IP address: 10.0.0.2 Repeat count [5]: 1 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: Type of service [0]: Set DF bit in IP header? [no]: y Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: y Sweep min size [36]: 1400 Sweep max size [18024]: 1500 Sweep interval [1]: Type escape sequence to abort. Sending 101, [1400..1500]-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds: Packet sent with the DF bit set !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!MMMMMMMM Success rate is 92 percent (93/101), round-trip min/avg/max = 8/10/12 ms

La mtu configurada en el ISP es de 1492.

RENDIMIENTO DEL EQUIPO

PROCESAMIENTO

Para chequear el rendimiento del equipo miraremos a los procesos que están corriendo. Para ello usamos el comando show process cpu o show process cpu history

Hay cuatro procesos clave que nos podrían llevar al equipo a una sobrecarga de procesamiento y dejarlo fuera de servicio. Son.

 - ARP Input - Cuando hacemos una ruta por defecto y la apuntamos a una interface de broadcast, como por ejemplo una ethernet (ip route 0.0.0.0 0.0.0.0 Fa0/0), cada vez que quiera salir tráfico a una ruta desconocida, mandará un broadcast por la interface y recibirá los ARP Input. Es mejor configurar como ruta por defecto una dirección ip (ip route 0.0.0.0 0.0.0.0 86.25.32.21)

 - ARP Bacground - tareas de ARP  como el clear, flush, age pueden sobrecargar

 - Net Background - Chequeamos las interfaces, sus throtles (la interface deja de funcionar momentáneamente y descarta paquetes) , overruns, ignores que tienen que ver con el procesamiento. Si vemos muchos de estos, es probable que haya una sobrecarga del proceso

 - IP Background - Se encarga de Interfaces up/down, encapsulación, cambios de Ip.

 - TCP Timer - Si este proceso está muy alto, vemos los detalles del protocolo:

show tcp statistics

Podemos comprobar errores, conexiones, paquetes duplicados,etc

show tcp brief

Sesiones TCP activas establecidas con nuestro router. Vemos ip y puerto 

 - Virtual Template Background - gestiona las conexiones vty. Muchas pueden sobrecargar

 - FIB Control Timer - gestiona las estadísticas de la FIB, las vecindades y registro

 - TTY background - gestiona las líneas de consola, auxiliar y async.

MEMORIA


¡¡Que el equipo se quede sin memoria es de lo peor que nos puede pasar!!


Si vemos que metemos un comando show y no nos devuelve nada, si no podemos entrar en el modo exec # o si vemos el típico mensaje de Syslog: SYS-2-MALLOCFAIL, es que estamos teniendo un problema de memoria.

Tenemos que comprobar que la imagen que tiene el equipo es la correcta para esa plataforma. Podría estar equivocada y requerir más memoria de la que puede soportar el equipo.

También podremos encontrarnos alguna imagen con BUGS (errores de software). Aquí no nos queda otra que buscar la información en Cisco para solucionar el problema.

Los ataques DoS también afectan a la memoria. Su objetivo es dejar al equipo sin memoria.

BGP -  si el equipo gestiona muchas rutas, ojo con BGP que usa mucha memoria.


show process memory

INTERFACES

Las interfaces necsitan del procesador para los paquetes y de la memoria para los buffers. Una sobrecarga de alguno de ellos afecta a las interfaces. Veremos descarte de paquetes o la imposibilidad de llegar a los destinos.

Cuando nos enfrentamos a problemas con las interfaces deberíamos chequear el modo de switching que tiene configurado el equipos: process, fast-switching o CEF.

Debemos verificar el modo de switching, la tabla de rutas y la tabla ARP Cache (sh ip cef)


2. CAPA 2