viernes, 24 de febrero de 2012

Redes.10 pautas para ser un buen Administrador de Sistemas

Reglas de oro para el administrador de sistemas
Me ha encantado este artículo de Unix Craft, así que voy a traducirlo/adaptarlo (+-) por encima porque sé que puede resultar interesante.

1. Haz las cosas fáciles.
En el mundo de la administración de sistemas, siempre hay varias formas de resolver un problema o realizar una tarea. Es bueno averiguar todas las formas posibles de abordar una tarea, tanto las complejas como las simples, pero a la hora de realizarla es siempre preferible hacerlo lo más sencillo posible.

2. Realiza copias de seguridad (Backups) periódicamente.
Para un momento a pensar si tienes copias de seguridad de todas las cosas realmente importantes tanto de tus servidores, proyectos personales, ordenador en el que trabajas regularmente… En caso contrario, deja cualquier cosa y haz backups de todo cuanto antes.
Nunca se sabe cuando puede haber un fallo en una máquina y que provoque que el trabajo de mucho tiempo se vaya al traste. Por ello es indispensable mantener copias regulares de toda información relevante e importante. Tarde o temprano te sucederá y desearas tener un backup de los datos perdidos para evitar cualquier catástrofe.


3. Comprueba tus copias de seguridad (Backups) regularmente.
De nada sirve hacer copias de seguridad periódicas si no comprobamos que cuando las necesitemos van a cumplir su función. Planifica comprobaciones de backups periódicamente para verificar que se realizan correctamente y en caso de desastre serán de utilidad.

4. Monitorización.
Una buena monitorización de las máquinas que un administrador de sistemas ha de supervisar es el mejor modo de adelantarte (en la medida de lo posible) a quejas de clientes, usuarios, etc sobre fallos del servicio. Así mismo, hará tu trabajo muchísimo más fácil teniendo controlado en todo momento tus redes, servidores, recursos, etc.

5. Documentación.
Los administradores de sistemas deberían documentar todo lo que realizan en sus sistemas, aunque realmente es prácticamente imposible. No obstante conviene tener una bitácora o base de datos en la que almacenar toda la información relacionada con tareas realizadas, solución a problemas que se han presentado, puede ser muy útil en infinidad de situaciones.
Se destacan los siguientes motivos para documentar:
No aprender lo mismo dos veces. A quíen no le ha pasado de arreglar algo, dejarlo pasar, presentarse el mismo fallo al tiempo y no recordar como ha sido solucionado.
En caso de que alguien ocupe tu puesto durante un tiempo (ya sea por vacaciones o cualquier otro motivo) o tengas un empleado a tu cargo, tendrá información clara y concisa sobre como solventar problemas comunes, situaciones críticas, etc.
Compartir conocimiento es bueno, y en el campo (tan sumamente amplio) de la administración de sistemas mucho más.
No malgastes toda la RAM de tu cerebro recordando todo, descarga esa información a un fichero de texto para liberar memoria ;)

6. Planificación y estructuración.
Cuando estés realizando una tarea, manten un orden y planifica cada uno de los pasos a realizar. Esto te ayudará a prevenir los posibles riesgos de cada uno de los pasos y las opciones para evitarlos, solventarlos en caso de que ocurran, etc.

7. Usa más la línea de comandos, y menos la GUI.
Los motivos son muy simples, la línea de comandos suele ser muchísimo más rápida que las interfaces gráficas. Normalmente las GUI evitan que se comprenda el funcionamiento total del sistema, y no hay duda que para tareas repetitivas es lo más rápido y preciso. Decir por supuesto que es mucho más divertido.

8. Automatiza tareas repetitivas.
Sin duda uno de los puntos más importantes. En el momento que veas que diariamente tienes que hacer una tarea una y otra vez, programa un script o una tarea para que se ejecute de forma automática. Te ahorrará tiempo y evitará perder un valioso tiempo con tareas de “monos” que puede usarse para cosas más interesantes.

9. Ayuda a los usuarios y clientes de tus sistemas.
Puede resultar frustrante tener que explicar el funcionamiento de un sistema o la solución de un problema a un cliente con pocas nociones informáticas. Lo ideal es explicar a los usuarios en términos no técnicos cual es el problema, y como ha sido solucionado, para que comprendan que no se ha tratado de un fallo del propio sistema (suele suceder), y que debe revisarse por ejemplo la programación de una aplicación para no alterar el correcto funcionamiento del servicio.

10. Sigue aprendiendo y disfrutando.
No hay duda de que la mayoría de administradores de sistemas disfrutan muchísimo de su trabajo. Esa es la ídea, seguir disfrutando día a día y aprendiendo con ilusión, pues es un trabajo en constante evolución

Fuente : http://rm-rf.es/10-pautas-para-ser-un-buen-administrador-de-sistemas/

CheckPoint.Recover a lost root password



I wrote this procedure last year after losing the both the shell and expert password on the SPLAT NGx R65 box. This procedure has been tested on both R65 many times in production environment by myself without losing any configurations. Here it is:

#1: boot up with CentOS 5.3, 5.4 or 5.5 CD #1 (DVD will work just as well) iso. You can do this from the IBM RSA Rack (aka ILOM) or DELL DRAC card if you have one. Go to "F5" to for rescue, then enter "linux rescue"

#2: do not need to active network connecvitity, just follow the default, this will take you directly to the # prompt.

#3: mkdir /checkpoint

#4 mount /dev/sda7 /checkpoint

#5: mount /dev/sda1 /checkpoint/boot

#6: chroot /checkpoint

#7: /bin/expert_password (change your expert password here)

#8: \passwd admin (change admin password cpshell here)

#9: reboot the box

Please keep this procedure handy

Windows.Combinar una instantánea con su archivo .vhd

Discos diferenciales son aquellos que acumulan las diferencias respecto a un padre. Un disco padre, puede tener diferentes discos diferenciales y estos estar asociados a diferentes máquinas virtuales, un ejemplo para entender todo esto, podría ser:

Tenemos un disco con Windows XP al que declaramos como padre y guardamos en una carpeta con permisos de solo lectura, creamos un disco diferencial conectado a este padre que asociamos a una máquina virtual en la que instalamos el sp2. Creamos otro disco duro diferencial conectado a este padre que asociamos a una máquina virtual en la que instalamos sp3. Ahora tenemos dos máquinas virtuales, una con xp sp2 y otra con xp sp3 para que nuestros desarrolladores prueben sus programas. No entro a detallar buenas prácticas en entornos de este tipo, pero raudos y veloces seguro que habéis pensado que el rendimiento del raid donde almacenamos el disco padre, afecta al rendimiento de las VM asociadas a los discos hijos.

Una vez tenemos discos padres y discos diferenciales o hijos, podemos realizar una combinación de ambos poniendo como origen del diferencial el mismo disco padre o crear un tercer disco con la combinación de estos dos. Muy a tener en cuenta esto en el anterior ejemplo, ya que la combinación de un disco padre con el disco hijo, podría afectar a la segunda máquina virtual (atención a esto para el tema que nos ocupa en el artículo).

Entramos en materia.

Dicho todo esto, es cuando podemos decir que una instantánea de una máquina virtual, no es más que un disco diferencial de crecimiento dinámico por cada disco .vhd que contiene la VM, almacenado por defecto en la carpeta “snapshots” que hay en de cada VM, a no ser que cambiemos esta ruta en la consola de administración de hyper-v. Un aspecto importante que tenemos que conocer, es que las snapshots, a pesar de tener una estructura exactamente igual a los discos diferenciales, tienen una extensión .avhd.

Seguro que habéis deducido que esto de las instantáneas no es una maravilla, sobre todo si hacéis una y dejáis el sistema trabajando con ese disco diferencial de crecimiento dinámico.

Por tanto, toca decir que no se recomienda trabajar con snapshots/instantáneas en producción, peeero, me arriesgo a apuntar que si conocemos el funcionamiento interno de esta tecnología, podríamos aventurarnos a utilizarlas y aprovechar su potencial, siempre y cuando repito, conozcamos hasta el último detalle sus pros y sus contras (Alguien me va a matar por esto).

Con cada Snapshot o Instantánea creada en cada VM se crea un disco diferencial asociado a un padre que es un .vhd de la máquina virtual. Podemos ver en el archivo .xml de una máquina virtual, el nombre de cada archivo .avhd de cada disco de cada snapshot nuestra máquina virtual, por ejemplo:



Si borráis una instantánea, el archivo .avhd no se combina con el archivo .vhd padre hasta que no hacéis una apagado ordenado de la máquina virtual y esperáis a la posterior “combinación”, no vale con apagar el host habiendo configurado que cada máquina virtual se apague previamente al apagado del host, por que este no espera a que termine la combinación iniciada con el apagado de la VM.

Por si acaso hacéis o habéis hecho caso omiso de esta y otras advertencias similares y por aquello de la ley de Murphy, va y se os queda colgada una instantánea, podéis recuperar la información almacenada en esta, dentro de su .vhd .

Voy a poner un ejemplo:

Puede pasar que teniendo un disco de tamaño fijo que ocupe una gran parte de la partición física realicemos una instantánea, esta empiece a crecer como disco dinámico que es y se coma el espacio que dejasteis entre en disco .vhd de tamaño fijo y la totalidad de la partición física. Entonces es cuando llegáis al 100 del espacio ocupado, la VM no arranca y aparecen esos sudores fríos, ese pensamiento de por qué elegí esto de la informática, si tengo la misma responsabilidad que un médico y gano mil veces menos (este es otro tema del que hablaremos algún día), etc.

Si recuperáis un archivo .vhd de una copia de seguridad, os podéis encontrar que en él, se encuentren los datos de hasta el día en el que hicisteis una instantánea y que puede que haya pasado mucho tiempo...

Si os encontráis en estos u otros problemas similares, puede que lleguéis a la conclusión de que queréis fusionar una instantánea con un .vhd. Pues bien, paso a detallaros los pasos a seguir para realizar esta acción. Un apunte importante, lo voy a realizar partiendo que la copia la habéis recuperado en otro servidor host de virtualización (vendito portátil que soporta virtualización), en el caso que queráis saber como hacerlo en el mismo host, tendréis que leer un anexo que aparecerá pronto en este mismo blog.

1. Recuperar de la copia de seguridad, los archivos: .XML , .VHD y el .AVHD que indica el XML que está asociado el disco .VHD (mirar la captura de más arriba):

2. Cambiar la extensión del archivo .AVHD a .VHD.

3. En la consola de Hyper-v – – Editar disco y elegir el disco renombrado:

4. Como no encuentra el disco padre, os pedirá la ruta para “Volver a conectar” el disco al archivo .VHD (aquí es importante no estar en el mismo host, si no os modificará el disco que tenéis en producción y esto puede funcionar bien o no, pero mejor no tocar este disco de momento).

5. Volver a Editar el disco y esta vez elegir la opción Combinar:

6. Elegir el disco duro primario, ya que no es el que está en producción (repito):

7. Final feliz.

He visto cosas que me han sorprendido gratamente, como es el recuperar un archivo .avhd en un disco en producción el cual contiene una nueva instantánea y que el asistente: Editar disco – Combinar, me proponga insertar los datos del archivo .avhd antiguo en el nuevo, esto último me hace pensar que podríamos aventurarnos a recuperar una instantánea recuperada del backup en un disco en producción sin el menor riesgo aun teniendo este una nueva instantánea (ya seríais el colmo si habéis vuelto a dejar algo así colgado y funcionando), pero mejor hacerlo como os he dicho, por si acaso.

Fuente : http://undercpd.blogspot.com/2009/03/combinar-una-instantanea-con-su-archivo.html y me ha salvado mas de una vez , totalmente recomendado!!


Windows.Matar procesos por linea de comandos

Buenas tardes ,para matar el proceso de un servidor o cliente windows sin la necesidad de ingresar mediante rdp o si el mismo se quedo "colgado" (comun en software´s microsoft) , lo podemos realizar mediante la linea de comandos si y solo si somos administradores del equipo cliente (locales o domain admins) de la siguiente manera:
  • Ingresar a la linea de comandos de windows ,  tipeamos lo siguiente :
    • tasklist /s [nombreequipo] ---> Lista los procesos que estan corriendo en el equipo remoto , luego de ingresar este comando nos solicitara la contraseña del usuario administrador del equipo remoto .
  • En caso de que no contemos con el passwd del administrador local y si estamos dentro de un dominio podriamos ingresar con el usuario domain admin de esta forma :
    • tasklist /s [nombrequipo] /u [usuariodomainadmin] /p [passwd]
          Asi vemos listado los procesos del equipo remoto .


  • De la imagen anterior debemos fijarnos en el nombre de la aplicacion que queremos matar , luego cerrarla mediante su process Id (PID) :
    • taskkill /s [nombreequipo] /PID [nroproceso]
    • ej : Vamos a matar el proceso EXCEL.EXE (MsExcel) del equipo remoto al que me conecte , el cual cuenta con el PID 8084. 
    • taskkill /s equipito /PID 8084 , luego de introducir el password de administrador el proceso es cerrado.
e


Utiles.NMAP basico


Nmap básico
Nmap es el scanner de puertos por excelencia, y esta licenciado bajo la GPL.
A continuación dejo unos ejemplos basicos pero muy utiles de esta herramienta. Para profundizar en nmap visitar http://insecure.org/nmap/nmap_documentation.html
1) Descubrir direcciones IP activas en la red 192.168.50.0
# nmap -sP 192.168.50.0/24
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2007-03-06 14:09 CET
Host 192.168.50.0 seems to be a subnet broadcast address (returned 2 extra pings).
Host 192.168.1.100 appears to be up.
MAC Address: 00:0C:41:3A:73:1A (The Linksys Group)
Host 192.168.1.254 appears to be up.
Host 192.168.1.255 seems to be a subnet broadcast address (returned 3 extra pings).
Nmap finished: 256 IP addresses (2 hosts up) scanned in 18.312 seconds
2) Eplorar puertos TCP activos en el host 192.168.50.100 (un router Linksys)
# nmap -sT 192.168.50.100
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2007-03-06 14:12 CET
Interesting ports on 192.168.50.100:
(The 1660 ports scanned but not shown below are in state: closed)
PORT   STATE SERVICE
23/tcp open  telnet
53/tcp open  domain
80/tcp open  http
MAC Address: 00:0C:41:3A:73:1A (The Linksys Group)
Nmap finished: 1 IP address (1 host up) scanned in 1.397 seconds
y para UDP:
# nmap -sU 192.168.50.100
3) Detectar el SO utilizado por un host:
# nmap -O 192.168.50.100
Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2007-03-06 14:17 CET
Interesting ports on 192.168.50.100:
(The 1660 ports scanned but not shown below are in state: closed)
PORT   STATE SERVICE
23/tcp open  telnet
53/tcp open  domain
80/tcp open  http
MAC Address: 00:0C:41:3A:73:1A (The Linksys Group)
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux 2.4.0 - 2.5.20
Uptime 1.678 days (since Sun Mar  4 22:01:48 2007)
Nmap finished: 1 IP address (1 host up) scanned in 4.749 seconds

Linux.Unix.10 consejos básicos para supervisar la seguridad en Linux


10 consejos básicos para supervisar la seguridad en Linux
He hecho un pequeño guión con los puntos a tener en cuenta a la hora de mantener seguro un sistema Linux, que en mi caso es Debian. Espero que os pueda ser útil como referencia inicial.
  1. Suscribirse a las listas de correo de seguridad de Debian debian-security-announce. Otra opción sería visitar periódicamente la sección de seguridad en la web de Debian.
  2. Tampoco esta de mas acostumbrase a visitar sitios especializados en seguridad comowww.securityfocus.com o www.kriptopolis.es .
  3. Actualizar todo el software que tengamos instalado con los últimos parches de seguridad.
  4. En Debian bastaría con:
    # apt-get update
    # apt-get upgrade
    Sin olvidar todos aquellas aplicaciones que hallamos instalado nosotros por nuestra cuenta. Por ejemplo aplicaciones web como: drupal, joomla, etc.
  5. Revisar periódicamente los log del sistema.
  6. Realizar periódicamente copias de seguridad de todos los datos de interés en nuestro servidor.
  7. Los directorios de usuarios (/home), las web (/var/www), los archivos de configuración (/etc), las bases de datos, etc.
    Lo ideal es automatizar las copias y tenerlas programadas diariamente, semanalmente, etc. en función de la importancia de los datos y la frecuencia en la que estos se actualicen.
  8. Configurar adecuadamente el firewall ya sea con Iptables, shorewall. Con el target por defecto a DROP.
  9. Revisar periódicamente las cuentas de usuario y fortaleza de las contraseñas.
  10. Revisar los archivos o ejecutables con el bit SUID activo.
  11. Podemos localizarlos mediante la orden:
    # find / -type f -perm -04000
    También podemos automatizar la revisión de la integridad de estos u otros ficheros con herramientas como tripwire
  12. Asignar cuotas y recursos limitados a los usuarios.
  13. Deshabilitar todos aquellos servicios que no utilicemos.
  14. Instalar y utilizar un antivirus.
  15. De esta forma podemos detectar y eliminar los posibles virus en las carpetas compartidas mediante samba, o cuentas ftp de nuestro servidor. Ya que, aunque a linux no afectes los posibles virus, si es una buena medida para aumentar la seguridad de la red en general y evitar en parte la existencia de virus en los archivos que se compartan en una red windows. Una de las opciones que tenemos es instalar y utilizar avg.
A partir de aquí, otra de las cosas que podríamos hacer es probar la vulnerabilidad de nuestro sistema mediante nessus, o monitorizar todos los servicios con herramientas como nagios. Con este último, podríamos por ejemplo monitorizar cuando una maquina de nuestra red o incluso un servicio de una maquina cae. Y programar avisos automáticos por correo, etc.

Linux.Servidor FTPS con VSFTPD


Utilizando Debian y el servidor FTP vsftpd, voy a configurar un servidor FTPS (FTP/SSL). La idea es disponer de un servidor FTP donde las transferencias sean seguras.
Lo voy a configurar para no aceptar conexiones anonimas, y unicamente permita las conexiones de tipo FTPS.
1º) Instalación
# apt-get install vsftpd openssl
2º) Crear certificado
# cd /etc/ssl/certs
# openssl req -x509 -nodes -days 730 -newkey rsa:1024 -keyout vsftpd.pem -out vsftpd.pem
3º) Configurar VSFTPD
La configuración se centraliza toda en el fichero /etc/vsftpd.conf.
#
# Configuración General
#
listen=YES
# No se permite acceso anonimo
anonymous_enable=NO
local_enable=YES
local_umask=022
ftpd_banner=Bienvenido al Servidor FTPS
# Se enjaulan los usuarios en su home
chroot_local_user=YES
# Configuracion PASV
pasv_enable=YES
pasv_min_port=6000
pasv_max_port=6100
pasv_address=ip_publica_servidor
#
# Configuracion SSL
#
# Habilita el soporte de TLS/SSL
ssl_enable=YES
# Permite utilizar TLS/SSL a usuarios anónimos
allow_anon_ssl=YES
# Obliga a utilizar TLS/SSL para todas las operaciones
force_local_data_ssl=YES
force_local_logins_ssl=YES
# Se prefiere TLSv1 sobre SSLv2 y SSLv3
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
# Ruta del certificado
rsa_cert_file=/etc/ssl/certs/vsftpd.pem
4º) Alta Usuarios
Los usuarios utilizados por vsftp serán los del sistema. Si tenemos que dar de alta usuarios exclusivamente para el ftp, lo adecuado es darlos de alta sin shell de la siguiente forma:
# echo "/bin/false" >> /etc/shells
# adduser usuario --shell /bin/false
5º) Abriendo Puertos
No hay que pasar por alto que en nuestro firewall tenemos que abril los puertos 20 (ftp-data) y 21 (ftp). Además al tratarse de una configuración con soporte al modo pasivo tenemos que abrir un rango de puertos, por ejemplo del 6000 al 6100.
6º) Cliente
Para probar el funcionamiento necesitamos utilizar un cliente FTP que soporte: FTPES - FTP sobre TLS/SSL explícito.
Cuando estemos configurando el servidor, recomiendo el cliente de terminal ftp-ssl. Y ya como cliente en modo gráfico, recomiendo utilizar FileZilla, que además de ser software libre es multiplaforma.
Para Debian lo instalamos desde los repositorios de paquetes
# apt-get install filezilla

Linux.Configuracion e instalacion de servidor FTP con VSFTPD en Debian Lenny


VSFTPD: es el demonio que utilizaremos para FTP

Con SSL tanto en el cliente como en el servidor, sus comunicaciones en Internet serán transmitidas en formato codificado. De esta manera, puede confiar en que la información que envíe llegará de manera privada y no adulterada al servidor que usted especifique.

Lo primero es la instalacion de los paquetes a utilazar.

* Instalando el servicio de FTP

# apt-get install vsftpd

* Instalando SSL

# apt-get install openssl

Ahora configuramos el archivo de configuracion de nuestro servidor ftp :

*Configurando el vsftpd.conf

# nano /etc/vsftpd.conf
anonymous_enable=NO
local_enable=YES
write_enable=YES 
local_umask=022 
dirmessage_enable=YES
xferlog_enable=YES 
connect_from_port_20=YES 
xferlog_std_format=YES 
ftpd_banner=Welcome to blah FTP service. 
listen=YES pam_service_name=vsftpd
userlist_enable=YES tcp_wrappers=YES
pasv_enable=YES pasv_promiscuous=YES
pasv_min_port=6000
pasv_max_port=7000 
ya tengo configurado lo que el servidor FTP vamos a trabajar en lo que es el tema de la 
codificacion con ssl.
Bueno para empezar vamos a crear lo que es un certificado ssl.
# openssl req -x509 -nodes -days- 365 -newkey rsa:1024 -key /etc/ssl/certs/vsftpd.pem
-out /etc/ssl/certs/vsftpd.pem 
despues de esto nos hara una serie de preguntas a las cuales tenemos que esponder no son 
preguntas tecnicas, asi que cualquiera las puede responder.  ya solo nos resta las ultimas
configuraciones para el demonio de FTP para que surja efecto SSL
# nano /etc/vsftpd.conf
ssl_enable=YES
allow_anon_ssl=NO
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=YES
ssl_sslv3=YES
rsa_cert_file=/etc/ssl/certs/vsftpd.pem
rsa_private_key_file=/etc/ssl/certs/vsftpd.pem


ahora ya solo nos queda reiniciar el servicio y todo listo para disfrutar de un servidor FTP seguro.

# /etc/init.d/vsftdd restart

jueves, 23 de febrero de 2012

Cisco.Enable TCP keepalives


To enable TCP keepalives on the routers, use the following configuration commands:
Router1# config term
Router1(config)# service tcp-keepalives-in
Router1(config)# service tcp-keepalives-out
Router1(config)# end

Cisco.IP subnet Zero


What is IP Subnet Zero? – Cisco Articles & Tips
miércoles, 21 de julio de 2010
08:33 p.m.
I am sure you have used the Cisco IOS command show running-config before, and noticed a peculiar default command in the configuration. The command I am talking about is ip subnet-zero. Here is what I am talking about:
 But what is this command? Why is it there? Let’s find out.
What is a zero subnet in the first place?
Before we talk about the command, let’s ask ourselves, “In the first place, what is a zero subnet?” Under old IP subnetting rules, the all 0’s subnet was reserved for the network, and the all 1’s subnet was reserved for the broadcast. Over time, engineers found that the all 0’s subnet wasn’t really used and, if it could be handed out as a useable network, many IP addresses could be changed.
An example of an IP address that is using a zero subnet is 10.1.0.1 with a subnet mask of 255.255.255.0. This IP address may look pretty weird to you. Some people may even try to argue that it is an invalid IP address because there is a 0 in third octet. However, today, this IP address is perfectly legal when it comes to subnetting. Thus, if I had an IP address of 10.1.0.0 with a 255.255.0.0 subnet mask and wanted to subnet it, I could actually get 255 valid networks out of it by using the 0 subnet. In other words, I could have networks ranging from 10.1.{0-254}.X where the X represents hosts 1-254. This gives me room for networks 0-254, or 255 total networks, by using the 0 subnet.
Do I need to enable my router to recognize the zero subnet?
The quick answer to this question is NO. Your Cisco IOS router, by default, has the command ip subnet-zero enabled on the router. Because of this command, the zero subnet can already be recognized.
Do I really want to use the zero subnet?
Just because something is there, doesn’t mean you should use it. That is true in the case of the zero subnet. Because many people still believe that the zero subnet is not a legal subnet, I would avoid using it if possible. I would do this just to avoid confusion when it comes to network configuration. On the other hand, if you work for a large Internet Service Provider and are handing out blocks of IP addresses, I would definitely hand out the zero block to help conserve your IP address resources.
Summary
In this article, we learned the difference between the following 3 commands:
  • ip default-gateway
  • ip default-network
  • ip route 0.0.0.0 0.0.0.0 (configuring a default route)
The default-gateway command should only be used when a router is functioning as a bridge. The ip default-network and ip route 0.0.0.0 0.0.0.0 commands should be used to tell the router what route to select as the “gateway of last resort”.

Cisco.NAT


NAT puede funcionar de forma Estatico o Dinamico.

El NAT Estatico puede ser útil para host internos que deben ser accesibles desde internet como servidores DNS, servidores web o de correo electrónico.

Se configuran direcciones en una tabla de búsqueda y se asocian una por una de forma estática.
Configuración de NAT Estatico: ( donde 172.16.129.2 es ip privada y 200.42.1.11 es ip publica)
Router-Cisco#config t
Router-Cisco(config)# ip nat inside source static 172.16.129.2 200.42.1.11
Router-Cisco(config)# interface serial 0
Router-Cisco(config-if)# ip nat outside
Router-Cisco(config)# interface ethernet 0
Router-Cisco(config-if)# ip nat inside

El NAT dinamico está diseñado para mapear una dirección IP privada a una dirección pública de entre un pool de direcciones públicas ya establecido. Es decir, Cualquier dirección IP pública de este pool se asigna a un host de la red interna.
1) Primero definir un pool de direcciones (las direcciones públicas que nos asigne nuestro ISP)
Router-Cisco#configure treminal
Router-Cisco(config)# ip nat pool 1 200.42.1.1 200.42.1.10 netmask 255.255.255.0
2) Crear una lista de acceso estándard que permita las direcciones internas que se deben traducir.
Router-Cisco(config)# access-list 1 permit 172.16.129.0 0 0.0.0.255
3) Configurar la NAT dinamico basada en la dirección de origen especificando la lista de acceso definida en el paso anterior.
Router-Cisco(config)# ip nat inside source list 1 pool 1
4) Especificar la interfaz interna y marcarla como conectada al interior.
Router-Cisco(config)# interface etherne 0
Router-Cisco(config-if)# ip nat inside
Router-Cisco(config-if)# exit
5) Especificar la interfaz externa y marcarla como conectada al exterior.
Router-Cisco(config)# interface serial 0
Router-Cisco(config)# ip nat outside
Comandos para verificación de la tabla NAT
show ip nat translations
show ip nat statistics
debug ip nat

Cisco.Offset List


Offset-list
sábado, 07 de agosto de 2010
05:42 p.m.
offset-list

Command
Offset-List
Use
This command allows you to modify the metric of a route on the routing table.
Syntax
Router(config-router)#offset-list <list> <in or out> <offset> <interface>

Options

<list> - 0
All networks
<list> - 1-99,1300-1999
Standard access list
<list> - Name
Named access list
<in>
Affects inbound updates
<out>
Affects outbound updates
<offset> -1-16
Amount to modify metric
<interface>
Only affects updates comming through this interface
Example



In this example we will change the metric on the 1.0.0.0 routes to 200000. Currently the metric is 156160


R2(config-router)#do show ip route eigrp
1.0.0.0/32 is subnetted, 3 subnets
D 1.1.1.1 [90/156160] via 10.1.1.1, 00:00:07, FastEthernet0/0
D 1.3.3.3 [90/156160] via 10.1.1.1, 00:00:07, FastEthernet0/0
D 1.2.2.2 [90/156160] via 10.1.1.1, 00:00:07, FastEthernet0/0
192.168.13.0/30 is subnetted, 1 subnets
D 192.168.13.0 [90/2172416] via 10.1.1.1, 00:00:07, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
D 3.3.3.3 [90/156160] via 10.2.2.3, 00:00:04, FastEthernet1/0
111.0.0.0/32 is subnetted, 1 subnets
D 111.111.111.111 [90/156160] via 10.1.1.1, 00:00:07, FastEthernet0/0
10.0.0.0/24 is subnetted, 3 subnets
D 10.4.4.0 [90/2172416] via 10.2.2.3, 00:00:04, FastEthernet1/0
[90/2172416] via 10.1.1.1, 00:00:04, FastEthernet0/0
11.0.0.0/32 is subnetted, 1 subnets
D 11.11.11.11 [90/156160] via 10.1.1.1, 00:00:07, FastEthernet0/0
Now we will set the offset on R2


R2(config)#access-list 25 permit 1.0.0.0 0.255.255.255
R2(config)#router eigrp 100
R2(config-router)#offset-list 25 in 43840
Checking the routing table, we see the 1.0.0.0 network metric is 200000.


2(config-router)#do show ip route eigrp
1.0.0.0/32 is subnetted, 3 subnets
D 1.1.1.1 [90/200000] via 10.1.1.1, 00:00:01, FastEthernet0/0
D 1.3.3.3 [90/200000] via 10.1.1.1, 00:00:01, FastEthernet0/0
D 1.2.2.2 [90/200000] via 10.1.1.1, 00:00:01, FastEthernet0/0
192.168.13.0/30 is subnetted, 1 subnets
D 192.168.13.0 [90/2172416] via 10.1.1.1, 00:01:20, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
D 3.3.3.3 [90/156160] via 10.2.2.3, 00:01:17, FastEthernet1/0
111.0.0.0/32 is subnetted, 1 subnets
D 111.111.111.111 [90/156160] via 10.1.1.1, 00:01:20, FastEthernet0/0
10.0.0.0/24 is subnetted, 3 subnets
D 10.4.4.0 [90/2172416] via 10.2.2.3, 00:01:17, FastEthernet1/0
[90/2172416] via 10.1.1.1, 00:01:17, FastEthernet0/0
11.0.0.0/32 is subnetted, 1 subnets
D 11.11.11.11 [90/156160] via 10.1.1.1, 00:01:20, FastEthernet0/0

Cisco.Limitar ancho de banda en servicios que se encuentran detras del router


Esta configuración funciona con las versiones de IOS que soportan QoS. Con esto lo que se hará es limitar el ancho de banda de los servicios que están detrás del Router Cisco.

Para configurar el rate-limit necesitaremos también dos valores más que se recomienda calcular con la formula proporcionada por Cisco. Estos valores son el "normal burst" y el "extended burst".
Según Cisco estos valores se calcula por:
"normal burst" = rate * (1 byte)/(8 bits) * 1.5 seconds
"extended burst" = 2 * "normal burst"
Lo que haremos es limitar el ancho de banda a estos servicios. Lo primero que haremos es especificar cuanto ancho de banda quiero para cada servicio teniendo en cuenta los 1mbps/512kbps.

Para entrada de correo una limitación de 256kbps (respecto los 1mbps).
Para salida de correo una limitación de 128kbps (respecto los 512kbps).
Para salida de contenido Web una limitación de 256kbps (respecto los 512kbps).
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->
Para restringir el ancho de banda a los servicios se utilizara una ACL.
Configuración:
Router(config)# access-list 10 permit tcp any eq www any
(limitamos el trafico Web saliente)
Router(config)# access-list 11 permit tcp any any eq smtp
(limitamos el trafico smtp entrante)
Router(config)# access-list 12 permit tcp any eq smtp any
(limitamos el trafico smtp saliente)
Implementar el comando rate-limit en la interfaz que conecta a internet o cualquier otro Router:
Router(config)# interface GigabitEthernet0/0

Router(config-if)#
rate-limit output access-group 10 256000 48000 96000 conform-action transmit exceed-action drop
(liminado el ancho de banda del trafico Web saliente)

Router(config-if)#
rate-limit input access-group 11 256000 48000 96000 conform-action transmit exceed-action drop
(limitamos el ancho de banda del correo entrante)
Router(config-if)#
rate-limit output access-group 12 128000 24000 48000 conform-action transmit exceed-action drop
(limitamos el ancho de banda del correo saliente)
Comandos para verificación
show interfaces rate-limit
(Para Muestra información sobre un determinado rate-limit en la interfaz)


Cisco.Layer by Layer troubleshooting


Every network admin is going to have trouble with network links on a Cisco router, at one point or another. The best way to troubleshoot any networking issues is to use the OSI model and go layer by layer. In my article How to use the OSI Model to Troubleshoot Networks, we talked about the different troubleshooting approaches and how to use them to troubleshoot your network, in general. In this article, you will find out how to use the OSI model to troubleshoot, bottom up, using a Cisco router.

OSI Model - Bottom Up Troubleshooting
If you will recall, the OSI model starts with the physical layer (layer 1) and goes up to layer 7 (application). When troubleshooting with a Cisco router, much of your time will be spent working in layers 1-3. They are:
  • Layer 3 - Network
  • Layer 2 - Data Link
  • Layer 1 - Physical
Because these layers build on each other, Layer 1 is most critical, without layer 1, layer 2 will not function. Without layer 1 & 2, layer 3 will not function, and so on. For this reason, I start troubleshooting at layer 1, physical, and move on up from there.
Router Troubleshooting at OSI Layer 1 & 2 - Physical & Data link
Remember, if Layer 1 isn't up, nothing else will work so make sure you start here. Examples of layer 1 are your T1 circuit or your Ethernet cable - physical connectivity. I usually troubleshoot layer 1 and layer 2 in union because they are so closely paired. Examples of layer 2 - data link - are your line protocol (such as Ethernet, ATM, 802.11, PPP, frame-relay, HDLC, or PPP).
To troubleshoot at these layers, the first thing I would do on your router is a show interface. Here is an example of a LAN Gigabit Ethernet circuit:
Router# show interface
GigabitEthernet0/0 is up, line protocol is up
Hardware is BCM1125 Internal MAC, address is 0015.2b46.5000 (bia 0015.2b46.5000)
Description: LAN Connection to Data center
Internet address is 10.20.100.1/16
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, link type is autonegotiation, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/1000/64/0 (size/max total/threshold/drops)
Conversations 0/2/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 750000 kilobits/sec
5 minute input rate 3218000 bits/sec, 1715 packets/sec
5 minute output rate 1390000 bits/sec, 2129 packets/sec
1416888620 packets input, 15402720 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 1556005 multicast, 0 pause input
0 input packets with dribble condition detected
1666663097 packets output, 573841802 bytes, 0 underruns
19 output errors, 0 collisions, 3 interface resets
0 babbles, 0 late collision, 0 deferred
19 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
Here is what a WAN T1or T3 circuit might look like:
Routerl# show interface serial 3/0
Serial3/0 is up, line protocol is up
Hardware is DSXPNM Serial
Description: Sprint T3
Internet address is 10.2.100.2/30
MTU 4470 bytes, BW 9000 Kbit, DLY 200 usec,
reliability 255/255, txload 77/255, rxload 26/255
Encapsulation HDLC, crc 16, loopback not set
Keepalive set (10 sec)
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 18394
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 927000 bits/sec, 1914 packets/sec
5 minute output rate 2752000 bits/sec, 1504 packets/sec
1560997932 packets input, 3254680247 bytes, 0 no buffer
Received 255480 broadcasts, 1 runts, 1 giants, 0 throttles
1567 input errors, 1567 CRC, 976 frame, 496 overrun, 0 ignored, 908 abort
1303636803 packets output, 3737276508 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 output buffer failures, 0 output buffers swapped out
1 carrier transitions
DSU mode 1, bandwidth 9000, real bandwidth 9000, scramble 0
Here is the quick version:
Router# show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 10.20.100.1 YES NVRAM up up
Serial3/0 10.2.100.2 YES NVRAM up up
Here is what you look for:
  • Is the interface UP?
  • Is the line protocol UP?
  • If both the interface and line protocol are NOT up, your connection is never going to work.
  • To resolve a line down, I look at the cable or the keepalives
  • To resolve a line protocol down, check to make sure that the protocols match on each side of the connection(notice the "line protocol" on each of the interfaces above).
  • Are you taking input, CRC, framing, or other errors on the line (notice how the serial interface above does show errors)? If so, check your cable or contact your provider.
In general, verify that you have a good cable on each side, verify that line protocols match, and that clocking settings are correct.
If this is an Ethernet connection, is there a link light on the switch?
If this is a serial connection, do you have an external CSU/DSU? If it is an external CSU, check that the Carrier Detect (CD) light & data terminal ready (DTR) lights are on. If not, contact your provider. This also applies if you have an internal Cisco WIC CSU card. If that is the case, take a look at this Cisco link on understanding the lights on that card.
You can, of course, use the Cisco IOS test commands to test your network interfaces with internal staff and with your telecommunications providers.
Do not proceed to upper level layers until your Physical interface on the router shows as being UP and your line protocol is UP. Until then, don't worry about IP addressing, pinging, access-lists or anything like that.
Router Troubleshooting at OSI Layer 3 - Network
Once you have Layers 1 & 2 working (your show interface command shows the line is "UP & UP", it is time to move on to layer 3 - the OSI Network layer. The easiest thing to do here to see if layer 3 is working is to ping the remote side of the LAN or WAN link from this router. Make sure you ping as close as possible to the router you are trying to communication with - from one side across to the other side.
Here are examples of successful & failed pings:
Router# ping 10.2.100.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.100.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Router#
Router#
Router#
Router#
Router# ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Router#
The easiest way to check the status of Layer 3 - the network layer - is to do a show ip interface brief, as I did above. Here is an example:
Router# show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 10.20.100.1 YES NVRAM up up
Serial3/0 10.2.100.2 YES NVRAM up up
Notice the IP addressing on each of these interface. Also do a show running-config, like this (you can even specify an interface, like this):
Router# show running-config int serial3/0
Building configuration...
Current configuration : 225 bytes
!
interface Serial3/0
description Sprint T3
bandwidth 9000
ip address 10.2.100.2 255.255.255.252
no ip proxy-arp
no ip mroute-cache
dsu mode 1
dsu bandwidth 9000
no cdp enable
end
Router#
I would recommend taking this interface configuration and comparing it, side by side, with the remote WAN connection to ensure they are the same. Ask yourself questions like:
  • Are these interfaces on the same IP network?
  • Do these interfaces have the same subnet mask?
  • Are there any access-lists (ACL) that are blocking your traffic?
  • Can you remove all optional IP features to make sure that the basic configuration works before adding additional features that could be causing trouble?
Here is an example. Look at the two interfaces below. What is the real problem, causing these two to not communicate?
Router 1
interface Serial3/0 description Sprint T3 - TO ROUTER 2 bandwidth 9000 ip address 10.2.100.2 255.255.255.252
Router 2
interface Serial3/0 description Sprint T3 - TO ROUTER 1 bandwidth 1500 ip address 10.2.100.5 255.255.255.252
No, there is no problem with the bandwidth statement. Bandwidth statements are only used as comments and by routing protocols to select the best route. The real problem here is that the second router's serial interface is not on the same IP subnet as router #1. Even though they have the same subnet, the 10.2.100.5 IP address will never be able to communicate to the 10.2.100.2 IP address because they are on different networks but directly connected.
Let's say that you are now able to ping across the link, from one side to another. While that is a great sign, it doesn't always mean that everything is "fixed". You still may not be able to communicate from a client on the LAN of one router, to a client on the LAN of another router, due to things like improperly configured IP routing protocols.
For one LAN to communicate to another LAN, through routers (through a WAN, usually), you MUST have either static routes  or dynamic routes configured. To ensure you have a route configured for the network you are trying to reach, do:
Router# show ip routes
and look at
Router# show ip protocols
For troubleshooting layers 3, all the way up, look at the output of this command:
Router# show ip interfaces
GigabitEthernet0/0 is up, line protocol is up
Internet address is 10.20.100.1/16
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.10
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is disabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is disabled
IP Flow switching is enabled
IP CEF switching is enabled
IP CEF Flow Fast switching turbo vector
IP multicast fast switching is disabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast, Flow cache, CEF, Subint Flow
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Policy routing is disabled
Network address translation is enabled, interface in domain inside
WCCP Redirect outbound is disabled
WCCP Redirect inbound is disabled
WCCP Redirect exclude is disabled
BGP Policy Mapping is disabled
Router Troubleshooting at OSI Layers 4 - 7
Now, let's say that you have made it to the point where you can ping from LAN to LAN, through your WAN. Congratulations - that is a very good sign. If you are still having trouble, it must be in OSI Layers4-7. Here are those layers listed out and possible issues you might experience in each layer:
  • Layer 4 - Transport - in the transport layer are TCP and UDP - you could be have an ACL or QoS feature blocking or slowing this traffic. Your TCP traffic could also be fragmented to the point that it could not be reassembled. Another option is that you may not be receiving an ACK back from your traffic that was successfully sent.
  • Layer 5 - Session - in the session layer are protocols like SQL, NFS, SMB, or RPC - you could be taking errors on any one of these session protocols. I would recommend using a protocol analyzer like Wireshark to analyze your session data.
  • Layer 6 - Presentation - in the Presentation layer are data encryption, compression, and formatting - your VPN tunnel could be failing or perhaps you are sending one type of data (like a MPEG) and the receiver is trying to view it as a WMV file.
  • Layer 7 - Application - in the Application layer are, of course, your applications like FTP, HTTP, SCP, TFTP, TELNET, SSH, and more - you could be trying to connect to a telnet server with the SSH protocol, for example.
  • Layer 8 - End User - the standing joke is that "Layer 8" is the user - the user could be just mistyping their username or password or you, the network admin, could have been troubleshooting the wrong IP address all along.
Summary
In summary, using the OSI model to troubleshoot connectivity issues is the fastest and most efficient way to troubleshoot any network issue. Even if someone calls you to work on a Windows share problem, all of the same principles in this article apply to that troublesooting process. So remember, the next time you work on a network issue - remember the OSI model and how to use the bottom-up approach to troubleshooting! It could same you a while lot of time!