Laboratorio + Ticket A

Integrantes:
Harold Marriaga Barrios
Wilmys Ibáñez
Julián Zapata
Situación Inicial

• En el TT-A primeramente plantean la situación de que SAPNA solicita

ayuda para solucionar algunas rutas faltantes requeridas para las
pruebas de implementación de BGP-VRF hay que verificar que la
implementación sea la correcta. Procedemos a validar la
conectividad LAN con las especificaciones de VTPv3 y MST.
Problema 1

• le falta la configuración de la instancia 2 y la VLAN

DLS1 110.

Diagnóstico • Falla en configuración de vlans, de MST y VTP

• Show spanning-tree mst configuration, show vtp

Verificación status , show spanning-tree mst configuration.

• Se debe configurar correctamente el vtp en modo

Solución transparentes, agregar las vlans faltantes y el MST.
DLS1 le falta la configuración de la instance 2 y la VLAN 110. Para poder agregar la VLAN al
DLS1 se debe configurar el DLS1 en modo transparent vlan para poder asignar la VLAN 110. Y
luego volvemos a dejarlo como el Primary Server para el VTP.

(config)# configure terminal

(config)# vtp mode transparent vlan
(config)# vlan 110
(config-vlan)# name GUEST
(config-vlan)# exit
(config)# vtp mode server vlan
Según las especificaciones las rutas requieren sincronización, así que la ruta
192.168.2.2/32 debe registrar como una ruta IGP en el dominio de enrutamiento
EIGRP. En R1 las rutas BGP se redistribuyen en EIGRP en IPv4 e IPv6). Pero en
R2 No se observan comandos de redistribución. Se procede a agregar los
comandos en R3 que tiene R1 para las direcciones EIGRP de IPv4 e IPv6.
Adicional se debe redistribuir la métrica BGP 65501 1544 2000 255 1 1500. Y
pudimos evidencias que R1 ha aprendido la ruta 192.168.2.2/32 como una ruta
EIGRP externa, y R2 aprendió la ruta a través de BGP.
Situación Inicial

• Como otra medida de seguridad del plano de control, la empresa ha

decidido implementar la autenticación MD5 entre los Routers EIGRP
y los conmutadores de capa 3. Como piloto, un colega suyo
configuró la autenticación MD5 en el Switch de capa 3 DLS2 y el
Router R3. Ahora los usuarios de sucursales en la LAN R3 (PC-C) no
pueden acceder a SRV1 ni a Internet.
Problema 2

• Error de configuración en BGP y error en

DLS2 y R1 configuración de acces list en DLS2

• Fallas en la sumarización de las rutas de EIGRP

Diagnóstico
• show bgp summary, show bgp neighbors, show
Verificación running config.

• Corrección de configuración bgp, rutas EIGRP y

Solución Acces list en DLS2 y R1.
verificar el estado del BGP con el comando show bgp
Se procede a generar ACL en DLS1 se aplica hacía la red interna por la interfaz E1/0.
Se procede a generar ACL en DLS2 se aplica hacía la red interna por la interfaz E1/0.
Se procede a generar ACL en DLS2 se aplica hacía la red interna por la interfaz E1/0.
Debido a que la sesión TCP para iBGP es la conexión entre cliente-servidor con el
puerto de destino 179. En caso de que R1 inicie la sesión BGP TCP en donde DLS2
bloqueará el tráfico TCP de retorno para la sesión iBGP. Se puede solucionar
agregando una ACE a cada ACL que permita que el puerto de origen sea 179.
Las redes EIGRP loopback de IPv4 de DLS1 no se ven en DLS2. En las tablas de enrutamiento
de R3 tampoco está presente la sumarización de las rutas de DLS2 por lo que se procede a
realizar la configuración.

ip summary-address eigrp 1 10.2.0.0 255.255.252.0

ipv6 summary-address eigrp 1 2001:DB8:CAFE:2000::/52
Las redes EIGRP loopback de IPv4 de DLS1 no se ven en DLS2. En las tablas de
enrutamiento de R3 tampoco está presente la sumarización de las rutas de DLS2
Situación Inicial

• Como otra medida de seguridad del plano de control, su empresa ha

decidido implementar la autenticación MD5 entre enrutadores EIGRP
y conmutadores de capa 3. Como piloto, un colega suyo configuró la
autenticación MD5 en el conmutador de capa 3 DLS2 y enrutador
R3. Ahora los usuarios de sucursales en la LAN R3 (PC-C) no
pueden acceder a SRV1 o el internet.
Problema N

DLS1 y DLS2 • Se evidencia que solo hay filtros de paquetes en DLS1 y

DLS2 (de TT-A); restringen TCP a BGP.

Diagnóstico • El problema se da en los objetos del SLA TCP Connect de

HSRP.

• Show running, show vlan database, show spanning-tree

Verificación
Solución • Actualizar los ACL
El problema se da en los objetos del SLA TCP Connect de HSRP.

access-list 100 permit tcp any any eq 23

access-list 100 permit tcp any eq 23 any

Después de estas actualizaciones de ACL, Telnet desde la LAN funciona a R3 pero no a R1.
Situación Inicial

• El telnet no funciona en R1 pero si en el R3, tenemos que solucionar

este problema .
aaa new-model
aaa authentication login default local
aaa authentication login CONSOLE none
aaa authorization exec default local

Ahora Telnet trabaja para R1. Tenga en cuenta que la característica TCP Connect del SLA 2
no impide el acceso de Telnet a R1 o R3, incluso si las direcciones IPv6 en el SLA definido por
IPv6 se utilizan como direcciones IPv6 de destino.
Problema N

R1 • En R1 el telnet no funciona desde la LAN

Diagnóstico • Para este fallo se cree que el protocolo triple AAA este
en vigencia

• Show running, se verifica desde el pc a través de telnet

Verificación
Solución • Se configura nuevamente triple AAA luego se verifica
telnet desde el pc