Resumen de rutas o Summarization (o Supernetting ) es imprescindible para reducir la cantidad de rutas que un Router debe notificar a su Router vecino.
Recordemos que por cada Router que notifiquemos, crece el tamaño del Update de rutas. Cuenta la leyenda que si no existiera Resumen de rutas Internet hubiera colapsado para 1997 por el tamaño del paquete de Update de rutas
Los Updates de rutas, efectuados con un protocolo link-state o por vector de distancia, crece con cada ruta que agregamos y notificamos. Basicamente, si un Router debe notificar 10 rutas, su tamaño de paquete de Update es grande, si aumentan las rutas, aumenta el tamaño de paquete update que debe notificar, si crece el tamaño del paquete, queda menos ancho de banda para la información en si. Pero con Resumen de rutas podemos notificar varias lineas de rutas en una sola, como veremos en el ejemplo de mas abajo.
Ademas, cuando un nuevo flujo de datos ingresa al router, este debe buscar en su tabla de ruteo hacia quien (que interfase) se dirige el trafico. Cuanto mas larga la tabla de rutas, mas ciclos de CPU usa, por lo tanto con Resumen de rutas ademas de ancho de banda util, ahorramos ciclos de CPU
Sencillisimo ejemplo de Summarization o Resumen de rutas
En el ejemplo, Router A debe notificar de sus 4 rutas a Router B.
Los rangos Ip son /24, por lo que buscamos los patrones de bits iguales en todas las rutas en los primeros 24 bits, para eso pasamos las direcciones IP a binario
Notamos que los primeros 22 bits de las 4 redes son comunes a todas. Por lo tanto podemos resumir las rutas con UNA MASCARA DE SUBRED QUE REFLEJE QUE ESTOS PRIMEROS 22 BITS SON COMUNES A TODAS LAS REDES INTERNAS. Esto es una mascara /22 , o 255.255.252.0.
Entonces solo nos queda UNA RUTA RESUMIDA DE 172.16.64.0/22
Esto le dice al Router B, (una vez que la linea de rutas es otificada al Router B) “Si te llega algun paquete direccionado con los primeros 22 bits en la forma 10101100.00010000.010000xx.xxxxxxxx, entonces mandamelos a mi, Router A”
Requisitos para usar Resumen de rutas o Summarization o Supernetting :
1-Los routers deben usar CLASLESS routing protocol (O SEA, LOS QUE LLEVAN MASCARA DE SUBRED JUNTO CON LA IP) como ser RIP v2, OSPF, EIGRP,
IS-IS, and BGP.
2-Las direcciones deben ser en formato jerarquico, como vimos arriba (no sirve 172.16.64.0 / 172.16.71.0 /172.16.76.0, se entiende? Sino como aplicamos los bits comunes a todos?)
RIP (Routing information protocol, protocolo de información de encaminamiento)¨:
RIP es un protocolo de encaminamiento interno, es decir para la parte interna de la red, la que no está conectada al backbone de Internet.
Entonces RIP es un protocolo usado por distintos routers para intercambiar información y así conocer por donde deberían enrutar un paquete para hacer que éste llegue a su destino.
Segun Wikipedia:
Funcionamiento RIP
RIP utiliza UDP para enviar sus mensajes y el puerto 520.
RIP calcula el camino más corto hacia la red de destino usando el algoritmo del vector de distancias. La distancia o métrica está determinada por el número de saltos de router hasta alcanzar la red de destino.
RIP tiene una distancia administrativa de 120 (la distancia administrativa indica el grado de confiabilidad de un protocolo de enrutamiento, por ejemplo EIGRP tiene una distancia administrativa de 90, lo cual indica que a menor valor mejor es el protocolo utilizado)
RIP no es capaz de detectar rutas circulares, por lo que necesita limitar el tamaño de la red a 15 saltos. Cuando la métrica de un destino alcanza el valor de 16, se considera como infinito y el destino es eliminado de la tabla (inalcanzable).
La métrica de un destino se calcula como la métrica comunicada por un vecino más la distancia en alcanzar a ese vecino. Teniendo en cuenta el límite de 15 saltos mencionado anteriormente. Las métricas se actualizan sólo en el caso de que la métrica anunciada más el coste en alcanzar sea estrictamente menor a la almacenada. Sólo se actualizará a una métrica mayor si proviene del enrutador que anunció esa ruta.
Las rutas tienen un tiempo de vida de 180 segundos. Si pasado este tiempo, no se han recibido mensajes que confirmen que esa ruta está activa, se borra. Estos 180 segundos, corresponden a 6 intercambios de información.
OSPF (Open shortest path first, El camino más corto primero)
OSPF se usa, como RIP, en la parte interna de las redes, su forma de funcionar es bastante sencilla. Cada router conoce los routers cercanos y las direcciones que posee cada router de los cercanos. Además de esto cada router sabe a que distancia (medida en hops) está cada router. Así cuando tiene que enviar un paquete lo envía por la ruta por la que tenga que dar menos saltos.
La O de OSPF viene de abierto, en este caso significa que los algoritmos que usa son de disposición pública.
OSPF, ha sido pensado para el entorno de Internet y su pila de protocolos TCP/IP, como un protocolo de routing interno, es decir, que distribuye información entre routers que pertenecen al mismo Sistema Autónomo
Se incluye un doc que explica MUY BIEN y claro OSPF
BGP (Border gateway protocol, protocolo de la pasarela externa)
Protocolo de encaminamiento externo.
Es la base del encaminamiento en Internet entre sistemas autónomos.
Un sistema autónomo (AS) es una colección de redes (prefijos) gestionadas por una misma
organización. Tienen números únicos.
Es muy vulnerable a errores de configuración (involuntarios) y a ataques (intencionados).
Las medidas de seguridad deben evitar que los errores repercutan en todo Internet.
BGP es un protocolo muy complejo que se usa en la interconexión de redes conectadas por un backbone de internet. Este protocolo usa parámetros como ancho de banda, precio de la conexión, saturación de la red, denegación de paso de paquetes, etc. para enviar un paquete por una ruta o por otra. Un router BGP da a conocer sus direcciones IP a los routers BGP y esta información se difunde por los routers BGP cercanos y no tan cercanos. BGP tiene su propios mensajes entre routers, no utiliza RIP.
Se adjunta un link MUY interesante
http://ws.edu.isoc.org/workshops/2004/CEDIA2/material/bgp.pdf
Como el autor del blog autoriza reproducir el material , me parecio conveniente privilegiar este humilde blog con tan completo material
Es muy interesante para tenerlo en cuenta
“Cada vez que debemos configurar un dispositivo que se incorpora a la red, gran parte de la configuración depende tanto del dispositivo como del diseño de la red en la que ese dispositivo va a incorporarse. Sin embargo, hay también un conjunto de features que siempre podemos o debemos tener en cuenta, independientemente del dispositivo y la red.
Dependiendo de las implementaciones y del mismo Administrador, siempre hay una lista de cosas que “siempre hay que hacer”: claves, nombres de dispositivos… etc. Esta es una lista posible de “10 cosas que siempre hay que configurar” en los dispositivos de una red:
• Configurar cuentas de acceso a los dispositivos.
• Configurar un hostname que lo identifique.
• Configurar una clave de acceso al modo privilegiado.
• Encriptar las claves.
• Deshabilitar el acceso vía http.
• Configurar un servicio de traducción de nombres.
• Configurar commandos alias.
• Configurar el reloj de los dispositivos.
• Evitar que los mensajes logging molesten durante las tareas de configuración.
• Configurar el servicio de logs.
Algunas de estas tareas ya las consideré en otros artículos, a los que procuraré referir en cada cado. Si tenés tu propia lista de “cosas que siempre hay que hacer” o algún elemento más para agregar, por favor, incorporalo como comentario a esta nota.
Configuración de cuentas de acceso a los dispositivos
Es altamente recomendable que los accesos a los dispositivos estén asegurados requiriendo la identificación de usuario y clave. No estamos hablando de una simple clave de acceso a modo usuario para la conexión a través de telnet o consola. La sugerencia es que ese acceso requiera del ingreso de usuario y clave.
Adicionalmente, Cisco IOS nos brinda la posibilidad de que esa clave se encripte utilizando MD5, como un forma adicional de segurizar nuestros dispositivos. El comando de configuración para realizar esta tarea es:
Router(config)#username [usuario] secret [clave]
Luego de configurado usuario y clave, es necesario aplicarlo a cada una de las líneas de acceso:
Router(config)#line con 0
Router(config-line)#login local
Router(config)#line aux 0
Router(config-line)#login local
Router(config)# line vty 0 4
Router(config-line)# login local
Obsérvese, para los que están acostumbrados a configurar una clave de acceso a modo usuario, que este procedimiento reemplaza aquel.
Configurar un hostname
Todos los dispositivos Cisco tienen un nombre configurado por defecto: Router ó Switch, según corresponda. La configuración de un nombre que identifique claramente al dispositivo es de gran utilidad para el desarrollo de tareas de administración y monitoreo de los dispositivos y en términos generales debe responder a una acción planificada y parametrizada por el Administrador de la red.
La modificación de este nombre por defecto es extremadamente sencilla:
Router(config)#hostname [nombre]
Adicionalmente, Cisco IOS permite configurar un nombre de dominio de modo que el dispositivo “conozca” en qué dominio DNS se encuentra:
Router(config)#ip domain name [dominio]
Configurar una clave de acceso al modo privilegiado
Un elemento de seguridad muy importante es bloquear el acceso al modo privilegiado de los dispositivos (desde el que se accede al modo configuración) utilizando una clave de acceso. Adicionalmente Cisco IOS brinda la posibilidad de que la clave configurada sea encriptada utilizando MD5.
Esta es una tarea extremadamente sencilla:
Router(config)#enable secret [clave]
Encriptar todas las claves no encriptadas
No todas las claves configuradas en dispositivos Cisco IOS están encriptadas por defecto. Esto se puede solucionar fácilmente activando el servicio de encipción de claves que ofrece IOS:
Router(config)#service password-encryption
Deshabilitar el acceso vía http
Acceder a interfaces de administración a través de un web browser es una facilidad buscada por muchos Administradores. Todos sabemos que la configuración por CLI es más tediosa; pero también es más precisa y flexible… y más segura. De aquí que se recomiende fuertemente que, por seguridad, se desactive el acceso vía http (o web broser) a los dispositivos.
Los dispositivos Cisco permiten por defecto el acceso utilizando navegadores web. Si este acceso no va a ser utilizado, es más seguro desactivarlo. Es otra tarea simple:
Router(config)#no ip http server
Configurar un servicio de traducción de nombres
Cuando se ingresa una cadena de caracteres en la CLI de Cisco IOS, por defecto, IOS la interpreta como si se tratara de un comando. Si no puede asociar un comando a esa cadena de caracteres, entonces interpreta que el operador está requiriendo hacer telnet a un dispositivo al que identifica con un nombre, y por lo tanto procura traducir ese nombre a una dirección IP.
Esto suele provocar inconvenientes durante el proceso de configuración ya que, ante un error de tipeo al ingresar un comando el dispositivo comienza inmediatamente a intentar una traducción de nombres hasta que falla (dns lookup en inglés).
Esto tiene 2 soluciones posibles. La primera solución es desactivar el servicio de traducción de nombres que Cisco IOS tiene activado por defecto:
Router(config)#no ip domain-lookup
La otra opción, es configurar un servidor DNS real para que el dispositivo pueda hacer las búsquedas que sean necesarias:
Router(config)#ip name-server [IP]
Configurar comandos alias
El comando alias es un recurso interesante que permite a los Administradores generar su propio conjunto de comandos abreviados para realizar aquellas tareas más repetitivas.
Un ejemplo de las posibilidades que brinda:
Router(config)#alias [modo] [abreviado] [comando]
Router(config)#alias exec s show running-config
De este modo, ingresando una sola letra se ejecuta un comando más complejo.
Configurar el reloj de los dispositivos
La mayoría de los dispositivos Cisco están dotados de un reloj interno que requieren de configuración. Esta tarea es de suma importancia al momento de revisar archivos logs, ya que es la base de información para estampar fecha y hora en los registros del log.
En principio este requisito se puede cubrir configurando, además de fecha y hora en el reloj, el uso horario:
En el caso de países o regiones que modifican el uso horario de acuerdo a la estación:
Router(config)#clock summer-time [huso] recurring
Ahora bien, en redes con numerosos dispositivos, es conveniente configurar el acceso a un servidor NTP a fin de asegurarnos que el reloj de todos los dispositivos se encuentre debidamente sincronizado, de modo que se facilite la tarea de diagnóstico y monitoreo. De este modo el dispositivo siempre buscará la información en el servidor al momento de inicializarse:
Router(config)#ntp server [IP]
Evitar que los mensajes logging molesten
Cuando se está configurando o revisando el resultado de un comando show resulta muy molesta la interrupción que provocan los mensajes de logging de algunos sucesos estándar (p.e. el estado de las interfaces) o de un debug.
Esto es fácilmente solucionable, con una mínima previsión al momento de realizar la configuración. Un modo, no aconsejable, es eliminar sencillamente estos mensajes:
Router(config)#no logging console
El que quizás es el mejor modo (porque nos permite seguir recibiendo estos mensajes de estado, que son de gran importancia), es sincronizar estoa mensajes con el ingreso de comandos en el prompt del sistema operativo:
Router(config)#line con 0
Router(config-line)#logging synchronous
Router(config)#line aux 0
Router(config-line)#logging synchronous
Router(config)#line vty 0 4
Router(config-line)#logging synchronous
Configurar el servicio de log
Los mensajes de estado por defecto son enviados a la consola y no se almacenan. Sin embargo, es muy probable que los eventos que nos preocupan (fallos, actualizaciones de rutas, etc.) ocurran mientras no hay un operador conectado al puerto consola que pueda evaluarlos.
Es por esto de gran utilida indicarle al dispositivo que se desea enviar esta información a un servidor de syslog, o al menos, almacenarlos en un buffer de memoria en el mismo dispositivo:
Router(config)# logging buffered [tamaño]”
Vuelvo a citar la fuente
http://librosnetworking.blogspot.com/2006/11/ndice-de-artculos-sobre-tecnologas.html
Hasta aca el aporte del blog citado arriba, no es necesario agregar nada ya que esta perfecto
En caso de tener un dispositivo en la red y no se que es, puedo intentar un telnet o SSH , si el mismo es accesible, me mostrara un banner como se muestra abajo
networking# telnet direccion IP
Trying direccion IP…
Connected to direccion IP
Escape character is ‘^]’.
User Access Verification
Password:
NOTA:
La linea “User Access Verification” es marca registrada de Cisco para el banner de telnet , por lo tanto aca le “pegue” a un router, a menos que el admin haya cambiado el banner con propositos de engañar al posible “atacante”
A continuacion explico como resetear las pass de un router o switch Cisco
NOTA: el metodo es general, recordar que varia ligeramente segun modelo, esta descripcion puede ser encontrada en la pagina oficial de Cisco entre otras.
1-Apagar el equipo, ya sea de power button o sacando el cable de pòwer directamente.
2-Volver a conectar el equipo presionando ctrl+break
3-Se ingresara a modo rommon>
4-Tipee confreg
5-Decir NO a todas las opciones excepto
a enable “ignore system config info”? y/n [n]: y
6-Decir NO a todas las demas opciones
7-Una vez en rommon> tipee reset
8-El dispositivo se reiniciara
9-Al reiniciar decir que no a
Wouldyou like to enter the initial configuration dialog? [yes/no]: no
10-
Hacer un show version, mostrara que el config register es 0×2142.
11-Ahora podemos hacer dos cosas
a.
Pasar a enable y hacer show startup-config para ver cual es la clave enable password, o
b.
Si tenes un enable secret password seteado. reemplazarlo haciendo un copy start run, luego pasar a global configuration y crear un nuevo enable secret with enable secret mi_clave_aca, luego reescribirla con with copy run start
12-Ahora queremos volver atras el registro de configuracion, entonces en global configuration, tipeamos config-register 0×2102
13-Grabamos con wr o
copy run start 14-Reboot, el dispositivo tiene la configuracion original PERO con la nueva clave que elejimos anteriormente
Breve resumen:
Ire posteando casos que me sucedan o sucedieron en mi dia a dia como profesional de sistemas, en cuanto a Networking, VoIP, Seguridad Informatica, Microinformatica, Dispositivos Cisco y Redes en general.
Algunos casos son complicados e interesantes y otros "faciles" pero a veces los anoto para no olvidarmelos
Hay referencias a links de paginas oficiales como a otros blogs cuyo contenido es de interes
Networking / VLAN144
IMPORTANTE. Los contenidos y/o comentarios vertidos en este servicio son exclusiva responsabilidad de sus autores así como las consecuencias legales derivadas de su publicación. Los mismos no reflejan las opiniones y/o línea editorial de Blogs de la Gente, quien eliminará los contenidos y/o comentarios que violen sus Términos y condiciones. Denunciar contenido.
