Sei sulla pagina 1di 29

PROYECTO REDES CASO DE ESTUDIO

JENER SANTIAGO FLOREZ PEREZ


MAGDA CATALINA LOPEZ JURADO
ALEXANDER ESCOBAR
ANDRES CAMILO CRUZ BAQUERO
JOEL SANTIAGO CUBILLOS
CRISTIAN JAVIER NAVARRO MUETE
LIZETH LOPEZ
CRISTIAN YULIAN SANTAMARÍA SANDOVAL
DIMITRI CONTRERAS

UNIVERSIDAD DE CUNDINAMARCA

FUSAGASUGA

INGENIERIA ELECTRÓNICA

2017
DESCRIPCIÓN

La Universidad está interesada en implementar su red de datos. La sede


principal está ubicada en Bogotá, y, cuenta con tres redes LAN: una para los
empleados de Administrativa, la segunda para los usuarios que están
compuestos por los docentes y los estudiantes y la tercera para ubicar los
servidores necesarios. Las necesidades de la sede de Pereira son similares,
mientras que en Girardot sólo se requieren dos redes LAN, tal como se ilustra
en la topología lógica de la siguiente gráfica.

La tarea consiste en diseñar, implementar y documentar completamente


la red de la Universidad. Además del informe formal, la Universidad desea ver
un prototipo de la red construida en un simulador, antes de su implementación
total, para confirmar que satisface sus necesidades.
FASE 1 - ESQUEMA DE DIRECCIONAMIENTO.

La Universidad solicita utilizar para su direccionamiento interno subredes


y VLSM, con direcciones privadas IPV4 de acuerdo con el RFC 1918 y con las
siguientes condiciones:

1.1 REQUISITOS DE HOST

Para calcular el número de hosts de cada una las redes, se utilizará


como base la variable X que será el resultado de sumar los tres últimos dígitos
del documento de identidad de cada uno de los estudiantes que componen el
grupo, multiplicado por diez (10). En caso de que la variable X resulte inferior a
3000, los estudiantes solicitarán al profesor la asignación de un valor para dicha
variable.

NOMBRES Y APELLIDOS ÚLTIMOS TRES DÍGITOS DOC. ID


Jener Santiago Florez Perez 413
Magda Catalina Lopez Jurado 891
Alexander Escobar 390
Andres Camilo Cruz Baqueró 080
Joel Santiago Cubillos 857
Cristian Javier Navarro Muete 300
Lizeth Lopez 836
Cristian Yulian Santamaría Sandoval 591
Dimitri Contreras 378
SUMA 4736
SUMA * 10 47360

La siguiente tabla muestra los requisitos de host para cada una de las
redes con base en la variable X

RED FACTOR TOTAL HOST


REQUERIDOS
Administrativa – Bogotá 2X 94720
Usuarios – Bogotá X 47360
Servidores - Bogotá X/500 95
Administrativa –Pereira X/2 23680
Usuarios -Pereira X/4 11840
Servidores - Pereira X/1000 47
Administrativa – Girardot X/6 7893
Usuarios – Girardot X/12 3947
Enlace Bogotá-Pereira N/A 2
Enlace Bogotá-Girardot N/A 2
Enlace Girardot-Pereira N/A 2

1.2 REQUISITOS DE DIRECCIONAMIENTO


Con base en los cálculos de requisitos de host del punto anterior, se
debe escoger una dirección de red PRIVADA apropiada para satisfacer las
necesidades de la Universidad.

DIRECCIÓN DE RED ESCOGIDA CLASE MÁSCARA DE SUBRED


10.0.0.0 A /8

 Usar la subred 172.1.1.0/30 para conectar Bogotá con el ISP.


 Usar la subred 200.21.30.0/24 para simular Internet.

Se debe crear una tabla en la que figuren todas las subredes posibles
que satisfagan los requisitos de la Universidad, utilizando un diseño VLSM. Las
subredes que no se utilizarán deben estar claramente identificadas en la tabla
como segmentos libres.

De acuerdo con lo anterior y con el diagrama lógico suministrado se


tienen las siguientes redes:

NOMBRE DE LA RED HOST DESCRIPCIÓN


REQUERIDOS
Administrativa – Bogotá 94720 Adm bta
Usuarios – Bogotá 47360 Usu bta
Servidores - Bogotá 95 Ser bta
Switches - Bogotá 24 Sw bta
Administrativa – Pereira 23680 Adm per
Usuarios – Pereira 11840 Usu per
Servidores - Pereira 47 Ser per
Switches -Pereira 24 Sw per
Administrativa – Girardot 7893 Adm gir
Usuarios – Girardot 3947 Usu gir
Switches -Girardot 16 Sw gir
Enlace Bogotá-ISP 2 Enl bta isp
Enlace Bogotá-Pereira 2 Enl bta per
Enlace Bogotá-Girardot 2 Enl bta gir
Enlace Girardot-Pereira 2 Enl gir per

Se dispone de las direcciones 10.0.0.0, de red clase A, con la cual se


deben suplir las necesidades de direccionamiento IP, utilizando para ello VLSM.
1.3 ESQUEMA DIRECCIONAMIENTO IP.

Diligenciar la siguiente tabla de acuerdo con los cálculos y resultados de VLSM (Se deben incluir
todos los segmentos de red libres):

SU NOMBRE DE SUBRED HOSTS DIRECCIÓN DIRECIÓN MÁSCARA HOST


BR REQUERID DE SUBRED BROADCAST SUBRED UTILIZA
ED OS BLES
Nº (ÚTILES)
1 Administrativa - Bogotá 94720 10.0.0.0 10.1.255.255 255.254.0.0/15 131070
2 Usuarios – Bogotá 47360 10.2.0.0 10.2.255.255 255.255.0.0/16 65534
3 Servidores - Bogotá 95 10.3.240.0 10.3.240.127 255.255.255.128/2 126
5
4 Switches - Bogotá 24 10.3.240.192 10.3.240.223 255.255.255.224/2 30
7
5 Administrativa - Pereira 23680 10.3.0.0 10.3.127.255 255.255.128.0/17 32766
6 Usuarios – Pereira 11840 10.3.128.0 10.3.191.255 255.255.192.0/18 16382
7 Servidores - Pereira 47 10.3.240.128 10.3.240.191 255.255.255.192/2 62
6
8 Switches -Pereira 24 10.3.240.224 10.3.240.255 255.255.255.224/2 30
7
9 Administrativa – Girardot 7893 10.3.192.0 10.3.223.255 255.255.224.0/19 8190
10 Usuarios - Girardot 3947 10.3.224.0 10.3.239.255 255.255.240.0/20 4094
11 Switches -Girardot 16 10.3.241.0 10.3.241.31 255.255.255.224/2 30
7
12 Enlace Bogotá-Pereira 2 172.1.1.4 172.1.1.7 255.255.255.252 2
13 Enlace Bogotá-Girardot 2 172.1.1.8 172.1.1.11 255.255.255.252 2
14 Enlace Girardot-Pereira 2 172.1.1.12 172.1.1.15 255.255.255.252 2
1.4 DIAGRAMA LÓGICO

Se debe presentar el diagrama lógico indicando todos datos pertinentes.

SE ANEXA UN PDF CON EL DISEÑO LOGICO

1.5 DESCRIPCIÓN DE ROUTERS


Para cada ubicación, incluida Internet, se requiere otro conjunto de
tablas. Estas tablas sirven de ayuda para las actividades de diseño y desarrollo
y se usan al configurar los routers. Se debe crear una tabla separada para cada
router, con las siguientes columnas:

Ubicación: Bogotá
Nombre del router: ISP
TIPO DCE CLOC NOMBRE DIRECCIÓ DIR IP MÁSCAR
Y Nº DE DTE K RED N INTERFAZ A
INTERFAZ RATE RED SUBRED
Serial 2/0 DCE 12800 ISP- 172.1.1.0 172.1.1.2 /30
0 Bogotá
Giga. Eth. N/A N/A ISP- 200.21.30. 200.21.30. /24
0/0 Internet 0 2

Ubicación: Bogotá
Nombre del router: Bogota
TIPO DC CLOC NOMBRE DIRECCIÓ DIR IP MÁSCA
Y Nº DE E K RED N INTERFAZ RA
INTERFAZ DTE RATE RED SUBRE
D
Serial 6/0 DTE N/A ISP- 172.1.1.0 172.1.1.1 /30
Bogotá
Serial 3/0 DC 12800 Bogotá- 172.1.1.8 172.1.1.10 /30
E 0 Girardot
Serial 2/0 DC 12800 Bogotá- 172.1.1.4 172.1.1.5 /30
E 0 Pereira
Giga. Eth. N/A N/A Adm_bta 10.0.0.0 10.0.0.1 /15
0/0.10
Giga. Eth. N/A N/A Usu_bta 10.2.0.0 10.2.0.1 /16
0/0.20
Giga. Eth. N/A N/A Ser_bta 10.3.240.0 10.3.240.1 /27
0/0.30
Ubicación: Girardot
Nombre del router: Girardot

TIPO DC CLOC NOMBRE DIRECCIÓ DIR IP MÁSCA


Y Nº DE E K RED N INTERFAZ RA
INTERFAZ DTE RATE RED SUBRE
D
Serial 3/0 DTE N/A Bogotá- 172.1.1.8 172.1.1.9 /30
Girardot
Serial 2/0 DC 12800 Girardot- 172.1.1.12 172.1.1.14 /30
E 0 Pereira
Giga. Eth. N/A N/A Adm_gir 10.3.192.0 10.3.192.1 /19
0/0.10
Giga. Eth. N/A N/A Usu_gir 10.3.244.0 10.3.244.1 /20
0/0.20

Ubicación: Pereira
Nombre del router: Pereira
TIPO DC CLOC NOMBRE DIRECCIÓ DIR IP MÁSCAR
Y Nº DE E K RED N INTERFAZ A
INTERFA DTE RATE RED SUBRED
Z
Serial 3/0 DTE N/A Bogotá – 172.1.1.4 172.1.1.6 /30
Pereira
Serial 2/0 DTE N/A Girardot - 172.1.1.12 172.1.1.13 /30
Pereira
Giga. Eth. N/A N/A Adm_per 10.3.0.0 10.3.0.1 /17
0/0.10
Giga. Eth. N/A N/A Usu_per 10.3.128.0 10.3.128.1 /18
0/0.20
Giga. Eth. N/A N/A Ser_per 10.3.240.12 10.3.240.129 /26
0/0.30 8

FASE 2 – ENRUTAMIENTO Y CONFIGURACIÓN BÁSICA DE ROUTERS

La Universidad desea que se recomiende un protocolo de enrutamiento


para la red, que sea el más adecuado para las condiciones que se tienen. Las
alternativas y propiedades del posible protocolo de enrutamiento se deben
identificar y describir, haciendo un resumen de las principales características,
ventajas y desventajas de los protocolos conocidos, así como un marco teórico
de enrutamiento. Posteriormente se hará un análisis y se recomendará el
protocolo a ser utilizado. El resultado de los análisis de cada uno de los
protocolos, se debe resumir en una tabla asignando un valor numérico o
cualitativo a cada una de las propiedades, por ejemplo, 0 a 5. Se realiza luego
una recomendación y la matriz de decisiones se presenta a la Universidad.

EIGRP (Enhanced Interior Gateway Routing Protocol).

Es un protocolo de encaminamiento vector distancia avanzado, propiedad


de Cisco Systems, que ofrece lo mejor de los algoritmos de vector de
distancias y del estado de enlace. Se considera un protocolo avanzado que
se basa en las características normalmente asociadas con los protocolos
del estado de enlace. Algunas de las mejores funciones de OSPF, como las
actualizaciones parciales y la detección de vecinos, se usan de forma
similar con EIGRP. Aunque no garantiza el uso de la mejor ruta, es bastante
usado porque EIGRP es algo más fácil de configurar que OSPF. EIGRP
mejora las propiedades de convergencia y opera con mayor eficiencia que
IGRP. Esto permite que una red tenga una arquitectura mejorada y pueda
mantener las inversiones actuales en IGRP.

Características

Las características más relevantes de EIGRP son:

1- Protocolo de transporte confiable (RTP)

2- Actualizaciones Limitadas

3- Algoritmo de actualización por difusión (DUAL)

4- Establecimiento por adyacencias

5- Tablas de vecinos y topología

Los routers EIGRP mantienen información de ruta y topología a disposición


en la RAM, para que puedan reaccionar rápidamente ante los cambios. Al
igual que OSPF, EIGRP guarda esta información en varias tablas y bases
de datos.
Las rutas reciben un estado y se pueden rotular para proporcionar
información adicional de utilidad.

EIGRP mantiene las siguientes tres tablas:

Tabla de vecinos: Cada router EIGRP mantiene una tabla de vecinos que
enumera a los routers adyacentes. Esta tabla puede compararse con la
base de datos de adyacencia utilizada por OSPF. Existe una tabla de
vecinos por cada protocolo que admite EIGRP.

Tabla de topología: La tabla de topología se compone de todas las tablas


de encaminamiento EIGRP recibidas de los vecinos. EIGRP toma la
información proporcionada en la tabla de vecinos y la tabla de topología y
calcula las rutas de menor costo hacia cada destino. EIGRP rastrea esta
información para que los routers EIGRP puedan identificar y conmutar a
rutas alternativas rápidamente. La información que el router recibe de los
vecinos se utiliza para determinar la ruta del sucesor, que es el término
utilizado para identificar la ruta principal o la mejor. Esta información
también se introduce a la tabla de topología. Los routers EIGRP mantienen
una tabla de topología por cada protocolo configurado de red (como IP, IPv6
o IPX). La tabla de enrutamiento mantiene las rutas que se aprenden de
forma dinámica.

Tabla de encaminamiento: La tabla de encaminamiento EIGRP contiene


las mejores rutas hacia un destino. Esta información se recupera de la tabla
de topología. Los routers EIGRP mantienen una tabla de encaminamiento
por cada protocolo de red.

Ventajas

 Soporta IPv6.
 Se considera classless, como RIPv2 y OSPF.
 Soporta VLSM y CIDR.
 Soporta sumarización y redes discontiguas.
 Descubrimiento eficiente de vecinos.
 Se comunica con Reliable Transport Protocol.

Desventajas
 Por defecto, EIGRP sumariza las rutas en el borde de la red
principal, similar al RIP.
 Como es un protocolo propietario de Cisco, otros enrutadores de
diferentes marcas no están habilitados para utilizar EIGRP

BGP (Border Gateway Protocol)

El protocolo de puerta de enlace de frontera1 o BGP (del inglés Border


Gateway Protocol) es un protocolo mediante el cual se intercambia
información de encaminamiento entre sistemas autónomos. Por ejemplo,
los proveedores de servicio registrados en Internet suelen componerse de
varios sistemas autónomos y para este caso es necesario un protocolo
como BGP.

Entre los sistemas autónomos de los ISP se intercambian sus tablas de


rutas a través del protocolo BGP. Este intercambio de información de
encaminamiento se hace entre los routers externos de cada sistema
autónomo, los cuales deben ser compatibles con BGP. Se trata del
protocolo más utilizado para redes con intención de configurar un protocolo
de puerta de enlace exterior (Exterior Gateway Protocol).

El protocolo de puerta de enlace de frontera (BGP) es un ejemplo de


protocolo de puerta de enlace exterior (EGP). BGP intercambia información
de encaminamiento entre sistemas autónomos a la vez que garantiza una
elección de rutas libres de bucles. Es el protocolo principal de publicación
de rutas utilizado por las compañías más importantes de ISP en Internet.
BGP4 es la primera versión que admite encaminamiento entre dominios sin
clase (CIDR) y agregado de rutas. A diferencia de los protocolos de puerta
de enlace internos (IGP), como RIP, OSPF y EIGRP, no usa métricas como
número de saltos, ancho de banda o retardo. En cambio, BGP toma
decisiones de encaminamiento basándose en políticas de la red, o reglas
que utilizan varios atributos de ruta BGP.

BGP realiza tres tipos de encaminamiento:

Enrutamiento interautónomo.
Enrutamiento intrautónomo.
Enrutamiento de paso (o tránsito).

Tipos de mensajes

Existen cuatro tipos de mensajes BGP que son los siguientes:


OPEN: se utiliza para el establecimiento de una sesión BGP una vez haya
sido establecida la conexión TCP. Se suelen negociar ciertos parámetros
que caractericen a esa sesión. Por ejemplo, es muy posible que los
miembros de la sesión no tengan la misma versión de BGP por lo que es
importante indicar el número de versión en este mensaje.

UPDATE: es un mensaje de actualización, de mucha importancia en las


operaciones de BGP ya que contiene los anuncios de nuevos prefijos. Se
generarán mensajes de actualización cada vez que se determine una nueva
mejor ruta para cierto destino o haya una modificación sobre alguna
existente.

KEEPALIVE: una vez que la sesión BGP está activa se envía


periódicamente un mensaje para mantener viva la conexión o KEEPALIVE
para confirmar que el otro extremo sigue estando activo en la sesión BGP.
Generalmente se acuerda un tiempo máximo de espera durante el
intercambio inicial de mensajes OPEN. El KEEPALIVE suele ser
aproximadamente una vez cada tercio del tiempo de espera, pero no más
de una vez cada segundo. Los mensajes KEEPALIVE no se deben generar
si el tiempo de espera es cero ya que en ese caso se entiende que la
sesión es completamente fiable.

NOTIFICATION: se envía al cerrar una sesión BGP y esto sucede cuando


ocurre algún error que requiera el cierre de la misma. De modo que es un
mensaje que permite informar nada.

RIP (Routing Information Protocol)

El Protocolo de Información de Encaminamiento, Routing Information Protocol


(RIP), es un protocolo de puerta de enlace interna o interior (Interior Gateway
Protocol, IGP) utilizado por los routers o encaminadores para intercambiar
información acerca de redes del Internet Protocol (IP) a las que se encuentran
conectados. Su algoritmo de encaminamiento está basado en el vector de
distancia, ya que calcula la métrica o ruta más corta posible hasta el destino a
partir del número de "saltos" o equipos intermedios que los paquetes IP deben
atravesar. El límite máximo de saltos en RIP es de 15, de forma que al llegar a 16
se considera una ruta como inalcanzable o no deseable. A diferencia de otros
protocolos, RIP es un protocolo libre es decir que puede ser usado por diferentes
routers y no únicamente por un solo propietario con uno como es el caso de
EIGRP que es de Cisco Systems.
Temporizadores

RIP utiliza unos temporizadores para que apoyen su funcionamiento, las cuales
son:

Temporizador periódico: este controla la publicación de los mensajes de


actualización regulares. Se debe ajustar el temporizador a 30 s, esto es para evitar
se sincronicen y así sobrecargar el Internet si los routers se actualizan de forma
simultánea. Cada router posee un temporizar periódico que se establece al azar a
un número que va de 25 a 35 que va en decremento hasta llegar a 0 y envía un
mensaje de actualización.
Temporizador de caducidad (o timer de invalidación): establece cuánto tiempo
puede estar una ruta en la tabla de ruteo sin ser actualizada. Cuando un router
recibe la información actualizada para una ruta, el temporizador establece 180 s
para esa ruta en particular. Si pasados los 180 s asignados no se actualiza la ruta,
se considera que está caducada y el número de saltos se pone 16 considerándose
una ruta inalcanzable.
Temporizador de Colección de Basura: este temporizador controla el tiempo que
pasa entre que una ruta es invalidada (o marcada como inalcanzable) y el tiempo
que pasa hasta que se elimina la entrada de la tabla de ruteo. El valor
predeterminado es de 240 s. Esto es 60 s más largo que el temporizador de
caducidad. Entonces, por 60 s el router estará anunciando sobre la ruta
inalcanzable a todos sus vecinos. El valor del temporizador debe setearse en un
valor mayor que el temporizador de caducidad.

Versiones
En la actualidad existen dos versiones de RIP: RIPv1, RIPv2. También existe la
versión RIpng, para IPv6.

RIPv1[editar]
La definición original, recogida en el RFC 1058, define RIP como un protocolo de
enrutamiento con clase, es decir, basado en las clases de las direcciones IP. Por
tanto, RIPv1 no soporta máscaras de tamaño variable (VLSM) ni direccionamiento
sin clase (CIDR). Esto implica que las redes tratadas por este protocolo deben
tener la máscara de red predefinida para su clase de dirección IP, lo que resulta
poco eficiente. Además, RIPv1 tampoco incluye ningún mecanismo de
autentificación de los mensajes, haciéndolo vulnerable a ataques.

Utiliza UDP para enviar sus mensajes a través del puerto 520.1

RIPv2[editar]
Debido a las limitaciones de la versión 1, se desarrolla RIPv2 en 1993,2 y se
estandariza finalmente en 1998.3 Esta versión soporta subredes, permitiendo así
CIDR y VLSM. Además, para tener retrocompatibilidad con RIPv1, se mantuvo la
limitación de 15 saltos.

Se agregó una característica de "interruptor de compatibilidad"3 para permitir


ajustes de interoperabilidad más precisos. RIPv2 soporta autenticación, utilizando
uno de los siguientes mecanismos: no autentificación, autentificación mediante
contraseña, y autentificación mediante contraseña codificada mediante MD5
(desarrollado por Ronald Rivest en 1997).

2.1 CONDICIONES DE ENRUTAMIENTO

Se debe planificar el enrutamiento utilizando el protocolo recomendado,


reforzado con rutas estáticas de backup. En el router Bogotá se debe
implementar lo necesario para que la ruta de salida a Internet sea redistribuida.

Para la realización del caso de estudio planteado se decide implementar el


protocolo de enrutamiento EIGRP, para lo cual se deben tener en cuenta los
siguientes pasos para su correcta configuración.

Router (config)#router eigrp 10 (ID: 10)


Router (config-router)#network [IP DE RED]
Router (config-router)#no auto-summary
Router (config-router)#exit

Ejemplo (PEREIRA)
2.2 CONFIGURACIÓN BÁSICA DE ROUTERS

Se debe garantizar la conectividad entre todos los dispositivos, así como,


la salida a Internet. La configuración de los dispositivos se entregará en
archivos de texto plano capturados: un archivo para cada router. Se debe incluir
dentro de la configuración, además de los comandos propios de enrutamiento,
los siguientes:

 Contraseña de acceso a consola, terminales virtuales y modo


privilegiado.
 Servicio de encripción de passwords
 Deshabilitar la búsqueda DNS

 Configurar tiempo de espera de 5 minutos para consola y vty

 Mensaje del día

 Descripción de interfaces
 Sincronización de mensajes de consola

 Habilitar historial de comandos para que guarde los últimos 200

FASE 3 – CONMUTACIÓN

La Universidad en la actualidad cuenta con el número de switches en


cada sede mostrados en el diagrama de la topología (Bogotá 3, Pereira 3 y
Giradot 2). Se creé que en el futuro el número de estos dispositivos crecerá, por
lo que se solicita designar un segmento de red para cada ciudad, con el
propósito de asignar direcciones a cada switch y de esta manera facilitar su
administración remota. A continuación se muestra la cantidad de dispositivos.
El factor X corresponde al último dígito del documento de identidad del último
participante del grupo:

 Bogotá: 3X
 Pereira: 3X
 Girardot: 2X

De las direcciones de red libres, seleccionar 3 nuevas redes que se


utilizarán para asignarlas a los switches de cada una de las sedes.

RED HOSTS DIRECCIÓ DIRECIÓN MÁSCAR HOST


REQUERID N DE RED BROADCA A UTILIZABLE
OS ST SUBRED S
(ÚTILES)
Switche 24 10.3.240.19 10.3.240.22 255.255.2 30
s 2 3 55.224
Bogotá
Switche 24 10.3.240.22 10.3.240.25 255.255.2 30
s Pereira 4 5 55.224
Switche 16 10.3.241.0 10.3.241.31 255.255.2 30
s 55.224
Girardot

3.1 CONFIGURACIÓN BÁSICA DE SWITCHES

La configuración de los dispositivos se entregará en archivos de texto


plano capturados: un archivo para cada switch. Se debe incluir dentro de la
configuración, además de los comandos propios de conmutación, los
siguientes:

 Contraseña de acceso a consola, terminales virtuales y modo


privilegiado.
 Servicio de encriptación de contraseñas
 Deshabilitar la búsqueda DNS
 Configurar tiempo de espera de 5 minutos para consola y terminales vty
 Mensaje del día
 Sincronización de mensajes de consola
 Habilitar historial de comandos para que guarde los últimos 200

Comandos

3.2 CONFIGURACIÓN DE LAN VIRTUALES


Teniendo en cuenta que habrá personal de cada una de las sedes
ubicado en los diferentes pisos de la edificación, se deben configurar las VLAN
necesarias en cada uno de los switches: Administrativa, Usuarios y Servidores.
La universidad desea que se utilice VTP con el fin de facilitar la administración
de las VLAN, para lo cual, se configurará uno de los switches como servidor y
los demás como clientes. Se debe suministrar la siguiente información
relacionada con la configuración de VTP:

Configuración VTP
SEDE SWITCH SWITCHE DOMINIO VERSIÓN CONTRASE
SERVIDOR S VTP VTP ÑA VTP
CLIENTE
Bogotá Piso1_bta Piso2_bta Bogota 2 cisco
Piso3_bta
Pereira Piso1_per Piso2_per Pereira 2 cisco
Piso3_per
Girardot Piso1_gir Piso2_gir Girardot 2 cisco

Comandos Para el Administrador es decir El Servidor Principal

Comandos Para el Administrador es decir El Cliente

3.3 REDUNDANCIA FÍSICA

La Universidad desea que las redes LAN sean diseñadas con cierta
seguridad, utilizando para ello redundancia de enlaces y el protocolo STP. Se
debe asegurar, mediante la configuración de STP, que el switch ubicado en el
último piso de cada edificación sea el switch raíz. Se debe incluir una
explicación detallada de las tareas de configuración para lograr esto.

Comando de STP.

STP su función es la de gestionar la presencia de bucles en topologías de red


debido a la existencia de enlaces redundantes (necesarios en muchos casos
para garantizar la disponibilidad de las conexiones). El protocolo permite a los
dispositivos de interconexión activar o desactivar automáticamente los enlaces
de conexión, de forma que se garantice la eliminación de bucles.

3.4 DETALLES DE CONFIGURACIÓN DE SWITCHES

En el modelo de simulación, se deben configurar al menos dos


dispositivos en cada VLAN, indicando en una tabla todos los detalles de
configuración necesarios, tales como, dirección IP, máscara de subred y
Gateway por defecto.

Se deben preparar además, tablas para cada una de las sedes que
documenten las principales características de configuración asignadas a los
switches:
Nomb Modelo Nº P Dir Ip Gateway VTP STP Ptos Ptos
re Pt is Mo Raíz Trun VLA
Switc os o do k N
h

Piso1 WS- 10 1 172.18.0. 172.18.0. serv Prima 0/1, 1/1,


_Gir CSwitch- 2 1 idor rio 8/1, 2/1
PT 9/1
Piso2 WS- 10 2 172.18.0. 172.18.0. Clie Secu 8/1, 0/1,
_Gir CSwitch- 3 1 nte ndari 9/1 1/1
PT o
Piso1 WS- 10 1 172.17.0. 172.12.0. serv Prima 0/1, 1/1,
_Per CSwitch- 2 1 idor rio 6/1, 2/1,
PT 7/1, 3/1
8/1,
9/1
Piso2 WS- 10 2 172.17.0. 172.12.0. Clie Secu 6/1, 0/1,
_ Per CSwitch- 3 1 nte ndari 7/1, 1/1
PT o 8/1,
9/1
Piso3 WS- 10 3 172.17.0. 172.12.0. clie Secu 6/1, 0/1
_ Per CSwitch- 4 1 nte ndari 7/1,
PT o 8/1,
9/1
Piso1 WS- 10 1 172.16.0. 172.12.0. serv Prima 0/1 1/1
_Bog CSwitch- 2 1 idor rio 6/1, 2/1
PT 7/1,
8/1,
9/1
Piso2 WS- 10 2 172.16.0. 172.12.0. Clie Secu 6/1, 0/1,
_ Bog CSwitch- 3 1 nte ndari 7/1, 1/1
PT o 8/1,
9/1
Piso3 WS- 10 3 172.16.0. 172.12.0. clie Secu 6/1, 0/1,
_ Bog CSwitch- 4 1 nte ndari 7/1, 1/1,
PT o 8/1, 2/1,
9/1 3/1,
4/1

3.5 SEGURIDAD DE PUERTO


En cada una de las sedes se debe instalar un servidor http y se desea
que la dirección MAC de éste sea considerada la única segura y que cualquier
otra, envíe al puerto al modo RESTRICT. Se solicita también que el puerto
donde se conectará el servidor no participe en el proceso STP.

Comandos Sw Primer piso Pereira

3.6 DOT1Q Y SUB INTERFACES

La universidad desea que se utilicen sub interfaces en los routers de


cada sede para soportar la comunicación entre las diferentes VLANS, por lo que
la configuración de los routers debe ajustarse a este requerimiento. En todas las
sedes se utilizará la interface FastEthernet 0/0 para tal fin.

Comandos Router Pereira


FASE 4 - SEGURIDAD

4.1 SEGURIDAD

La universidad desea tener cierto grado de protección, especialmente lo


relacionado con el acceso a los servidores ubicados en cada una de las sedes y
también desea restringir el uso de ciertos recursos a los usuarios de cada una
de las redes. Para la implementación de seguridad se deben tener en cuenta
los siguientes aspectos:

4.1.1 En la red LAN de servidores de la sede de Bogotá existen los


siguientes servidores:

Un servidor FTP con los archivos fuente de todas las aplicaciones


utilizadas en la Universidad. Por ejemplo, instaladores de
Windows, Office, aplicativo de contabilidad, etc. Ese servidor está
identificado y configurado con la segunda dirección IP disponible
en el segmento.
Un servidor de bases de datos MySQL, identificado y configurado
con la tercera dirección IP disponible en el segmento.

Un servidor HTTP, identificado y configurado con la cuarta


dirección IP disponible en el segmento.

Un servidor TFTP para almacenar las configuraciones y IOS de


todos los dispositivos de Red de la institución, identificado y
configurado con la quinta dirección IP disponible en el segmento.
LAN BOGOTA

4.1.2 En las sedes de Pereira y Girardot existe un servidor HTTP


identificado con las segundas direcciones IP disponibles en cada
segmento.
Servidor Ciudad Servicios Dirección IP Puertos
Ubicación
http - Gir Girardot http 172.18.8.2 Giga. Eth. 0/0
http – Per Pereira http 172.17.64.2 Giga. Eth. 0/0
ftp – Bog Bogotá ftp 172.16.224.2 Giga. Eth. 0/0
MySQL – Bog Bogotá Bases de 172.16.224.3 Giga. Eth. 0/0
datos
http – Bog Bogotá http 172.16.224.4 Giga. Eth. 0/0
tftp - Bog Bogotá tftp 172.16.224.5 Giga. Eth. 0/0
ftp – ISP2 Bogotá ftp 192.168.1.3 Giga. Eth. 0/0
http – ISP2 Bogotá http 192.168.1.4 Giga. Eth. 0/0
dns – ISP2 Bogotá dns 192.168.1.5 Giga. Eth. 0/0
http – ISP3 Bogotá http 192.168.0.2 Giga. Eth. 0/0

4. 2 ESPECIFICACIONES DE SEGURIDAD

La dirección de la Universidad desea que se implementen las siguientes


políticas.

4.2.1 El servidor HTTP de la sede Bogotá podrá ser accedido desde


cualquier ubicación.

4.2.2 Los servidores HTTP de las sedes de Pereira y Girardot sólo


podrán ser vistos por cualquier usuario dentro de la organización.

4.2.3 Los servidores FTP y TFTP de la sede Bogotá sólo podrán ser
accedido por los computadores de los administradores de cada
sede, que estarán identificados con la siguiente dirección IP
disponible en el segmento de Servidores de cada sede. Pc dentro
de servidores

4.2.4 La universidad cuenta con un proveedor de software, identificado


con la dirección IP 200.21.30.31/24 que tendrá acceso al servidor
FTP.

4.2.5 A todos los usuarios de la Universidad se les permite el acceso a


servicios FTP y HTTP externos.
4.2.6 Al servidor de bases de datos MySQL sólo tendrán acceso los
dispositivos ubicados en los segmentos de servidores de cada
sede.
Este punto se realiza con ACL.

Comandos ACL

FASE 5 – DHCP

Los routers de cada una de las sedes prestarán los servicios de DHCP
para cada uno de los segmentos locales. Dentro de los parámetros de
configuración se deben incluir: el nombre de dominio, el Gateway por defeco y
el servidor DNS. Se deben excluir del proceso DHCP a las primeras diez
direcciones disponibles, las cuales están asignadas a dispositivos de red y son
configuradas manualmente.

Se debe diligenciar la siguiente tabla para cada una de las sedes.

Sede: Bogota

Nombre Dirección de Direcciones Gateway por Servidor


del Pool Red / Máscara Excluidas defecto DNS
DHCP
Vlan10 172.16.0.0 172.16.0.1 – 172.16.0.1 192.168.1.5
255.255.128.0 172.16.0.20
Vlan20 172.16.128.0 172.16.128.1- 172.16.128.1 192.168.1.5
255.255.192.0 172.16.128.20
Vlan30 172.16.224.0 172.16.224.1- 172.16.224.1 192.168.1.5
255.255.255.22 172.16.224.20
4

Sede: Pereira

Nombre Dirección de Direcciones Gateway por Servidor


del Pool Red / Máscara Excluidas defecto DNS
DHCP
Vlan10 172.17.0.0 172.17.0.1 – 172.17.0.1 192.168.1.5
255.255.124.0 172.17.0.20
Vlan20 172.17.32.0 172.17.32.1- 172.17.32.1 192.168.1.5
255.255.240.0 172.17.32.20
Vlan30 172.17.64.0 172.17.64.1- 172.17.64.1 192.168.1.5
255.255.255.22 172.17.64.20
4

Sede: Girardot

Nombre Dirección de Direcciones Gateway por Servidor


del Pool Red / Máscara Excluidas defecto DNS
DHCP
Vlan10 172.18.0.0 172.18.0.1 – 172.18.0.1 192.168.1.5
255.255.248.0 172.18.0.20
Vlan20 172.18.8.0 172.18.8.1- 172.18.8.1 192.168.1.5
255.255.252.0 172.18.8.20
DOCUMENTACIÓN

El caso de estudio debe presentarse de acuerdo con las normas de la


Universidad para trabajos escritos y debe contener los siguientes documentos:

1. Archivo en Word con el desarrollo de las fases propuestas


2. Diagrama de red con el esquema de direccionamiento
3. Archivos de texto plano con la configuración para cada uno de los
dispositivos
4. Archivo con la implementación del modelo en el simulador

Potrebbero piacerti anche