Recursos para estudiar.

Este sólo es un comentario al aire, muchos utilizan GNS3 para practicar, y se pueden utilizar muchos tipos de dispositivos, algunos son gratuitos, otros son restringidos, pero entre los gratuitos está un router Cisco 1000v, y que pueden utilizar para algunas pruebas.

Además hay otras opciones que están limitadas a empleados de Cisco,como IOU o IOL.

Pero si no son empleados, hay alternativas para utilizar IOL de manera legal, pueden pagar una licencia de VIRL anual de $79 USD con propósitos académicos que les permite similar una red, de una manera más completa que usar GNS3.

Explicado esto, si alguien que no es empleado de Cisco, pero tiene acceso al TAC de Cisco, y hace un laboratorio en GNS3, NO LLAMEN AL TAC para pedir ayuda.

• La primera razón es que el TAC provee soporte breack & fix, es decir, funciona, deja de funcionar y el TAC lo arregla.
• La segunda es que el software utilizado para correr en GNS3 no es legal, y se pueden meter en un problema.
• Y la tercera es que el TAC no ayuda con 'laboratorios' o estudios, no dan clases, no enseñan, no son instructores.

Para eso existen los forus de ayuda, la documentación de los fabricantes, como las guías de configuración de Cisco y la bibliografía disponible.

Incluso, si no quieren comprar un libro de $80USD o más, hay opciones, como Safari Books,  que les da acceso a la gran mayoría de libros de Cisco Press por una memebresía anual.

¿Qué es una VRF?

En la entrada anterior se describe brevemente como funciona un router y el proceso que lleva a instalar un ruta en la tabla de ruteo, el control plane se comunica con otros routers utilizando los protocolos de ruteo e intercambia información de la red.

Este proceso se lleva a cabo por defecto para la tabla de ruteo global y todas las interfaces conectadas a una red participan de esta tabla de ruteo.

La tecnología Virtual Routing Forwarding nos permite separa información de ruteo en el control plane en diferentes instancias, aislando la tabla de ruteo global de la tabla de ruteo de otra VRF. Cuando se utiliza únicamente para aislar las tablas de ruteo, se llama VRF Lite.

Esto permite que el router se comporte como si fueran varios router a la vez, haciendo posible la existencia virtual de varios dispositivos.

Para configurar una vrf hay varios métodos, utilizaré el que recomienda Cisco, aunque hay uno más reciente que de momento no sé que se incluya en alguna certificación.

Definimos el nombre de la VRF, le asignamos un Route Distinguisher y la familia de direcciones que se relaciona con la VRF, con el método anterior sólo podía utilizarse IPv4, con este método se soporta IPv4 e IPv6.

**Este no es el caso, pero cuando se utilizan las address families en conjunto mBGP (u OSPF) se pueden formar VPN layer 3 de MPLS utilizando route-targets.

Pueden ver que ambos routers están conectados directamente del puerto E0/0 al puerto E0/3, y he creado 4 subinterfaces y una instancia de OSPF en 2 VRF para simular que tenemos una red compleja, la prueba será un ping desde el R1 Loopback1 a la Loopback 2 en el mismo R1, el traceroute nos mostrará el camino entre las diferentes VRF y podemos ver que aunque ambas interfaces están en el mismo router, no pueden comunicarse directamente pues el proceso de virtualización las mantiene aisladas:

¿Cómo funciona un router Cisco?

Un router es una computadora de propósito específico que se divide en 3 partes principales:

• Control Plane

que ejecuta todas las operaciones de los protocolos en el router, por ejemplo PIM; OSPF; EIGRP, LACP, BFD, ARP, etc. e interactúa con otros routers.

• Data plane

que es responsable de recibir y transmitir los paquetes que fluyen en la red, así como aplicar políticas de calidad de servicio (QoS) o de seguridad como las access lists.

• Management Plane

que se encarga de las conexiones del dispositivo para su administración, como sesiones de SSH, Telnet, FTP, etc.

Dentro del control plane se ejecutan las decisiones sobre que rutas deben instalarse en la tabla de ruteo o RIB (Routing information Base), y las fuentes de esas rutas pueden ser estáticas o dinámicas.
Dentro de las estáticas están las interfaces conectadas en el router, o las rutas que nosotros incluímos por medio de un comando.
Dentro de las dinámicas están las aprendidas de los diferentes protocolos de ruteo que pueden ser
del tipo

• Vector Distancia como RIP, basado en saltos.
• Vector Distancia Mejorado, como EIGRP, basado en saltos, delay, ancho de banda, confiabilidad, ocupación y MTU del enlace.
• Estado del enlace, como OSPF e IS-IS, basados en costo de cada enlace en el dominio de ruteo
• Vector Trayectoria (path vector) como BGP, basado en "saltos" a través de diferentes sistemas autónomos.

Licencias en Cisco IOS

Hay una pregunta muy frecuente que es hecha por usuarios tanto principiantes como expertos, ¿por qué mi router/switch no acepta el comando?

El IOS de Cisco comenzó en las versiones 8, saltó a la 12 y siguió su evolución hasta las presentes 15 y comienzan a salir algunas versiones 16. En esas primeras etapas, el almacenamiento y la memoria de ejecución eran limitadas por un tema principalmente económico, al abaratarse el almacenamiento y la memoria RAM, fue posible incluir mas características en una versión.

Con las versiones 12 se tenían licencias de diferentes niveles, cada una contenía un conjunto de diferentes tecnologías que el usuario podía utilizar, y que por tanto permitía que el dispositivo aceptara o no ciertos comandos que podían no estar incluídos en la versión.

Los diferentes niveles eran algo así:

• IP Base
• IP Voice

• Advanced Security
• SP Services
• Enterprise Base

• Advanced IP Services
• Advanced Enterprise

• Advanced Enterprise Services

Con las versiones 15, Cisco migró a un IOS versión Universal, lo que significa que el IOS contiene todos los comandos y tecnologías disponibles para esa plataforma en particular, pero que son activados o desactivados de acuerdo a la licencia instalada en el equipo.

Un ejemplo muy frecuente son los Switches Catalyst 4500 que utilizan software IOS XE, (lo que les permite ser equipos multiprocesador y ejecutar las funciones del equipo en procesos separados, lo cual les da una mayor estabilidad ante posibles fallas o errores). El IOS XE usualmente viene con licencias IP BASE, y por tanto al ejecutar EIGRP sólo se érmite el modo stub, lo que limita la funcionalidad del ruteo al comunicar sólo rutas locales, conectadas o sumarizadas en el router, y muy frecuentemente los usuarios creen que es un problema del equipo porque no reenvía información que recibió de otros vecinos.

Este pequeño inconveniente se resuelve adquiriendo e instalando la licencia de IP Services, o se puede hacer una solución parcial al utilizar un leak-map de EIGRP para permitir ciertas rutas.

Hay mucha información en Cisco sobre las licencias, como instalarlas, como utilizar versiones de prueba y como adquirirlas.

Pero a veces también es necesario saber, este router o switch ¿hacen lo que yo necesito? por ejemplo, ¿pueden correr FlexVPN?, ¿soportan túneles de GRE?. Para esto se puede utilizar el Feature Navigator, seleccionamos la plataforma, versión y licenciamiento que tenemos y nos dirá que tecnologías incluye; o al revés, seleccionamos la tecnología y nos dirá en que dispositivos se soporta, con que versiones y en que licenciamiento.

Un ejemplo de esto es el soporte de GRE, casi todos los usuarios dan por sentado que un dispositivo que tiene un comando tunnel es porque soporta túneles de GRE, pero en los switches 3750 no es una tecnología soportada, viene en el software, pero activarla podría causar problemas en el dispositivo.

Así que, utilicen también esta información para referencia cuando planeen una red, o cuando un problema de capacidad en los equipos se presente, no siempre es un tema de error en el hardware o software, también podría ser un tema de licencias o capacidades en los routers o switches.

Servicios IP (network services)

De la lista de temas a evaluar en el examen de CCIE, tenemos los servicios IP (5.3 Network services), en este artículo veremos algunos, son temas muy extensos que sólo menciono brevemente porque es importante conocerlos, pero que no son tan importantes como para explorarlos a fondo; pero son configuraciones que se deben dominar, ya que son temas comunes en cualquier red, comenzaermos con una configuración básica de DHCP en el router Green2, configurando el ip helper address en el Green1 para poder asignarle una IP al router dhcp_client. Usaré la topología anterior, simulando un ISP que nos provee de conexión mediante MPLS entre el PE1 y el PE2, estando esta parte de la red "oculta" a nuestros routers de la VRF Green.
Los servicios son: DHCP, NTP, SNMP, Syslog, WCCP, Netflow, Cisco IOS Embedded Event Manager, Remote Monitoring, FTP, TFTP y SCP en un router, acceso http, https, telnet y ssh, y por último IP SLA.

DHCP

Primero en dhcp_client desactivamos el ruteo (para simular un host), habilitamos un puerto con la configuración de cliente de dhcp, configuramos el router con el ip helper, es decir, le indicamos la dirección IP que tiene el servicio de DHCP, en este caso es la loopback 100 del router Green2, y en este último configuramos el servicio de DHCP, indicando la red,  el default gateway que se debe asignar a los clientes, así como el dominio y el servidor de DNS; es importante también configurar las direcciones IP que no queremos que sean asignadas con este servicio:
documento en cisco.com

DHCP_client#
! 
no  ip routing
!
interface Ethernet0/1
 ip address dhcp
 no ip route-cache

Configuración de MPLS parte 4, ruteo entre ISP (PE) y cliente (CE)

Ya que hicimos las VRF para cada cliente y sus correspondientes etiquetas, así como la comunicación entre los diferentes PE, haremos la comunicación de las rutas entre el cliente y el ISP, y la correspondiente redistribución hacia mBGP a fin de propagar las rutas entre los sitios del cliente.

Ambos clientes tienen las mismas redes a fin de demostrar que las VRF hacen posible el escenario entre clientes; por lo que utilizaremos loopback interfaces diferentes en cada router y las asignaremos  a diferentes protocolos de ruteo, probando así que existe la separación.

Desde del lado del cliente no hay nada especial:

blue1#sh runn | beg router

router eigrp 10

 network 10.11.0.0 0.0.0.7

 network 11.0.0.1 0.0.0.0

!

router ospf 10

 network 10.11.0.0 0.0.0.7 area 0

 network 11.0.0.2 0.0.0.0 area 1

!

router rip

 version 2

 passive-interface default

 no passive-interface Ethernet0/0

 no passive-interface Loopback103

 network 10.0.0.0

 network 11.0.0.0

 no auto-summary

Configuración de MPLS parte 3, las VRF

Comenzaremos con una breve explicación de qué es una VRF, y como las identificamos.
Una VRF (virtual routing and forwarding) es una instancia virtual y separada de la instancia global de ruteo en el dispositivo; es decir, es casi como tener un segundo router corriendo sus propios procesos de ruteo, independientes de cualquier otro presente en el dispositivo.

El uso más común y que simularemos en el ejemplo, es el que los proveedores de servicio utilizan para conectar a sus clientes con MPLS, configurando redes privadas virtuales que separan el tráfico de los clientes en instancias separadas de los demás clientes por medio de las etiquetas de ruteo. los routers que tenemos dentro del ISP les llamaremos P (provider), a los del borde de la red del ISP les llamaremos PE (provider edge) a los del cliente CE (customer edge)

Esta separación se logra con la configuración de la VRF primero, declarando su nombre, y después utilizando etiquetas para poder separar esa información de los demás procesos. Dichas etiquetas son muy parecidas a las que utilizamos en LDP para MPLS, pero en este ejemplo utilizaremos el formato "extendido". Dichas etiquetas son utilizadas en el encabezado de las rutas, por lo que cualquier vecino de mBGP que reciba dichas rutas etiquetadas podrá instalarlas en sus propias VRF conforme a lo que se le indica en la configuración.

Entre otros beneficios, tener una VRF nos permite la duplicación de direcciones IP entre diferentes clientes, es decir, podríamos tener a dos clientes diferentes utilizando las redes 10.0.0.0/16 sin problemas, ya que las rutas se procesas basadas en las etiquetas.

Basados en estas etiquetas indicaremos cuál es la que identifica localmente a nuestra VRF y compartiremos dicha información con nuestro vecino de mBGP , comunicando así que por ejemplo, la VRF X está dentificada por el Route Distinguisher Y:Z, y que necesitamos que exporte esa información hacia mBGP y que desde ahí importe las etiquetas que necesitamos para comunicar dos sitios de un mismo cliente. También agregaremos una familia de direcciones a BGP que comunique el ruteo entre ambos PE para la VRF de cada cliente.

Cuando activamos una nueva instancia o VRF, el router puede ejecutar sus propios procesos de BGP, OSPF, RIP, ISIS, etc. y los utilizaremos para intercambiar rutas entre el cliente y el ISP, logrando que el cliente nos entregue la información de sus redes y nosotros la llevemos a los demás sitios del mismo cliente, estableciendo así una red privada con comunicación basada en MPLS. También indicaremos en cada interface a que VRF queremos que pertenezca.

IMPORTANTE: cuando asignas una interface a una VRF, se borra la configuración de la interface y deberemos volver a indicar la IP y demás características deseadas en dicho puerto.

Los routers P (2, 3 y 4) no requieren configuración adicional.

Ejemplo de los routers PE con dos clientes, las compañías blue y green que tienen un sitio cada una conectados ambos al PE 1, y dos sitios conectados al PE2:

Configuración de MPLS parte 2, mBGP

Después de que hemos configurado el intercambio de etiquetas de MPLS, sigue activar mBGP a fin de poder intercambiar información de ruteo entre diferentes sistemas autónomos, dándonos la funcionalidad de poder comunicar dichos sistemas con cierta privacidad y aislando el tráfico en diferentes instancias, comenzando así con el servicio de una red privada virtual o VPN.

Lo primero es activar BGP en los routers 1 y 5, establecer su vecindad y configurar el tipo de instancia que queremos utilizar, en este caso VPNv4:

R1
router bgp 99
 bgp log-neighbor-changes
 neighbor 5.5.5.5 remote-as 99
 neighbor 5.5.5.5 update-source Loopback1
 !
 address-family vpnv4
  neighbor 5.5.5.5 activate
  neighbor 5.5.5.5 send-community extended
 exit-address-family

R5
router bgp 99
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 99
 neighbor 1.1.1.1 update-source Loopback1
 !
 address-family vpnv4
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 send-community extended
 exit-address-family

Configuración de MPLS parte 1, las etiquetas

Los routers Cisco tienen varias tablas que intervienen en la manera de reenviar un paquete, básicamente los procesos de ruteo se encargan de establecer opciones, seleccionar las mejores rutas e instalarlas en la tabla de ruteo global (RIB routing information base) y así tener opciones para ir a distintas redes.
Cuando las métricas son iguales (o similares si así nos interesa) se puede balancear el tráfico entre distintas rutas posibles.
Un inconveniente de la tabla de ruteo es que revisar la dirección de destino de un paquete contra la tabla es un proceso secuencial que ocupa mucha memoria, por lo que a través de CEF se construye una tabla de reenvío (FIB forwarding information base); este proceso es más rápido porque construye una tabla en la que se registran las direcciones de destino y las interfaces que nos llevan ahí, haciendo un proceso de conmutación o IP switching que es más eficiente para reenviar un paquete.
Lo siguiente es MPLS, que construye una tabla de etiquetas relacionando las redes que conocemos por distintos medios con números asignados localmente y remotamente, construyendo una tabla LIB (label information base) que reenvía el tráfico de manera más eficiente; ésto es porque el router recibe un paquete con un encabezado adicional que incluye las etiquetas de MPLS y que le indican por medio de la etiqueta el destino al que se dirige el paquete, se lee la etiqueta, se consulta la LIB, se quita la etiqueta de entrada, se coloca una etiqueta de salida (o se quitan todas si ha llegado a su destino) y se reenvía el paquete, todo sin consultar la tabla de ruteo o RIB.
El proceso de ruteo se encarga de mantener la LIB actualizada en cuanto a las distintas rutas disponibles, haciendo más eficiente el proceso de intercambiar rutas, y así mismo, el de transmitir tráfico.
Haremos un pequeño ejercicio de como configurar una MPLS con 5 routers contiguos, todos corriendo el proceso de OSPF 1 y todos con una loopback interface con máscara de 32 bits:

Descarga aquí las configuraciones completas de este laboratorio.

próximamente...

Hasta aquí he escrito de diferentes tecnologías de capa 2 para conectar dispositivos como DMVPN, VLANs, Frame-Relay, etherchannel, etc.

Ahora una pregunta un poco más complicada, ¿cómo conectar la interface FastEthernet de un router a dos VLANs diferentes utilizando sólo una IP?

Esto es más complicado porque al utilizar trunking (router on a stick) cada subinterface tiene una IP, y podría existir la necesidad de utilizar sólo una IP para dos VLANs.

Configuración Frame-Relay mapping

Para hacer la configuración de una interface física con encapsulación frame-relay que funciona como multipunto hay que tomar en cuenta el mapeo necesario para ligar una IP (lógica) a un DLCI (físico).

En este ejemplo tenemos un switch de FR simulando un ISP, que nos provee los siguientes circuitos:
del puerto 0 con dlci 101 al puerto 1 con dlci 202
del puerto 0 con dlci 102 al puerto 2 con dlci 203

Nótese que el puerto 0 cuenta con 2 DLCI, por lo que se trata de una interface multipunto.

La configuración consiste en fijar la encapsulación como Frame-Relay, con un tipo de lmi ANSI para este caso, y algo muy importante, hacemos el mapeo del circuito físico local a la IP remota, para el caso de R1 hice el mapeo de un DLCI a la IP local para poder hacer ping a la interface serial, como podemos ver en la validación, el ping es exitoso. Se agrega la instrucción broadcast para que la interface soporte el multicast de EIGRP y se formen las adyacencias.

En el caso de R2 no existe el mapeo de la IP local, por lo que el ping a su propia interface no es exitoso. Existe el mapeo del DLCI local a la IP de R1 indicando que soporta broadcast y el mapeo a R3 sin esta indicación, esto es importante porque  para llegar a R3 pasamos por R1 y el tráfico de multicast no es reenviado pro R1 hacia R3, por lo que no habría un correcto funcionamiento si utilizamos la indicación de broadcast.

La lógica de funcionamiento es similar a los túneles generados en el ejemplo de DMVPN, donde se mapea el tráfico multicast a la interface física, y se debe indicar el modo de funcionamiento de la interface (broadcast, non-broadcast, point-to-point. point-to-multipoint). Otra solución es hacer subinterfaces, pero implica un manejo lógico de dos interfaces distintas con diferente IP que carece del problema de split-horizon, y que utilizaría diferentes segmentos de red; en este ejemplo las 3 interfaces están en el misma red.

Este laboratorio ejecuta EIGRP, que sabemos que no puede regresar anuncios de rutas por la misma interface por la que llegan, así que en este caso especial deshabilitamos la regla de split-horizon para que las rutas aprendidas de R3 puedan ser enviadas por R1 a R2, y viceversa.

Ahora, las configuraciones de ejemplo:

Resource Reservation Protocol

Este es un ejemplo de configuración para reservar 60Kbps en una trayectoria entre distintos dispositivos, comenzando de R4, pasando a R3 y terminando en R5.

Comprobaremos reservando un bit rate de 5kbps con ráfagas de 2kbps para telnet desde R4 hacia R5.

R4# sh runn int s1/0
interface Serial1/0
 ip address 172.10.43.4 255.255.255.0
 serial restart-delay 0
 ip rsvp bandwidth 60

R3#sh runn int s1/0
interface Serial1/0
 ip address 172.10.43.3 255.255.255.0
 serial restart-delay 0
 ip rsvp bandwidth 60
end
R3#sh runn int fa0/1
interface FastEthernet0/1
 ip address 172.10.35.3 255.255.255.0
 ip ospf authentication-key test
 speed auto
 duplex auto
 ip rsvp bandwidth 60

end
R5#sh running-config interface fa0/1
interface FastEthernet0/1
 ip address 172.10.35.5 255.255.255.0
 ip ospf authentication-key test
 speed auto
 duplex auto
 ip rsvp bandwidth 60
end

Comprobación:
R4(config)# ip rsvp sender-host 172.10.35.5 172.10.43.4 tcp 23 5000 5 2
R4(config)#ip rsvp sender-host [destino] [origen] [protocolo] [puerto destino] [puerto origen] [bw] [burst]

configuración IP SLA

Monitorear el tiempo de respuesta de un servidor de Telnet cada 60seg (tiempo por default)

! primero damos el nombre de la prueba, en este caso 23

! y configuramos el servicio a probar, la conexión TCP, la IP destino y desactivamos paquetes de control

! configuramos el tiempo de vida (permanente) y tiempo de arranque de la prueba (ahora)

R1(config)# ip sla 23

R1(config-ip-sla)# tcp-connect 172.10.105.1 23 control disable

R1(config-ip-sla)# exit

R1(config)# ip sla schedule 23 life forever start-time now

! verificamos las estadísticas y vemos que la conexión es exitosa y tomó 112ms en la última prueba

CCIE lab: Layer 2 Technologies

Aquí un pequeño laboratorio de tecnologías capa 2 para el examen práctico de CCIE:

DMVP
IGMP
SPAN
RSPAN
MAC address aging
VTP
Trunking
Eherchannel
STP
RPVSP+ (portfast)
PPP (multilink y CHAP, PAP para S1/7)

DMVPN 2

Siguiendo con la confiiguración de DMVPN, ahora agregamos la encripción de IPSec, que puede ser en modo túnel o transporte, en este caso utilizamos transporte porque sólo es tráfico encriptado que viaja entre dos dispositivos que se conectan directamente, quizás si hubiera una red entre ambos extremos del túnel valdría la pena encriptar en modo túnel:
Transporte encripta/autentica sólo el payload del datagrama y podemos leer origen y destino
Túnel encripta todo el datagrama, por lo que los routers en el camino no pueden interpretar el origen y destino, por ejemplo en casos donde el origen y destino no son parte del esquema de ruteo de la red.
Mas información al respecto aquí.

Los pasos para esta configuración son:

DMVPN

DMVPN es una tecnología que se basa la generación de túneles de GRE desde varios puntos remotos (spokes) hacia un nodo central (hub), la comunicación a través de esos túneles es en una red Non-Broadcast Multiaccess, lo que se debe tener en cuenta al implementar protocolos de ruteo.
Un documento que pueden consultar es DMVPN Design and Implementation.
Por ser este tipo de red, necesitamos ejecutar un proceso de ruteo para las interfaces físicas y uno para las interfaces lógicas; esto permite que el router conozca la ruta a la dirección lógica de otro túnel a través de la interfaz física,aunque no es obligatorio para levantar los túneles, sino para pasar tráfico a través de ellos.
Para nuestro ejemplo tenemos routers con puertos Ethernet con las direcciones: 1.0.0.0/24
e interfaces lógicas en 2.0.0.0/24
Al estar todos a un switch capa dos, no requieren el ruteo de las interfaces físicas en este caso, pero podrían estar en una red más compleja y funcionaría más o menos igual.

Los pasos principales de configuración son:

• Asegurarnos de que las interfaces físicas de los routers se pueden comunicar unas con otros, a través de pings
• crear el túnel (interfaces lógicas)
• asignar direcciones de manera que todas estén en la misma red
• bloquear el redireccionamiento de pings
• asignar un valor de MTU al túnel (considerando que una parte del paquete lo ocupa NHRP)
• activar NHRP que nos permite levantar los túneles dinámicos (next hop resolution protocol)
• el network-id
• el mapeo de las direcciones
• el mapeo de multicast (dinámico en hub y estático en spokes)
• indicar la dirección del next-hop-server (ip nhrp nhs A.B.C.D)
• asignar el origen del tráfico en el túnel con la interfaz física
• configurar el tipo de túnel
• configurar en cada túnel los comandos específicos del protocolo de ruteo que utilicemos.

Ejemplo de configuración básica:

El camino al CCIE de Routing and Switching

Han pasado años de no escribirle a este blog y muchas cosas han cambiado, desde la versión de CCNA que alguna vez tomé como reto y que hoy es totalmente nueva, pero en esencia exige los mismos conocimientos;y sobre todo, yo he cambiado, el tamaño de los retos ha cambiado.

Logré completar 3 CCNP, seguridad, routing and switching, CCDP de diseño, y quisiera seguir con Data Center, pero decidí dejarlo de lado porque descubrí que en el fondo evito enfrentar el CCIE haciendo otras cosas menos difíciles, así que, volveré a escribir aquí como parte de la metodología de estudio y preparación para la siguiente meta.

ITIL foundations v3
CCIE R&S written
CCNP Routing & Switching
CCNA R&S
CCDP
CCDA
CCNP Security
CCNA Security
CCNA Data Center
Cisco Cybersecurity Specialist
Cisco IOS Security Specialist
Cisco IPS Specialist
Cisco VPN Security Specialist
Cisco Firewall Security Specialist
Cisco ASA Specialist

Esta es la lista de temas que se deben dominar para el examen práctico de Cisco Certified Internetwork Expert version 5.0.

VLANs privadas

Puertos protegidos y no protegidos.
Los puertos protegidos sólo se pueden comunicar con puertos no protegidos, son útiles para switches de acceso, y es una configuración local al switch, no se extiende más allá del dispositivo.

Configuring Private VLANs

Características:

• Una VLAN primaria se divide en VLANs secundarias
• estas VLAN son aisladas en community VLANs
• el host puede comunicarse sólo con puertos promiscuos
• los hosts en community VLANs pueden comunicarse en la misma comunidad
• PVLAN no son soportadas en los Catalyst 2960

Puertos:

• Aislados, pueden comunicarse sólo con puertos promiscuos
• Promiscuos, se comunican con todos los otros puertos
• Comunidad, se comunican con los puertos de la comunidad y promiscuos.

Configuracion de PVLAN aisladas:

verificando operaciones generales de VLAN

show interface switchport
show running-config int f0/8
show vlan
show interfaces trunk

problemas comunes de las troncales.
Las troncales pueden ser estáticas o autonegociadas con DTP
para el trunking autonegociado, los switches deben estar en el mismo dominio de VTP
algunas combinaciones de trunk serán exitosas, algunas no:

• auto - auto (no será trunk)
• deseable - acceso (no será trunk)
• trunk no negotiate - auto (no será trunk)

Troubleshooting:
Crear las VLAN
¿se agregaron a todos los switches?
debe ser limitada manualmente? (pruned)
Agregar nuevos usuarios a los puertos
está el puerto en la VLAN correcta?
está el puerto activo?
está activo como switchport?
verificar la conectividad
están todos los links en trunk?
está la VLAN permitida en todos los trunks?
está STP bloqueando un link?

 Problemas con 802.1q native VLAN
los frames son transportados en un link de trunk que no tiene tagging
la VLAN nativa debe hacer match en los dos dispositivos que están en link
el tráfico se mezcla si no coinciden los nombres de LVAN nativa.
la VLAN nativa de default es la VLAN 1
configurar las VLAN no utilizadas...

Recomendaciones para configurar Trunks y VTP

switchport mode interactions

• Siempre configurar los puertos como trunk o acceso en ambos switches
• tratar de no usar auto-negociación, deshabilitar la negociación y no usar dynamic.
• La configuración manual es deseable.

1. Configurar las VLANs
2. Configurar el modo trunk
3. Desactivar la negociación de trunk
4. Quitar las VLAN innecesarias de los trunks
5. Configurar las VLAN nativas como no usadas
6. Desactivar trunking en los puertos de host (acceso)
7. No usar VTP (utilizar transparent mode)

Configuración VTP

usar modo transparente

VLAN se almacena en la configuración del switch

no anunciar VTP a otros switches

....

show VTP status

Problemas con VTP

• VLANs que faltan (otro VTP switch nos borra las VLANs)
• No recibir actualizaciones como se esperaban (VTP passwords y  dominios deben coincidir)
• Demasiadas VLANs (hay que hacer los dominios de VTP pequeños)