0% encontró este documento útil (0 votos)
40 vistas13 páginas

Sol1 Pec2

Ejercicios de redes resueltos de Cisco.

Cargado por

ruben ramirez
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
40 vistas13 páginas

Sol1 Pec2

Ejercicios de redes resueltos de Cisco.

Cargado por

ruben ramirez
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

PEC 2 DRC

2023-24/2

Estudios de Informática, Multimedia y Telecomunicación

Redes y Aplicaciones Internet


Actividad: PEC 2 – Segunda Prueba de Evaluación Continua

✓ He resuelto esta PEC de forma individual y bajo mi responsabilidad. Estoy al corriente de los
requisitos para la cita de fuentes externas, y de las consecuencias académicas de la falta
de originalidad en mis actividades evaluables.
✓ Modelo CCNA

Para la resolución de esta PEC2 se han tomado como referencia el manual (Àlex Macia Pérez, 2019)
y el curso (Networking Academy - Cisco Systems, s.f.).

Ejercicio 1 (30%) - Configuración de dispositivos


En primer lugar, para evitar posibles confusiones, comenzamos por configurar el hostname correspon-
diente en cada uno de los equipos.

1. Mantener el montaje de la sede actual:


Para que cada una de las 4 subredes sea alcanzable desde cualquier red externa a la LAN actual y dado que
se indica que “RT_wan” no permite configurar enrutamiento dinámico, debemos configurar una ruta está-
tica para cada una de las subredes en este router de la siguiente forma:

RT_wan(config)#ip route 172.27.0.128 255.255.255.192 172.27.0.241 → ruta hacia RT_west


RT_wan(config)#ip route 172.27.0.192 255.255.255.224 172.27.0.245 → ruta hacia RT_central (gi0/1)
RT_wan(config)#ip route 172.27.0.224 255.255.255.240 172.27.0.245 → ruta hacia RT_central (gi0/2)
RT_wan(config)#ip route 172.27.0.0 255.255.255.128 172.27.0.249 → ruta hacia RT_east

Además, es necesaria una ruta por defecto que dirija el tráfico a la IP de la interfaz del router RT_core co-
nectada al RT_wan (se le ha asignado la IP 172.27.0.254) para el acceso hacia el exterior desde cada una de
las subredes:

RT_wan(config)#ip route 0.0.0.0 0.0.0.0 172.27.0.254

Por otro lado, en el router RT_core será necesario dirigir las peticiones con destino las subredes conectadas
al RT_wan hacia la IP de la interfaz de interconexión entre ellos (Serial0/0/0), a la que se le ha asignado la IP
172.27.0.253:

RT_core(config)#ip route 172.27.0.128 255.255.255.192 172.27.0.253


RT_core(config)#ip route 172.27.0.192 255.255.255.224 172.27.0.253
RT_core(config)#ip route 172.27.0.224 255.255.255.240 172.27.0.253
RT_core(config)#ip route 172.27.0.0 255.255.255.128 172.27.0.253

2. Implementar una DMZ:


Dado que se trata de una sede y un servicio independientes, se ha decidido asignar otro rango privado dis-
tinto al diseño actual. El direccionamiento será el siguiente:
PEC 2 DRC
2023-24/2

- RT_dmz:
gi0/1 - 10.27.0.14/28 → SW_DMZ

- SRV-Web:
fa0 - 10.27.0.8/28

- SRV-FTP_IN:
fa0 - 10.27.0.9/28

- SRV-FTP_EX:
fa0 - 10.27.0.10/28

Aunque formalmente sería suficiente con asignar una máscara /29 a esta red (sólo disponemos de 3 equi-
pos y una puerta de enlace), se ha decidido asignar una /28 por disponer de cierto margen en caso de un
posible crecimiento de la red.
Para cada uno de los servidores, su puerta de enlace será la IP de la interfaz gi0/1 del router RT_dmz. Se
muestra a continuación cómo se configuraría la interfaz gi0/1 del router y se muestra la configuración de
uno de los servidores FTP:

RT_dmz(config)#interface gigabitEthernet 0/1


RT_dmz(config)#ip address 10.27.0.14 255.255.255.240
RT_dmz(config)#no shut

3. Líneas dedicadas:
Antes de comenzar a configurar OSPFv2, vamos a asignar el direccionamiento para la comunicación entre el
router RT_core hacia cada una de las LAN y DMZ (RT_wan, RT_dmz y sw_core), quedando la asignación de
la siguiente forma:

- RT_core:
se0/1/1 - 172.27.0.254/30 → RT_wan
se0/0/0 - 10.27.0.254/30 → RT_dmz
gi0/1 - 172.27.1.254/29 → sw_core
PEC 2 DRC
2023-24/2

- RT_wan:
se0/1/1 - 172.27.0.253/30 → RT_core

- RT_dmz:
se0/0/0 - 10.27.0.253/30 → RT_core

Se muestra a continuación cómo se configurarían las interfaces del router RT_core:

RT_core(config)#interface se0/1/1
RT_core(config)#ip address 172.27.0.254 255.255.255.252
RT_core(config)#no shut
RT_core(config)#interface se0/0/0
RT_core(config)#ip address 10.27.0.254 255.255.255.252
RT_core(config)#no shut
RT_core(config)#interface gi0/1
RT_core(config)#ip address 172.27.1.254 255.255.255.240
RT_core(config)#no shut

NOTA: la red asignada a la nueva LAN (Marketing, Helpdesk e I+D), así como la configuración de los equi-
pos, se detalla en el punto 4.

Comencemos a configurar OSPFv2. Es necesario tener en cuenta que nos encontramos en un escenario de
área única con redes de multiacceso de punto a punto y de difusión. Para llevar a cabo este cometido, se
seguirán las siguientes pautas:

- Se utiliza el ID 10 para la activación de OSPF en todos los routers y el “0” como identificador de área.
- Se habilitan las interfaces de cada router para enviar y recibir paquetes OSPF.
- Se configura OSPF para que las actualizaciones de enrutamiento no se envíen a las redes donde no sean
necesarias.

A continuación, se muestra la configuración resultante de cada router tras aplicar las indicaciones anterio-
res:

RT_core:
router ospf 10
log-adjacency-changes
passive-interface GigabitEthernet0/2
network 10.27.0.254 0.0.0.0 area 0
network 172.27.1.0 0.0.0.255 area 0

interface GigabitEthernet0/1
ip ospf 10 area 0

interface serial 0/0/0


ip ospf 10 area 0

RT_mkt:
router ospf 10
log-adjacency-changes
passive-interface GigabitEthernet0/0
network 172.27.1.0 0.0.0.255 area 0
interface GigabitEthernet0/0
PEC 2 DRC
2023-24/2

ip ospf 10 area 0

interface GigabitEthernet0/1
ip ospf 10 area 0

RT_hlp:
router ospf 10
log-adjacency-changes
passive-interface GigabitEthernet0/0
network 172.27.1.0 0.0.0.255 area 0

interface GigabitEthernet0/0
ip ospf 10 area 0

interface GigabitEthernet0/1
ip ospf 10 area 0

RT_id:
router ospf 10
log-adjacency-changes
passive-interface GigabitEthernet0/0
network 172.27.1.0 0.0.0.255 area 0

interface GigabitEthernet0/0
ip ospf 10 area 0

interface GigabitEthernet0/1
ip ospf 10 area 0

RT_dmz:
router ospf 10
log-adjacency-changes
passive-interface GigabitEthernet0/1
network 10.27.0.253 0.0.0.0 area 0
network 10.27.0.0 0.0.0.15 area 0

interface GigabitEthernet0/1
ip ospf 10 area 0

interface serial 0/0/0


ip ospf 10 area 0

- Se configura el router RT_core con la prioridad de interfaz OSPF más alta para que sea siempre el router
designado de la red multiacceso:

RT_core(config)#interface GigabitEthernet0/1
RT_core(config-if)# ip ospf priority 255
PEC 2 DRC
2023-24/2

- Se configura en el router RT_core una ruta predeterminada hacia la interfaz del servidor Google, de forma
que se distribuya automáticamente a todos los routers de la red:

RT_core(config)#ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/2


RT_core(config)#router ospf 10
RT_core(config-router)#default-information originate

Los vecinos de cada uno de los routers quedarían de la siguiente forma:

RT_core#show ip ospf neighbor


Neighbor ID Pri State Dead Time Address Interface
172.27.1.245 1 FULL/BDR 00:00:33 172.27.1.245 GigabitEthernet0/1
172.27.1.241 1 FULL/DROTHER 00:00:32 172.27.1.241 GigabitEthernet0/1
172.27.1.249 1 FULL/DROTHER 00:00:33 172.27.1.249 GigabitEthernet0/1
10.27.0.253 0 FULL/ - 00:00:32 10.27.0.253 Serial0/0/0

RT_mkt#show ip ospf neighbor


Neighbor ID Pri State Dead Time Address Interface
172.27.1.254 255 FULL/DR 00:00:39 172.27.1.254 GigabitEthernet0/1
172.27.1.241 1 FULL/DROTHER 00:00:36 172.27.1.241 GigabitEthernet0/1
172.27.1.249 1 FULL/DROTHER 00:00:38 172.27.1.249 GigabitEthernet0/1

RT_hlp#show ip ospf neighbor


Neighbor ID Pri State Dead Time Address Interface
172.27.1.245 1 FULL/BDR 00:00:34 172.27.1.245 GigabitEthernet0/1
172.27.1.254 255 FULL/DR 00:00:34 172.27.1.254 GigabitEthernet0/1
172.27.1.241 1 2WAY/DROTHER 00:00:32 172.27.1.241 GigabitEthernet0/1

RT_id#show ip ospf neighbor


Neighbor ID Pri State Dead Time Address Interface
172.27.1.245 1 FULL/BDR 00:00:39 172.27.1.245 GigabitEthernet0/1
172.27.1.254 255 FULL/DR 00:00:30 172.27.1.254 GigabitEthernet0/1
172.27.1.249 1 2WAY/DROTHER 00:00:39 172.27.1.249 GigabitEthernet0/1

RT_dmz#show ip ospf neighbor


Neighbor ID Pri State Dead Time Address Interface
172.27.1.254 0 FULL/ - 00:00:36 10.27.0.254 Serial0/0/0

4. Plan de direccionamiento "continuista":


Con el fin de mantener la misma filosofía en cuanto al direccionamiento y dado el número de puestos de
trabajo necesarios para casa subred, se ha asignado el siguiente direccionamiento:

- RT_mkt:
gi0/1 - 172.27.1.245/28 → sw_core
gi0/0 - 172.27.1.222/27 → SW_mkt

- RT_hlp:
gi0/1 - 172.27.1.249/28 → sw_core
gi0/0 - 172.27.1.126/25 → SW_hlp

- RT_id:
PEC 2 DRC
2023-24/2

gi0/1 - 172.27.1.241/28 → sw_core


gi0/0 - 172.27.1.190/26 → SW_id

Se muestra a continuación un ejemplo de configuración para uno de los routers:

RT_mkt(config)#interface gigabitEthernet 0/0


RT_mkt(config-if)#ip address 172.27.1.222 255.255.255.224
RT_mkt(config-if)#no shut
RT_mkt(config-if)#interface gigabitEthernet 0/1
RT_mkt(config-if)#ip address 172.27.1.245 255.255.255.240
RT_mkt(config-if)#no shut

Para cada equipo dentro de la subred a la que pertenece, su puerta de enlace será la IP de la interfaz gi0/0
de su router de referencia. Por ejemplo, para un equipo de la subred de marketing, la puerta de enlace será
la IP 172.27.1.222. Por lo tanto, se configura cada host con una IP estática dentro del rango de la subred a
la que pertenece (siguiendo el mismo patrón que en el diseño actual) y se le asigna la puerta de enlace co-
rrespondiente.

Se muestra a continuación la configuración de un equipo de marketing:

En este punto, todos los equipos son alcanzables entre sí y pueden acceder al servidor de Google (8.8.8.8).

Ejercicio 2 (30%) - Configuración de ACLs


● Desde todas las ubicaciones (internas y externas) se debe de poder acceder al servicio web de
"SRV-WEB".
Este acceso se configurará en todas las ACL aplicadas ya que, en caso de no aplicarse ninguna ACL sobre una
interfaz, el tráfico por defecto estará permitido. Sin embargo, en el momento de aplicar una ACL todo el
tráfico se bloqueará de forma predeterminada a menos que se indiquen explícitamente los accesos
permitidos. Además, para que esta regla se cumpla siempre se añadirá de primera en la lista (ID más bajo).
La línea que identifica esta necesidad es la siguiente:

permit ip any host 10.27.0.8


PEC 2 DRC
2023-24/2

NOTA: En el punto 4 veremos que será necesario añadir una línea encima en algunos casos.

● El acceso por FTP a "SRV-FTP_IN" sólo debe funcionar desde las subredes de la empresa (todas).
Dado que en las ACL extendidas se aconseja aplicarlas en las interfaces tan cercanas como sea posible al
origen del tráfico, se creará una ACL en cada uno de los routers de las subredes, los más cercanos a los
equipos origen. Dicha ACL se configurará en entrada en las interfaces de cada router que conectan con las
subredes correspondientes. Como desde cada subred ya sólo puede haber una red origen, la ACL tendrá el
siguiente formato:

ip access-list extended ACCESO_DMZ


permit tcp any host 10.27.0.9 eq ftp

Además, para denegar el acceso desde el exterior, se configurará una ACL en la interfaz externa del router
RT_core gi0/2 y se aplicará al tráfico entrante (como veremos en la configuración final, no será necesario
indicar explícitamente esta denegación al aplicarse el “deny” implícito de la ACL).

● El acceso por FTP a "SRV-FTP_EX" sólo debe funcionar desde el exterior de la empresa (Internet).
Nos encontramos en un escenario parecido al caso anterior, pero en este caso (gracias al "deny" explícito),
no es necesario denegar explícitamente esta conexión desde cada subred de la red interna. Tan sólo es
necesario permitir el acceso desde el exterior añadiendo la siguiente línea en la ACL del RT_core indicada en
el punto anterior:

ip access-list extended ACCESO_DMZ


permit tcp any host 10.27.0.10 eq ftp

● El envío de ping a todos los servidores sólo debe funcionar desde las redes "HelpDesk", "I+D" y
"IT".
Como ya tenemos creada una ACL en cada una de las subredes, las aprovecharemos para permitir/denegar
este acceso en las redes solicitadas. A pesar de que en el punto 1 hemos indicado que esa línea tendría el ID
más bajo, para poder denegar el envío de ping será necesario incluir una línea por encima en los casos
correspondientes. Por lo tanto:

- Para el caso de las redes "HelpDesk", "I+D" y "IT":


ip access-list extended ACCESO_DMZ
permit icmp any 10.27.0.0 0.0.0.15

- Para el resto de los casos (importante que esta línea esté por encima de la del punto 1):
ip access-list extended ACCESO_DMZ
deny icmp any 10.27.0.0 0.0.0.15

NOTA: Como en el punto 1 tan sólo hemos permitido el acceso al SRV-WEB, bastaría con denegar icmp tan
sólo para este servidor, ya que el resto ya se denegaría con el "deny" implícito.

● El acceso por SSH a todos los servidores sólo debe funcionar desde la red "IT".
Al igual que en el caso anterior, permitimos este acceso sólo desde la red "IT" y denegamos en el resto de la
siguiente forma:
PEC 2 DRC
2023-24/2

- Para el caso de "IT":


ip access-list extended ACCESO_DMZ
permit tcp any 10.27.0.0 0.0.0.15 eq 22

- Para el resto de los casos (importante que esta línea esté por encima de la del punto 1):
deny tcp any 10.27.0.0 0.0.0.15 eq 22

Finalmente, las ACLs de cada router (junto con la configuración aplicada sobre la interfaz correspondiente)
serán las siguientes:

RT_core:
ip access-list extended ACCESO_DMZ
deny icmp any 10.27.0.0 0.0.0.15
deny tcp any 10.27.0.0 0.0.0.15 eq 22
permit ip any host 10.27.0.8
permit tcp any host 10.27.0.10 eq ftp

interface gi0/2
ip access-group ACCESO_DMZ in

**************
RT_west:
ip access-list extended ACCESO_DMZ
deny icmp any 10.27.0.0 0.0.0.15
deny tcp any 10.27.0.0 0.0.0.15 eq 22
permit ip any host 10.27.0.8
permit tcp any host 10.27.0.9 eq ftp

interface gi0/1
ip access-group ACCESO_DMZ in

**************
RT_central:
ip access-list extended ACCESO_DMZ
deny icmp any 10.27.0.0 0.0.0.15
deny tcp any 10.27.0.0 0.0.0.15 eq 22
permit ip any host 10.27.0.8
permit tcp any host 10.27.0.9 eq ftp

interface gi0/1
ip access-group ACCESO_DMZ in
interface gi0/2
ip access-group ACCESO_DMZ in

**************
RT_east:
ip access-list extended ACCESO_DMZ
permit ip any host 10.27.0.8
permit tcp any host 10.27.0.9 eq ftp
permit icmp any 10.27.0.0 0.0.0.15
PEC 2 DRC
2023-24/2

permit tcp any 10.27.0.0 0.0.0.15 eq 22

interface gi0/1
ip access-group ACCESO_DMZ in

**************
RT_mkt:
ip access-list extended ACCESO_DMZ
deny icmp any 10.27.0.0 0.0.0.15
deny tcp any 10.27.0.0 0.0.0.15 eq 22
permit ip any host 10.27.0.8
permit tcp any host 10.27.0.9 eq ftp

interface gi0/0
ip access-group ACCESO_DMZ in

**************
RT_hlp:
ip access-list extended ACCESO_DMZ
deny tcp any 10.27.0.0 0.0.0.15 eq 22
permit ip any host 10.27.0.8
permit tcp any host 10.27.0.9 eq ftp
permit icmp any 10.27.0.0 0.0.0.15

interface gi0/0
ip access-group ACCESO_DMZ in

**************
RT_id:
ip access-list extended ACCESO_DMZ
deny tcp any 10.27.0.0 0.0.0.15 eq 22
permit ip any host 10.27.0.8
permit tcp any host 10.27.0.9 eq ftp
permit icmp any 10.27.0.0 0.0.0.15

interface gi0/0
ip access-group ACCESO_DMZ in

Ejercicio 3 (20%) - Plan de seguridad


● Identificación de los activos de la empresa:
Para poder identificar correctamente los activos de la empresa, se tomará como referencia la clasificación
indicada en (Instituto Nacional de Ciberseguridad (INCIBE), 2016). Así, en la empresa podemos encontrar:

- Datos → Cualquier tipo de información (digitalizada o no) gestionada por la empresa como, por ejemplo,
documentación técnica, procedimientos internos, manuales de usuario, contratos, informes, etc.; bases de
datos de usuarios, de clientes, de inventario y logística, etc.

- Hardware de red → se identifican un total de 9 routers y 9 switches.


PEC 2 DRC
2023-24/2

- Otro tipo de hardware → en este apartado se incluyen todos los PCs de cada una de las subredes,
incluyendo los 3 servidores de DMZ, así como todo el cableado de interconexión (también se incluiría aquí
cualquier otro tipo de equipamiento como teléfonos, portátiles, tablets, PDAs, etc.).

- Software → todas las versiones de firmware de los equipos de red, junto con los sistemas operativos y
aplicaciones instaladas en los equipos para el correcto desarrollo de las funciones de la empresa.

- Personal → cada uno de los trabajadores de la empresa (también se incluiría personal subcontratado
externo a la organización, en caso de existir).

- Instalaciones → la organización cuenta con un total de 3 sedes en las que será necesario tener en cuenta
cada uno de los elementos que formen parte de éstas (oficinas, mobiliario, rack de comunicaciones,
vehículos, etc.).

● Evaluación del riesgo:


En la página (Instituto Nacional de Ciberseguridad (INCIBE), 2017) se facilitan 6 pasos clave para realizar un
análisis de riesgos de la empresa de forma satisfactoria. En nuestro caso, apenas disponemos de información
del estado actual de la organización y la evaluación de todos los posibles escenarios daría lugar a un
documento demasiado extenso (lo que se supone que no es el objetivo de este ejercicio). Por lo tanto, se
pondrán de ejemplo algunos de los riesgos que podrían ocasionarse:

Impacto
Riesgo
(Alto/Medio/Bajo)

No contar con un sistema de


Alto
detección de amenazas

Necesidad de mantener los


sistemas y aplicaciones
actualizados a las últimas Alto
versiones de software y con
parches de seguridad

No contar con una solución de


Alto
protección de endpoints

Posible pérdida de información Alto

Facilitar el acceso a los datos


con los permisos necesarios de Medio
cada usuario

Revisión del estado y las


Medio
vulnerabilidades de la red
PEC 2 DRC
2023-24/2

Falta de concienciación del


personal sobre cuestiones de Medio
seguridad informática

En la guía (Instituto Nacional de Ciberseguridad (INCIBE), 2015), se facilita un manual útil para poder
identificar y gestionar correctamente los riesgos.

● Acciones a llevar a cabo:


Para cada uno de los riesgos identificados en el punto anterior, se indican posibles acciones mitigadoras:

Riesgo Acción correctiva/preventiva

Mediante la implantación de un
software específico para la detección de
intrusiones, se podrían identificar y
No contar con un sistema de
bloquear posibles ataques (DoS,
detección de amenazas
sniffing, man-in-the-middle, etc.)
protegiendo la red antes de ser
infectada

Actualizaciones y parches regulares:


mantener los sistemas actualizados con
Necesidad de mantener los sistemas
los últimos parches de seguridad y
y aplicaciones actualizados a las
actualizaciones de software es crucial
últimas versiones de software y con
para mitigar las vulnerabilidades
parches de seguridad
conocidas que los ciberdelincuentes
pueden aprovechar

Instalación de antivirus: permitirá


proteger los sistemas informáticos en
tiempo real contra cualquier tipo de
No contar con una solución de
software malicioso, detectando y
protección de endpoints
eliminado malware y escaneando
correos electrónicos sospechosos (entre
otras funciones)

Realización periódica de copias de


seguridad: los backups, almacenados en
ubicaciones seguras y probados
Posible pérdida de información periódicamente para su integridad,
permiten restaurar los sistemas y datos
en caso de un ataque exitoso de
ransomware
PEC 2 DRC
2023-24/2

Establecer criterios de seguridad, tanto


a través implantación de ACLs (este
paso ya se está implantando) como
Facilitar el acceso a los datos con los
mediante la instalación de un equipo
permisos necesarios de cada usuario
ISE, que permitan el control del acceso
de cada tipo de usuario a la información
correspondiente

Auditorías de seguridad de forma


periódica: mediante esta práctica, será
posible testear el grado de
Revisión del estado y las cumplimiento de las medidas de
vulnerabilidades de la red seguridad que han sido implementadas,
pero también la detección de posibles
campos de mejora o las
vulnerabilidades del sistema

Concienciación y entrenamiento del


personal: educar y formar al personal
sobre las prácticas de seguridad
Falta de concienciación del personal cibernética, incluyendo la identificación
sobre cuestiones de seguridad de correos electrónicos de phishing y el
informática reconocimiento de comportamientos
sospechosos, puede ayudar a prevenir
ataques de malware y ransomware
basados en ingeniería social

Es necesario indicar que estas son algunos de los múltiples riesgos que podrían darse en la empresa. En esta
actividad se ha decidido centrarse en los más habituales (en cuanto a seguridad informática se refiere),
omitiendo otros muchos relacionados, por ejemplo, con la infraestructura (climatización adecuada, riesgo de
incendio e inundación, acceso físico a los equipos de comunicaciones, etc.).

Ejercicio 4 (20%) - Resumen general


● Los paquetes LSR de OSPF se utilizan para confirmar la solicitud de enlace de un router vecino.
Falso. Los paquetes LSR se utilizan para solicitar registros específicos de estado de enlace de router a router.
Para establecer y mantener la adyacencia con otros routers OSPF se usan los paquetes “Hello”.

Fuente: Capítulo “1.2.2 Tipos de paquetes OSPF” del curso (Networking Academy - Cisco Systems, s.f.).

● En OSPF de área única el número de área en todos los routers debe ser obligatoriamente cero.
Falso. Es recomendable utilizar el número de área 0, especialmente por si en el futuro se amplía la red y se
decide ampliar el número de áreas (en multiárea es habitual utilizar el área 0 como troncal), pero no es
obligatorio y se puede utilizar cualquier identificador de área.

Fuente: Capítulo “2.2.1 Sintaxis del comando network” del curso (Networking Academy - Cisco Systems, s.f.).
PEC 2 DRC
2023-24/2

● La única diferencia entre OSPFv2 y OSPFv3 es que éste último permite eliminar las diferentes áreas
y trabajar con una única área.
Falso. OSPFv3 es el equivalente a OSPFv2 para intercambiar prefijos IPv6 (aunque también incluye soporte
para IPv4).

Fuente: Capítulo “1.1.6 OSPFv3” del curso (Networking Academy - Cisco Systems, s.f.).

● Las ACLs de tipo extendida interesa ponerlas siempre lo más cerca posible del destino de la
conexión.
Falso. Las ACLs de tipo extendida normalmente se aplican cerca del origen de la conexión ya que, de esta
forma, se evita que el tráfico que queremos bloquear atraviese la infraestructura de red ocupando ancho de
banda innecesariamente.

Fuente: Capítulo “4.4.3 Dónde ubicar las ACL” del curso (Networking Academy - Cisco Systems, s.f.).

● Todas las ACLs generadas en un router necesitan una primera ACE que defina la política por
defecto (Accept / Deny).
Falso. A pesar de que no se muestra en la configuración, toda ACL posee una ACE de denegación implícita al
final que bloquea todo el tráfico que no ha macheado en ninguna de las ACE anteriores. Por lo tanto, para
que una ACL cobre sentido, debe contener al menos una instrucción “permit” ya que, de lo contrario, se
denegará todo el tráfico.

Fuente: Capítulo “4.1.3 Funcionamiento de las ACL” del curso (Networking Academy - Cisco Systems, s.f.).

Referencias
Àlex Macia Pérez, E. L. (febrero de 2019). Manual de referencia de Cisco IOS. Obtenido de
https://campus.uoc.edu/annotation/b85212820f8e4e61a739a11d7b1c87b8/34941/PID_0
0262485/PID_00262485.html
Instituto Nacional de Ciberseguridad (INCIBE). (2015). Gestión de riesgos: Una guía de
aproximación para el empresario. Obtenido de
https://incibe.es/sites/default/files/contenidos/guias/doc/guia_ciberseguridad_gestion_ri
esgos_metad.pdf
Instituto Nacional de Ciberseguridad (INCIBE). (29 de 12 de 2016). Inventario de activos y gestión
de la seguridad en SCI. Obtenido de https://www.incibe.es/incibe-cert/blog/inventario-
activos-y-gestion-seguridad-sci
Instituto Nacional de Ciberseguridad (INCIBE). (16 de 01 de 2017). ¡Fácil y sencillo! Análisis de
riesgos en 6 pasos. Obtenido de https://www.incibe.es/empresas/blog/analisis-riesgos-
pasos-sencillo
Networking Academy - Cisco Systems. (s.f.). CCNAv7:Enterprise Networking, Security, and
Automation. Obtenido de https://lms.netacad.com/course/view.php?id=2221424

También podría gustarte