Diseño de La Arquitectura de Red Basado en La Seguridad, Monitorizacion y Alta Disponibilidad - 2015

UNIVERSIDAD
AUTONOMA DE MADRID
ESCUELA POLITECNICA SUPERIOR
TRABAJO DE FIN DE GRADO

DISEÑO DE LA ARQUITECTURA DE RED BASADO EN LA
SEGURIDAD,
MONITORIZACIÓN Y ALTA DISPONIBILIDAD DEL
CONSULADO GENERAL DEL REINO DE MARRUECOS
MEHDI AMARTI CHERTI

([email protected])
JUL 2015
DISEÑO DE LA ARQUITECTURA DE RED BASADO EN LA
SEGURIDAD,
MONITORIZACIÓN Y ALTA DISPONIBILIDAD DEL
CONSULADO GENERAL DEL REINO DE MARRUECOS
AUTOR: Mehdi Amarti Cherti

TUTOR: Juan Antonio Andrés Sáez
PONENTE: Jorge E. López de Vergara Méndez
High Performance Computing and Networking
Dpto. de Tecnologı́a Electrónica y de las Comunicaciones
Escuela Politécnica Superior
Universidad Autónoma de Madrid
JUL 2015
Diseño de la arquitectura de red del Consulado General del Reino de Marruecos
Resumen — A lo largo de estas últimas décadas se ha podido observar que la conexión

entre múltiples puntos alrededor del mundo es crucial para transportar información. Esta infor-
mación pueden ser movimientos de fondos entre bancos, transmisión de información confidencial
entre paı́ses o los paquetes que generan una videollamada. Debido a ello el estudio de las redes
se ha convertido en una prioridad a la hora de la creación de una nueva sede, oficina o empresa.
Estos estudios están encaminados según las necesidades de cada institución. La escalabilidad,
disponibilidad, redundancia, seguridad y monitorización son factores a tener en cuenta a la hora
de la creación de cualquier red. Existe una frontera entre distintas redes tal como la separación
entre la red interna y el exterior. Por lo tanto , la forma de entender la estructuración de ambas
es diferente. Por consiguiente , realizaremos una arquitectura de red adaptada a las necesidades
del Consulado General del Reino de Marruecos, cumpliendo con los requisitos recogidos a lo
largo del estudio y las reuniones realizadas previas a la realización de este documento. Daremos
conectividad a los puestos de cada departamento garantizando el servicio y acceso a las aplica-
ciones externas alojadas en el Ministerio de Rabat. Primero se estudiará la red para descubrir
con que dispositivos se trabaja y como interactúan entre ellos. Teniendo toda esa información,
se analizarán las posibles soluciones acordes a las necesidades. Se desarrollará una solución ópti-
ma para cada red diferente. Implantaremos las configuraciones necesarias para la creación de
la arquitectura de red ası́ como la integración de los dispositivos y funcionamiento correcto del
modelo.
Palabras Clave — Redundancia, Alta disponibilidad, Monitorización, Seguridad, Centro
de Datos.
I
Abstract — During the last decades, we are seeing that connection among di↵erent points
of the world is crucial for transferring information purposes. Specifically, this pertains to I
am talking about money movement between banks, confidential information transfer between
countries, or even a data package of a video call. For this reason, network set-up has become
a priority in alongside the creation of a company. This study follow di↵erent rules based on
the needs of each institution. Scalability, availability, redundancy, security, and monitoring are
factors to consider when you required to set up any kind of network. There is a border between
di↵erent networks such as global and local. Therefore, the understanding of both structures is
di↵erent. Consequently, we will build an architecture adapted to the needs of the Consulate
of the Kingdom of Morocco meeting the requirements collected during the study and meetings
held during the completion of this document. We will give connectivity to desks of each depart-
ment, which will provide the service and access to external applications hosted in some Rabat’s
ministries. We will look for the type of the network with the knowledge of what kind of devices
we will work with and how they interact with each other. With this information, we will analyze
di↵erent solutions according to the circumstances and will apply the optimal solution for each
di↵erent network. We will implement the main configuration to create the network architectu-
re, and through simulations we will check the integration of devices and proper functioning of
model configurations.
Index Terms — Redundancy, High availability, Monitoring, Security, Data center.
II
Agradecimientos
III
IV
Índice general
1 Introducción 1
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Fases de realización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Estado del arte 3

2.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Centro de procesamiento de datos . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Trabajo previo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Análisis del problema 7

3.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1 Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2 Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 Desarrollo de la solución 11
4.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 División en módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1 Red Interna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.2 Red DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.3 Red de Invitados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5 Implementación de la red 25
5.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 División en módulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.1 Intermedio DMZ-LAN (lı́neas de operadores) . . . . . . . . . . . . . . . . 27
5.2.2 Red interna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.3 Red de Invitados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6 Integración 41
6.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2 Caracterı́sticas técnicas del cableado de datos . . . . . . . . . . . . . . . . . . . . 41
6.2.1 Cableado de datos cobre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2.2 Cableado de fibra óptica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.3 Monitorización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.4 Arquitectura global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.5 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
V
7 Conclusiones y Trabajo futuro 49

7.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.2 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.3 Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
A Nomenclatura de Cables, Latiguillos y Switches 53

A.1 Caracterı́sticas generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.2 Nomenclatura de Cables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.2.1 Códigos de categorı́a de los cables . . . . . . . . . . . . . . . . . . . . . . 53
A.2.2 Cable de planta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.2.3 Cable inter-salas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.2.4 Cable Local (Hub/Switch) en Despacho o Mesa . . . . . . . . . . . . . . . 55
A.3 Etiquetas en Latiguillos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
B Gestor de Turnos 59
B.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
B.2 Descripción general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
B.3 Motor, configuración y dispensación asistida (Servidor) . . . . . . . . . . . . . . . 61
B.4 Teclado(Cliente) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
B.5 Supervisión y estadı́sticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
B.6 Requisitos técnicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
C Configuraciones de los Switches 65

C.1 Core Cisco WS-C3750X-24T-S . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
C.2 Planta 1 Cisco Catalyst 2960S-24TS-L . . . . . . . . . . . . . . . . . . . . . . . . 73
VI ÍNDICE GENERAL
Índice de cuadros
VII
VIII ÍNDICE DE CUADROS

Índice de figuras
4.1 Diagrama lógico de red global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 Disponibilidad del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Relación de disponibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4 Diseño conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.5 Cisco C3750X de core en Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6 Redundancia Servidor AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.7 Redundancia Servidor AA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.8 Diagrama lógico Metrolan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.9 Redundancia WAN a través de dos operadores . . . . . . . . . . . . . . . . . . . 19
4.10 Redundancia WAN a través de dos operadores con switch intermedio . . . . . . . 19
4.11 Componentes infraestructura WIFI . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.12 Reglas de acceso WIFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.13 Netscreen Security Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.14 Componentes de la infraestructura de comunicaciones interna . . . . . . . . . . . 23
4.15 Gestión de los componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.16 Diagrama lógico red de invitados . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1 Arquitectura de Red estándar TIA-942 . . . . . . . . . . . . . . . . . . . . . . . 26

5.2 VLAN y Direccionamiento IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3 Mapa global de VLANes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4 Asignaciones de IPs fijas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.5 Trunking Switch 3750X Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.6 Trunking Switch 2960 Planta 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.9 Conexiones CORE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.10 Conexion de CORE con switches de Planta . . . . . . . . . . . . . . . . . . . . . 34
5.11 Conexión de servidores con el CORE . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.12 Funcionamiento de un Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.13 Diagrama lógico CORE red de Invitados . . . . . . . . . . . . . . . . . . . . . . . 38
6.1 Descripcion producto Kiwi Syslog Free Edition . . . . . . . . . . . . . . . . . . . 43

6.2 Configuración script Teraterm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.3 Tipo apertura TeraTerm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.4 Ilustración del Programa FreePing . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.5 Mapa de conexiones de Core con Dispositivos . . . . . . . . . . . . . . . . . . . . 46
6.6 Mapa de la Arquitectura Global . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.1 Eliminación MetroLan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.1 Tabla categorı́as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

A.2 Nomenclatura Cable de planta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.3 Tabla Cable de planta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
IX
A.4 Nomenclatura Cable de Inter-salas . . . . . . . . . . . . . . . . . . . . . . . . . . 55

A.5 Tabla Cable de Inter-salas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.6 Nomenclatura Cable Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A.7 Tabla Cable Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
B.1 Visión general Gestor de turno . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

B.2 Diagrama gestor de turno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
B.3 Motor gestor de turno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
B.4 Software teclado Gestor de turno . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
B.5 Especificaciones teclado Gestor de turno . . . . . . . . . . . . . . . . . . . . . . . 63
B.6 Estadı́sticas Gestor de turno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
C.1 Configuración switch Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

C.8 Configuración switch Planta 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
X ÍNDICE DE FIGURAS
Glosario
Etherchannel Son grupos de enlaces Ethernet que se comportan como un único enlace.
CGRM Consulado General del Reino de Marruecos
HA Protocolo de diseño del sistema y su implementación asociada que asegura un cierto grado
absoluto de continuidad operacional durante un perı́odo de medición dado.
SPOF Es un componente de un sistema que tras un fallo en su funcionamiento ocasiona un fallo

global en el sistema completo, dejándolo inoperante.
MTTF Mide el tiempo medio entre fallo con la suposición de un modelo en que el sistema fallido
no se repara.
STP Protocolo que gestiona la presencia de bucles en topologı́as de red debido a la existencia
de enlaces redundantes.
Multilayer Un switch multilayer, además de funcionar como un switch (Capa2), realiza funciones de
capa 3.
TIA-942 Estándar que proporciona una serie de recomendaciones y directrices (guidelines) para la
instalación de un centro de datos.
Backbone El término se refiere al cableado troncal o subsistema vertical en una instalación de red
de área local que sigue la normativa de cableado estructurado.
CPD Centro de procesamiento de datos.
DMZ Red demilitarizada.
XI
1
Introducción
El Consulado General del Reino de Marruecos abastece a más de 400 personas diariamente en
cuanto a tramitación de diversos documentos. Las personas que visitan el Consulado no solo
pertenecen a Madrid. Es el consulado que corresponde a las provincias de Madrid, Zamora,
Valladolid, Salamanca, Segovia, Soria, Guadalajara, Toledo, Cuenca, Ciudad Real y Albacete.
Por lo tanto, es un núcleo muy importante que debe brindar diversos servicios a más de 200.000
personas que pertenecen a la comunidad marroquı́ censadas en las provincias colindantes. Nos
encontramos muchas historias de familias, las cuales deben de recorrer más de 100 km para una
tramitación administrativa. Esto les supone la pérdida de su jornal, traer a sus hijos consigo
porque no tienen donde dejarlos o no les da tiempo a recogerlos del colegio, etc. No es posible
decirles a esas personas que vuelvan mañana porque no ha sido posible realizar su tramitación.
Por ello, el garantizar que el servicio FUNCIONE de manera ininterrumpida es vital. Con
esta motivación me he propuesto realizar este proyecto para subsanar las deficiencias que pueda
tener el sistema. Tan importante es mantener la continuidad del servicio como localizar un fallo
y poder corregirlo con un tiempo que se considere aceptable.
1.1 Objetivos
A lo largo de este trabajo se tratará de crear una arquitectura de red robusta que sea capaz de
garantizar el servicio de una institución pública de forma eficiente.
1
1.2 Fases de realización

Para el progreso de este proyecto se han establecido una serie de fases. Con ello aseguramos que
no se deja nada en el tintero y se presta la información de un modo ordenado. De esta manera
nos podremos encaminar hacia la realización del proyecto de manera satisfactoria.
La primera de todas ellas fue la investigación del estado del arte, para poder tomar ideas
sobre las tecnologı́as ya existentes y ası́ cubrir nuestra necesidad y adaptarlo a la arquitectura
que procede.
La segunda fase del proyecto trató sobre la investigación y el análisis del problema ası́ co-
mo de los requisitos, tanto funcionales como no funcionales, para cada uno de los tipos de red
divididos en módulos.
La tercera fase del proyecto constó de la implementación del sistema con la información
recabada del capitulo anterior. Esto es, materializar las caracterı́sticas de cada modulo de red
en soluciones a tomar.
En este último punto el esfuerzo invertido en el proyecto se dedico a integrar todo el sistema
mostrando la arquitectura global y formas de monitorización.
1.3 Estructura del documento

En el siguiente capı́tulo se realizará una exposición del Estado del arte, que ofrecerá una visión
del escenario sobre el que tenemos que trabajar.
En el capı́tulo 3 se efectuará un análisis de la solución. Se recogerá en una lista de requisitos.
En el capı́tulo 4 se explicará cómo se ha diseñado y desarrollado la solución, ası́ como la

separación de los módulos de red según sus propiedades.
En el capı́tulo 5 se describirá el proceso de implementación de la red de manera mas profunda.
En el capı́tulo 6 se explicará cómo se procede a la integración de cada uno de los módulos

de red, configuración, arquitectura global y la monitorización de ésta.
Finalmente, en el capı́tulo 7 se verán las conclusiones del trabajo realizado, ası́ como las
aportaciones futuras que se pueden añadir al trabajo presentado.
2 CAPÍTULO 1. INTRODUCCIÓN
2
Estado del arte
2.1 Introducción
En este capı́tulo se hará una descripción breve sobre la actividad y funcionamiento del CGRM .
Ası́ se podrá obtener una visión global de la sede sobre la que plasmaremos el proyecto. Además
se tomarán ideas de un Centro de procesamiento de Datos que concuerden con los objetivos
deseados de nuestra arquitectura.
2.2 Centro de procesamiento de datos
El procedimiento de redundancia y alta disponibilidad de nuestro sistema se basará en el con-

cepto de un CPD [1]. Buscaremos el modo de adaptar nuestra solución haciendo uso de la idea
de funcionamiento de un centro de datos.
Un centro de procesamiento de datos es una instalación utilizada en los sistemas informáti-
cos internos, las telecomunicaciones y los sistemas de almacenamiento. Por lo general, incluye
fuentes de alimentación redundantes, copias de seguridad redundadas, conexiones de comunica-
ciones de datos redundantes, controles ambientales (por ejemplo, aire acondicionado, extinción
de incendios) y varios dispositivos de seguridad.
Las infraestructuras tecnológicas son un aspecto crucial en la mayorı́a de las organizaciones

en todo el mundo. Una de las principales preocupaciones es la continuidad del negocio. Las
empresas confı́an en sus sistemas de información para ejecutar sus operaciones. Si un sistema
no está disponible, la empresa puede verse afectada o se detenga por completo. Es necesario
proporcionar una infraestructura fiable, con el fin de minimizar cualquier probabilidad de in-
terrupción. La seguridad de la información es también una preocupación. Por esta razón un
centro de datos tiene que ofrecer un entorno seguro que minimiza las posibilidades de que exista
un fallo de seguridad.
Por tanto, un centro de datos debe mantener altos estándares para garantizar la integridad
y funcionalidad de su entorno informático. Esto se logra a través de la redundancia de los siste-
mas de energı́a (incluyendo los generadores de energı́a de reserva de emergencia) de refrigeración
mecánica, de dispositivos y de cableado.
3
La TIA-942(Asociación de la Industria de Telecomunicaciones), especifica los requisitos

mı́nimos de infraestructura de telecomunicaciones de centros de datos y salas de ordenadores,
incluyendo centros de datos empresariales individuales y centros de datos de hosting de múltiples
usuarios de Internet. La topologı́a propuesta está destinada a ser aplicable a cualquier tamaño
de centro de datos. Nosotros haremos uso de esos estándares para configurar una infraestructura
de red adecuada. Las especificaciones básicas referidas al diseño lógico de redes son, entre otras:
1. Creación de zonas desmilitarizadas (DMZ).

2. Segmentación de redes locales y creación de redes virtuales (VLAN).
3. Despliegue y configuración de la electrónica de red: pasarelas, enrutadores, conmutadores,
etc.
4. Creación de los entornos de explotación, pre-explotación, desarrollo de aplicaciones y
gestión en red.
5. Creación de la red de almacenamiento.
6. Instalación y configuración de los servidores y periféricos.
2.3 Trabajo previo

A la hora de estudiar la labor en una administración pública y su funcionamiento, nos pode-
mos encontrar con diversas dinámicas de trabajo. Una forma de comprender sus necesidades es
poder seguirles de cerca. En el Consulado General del Reino de Marruecos se realizan todas las
gestiones relacionadas con visados, certificados, DNI, Legalización, registro civil, pasaportes y
Notarios de matrimonio (Adules).
Con motivo de las vacaciones de verano el departamento de pasaportes se suele saturar con
personas que quieren renovar sus pasaportes para poder viajar a Marruecos. Por ello es necesario
un refuerzo en su plantilla. Gracias a haber trabajado una campaña de verano en el departa-
mento de pasaportes pude tener mi primera toma de contacto con el Consulado. Mi labor era
entrar en una aplicación de pasaportes (en francés), verificar y contrastar con la información del
dossier, modificar algún dato en caso necesario y finalmente autorizar si va a ser una renovación
o prorrogación. Esto es, si un pasaporte tiene cinco años, se puede prorrogar su validez cinco
años más. Si esta deteriorado, o tiene diez años, se debe hacer una renovación y expedir un
pasaporte nuevo.
Durante ese periodo, gracias a mis conocimientos tecnológicos y afán por aprender el fun-
cionamiento de su red, tuve la oportunidad de poder introducirme en sus profundidades. La no
existencia de una figura de técnico en la sede me permitió destacar en este aspecto. Después de
tiempo analizando y resolviendo incidencias puntuales me brindaron la oportunidad de trabajar
en el consulado como técnico durante este último año.
Con motivo de la remodelación radical del edificio del Consulado, era un buen momento
para dejar la posibilidad de poder escalar a la nueva topologı́a de red. Esto es, acondicionar el
espacio para la distinta colocación de los dispositivos en caso de llevarse a cabo, hacer uso de un
buen cableado que recorre las canalizaciones, etc. Debido al conocimiento de número de puestos
de trabajo, departamentos existentes y las necesidades de conexión que tienen cada uno, me
reunı́ con el arquitecto para mostrarle sobre plano la colocación de las tomas de red. También
se decidió la tipologı́a y estructura del cableado de canalizaciones de la pared,entre otros.
4 CAPÍTULO 2. ESTADO DEL ARTE

2.4 Conclusiones
En este capı́tulo se ha mostrado el estado del arte en la arquitectura de un CPD basada en
la redundancia y la alta disponibilidad, ası́ como el trabajo previo. Se han citado cada una de
las propiedades existentes en éste y se ha seleccionado un modelo a seguir para crear una red
propia adaptada a nuestro escenario.
En el siguiente capı́tulo se tomarán las ideas expuestas en este capı́tulo y en los objetivos
para resolver el problema. También se desarrollará un análisis más a fondo del problema y se
plantearán las soluciones necesarias para afrontarlo.
CAPÍTULO 2. ESTADO DEL ARTE 5

6 CAPÍTULO 2. ESTADO DEL ARTE

Análisis del problema
3
3.1 Introducción
En este capı́tulo se analizará de una forma más técnica el problema de la arquitectura de red
del CGRM. Esto es, extrayendo de los objetivos deseados las lı́neas principales y tomando las
ideas de un CPD que más se adecuan a nuestras necesidades.
3.2 Análisis de requisitos
A continuación se mostrará una lista de los requisitos funcionales y no funcionales que deberá
tener la arquitectura de red. Se explicarán la condiciones que deberá cumplir una vez acabado,
para que no exista ninguna carencia.
3.2.1 Requisitos funcionales

En esta sección se explicarán los requisitos funcionales que deberá tener la red una vez acabada,
esto es las funcionalidades que deberá tener. Para facilitar la comprensión de todos los requisitos
se ha hecho una diferenciación dependiendo de la naturaleza de la red. Estas diferenciaciones
serán las siguientes:
• Red Interna: Aquı́ se introducirán todos aquellos requisitos que estén relacionados con
la red interna.
• Red DMZ: Esta categorı́a citaremos aquellos requisitos que guarden relación con lo
referido a la red Desmilitarizada.
• Red de invitados:Esta parte se encargará de recoger la información necesaria para crear

la red de invitados.
A continuación se detallarán los requisitos funcionales para cada una de estas categorı́as del
sistema de una forma técnica.
7
Red interna
RF1: Dar conectividad a internet a los puestos de trabajo.
RF2: Dar acceso a las aplicaciones correspondientes en cada departamento.
RF3: Control de acceso a internet.
RF4: Instalar un puesto de control.
RF5: Instalar un gestor de turnos.
Red DMZ
RF6: Dar salida hacia el exterior.
RF7: Establecer una conexión punto a punto entre las 2 sedes.
Red de invitados
RF8: Crear red especı́fica para poder dotar de conectividad en el edificio.O bien, de forma
puntual (una reunión de trabajo) o de forma prolongada (un congreso de varios dı́as)
RF8.1: Conectividad a personal externo que accede al consulado como invitado.

RF8.2: Conectividad a personal propio del consulado.
RF9: Proporcionar acceso a servicios en Internet.
RF10: Conexión inalámbrica: Facilitar el acceso a la misma y para evitar que sea necesario
disponer de cableado fı́sico a elementos especı́ficos en las salas donde se celebren los eventos
que requieran de esta conexión.
3.2.2 Requisitos no funcionales

A continuación se mostrarán otro tipo de requisitos, los no funcionales. Estos requisitos son las
caracterı́sticas que debe cumplir nuestro sistema, pero no se encuentran relacionados con su
funcionalidad. Por otro lado, son factores indispensables para garantizar los servicios adminis-
trativos.
RNF1: Fiabilidad. Garantizar que el sistema continúe funcionando en un determinado

instante en el tiempo.
RNF2: Elasticidad. Tenga capacidad el sistema para adaptarse a condiciones externas

imprevistas (fallos, aumento de carga,etc) para continuar cumpliendo sus parámetros de
calidad.
RNF3: Estabilidad. La red deberá estar operativa continuamente, por lo que debe ser
altamente estable.
RNF4: Mantenibilidad. Tener capacidad de realizar una reparación satisfactoria en un

tiempo determinado.
RNF6: Sistema tolerante a fallos (Fault-Tolerant Systems). Sistema que contienen com-
ponentes hardware dobles de modo que el fallo de uno de ellos no suspende su operación.
RNF7: Recuperación ante desastres (Disaster Recovery). Capacidad de la instalación de

recuperar la operatividad tras un evento de gran magnitud, bien de tipo local (edificio),
urbano (ciudad) o regional (área extendida con infraestructuras comunes).
8 CAPÍTULO 3. ANÁLISIS DEL PROBLEMA

RNF8 : Escalabilidad. Poder adaptarse a los futuros movimientos.
RNF9: Seguridad. Garantizar a los usuarios legı́timos la confidencialidad de sus comu-

nicaciones en este medio. Poder detectar que elementos maliciosos intenten ataques y
aislarlos.
Red de invitados
RNF11: Seguridad. Detectar y parar cualquier intento de ataque a otras organizaciones

externas por parte de un usuario de esta Red de Invitados.
RNF12: Disponibilidad. Al tratarse de un servicio prestado por el Consulado a los invi-

tados a sus instalaciones no se exige un alto nivel de disponibilidad para estos elementos.
3.3 Conclusiones
En este capı́tulo se han mostrado las caracterı́sticas deseables del proyecto y se ha expuesto
la división de módulos por cada red, haciéndolo más sencillo de analizar, desarrollar y
mantener. En el siguiente capı́tulo veremos cómo cada uno de los requisitos mostrados
en el proyecto van tomando forma. Asimismo se mantendrá la división en módulos para
conservar una estructuración más sencilla de entender.
CAPÍTULO 3. ANÁLISIS DEL PROBLEMA 9

10 CAPÍTULO 3. ANÁLISIS DEL PROBLEMA

Desarrollo de la solución
4
4.1 Introducción
En este capı́tulo se expondrá el diseño y el desarrollo de la solución propuesta en el anterior

capı́tulo. Se tomarán las caracterı́sticas deseadas del anterior capı́tulo para convertirlas en
algo más tangible. Asimismo, se instaurará un sistema de módulos de redes para facilitar
la comprensión, el diseño y desarrollo.
4.2 División en módulos
Como se ha especificado anteriormente, se dividirá el diseño y el desarrollo de la solución en

módulos para facilitar el esfuerzo necesario, tanto para realizarlo como para comprenderlo.
Se especificarán las medidas necesarias para crear los módulos de manera independiente
pero siempre teniendo en cuenta la futura comunicación entre ellos.
4.2.1 Red Interna
La red interna es el núcleo en el que más nos centraremos en este proyecto. Básicamente
es el corazón de nuestra arquitectura. Por lo tanto es necesario que esta red se encuen-
tre operativa en un porcentaje que tiende al 99,9 %. Esto se traduce en construir una
red de Alta disponibilidad (HA). La no disponibilidad debe ser minimizada por paradas
planificadas como:
• Actualización de nuevas reglas del firewall

• Configuración switches core de la red y de planta.
• Copias de seguridad
• Copias de servidores
11
Figura 4.1: Diagrama lógico de red global
Se deberá crear una arquitectura que en caso de producirse una causa de interrupción
del servicio no planificado, el sistema pueda recuperarse en un instante de tiempo que se
considere aceptable y no interfiera en la dinámica de trabajo de los empleados. La disponi-
bilidad estará relacionada con la fiabilidad de los componentes y sistemas, la elasticidad de
los mismos en situaciones imprevistas, la mantenibilidad de cada uno de los componentes
y la recuperación ante desastres. Las paradas no planificadas pueden deberse a:
• Fallos de aplicación
• Fallo hardware
• Errores de configuración software
La conexión de componentes se realizará en la medida de lo posible en paralelo. Esto es,

para cumplir con el principio de redundancia y crear una arquitectura más robusta. De
lo contrario, si los componentes están en serie, un fallo en cualquiera de ellos condena
el sistema global. Para aclarar este escenario, se muestran las distintas fórmulas de la
disponibilidad total de un sistema en cada uno de los casos. Suponer que el fallo en cada
uno de los sistemas es independiente del fallo en cualquier otro. [2]
A es la disponibilidad total que viene acotada entre [0,1]. A i es la disponibilidad de cada

componente.
12 CAPÍTULO 4. DESARROLLO DE LA SOLUCIÓN

[Serie]
[Paralelo]
Figura 4.2: Disponibilidad del sistema
En el primer caso se puede observar que existe una dependencia en cadena. [3] En caso de
que cualquier Ai sea 0, la disponibilidad total será 0. La segunda fórmula muestra que con
que uno de los componentes en paralelo tenga disponibilidad, el sistema puede continuar
su funcionamiento. Por otro lado, a mayor disponibilidad, mayor es el coste del sistema.
Debido a ello es importante evaluar el nivel de disponibilidad requerido para invertir lo
necesario para conseguirlo, y no excederse.
Figura 4.3: Relación de disponibilidad
La labor principal es la eliminación de Puntos Simples de Fallo (Single Points Of Failure,

SPOF) [4] en aquellos dispositivos más crı́ticos. El uso de clústeres en la cadena de proce-
samiento es una solución óptima para incrementar el tiempo medio hasta fallo del sistema
(MTTF).
CAPÍTULO 4. DESARROLLO DE LA SOLUCIÓN 13

Por otro lado, según el estado de cada componente del clúster nos podemos encontrar con
tres comportamientos:
• Activo-Activo: Todos los componentes se encuentran en funcionamiento realizando

procesamientos para el sistema final.
• Activo-StandBy: Únicamente hay un componente en funcionamiento mientras que

el otro está a la espera de ponerse en marcha en caso de que se necesite. La incorpo-
ración de los componentes en Standby al sistema cuando se solicite es instantánea.
• Activo-Pasivo: Un componente se encuentra activo mientras que el resto son acti-

vados bajo petición después de un intervalo determinado de tiempo.
En la medida de lo posible, nuestra arquitectura se basará en el comportamiento Activo-

Activo, que aprovecha todos los recursos de los que se dispone. No siempre es sencillo
poder aplicar este tipo de funcionamiento ya que complica las conexiones y configuracio-
nes. Respaldándonos en el uso de varios protocolos podremos conseguir nuestros objetivos.
Dentro de las comunicaciones es imprescindible estudiar la redundancia de los enlaces

entre los distintos elementos, los equipos que forman la core y acceso de la red(Switches).
Las implicaciones de la aplicación de la redundancia a nivel 2 supone la formación de
bucles en los posibles caminos entre dos nodos de la red.
La solución que aplicaremos a este problema es la activación del Spanning Tree Protocol
(STP) [5] en los distintos dispositivos. Debido a que nuestros aparatos a instalar soportan
la versión mas avanzada de éste, usaremos Rapid Spanning Tree protocol(RSTP) que con-
verge más rápido en la configuración a la hora de producirse un fallo. El funcionamiento
de este protocolo (802.1w) básicamente bloquea los puertos que implicarı́an la aparición
de bucles.En caso de fallo de un enlace, se reconfigurará el ST y se utilizará un enlace
alternativo(desbloqueando el puerto) para comunicar con los nodos que dependan de él.
A continuación mostramos el diseño de la red, tanto conceptual como fı́sica, para el entorno
de Red Interna.

Diseño conceptual (alto nivel)
En el diseño conceptual se fija la topologı́a de alto nivel de la red. Siguiendo el modelo

jerárquico distinguimos 2 niveles: Core y Acceso. La arquitectura básica en modo tradi-
cional se muestra a continuación:
Figura 4.4: Diseño conceptual
Nivel de core Buscamos un dispositivo que sea, entre otras cosas, Stackable y multi-
layer, es decir, que tenga capacidad de enrutar. En particular, el modelo que se adecúa
a nuestras necesidades es el Cisco WS-C3750X-24T-S [?]. Este dispositivo tiene las
caracterı́sticas que se adaptan a nuestro modelo.
Dispone las funcionalidades básicas de nivel 3, sin PoE, uplinks de altas velocidades, etc.
A continuación mostramos sus especificaciones:
• Total 10/100/1000 Ethernet Ports : 24

• Uplinks : Modular 4 x 1 GE, 2 x 10 GE, 2 x 10GB-T, and Service Module with two
10 GE SFP+ Interfaces
• Default AC Power Supply Rating with Dual Modular Slots 350W
• Stack Power: Yes
• With IP Base Software
El conjunto de funciones del IP base [6] incluye Calidad de Servicio avanzada (QoS),
Rango limitado, listas de control de acceso (ACL), y las funciones básicas estáticas y del
protocolo de ruteo Routing Information Protocol (RIP).
Por lo tanto, para el nivel de Core el planteamiento es instalar dos equipos Cisco Ca-
talyst 3750-X Series Switches en modo Stack y conectados a través de dos enlaces por
Etherchannel.

De esta forma conseguimos que estén interconectados de manera redundante, multiplican-

do por dos el ancho de banda entre ellos y mantener los dos enlaces en Activo-Activo.
De lo contrario, si establecemos las conexiones sin Etherchannel, nos encontrarı́amos con
un escenario de Activo-StandBy ya que el RSTP bloquearı́a uno de los puertos para no
producir bucles.
Figura 4.5: Cisco C3750X de core en Stack
Nivel de acceso A nivel de arquitectura de red tenemos en el nivel de acceso equipos

Cisco Catalyst 2960S-24TS-L [7] que repartirán la conexión a los distintos equipos de
cada planta y departamento. Tienen las siguientes especificaciones básicas:
• 24 Ethernet 10/100/1000 ports
• Uplinks: 4 One Gigabit Ethernet SFP ports
Los uplinks de Giga serán usados para conectar los dispositivos al core. Ası́ evitaremos
posibles cuellos de botella.
Siguiendo el criterio de alta disponibilidad, estos equipos serı́an un punto único de fallo
(SPOF). Si fallara un switch de acceso, dejarı́a sin servicio a una planta. Por ello se dispo-
ne de un switch reservado con la configuración establecida, de tal manera que se garantiza
que el TimeOut del servicio no supere los 40 minutos.
Para garantizar alta disponibilidad en la conectividad de servidores es necesario contar

con conexiones desde cada servidor a dos switches de la core distintos. De este modo una
(o varias interfaces) de un servidor irán a un switch y otra (u otras) irán al otro switch.
Estos dos switches no comparten recursos, es decir, cuentan con lı́nea de alimentación
diferenciada, para minimizar la posibilidad de fallo simultáneo en ambos switches. A
continuación profundizamremos en la red de servidores.

Red de Servidores
El servidor central donde se alojan las aplicaciones que se usan en el dı́a a dı́a se encuentra
en Rabat. Con esto, podemos encontrarnos con un SPOF no resuelto. La caı́da de este
servicio puede dejar sin funcionar al sistema ya que todas las tramitaciones se realizan a
través de las diferentes aplicaciones. Por ello se propone el uso de servidores locales con
réplicas de únicamente los datos que conciernen al Consulado de Madrid. De esta manera
aparecen unos nuevos dispositivos a añadir en nuestra red.
Para garantizar el acceso a estos dispositivos , debemos tener una conexión redundada
, es decir , al menos dos “puertas” por las que entrar al servidor. Si introducimos dos
adaptadores de red en el servidor se obtiene el objetivo perseguido. Por otro lado, se nos
presenta un problema de direcciones. Cuando se realiza una petición a este servidor por
los distintos dispositivos de la red, debe de haber una única puerta de entrada hacia éste.
Nos referimos a que, a nivel dos, debe de existir una única MAC de entrada y salida. Una
solución se encontrarı́a en mantener un adaptador de red en StandBy . La gestión del
adaptador en el sistema (a través de su driver) hace que únicamente se encuentre activo
uno de ellos. Ambos comparten la misma dirección MAC. En caso de fallo de uno de ellos,
el sistema conmuta, en un tiempo menor que un segundo al adaptador de reserva. Por lo
tanto no existen cambios para los protocolos de niveles superiores.
Figura 4.6: Redundancia Servidor AS
Por otra parte, como se cita en el inicio de este apartado, siempre que sea posible ,
adoptaremos el comportamiento Activo-Activo. Para ello , haremos uso de EtherChannel.
De esta manera todos los puertos de un Etherchannel comparten la misma dirección MAC.
Los protocolos de niveles superiores lo ven como un único enlace de nivel dos. Con ello
conseguimos mayor rapidez en la resolución de fallos y aumento de ancho de banda de las
conexiones.
Figura 4.7: Redundancia Servidor AA

4.2.2 Red DMZ
Tan importante es la redundancia en la red interna como lo es en la red desmilitarizada.

En este caso deberemos controlar la redundancia en la lı́nea de comunicaciones y entre los
routers del operador. La conectividad hacia el exterior será a través de un operador.
Se contratará una MetroLAN [8] para tener ambos núcleos de las distintas sedes en cone-
xión directa, pudiendo tratar ambas infraestructuras de red como una única. MetroLAN
es un servicio de nivel 2 en la red de Metro Ethernet que proporciona conectividad pun-
to a punto, punto a multipunto o multipunto a multipunto. Es un servicio LAN (Local
Area Network) basado en Ethernet, capaz de cubrir grandes distancias y múltiples sedes
a altas velocidades, lo cual permite a una empresa interconectar todas sus redes locales,
integrándolas a una sola red.
Caracterı́sticas básicas
1 Dispone de conectividad de alta velocidad entre múltiples sitios.
2 La conectividad puede configurarse entre dos puntos, punto a multipunto o multi-

punto a multipunto.
3 No hay necesidad de conexiones punto a punto entre múltiples sitios.
4 Aumento de ancho de banda implementando sólo los cambios de software.
5 Se integra con cierta facilidad con la infraestructura existente (LAN).
6 Basada en Ethernet.
La MetroLan hace de respaldo para la salida de internet, en caso de que exista un fallo
en el firewall o en el router del operador.
Figura 4.8: Diagrama lógico Metrolan
Esta solución de servicio tiene varias motivaciones. Primeramente, para tener espaldo de
ambas sedes en caso de caı́da de una de ellas. Por otro lado, el firewall viene ya configurado
de Rabat y no es posible acceder a estas configuraciones. Durante todo el proyecto se
tratará como una caja negra.

Tenemos conocimiento de que, aún teniendo el firewall más puertos, solo están habilitados
dos. Uno que conecta con el router de internet y otro que es para conectar al core. No
es posible establecerle reglas para introducir dos operadores en el mismo firewall, para
mantener uno de respaldo.
Figura 4.9: Redundancia WAN a través de dos operadores
Se ha contemplado el caso de situar un switch intermedio entre el firewall y los operadores

de internet. Se podrı́a establecer un Default Gateway maestro y otro secundario. De esta
manera podrı́amos conseguir una redundancia WAN menos costosa que una MetroLan.
Sin embargo, serı́a necesario establecer una configuración en el firewall de rutas hacia
fuera.
Figura 4.10: Redundancia WAN a través de dos operadores con switch intermedio

4.2.3 Red de Invitados
Esta parte del documento detalla la infraestructura de la Red de Invitados. Se detallan

las distintas interconexiones entre los equipos que forman parte de esta infraestructura y
los flujos de comunicación que se establecen entre ellos.
Primeramente comenzaremos con el funcionamiento del servicio. El objetivo de la Red de

Invitados es poder ofrecer a aquellas personas que ocasionalmente puedan acudir a las
instalaciones del Consulado una conexión a Internet como servicio de valor añadido. Este
servicio se ofrece sin un nivel de garantı́a de servicio explı́cito y se ha diseñado de forma
que el uso del mismo no tenga impacto sobre la infraestructura de conectividad con Inter-
net del Consulado. Está previsto ofrecer este servicio tanto a los ciudadanos que acceden
al edificio como a aquellas personas que puedan acudir a eventos organizados (reuniones,
seminarios, presentaciones, etc.) por el Consulado de Marruecos en sus instalaciones.
A continuación expondremos la estructura del servicio. El servicio de Red de Invitados se

proporciona a través de dos bloques de componentes diferenciados:
• Una infraestructura de comunicaciones formada por conmutadores y puntos de acceso

inalámbricos. Esta infraestructura es independiente de la infraestructura de comuni-
caciones que soporta las redes internas del Consulado, y dará servicio en las distintas
ubicaciones fı́sicas del Consulado de Marruecos.
• Un sistema de interconexión con Internet que permita implementar un control de

seguridad perimetral e interconectar a la infraestructura de la Red de Invitados con
la infraestructura de interconexión con Internet del Consulado de Marruecos.
Infraestructura de comunicaciones interna
Para la conexión de Red de Invitados existirá un conjunto de conmutadores de comunica-

ciones especı́ficos que dispondrá de puntos fı́sicos de conexión en las salas que se considere
necesario.
Se utilizarán puntos de acceso inalámbricos para la creación de las redes inalámbricas,

estando estos puntos conectados a un interfaz fı́sico dentro de los conmutadores de co-
municaciones especı́ficos de esta red. En el caso de que sea necesario extender la red
inalámbrica más allá de su zona de cobertura (porque existan ubicaciones distintas para
los eventos) se utilizarán extensores (bridge) de redes Wifi. La configuración de estos pun-
tos de acceso y extensores se realizará de forma explı́cita en función de las necesidades del
servicio.
El cableado utilizado para estas conexiones estará separado del cableado de las conexiones
de las redes internas del Consulado y, en la medida de lo posible, todas las conexiones fı́si-
cas a esta red estarán convenientemente marcadas como conexiones a la Red de Invitados.
Los usuarios que se conecten a este entorno no son confiables y se considerará, por tanto,
las redes de esta infraestructura como no confiables.

A continuación se detallan los componentes de esta infraestructura.
Figura 4.11: Componentes infraestructura WIFI
Sistema de Interconexión con Internet
Para la conexión de la infraestructura de comunicaciones interna de la Red de Invitados

con Internet se utilizará una infraestructura de comunicaciones que consistirá en una red
de comunicaciones integrada con la infraestructura de interconexión con Internet. Esta
infraestructura de comunicaciones definirá una serie de redes que se tratarán como no
confiables y ubicada fuera de los sistemas de seguridad perimetral de la infraestructura
de conexión con Internet.
La infraestructura estará conectada con la infraestructura de interconexión de Internet
del Consulado de Marruecos. Esta conexión no será directa sino que se controlará a través
de dispositivos de seguridad perimetral. Para ello se utilizará el equipo Juniper NetS-
creen SSG5, que incorporan funciones de cortafuegos ası́ como funciones de IDS/IPS y
control/gestión del ancho de banda:
• Control de Acceso: No se realizará un filtrado del tráfico saliente (para simplificar la

gestión de autorizaciones en el acceso) pero sı́ se filtrará el tráfico entrante de forma
que los equipos instalados en esta red no sean directamente accesibles desde Internet.
• Prevención de intrusiones (IDS/IPS): se intentará detectar cualquier tráfico malicioso

originado por esta red hacia Internet o la infraestructura del Consulado.
• Control de ancho de banda: se utilizará para garantizar que un elemento malicioso

en dicha red no puede afectar a los servicios en producción.

En la siguiente tabla mostramos las reglas generales de acceso.
Figura 4.12: Reglas de acceso WIFI
Las reglas deberán añadirse en la gestión de la consola de cortafuegos Juniper: Netscreen

Security Manager.
Figura 4.13: Netscreen Security Manager
En el NSM podemos ver de forma esquemática e intuitiva las reglas establecidas. Por
ejemplo, la regla de ID 53 denegamos todo acceso que vaya del grupo de red de invitados
al grupo de red interna. Por otra parte en la regla 98, si nos encontramos en el grupo
de red de invitados podremos acceder a los demás grupos con los servicios mostrados
(HTTP,HTTPS,etc).

En estas reglas añadimos un sistema de monitorización más. Habilitamos la función Log

para cuando las acciones sean “dropeadas”. Es decir, cada vez que se deniega un acceso
tirando el paquete, éste proceso se queda registrado en un log para su estudio. De esta
manera podemos identificar posibles ataques a la red interna o el mal uso de la red de
invitados.
Las funcionalidades de seguridad permitirán, por un lado, proteger a los usuarios conec-
tados en esta Red de Invitados de ataques provenientes de Internet y, asimismo, controlar
el acceso de los usuarios tanto a Internet como a la infraestructura del Consulado.
Figura 4.14: Componentes de la infraestructura de comunicaciones interna
Otros usos de la infraestructura
Si bien la infraestructura se utilizará principalmente para el servicio de Red de Invitados

la infraestructura de comunicaciones que interconecta con Internet está implementada de
forma que será posible utilizarla para otros usos. En concreto para la Red de acceso para
proveedores, que se detalla a continuación.
Red de acceso de proveedores Esta red se ofrece para proporcionar acceso a provee-
dores externos cuando sea necesario realizar tareas de mantenimiento de ciertos sistemas
y el proveedor sólo pueda realizar este servicio mediante la gestión remota de equipos a
través de Internet. Esta red proporcionará acceso a equipos que tengan que recibir un
nivel de soporte remoto.
La red de proveedores estará conectada a Internet a través de un elemento de seguridad

perimetral que permitirá el establecimiento de conexiones desde Internet a equipos ubi-
cados en esta red realizando traducción de direcciones con el direccionamiento que decida
el Consulado en el momento de la intervención del proveedor. Los elementos de seguridad
perimetral se configurarán cuando se requiera para sólo permitir el acceso a los dispositivos
en esta red desde las direcciones IP autorizadas del proveedor externo, que se comunicarán
con antelación al Consulado.
Estas conexiones se definirán siempre de forma permanente para equipos que deban estar
accesibles para su administración por parte de proveedores externos para pruebas o ins-
talaciones de larga duración. Los equipos en esta red no podrán reubicarse en otras redes
distintas (por ejemplo, en Red Interna) sin que pasen los controles y validaciones pertinen-
tes que establezca el departamento que gestiona la Seguridad. Para ello se define una red
de validación que se utilizará sólo cuando sea necesario aislar el equipo de la conexión a
Internet para lo que será necesario cambiar la configuración del equipo (direccionamiento
IP) y del dispositivo de comunicaciones al que el equipo esté conectado.

Gestión de la infraestructura
La infraestructura del servicio se gestionará a través de distintos mecanismos en función

del componente.
Figura 4.15: Gestión de los componentes
Figura 4.16: Diagrama lógico red de invitados
4.3 Conclusiones
En este capı́tulo se ha mostrado como se han desarrollado cada uno de los módulos ne-
cesarios para poder solucionar el problema planteado. Se han mostrado las estructuras
necesarias para el funcionamiento y la comunicación existente entre ellas, ası́ como la
comunicación externa. En el próximo capı́tulo se mostrara la implementación y las confi-
guraciones que se han seguido para conseguir nuestros objetivos.

Implementación de la red
5
5.1 Introducción
En este capı́tulo procederemos a mostrar la implementación de la red con la diferenciación

entre departamentos, como se integrará, como llevaremos a cabo la monitorización. Tam-
bién haremos una breve descripción del servidor proxy y las aplicaciones que le daremos.
5.2 División en módulos
Teniendo en cuenta las recomendaciones de la TIA-942 [9] en lo referido a la arquitectura,

se ha considerado un diseño de cableado estructurado con arquitectura de topologı́a de
estrella redundante, para proporcionar fiabilidad, flexibilidad y escalabilidad, para poder
adaptarse a los futuros movimientos.
Al diseñar una red conforme a la norma, se obtienen ventajas fundamentales, como son:
• Nomenclatura estándar.
• Funcionamiento a prueba de fallos.
• Aumento de la protección frente a agentes externos.
• Fiabilidad a largo plazo, mayores capacidades de expansión y escalabilidad.
De acuerdo con el estándar TIA-942, la infraestructura de soporte de un Centro de da-

tos estará compuesta por cuatro subsistemas. En este caso detallamos uno de ellos que
corresponde a nuestro planteamiento.
• Telecomunicaciones: Cableado de armarios y horizontal, accesos redundantes, cuarto

de entrada, área de distribución, backbone, elementos activos y alimentación redun-
dantes, patch panels y latiguillos, documentación.
25
La arquitectura se puede representar de forma simplificada para una mayor comprensión

en el esquema adjunto, en los que se observan los principales elementos del centro de
datos [10]
MDA: Área de distribución principal
HDA: Área de distribución horizontal
ZDA: Área de distribución zonal
EDA: Área de distribución de equipos
A nivel ilustrativo en la imagen inferior se aprecia una arquitectura posible.
Figura 5.1: Arquitectura de Red estándar TIA-942
El MDA incluye las principales conexiones cruzadas, constituyendo el punto central de

distribución del sistema de cableado fı́sico estructurado del centro de datos y puede incluir
una conexión cruzada horizontal cuando las áreas de equipos son conectadas directamente
desde el MDA. Todos los centros de datos incluyen, por lo menos un MDA. El HDA sirve
a las áreas de equipos y las EDA están asignadas para los equipos finales. Al encontrarnos
con un escenario de un centro de datos a pequeña escala, podemos englobar MDA con
HDA y ZDA con EDA. Todo el cableado a emplear, tanto en cobre como en fibra óptica,
deberá cumplir con las siguientes normativas:
ISO/IEC 11801:2010, EIA/TIA 568C, EIA/TIA 942-A, ISO/IEC 14763-2, ISO/IEC

14763-3, EN 50173-1 EN 50173-5, EN50174-1, EN 50174-2.
Toda la electrónica de red, estará reflejada en paneles de parcheo, tanto en los HDAs y
MDAs, para conseguir una mayor seguridad y fiabilidad.
26 CAPÍTULO 5. IMPLEMENTACIÓN DE LA RED

5.2.1 Intermedio DMZ-LAN (lı́neas de operadores)
A tı́tulo informativo, debido a que la distribución de este cableado está fuera del alcance
del proyecto, se detalla la configuración y diseño a realizar por terceras partes. Existirá
una única entrada para lı́neas de operadores a la sala de comunicaciones.
Se proporcionará un pequeño espacio en la sala donde los operadores entregan sus lı́neas
en repartidores de cableado tanto de fibra óptica, pares metálicos, coaxiales, etc. Este será
el punto de demarcación donde los cables de los proveedores se conectarán a los cables
del cliente, siendo nuestra responsabilidad la instalación del cableado interior desde dicho
espacio al core de la red.
Se deberá confirmar con los distintos proveedores el tipo de conector de interconexión

usado en cada uno de los servicios a prestar y ası́ poder facilitar su planificación y conexión
fı́sica (RJ45, fibra, coaxial,etc).
5.2.2 Red interna
Los departamentos serán diferenciados por la creación de Vlanes diferentes por cada uno
de ellos. También estableceremos un direccionamiento IP para cada uno de los departa-
mentos.
En nivel 2, los departamentos están separados por VLANES diferentes. También se efectúa
una disgregación de direccionamiento IP de tal manera que, para cada departamento se
establece una subred.
Existen ciertos cargos que interesa que estén en grupos de trabajo determinados. Un cónsul
adjunto es el que dirige su departamento correspondiente. Podemos encontrarnos con un
cónsul adjunto de pasaportes, visados, certificados, etc. Queremos que todos los cónsules
adjuntos formen parte de la misma subred. A la vez pretendemos que cada uno de ellos
tenga acceso a la VLAN que corresponde al departamento que gestiona.
CAPÍTULO 5. IMPLEMENTACIÓN DE LA RED 27

Figura 5.2: VLAN y Direccionamiento IP
Por otra parte, nos encontramos con el cónsul. El cónsul es la persona que dirige todo el
consulado. Existen aplicaciones que solo él puede tener acceso. Por ejemplo la aplicación
de contabilidad. Esta aplicación no será replicada en un servidor local por motivos de
seguridad. Asimismo, el acceso a ésta es esporádico. El no mantener la alta disponibilidad
en este aspecto no supondrı́a un problema de fondo.
Existe también una aplicación donde viene reflejado el expediente consular con todos los
datos del ciudadano. Esta aplicación deben tener acceso todos los empleados para poder
consultar cualquier dato que sea necesario en una tramitación.
Se implantará una VLAN de gestión por la cual podremos configurar todos los equipos
de nuestra red. Se asignará una IP fija a cada dispositivo que forma la red. El DHCP solo
se realizará en la red de invitados. Para mantener un estándar nemotécnico se precede a
asignar de la siguiente manera:
172.20.XXX.ZZ
XXX: VLan a la que corresponde
ZZ: Del 1..5 Se reservan para Servicios. De 6..254 para clientes.

Figura 5.3: Mapa global de VLANes

Figura 5.4: Asignaciones de IPs fijas
Por otro lado se deben establecer los Trunking de los puertos de cada switch. En las
siguientes tablas se muestran las VLANes que deben estar presentes en cada puerto.
Figura 5.5: Trunking Switch 3750X Core

Figura 5.6: Trunking Switch 2960 Planta 1

Diseño fı́sico (bajo nivel)
Con el estudio realizado previamente acerca de la sala de comunicaciones y los requisitos

recogidos se puede ajustar la topologı́a del diseño conceptual y dimensionar la red acorde
al tamaño del CGRM.
Nivel de Core Se va a realizar el diseño considerando una arquitectura en stack con

dos Cisco Catalyst 3750 para conseguir un diseño basado en la agregación y redundancia.
Definición de la solución de core:
Requerimientos por cada equipo de Core:
• Uplinks de conexión de los switches de acceso: 3 puertos de 1 GE

• Puerto acceso a Firewall: 1 puerto 1 GE
• Puerto para interconexión de los cores entre distintas sedes: 1 puerto de 1 GE
• Puertos para conexión de servidores : 5 puertos de 1 GE
• Puertos para conexión de Proxy : 1 puerto de 1GE
• Puerto para la Red de invitados : 1 puerto de 1 GE
• Puerto auxiliar de salida al exterior: 1 puerto de 1 GE
• Puerto para puesto de control: 1 puerto de 1 GE
Escalabilidad. Está garantizada porque existen puertos libres en las maquinas conside-
radas: puertos de 1 GE

La siguiente tabla ilustra estas conexiones.
Figura 5.9: Conexiones CORE
Nivel de Acceso La elección adecuada es la instalación de un cisco 2960 por cada

planta.
Requerimientos por cada equipo de Acceso:
• Puertos para conexión a core: 2 puertos de 1 GE
• Planta 1
Puertos para puestos de legalización : 3 puertos de 100 ME

Puertos para puestos de Registro civil: 3 puertos de 100 ME
Puertos para puestos de DNI: 2 puertos de 100 ME
Puertos para puestos de Certificados: 7 puertos de 100 ME
Puertos para puestos de Gestor de Turnos: 1 puerto de 100 ME
• Planta 2
Puertos para puestos de Pasaportes: 10 puertos de 100 ME

Puertos para puestos de Contabilidad: 2 puertos de 100 ME
• Planta 3
Puertos para puestos de Consules:7 puertos de 100 ME

Puertos para puestos de Visados: 7 puertos de 100 ME
Escalabilidad. Está garantizada porque existen puertos libres en las maquinas conside-
radas: puertos de 100 ME

En la siguiente figura se muestran las conexiones del core con las plantas:
Figura 5.10: Conexion de CORE con switches de Planta
Red de Servidores
Basaremos nuestra arquitectura en la adquisición de servidores locales y actualizando los

datos con copias ası́ncronas.
Se instalarán servidores locales para almacenar los datos de cada aplicación. Inicialmente
se realizará una copia del servidor central de Rabat con solamente la información que
corresponde a los censados en España. Una vez hecho este proceso tendremos replicados
los datos tanto en el servidor central como en el local.
A partir de entonces se trabajara sobre el servidor local, descongestionando el flujo de
datos hacia fuera y hacia el servidor central. El acceso a la aplicación será menos lento
debido a que no tiene que pasar por el firewall. Se podrı́a conseguir reducir la latencia
de acceso de manera considerable. Esto es, se podrı́a resolver las caı́das producidas por
congestión de acceso al servidor central en horas pico en las que todos los consulados
de Marruecos repartidos por todo el mundo están accediendo simultáneamente. Una vez
finalizada la jornada laboral, se realizarı́a una copia de los datos desde el servidor local
hacia el servidor central. Se programarı́a dicha acción en una hora en la que el flujo de
datos en las redes de la administración Marroquı́ sea escaso. Deberı́amos buscar una hora
adecuada ya que no debemos olvidar que los consulados se encuentran a lo largo de todo
el globo terráqueo, con sus diferentes franjas horarias.

A continuación una imagen de cómo quedarı́an.
Figura 5.11: Conexión de servidores con el CORE
Implementación de servidor Proxy HTTP
En el contexto de servidores y servicios de Internet, un proxy [11] es un programa que

realiza las tareas de petición y conexión a un servicio remoto, cuando un cliente realiza
una petición a un servicio de Internet a través de un proxy. El cliente en realidad no se
conecta directamente al servidor destino. En su lugar, el servidor proxy recibe la petición
y es él quien realiza la petición y conexión con el servidor destino solicitado. Un servidor
proxy actúa como intermediario entre el cliente y el servidor destino.
El proxy web sirve para dar acceso a servicios y recursos remotos a través del protocolo
HTTP. La mayorı́a de proxies HTTP tienen las capacidades de controlar el acceso a los
recursos usando diferentes criterios de acceso. También, registrar los accesos de los clien-
tes para cuestiones de administración de recursos y/o auditorı́a .Algunos otros tienen las
capacidades de almacenar en un cache local los objetos estáticos para ası́ ahorrar ancho
de banda y dar un mayor servicio a los clientes.

La siguiente figura muestra el esquema básico del funcionamiento de un proxy HTTP:
Figura 5.12: Funcionamiento de un Proxy
En el esquema anterior, los clientes HTTP, sean navegadores u otros programas deben ser
configurados para acceder a Internet a través de un proxy, en dicho caso se debe especificar
la dirección.
En nuestro caso, todas las aplicaciones son HTTP / HTTPS. El proxy es el que gestiona
el control de destino de las aplicaciones indicando si tienen que ir a un servidor local o
pasar por el firewall para dirigirse a un servidor remoto.

Gestor de Turnos
Toda la información del gestor de turnos viene respaldada por el Anexo B. Recalcar que
en este apartado introduciremos la lista de control de acceso (ACL).
“Una lista de control de acceso o ACL (del inglés, access control list) es un concepto de
seguridad informática usado para fomentar la separación de privilegios. Es una forma de
determinar los permisos de acceso apropiados a un determinado objeto, dependiendo de
ciertos aspectos del proceso que hace el pedido. Las ACL permiten controlar el flujo del
tráfico en equipos de redes, tales como enrutadores y conmutadores. Su principal objetivo
es filtrar tráfico, permitiendo o denegando el tráfico de red de acuerdo a alguna condición.”
En nuestro caso queremos controlar que el flujo de la información de turnos no tenga

salida al exterior. Por ello establecemos una regla para que tenga acceso sólo a su direc-
cionamiento propio. Añadiremos la correspondiente regla en la configuración del core.
5.2.3 Red de Invitados
Redes lógicas de la infraestructura de Red de Invitados
Descripción de Redes lógicas La infraestructura está formada por las siguientes redes
lógicas:
• Redes internas: Se han contemplado distintas redes de usuarios para que éstos se
conecten con distintos fines. Algunas de estas redes estarán conectadas a puntos de
acceso inalámbricos que se deberán de instalar en las diferentes salas en las que se
requiera del servicio de Red de Invitados y conectarán directamente con los con-
mutadores Core DLINK. Otras redes se implementará a través de conmutadores de
distribución.
• Redes de tránsito externo: Las redes de tránsito comunican el encaminador del
proveedor de ADSL con el cortafuegos de invitados a través de los conmutadores de
Red de Invitados. Esta red es por donde circula todo el tráfico dirigido a Internet de
las redes de Invitados.
• Redes de Proveedores y Validación: Las redes de Proveedores están directa-
mente definidas en los conmutadores de Red de Invitados . Los servidores u otros
equipos que tengan que instalarse para que estén accesibles por parte de empresas
externas (para operaciones de mantenimiento remoto) se conectarán directamente a
estos switches.
Flujos de Conexión
La polı́tica instalada en los cortafuegos de la Red de Invitados controlan los flujos de

navegación provenientes de las redes de la infraestructura y los accesos de gestión a los
dispositivos. Las conexiones inicialmente autorizadas son:
La navegación desde las redes de invitados a Internet .
La conexión de los servicios de gestión de los equipos instalados en la red de pro-
veedores y de los equipos de comunicaciones de LAN, desde la red de gestión de
Internet.
En función de las necesidades de soporte remoto a equipos, y de forma restringida, se
podrı́an producir flujos de gestión desde sistemas en Internet a equipos instalados en la
Red de Proveedores.

Figura 5.13: Diagrama lógico CORE red de Invitados
Mecanismos de alta disponibilidad
Al tratarse de un servicio prestado por el Consulado sin compromiso de calidad de servicio

no se exige un alto nivel de disponibilidad para estos elementos. Ante la caı́da de algún
elemento se podrá realizar la modificación manual para variar el camino del tráfico.
Mecanismos de Control de flujo de tráfico (Clase/Calidad de servicio)
Se activarán los mecanismos de control de la calidad del servicio para los cortafuegos de
la Red de Invitados, esto permitirá priorizar determinadas clases de tráfico frente a otras.
Además de activar el servicio de control de calidad del servicio se han establecido los códi-
gos de diferenciación del Servicio de 1 al 3. Tres para el servicio más prioritario y uno para
el menos prioritario. Hay que destacar que esta caracterı́stica no realiza ninguna función
si no hay una clasificación previa y etiquetado del tráfico que pasa por los cortafuegos.
Los pasos que hay que realizar para la completa configuración del servicio de control de
calidad en los equipos Juniper SGS5 de la Red de Invitados son los siguientes:
En primer lugar para poder completar este proceso se deben establecer los lı́mites de
tráfico, máximo posible y mı́nimo garantizado que deberá soportar cada servicio. Una vez
se haya determinado esto el control de los servicios podrá realizarse mediante la polı́tica
asociada a los cortafuegos. También es posible realizar la priorización del trafico mediante
varias colas que van desde la prioridad 0 (la más alta) a la prioridad 3 (la más baja), esto
además de realizar la priorización del trafico en los cortafuegos de la Red de Invitados
marcará el trafico con ese nivel de prioridad para que otros dispositivos en el canal de
comunicación de esa conexión puedan identificar el trafico y priorizarlo.
También es posible marcar este tráfico, priorizándolo, para que otros dispositivos en el
canal de comunicación sean los que realicen realmente el control del flujo de tráfico.

Mecanismos de prevención mediante ataques e inspección profunda de paque-

tes
Los equipos Juniper SGS5 de la Red de Invitados cuentan con una funcionalidad básica que
permite el control de determinados tipos de ataques mediante la inspección de la carga de
los paquetes y el ensamblado de sesiones. Para ello, los equipos SGS5 podrán descargar una
base de datos de ataques de forma automática. Además de esto se pueden configurar ciertos
perfiles básicos de protección. Los perfiles de protección predefinidos son los siguientes:
protección base, protección de servidores, protección de clientes, y protección frente a
gusanos (Worm Mitigation). Debido a que el servicio de red de Invitados está orientado a
clientes que conectarán principalmente con servicios exteriores en Internet, se ha elegido
el perfil de protección contra clientes. Este perfil previene a los usuarios de la descarga de
malware y realiza la inspección profunda de varios protocolos populares como son HTTP,
DNS, FTP, IMAP4, POP3 y servicios de mensajerı́a como (MSN, AIM, YMSG e IRC)
Para utilizar este servicio se debe contar con la subscripción del servicio de protección
contra ataques activa. Para activar este servicio de subscripción se deberá realizar lo
siguiente:
1 Comprar la subscripción mediante los canales habituales de venta de Juniper.

2 Asociar el código de la esta subscripción con los dispositivos de cortafuegos Juniper
SGS5.
3 Actualizar la licencia de los dos dispositivos.
Una vez se produzca la detección de un ataque mediante este perfil de protección será
notificado en la consola de NSM mediante una notificación en el sistema de registros.
5.3 Conclusiones
En este apartado se ha podido ver una explicación algo más exhaustiva de las especifi-
caciones técnicas llevadas a cabo,ası́ como las tecnologı́as a usar. También se han visto
varios mecanismos dedicados a la mejora y prevención de la red.


6
Integración
6.1 Introducción
En este capı́tulo se relatará la integración de la red desarrollada. Se mostrará la arquitec-

tura diseñada de un modo completo, la configuración necesaria para poder volcarla a los
switches. Se establecerán las caracterı́sticas técnicas del cableado y la monitorización.
6.2 Caracterı́sticas técnicas del cableado de datos
A la hora de calcular las distancias de cableado, debe tenerse en cuenta en criterio de re-
dundancia, según el cual debe evitarse la coincidencia de recorridos de cables redundantes.
La elección del sistema de cableado a implementar deberá cumplir con los siguientes re-
querimientos mı́nimos:
Altas prestaciones
Escalabilidad y modularidad estructurada
Alta disponibilidad y Flexibilidad
Capacidad de crecimiento
Arquitectura abierta y basada en estándares
Cableado libre de halógenos y baja emisión de humos (LSZH/LSOH)
Todo el cableado a emplear, tanto en cobre como en fibra óptica, deberá cumplir con las
siguientes normativas:
EIA/TIA 568C, EIA/TIA 942-A,

ISO/IEC 11801:2010, ISO/IEC 14763-2, ISO/IEC 14763-3,
EN 50173-1, EN 50173-5, EN50174-1, EN 50174-2.
41
6.2.1 Cableado de datos cobre
El tipo de cableado de cobre a considerar en el diseño de detalle será Categorı́a 6, el cual

deberá de cumplir:
• Solución completa y totalmente UTP. No se contemplarán soluciones que contengan

pantallas flotantes, latiguillos apantallados o en definitiva cualquier elemento metálico
a excepción de los propios hilos conductores.
• Diámetro del cable inferior a 7.25mm, con objeto de no penalizar el dimensionamiento

de las canalizaciones, y minimizar la obstrucción con el flujo de aire.
• Los cables de cobre serán tipo LSZH de acuerdo con IEC 332-3-22.
• Disponibles de una gama completa de colores para los latiguillos de cobre y fibra
óptica, al menos 5 colores distintos, con objeto de poder identificar visualmente las
distintas redes que pudieran existir.
• La solución de Categorı́a 6 UTP deberá asegurar el cumplimiento de la categorı́a en

longitudes en distancias entre 3m y 100m para enlaces de 2 conexiones y entre 5m y
100m para enlaces de 3 o 4 conexiones. Además los latiguillos de Categorı́a 6 deberán
estar disponibles en longitudes a partir de 0.5m.
6.2.2 Cableado de fibra óptica
Por otra parte el tipo de cableado de fibra óptica deberá cumplir con los siguientes reque-
rimientos:
• Utilización de fibra óptica multimodo y monomodo optimizada frente al radio de

curvatura y componentes de bajas perdidas.
• Los cables y latiguillos de fibra óptica serán tipo LSZH cumpliendo con la normativa
IEC 332-3-24.
• El fabricante del cableado de fibra óptica deberá disponer de tabla de prestaciones

garantizadas, donde se recojan las distancias mı́nimas aseguradas. Dichas tablas de
prestaciones deberán ser públicas y disponibles en la web. No se aceptarán tablas
elaboradas a propósito para este proyecto.
42 CAPÍTULO 6. INTEGRACIÓN
6.3 Monitorización
Para la monitorización del sistema se ha decidido implementarla a través varias herramien-
tas que cumplirán una función determinada. Con esta suite de paquetes conseguiremos
alcanzar un nivel óptimo de vigilancia para nuestra red. La monitorización del sistema
será abordada por cuatro flancos:
Por un lado se vigilarán los eventos de cada switch que forma la red. Se almacenarán las
configuraciones de los switches de manera regular. A esto se le añade la monitorización en
tiempo real de la vida de los switches. Finalmente se integrará cambios de configuración
de los switches ante un suceso o evento para mantener el servicio.
Para el primer caso, se ha optado por almacenar diariamente el Log de eventos propio de
cada switch en un fichero de texto plano. Esto es posible gracias a la adición de sentencias
en la configuración del switch (véase Apartado Configuraciones) y a la instalación de un
software. Este software es el Kiwi Syslog. [12]
Este programa hace uso del protocolo syslog .Su uso es sencillo. Existe un ordenador
ejecutando el servidor de syslog, conocido como syslogd (demonio de syslog). El cliente
envı́a un pequeño mensaje de texto (de menos de 1024 bytes).Los mensajes de syslog se
suelen enviar vı́a UDP, por el puerto 514, en formato de texto plano.
Existe una versión de pago pero optaremos por la versión gratuita que se adecua perfec-
tamente a nuestras expectativas.
A continuación mostramos sus propiedades mostradas en la web.
Figura 6.1: Descripcion producto Kiwi Syslog Free Edition
Con el uso de este programa podemos tener un repositorio de todos los eventos producidos
a lo largo del dı́a como, por ejemplo, caı́da de algún puerto.
Para el almacenamiento de las configuraciones hemos seleccionado, por mantener la filo-
sofı́a de software gratuito, Teraterm.
Primeramente se instala este software en el puesto de control. Luego se crea un fichero
ttl con lo que queremos realizar. En nuestro caso queremos guardar las configuraciones de
cada uno de los switches diariamente. Para ello hemos creado El siguiente script:
Debemos conectarnos a cada una de las maquinas y extraer las configuraciones. Véase que
en la primera configuración de la máquina aparece:
CAPÍTULO 6. INTEGRACIÓN 43
1 connect 172.20.1.10 /timeout=20 /ssh /2 /auth=password /user=user /passwd=password

2 if result = 0 then
3 closett
4 elseif result = 1 then
5 closett
7 wait >
8 logopen nombre de fichero 0 0
9 sendln terminal length 0
10 sendln show running-config
11 wait >
12 sendln quit
13 endif
14 waitevent 4 or 1
16 closett
18 endif
21 closett
23 closett
25 wait >
29 wait >
30 sendln quit
31 endif
32 waitevent 4 or 1
34 closett
36 endif
39 closett
41 closett
43 wait >
47 wait >
48 sendln quit
49 endif
50 waitevent 4 or 1
52 closett
54 endif
57 closett
59 closett
61 wait >
65 wait >
66 sendln quit
67 endif
68 ...
Figura 6.2: Configuración script Teraterm
Figura 6.3: Tipo apertura TeraTerm
A diferencia de las siguientes que tienen un 1 en vez de un 0 es debido a que en primera

instancia queremos crear el fichero de texto y a continuación ir añadiendo cada una de las
configuraciones restantes debajo de la anterior.
Con esto conseguimos tener un repositorio de versiones de configuraciones. Esto es útil

para en caso de que algo falle, por ejemplo por un cambio incorrecto, podamos restablecer
la ultima configuración operativa.
Por otro lado, es interesante saber si están disponibles y funcionando cada uno de los dispo-
sitivos que forman la red. En definitiva, ver si responden ante la pregunta de ¿Estás vivo?
Para este proceso lo más sencillo, económico y que no consuma recursos es el uso de un
software que haga ping cada intervalo de tiempo. Para ello hacemos uso de FREEping [13].
FREEping es un producto de software gratis que, a base de intervalos antemano definidos,

hace un ping a direcciones de IP en la red indicadas. FREEping hace ping según la lista
de direcciones indicada y ofrece estadı́sticas a cada host que reciba un ping. Aquı́ una
ilustración del programa:
Figura 6.4: Ilustración del Programa FreePing
Ha de destacar que no todos los dispositivos admiten este protocolo. Por ejemplo, los
firewalls suelen tener denegado el uso del protocolo ICMP Echo. Por ello deberemos buscar
una alternativa para poder conocer si los firewalls que componen nuestra red están activos
y funcionado.
Para finalizar, el control de cambios de configuración ante un suceso será implementado
a través de Cisco IOS Embedded Event Manager (EEM). [14]
Cisco IOS Embedded Event Manager (EEM) es un subsistema potente y flexible que pro-
porciona detección de eventos de red en tiempo real y la automatización a bordo. Te da
la posibilidad de adaptar el comportamiento de los dispositivos de red para alinearse con
nuestras necesidades.
Soporta más de 20 detectores de eventos que están altamente integradas con diferentes
componentes de software Cisco IOS para desencadenar acciones en respuesta a los eventos
de la red. Su lógica de negocio puede ser inyectado en las operaciones de red utilizando
polı́ticas IOS Event Manager Embedded. Estas polı́ticas se programan utilizando sencilla
interfaz de lı́nea de comandos (CLI) o el uso de un lenguaje de programación llamado
Tool Command Language (TCL).
Nosotros en nuestro caso lo programaremos a través de CLI. La implementación de esta

tecnologı́a podemos verla reflejada en la parte de Configuraciones de este documento.
6.4 Arquitectura global
Usamos distintos puertos para cada tecnologı́a o dispositivo en cada uno de los switches
que componen el núcleo. Con ello añadiremos otro tipo redundancia. Ambos switches es-
tarán configurados de manera simétrica. De esta forma, si se daña uno de los dispositivos
que forman la core, de manera fı́sica podremos cambiar los cables del switch dañado al
operativo, manteniéndose el servicio interrumpido en un tiempo que se considera acepta-
ble. Por ejemplo, el puerto 22, aunque en condiciones normales no está en uso, esta ya
configurado para funcionar como respaldo.
Figura 6.5: Mapa de conexiones de Core con Dispositivos
El mapa final de la red quedarı́a de esta manera.
Figura 6.6: Mapa de la Arquitectura Global
6.5 Conclusiones
En este capı́tulo se ha relatado la integración de la arquitectura desarrollada , junto el
tipo de cableado que le conecta. Se ha explicado el proceso de monitorización llevado a
cabo por diferentes flancos.
Por último, se mostrará en el último capı́tulo del documento las conclusiones extraı́das del
trabajo realizado y se mostrarás las tareas que aún quedan por hacer para perfeccionar la
arquitectura.
Conclusiones y Trabajo futuro
7
7.1 Introducción
En este capı́tulo se analizará el trabajo desarrollado y expuesto en este documento y se

extraerán las conclusiones finales del documento. Además, se analizarán los puntos que
necesitan un trabajo extra en la sección de Trabajo Futuro.
7.2 Conclusiones
El objetivo de este TFG era la creación de una arquitectura de red de calidad que cumpliese
una serie de caracterı́sticas (fiabilidad,alta disponibilidad,redundancia, etc.). El resultado
obtenido ha sido una red robusta, que cumple los requisitos establecidos en el inicio del
documento.
La arquitectura se ha dividido en tres módulos : Red interna, red de invitados y red DMZ.
Esta división ha hecho mucho más sencillo tanto el desarrollo como su integración.
A lo largo del proyecto hemos podido observar la creación de una arquitectura de red desde
cero, basándonos en distintos estándares establecidos como TIA-942.Esta arquitectura de
red tiene la finalidad de cubrir las necesidades de un consulado y, a su vez, respaldar el
servicio de una embajada. Finalmente se ha conseguido una red completa con todas sus
especificaciones técnicas, los dispositivos adecuados y el mapa de cómo resultarı́a.
7.3 Trabajo Futuro
Se propone para trabajo futuro la sustitución de la MetroLan por una infraestructura

propia que viajen los datos de manera aérea. Este cambio supone hacer un estudio a
fondo de viabilidad, conocer el estado de licencias que da el ayuntamiento para estas
instalaciones,etc.
49
A continuación ilustramos de manera grafica.
Figura 7.1: Eliminación MetroLan
De esta manera los costes de mantener ambas sedes conectadas serı́a mucho menor. Serı́a
imprescindible el uso de fibra para conectar el dispositivo al core debido a que la distancia
es mayor de 100 metros.
Tambien serı́a interesante hacer uso de las Access List para limitar el acceso por depar-
tamentos. Esto es, permitir a los empleados del departamento X, acceder al servidor del
departamento X y sólo ese, además de la salida a internet. Actualmente el routing esta
permitido a lo largo de toda la red interna ya que es una red segura. El unico agente
externo serı́a el gestor de turnos, el cual le hemos limitado su acceso por medio de una
regla.
50 CAPÍTULO 7. CONCLUSIONES Y TRABAJO FUTURO

Bibliografı́a
[1] “Data center.” [Online]. Available: https://en.wikipedia.org/wiki/Data center

[2] “Macrolan.” [Online]. Available: http://portal.uned.es/pls/portal/docs/
PAGE/UNED MAIN/CTU/COMUNICACIONES SEGURIDAD/ACS50/ACS506/
ACS50606/SERVICIO%20MACROLAN.PDF
[3] “Apuntes sistemas informáticos ii de escuela politécnica superior.” [Online].
Available: https://moodle.uam.es
[4] “Single point of failure.” [Online]. Available: https://es.wikipedia.org/wiki/
Single point of failure
[5] “Spanning tree protocol.” [Online]. Available: https://es.wikipedia.org/wiki/
Spanning tree
[6] “Type of ip services.” [Online]. Available: https://supportforums.cisco.com/
document/17541/what-di↵erence-between-ip-base-image-and-ip-services-image#
sthash.tZAwwNxt.dpuf
[7] “Cisco catalyst 2960.” [Online]. Available: http://www.cisco.com/c/en/us/support/
switches/catalyst-2960s-24ts-l-switch/model.html
[8] “Metrolan.” [Online]. Available: http://www.telkom.co.za/sites/business/
government/government product detail/&productname=MetroLAN
[9] “Tia-942.” [Online]. Available: http://www.tia-942.org
[10] “More info tia-942.” [Online]. Available: https://www.bicsi.org/uploadedFiles/
BICSI Website/Global Community/Presentations and Photos/Caribbean/
2012 Fall/2.0%20Siemon%20ANSI-TIA%20942A%20ISO-IEC%2024764.pdf
[11] “Proxy.” [Online]. Available: http://tuxjm.net/docs/Manual de Instalacion de
Servidor Proxy Web con Ubuntu Server y Squid/html-multiples/introduccion.html
[12] “Syslog.” [Online]. Available: https://es.wikipedia.org/wiki/Syslog
[13] “Freeping.” [Online]. Available: http://www.tools4ever.es/software/
software-adicional/freeping/
[14] “Eem cisco.” [Online]. Available: http://www.cisco.com/c/en/us/products/
ios-nx-os-software/ios-embedded-event-manager-eem/index.html
51
52 BIBLIOGRAFÍA
Nomenclatura de Cables, Latiguillos y Switches
A
A.1 Caracterı́sticas generales
A continuación se indican las distintas modalidades de tendidos de cables a incorporar en

las instalaciones, descritos individualizadamente, según tipo de cable, las ubicaciones que
interconectan y las redes a las que pertenecen.
También se detalla en este apartado la normativa a utilizar para el etiquetado de los
latiguillos .
Todos los tipos de nomenclatura llevarán un campo final de numeración del cable que será
secuencial a fin de identificar individualmente a cada cable y cuya secuencia puede ser
decimal, hexadecimal o alfanumérica, según se indique.
A.2 Nomenclatura de Cables

Los cables que se podrán encontrar en las instalaciones del CGRM estarán enmarcados
en alguno de los tipos siguientes:
• Cable de Planta PCxx0nnn

• Cable Inter-salas ICxxyynn
• Cable Local LEzMpxxn
A.2.1 Códigos de categorı́a de los cables
La nomenclatura de todo cable llevará un campo que describe la categorı́a o especifica-

ción técnica del cableado. Este consta de un dı́gito numérico que se indica en la tabla a
continuación y será común a todos los códigos de nomenclatura.
A.2.2 Cable de planta
Esta nomenclatura se aplica a los cables que van desde los cuartos de bastidores de reparto
de cableado (CBs) hacia despachos u otras ubicaciones dentro de la misma planta del
edificio. Su formato de nomenclatura será como sigue:
53
Figura A.1: Tabla categorı́as
Figura A.2: Nomenclatura Cable de planta
Figura A.3: Tabla Cable de planta
54 APÉNDICE A. NOMENCLATURA DE CABLES, LATIGUILLOS Y SWITCHES

A.2.3 Cable inter-salas
Esta nomenclatura aplica a los tendidos de cableado entre los CPDs y los bastidores de
reparto de Cableado (CBs). La nomenclatura se ajustará al formato:
Figura A.4: Nomenclatura Cable de Inter-salas
Figura A.5: Tabla Cable de Inter-salas
A.2.4 Cable Local (Hub/Switch) en Despacho o Mesa
Figura A.6: Nomenclatura Cable Local
A.3 Etiquetas en Latiguillos
Los proveedores de cables deberán entregar los latiguillos de cobre y fibra debidamente
etiquetados en ambos extremos, siguiendo las siguientes indicaciones. Etiquetado en am-
APÉNDICE A. NOMENCLATURA DE CABLES, LATIGUILLOS Y SWITCHES 55

Figura A.7: Tabla Cable Local
bos extremos con un código único por latiguillo con el formato:
LL-SSAAxxxx
donde:
LL: Indica la longitud del latiguillo en metros enteros (1 o dos cifras).

SS: Semana del año en que se ha hecho la compra de los cables
AA: Año del pedido
XXXX: Secuencia del cable asignado dentro del pedido (cuatro cifras)
El etiquetado muy conveniente. Sin embargo, siempre que se numeren los latiguillos se
debe seguir esta norma de nomenclatura para evitar la duplicación de códigos. Algunos
proveedores incluyen el etiquetado de los latiguillos sin coste adicional. Estas etiquetas
nunca deberán eliminarse ni modificarse ya que sirven para identificar la longitud del
latiguillo ası́ como la fecha de fabricación del mismo, dato necesario para poder reclamar
la reparación del mismo, si llega a fallar dentro del perı́odo de garantı́a. Cuando se trate de
latiguillos proporcionados en el momento de realizarse el tendido de cableado, para cubrir
las necesidades de conexión de los equipos a la red, además de las etiquetas indicadas en
el párrafo anterior, deberán colocar una etiqueta que coincida con la etiqueta del cable de
Planta o Inter-salas donde se va a conectar.

Ejemplos: Si se hace un pedido de 30 latiguillos de 2 metros y 15 latiguillos de 10 me-

tros, para entregar el 12 de enero de 2015 (Semana 3 de 2015), los cables deberán venir
etiquetados en ambos extremos como sigue:
2-03150001 a 2-03150030 para los 30 latiguillos de 2 metros

10-03150001 a 10-0310015 para los 15 latiguillos de 10 metros.
La empresa proporcionará los latiguillos que se le pidan con las etiquetas de longitud y
fabricación indicadas y además incluirá en los dos extremos de los latiguillos la etiqueta
P6000134. Uno de esos latiguillos se conectará en el extremo del PC colocando el extremo
con la etiqueta P6000134 en la tarjeta del PC. El otro latiguillo se utilizará para el extremo
del cuarto de bastidores, colocando el extremo con la etiqueta P6000134 en el extremo
conectado a la boca del Equipo de red (switch, hub, etc.) al que se conecta en el cuarto
de bastidores.
APÉNDICE A. NOMENCLATURA DE CABLES, LATIGUILLOS Y SWITCHES 57


Gestor de Turnos
B
B.1 Introducción
El Sistema Inteligente de Gestión de Espera es una herramienta para mejorar la eficiencia

y la imagen de una entidad que preste servicios de atención al público.
• Mejora la calidad de los servicios prestados (llamadas selectivas por orden, núme-
ro, cola de atención, etc., re-llamada, direccionamiento re-direccionamiento de los
usuarios)
• Facilita el trabajo de los empleados (software cliente con amplia gama de funciona-
lidades)
• Facilidad el trabajo de los directivos (estadı́sticas de funcionamiento que permiten

el análisis a nivel cuantitativo y cualitativo del trabajo desarrollado permitiendo ası́
mejorar la distribución de los recursos humanos disponibles)
• Mejora la autonomı́a de la entidad (sistema configurable con la posibilidad de crear,

modificar o borrar colas de atención, distribuir las colas por puesto o usuario, modi-
ficar el interfaz táctil y los tickets de atención, etc.)
B.2 Descripción general
En un Sistema de Gestión de Espera se pueden identificar 3 zonas distintas: la zona de

recepción, la zona de espera y la zona de atención. La zona de recepción es donde los
clientes entran en la empresa o entidad e imprimen su número de tickets, la zona de
espera es donde esperan su llamada y la de atención donde son atendidos por el personal
encargado.
59
Figura B.1: Visión general Gestor de turno
Figura B.2: Diagrama gestor de turno
60 APÉNDICE B. GESTOR DE TURNOS

B.3 Motor, configuración y dispensación asistida (Servidor)
El “Motor del Sistema” se ocupa de gestionar las comunicaciones con los teclados virtuales
o fı́sicos, con el dispensador de tickets y con las pantallas de grupo (y según la configuración
con las pantallas de puesto también). Además , se ocupa de la administración de la Base
de Datos Microsoft Access (o Microsoft SQL Server ) dentro de la cual almacena los
números de tickets dispensados a los clientes para luego recuperarlos, llamarlos o realizar
el seguimiento de los mismos (grabación de la hora de emisión, atención y cierre, puesto
de atención, usuario, etc.).
Figura B.3: Motor gestor de turno
Por otro lado, aparte de visualizar informaciones sobre el turno, el motor muestra tam-
bién algunos datos técnicos del sistema como el número de conexiones TCP/IP activas, el
número de errores de transmisión y el número de paquetes enviados o recibidos desde los
diferentes dispositivos.
En la parte baja de la pantalla se encuentra la zona de los mensajes donde es posible
visionar la actividad del servidor paso a paso (fichero de log) y que resulta muy útil a la
hora de detectar y solucionar problemas eventuales.
Desde el motor es posible enviar mensajes a los Teclados Virtuales y cambiar las priori-
dades de los servicios activos en marcha sin tener que parar el sistema. Cada vez que se
arranca, el “Motor del Sistema” comprueba el buen funcionamiento de las pantallas. En
caso de fallos hardware las excluye del sistema para no comprometer el buen funciona-
miento del mismo.
El Motor tiene incorporado también un sistema de recuperación de fallos de forma que
si por cualquiera razón, como por ejemplo un fallo de la red eléctrica, se tuviera que re-
inicializar la aplicación, esta recuperarı́a su estado antes del cierre.
La “Herramienta de Configuración” permite configurar el sistema de Gestión de Espera
APÉNDICE B. GESTOR DE TURNOS 61

adaptándolo a las necesidades de cada cliente. En detalle se pueden configurar los paráme-
tros generales de funcionamiento ası́ como todos los dispositivos hardware presentes, los
servicios, los usuarios y las condiciones de alarmas y funcionamiento de cada servicio a
nivel de horario y números expedidos.
Por último, la “Dispensación Asistida” permite que uno de los empleados de la entidad
puedan manejar a distancia el dispensador imprimiendo tickets de cualquiera de los ser-
vicios. Esta herramienta es particularmente útil en todos aquellos casos donde los clientes
o ciudadanos no imprimen los tickets por su cuenta si no que tienen que dirigirse antes a
algún empleado de la entidad.
B.4 Teclado(Cliente)
El “Teclado Virtual” permite al operador llamar al número siguiente por atender, re-
llamarlo en pantalla o por megafonı́a según el tipo de instalación o re-enviarlo a otro
servicio o puesto de trabajo.
Figura B.4: Software teclado Gestor de turno
El Teclado se puede ejecutar con 2 interfaces diferentes una de las cuales ocupan un espacio
muy limitado en pantalla para no dificultar el trabajo ordinario de cada usuario. Permite
también la llamada de un número en concreto o la llamada de números perteneciente a
un determinado servicio.

Figura B.5: Especificaciones teclado Gestor de turno
B.5 Supervisión y estadı́sticas
La “Herramienta de Supervisión” permite visualizar el estado del sistema de Gestión de

Espera en tiempo real. De forma simple y rápida es posible ver el número de ticket en cada
estado para cada servicio. También, los tiempos medios de espera y de atención ası́ como
el último número de ticket llamado para cada servicio. Por otro lado es posible establecer
alarmas que nos avisen en el interfaz principal en caso se supere un número prefijado de
personas en espera o se exceda un tiempo de atención prefijado.
El software de “Estadı́sticas” permite visualizar una serie de estadı́sticas de resumen sobre
los varios servicios de atención al público.
APÉNDICE B. GESTOR DE TURNOS 63

Las “Estadı́sticas” de funcionamiento del sistema permiten trazar un cuadro lo más ex-
haustivo posible sobre los servicios prestados al publico midiendo la cantidad (número
de tickets emitidos, números de clientes atendidos, etc.) como la calidad (tiempos medios
de espera, tiempos medios de atención, etc.) de la actividad desarrollada a lo largo del
tiempo.
Figura B.6: Estadı́sticas Gestor de turno
Las “Estadı́sticas” se pueden instalar en cualquier ordenador de la red local o en orde-

nadores fuera de la red actuando simplemente sobre una copia de la base de datos. Las
estadı́sticas obtenidas se pueden exportar a Microsoft Excel .
B.6 Requisitos técnicos
Los requisitos fundamentales para el funcionamiento del sistema son:
• La aplicación no necesita ningún acceso a redes externas (acceso Internet).
• El dispensador/servidor y el/los panel/es de leds tengan una IP fija.
• Un punto de corriente a 220V y una toma de red en proximidad de cada equipo.
• La posibilidad de utilizar conexiones TCP/IP entre la aplicación servidor en contra

los paneles de led y los puestos de trabajo utilizando el puerto 1007 u otro puerto
disponible.

C
Configuraciones de los Switches
65
C.1 Core Cisco WS-C3750X-24T-S
1
2 !
3 version 12.2
4 no service pad
5 service timestamps debug datetime msec
6 service timestamps log datetime msec
7 service password-encryption
8 !
9 hostname CORE
10 !
11 boot-start-marker
12 boot-end-marker
13 !
14 !
15 enable password 7 011F070A085D535A
16 !
17 username admin password 7 07182042420817
18 no aaa new-model
19 system mtu routing 1500
20 vtp domain Consulado
21 vtp mode on
22 vtp mode server
23 !
24 ip routing
25 no ip domain-lookup
26 ip domain-name Red_Interna
27 !
28 spanning-tree mode pvst
29 spanning-tree extend system-id
30 !
31 vlan internal allocation policy ascending
32 !
33 vlan11
34 name CERTIFICADOS
35 !
36 vlan12
37 name DNI
38 !
39 vlan13
40 name PASAPORTES
41 !
42 vlan14
43 name CONTABILIDAD
44 !
45 vlan15
46 name CONSULES
47 !
48 vlan16
49 name REG_CIVIL
50 !
51 vlan17
52 name LEGALIZACION
53 !
54 vlan15
55 name CONSULES
56 !
57 vlan50
58 name INVITADOS
59 !
60 vlan100
Figura C.1: Configuración switch Core
66 APÉNDICE C. CONFIGURACIONES DE LOS SWITCHES

1 name SERVIDORES
2 !
3 vlan150
4 name TURNOS
5 !
6 vlan200
7 name METROLAN
8 !
9 vlan250
10 name EXTERIOR
11 !
12 !
13 !
14 track 3 ip sla 3 reachability
15 delay down 5 up 5
16 ip routing
18 !
19 interface Port-channel1
20 description Planta_1
21 switchport trunk encapsulation dot1q
22 switchport trunk allowed vlan 1,11,12,16,17,150
23 switchport mode trunk
24 !
28 switchport trunk allowed vlan 1,13,14
30 !
36 !
38 description Visados
40 switchport trunk allowed vlan 100
42 !
44 description Exp_consular
48 !
50 description Pasaportes
54 !
56 description Certificados
60 !
APÉNDICE C. CONFIGURACIONES DE LOS SWITCHES 67

2 description Turnos
6 !
8 description P_control
12 !
13 !
14 !
15 interface Gi1/0/1
20 channel-group 1 mode active
21 !
28 !
35 !
37 description Invitados
41 !
43 description Proxy
47 !
54 !

1 !
8 !
15 !
22 !
24 description Metrolan
28 !
30 description Exterior
34 !
41 !
48 !
55 !


2 !
4 description Proxy
8 !
10 description Invitados
14 !
21 !
28 !
35 !
42 !
49 !
51 description Exterior
55 !
57 description Metrolan

1 !
8 !
9 !
10 !
11 interface Vlan1
12 description GESTION
13 ip address 172.20.1.1 255.255.255.240
14 !
15 interface vlan11
16 description CERTIFICADOS
17 ip address 172.20.11.1 255.255.255.240
18 !
19 interface vlan12
20 description DNI
21 ip address 172.20.12.1 255.255.255.240
22 !
23 interface vlan13
24 description PASAPORTES
25 ip address 172.20.13.1 255.255.255.240
26 !
27 interface vlan14
28 description CONTABILIDAD
29 ip address 172.20.14.1 255.255.255.240
30 !
31 interface vlan15
32 description CONSULES
33 ip address 172.20.15.1 255.255.255.240
34 !
35 interface vlan16
36 description REG_CIVIL
37 ip address 172.20.16.1 255.255.255.240
38 !
39 interface vlan17
40 description LEGALIZACION
41 ip address 172.20.17.1 255.255.255.240
42 !
43 interface vlan50
44 description INVITADOS
45 ip address 172.20.50.1 255.255.255.240
46 !
47 interface vlan200
48 description METROLAN
49 ip address 172.20.200.1 255.255.255.240
50 !
52 description EXTERIOR
53 ip address 172.20.250.1 255.255.255.248
54 !
56 description SERVIDORES
57 ip address 172.20.100.1 255.255.255.240
58 !
60 description TURNOS

1 ip address 172.20.150.1 255.255.255.240

2 ip access-group 100 in
3 !
4 no ip http server
5 no ip http secure-server
6 !
7 !
8 ip route 0.0.0.0 0.0.0.0 172.20.250.10
9 !
10 !
11 ip sla 3
12 dns www.google.es name-server 8.8.8.8
13 frequency 300
14 ip sla schedule 3 life forever start-time now
15 ip sla enable reaction-alerts
16 logging esm config
17 !
18 !
19 access-list 100 permit ip 172.20.150.0 255.255.255.240 any
20 access-list 100 deny any any
21 !
22 !
23 !
24 !
25 line con 0
26 password 7 06110E2F404F07
27 login
28 line vty 0 4
29 password 7 15050A02082B25
30 login local
31 transport input telnet
32 transport output telnet
33 line vty 5 15
34 password 7 03135A050A0E2F
35 login local
38 !
39 !
40 event manager session cli username "admin"
41 event manager applet Next_Hop_PRODUCCION-Embajada
42 event syslog pattern " %TRACKING-5-STATE: 3 ip sla 3 reachability Up->Down"
43 action 1.0 cli command "enable"
44 action 2.0 cli command "configure terminal"
45 action 3.0 cli command "no ip route 0.0.0.0 0.0.0.0 172.20.250.10"
46 action 4.0 cli command "ip route 0.0.0.0 0.0.0.0 10.0.200.2"
47 action 5.0 cli command "exit"
48 action 6.0 cli command "write"
49 event manager applet Next_Hop_PRODUCCION-Directo
50 event syslog pattern "TRACKING-5-STATE: 3 ip sla 3 reachability Down->Up"
51 action 1.0 cli command "enable"
52 action 2.0 cli command "configure terminal"
53 action 3.0 cli command "no ip route 0.0.0.0 0.0.0.0 10.0.200.2"
54 action 4.0 cli command "ip route 0.0.0.0 0.0.0.0 172.20.250.10"
55 action 5.0 cli command "exit"
56 action 6.0 cli command "write"
57 !
58 !
59 end

C.2 Planta 1 Cisco Catalyst 2960S-24TS-L
1
2 !
3 version 12.2
4 no service pad
8 !
9 hostname ACCESO1
10 !
12 boot-end-marker
13 !
14 !
16 !
18 no aaa new-model
21 vtp mode on
22 vtp mode client
23 !
26 !
29 !
31 !
37 !
38 !
39 !
40 !
41 interface Gi0/1
47 !
48 interface Gi0/2
54 !
55 interface FastEthernet0/1
56 description legalizacion1
57 switchport access vlan 17
58 switchport mode access
59 spanning-tree portfast
60 !
Figura C.8: Configuración switch Planta 1

6 !
12 !
14 description reg_civil1
18 !
24 !
30 !
32 description dni1
36 !
38 description dni2
42 !
44 description certificados1
48 !
54 !
60 !


4 !
10 !
16 !
22 !
24 description ges_turnos
28 !
29 interface Vlan1
31 ip address 172.20.1.11 255.255.255.240
32
33 ip default-gateway 172.20.1.1
34 !
35 line con 0
36 password 7 06110E2F404F07
37 login
38 line vty 0 4
39 password 7 15050A02082B25
40 login local
43 line vty 5 15
45 login local
48 !
49 !
50 end

1
2 !
3 version 12.2
4 no service pad
8 !
9 hostname ACCESO2
10 !
12 boot-end-marker
13 !
14 !
16 !
18 no aaa new-model
21 vtp mode on
22 vtp mode client
23 !
26 !
29 !
31 !
37 !
38 !
39 !
40 !
41 interface Gi0/1
47 !
48 interface Gi0/2
54 !
56 description pasaportes1
60 !

6 !
12 !
18 !
24 !
30 !
36 !
42 !
48 !
54 !
56 description contabilidad1
60 !
62 description contabilidad2


4 !
5 interface Vlan1
7 ip address 172.20.1.12 255.255.255.240
9 !
10 line con 0
11 password 7 06110E2F404F07
12 login
13 line vty 0 4
14 password 7 15050A02082B25
15 login local
18 line vty 5 15
20 login local
23 !
24 !
25 end

1 !
2 version 12.2
3 no service pad
7 !
8 hostname ACCESO3
9 !
11 boot-end-marker
12 !
13 !
15 !
17 no aaa new-model
20 vtp mode on
21 vtp mode client
22 !
25 !
28 !
30 !
36 !
37 !
38 interface Gi0/1
44 !
45 interface Gi0/2
51 !
53 description consules1
57 !


3 !
9 !
15 !
21 !
27 !
33 !
35 description visados1
39 !
45 !
51 !
57 !


3 !
9 !
15 !
16 interface Vlan1
18 ip address 172.20.1.13 255.255.255.240
20 !
21 line con 0
22 password 7 06110E2F404F07
23 login
24 line vty 0 4
25 password 7 15050A02082B25
26 login local
29 line vty 5 15
31 login local
34 !
35 !
36 end

Diseño de La Arquitectura de Red Basado en La Seguridad, Monitorizacion y Alta Disponibilidad - 2015

Cargado por

Copyright:

Formatos disponibles

Diseño de La Arquitectura de Red Basado en La Seguridad, Monitorizacion y Alta Disponibilidad - 2015

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Diseño de La Arquitectura de Red Basado en La Seguridad, Monitorizacion y Alta Disponibilidad - 2015

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD

TRABAJO DE FIN DE GRADO

MEHDI AMARTI CHERTI

AUTOR: Mehdi Amarti Cherti

Resumen — A lo largo de estas últimas décadas se ha podido observar que la conexión

2 Estado del arte 3

3 Análisis del problema 7

7 Conclusiones y Trabajo futuro 49

A Nomenclatura de Cables, Latiguillos y Switches 53

C Configuraciones de los Switches 65

VIII ÍNDICE DE CUADROS

4.1 Diagrama lógico de red global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.1 Arquitectura de Red estándar TIA-942 . . . . . . . . . . . . . . . . . . . . . . . 26

6.1 Descripcion producto Kiwi Syslog Free Edition . . . . . . . . . . . . . . . . . . . 43

7.1 Eliminación MetroLan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

A.1 Tabla categorı́as . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

A.4 Nomenclatura Cable de Inter-salas . . . . . . . . . . . . . . . . . . . . . . . . . . 55

B.1 Visión general Gestor de turno . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

C.1 Configuración switch Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

CGRM Consulado General del Reino de Marruecos

SPOF Es un componente de un sistema que tras un fallo en su funcionamiento ocasiona un fallo

CPD Centro de procesamiento de datos.

DMZ Red demilitarizada.

1.2 Fases de realización

1.3 Estructura del documento

En el capı́tulo 3 se efectuará un análisis de la solución. Se recogerá en una lista de requisitos.

En el capı́tulo 4 se explicará cómo se ha diseñado y desarrollado la solución, ası́ como la

En el capı́tulo 5 se describirá el proceso de implementación de la red de manera mas profunda.

En el capı́tulo 6 se explicará cómo se procede a la integración de cada uno de los módulos

2.2 Centro de procesamiento de datos

El procedimiento de redundancia y alta disponibilidad de nuestro sistema se basará en el con-

Las infraestructuras tecnológicas son un aspecto crucial en la mayorı́a de las organizaciones

La TIA-942(Asociación de la Industria de Telecomunicaciones), especifica los requisitos

1. Creación de zonas desmilitarizadas (DMZ).

2.3 Trabajo previo

4 CAPÍTULO 2. ESTADO DEL ARTE

CAPÍTULO 2. ESTADO DEL ARTE 5

6 CAPÍTULO 2. ESTADO DEL ARTE

3.2 Análisis de requisitos

3.2.1 Requisitos funcionales

• Red de invitados:Esta parte se encargará de recoger la información necesaria para crear

RF2: Dar acceso a las aplicaciones correspondientes en cada departamento.

RF3: Control de acceso a internet.

RF4: Instalar un puesto de control.

RF5: Instalar un gestor de turnos.

RF7: Establecer una conexión punto a punto entre las 2 sedes.

RF8.1: Conectividad a personal externo que accede al consulado como invitado.

RF9: Proporcionar acceso a servicios en Internet.

3.2.2 Requisitos no funcionales

RNF1: Fiabilidad. Garantizar que el sistema continúe funcionando en un determinado

RNF2: Elasticidad. Tenga capacidad el sistema para adaptarse a condiciones externas

RNF4: Mantenibilidad. Tener capacidad de realizar una reparación satisfactoria en un

RNF7: Recuperación ante desastres (Disaster Recovery). Capacidad de la instalación de

8 CAPÍTULO 3. ANÁLISIS DEL PROBLEMA

RNF8 : Escalabilidad. Poder adaptarse a los futuros movimientos.

RNF9: Seguridad. Garantizar a los usuarios legı́timos la confidencialidad de sus comu-

RNF11: Seguridad. Detectar y parar cualquier intento de ataque a otras organizaciones

RNF12: Disponibilidad. Al tratarse de un servicio prestado por el Consulado a los invi-

CAPÍTULO 3. ANÁLISIS DEL PROBLEMA 9