5 años desde que publiqué mi último post. Muchas cosas pueden cambiar en 5 años... ya no estoy soltero sino felizmente casado, ya no vivo en Venezuela sino en México, tengo un hermoso perro labrador que es como mi primer hijo... y ahora resulta que IS-IS, un protocolo de enrutamiento que supuestamente era de los dinosaurios, está de moda de nuevo.
Y es que no es que haya pasado de moda, siempre estuvo, es que cuando comienzas a salirte del mundo de redes empresariales y comienzas a meterte en el mundo de redes de ISP, te das cuenta que IS-IS es EL PROTOCOLO.... y pasas por 3 etapas:
1. Fuck this shit! nunca lo quise estudiar, que pereza... es el patito feo de CCNP.
2. Bueno vamos a ver de que se trata... vamos a estudiarlo.
3. NO ENTIENDO PORQUÉ EXISTEN OTROS IGPs!
Una vez que lo entiendes (cosa que no es taaaan complicado) te das cuenta de la versatilidad de este protocolo... te das cuenta que no tienes que estar haciendo marañas ni nada por el estilo para que funcione... te das cuenta que a pesar de que fue creado hace alrededor de 50 años desde sus inicios ya estaba completamente preparado para IPv6, para MPLS y un sin numero de tecnologías que actualmente son vigentes y que por ejemplo OSPF ha tenido que sacar nuevas versiones para poder estar a la par.
Se acuerdan de cuando iban a su videotienda favorita (tijeritas... o blockbuster para los de La Lago) y existían 2 formatos antes de los DVDs, estos eran BETA y VHS. No se si lo sabían pero BETA y VHS estaban disputándose quien sería el estándar de video, guerra la cual ganó VHS. Sin embargo BETA siempre fue superior. La calidad de BETA, el diseño más compacto y otros factores hacia BETA un estándar superior a VHS sin embargo por temas de mercadotecnia y convenios con distribuidoras el VHS se hizo mucho más popular.
Lo mismo sucedió con IS-IS y OSPF.
Recuerdan el modelo OSI?
Bueno realmente el modelo OSI era la arquitectura completa de todo el estándar OSI, en el cual adivinen cual era el protocolo de enrutamiento? IS-IS. Lo hermoso de este estándar es su versatilidad y escalabilidad, tanto que 50 años después aun sigue siendo vigente sin necesidad de actualizaciones. Lo que pasa es que esta versatilidad lo hacía ver muy complejo para la época. Tanto que parecía innecesaria tanta complejidad, y es por eso que quien ganó el estándar de la industria fue lo que todos conocemos como TCP/IP.
Miren.
Para mi la forma más fácil de entender IS-IS es como si, viendo el modelo OSI, fuera un protocolo que trabajara en una capa... digamos... 2.8. O sea trabaja a un nivel superior que MPLS por ejemplo, pero no requiere tanta configuración a nivel de capa 3 para funcionar, como lo necesita por ejemplo OSPF, EIGRP o RIP.
Hace unos días le pregunte a un amigo que trabaja en telefónica, ¿Qué protocolo de enrutamiento utiliza Telefónica?... y su respuesta fue BGP. Yo le digo, ok pero BGP se monta sobre un IGP (Interior Gateway Protocol), a menos que usen rutas estáticas que no creo.. y me contesta, chamo, solo usa BGP y MPLS.... no seguí la conversación pero me pareció muuuuy extraño, sin embargo un par de horas después me llama mi amigo y me dice "chamo ya averigüé, es que usa IS-IS pero esa verga es invisible! como nunca hay que configurar nada de IS-IS ni siquiera sabía que existía en la red". Eso da una idea de lo simple que hace el trabajo IS-IS. Tanto que ni cuenta te das de que está operando.
Bueno lo que quería lograr con este post es despertar un poco el interés en este protocolo que, según muchos vimos en clase era como aprender arameo, y ahora es como si el arameo fuera la lengua de moda.
Espero poder haberlos ayudado en algo y no dejen de revisar el siguiente post en el cual vamos un poco a la explicación de como funciona IS-IS y, por qué no? un pequeño laboratorio para que vean como trabaja.
Saludos!
Néstor
jueves, 23 de agosto de 2018
jueves, 27 de junio de 2013
OSPF. Qué son los LSA?
Para trabajar con un protocolo de enrutamiento, en especial con OSPF, es muy importante tener bien clara la teoría, así que me voy a tomar unos minutos para explicar que son los famosos LSA, para que sirven y por qué es tan importante conocerlos.
Los LSA (Link State Advertisements) son, como dicen sus siglas en inglés, actualizaciones del estado de los enlaces, es decir, son los paquetes que contienen toda la información referente a rutas, quien se conecta con quien, interfaces, costos, etc... Cada vez que una interfaz levanta o cae, son los LSA quienes llevan esta información a todos los routers. Obviamente juegan un papel FUNDAMENTAL en el funcionamiento del OSPF, es por ello que para un buen diseño y troubleshoot debemos conocerlos, entenderlos y quererlos.
Existen diferentes tipos de LSA, los cuales describo a continuación:
LSA Type 1 (Router LSA)
Un LSA tipo 1 es quien lleva la identificación de cada router (Router-id) dentro de un área y los enlaces que lo conectan. Cada router que hable OSPF crea un LSA tipo 1 para si mismo, y luego lo envia dentro del área al que pertenece. Este LSA es transmitido hacia cada neighbour y viceversa, hasta que todos tengan la misma copia de LSA. Si aún no se ha elegido ningún DR, muestra una lista de las interfaces con sus subredes, mascaras y costos. Si ya se eligió el DR entonces muestra la IP del DR
LSA Type 2 (Network LSA)
Los LSA tipo 2 son enviados dentro del área por el DR y contienen las redes que tiene conectadas y sus máscaras, ayudando así a moldear la topología de la red.
LSA Type 3 (Network summary)
Los LSA tipo 1 y 2 solo fluyen dentro de un área, o sea los ABR no los transmiten. Ellos generan LSA tipo 3 para cada subred en un área y luego las publica en las otras áreas, permitiendo que las mismas aprendan sobre ellas.
Hay que acotar que, aunque se llamen "Network summary" los LSA tipo 3 no son utilizados para hacer sumarización.
LSA Type 4 (ASBR Summary)
Son como los tipo 3, pero publica son las rutas necesarias para llegar a un ASBR.
LSA Type 5 (External LSA)
Los LSA Tipo 5 son creados por los ASBR y contienen las rutas que son redistribuidas por otro protocolo de enrutamiento o por rutas estáticas.
LSA Type 7 (NSSA External)
Los LSA tipo 7 solo existen en redes Cisco, porque son generados por ASBR dentro de un NSSA (Not-so-stubby Area). En un NSSA los LSA tipo 5 son filtrados, entonces si dentro de esa área existe un router que quiera redistribuir rutas estáticas u otro protocolo de enrutamiento, este debe transmitirlos a través de LSA tipo 7 para que el ABR no los filtre, sino que al recibirlo los convierte en LSA tipo 5 y los transmite al resto de las áreas.
Para comprender mejor el uso de los LSA, les recomiendo leer el post referente a las áreas OSPF.
Espero haber ayudado en algo, cualquier duda y/o comentario por favor comenten!
Néstor.
Etiquetas:
areas,
Cisco,
maracaibo,
networking,
no-summary,
not-so-stubby area,
nssa,
Ospf,
stub,
stubby,
summary,
totally stubby,
venezuela
OSPF. Areas y Sumarización
Nota: para comprender mejor este post recomiendo leer el post referente a los LSA de OSPF
Levantar OSPF, así como cualquier otro protocolo de enrutamiento parece ser una tarea superfacil. Basta con escribir Router OSPF X, declarar las interfaces que van a hablar OSPF y listo... Todo fino... o no?
...El detalle está en que el OSPF realmente sea más eficiente que el esquema de enrutamiento estático. Y es que una vez arriba el OSPF a lo hagas un show ip route o un show ip route ospf vas a ver la cantidad ENORME de rutas, muchas más que las que verías en un esquema de enrutamiento estático. Cómo arreglamos esto? es ahí donde entran las áreas en OSPF.
Imaginemos una topología como la siguiente:
En la tabla de enrutamiento de cada uno de los routers veremos absolutamente todas las rutas. Pero si nos fijamos bien, R1 sólo tiene una forma de llegar a los otros routers, que es a traves de R2. De igual manera pasa con R5, solo puede llegar al resto de la red a traves de R4. Si fuese enrutamiento estático utilizaríamos una ruta por default en R1 y R5... pero como estamos hablando de OSPF, entonces la solución es crear un area para R1 y otra para R5, de la siguiente manera:
Y aqui es cuando introducimos los siguientes tipos de area:
1. Stubby Area: filtra los paquetes LSA tipo 5 que contienen la información acerca de rutas externas al sistema autónomo, es decir, rutas estáticas redistribuidas o de otros protocolos de enrutamiento. Cuando los routers necesiten enrutar hacia redes que esten en otro sistema autónomo van a usar una ruta por defecto que se la envia el ABR (en nuestro caso R2) a los otros routers internos del área Stub (R1). Un area Stubby no puede tener un ASBR, es decir ni conexiones a otros protocolos de enrutamiento, ni redistribucion de rutas estaticas o redes conectadas.
Se configura de la siguiente manera:
R1:
router ospf 1
area 1 stub
R2:
router ospf 1
area 1 stub
2. Totally Stubby Area: Este es más depravao que Stubby porque filtra los LSA tipo 3, 4 y 5, en este caso R2 enviaría una ruta por defecto para todas las rutas externas y a diferencia de en el caso anterior SUMARIZADAS (esa es la mayor diferencia con Stub).
Tampoco puede tener ASBR ni nada de eso chevere...
Se configura de la siguiente manera:
R1:
router ospf 1
area 1 stub
R2:
router ospf 1
area 1 stub no-summary
3. Not-So-Stubby Area: Imagínense que R1 tiene unas rutas estáticas que quiere transmitir, pero está dentro de un Stubby Area. Como el router filtra los LSA tipo 3, 4 y 5, el NSSA transmite esta información como LSA tipo 7. Luego esta información llega a R2 y la convierte de nuevo en LSA 5. Es una hermosa maraña, y es la forma de tener ASBR en un area Stub. Este area es propietario de Cisco.
Se configura de la siguiente manera:
R1:
router ospf 1
area 1 nssa
R2:
router ospf 1
area 1 nssa
4. Totally Stuby Not-So-Stubby Area: Bingo! esta es la que más me gusta. Esta viene siendo como la Totally Stubby Area, pero, al igual que en la NSSA, transmite la información como LSA7 y luego el ABR lo convierte en LSA tipo 5. Este es el area que permite mayor sumarización, pero manteniendo la libertad de redistribuir una que otra ruta y/o protocolo. Por supuesto, tambien es propietaria de Cisco.
Se configura de la siguiente manera:
R1:
router ospf 1
area 1 nssa
R2:
router ospf 1
area 1 nssa no-summary
Siempre es bueno tener presente la teoría para poder comprender las los escenarios que se presentan en la vida real, sin embargo en una próxima entrada montaré un laboratorio en gns3 para ilustrar esta configuración.
Cualquier duda o comentario por favor comenten.
Néstor
Levantar OSPF, así como cualquier otro protocolo de enrutamiento parece ser una tarea superfacil. Basta con escribir Router OSPF X, declarar las interfaces que van a hablar OSPF y listo... Todo fino... o no?
...El detalle está en que el OSPF realmente sea más eficiente que el esquema de enrutamiento estático. Y es que una vez arriba el OSPF a lo hagas un show ip route o un show ip route ospf vas a ver la cantidad ENORME de rutas, muchas más que las que verías en un esquema de enrutamiento estático. Cómo arreglamos esto? es ahí donde entran las áreas en OSPF.
Imaginemos una topología como la siguiente:
En la tabla de enrutamiento de cada uno de los routers veremos absolutamente todas las rutas. Pero si nos fijamos bien, R1 sólo tiene una forma de llegar a los otros routers, que es a traves de R2. De igual manera pasa con R5, solo puede llegar al resto de la red a traves de R4. Si fuese enrutamiento estático utilizaríamos una ruta por default en R1 y R5... pero como estamos hablando de OSPF, entonces la solución es crear un area para R1 y otra para R5, de la siguiente manera:
Y aqui es cuando introducimos los siguientes tipos de area:
1. Stubby Area: filtra los paquetes LSA tipo 5 que contienen la información acerca de rutas externas al sistema autónomo, es decir, rutas estáticas redistribuidas o de otros protocolos de enrutamiento. Cuando los routers necesiten enrutar hacia redes que esten en otro sistema autónomo van a usar una ruta por defecto que se la envia el ABR (en nuestro caso R2) a los otros routers internos del área Stub (R1). Un area Stubby no puede tener un ASBR, es decir ni conexiones a otros protocolos de enrutamiento, ni redistribucion de rutas estaticas o redes conectadas.
Se configura de la siguiente manera:
R1:
router ospf 1
area 1 stub
R2:
router ospf 1
area 1 stub
2. Totally Stubby Area: Este es más depravao que Stubby porque filtra los LSA tipo 3, 4 y 5, en este caso R2 enviaría una ruta por defecto para todas las rutas externas y a diferencia de en el caso anterior SUMARIZADAS (esa es la mayor diferencia con Stub).
Tampoco puede tener ASBR ni nada de eso chevere...
Se configura de la siguiente manera:
R1:
router ospf 1
area 1 stub
R2:
router ospf 1
area 1 stub no-summary
3. Not-So-Stubby Area: Imagínense que R1 tiene unas rutas estáticas que quiere transmitir, pero está dentro de un Stubby Area. Como el router filtra los LSA tipo 3, 4 y 5, el NSSA transmite esta información como LSA tipo 7. Luego esta información llega a R2 y la convierte de nuevo en LSA 5. Es una hermosa maraña, y es la forma de tener ASBR en un area Stub. Este area es propietario de Cisco.
Se configura de la siguiente manera:
R1:
router ospf 1
area 1 nssa
R2:
router ospf 1
area 1 nssa
4. Totally Stuby Not-So-Stubby Area: Bingo! esta es la que más me gusta. Esta viene siendo como la Totally Stubby Area, pero, al igual que en la NSSA, transmite la información como LSA7 y luego el ABR lo convierte en LSA tipo 5. Este es el area que permite mayor sumarización, pero manteniendo la libertad de redistribuir una que otra ruta y/o protocolo. Por supuesto, tambien es propietaria de Cisco.
Se configura de la siguiente manera:
R1:
router ospf 1
area 1 nssa
R2:
router ospf 1
area 1 nssa no-summary
Siempre es bueno tener presente la teoría para poder comprender las los escenarios que se presentan en la vida real, sin embargo en una próxima entrada montaré un laboratorio en gns3 para ilustrar esta configuración.
Cualquier duda o comentario por favor comenten.
Néstor
Etiquetas:
areas,
Cisco,
networking,
no-summary,
not-so-stubby area,
nssa,
Ospf,
stub,
stubby,
summary,
totally stubby
Areas OSPF. Laboratorio
Este es un laboratorio para complementar el post sobre las Areas OSPF y la sumarización. Veamos el siguiente ejemplo:
En el router R1 está creada la loopback 10.1.1.1/32 declarada en ospf, en r2 tengo la loopback 200.44.32.12/24 recreando una salida a internet, y tengo rutas estáticas de la red 200.59.x.x redistribuidas en el proceso OSPF; en R4 tengo la loopback 10.4.4.1/24 y una ruta estatica de la red 69.25.x.x redistribuida en OSPF.
Veamos la tabla de enrutamiento de R1:
Podemos ver las direcciones IP 200.59.x.x como E2 que son las rutas estáticas creadas en R2 hacia internet, las 10.x.x.x que son las interfaces de los routers presentes en otras áreas que no sean el área 1; la ruta 0.0.0.0 también como E2 que dice que el default Gateway lo tiene R2. Ahora veamos lo que sucede si convertimos el área 1 en un stubby área. Configuremos lo siguiente:
R1:
Router ospf 1
Área 1 stub
R2:
Router ospf 1
Área 1 stub
Al ingresar estos comandos estamos diciendo que el área 1 es un área stub. El ospf caerá y levantará de nuevo. Y qué debería suceder? Pues recordemos que en un área stub el ABR (en nuestro caso R2) filtrará todos los LSA 5, es decir, las rutas externas a nuestro proceso OSPF. Veamos cómo queda la tabla de enrutamiento de R1:
Efectivamente podemos ver que todas las rutas que aparecían como E2 desaparecieron de la tabla de enrutamiento. R1 sabe ahora que cualquier cosa que no conozca debe buscarla por R2, lo que podemos ver en la última ruta.
Ahora convirtamos el área 1 en un área Totally Stub. De esta forma filtraremos los LSA tipo 3, 4 y 5. Simplemente debemos agregar el comando no-summary en el ABR (R2):
R2:
Router ospf 1
Área 1 stub no-summary
Veamos cómo queda la tabla de enrutamiento:
Como podemos ver la tabla de enrutamiento se redujo drásticamente. Ahora sólo aparecen las interfaces directamente conectadas, y como el área 1 solo tiene 1 salida hacia las otras áreas que es a través de R2, simplemente utiliza una ruta por default para acceder al resto de las áreas. Si comparamos esta tabla de enrutamiento con la tabla original es evidente el procesamiento que estaremos ahorrándole a R1.
Ahora veamos la tabla de enrutamiento de R4:
R4:
En el caso de R4 no podemos convertirla en un Totally Stuby Area porque tenemos unas rutas estáticas, las cuales se transmiten a las otras áreas por medio de LSA tipo 5. La solución para este caso es configurarla como un Totally Stuby Not-so-stubby Área. De esta forma el ABR (R3) va a filtrar los LSA de igual manera que lo hace R2, sólo que al ser un NSSA las rutas estáticas de R4 no se van a transmitir por LSA 5 sino por LSA7; entonces R3 no las va a filtrar pero va convertir los LSA7 en LSA 5 para poder transmitirlos hacia las otras áreas. Suena complicado pero veamoslo en acción. Configuremos:
R1:
Router ospf 1
Área 1 nssa
R2:
Router ospf 1
Área 1 nssa no-summary
La tabla de enrutamiento de R4 queda de la siguiente manera:
Igual que en R1, todas las rutas aprendidas por OSPF fueron sumarizadas en una única ruta 0.0.0.0 hacia R3, y la ruta estática 69.25.160.15 se mantiene, ya que es una ruta creada en el mismo router. Veamos la tabla de R3:
Como podemos ver en R3 aparece la ruta hacia la 69.25.160.15 como N2 que se refiere a un NSSA y se le hace ping a todo.
Con este laboratorio pudimos ilustrar los distintos comportamientos de las áreas en OSPF y cómo sumarizar con ellas, así como entender para que sirve cada tipo de LSA y por qúe es tan importate conocerlos. Espero que este post haya sido de ayuda, cualquier duda por favor comenten.
Saludos,
Néstor
Etiquetas:
areas,
Cisco,
networking,
no-summary,
not-so-stubby area,
nssa,
Ospf,
stub,
stubby,
summary,
totally stubby
viernes, 21 de junio de 2013
Plantilla de configuración de QoS like a boss...
Esta es una plantilla para configurar calidad de voz en los routers cisco. Lo unico que hay que hacer es configurarle el comando bandwith a la interfaz donde se va a aplicar, para que el router pueda calcular el porcentaje de ancho de banda correctamente. También se pueden cambiar los porcentajes de BW si se desea.
1. Crear los class-map para taguear los DSCP.
class-map match-any VOZ-SIGNALING
match dscp cs3
match dscp af31
exit
class-map match-any VOZ-RTP
match dscp ef
exit
2. Crear la politica en donde se le asocia un porcentaje del ancho de banda a cada class-map creado.
policy-map qos
class VOZ-RTP
priority percent 10
class VOZ-SIGNALING
bandwidth percent 8
class class-default
fair-queue
random-detect
3. Aplicar la política a la interfaz.
interface FastEthernet 4
service-policy output qos
C'est tout!
Néstor.
1. Crear los class-map para taguear los DSCP.
class-map match-any VOZ-SIGNALING
match dscp cs3
match dscp af31
exit
class-map match-any VOZ-RTP
match dscp ef
exit
2. Crear la politica en donde se le asocia un porcentaje del ancho de banda a cada class-map creado.
policy-map qos
class VOZ-RTP
priority percent 10
class VOZ-SIGNALING
bandwidth percent 8
class class-default
fair-queue
random-detect
3. Aplicar la política a la interfaz.
interface FastEthernet 4
service-policy output qos
C'est tout!
Néstor.
Etiquetas:
calidad de servicio,
Cisco,
class-map,
dscp,
maracaibo,
networking,
policy-map,
qos,
quality,
service-policy,
venezuela,
voice,
voz
lunes, 27 de mayo de 2013
Curiosidades sobre el VTP
Se me presentó este caso:
En otras palabras, los switches de "transito" tienen que tener en su base de datos de vlanes las vlanes que quieres transmitir, osea que la información se transmitiera tuvimos que crear en los switches del edificio las vlanes que queriamos pasar.
Ok lo se, es un hueco de seguridad ENORME, no es lo ideal... lo se.... pero tampoco lo se todo asi que mientras tanto lo deje asi. Cuando tenga una solución de niño grande actualizaré este post.
Saludos y feliz dia.
Donde SW2 y SW3 están en un edificio conectados por fibra con los puertos trunk. Los switches pertenecen al edificio y no hay ninguna otra forma de pasar otro cable desde la azotea (sw2) hasta la oficina (sw3).
Por otro lado tengo una oficina principal a 2 cuadras (sw3) y quiero comunicar las vlans de la misma con la sucursal que se encuentra en el edificio (sw4). Se entiende? Si no, comenten... =)
Resolución:
Se me ocurrió que la configuración de VTP de los switches del edificio deberían estar en modo transparente y que mis switches debían estar en la principal como vtp mode server y en el edificio vtp mode client. Por supuesto los switches del edificio tienen su dominio vtp diferente al mío.
No se transmitieron las VLANs. Resulta que al parecer hay un bug en los ios de los catalyst 3550 y 3560, que con vtp versión 2 no se permite la comunicación entre 2 dominios vtp diferentes. Cisco dice que si, los libros también, pero en la realidad no camina. Al hacer un debug muestra el siguiente mensaje:
Bueno, esto no es la solución pero cómo nosotros administramos los switches del edificio cambiamos el dominio de los switches SW2 y SW3 al mismo dominio de nosotros. Chévere. Se pasaron las vlans, todo cool... Excepto que... No le hacemos ping a las ips que estan en las VLANs que se pasaron....
Que rayos sucede? Cual es el problema? Será un problema de capa 3?
Respuesta:
Resulta que el problema era de capa 8... Es decir... De nosotros; y es que la respuesta nos la dio un chamo que apenas esta estudiando CCNA. El problema está en la definición de los diferentes modos VTP, los cuales describiré a continuación:
Transparent switches are a perfect solution when placing a managed Cisco switch in the transit path of two VTP enabled switches, this way The VTP Server and VTP client(s) can still communicate through the transparent switch and operate correctly
The downfall to transparent switches is that they must have the same VLAN’s IF they are a transit switch in a VTP domain.
En otras palabras, los switches de "transito" tienen que tener en su base de datos de vlanes las vlanes que quieres transmitir, osea que la información se transmitiera tuvimos que crear en los switches del edificio las vlanes que queriamos pasar.
Ok lo se, es un hueco de seguridad ENORME, no es lo ideal... lo se.... pero tampoco lo se todo asi que mientras tanto lo deje asi. Cuando tenga una solución de niño grande actualizaré este post.
Saludos y feliz dia.
domingo, 19 de mayo de 2013
Username para lineas vty y consola
La seguridad es uno de los aspectos que nunca pueden ser pasados por alto en el mundo del networking. En CCNA Cisco nos enseña a configurar un password de enable y un password para las lineas VTY de la siguiente manera:
De esta manera al ingresar al router por cualquier vía, el mismo pedirá un username y un password. Peeeeero aún tenemos otra falla de seguridad, y es que los passwords de los usuarios no están encriptados, y al hacer login con mi usuario puedo ver las contraseñas de los demás. Es por esto que la sintaxis correcta es la siguiente:
Config t
Enable password cisco
! Donde cisco es el password del router
Enable secret class
! Haciendo que el verdadero password "class" sea el que permita el acceso y que el mismo este encriptado
Line vty 0 4
Password ciscovty
Exit
Line console 0
Password ciscoconsole
De esa forma el router tendrá un password para telnet (ciscovty), uno para consola (ciscoconsole) y uno para el modo privilegiado (class). Pero que tal si un grupo de personas administran un mismo router y cada quien quiere memorizar una única contraseña y que tengan diferentes privilegios? Pues aquí es donde entran los nombres de usuarios y contraseña. Cisco dice que los usuarios se configuran de la siguiente manera:
Config t
Username nestor privilegie 15 password 123
! Donde el nombre de usuario es nestor, tiene todos los privilegios y el password es 123
Line vty 0 4
Login local
Line console 0
Login local
De esta manera al ingresar al router por cualquier vía, el mismo pedirá un username y un password. Peeeeero aún tenemos otra falla de seguridad, y es que los passwords de los usuarios no están encriptados, y al hacer login con mi usuario puedo ver las contraseñas de los demás. Es por esto que la sintaxis correcta es la siguiente:
Conf t
Username nestor privilegie 15 secret 123
Al utilizar "secret" el password se encriptará en el show run con md5, un algoritmo que actualmente aún es inviolable.
Espero haber podido ayudarlos. Cualquier duda por favor comenten.
Saludos,
Néstor.
Suscribirse a:
Entradas (Atom)



