lpp trabajo final - WordPress.com · 2016-04-10 · 2 Historia de las LAN Party. En primer lugar,...

LPP TRABAJO FINAL

ALEJANDRO ACEDO FAJARDO

PEDRO ÁLVAREZ GUIRADO

JOSE ÁNGEL EXPÓSITO ARENAS

PEDRO LUIS FUERTES MORENO

SARA GÁMIZ PÉREZ

ALEJANDRO GÓMEZ ALANÍS

DANIEL HERNÁNDEZ BÉLANGER

ANTONIO MARTÍNEZ RUIZ

PILAR MOREU FALCÓN

FRANCISCO PORCEL RODRÍGUEZ

17 DE ENERO DE 2016

LABORATORIO DE TELEMÁTICA

4º GITT (UGR)

1

LPP v1.0 DOCUMENTO FINAL

Contenido

Introducción. ........................................................................................................ 5 1

Historia de las LAN Party. ................................................................................. 7 2

Objetivos. ............................................................................................................ 12 3

Requisitos ........................................................................................................... 15 4

Propuestas de diseño de red .............................................................................. 19 5

5.1 Primera propuesta de diseño de red .............................................................. 20

5.2 Segunda propuesta de diseño de red ............................................................ 24

5.3 Tercera propuesta de diseño de red .............................................................. 26

5.4 Comparación de propuestas de diseño de red .............................................. 29

Diseño de la red de la LPP ................................................................................ 31 6

6.1 Arquitectura y protocolos ............................................................................. 31

VLAN ....................................................................................................... 31 6.1.1

802.1q ....................................................................................................... 31 6.1.2

STP ........................................................................................................... 31 6.1.3

DHCP ....................................................................................................... 32 6.1.4

NAT .......................................................................................................... 32 6.1.5

NTP ........................................................................................................... 32 6.1.6

6.2 Topología lógica y física .............................................................................. 32

6.3 Configuración a nivel físico ......................................................................... 42

6.4 Diseño de VLANs y trunking....................................................................... 43

6.5 Jerarquía y direccionamiento IP. .................................................................. 48

6.6 Protocolos y Servicios de Red ...................................................................... 52

Servicio DHCP ......................................................................................... 52 6.6.1

Servicio NAT ............................................................................................ 55 6.6.2

Servicio NTP ............................................................................................ 57 6.6.3

6.7 Interconexión con ISP .................................................................................. 58

6.8 Seguridad ...................................................................................................... 59

Seguridad en nivel de acceso .................................................................... 59 6.8.1

Seguridad en nivel de distribución ........................................................... 61 6.8.2

Seguridad en Internet ................................................................................ 64 6.8.3

6.9 Comportamiento de servicios y disponibilidad ............................................ 66

Técnicas de compartición de carga, y balanceo. ...................................... 66 6.9.1

Recomendaciones para redundancia. ........................................................ 68 6.9.2

Conclusión ................................................................................................ 69 6.9.3

6.10 Inventario de Hardware y software de equipos que componen la red ......... 69

2


6.11 Presupuesto................................................................................................... 72

Presupuesto mano de obra ................................................................. 73 6.11.1

Juegos y aplicaciones ......................................................................................... 74 7

7.1 Minecraft ...................................................................................................... 74

Información detallada del juego ............................................................... 74 7.1.1

Funcionamiento ........................................................................................ 74 7.1.2

Modos de juego ........................................................................................ 75 7.1.3

Plataformas ............................................................................................... 75 7.1.4

Requisitos ................................................................................................. 76 7.1.5

Dispositivos/software necesario ............................................................... 76 7.1.6

Licencias/Modo de operación ................................................................... 76 7.1.7

Técnicas de virtualización empleadas ...................................................... 76 7.1.8

Plan de contingencia en caso de fallo ....................................................... 77 7.1.9

Instrucciones para arrancar Minecraft en el servidor local ............... 77 7.1.10

Servidor y propiedades ...................................................................... 77 7.1.11

Caracterización del tráfico LAN/WAN generado ............................. 77 7.1.12

Implementación de QoS .................................................................... 78 7.1.13

7.2 Hearthstone................................................................................................... 78

Información detallada del juego ............................................................... 78 7.2.1

Desarrollo del juego.................................................................................. 78 7.2.2

Dispositivos/software necesario ............................................................... 79 7.2.3

Licencias para llevar a cabo el torneo ...................................................... 79 7.2.4

Tráfico generado ....................................................................................... 80 7.2.5

7.3 Implementación de la QoS ........................................................................... 80

Monitorización y gestión de red ....................................................................... 82 8

8.1 Protocolos ..................................................................................................... 82

SNMP ....................................................................................................... 82 8.1.1

Port Mirroring ........................................................................................... 83 8.1.2

8.2 Aplicaciones ................................................................................................. 83

The Dude .................................................................................................. 83 8.2.1

8.3 Medición cuellos de botella en segmentos/enlaces de acceso y troncales ... 83

8.4 Medición de parámetros típicos de QoS: pérdidas de paquetes, latencias y

jitters………. .............................................................................................................. 84

8.5 Monitorización y seguimiento de estaciones conflictivas. ........................... 84

Consumo eléctrico ............................................................................................. 85 9

Planificación ................................................................................................... 88 10

10.1 Tareas ........................................................................................................... 88

3


10.2 Diagrama de Gantt ....................................................................................... 90

10.3 Tablas de validación de tareas ...................................................................... 92

Verificación y validación de la LPP ........................................................... 100 11

11.1 Conmutación entre VLANs ........................................................................ 102

11.2 Balanceo de Carga mediante STP .............................................................. 102

11.3 DHCP ......................................................................................................... 105

11.4 NAT ............................................................................................................ 107

11.5 NTP ............................................................................................................ 108

11.6 Control de tormentas de broadcast ............................................................. 108

11.7 Listas de acceso .......................................................................................... 109

Gestión y administración ............................................................................. 111 12

12.1 Organización de la LPP .............................................................................. 111

Organigrama Jerárquico .................................................................. 113 12.1.1

Reglamento Interno ......................................................................... 114 12.1.2

Reglas de juegos y torneos .............................................................. 120 12.1.3

12.2 Gestión de usuarios .................................................................................... 135

Reglamentos y reglas de la LPP ...................................................... 135 12.2.1

Administración y perfil de usuarios ................................................ 137 12.2.2

12.3 Aspectos legales ......................................................................................... 138

Seguridad física ............................................................................... 138 12.3.1

Protección de datos.......................................................................... 139 12.3.2

Uso de Licencias ............................................................................. 140 12.3.3

Conexión a redes P2P y compartición de contenidos ..................... 140 12.3.4

12.4 Planes de contingencia ............................................................................... 141

Consideraciones ECO .................................................................................. 144 13

Servicios LPP ................................................................................................ 147 14

14.1 Cámara IP ................................................................................................... 147

Introducción .................................................................................... 147 14.1.1

Funcionamiento básico .................................................................... 147 14.1.2

Tráfico generado ............................................................................. 151 14.1.3

Implementación ............................................................................... 152 14.1.4

14.2 Servicio de almacenamiento en nube Owncloud ....................................... 152

Objetivos y directrices ..................................................................... 152 14.2.1

Arquitectura ..................................................................................... 152 14.2.2

Configuración .................................................................................. 152 14.2.3

Más ajustes ...................................................................................... 154 14.2.4

Ajustes del .htaccess ........................................................................ 155 14.2.5

4


14.3 Servicio de mensajería instantánea ............................................................ 155

14.4 Facebook .................................................................................................... 156

14.5 Twitter ........................................................................................................ 157

14.6 Página web ................................................................................................. 158

Anexos ........................................................................................................... 160 15

15.1 Comandos para el direccionamiento IP estáticos ....................................... 160

15.2 Comandos para configuración de VLANs y troncales ............................... 161

15.3 Configuración de balanceo de carga .......................................................... 170

15.4 Configuración DHCP ................................................................................. 171

15.5 Configuración NAT.................................................................................... 172

15.6 Configuración NTP .................................................................................... 173

15.7 Configuración para control de tormentas de broadcast .............................. 173

15.8 Configuración para seguridad por MAC .................................................... 173

15.9 Configuración de listas de acceso .............................................................. 173

15.10 Configuración de calidad de servicio QoS: ................................................ 176

15.11 Configuración del servidor Minecraft ........................................................ 180

15.12 Comandos para configurar SNMP ............................................................. 187

Configuración de la estación gestora para las Traps ....................... 187 15.12.1

Comandos auxiliaries ...................................................................... 187 15.12.2

Configuración de los dispositivos gestionados (Switches) ............. 188 15.12.3

15.13 Configuración de Port Mirroring................................................................ 188

5


Introducción. 1

El proyecto desarrollado a continuación se trata de una propuesta real de la creación,

diseño y puesta en marcha de una LAN Party Piloto (LPP) en la Universidad de

Granada, concretamente en la Escuela Técnica Superior de Ingenierías Informática y de

Telecomunicación (ETSIIT).

Este proyecto nace como un complemento básico para la formación de los futuros

ingenieros de telecomunicaciones de la Escuela, que les ayudará a adquirir ciertos

conocimientos prácticos y teóricos para el desarrollo de futuros proyectos en el ámbito

de las telecomunicaciones como lo es el diseño, monitorización y diseño de redes, la

solución de posibles errores y problemas, etc. Además, este proyecto servirá como un

buen entrenamiento de la vida profesional que el alumno llevará a cabo en unos años.

Mediante el reto LPP se pretende que el alumnado adquiera, profundice y ponga en

práctica aquellos conocimientos sobre redes y sistemas telemáticos aprendidos durante

el grado de Ingeniería en Tecnologías de Telecomunicación y en concreto en la

asignatura Laboratorio de Telemática. Por otra parte, mediante la puesta en marcha del

proyecto los alumnos serán capaces de trabajar en un ambiente similar al que les espera

dentro de unos años en el mundo laboral, en el que será imprescindible la organización

de tareas y personal, el trabajo en equipo y sobre todo la labor de un líder que coordine

y fije cada uno de los sub-proyectos para así sacar el máximo partido de los

conocimientos y habilidades de los participantes del proyecto y maximizar el

rendimiento y éxito de éste. Por ello, el reto a realizar les brinda una oportunidad única

para aprender lo que en un futuro será su día a día, y además permitirá que se aclaren y

profundicen todos los conocimientos que se han adquirido, pero nunca se han puesto en

práctica completando así su aprendizaje.

Tal y como se ha comentado, la puesta en marcha del evento se hará en la ETSIIT

por lo que se tendrá una LPP a pequeña escala debido a que no se puede ocupar todo el

espacio de la Escuela y debido a que el alumnado no tendrá todos los conocimientos ni

medios como para hacer un gran evento, sino que el objetivo de éste es el completo

aprendizaje de ellos. En definitiva puesto que la creación del evento no se llevará a cabo

por profesionales es necesario reducir la escalabilidad de éste para evitar riesgos

innecesarios y garantizar una cierta calidad y la finalización de la LPP de manera

exitosa.

Por todo ello, este proyecto se realiza teniendo en cuenta las limitaciones y

restricciones consecuentes de realizar el evento con los recursos disponibles en la

ETSIIT, del hecho de ser una asignatura de enseñanza reglada y por el hecho de que se

realizará en su totalidad por alumnos del grado. Todas estas limitaciones se

mencionarán y explicarán posteriormente.

Las LAN Parties pueden tener diferentes objetivos en función de las necesidades de

los encargados de su creación. A día de hoy existen tres posibilidades pero a medida que

la práctica de este evento se va haciendo más popular irán surgiendo nuevas necesidades

y por tanto nuevos tipos de LP.

Si bien se trata de una empresa que ofrece el servicio por un precio específico y con

el fin meramente económico se denomina LAN Party con fin económico y se suelen

6


desarrollar en espacios físicos grandes con conectividad a internet fija, es decir, la

empresa ofrece una infraestructura de red montada y permanente así como la utilería

necesaria (mesas, sillas, etc.). Normalmente los participantes que acuden a este tipo de

evento son personas individuales, visitantes casuales y, en escasas ocasiones, grupos

para practicar o jugar.

En cambio, si el evento presenta una alta asistencia de participantes (antiguos

participantes, grupos de personas conocidas entre sí o incluso desconocidos) se requiere

una organización formal que se encargue del montaje de éste, del alquiler del local e

infraestructura de red, etc. Este tipo de LP se denomina LAN Party ocasional masiva y

suele realizarse en unas fechas concretas (fin de semanas, ferias o fechas históricas de la

organización o del origen de las LAN Parties).

Por último, existe la denominada LAN Party casera. Este evento, como es de esperar,

fue el primer tipo de LP que existió y se caracteriza porque los asistentes suelen ser

amigos y se desarrolla en un lugar pequeño (piso, garaje, pequeño local, etc.). En este

tipo de LP no siempre se paga una inscripción aunque resulta útil para cubrir el gasto

económico correspondiente al elevado consumo de energía que puede tener este evento.

Por todo lo anterior las LAN Parties caseras se caracterizan por tener un ambiente

privado. A continuación se comprobará que este último tipo de LAN Party es la que se

llevará a cabo en este proyecto puesto que el número de participantes será escaso y

probablemente todos ellos pertenezcan a la Escuela ya que el espacio físico en el que se

desarrollará es reducido.

En cuanto a la duración del proyecto a desarrollar esta puede ser de unas horas, una

noche o incluso varios días, como suele ocurrir normalmente. Sin embargo, en este caso

la duración de la LAN Party Piloto dependerá de las limitaciones impuestas por la

Escuela, de modo que este dato se conocerá posteriormente y una vez estudiadas las

limitaciones y requisitos.

7


Historia de las LAN Party. 2

En primer lugar, se define una LAN Party (LP) como un evento en el que se reúne un

grupo de personas con sus ordenadores con el fin de jugar a videojuegos, compartir e

intercambiar información e incluso en las LP más recientes de disfrutar de conciertos,

conferencias, talleres y otras actividades de ocio relacionadas con el mundo tecnológico

(seguridad informática, multimedia e imagen, robótica, etc.). Por tanto, este tipo de

evento tiene como principal objetivo el compartir y aprender con otros usuarios

conocimientos sobre la tecnología de la información y las comunicaciones así como la

diversión de todos y cada uno de los participantes.

La denominación de este evento tiene su origen en la manera en la que se

interconectan los ordenadores de los participantes, esto es, mediante una red de área

local (LAN). Este tipo de red permite que el intercambio de datos entre los equipos

pertenecientes a la LAN se realice a altas velocidades. Además, en función del número

de participantes y de la velocidad mínima requerida y el rendimiento para que todos

ellos asistan al evento satisfactoriamente las redes pueden ser inalámbricas o cableadas.

Normalmente, en este tipo de evento utilizamos redes cableadas puesto que pueden

alcanzarse mayores velocidades y rendimiento debido a que únicamente se tienen en

cuenta las interferencias de la propia red LAN.

Las ahora denominadas LAN Parties no son una moda actual, es más lleva

practicándose durante más de 10 años. Originariamente esta práctica no era conocida

como un evento a gran escala sino que comenzó como pequeñas reuniones entre

universitarios que se reunían en el piso de uno de ellos para jugar a ciertos videojuegos

durante dos o tres días y para paliar la necesidad de compartir recursos a bajo coste. A

pesar de ello, las LAN Parties comenzaron como reuniones en las que se competía en

distintos videojuegos y más tarde, cuando la tecnología evolucionó comenzó a ser más

popular ese intercambio de información y software. Normalmente los participantes se

conectaban a un servidor de Internet en línea y añadían una palabra delante de su

usuario en los videojuegos para indicar al resto de jugadores que son un grupo. En sus

inicios estas reuniones eran muy comunes en el norte de Europa, por lo que se dice que

las LAN Parties tienen su origen allí. Este tipo de reuniones se hicieron cada vez más

populares entre los estudiantes, hasta tal punto de que no cupieran más personas en el

piso.

Fig. 2.1. Primeras LAN Parties

A principios del año 2000 las LAN Parties privadas alcanzaron su pico de

popularidad a pesar de que el acceso Internet de banda ancha que estaba disponible era

8


demasiado caro para la mayoría de las personas interesadas en esta práctica, en su

mayoría estudiantes. Sin embargo, se realizaban estas reuniones que cada vez fueron

creciendo en número de participantes y que incluían otro tipo de actividades además de

competir en videojuegos multijugador. Para la realización de estas reuniones bastaba

con tener conexión inalámbrica, una buena cantidad de energía y las superficies

adecuadas para todos los equipos.

En este momento, uno de los principales objetivos de los asistentes y por tanto, una

nueva práctica incluida en este tipo de evento fue la oportunidad de compartir software,

películas o música. Este hecho marcó un antes y un después en el mundo tecnológico y

sobre todo en la historia de las LAN Parties ya que el intercambio de archivos a través

de redes LAN de forma cómoda entre los participantes resultaba algo novedoso e

increíble para aquellos usuarios, en esta época la mayoría, que no tenían acceso a la alta

velocidad y ancho de banda que una conexión a internet de banda ancha ofrecía.

Más tarde, las LAN Parties tradicionales compartieron protagonismo con una nueva

práctica, la aparición de consolas centralizadas en la red, como Xbox 360 y PlayStation

3. Esto provocó que las LAN Parties no tuvieran la exclusividad de juegos en red ya que

estas nuevas consolas permitían esa misma práctica, denominándose este tipo de evento

como LAN Parties basadas en consola. Por ello, para que las LP no se extinguieran fue

crucial incluir las competiciones con estas consolas. De este modo, las LAN Parties

tradicionales evolucionaron dando lugar a LP en las que se podía competir mediante

ordenadores o consolas.

A pesar de esta nueva práctica, en las LAN Parties de la época siguieron siendo

populares los ordenadores ya que competir mediante consolas requería tener una

consola por participante, juegos y televisiones y en esos tiempos no todo era tan

sencillo. Por ello, muchos de los juegos multijugador populares para la consola se

adaptaron y sus desarrolladores sacaron su versión para PC. De este modo, los

desarrolladores de los juegos más populares dieron a los consumidores la opción de

poder disfrutar los mismos juegos en múltiples plataformas.

Este último acontecimiento provocó que en el siglo XXI surgiera un escenario

alternativo, las grandes LAN Parties, evento que se realiza actualmente y consiste en

ofrecer diversos torneos, con grandes premios y una asistencia de participantes elevada.

Estos premios pasaron a ser hardware (cascos, ventiladores, tarjetas gráficas, etc.) e

incluso ordenadores. Para la realización de este evento el anfitrión u organización utiliza

equipos que harán de servidores de los videojuegos en los que se compiten. Con la

aparición de las grandes LP la duración de este evento pasó de ser unas horas o como

mucho un día a albergar eventos de hasta una semana. Por ello, se ofrecen tranquilos

espacios para dormir, lugares para el aseo personal y zona de restauración y ocio

alternativo. Sin embargo, a día de hoy la duración no ha sido estandarizada y varía en

función de la organización que realice la LAN Party. Otro aspecto que mejoró en la

evolución de las LAN Parties tradicionales a las grandes LAN Parties fue la seguridad

tanto física como informática. De este modo, la organización debe contratar a

profesionales especializados en este ámbito incrementando así el número de personas

que se encargan de la puesta en marcha del evento y por tanto el coste económico de

éste. Por todo ello, a partir de este momento se comenzó a poner una cuota de

inscripción a los diferentes usuarios en función de los servicios que desean disfrutar.

9


Otro aspecto relevante de las LAN Parties y que cada vez cobra mayor importancia

es la posibilidad de asistir a este evento a pesar de celebrarse en otra ciudad o país

diferente a tu lugar de residencia. De este modo, mediante un software VPN como

Hamachi es posible organizar los ordenadores a través de Internet pareciendo que están

en la misma LAN. Este hecho en un principio servía para que los participantes

extranjeros o que tenían imposibilidad de asistir al evento pudieran disfrutar de sus

servicios desde su casa. Sin embargo, en la actualidad esta práctica se ha extendido y

cada vez existe un mayor número de servicios que se aprovechan de esta conexión, de

manera que se puede ofrecer conferencias y talleres desde cualquier parte del mundo.

Del mismo modo que han evolucionado las LAN Parties en la última década también

lo han hecho los usuarios que participan en ellas. Inicialmente los participantes de las

pequeñas LP privadas eran grupos de amigos que se reunían para disfrutar de los

videojuegos e intercambio de información en red. Posteriormente la mayoría de estos

grupos de jugadores acudían al evento con el único objetivo de ganar torneos,

mejorando así en la clasificación en ligas nacionales e internacionales de ciertos

videojuegos. Con la aparición y éxito de las grandes LAN Parties los participantes de

este evento fueron cada vez más diversos, desde estos mismos clanes que pretendían

alzarse con el primer puesto de las ligas hasta asistentes casuales e individuales que

participan para intercambiar recursos a velocidades elevadas.

Análogamente a la evolución de esta fiesta también ha sido necesario la mejora y

evolución de los videojuegos y todo el software relacionado con ellos. En las primeras

LAN Parties privadas debido al reducido número de jugadores estos juegos

generalmente se jugaban en pequeños niveles y/o contra robots. Además, para que los

participantes disfrutaran al máximo de la experiencia utilizaban software como

TeamSpeak (chat de voz sobre IP), Steam (plataforma de distribución digital de

videojuegos desarrollados por „Valve‟) y las redes sociales. De este modo, también era

posible que los clanes o grupos de amigos pudieran disfrutar de la experiencia desde sus

propios hogares.

Los primeros juegos surgieron en los 70‟s (Larn, Hack, Rogue y Hunt the Wumpus)

y fueron mejorando durante los 80‟s para permitir tener cuatro jugadores simultáneos de

forma estable. Más tarde se crearon los primeros videojuegos tipo “shooter” en los que

se jugaba en primera persona. Algunos de los software más comunes fueron

Wolfenstein 3D, Doom o Quake. La mejora de los videojuegos y el aumento del

número de participantes ayudaron a incrementar la popularidad de las LAN Parties. Por

tanto, en ese momento tuvo lugar la primera LAN Party en 1996, denominada

QuakeCon ya que el principal videojuego era Quake puesto que permitía jugar

simultáneamente a 16 personas. Esta primera LAN Party se desarrolló en Texas y reunió

a más de 200 personas. Pasados los años surgieron otros juegos de estrategia como

Command & Conquer, Warcraft, Counter Strike y Starcraft que más tarde fueron muy

exitosos, incluso alguno de ellos sigue siendo popular en la actualidad. Hoy en día, los

videojuegos más populares de las LAN Parties son Starcraft II, Hearthstone, Call of

duty, Street Fighter o League of Legends, entre otros.

Con la aparición de las LAN Parties basadas en consola aparecieron otras actividades

y juegos en este evento como simuladores de avión o juegos como FIFA Soccer y

Falcon 4.0. Debido a la evolución tecnológica este tipo de evento fue cobrando mayor

importancia y la afluencia de participantes aumentó considerablemente, sobre todo con

10


el lanzamiento del sistema operativo multitarea Windows 95, que tenía tarjetas LAN de

muy bajo coste (Ethernet).

En España, la primera y más famosa LAN Party se creó en 1997 bajo el nombre de

Campus Party y se celebró en semana santa en Málaga patrocinada por las empresas

3com, OKI y Guillemot. En sus comienzos ofrecía otras actividades además de las que

se desarrollan en las LP. Estas nuevas actividades podían ser desde conferencias y

talleres hasta drones y diseños de videojuegos o incluso multimedia y fotografía. En la

actualidad este tipo de actividades son muy comunes en todos los tipos de LAN Party

celebrados en todo el mundo. Más tarde, se crearon otras LP que a día de hoy siguen

celebrándose como la Euskal Amiga Party (creada en 1994 y denominada más tarde

Euskal Encounter 2003) y la Tenerife LAN Party (creada en 2006 por una asociación de

ingenieros). De todas ellas, la más importante es la Campus Party, que hoy en día

celebra ediciones en todo el mundo. En su última edición en San Salvador, contaba con

numerosos áreas como astronomía, creatividad, innovación, juegos, desarrolladores… y

estaba patrocinada por el gobierno de El Salvador y empresas importantes como Coca

Cola, Diario el Mundo, etc.

Actualmente existe una gran variedad de LAN Parties desarrolladas en todos los

países del mundo: DreamHack, Campus Party, Insomnio Festival, LANFest NETWAR,

Lanwar, The Gathering, Gaming Scotland, QuakeCon, etc. Sin embargo, la más

importante de todas ellas es la DreamHack, evento que comenzó como una reunión

entre amigos en el sótano de un colegio de Malung (Suecia) en 1994. Esta LAN Party

consta de cinco áreas: el evento en sí, las competiciones de videojuegos, de arte digital,

los conciertos y las exposiciones. Debido al éxito que tuvo este evento a partir de 2002

comenzaron a celebrarse dos ediciones por año (DreamHack Summer y DreamHack

Winter) convirtiéndose así en un evento semestral. Más tarde, en noviembre de 2012 la

organización de este evento se asoció con Electronic Sports League y Major League

Gaming para facilitar el crecimiento y desarrollo de los eSports norteamericanos y

europeos. En la primera DreamHack celebrada en 1997 asistieron 40 participantes y en

la actualidad, en el último evento celebrado y con estadísticas públicas la organización

logró un record mundial ya que asistieron 22810 participantes aunque únicamente

17403 personas hicieron uso de la infraestructura de red desplegada y los usuarios

restantes asistieron a las demás actividades culturales y de ocio digital. En esta última

edición la velocidad de Internet alcanzó una cifra de 40 Gbps, tal y como llevaba

haciendo en las cuatro últimas ediciones (años 2012 y 2013).

Por otra parte, es importante mencionar que la última edición celebrada en 2015 tuvo

lugar en Valencia (España) y el evento se dividió en tres zonas: zona LAN, donde se

disfruta de las competiciones; zona eSports, donde se presentan los mejores jugadores

del mundo y tiene lugar torneos nacionales y europeos; y la zona Expo, dónde las

empresas colaboradoras ofrecen sus productos en diversos stands. Este evento presenta

una página web muy completa en la que es posible documentarse de las actividades a

realizar, normas de conducta, tarifas, patrocinadores y otros hechos de interés.

En cuanto a la repercusión de las LAN Parties en podemos destacar tres tipos: social,

económica y mediática. Es sencillo ver que la principal repercusión económica que

presenta este tipo de eventos es el beneficio económico por parte de la organización

debido a las cuota de inscripción, patrocinios y ayudas así como para la ciudad en la que

se celebra ya que los participantes de las grandes LAN Parties deben alojarse en hoteles,

11


comer, etc. De este modo, la celebración de este evento es muy beneficiosa para la

ciudad en el ámbito económico y cultural ya que la afluencia de visitantes es muy

grande y se pueden organizar actividades alternativas y complementarias al evento por

la ciudad. Por otra parte, este hecho tiene una repercusión mediática muy grande puesto

que con él se está dando publicidad gratuita de la ciudad y con ello de las empresas que

patrocinan el evento. Por tanto resulta un evento con gran repercusión económica y

mediática para la ciudad y sus empresas. Un ejemplo de repercusión mediática es el

anuncio de retransmisiones en canales locales de la cuidad, en visitas culturales e

incluso galerías de fotos y vídeos que darán a conocer la ciudad. Por último, es

importante también considerar las repercusiones sociales puesto que una LAN Party

reúne un gran número de participantes que se reúnen con un mismo fin, disfrutar de la

tecnología e informática. Por ello, todos ellos se conocerán y se establecerán nuevas

relaciones sociales entre participantes ayudando así a la sociabilización por medio del

entretenimiento y aficiones en común.

12


Objetivos. 3

La realización de una LAN Party Piloto tiene diferentes objetivos en función del

punto de vista del estudio o del tipo de usuario. Para usuarios activos que se encargan de

la organización del evento los objetivos más importantes son los siguientes:

En primer lugar, el análisis de los requisitos y limitaciones según la posibilidad

y disponibilidad de recursos en la Escuela. Este análisis será crucial para que el

desarrollo del evento sea adecuado y satisfactorio puesto que en él se basan el

resto de objetivos y tareas del reto. Se trata de la base que sustenta todo el

proyecto y si algún requisito se ve modificado en cualquier momento es

probable que cambien algunos aspectos del proyecto diseñado, concretamente

aquellos en los que esté directamente relacionado.

Estudiadas las limitaciones y requisitos, los encargados de la realización de la

LPP son capaces de diseñar la red lógica y física así como los servicios que se

ofrecerán. Además es necesario buscar soluciones a los posibles problemas que

puedan surgir en la puesta en marcha del reto y encontrar el equipamiento

técnico disponible para así diseñar la red en función de estos recursos. Tal y

como puede verse, este aspecto está muy relacionado al anterior ya que si

aparece, desaparece o se modifica alguna limitación o requisito la red diseñada

se verá afectada directamente y los encargados de ello deberán solucionar

dicho problema. Por otra parte, es muy importante conocer a priori los equipos

y materiales con los se cuentan para así minimizar el coste económico de la

LPP y aprovechar al máximo los recursos disponibles. Este aspecto es aún más

importante en el proyecto desarrollado ya que se pondrá en marcha una LPP

por estudiantes en un espacio físico limitado y con un presupuesto reducido

puesto que el principal fin de este evento no es económico ni masivo sino el

mero aprendizaje de conceptos adquiridos en la asignatura Laboratorio de

Telemática y durante el grado.

El tercer objetivo o tarea a realizar es la instalación de la infraestructura de red

y servicios, una vez analizada y diseñada la red. Antes de realizar la instalación

es necesario que se realicen ciertas simulaciones y verificaciones para que este

tercer aspecto resulte sencillo y evitar problemas innecesarios. Por ello, los

encargados del diseño de la red y servicios deben asegurarse de que todo está

correcto con la ayuda del profesor de la asignatura y de compañeros

encargados de la verificación. Por otra parte, a la hora de poner en marcha

estas infraestructuras es imprescindible que se realice correctamente el proceso

completo de configuración de cada uno de los equipos así como la validación

de todos ellos.

Gestión y monitorización de la red. En esta tarea es necesario que se realice un

aprovisionamiento de recursos para cualquier incidencia ocurrida durante el

desarrollo del evento. Es importante monitorizar la red para que durante el

evento no se quede sin servicio ningún participante. Finalmente, una vez

comenzada la LAN Party Piloto se estudiará el tráfico cursado por cada usuario

y en total para que una vez finalizado el evento se haga una estadística de

tráfico. Del mismo modo, se pueden realizar todas las estadísticas que se

deseen relacionadas con ciertos aspectos de los participantes (edad, sexo o

13


procedencia), cantidad de datos intercambiados durante el evento, videojuegos

con mayor número de participantes, etc.

Durante el desarrollo del evento también será necesario encargarse de la

gestión de los usuarios. Esta gestión incluye el alta y baja de cada uno de los

usuarios a la red y a las competiciones en las que se desea participar, la

notificación de actividades y otros aspectos que los usuarios deban conocer.

Además, en el caso de realizarse una inscripción con coste económico es

importante que de forma ordenada se realiza la inscripción y recogida del

importe de la entrada para evitar pérdidas y que los usuarios no estén contentos

con los servicios prestados.

Gestión general del evento. Este aspecto incluye la seguridad física de la

infraestructura de red física, de los equipos de los participantes y de las

personas físicas que desean participar de las actividades y servicios prestados

en la LAN Party Piloto. Además de los aspectos de seguridad será necesario

supervisar la infraestructura de red para que cuando surja cualquier problema

pueda ser solucionado rápidamente y sin que los participantes noten nada. Por

otra parte, es importante que se esté monitorizando el tráfico, que se instalen

puestos de socorro, de restauración, aseos y demás servicios que cubran las

necesidades básicas de los participantes. Por último pero no menos importante,

para la correcta gestión del evento es necesario que se establezcan horarios de

trabajo organizados para que todos los alumnos encargados de la realización de

la LAN Party Piloto sepan previamente dónde y cuándo deben encontrarse en

cada momento, cuáles son su principales encargos y tareas y cómo solucionar

los posibles problemas que se presenten para que el desarrollo del evento sea

exitoso.

Generación de la documentación y presupuestos necesarios. Antes de la

instalación de la infraestructura de red y servicios es necesario que se realice

un presupuesto que incluya todos los gastos, fijos y adicionales en caso de

problemas, tanto de equipamiento como de mano de obra. En este proyecto

puesto que se realizará en su totalidad por el alumnado de la asignatura

Laboratorio de Telemática no se tendrá en cuenta la mano de obra a la hora de

realizar el presupuesto. Por otra parte, este presupuesto debe crearse acorde al

diseño topológico de la red y en caso de que no sea aceptado por el

departamento de la Escuela encargado de cubrir los gastos del evento, la

topología de la red debe ser modificada para minimizar el número de

materiales y así disminuir el presupuesto. Por otra parte, para la correcta

instalación es vital que se desarrolle un documento que explique de forma

exhaustiva los procedimientos y configuraciones necesarias para la correcta

instalación de la infraestructura de la red física y lógica así como de los

servicios que se prestarán en la LAN Party Piloto. Este documento debe

redactarse de manera que si se entregara a un técnico experto en la materia

fuera capaz de instalar la red deseada correctamente. Finalmente, tras el

desarrollo del evento deberán redactarse documentos que incluyan las

estadísticas pertinentes y las conclusiones obtenidas de la puesta en marcha de

la LPP.

14


Tal y como se comentó al principio, los objetivos descritos anteriormente

corresponden a las tareas a realizar por los encargados de la realización de la LAN Party

Piloto. De este modo, si se cumplen todos estos objetivos básicos el desarrollo del

evento será exitoso. Por otra parte, tal y como se dijo, los usuarios pasivos que

participan en la LPP, tales como los participantes de ésta, tienen unos objetivos

completamente distintos, que se describen a continuación.

El principal objetivo de los asistentes es la conexión directa de su ordenador con

el de otros participantes. Esta conexión se realizará mediante una tarjeta de red

Ethernet y permitirá alcanzar grandes velocidades de interconexión, imposibles

si estás conectado a Internet. De este modo, resulta muy fácil jugar a

videojuegos en línea y en tiempo real de forma que los asistentes podrán

competir entre ellos y además son capaces de conocerse físicamente y entablar

una conversación. Este es el objetivo de muchos de los asistentes ya que en sus

hogares pueden jugar a este tipo de juegos multijugador, sin embargo, en el

evento lo hacen a velocidades muy superiores y además tienen el plus de

conocer a sus contrincantes personalmente. Otra ventaja de la conexión directa

entre ordenadores es que casi instantáneamente puede intercambiarse archivos

de gran tamaño como vídeos, música o videojuegos.

Otro objetivo secundario es la posibilidad de intercambiar conocimientos con

otros usuarios amantes de la tecnología, compartiendo trucos, estrategias…

Además, en una LAN Party se puede probar de forma gratuita juegos que

saldrán al mercado, disfrutar de conciertos y talleres e incluso asistir a

conferencias que se están realizando en cualquier punto del mundo.

15


Requisitos 4

Para la creación y puesta en marcha de la LAN Party Piloto es necesario estudiar y

analizar previamente los requisitos y limitaciones, tal y como se indica en los objetivos

del proyecto. En primer lugar, se define el tamaño de la LPP y a partir de ahí se evalúan

las limitaciones que éste conlleva.

Espacio físico

En el proyecto a desarrollar se diseñará e instalará una LAN Party Piloto a pequeña

escala puesto que ésta se celebrará en la Escuela Técnica Superior de Ingenierías

Informática y de Telecomunicación, concretamente se dispone de tres aulas contiguas

(laboratorios 3.3, 3.4 y 3.5). Por tanto, en este espacio físico se debe situar el

equipamiento, infraestructura y organización del evento provocando así una

disminución del espacio reservado para los participantes a dos aulas. En concreto se

destinarán los laboratorios 3.3 y 3.5 para reunir los asistentes al evento de manera que

debido a que estos laboratorios poseen únicamente 22 puesto de trabajos se tendrá un

número máximo de asistentes esperados de 44 personas.

Si bien ahora se distribuye el espacio físico es fácil ver que el control de acceso y

seguridad se desarrollará en la entrada de los laboratorios 3.3 y 3.4, aulas destinadas a

congregar los participantes del evento. De este modo el laboratorio 3.4 se usará

exclusivamente para la organización del evento y por ello en él se situará el nivel de

distribución y Core, los servidores de los videojuegos y aplicaciones que ofrece el

evento y la monitorización y control del mismo. Por tanto, es imprescindible que esta

sala reúna mayor cantidad de alumnos para que se encarguen de la configuración e

instalación previa al evento y durante el mismo del control y seguridad informática y

física. Del mismo modo, no se puede dejar de lado la instalación, configuración y

control durante el evento de las infraestructuras de red en los laboratorios 3.3 y 3.5 ya

que si ocurre cualquier error o surge un problema en ellas los asistentes se quedarán sin

acceso a la red LAN.

Topología y diseño de red

Por otra parte, otro aspecto importante a considerar es la topología y diseño de la red.

Debido al espacio físico y a los recursos disponibles así como los requisitos por parte

del profesorado de la asignatura Laboratorio de Telemática se plantea un diseño

jerárquico de la red en una zona principal (ZP) y dos zonas secundarias (ZS).

La zona principal se diseñará e instalará en el laboratorio 3.4 y estará reservada para

la infraestructura de red y servicios así como para la gestión y monitorización de ésta.

En ella se diseñará el nivel de distribución y Core. Por una parte, el nivel de distribución

estará unido al nivel de acceso de los laboratorios contiguos, o lo que es lo mismo, de

las dos zonas secundarias. Esta unión se llevará a cabo mediante dos cables troncales de

Uplink por cada Switch de acceso que bien puede tratarse de tecnología Etherchannel o

balanceo de carga basado den STP para ayudar a que las velocidades de subida sean

elevadas. Par ello, se utilizará el rack de la Isla 2 de cada laboratorio. Por otra parte el

nivel de distribución debe proveerse de seguridad informática mediante ACLs, routing

entre VLANs u otros mecanismos que el alumnado crea convenientes, implementándose

las funcionalidades típicas de este nivel. Finalmente hay que tener en cuenta una

16


limitación impuesta por los recursos disponibles en la Escuela y es que tan solo se

dispone de un Switch Cisco WS-C3550-24-SMI lo que implicará que la red a diseñar

debe tener pequeñas dimensiones. A pesar de ello, esta limitación no va a causar

grandes cambios en la topología di diseño de red puesto que desde un principio el

alumnado conoce la escalabilidad de la LAN Party, siendo esta de pequeñas

dimensiones debido a la disponibilidad de aulas en la Escuela así como por los recursos

que ésta les cede al proyecto. Por otra parte, dentro de la zona principal debe situarse el

nivel de Core, sin embargo debido a que tendremos una LAN Party Piloto a pequeña

escala no es necesario implementar este nivel.

En cuanto a las dos zonas secundarias, se diseñarán en los laboratorios 3.3 y 3.5 de

manera que queden contiguas a la zona principal y proveerán de acceso a los usuarios

más cercanos geográficamente y agregarán su tráfico hasta la zona principal. Para la

instalación de las ZS se utilizarán los Switchs y Routers de las Islas 3, 4 5 y 6 de ambos

laboratorios. Estos Switchs de acceso alojados en las ZS serán los cedidos por la

Escuela, Catalyst 2950-12. De este modo se tendrá una capacidad máxima por cada

zona secundaria de 22 usuarios. En cada una de las zonas secundarias debe

implementarse el nivel de acceso a la red mediante una conexión a internet. Este acceso

se proveerá mediante interfaces 100Base-Tx con cables UTP CAT 6 por cada puesto de

acceso para soportar dicha tecnología. Por tanto, tendremos 22 cables de este tipo por

cada zona secundaria. Un requisito fundamentas es minimizar la longitud de los cables

mediante una adecuada localización de las ZS y de la ZP para así minimizas el gasto

económico de la puesta en marcha de la LPP. A pesar de esta minimización del

presupuesto, no debe pasar por alto que la distribución de los cables y zonas ZP y ZS

debe facilitar la operación y mantenimiento de la red ya que en caso de ocurrir algún

problema durante el desarrollo de la LAN Party Piloto la solución de este debe hacerse

de la manera más discreta posible y sin entorpecer a los asistentes ni parar el evento

momentáneamente.

Redundancia y balanceo de carga

Una vez diseñada la red se requiere realizar la redundancia y balanceo de carga

mediante mecanismos a diversos niveles que permitan reducir el tráfico innecesario en

la red. Algunos de estos mecanismos, tanto de los equipos de acceso como los de

distribución, se han visto en la asignatura y destaca el balanceo de carga mediante

Spanning-Tree y fast-Etherchannel.

Seguridad física e informática

Otro requisito de gran importancia es la seguridad de red, tanto a nivel de acceso

como de distribución ya que si cualquiera de ellos falla se pierde el control de la red y

ésta puede venirse abajo en cualquier momento. Por ello, es importante encargarse y

cuidad la seguridad a nivel de acceso mediante puertos seguros, protección contra

tormentas de broadcast y puertos de monitorización. Del mismo modo, debe

implementarse mediante ACLs la seguridad en la red a nivel de distribución. Por tanto,

es imprescindible hacer un shutdown del puerto del switch de acceso en el que se

intente acceder de forma fraudulenta, esto es, con una MAC distinta de la que

previamente se registró. Cuando se caiga ese enlace debe generarse un TRAP SNMP en

el sistema de monitorización para informar de este intento de violación de la seguridad

17


de la red. Para que la seguridad sea maximizada se pide como requisito que se creen

listas de acceso para así definir qué usuarios de la red tienen acceso a qué cosas.

Por otra parte, la seguridad física del evento es imprescindible, más cuando tenemos

la limitación de que cada usuario pueda acceder únicamente con un portátil y su

maletín, prohibiendo así la entrada con pantallas, u ordenadores de torre. Este requisito

surge de la limitación energética impuesta por la Escuela. Por otra parte, los alumnos

encargados de la seguridad física en la LPP deben estar pendientes de que no se inicie

ninguno de los PCs de los laboratorios, pero si lo desean los participantes pueden

conectar sus portátiles a las pantallas de los puestos de trabajo de las aulas. Por ello, es

necesario que en cada laboratorio estén presentes al menos cuatro personas de la

organización para asegurarse que se cumplan todos los requisitos. Además, al inicio del

evento los usuarios deben registrarse y se les asignará un puesto y ventana de tiempo

concretos, haciendo shutdown a su puerto de acceso una vez finalizado su tiempo.

QoS y VLANs

A continuación, debe garantizarse cierta calidad de servicio (QoS). Para ello, se

desea diseñar la red mediante VLANs en la que cada una de ellas implementará un

servicio o un grupo lógico de usuarios que compartan datos o servicios y por tanto

deben tener calidades de servicio diferenciadas. Esto resulta útil ya que no todos los

participantes de evento requieren los mismos servicios sino que unos desean competir

en videojuegos a tiempo real por lo que se requiere una QoS concreta mientras otros

únicamente desean compartir recursos, y por ello la QoS requerida es diferente. Tal y

como se ha explicado, esta calidad de servicio debe contemplar las distintas

prestaciones que puedes ofrecerse dentro de una misma VLAN ya que la organización

del evento no va a saber a priori qué hará cada usuario para situarlo en una VLAN u

otra, diseñando así VLANs con distintas QoS. En cuanto a la creación de las VLANs

para el correcto funcionamiento de la red como mínimo debe crearse una VLAN de

gestión y monitorización y una VLAN por servicio de usuario de la LPP. De este modo,

las VLANs transportarán su tráfico desde el nivel de acceso al de distribución mediante

encapsulación 802.1q.

Enrutamiento y direccionamiento lógico

Tal y como se indica a continuación una limitación importante es que en toda la LAN

Party Piloto deben usarse direcciones IP privadas de clase A y en caso de ser necesario

se utilizará OSPF en una única área como protocolo de enrutamiento o bien protocolos

First Hop Redundancy (HSRP, VRRP Y GLBP) y NAT TCP load distribution.

Aplicaciones y servicios

Durante el evento se ofrecerán torneos sobre los videojuegos: League of Legends,

FIFA, Team Fortress II, Hearthstone, Minecraft, Counter Strike y Street Fighter así

como un servicio de carga y descarga de ficheros y videostreaming que permitirá a los

usuarios subir y bajar ficheros y hacer streaming de audio y video. Sin embargo, se

impone el requisito de que ninguna información se pueda borrar. Para prestar estos

servicios de intercambio de información se tiene como limitación una capacidad menor

de 2x2 TByte. Además de todo esto se ofrecerán los siguientes servicios, implementado

siempre en ordenadores portátiles.

18


Un servicio de mensajería instantánea. Mediante este servicio la organización, en

este caso el alumnado, distribuirá mensajes y notificaciones para responder las dudas de

los participantes en tiempo real. Además, se implementará un servidor WebCam en

cada uno de los laboratorios 3.3 y 3.5 que servirá como cámaras de seguridad.

Capacidad eléctrica y otras consideraciones ECO

La capacidad eléctrica del espacio físico está limitada por la Escuela de manera que

cada usuario de la LAN Party Piloto no podrá consumir más de 250W, por tanto los

participantes únicamente podrán traer al evento sus ordenadores portátiles. Además de

estar impuesta por la ETSIIT, esta limitación tiene unas consecuencias ecológicas que

favorecen el respeto del medio ambiente y la sostenibilidad puesto que se gastará menor

cantidad de energía. Por ello, además de este requisito se deben incluir en la creación de

la LPP del proyecto todas aquellas consideraciones ECO que incidan en el respeto del

medio ambiente, como por ejemplo el uso de materiales ecológicos.

Gestión de la LPP

Finalmente, y no por ello menos importante, una vez montada la infraestructura de

red y durante el evento debe organizarse adecuadamente la gestión de éste. Para ello,

será necesario crear un servicio Web que describa la LPP del proyecto, así como todas

las cuentas en redes sociales y mails necesarios para atender las peticiones del evento y

darlo a conocer. Para la creación del servicio Web es importante que se implemente en

dos servidores en espejo y mediante un sistema de balanceo de conexiones. De este

modo, se evitarán problemas en la arquitectura cliente-servidor y el servicio Web será

accesible desde la red LAN de la LAN Party Piloto. Además, es bueno implementar un

servicio de monitorización de la infraestructura de red basado en SNMP.

Por último, debe crearse una dirección del evento para que desde sus comienzos se

encargue de la organización de la LPP, elabore los reglamentos internos y de los

participantes, así como de la gestión de éstos y demás aspectos legales. Además, es

importante que elabore los planes de contingencia para el correcto desempeño de cada

función del alumnado y con ello de la buena dirección del proyecto.

19


Propuestas de diseño de red 5

En este apartado se van a describir las tres propuestas de diseño de red a nivel físico

que han realizado los tres grupos de trabajo de la asignatura „Laboratorio de Telemática‟

para la que se realiza este proyecto. En primer lugar, se van a repasar las limitaciones y

requisitos que afectan al diseño de la red a nivel físico, ya que las tres propuestas han

sido diseñadas de acuerdo a dichas limitaciones.

Tal y como se ha comentado en el apartado anterior, solamente se dispone de tres

laboratorios contiguos de la tercera planta de la Escuela para albergar el evento. En

concreto, estos laboratorios son el 3.3, el 3.4 y el 3.5.

Además, se debe utilizar un diseño jerárquico de la red de forma que cuente con un

nivel de acceso y otro nivel de distribución. El nivel de Core no se va a implementar

debido a que la red tiene unas dimensiones muy pequeñas.

Se deben utilizar dos Zonas Secundarias (ZS) que deben proveer de acceso a los

usuarios y agregar su tráfico hasta la Zona Principal (ZP). Estas dos Zonas Secundarias

se deben albergar en los laboratorios 3.3 y 3.5. Por otro lado, la capacidad máxima de

cada Zona Secundaria es de 22 usuarios, por lo que el número máximo de puestos de

usuario es 44.

También, se debe utilizar una Zona Principal (ZP) que se albergará en el laboratorio

3.4. Este laboratorio se va a dedicar exclusivamente para la organización del torneo, de

manera que se van a situar en él: el nivel de distribución/Core, servidores de juegos y

aplicaciones, y la monitorización y control del evento.

En cuanto a las limitaciones de equipamiento, se debe indicar que para el nivel de

distribución solamente se dispone de un único switch multilayer Cisco WS-C3550-24-

SMI. Y para el nivel de acceso se dispone de 18 switches Catalyst 2950-12.

Además, los interfaces de acceso a los usuarios deben ser 100BaseTx con cables

UTP CAT 6, y se usará un cable por cada puesto de usuario.

Para poder realizar el diseño de red, se han tenido que medir los tres laboratorios que

se van a usar para saber la cantidad de cable necesario y poder elegir una distribución de

los puestos de usuario. En la figura 5.1 se muestra un plano de los tres laboratorios. En

este plano solamente se observan los elementos del laboratorio que realmente afectan al

diseño de la red física, como por ejemplo las ventanas, las bancas y las columnas. Sin

embargo, las puertas no están señaladas en el plano debido a que en las tres propuestas

de diseño se ha optado por utilizar las ventanas para pasar los cables que unen el nivel

de acceso con el nivel de distribución.

20


Fig. 5.1. Plano de los laboratorios 3.3, 3.4 y 3.5.

A continuación, se presentan las diferentes propuestas de diseño de la red física. Se

indicará el número de switches por clase y por columna de bancas, y se adjuntará un

plano de cada una para saber las ubicaciones de cada uno de los equipos necesarios para

implementar la red. Además, se indicará el número total de metros de cable que se

necesita, así como los puertos disponibles en los switches de acceso y en el switch

multilayer de distribución. También, se va a valorar la escalabilidad del diseño para ser

reutilizado en futuros proyectos.

5.1 Primera propuesta de diseño de red

Esta propuesta se basa en utilizar cuatro switches en cada zona secundaria y el único

switch multilayer en la zona principal. En cuanto a la disposición de los switches, se

propone utilizar un switch por cada columna de bancas en las zonas secundarias.

En cuanto al nivel de distribución, se propone utilizar dos cables troncales de uplink

por cada switch de acceso. Por tanto, se necesitan 16 cables troncales de uplink en total.

Esto significa que 16 de los 24 puertos del switch multilayer de distribución van a estar

ocupados de forma que solamente ocho puertos quedan libres para conexión con los

servidores, equipos de monitorización y acceso a Internet. Por ello, se propone conectar

un switch Catalyst 2950-12 mediante dos cables troncales al switch multilayer para

disponer de 10 puertos adicionales para servidores o equipos que necesiten poco ancho

de banda.

Con esta propuesta se pueden albergar 24 puestos de usuario en la Zona Secundaria 1

(Laboratorio 3.5) y 22 puestos de usuario en la Zona Secundaria 2 (Laboratorio 3.3).

En las figuras 5.2, 5.3 y 5.4 se muestran los planos de las dos zonas secundarias y de

la zona principal. Realmente, en la zona principal se pueden añadir más equipos de

monitorización y servidores que son necesarios para implementar el evento. Sin

embargo, en la propuesta final va a ser donde se van a añadir todos los servidores de

juegos necesarios, así como los equipos de monitorización y el servidor web.

21


Fig. 5.2. Plano de la Zona Secundaria 1.

Fig. 5.3. Plano de la Zona Secundaria 2.

22


Fig. 5.4. Plano de la Zona Principal.

En la tabla 5.1 se muestra la longitud de todos los cables necesarios y la longitud

total de cable. Además, en la tabla 5.2 se muestran los equipos necesarios y los puertos

utilizados.

Una vez que se ha presentado la primera propuesta de diseño de red, se van a analizar

las ventajas e inconvenientes.

La principal ventaja de esta propuesta es su escalabilidad, de forma que si se añaden

nuevas columnas de bancas o nuevos laboratorios para poder utilizarlos en el evento, se

puede utilizar este mismo diseño de red para esos nuevos módulos. Además, la longitud

de los cables de acceso se puede organizar también en módulos de manera que se

podrían reutilizar en un posible nuevo evento.

En cuanto al cableado, según la tabla 5.1, es necesario un total de 495.6 metros de

cable UTP categoría 6. Sin embargo, en dicha tabla no se tienen en cuenta los cables

que se utilizarían en el nivel de distribución para conexión con servidores y equipos de

monitorización. Este aspecto sí se tendrá en cuenta en la propuesta de diseño final.

Como se podrá ver más adelante, esta propuesta presenta un ahorro en cableado en

comparación con las otras dos propuestas.

En cuanto al número de puertos utilizados en los distintos equipos, se puede ver en la

tabla 5.2 que en los switches de acceso hay suficientes puertos de reserva disponibles

(como mínimo tres puertos en cada switch). Sin embargo, el switch multilayer de

distribución sólo tiene ocho puertos disponibles para conexión con servidores, equipos

de monitorización, etc. Este aspecto se intenta compensar conectando un switch

Catalyst 2950-12 al switch multilayer para aumentar el número de puertos disponibles

en distribución.

23


Con respecto a la seguridad física de los equipos, este diseño propone utilizar tres

personas de seguridad en cada zona secundaria (una en cada columna de bancas), lo

cual supone una desventaja respecto de las otras dos propuestas de diseño.

Tabla 5.1. Cables necesarios y longitud total de cable.

Equipo Ubicación

Puertos

ocupados

acceso

Puertos

ocupados

uplink

Puertos

disponibles

Switch Catalyst

2950-12 (1)

Lab. 3.5, mesa

superior FE [1, …, 7] FE [11, 12] FE [8, 9, 10]

Switch Catalyst

2950-12 (2)

Lab. 3.5, mesa

central superior FE [1, …, 5] FE [11, 12] FE [6, …, 10]

Switch catalyst

2950-12 (3)

Lab 3.5, mesa

central inferior FE [1, …, 5] FE [11, 12] FE [6, …, 10]

Switch catalyst

2950-12 (4)

Lab. 3.5, mesa

inferior FE [1, …, 7] FE [11, 12] FE [8, 9, 10]

Switch Catalyst

2950-12 (5)

Lab. 3.3, mesa

superior FE [1, …, 5] FE [11, 12] FE [6, …, 10]

Switch Catalyst

2950-12 (6)

Lab. 3.3, mesa

central superior FE [1, …, 5] FE [11, 12] FE [6, …, 10]

Switch Catalyst

2950-12 (7)

Lab. 3.5, mesa

central inferior FE [1, …, 5] FE [11, 12] FE [6, …, 10]

Switch Catalyst

2950-12 (8)

Lab. 3.5, mesa

inferior FE [1, …, 7] FE [11, 12] FE [8, 9, 10]

Switch Multilayer

Cisco WS-C3550-

24-SMI

Lab 3.4, mesa

central FE [1, …, 16] FE [17] FE [18, …, 24]

Switch Catalyst

2950-12 (9)

Lab. 3.4, mesa

central FE [1, …, 4] FE [11, 12] FE [5, …, 10]

Tabla 5.2. Equipos y ocupación de puertos de la primera propuesta de diseño de red.

24


5.2 Segunda propuesta de diseño de red

Esta propuesta se basa en utilizar tres switches en cada zona secundaria y el único


propone situar los tres switches en una misma columna de bancas, en concreto, en la

columna de bancas más cercana al laboratorio 3.4 (zona principal).




ocupados de forma que solamente doce puertos quedan libres para conexión con los

servidores, equipos de monitorización y acceso a Internet.


(Laboratorio 3.5) y 22 puestos de usuario en la Zona Secundaria 2 (Laboratorio 3.3). En

la figura 5.5 se muestran los planos de las dos zonas secundarias y de la zona principal.

En esta propuesta, no se detallan los equipos que se deben utilizar en la zona principal.

Como ya se dijo antes, debido a la flexibilidad de diseño del nivel de distribución, sólo

se va a hacer una única propuesta para el nivel de distribución que se va indicar en la

propuesta definitiva.

Fig. 5.5. Planos de las Zonas Secundarias y Zona Principal.

En la tabla 5.3 se muestran los equipos necesarios y los puertos utilizados. Además,

en la tabla 5.4 se muestra la longitud de todos los cables necesarios y la longitud total de

cable que se debe utilizar en esta propuesta.

Una vez que se ha presentado la segunda propuesta de diseño de red, se van a

analizar las ventajas e inconvenientes.

La desventaja más importante de esta propuesta es la escalabilidad, de forma que si

se añaden nuevas columnas de bancas o nuevos laboratorios para poder utilizarlos en el

evento, no se puede utilizar este mismo diseño de red para esos nuevos módulos, ya que

habría que pensar cómo se conectarían los nuevos puestos de usuario con los switches

de acceso y rehacer los cálculos. Además, la longitud de los cables de acceso no se

25


puede organizar en módulos porque nunca existe la misma distancia entre un switch de

acceso y los puestos de usuario con los que se conecta.

En cuanto al cableado, según la tabla 5.4, es necesario un total de 628.2 metros de

cable UTP categoría 6. Sin embargo, en dicha tabla tampoco se tienen en cuenta los

cables que se utilizarían en el nivel de distribución para conexión con servidores y

equipos de monitorización. Por tanto, esta propuesta necesita una mayor cantidad de

cable que la primera propuesta (495.6 metros).



(como mínimo dos puertos en cada switch). Además, la principal ventaja es que el

switch multilayer de distribución tiene doce puertos disponibles para conexión con

servidores, equipos de monitorización, etc. Entonces, no es necesario conectar algún

otro switch Catalyst 2950-12 al switch multilayer para aumentar el número de puertos

disponibles en distribución.

Con respecto a la seguridad física de los equipos, este diseño presenta la ventaja de

solamente necesitar una persona de seguridad en cada zona secundaria para estar al

cuidado de los switches de acceso.

Equipo Ubicación Puertos ocupados

acceso

Puertos

ocupados

uplink

Puertos

disponibles

Switch Catalyst

2950-12 (1)

Lab. 3.5, mesa

inferior FE [1, …, 8] FE [11, 12] FE [9, 10]

Switch Catalyst

2950-12 (2)

Lab. 3.5, mesa

inferior FE [1, …, 8] FE [11, 12] FE [9, 10]

Switch catalyst

2950-12 (3)

Lab 3.5, mesa

inferior FE [1, …, 6] FE [11, 12] FE [7, …, 10]

Switch catalyst

2950-12 (4)

Lab 3.3, mesa

superior FE [1, …, 8] FE [11, 12] FE [9, 10]

Switch catalyst

2950-12 (5)

Lab 3.3, mesa

superior FE [1, …, 8] FE [11, 12] FE [9, 10]

Switch Catalyst

2950-12 (6)

Lab. 3.3, mesa

superior FE [1, …, 6] FE [11, 12] FE [7, …, 10]

Switch Multilayer

Cisco WS-C3550-

24-SMI

Lab 3.4, mesa

central FE [1, …, 12] - FE [13, …, 24]

Tabla 5.3. Equipos y ocupación de puertos de la segunda propuesta de diseño de red.

26



5.3 Tercera propuesta de diseño de red

Esta propuesta se basa en utilizar tres switches en cada zona secundaria y el único


propone situar los tres switches en la parte intermedia de la columna de bancas central.




ocupados, de forma que 12 puertos quedan libres para conexión con los servidores,

equipos de monitorización y acceso a Internet.


(Laboratorio 3.5) y 25 puestos de usuario en la Zona Secundaria 2 (Laboratorio 3.3). En

la figura 5.6 se muestran los planos de las dos zonas secundarias y de la zona principal.

En esta propuesta se agrupan los cables en grupos modulares de forma que los puestos

de usuario con etiqueta verde necesitan un cable de aproximadamente 4 metros, los que

tienen etiqueta celeste requieren un cable de 7 metros, los de etiqueta naranja necesitan

un cable de 10 metros y los que tienen etiqueta roja necesitan un cable de 15 metros.

Fig. 5.6. Planos de las Zonas Secundarias y Zona Principal.

27


En la tabla 5.5 se muestran los equipos necesarios y los puertos utilizados. Además,

en la tabla 5.6 se muestra la longitud de todos los cables necesarios y la longitud total de

cable que se debe utilizar en este diseño de red propuesto.

Una vez que se ha presentado la tercera propuesta de diseño de red, se van a analizar

las ventajas e inconvenientes.

Al igual que con la segunda propuesta, la desventaja más importante de esta

propuesta es su escalabilidad, ya que si se añaden nuevas columnas de bancas o nuevos

laboratorios para poder utilizarlos en el evento, no se puede utilizar este mismo diseño

de red para esos nuevos módulos, ya que habría que pensar cómo se conectarían los

nuevos puestos de usuario con los switches de acceso y rehacer los cálculos. Aunque la

longitud de los cables de acceso está organizada en módulos, no existe la misma

distancia entre un switch de acceso y los puestos de usuario con los que se conecta, por

lo que si se añaden nuevos puestos de usuario en otras columnas de bancas se

desperdiciarían muchos metros de cable para conectarlos con un switch de acceso que

se encontraría en la parte intermedia de la columna de bancas central.

En cuanto al cableado, según la tabla 5.6, es necesario un total de 623 metros de

cable UTP categoría 6. Aunque en dicha tabla no se tienen en cuenta los cables que se

utilizarían en el nivel de distribución para conexión con servidores y equipos de

monitorización. Por tanto, esta propuesta necesita una mayor cantidad de cable que las

otras dos propuestas.



(dos puertos en cada switch). Además, la principal ventaja es que el switch multilayer

de distribución tiene doce puertos disponibles para conexión con servidores, equipos de

monitorización, etc. Entonces, no es necesario conectar algún otro switch Catalyst 2950-

12 al switch multilayer para aumentar el número de puertos disponibles en distribución.

Con respecto a la seguridad física de los equipos, este diseño también presenta la

ventaja de solamente necesitar una persona de seguridad en cada zona secundaria para

estar al cuidado de los switches de acceso.

28


Equipo Ubicación

Puertos

ocupados

acceso

Puertos

ocupados uplink

Puertos

disponibles

Switch Catalyst

2950-12 (1)

Lab. 3.5, mesa

central FE [1, …, 8] FE [11, 12] FE [9, 10]

Switch Catalyst

2950-12 (2)

Lab. 3.5, mesa

central FE [1, …, 8] FE [11, 12] FE [9, 10]

Switch catalyst

2950-12 (3)

Lab 3.5, mesa

central FE [1, …, 8] FE [11, 12] FE [9, 10]

Switch catalyst

2950-12 (4)

Lab 3.3, mesa

central FE [1, …, 8] FE [11, 12] FE [9, 10]

Switch catalyst

2950-12 (5)

Lab 3.3, mesa

central FE [1, …, 8] FE [11, 12] FE [9, 10]

Switch Catalyst

2950-12 (6)

Lab. 3.3, mesa

central FE [1, …, 8] FE [11, 12] FE [9, 10]

Switch Multilayer

Cisco WS-C3550-

24-SMI

Lab 3.4, mesa

central FE [1, …, 12] FE[13, …, 20] FE [21, …, 24]

Tabla 5.5. Equipos y ocupación de puertos de la tercera propuesta de diseño de red

Zona Secundaria 1 (Laboratorio 3.5) Zona Secundaria 2 (Laboratorio 3.3)

Uplnk

(metros)

Mesa

superior

(metros)

Mesa

central

superior

(metros)

Mesa

central

inferior

(metros)

Mesa

inferior

(metros)

Uplink

(metros)

Mesa

superior

(metros)

Mesa

central

superior

(metros)

Mesa

central

inferior

(metros)

Mesa

inferior

(metros)

15 7 4 4 7 15 7 4 4 7

15 10 4 4 10 15 10 4 4 10

15 10 4 4 10 15 10 4 4 10

15 15 4 4 15 15 15 4 4 15

15 15 4 4 15 15 15 4 4 15

15 15 15 15 15 15

15 15 15

15 15

Suma 90 72 20 20 102 90 102 20 20 87

Suma Uplink (m) 180

Suma Acceso (m) 443

Total (m) 623


29


5.4 Comparación de propuestas de diseño de red

En este apartado se van a comparar las ventajas e inconvenientes de las tres

propuestas de diseño de red presentadas. Una vez analizadas las ventajas e

inconvenientes, se va a elegir la propuesta más apropiada en la que se va a basar el

diseño de red definitivo.

En primer lugar, cabe destacar que las tres propuestas cumplen los requisitos de

diseño de red, ya que todas ellas utilizan dos Zonas Secundarias y una Zona Principal.

Además, todos los switches de acceso se conectan con el nivel de distribución mediante

dos cables troncales de uplink. A pesar de que un requisito de diseño es que las dos

Zonas Secundarias solamente pueden albergar 22 puestos de usuario cada una, la

primera y la tercera propuesta añaden más puestos de usuario en cada Zona Secundaria

para que puedan asistir más usuarios al evento, lo cual no se trata de un incumplimiento

de los requisitos crítico debido a que se puede reducir el número de puestos de usuario

hasta 22, y habría algunos puestos libres.

En la tabla 5.7 se indica la escalabilidad, seguridad, número de personas de seguridad

requerido, longitud total del cableado y el número de puertos ocupados en el switch

multilayer de distribución para cada una de las tres propuestas.

Escalabilidad Seguridad Nº personas

seguridad

Longitud

cableado

(metros)

Nº puertos

ocupados

Multilayer

1ª Propuesta Sí Sí 3 495.6 16

2ª Propuesta No Sí 1 628.2 12

3ª Propuesta No Sí 1 623 12

Tabla 5.7. Comparación de características de las propuestas de diseño de red.

La única propuesta que presenta la propiedad de escalabilidad es la primera, ya que

usa un switch de acceso por columna de bancas, de forma que la distancia entre un

switch y los puestos de usuario con los que se conecta es siempre la misma. Esta

característica es muy importante para el proyecto al que nos enfrentamos debido a que

el evento que se pretende llevar a cabo se va a repetir en más ocasiones, y es posible que

se añadan más columnas de bancas o laboratorios para que puedan asistir mayor número

de usuarios al evento.

En cuanto a la seguridad, todas las propuestas son seguras debido a que los switches

de acceso pueden estar vigilados por personas de seguridad. Sin embargo, la primera

propuesta requiere como mínimo tres personas de seguridad por Zona Secundaria (una

por cada columna de bancas), y las otras dos propuestas solamente requieren una

persona de seguridad por Zona Secundaria debido a que los switches de acceso están

todos ubicados en el mismo lugar.

En cuanto al cableado, la primera propuesta presenta un ahorro en cableado con

respecto a las otras dos propuestas. Además, los cables se pueden agrupar en módulos y

ser reutilizados en otros eventos.

30


Con respecto a la ocupación de puertos, todas las propuestas presentan como mínimo

dos puertos de reserva en cada switch de acceso. Sin embargo, la primera propuesta

necesita ocupar 16 de los 24 puertos del switch multilayer que se utiliza en el nivel de

distribución, y las otras dos propuestas solamente requieren ocupar 12 puertos. Este es

un aspecto importante debido a que se necesitan conectar varios servidores de juegos,

un servidor web, varios equipos de monitorización, y otro puerto para conexión con

Internet.

Una vez que se han comparado las ventajas e inconvenientes de cada propuesta, se

decide escoger la primera propuesta para basarse en el diseño físico definitivo de la red.

Esto es debido a que es la única propuesta que ofrece escalabilidad y que permite

utilizar conjuntos de cables modulares que se pueden reutilizar en futuros eventos.

Además, es la propuesta que requiere una menor longitud total de cableado. A pesar de

que requiere un mayor número de vigilantes de seguridad para los switches de acceso,

éste no es un problema debido a que se cuenta con suficiente personal para llevar a cabo

esta tarea. Por otro lado, también es la propuesta que requiere un mayor número de

puertos ocupados en el switch multilayer, ya que utiliza cuatro switches de acceso por

Zona Secundaria. Este es un inconveniente, pero se puede compensar reduciendo a tres

el número de switches de acceso por Zona Secundaria y conectando algún switch

Catalyst 2950-12 al switch multilayer.

31


Diseño de la red de la LPP 6

6.1 Arquitectura y protocolos

A continuación, se hará un breve resumen de cada uno de los protocolos utilizados

para la implementación de la red de la LPP. En el resto de secciones de este informe, se

explicarán algunos con mayor profundidad así como se analizará su aplicación y su

implementación en dicha red.

VLAN 6.1.1

VLAN, acrónimo de Red de Área Local Virtual, es un método que permite crear

redes lógicas independientes dentro de una misma red física. Las VLANs son útiles para

reducir el tamaño del dominio de difusión y ayudan en la administración de la red

separando segmentos lógicos de una red de área local. En nuestro caso, utilizaremos las

VLANs para separar los distintos juegos y el sistema de videovigilancia.

802.1q 6.1.2

El propósito de los enlaces troncales es evitar agregar un enlace por cada VLAN.

Esta es una forma simple de implementar la comunicación de VLANs entre switches,

pero esta no es escalable.

Este protocolo es una modificación al estándar de Ethernet. Fue un proyecto del

grupo de trabajo 802 de IEEE para desarrollar un mecanismo que permita a múltiples

redes interconectadas con puentes o switches compartir transparentemente el mismo

medio físico sin problemas de interferencia entre las redes que comparten el medio

(trunking). Es también el nombre actual del estándar establecido en este proyecto y se

usa para definir el protocolo de encapsulamiento usado para implementar este

mecanismo en redes Ethernet. El estándar 802.1Q, en realidad, no encapsula la trama

original sino que añade 4 bytes al encabezado Ethernet original para identificar la

VLAN a la que pertenece la información que se está transportando entre dispositivos de

la capa 2. Permite identificar a una trama como proveniente de un equipo conectado a

una red determinada. Una trama perteneciente a una VLAN sólo se va a distribuir a los

equipos que pertenezcan a su misma VLAN, de forma que se separan dominios de

broadcast. Resumiendo, gracias a este protocolo es posible transportar el tráfico de

varias VLANs sobre Ethernet.

STP 6.1.3

STP (Spanning Tree Protocol) es un protocolo de red de la capa de enlace del modelo

OSI cuya función es gestionar la presencia de bucles en topologías de red debido a la

existencia de enlaces redundantes (necesarios en muchos casos para garantizar la

disponibilidad de las conexiones). El protocolo permite a los dispositivos de

interconexión activar o desactivar automáticamente los enlaces de conexión de forma

que se garantice la eliminación de bucles.

32


En cuanto al funcionamiento, el algoritmo transforma una red física con forma de

malla, en la que existen bucles, por una red lógica en forma de árbol (libre de bucles).

DHCP 6.1.4

DHCP o Protocolo de Configuración Dinámica de Máquinas especifica un método

para configurar dinámicamente los parámetros de red necesarios para que un sistema

pueda comunicarse efectivamente. Es decir, se trata de un protocolo de tipo

cliente/servidor en el que generalmente un servidor posee una lista de direcciones IP

dinámicas y las va asignando a los clientes conforme van quedando libres.

NAT 6.1.5

NAT es un protocolo de traducción de direcciones de red. Esto es necesario cuando

se intenta establecer comunicación entre dos puntos de una red que no resultan

compatibles.

Se desarrolló para resolver la falta de direcciones IP con el protocolo IPv4 (dentro de

poco tiempo el protocolo IPv6 resolverá este problema).

De hecho, en las direcciones IPv4 la cantidad de direcciones IP enrutables (que son

únicas en el mundo) no es suficiente para permitir que todos los equipos que lo

requieran estén conectados a Internet.

Por tanto, el principio de NAT consiste en utilizar una conexión de pasarela a

Internet, que tenga al menos una interfaz de red conectada a la red interna y al menos

una interfaz de red conectada a Internet (con una dirección IP enrutable) para poder

conectar todos los equipos a la red.

NTP 6.1.6

El protocolo NTP (Network Time Protocol), más comúnmente conocido como NTP,

es un protocolo de Internet ampliamente utilizado para transferir el tiempo a través de

una red. NTP es normalmente utilizado para sincronizar el tiempo en clientes de red a

una hora precisa.

6.2 Topología lógica y física

En base a la primera propuesta de diseño de red, explicada en el apartado 5, se va

presentar el diseño definitivo que se va a utilizar para albergar el evento.

Al igual que en la primera propuesta descrita anteriormente, se usará un switch de

acceso por cada columna de bancas, pero para poder liberar cuatro puertos en el switch

multilayer de distribución se va a ubicar un único switch de acceso para las dos

columnas de bancas centrales. Además, se van a añadir dos cámaras IP en cada Zona

Secundaria.

La topología lógica de la red completa se presenta en la figura 6.1.

http://es.ccm.net/contents/internet/ip.php3

http://es.ccm.net/contents/protip.php3

http://es.ccm.net/contents/ipv6.php3

33


Tal y como se puede observar, existen 22 puestos de usuario, tres switches de acceso

y dos cámaras IP en cada Zona Secundaria. Estas serán abiertas al público para el uso de

los usuarios.

En la Zona Principal, se encuentra el switch multilayer que tiene doce puertos

ocupados de los troncales de uplink correspondientes al nivel de acceso. Tiene, además,

un puerto ocupado por el servidor del juego Minecraft, el cual requiere un gran ancho

de banda, dos puertos asignados a las dos troncales del switch que alberga una cámara

IP, el servidor Owncloud, y los servidores de los juegos Counter Strike y Team Fortress

(servidores que necesitan poco ancho de banda), dos puertos para dos equipos de

monitorización que necesitan tener gran ancho de banda y otros dos puertos para las dos

troncales de un switch que alberga hasta 10 posibles equipos de gestión. Por tanto, hay

un total de 19 puertos ocupados en el switch multilayer, pero también hay que tener en

cuenta que se necesita otro puerto para conexión con Internet. En conclusión, hay 20

puertos ocupados y 4 puertos de reserva en el switch multilayer Cisco WS-C3550-24-

SMI.

Fig. 6.1. Diseño lógico de la red definitiva.

El resto de juegos necesitarán conexión a internet para poder jugar online con el resto

de jugadores. Estos servidores no se encuentran en nuestra red.

Como ya se ha visto, los servidores de los juegos que se van a ofertar a los usuarios

se encuentran en la Zona Principal. Los juegos que necesitan acceso a Internet no se

encuentran en nuestra red y eso mismo ocurre con respecto al servidor web.

Se ha decidido que el servidor web no se encuentre dentro de nuestra red por una

serie de motivos:

- Es necesaria la publicidad del evento y una zona para que los participantes de la

LPP se puedan registrar. Si el servidor se encuentra en esta red no va a ser

34


posible ponerlo en marcha hasta los días planteados para el montaje de la red.

Por tanto, sería imposible la utilidad de la página web por parte de los usuarios.

- Al estar el servidor web en esta red, se podría acceder a él desde fuera y esto

también puede suponer amenazas de seguridad.

En cuanto al diseño físico definitivo de la red, se pueden observar los planos de las

Zonas Secundarias 1 y 2, y el de la Zona Principal en las figuras 6.2, 6.3 y 6.4.

Cabe destacar que se han utilizado diez conjuntos modulares de cable (L1, L2,…,

L10) en donde cada uno tiene una longitud diferente. En la tabla 6.1 se muestra la

longitud de cada conjunto.

Conjunto modular

cable Longitud (m)

L1 1

L2 2

L3 3.2

L4 4.4

L5 5.6

L6 6.8

L7 8

L8 9.2

L9 16

L10 19 Tabla 6.1. Conjuntos de cable y longitud.

35


Fig. 6.2. Diseño físico de la Zona Secundaria 1.

Fig. 6.3. Diseño físico de la Zona Secundaria 2.

36


Fig. 6.4. Diseño físico de la Zona Principal.

Como se puede ver en estos planos, cada equipo tiene unas siglas que lo identifican.

Los 44 equipos de usuario se identifican desde el H1 hasta el H44. A cada uno de los

ocho switches se les ha asignado un número de forma que se identifican desde el SW1

hasta el SW8. Las cinco cámaras IP se identifican desde C1 hasta C5. Y a los cuatro

equipos de gestión y monitorización se les asigna la identificación desde G1 hasta G4.

Además, se puede ver que cada equipo de usuario tiene asignado una longitud que

varía desde L1 hasta L8, lo cual significa que el cable Ethernet que conecta el equipo de

usuario al switch de acceso tiene la longitud correspondiente al grupo modular de cable

indicado.

En la tabla 6.3 se muestran los equipos utilizados para la infraestructura de red, así

como los puertos ocupados y libres que tiene cada equipo.

Por otro lado, en la tabla 6.4 se muestra el número de conjuntos modulares de cable

que se deben usar en este diseño de red, así como la cantidad de cable total que es

necesario para la infraestructura de red. Tal y como se muestra, la longitud total de

cable UTP CAT 6 necesario es 449.4 metros.

En las tablas 6.5, 6.6 y 6.7 se muestra la ocupación de todos los puertos de los

equipos de la red y el etiquetado de los cables que se conectan en esos puertos. La tabla

6.5 se corresponde con los equipos de la Zona Secundaria 1, la tabla 6.6 con los de la

Zona Secundaria 2, y la tabla 6.7 se corresponde con los equipos de la Zona Principal.

Por tanto, la construcción de la tabla que muestra el número de conjuntos modulares de

cable necesarios (tabla 6.4) se ha realizado a partir de estas tres tablas, de manera que se

37


ha ido sumando el número de conjuntos de cable que se necesita en las Zonas

Secundarias y Principal.

Con el fin de poder entender las etiquetas que se muestran en estas tres últimas

tablas, es necesario conocer el significado de las siglas que se muestra en la siguiente

tabla.

Siglas Significado

SW Switch

R Router o Switch Multilayer

H Equipo de usuario (host)

G Equipo de gestión o monitorización

S Servidor

C Cámara IP

Tabla 6.2. Siglas de etiquetas y significado.

Equipo Ubicación

Puertos

ocupados

acceso

Puertos

ocupados uplink

Puertos

disponibles

Switch Catalyst

2950-12 (1)

Lab 3.5, mesa

inferior FE [1, …, 9] FE [11, 12] FE [10]

Switch Catalyst

2950-12 (2)

Lab 3.5, mesa

central FE [1, …, 8] FE [11, 12] FE [9, 10]

Switch Catalyst

2950-12 (3)

Lab 3.5, mesa

superior FE [1, …, 7] FE [11, 12] FE [8, 9, 10]

Switch Catalyst

2950-12 (4)

Lab 3.3, mesa

superior FE [1, …, 9] FE [11, 12] FE [10]

Switch Catalyst

2950-12 (5)

Lab 3.3, mesa

central FE [1, …, 8] FE [11, 12] FE [9, 10]

Switch Catalyst

2950-12 (6)

Lab 3.3, mesa

inferior FE [1, …, 7] FE [11, 12] FE [8, 9, 10]

Switch Multilayer

Cisco WS-C3550-

24-SMI

Lab 3.4, Rack de

Isla 4 FE [1, …, 12] FE[13, …, 20] FE [21, …, 24]

Switch Catalyst

2950-12 (7)

Lab 3.4, mesa

superior FE [1, 2] FE[11, 12] FE [3, …, 9]

Switch Catalyst

2950-12 (8)

Lab. 3.4, Rack de

Isla 4 FE [1, 2, 3, 4] FE[11, 12] FE [5, …, 9]

Tabla 6.3. Equipos y ocupación de puertos de diseño de red definitivo.

38


Conjuntos modulares de cable

Conjuntos de cable

Número de

conjuntos Suma

Zonas secundarias

(Acceso)

L1 (1 m) 8 8 m

L2 (2 m) 12 24 m

L3 (3.2 m) 8 25.6 m

L4 (4.4 m) 6 26.4 m

L5 (5.6 m) 2 11.2 m

L6 (6.8 m) 4 27.2 m

L7 (8 m) 4 32 m

L8 (9.2 m) 4 36.8 m

Total Acceso (ZS) 191.2 m

Zonas Secundarias

(Uplink)

L9 (16 m) 8 128 m

L10 (19 m) 4 76 m

Total Uplink (ZS) 204 m

Zona Principal

L1 (1 m) 3 3 m

L2 (2 m) 2 4 m

L4 (4.4 m) 4 17.6 m

L5 (5.6 m) 2 11.2 m

L8 (9.2 m) 2 18.4 m

Total Zona Principal 54.2 m

Total (Zonas Secundarias + Zona Principal) 449.4 m

Tabla 6.4. Número de conjuntos de cable necesarios para la infraestructura de red.

39


Zona Secundaria 1 (Laboratorio 3.5)

Dispositivo Utilidad de puertos Número de puerto Etiqueta cable

Switch 1

Host

FE 01 SW1_01-H1 (1 m)

FE 02 SW1_02-H2 (2 m)

FE 03 SW1_03-H3 (3.2 m)

FE 04 SW1_04-H4 (4.4 m)

FE 05 SW1_05-H5 (5.6 m)

FE 06 SW1_06-H6 (6.8 m)

FE 07 SW1_07-H7 (8 m)

FE 08 SW1_08-H8 (9.2 m)

Cámara IP FE 09 SW1_09-C5 (2 m)

Reserva FE 10

Uplink FE 11 SW1_11-R1_01 (16 m)

FE 12 SW1_12-R1_02 (16 m)

Switch 2

Host

FE 01 SW2_01-H9 (1 m)

FE 02 SW2_02-H10 (2 m)

FE 03 SW2_03-H11 (3.2 m)

FE 04 SW2_04-H12 (4.4 m)

FE 05 SW2_05-H13 (1 m)

FE 06 SW2_06-H14 (2 m)

FE 07 SW2_07-H15 (3.2 m)

FE 08 SW2_08-H16 (4.4 m)

Reserva FE 09

FE 10

Uplink FE 11 SW2_11-R1_03 (16 m)

FE 12 SW2_12-R1_04 (16 m)

Switch 3

Host

FE 01 SW3_01-H17 (1 m)

FE 02 SW3_02-H18 (2 m)

FE 03 SW3_03-H19 (3.2 m)

FE 04 SW3_04-H20 (6.8 m)

FE 05 SW3_05-H21 (8 m)

FE 06 SW3_06-H22 (9.2 m)


Reserva

FE 08

FE 09

FE 10

Uplink FE 11 SW3_11-R1_05 (19 m)

FE 12 SW3_12-R1_06 (19 m)

Tabla 6.5. Ocupación de puertos y etiquetado de cables de Zona Secundaria 1.

40


Zona Secundaria 2 (Laboratorio 3.3)

Dispositivo Utilidad de puertos Número de puerto Etiqueta cable

Switch 4

Host

FE 01 SW4_01-H23 (1 m)

FE 02 SW4_02-H24 (2 m)

FE 03 SW4_03-H25 (3.2 m)

FE 04 SW4_04-H26 (4.4 m)

FE 05 SW4_05-H27 (5.6 m)

FE 06 SW4_06-H28 (6.8 m)

FE 07 SW4_07-H29 (8 m)

FE 08 SW4_08-H30 (9.2 m)


Reserva FE 10

Uplink FE 11 SW4_11-R1_07 (16 m)

FE 12 SW4_12-R1_08 (16 m)

Switch 5

Host

FE 01 SW5_01-H31 (1 m)

FE 02 SW5_02-H32 (2 m)

FE 03 SW5_03-H33 (3.2 m)

FE 04 SW5_04-H34 (4.4 m)

FE 05 SW5_05-H35 (1 m)

FE 06 SW5_06-H36 (2 m)

FE 07 SW5_07-H37 (3.2 m)

FE 08 SW5_08-H38 (4.4 m)

Reserva FE 09

FE 10

Uplink FE 11 SW5_11-R1_09 (16 m)

FE 12 SW5_12-R1_10 (16 m)

Switch 6

Host

FE 01 SW6_01-H39 (1 m)

FE 02 SW6_02-H40 (2 m)

FE 03 SW6_03-H41 (3.2 m)

FE 04 SW6_04-H42 (6.8 m)

FE 05 SW6_05-H43 (8 m)

FE 06 SW6_06-H44 (9.2 m)


Reserva

FE 08

FE 09

FE 10

Uplink FE 11 SW6_10-R1_11 (19 m)

FE 12 SW6_11-R1_12 (19 m)

Tabla 6.6. Ocupación de puertos y etiquetado de cables de Zona Secundaria 2.

41


Zona principal (Laboratorio 3.4)

Dispositivo Utilidad de puerto Número de puerto Etiqueta cable

Switch Multilayer 1

Acceso, servidores y

gestión

FE 01 SW1_11-R1_01 (16 m)

FE 02 SW1_12-R1_02 (16 m)

FE 03 SW2_11-R1_03 (16 m)

FE 04 SW2_12-R1_04 (16 m)

FE 05 SW3_11-R1_05 (19 m)

FE 06 SW3_12-R1_06 (19 m)

FE 07 SW4_11-R1_07 (16 m)

FE 08 SW4_12-R1_08 (16 m)

FE 09 SW5_11-R1_09 (16 m)

FE 10 SW5_12-R1_10 (16 m)

FE 11 SW6_11-R1_11 (19 m)

FE 12 SW6_12-R1_12 (19 m)

FE 13 SW7_11-R1_13 (9.2 m)

FE 14 SW7_12-R1_14 (9.2 m)

FE 15 SW8_11-R1_15 (1 m)

FE 16 SW8_12-R1_16 (1 m)

FE 17 R1_17-G1 (5.6 m)

FE 18 R1_18-G2 (5.6 m)

FE 19 R1_19-S1 (4.4 m)

Reserva

FE 20

FE 21

FE 22

FE 23

FE 24

Switch 7

Gestión FE 01 SW7_01-G3 (1 m)

FE 02 SW7_02-G4 (2 m)

Reserva

FE 03

FE 04

FE 05

FE 06

FE 07

FE 08

FE 09

FE 10

Uplink FE 11 SW7_11-R1_13 (9.2 m)

FE 12 SW7_12-R1_14 (9.2 m)

Switch 8

Servidor

FE 01 SW8_01-S2 (4.4 m)

FE 02 SW8_02-S3 (4.4 m)

FE 03 SW8_03-S4 (4.4 m)


Reserva

FE 05

FE 06

FE 07

FE 08

FE 09

FE 10

Uplink FE 11 SW8_11-R1_15 (1 m)

FE 12 SW8_12-R1_16 (1 m)

Tabla 6.7. Ocupación de puertos y etiquetado de cables de Zona Principal.

Una vez comentada la topología lógica y física, hay que centrarse en la organización

de la LPP.

42


Tal y como se ha comentado hasta el momento, se dispone de 44 puestos de usuario,

repartidos en dos zonas secundarias. En esta LPP, se van a ofrecer siete juegos distintos

a dichos usuarios, por lo que se ha decidido dividir la red en distintas subredes, cada una

destinada a un juego. Para ello, se utilizarán VLANs.

El uso de las VLANs supone una separación de la red completa en subredes, esto es

imprescindible en una red ya que proporciona una serie de ventajas:

Limitación del dominio de difusión. Cada VLAN tiene un domino de difusión

distinto, por lo que el tráfico broadcast queda limitado.

Proporciona mayor flexibilidad en la administración y en los cambios de la red.

Mayor seguridad. Los usuarios sólo pueden acceder, en principio, a equipos

situados en la misma VLAN.

Se deben configurar las interfaces de los switches de acceso de tal forma que los

equipos en los que se puede jugar a un juego determinado se encuentren dentro de una

misma VLAN.

En definitiva, cada puesto de usuario (interfaz específica del switch que da acceso)

tendrá una VLAN configurada, la del juego en sí.

Los puestos de usuario se podrían organizar de tal forma que en cada uno de los 44

equipos disponibles se pudiera jugar a cualquier juego. Sin embargo, se ha encontrado

dificultad en cuanto a la implementación, ya que se tendría que ir cambiando la

configuración del puerto correspondiente al equipo en el switch, es decir, habría que

asignarles la VLAN correspondiente del nuevo juego. Por ello, se decide que sólo se

pueda jugar a un juego en una serie de equipos fijos.

La distribución de las VLANs en los switches de acceso y en los equipos se explicará

en el punto 6.4.

Para comprobar que la red funciona correctamente, se procederá a simularla con el

programa GNS3. Sin embargo, debido a la gran limitación que éste supone, no se va a

poder simular nuestra red exactamente, sino que se va a tener que ver afectada por

algunas modificaciones. En el punto 11 se comentarán exactamente cuáles han sido

estas modificaciones.

6.3 Configuración a nivel físico

Tal y como se ha comentado anteriormente, la LAN Party dispondrá de una

infraestructura de red exclusivamente alámbrica. El cableado que se va a usar es del tipo

UTP CAT 6, que se caracteriza por ser full-dúplex y tener una velocidad igual a 100

Mbps en cada sentido. Por tanto, tanto los enlaces de acceso como los enlaces troncales

dispondrán de la misma velocidad.

En los siguientes apartados de este capítulo se van a indicar los siguientes puntos:

Separación de equipos en subredes virtuales, a través de VLANs.

Prevención de bucles, mediante Spanning Tree Protocol.

43


Balanceo de carga usando el protocolo STP.

Configuración de direcciones IP y máscaras de subred en los equipos.

Configuración de los protocolos DHCP y NAT.

Configuración de protocolos de seguridad en los switches.

Conexión a Internet con ISP mediante un enlace de fibra óptica con una

velocidad 100Mbps.

6.4 Diseño de VLANs y trunking

En este punto se explica la propuesta de diseño de las VLANs, así como el balanceo

de carga de la red.

Como ya se ha comentado en puntos anteriores, se ha decidido asignar una VLAN a

cada juego. A parte de las VLANs de juegos, se tendrán las VLANs correspondientes al

sistema de videovigilancia y al sistema de gestión (por defecto VLAN 101) y la VLAN

correspondiente a los switches (VLAN 110).

En la siguiente tabla se recoge la asignación de VLANs.

Virtual LAN Subred Color identificativo

VLAN 10 Hearthstone Verde oscuro

VLAN 20 Counter Strike Gris oscuro

VLAN 30 Leage of Legends Naranja

VLAN 40 Minecraft Marrón

VLAN 50 Team Fortress 2 Azul oscuro

VLAN 60 FIFA y Street Fighter Rojo

VLAN 70 Sistema de videovigilancia Morado

VLAN 100 Owncloud Negro

VLAN 101 Equipos de gestión Rosa

VLAN 110 Gestión (switches) Verde claro

Tabla 6.8. Reparto de VLANs, significado y colores identificativos.

A continuación, se debe asignar un número fijo de equipos que pertenecerán a una de

estas VLANs.

La VLAN 101 será la que esté configurada en los equipos de gestión. Como se verá

más adelante, estos equipos podrán acceder en principio a todos los equipos de la red

(hosts finales y switches). Por otro lado, la VLAN 110 se utilizará para la asignación de

direcciones IP a los switches. Solamente los equipos de gestión podrán hacer telnet a

estos equipos para su configuración.

En cuanto a la distribución física de los laboratorios (Zonas Secundarias) se ha

pensado que lo más lógico y equitativo sería desplegar las VLANs repartidas en las

aulas 3.3 y 3.5 de forma que no todos los jugadores de un mismo juego se encuentren en

una misma sala. Se ha pensado que las dos Zonas Secundarias sean iguales y en ambas

se juegue a los mismos juegos. Esto se ha decidido así ya que en el caso de que tuviesen

más éxito juegos que se encontraran en la misma Zona Secundaria encontraríamos un

aula llena de gente y otra vacía. Esto, además de ser perjudicial por el gran consumo de

ancho de banda en una zona y poco consumo en otra, no queda bien estéticamente, ya

que para un mayor bienestar de los usuarios y para un mejor control de los

organizadores del evento, es mejor que los usuarios queden repartidos.

44


En cuanto al laboratorio central 3.4, tendrá algunos servidores de juegos que deberán

ser configurados en la misma VLAN.

Otro de los aspectos a considerar es el ancho de banda de los juegos y de las cámaras

IP. Se ha realizado un análisis previo, el cual se comentará con más profundidad en el

capítulo 7, y se ha recogido la siguiente tabla:

JUEGO ANCHO DE BANDA MEDIO ANCHO DE BANDA PICO

Hearthstone 500 Kbps 5 Mbps

League of Legends 120 Kbps 120 Kbps

Team Fortress 2 80 Kbps 80 Kbps

Minecraft 4 Mbps 10 Mbps

Counter Strike 80 Kbps 80 Kbps

Street Fighter 2.56 Kbps 9.52 Kbps

FIFA 5 Mbps 10 Mbps

Cámaras IP 1.5 Mbps 1.5 Mbps

Owncloud 2 Mbps 2 Mbps

Tabla 6.9. Ancho de banda requerido por juegos, cámaras IP y servidor de Owncloud.

Otro de los aspectos a considerar es el ancho de banda de los juegos. Se ha realizado

un análisis previo y se ha visto que el tráfico depende del juego. Se debe considerar el

peor de los casos (momentos de pico) para asegurar que en todo momento va a haber

disponibilidad en cuanto al ancho de banda se refiere.

Afectan también las limitaciones tecnológicas que se tienen, puesto que sólo se

pueden usar dos PlayStations.

Por último, otro punto que influye es la popularidad de los juegos de la LPP, y por lo

tanto el número de personas que, se supone, querrán jugar a cada juego. Para el caso del

juego League of Legends, se tiene una imposición (por parte de la organización del

juego) que afecta al número mínimo de jugadores. Por otro lado, los juegos FIFA y

Street Fighter se jugarán utilizando dos PlayStations 3.

Considerando todos estos aspectos, se ha decidido asignar el siguiente número de

jugadores a cada juego:

1. Hearthstone 6 jugadores

2. League of Legends 10 jugadores

3. Team Fortress 2 10 jugadores

4. Minecraft 4 jugadores

5. Counter Strike 10 jugadores

6. Street Fighter 2 a 4 jugadores

7. Fifa 2 a 4 jugadores

En las siguientes imágenes, se puede ver cómo se han distribuido los puestos del

laboratorio por VLANs (videojuegos, videovigilancia y gestión).

45


Fig. 6.5. Distribución por VLANs del laboratorio 3.5.


46



Una vez que ya se han diseñado las VLANs, se tiene que configurar la comunicación

entre ellas y la VLAN 100 correspondiente al servidor de owncloud. Se hace así para

que cada usuario tenga la oportunidad de descargar y cargar ficheros en dicho servidor.

Para configurar que solamente se puedan comunicar cada VLAN correspondiente a un

juego con la VLAN 100, y no se puedan comunicar dos VLANS correspondientes a

juegos diferentes, se restringirá el acceso mediante listas de acceso, introducidas en el

apartado de seguridad.

Ahora, se va a plantear el balanceo de carga usando el protocolo STP. Como ya se

sabe, se dispone de dos troncales que unen los switches de acceso con el switch

multilayer de distribución. El objetivo será el siguiente:

Distribuir el tráfico de forma equilibrada de forma que se reparta el ancho de

banda entre los troncales.

Para ello, se disminuirán las prioridades a los puertos del switch raíz para que queden

bloqueados los puertos correspondientes de los switches de acceso. De esta forma, se va

consiguiendo la eliminación de bucles (no todos los puertos están en FORWARDING,

sino que hay algunos BLOCKED) y se está balanceando la carga de manera justa (según

el ancho de banda disponible).

Si por cualquier motivo, un troncal que conecta un switch de distribución con el

switch multilayer se cayera, al cabo de un tiempo (rondando los 30 segundos), se

recuperaría la conectividad debido a que el otro troncal pasaría a modo FORWARDING

para las VLANs correspondientes. De todo esto se ocupa el protocolo Spanning Tree

47


Protocol. En el anexo, se recoge el procedimiento con los comandos necesarios para la

configuración.

Para realizar el reparto del tráfico, se recoge en la siguiente tabla la suma del ancho

de banda aproximado que se tendrá en cada troncal. Cabe destacar que todas las

estimaciones se han intentado realizar de forma que se considere siempre el peor caso.

Se deben tener en cuenta los siguientes aspectos.

El ancho de banda consumido por las cámaras IP puede alcanzar los 1.5

Mbps (caso límite) dependiendo del códec utilizado y la tasa de fotogramas

por unidad de tiempo. Se puede reducir la calidad de la imagen hasta una tasa

de 1 Mbps.

Los jugadores de Minecraft y del FIFA pueden llegar a necesitar 10 Mbps

para poder mantener una partida online. Se pueden tener 4 jugadores de

Minecraft que producirían un tráfico de 40 Mbps y 2 jugadores de FIFA que

supondrían 20 Mbps.

Los servidores de juegos deben ser capaces de mantener las sesiones con

todos los jugadores.

En la siguiente tabla, se recoge el reparto de tráfico (ancho de banda) de forma

aproximada. Se ha procurado siempre separar las cámaras de seguridad y el juego que

más ancho de banda consume, Minecraft en este caso.

LABORATORIO SWITCH TRONCAL 1 (FE 0/11) TRONCAL 2 (FE 0/12)

VLANs TRÁFICO VLAN TRÁFICO

3.5

SW1 70 1.5 Mbps 40 y 50 20.05 Mbps

SW2 10 15 Mbps 20 y 60 10.04 Mbps

SW3 70 1.5 Mbps 20 y 30 0.61 Mbps

3.4

SW7 101 2 Mbps 101 2 Mbps

SW8 70 y 50 1.6 Mbps 100 y 20 4.01 Mbps

Multilayer ------------- ---------------- ------------- -------------

3.3

SW4 70 1.5 Mbps 40 y 50 20.05 Mbps

SW5 10 15 Mbps 20 y 60 10.04 Mbps

SW6 70 1.5 Mbps 20 y 30 0.61 Mbps

Tabla 6.9. Reparto el ancho de banda y balanceo de carga.

Como muestra la tabla anterior, para el switch 6 del laboratorio 3.5 (por ejemplo), el

tráfico correspondiente a la cámara IP número 5 (correspondiente a la VLAN 80) irá por

el troncal correspondiente a la interfaz fastEthernet 0/11 del switch. Por otro lado, el

tráfico de las VLANs 20 y 30 (Counter Strike y League of Legends) irán por el segundo

troncal, correspondiente a la interfaz fastEthernet 0/12. Así, se está balanceando el

tráfico.

Como ya se ha dicho, el balanceo de carga se realizará en el switch raíz, que en

nuestro caso será el multilayer. En el anexo (capítulo 15), se recoge el conjunto de

comandos que hay que introducir en este switch para conseguir el balanceo de carga

según la tabla anterior. Por otro lado, en el punto 11, se puede ver la simulación en

GNS3 de la red (incluyendo todos estos aspectos: VLANs, balanceo, STP, etc).

48


6.5 Jerarquía y direccionamiento IP.

Una vez se ha estudiado y propuesto una estructura lógica de la red, se propone un

despliegue de direccionamiento IP.

En primer lugar, se debe diferenciar entre el direccionamiento estático y dinámico a

través del protocolo DHCP. Analizando los equipos de la red, lo más lógico es asignar

una dirección IP estática a todos los servidores de juegos y a las cámaras IP de

seguridad. Por otro lado, el resto de equipos podrán obtener una dirección IP de forma

dinámica en un rango determinado, excluyendo aquellas direcciones que asignemos de

forma fija.

Dada la libertad que se dispone para utilizar direccionamiento privado dentro de esta

red, se utiliza la dirección 192.168.0.0/16 para la LPP. A partir de aquí, se construyen

diferentes subredes con distintos equipos, de forma que se respete la jerarquía. Es decir,

las subredes tendrán una máscara superior a /16.

Para la asignación de las direcciones de subred, se proponen dos modelos diferentes

(A y B). A continuación, se analizarán las ventajas e inconvenientes de ambos modelos

y se elegirá el que se considera más óptimo.

1. Esquema de direccionamiento A).

En base a las 10 subredes de las que se dispone, se dividen los bits correspondientes

al último octeto de la siguiente forma. Se toman 4 bits para crear subredes y 4 bits para

los hosts de cada subred. De esta forma, hay subredes y equipos de sobra para esta LPP.

192.168.1. xxxx|xxxx /28

Con este esquema de direccionamiento, se tienen 24 subredes (mayor que 10) con 16

equipos cada una de ellas. No se debe olvidar que hay que quitar la dirección de subred,

y de difusión. En total, tenemos 14 direcciones para asignar a cada VLAN.

A continuación, se muestra el posible direccionamiento que asignaríamos a las VLANs:

Primeros 4 bits Subred Dirección de subred VLAN

0000 1 192.168.1.0 /28 10

0001 2 192.168.1.16 /28 20

0010 3 192.168.1.32 /28 30

0011 4 192.168.1.48 /28 40

0100 5 192.168.1.64 /28 50

0101 6 192.168.1.80 /28 60

0110 7 192.168.1.96 /28 70

0111 8 192.168.1.112 /28 100

1000 9 192.168.1.128 /28 101

Tabla 6.10. Direccionamiento IP, esquema A.

Como ya se ha dicho, se asigna de forma dinámica, por DHCP, las direcciones IP

correspondientes a un rango de direcciones dentro de la subred, que no sean ni las

reservadas de difusión y subred ni las asignadas de forma estática a los servidores. La

VLAN correspondiente a las cámaras tendrá todas las direcciones estáticas.

49


Este esquema de direccionamiento es muy eficiente en cuanto al ahorro de

direcciones IP. Esto sería una solución muy buena si en un futuro la red se ampliase de

forma considerable y se tuviera que ser muy eficiente en la asignación.

Sin embargo, este esquema tiene la desventaja de que es poco intuitivo en el sentido

de que al tener una máscara de 28 bits, sería más lento localizar una dirección IP

aleatoria dentro de la red. Por tanto, se propone un segundo modelo, que desperdicia

más direcciones IP pero es muy cómodo para los administradores de la red.

2. Esquema de direccionamiento B).

En este caso, el tercer octeto de la dirección IP corresponderá con la subred (VLAN)

y el último byte se deja libre para los hosts. En este caso, se tienen 254 direcciones IP

disponibles para cada VLAN. Así mismo, 255 posibles subredes.

A continuación, se muestra la asignación definitiva de direcciones IP, por subredes:

VLAN 10 192.168.10.0 /24

VLAN 20 192.168.20.0 /24

VLAN 30 192.168.30.0 /24

VLAN 40 192.168.40.0 /24

VLAN 50 192.168.50.0 /24

VLAN 60 192.168.60.0 /24

VLAN 70 192.168.70.0 /24

VLAN 100 192.168.100.0 /24

VLAN 110 192.168.110.0 /24

VLAN 101 192.168.101.0 /24

Los servidores que necesitamos que tengan una IP fija son los de las VLANs:

VLAN 20 Counter Strike La dirección IP de la interfaz (VLAN) es

192.168.20.1/24, la dirección IP de la puerta de enlace es la 192.168.20.2/24, la del

servidor es la 192.168.20.3/24 y la de los hosts puede ser cualquiera a partir de

192.168.20.4/24.

VLAN 40 Minecraft La dirección IP de la interfaz (VLAN) es



192.168.40.4/24.

VLAN 50 Team Fortress La dirección IP de la interfaz (VLAN) es



192.168.50.4/24.

50


VLAN 110 Esta VLAN se usa para el asignar direccionamiento IP a los switches.

En este caso, el direccionamiento de cada switch se hace dependiendo del número de

switch:

Switch 1 192.168.110.1 /24

Switch 2 192.168.110.2 /24

Switch 3 192.168.110.3 /24

Switch 4 192.168.110.4 /24

Switch 5 192.168.110.5 /24

Switch 6 192.168.110.6 /24

Switch 7 192.168.110.7 /24

Switch 8 192.168.110.8 /24

Switch Multilayer 192.168.110.10 /24

VLAN 101 Esta VLAN se usa para los equipos de gestión de nuestra red:

Equipo de gestión G1 192.168.101.1 /24




Las cámaras de seguridad de la VLAN 80 tendrán las siguientes direcciones IP

asignadas de forma estática:

Cámara 1 192.168.70.10/24

Cámara 2 192.168.70.20/24

Cámara 3 192.168.70.30/24

Cámara 4 192.168.70.40/24

Cámara 5 192.168.70.50/24

Por tanto, se tienen los siguientes rangos de direcciones IP posibles para asignar de

forma dinámica con DHCP:

Subred Dirección de subred Rango libre para DHCP VLAN

10 192.168.10.0 /24 192.168.10.11 - 192.168.10.254 10

20 192.168.20.0 /24 192.168.20.11 - 192.168.20.254 20

30 192.168.30.0 /24 192.168.30.11 - 192.168.20.254 30

40 192.168.40.0 /24 192.168.40.11 - 192.168.20.254 40

50 192.168.50.0 /24 192.168.50.11 - 192.168.20.254 50

60 192.168.60.0 /24 192.168.60.11 - 192.168.10.254 60

70 192.168.70.0 /24 Cámaras de seguridad: IP estáticas 70

101 192.168.101.0 /24 Equipos de gestión: IP estáticas 101

110 192.168.110.0 /24 Direccionamiento de swtiches: IP estáticas 110

Tabla 6.11. Rango de direcciones IP libres para asignar por DHCP.

Los planos lógicos de la red, incluyendo las subredes y las VLANs son los

siguientes:

51




52



6.6 Protocolos y Servicios de Red

Servicio DHCP 6.6.1

DHCP (siglas en inglés de Dynamic Host Configuration Protocol, en español

«protocolo de configuración dinámica de host») es un protocolo de red que permite a

los clientes de una red IP obtener sus parámetros de configuración automáticamente. Se

trata de un protocolo de tipo cliente/servidor en el que generalmente un servidor posee

una lista de direcciones IP dinámicas y las va asignando a los clientes conforme éstas

van quedando libres, sabiendo en todo momento quién ha estado en posesión de esa IP,

cuánto tiempo la ha tenido y a quién se la ha asignado después.

Cada dirección IP debe configurarse manualmente en cada dispositivo y, si el

dispositivo se mueve a otra subred, se debe configurar otra dirección IP diferente. El

DHCP le permite al administrador supervisar y distribuir de forma centralizada las

direcciones IP necesarias y, automáticamente, asignar y enviar una nueva IP si fuera el

caso en que el dispositivo es conectado en un lugar diferente de la red.

El protocolo DHCP incluye tres métodos de asignación de direcciones IP:

53


Asignación manual o estática: Asigna una dirección IP a una máquina

determinada. Se suele utilizar cuando se quiere controlar la asignación de

dirección IP a cada cliente, y evitar, también, que se conecten clientes no

identificados.

Asignación automática: Asigna una dirección IP a una máquina cliente la

primera vez que hace la solicitud al servidor DHCP y hasta que el cliente la

libera. Se suele utilizar cuando el número de clientes no varía demasiado.

Asignación dinámica: el único método que permite la reutilización dinámica de

las direcciones IP. El administrador de la red determina un rango de direcciones

IP y cada dispositivo conectado a la red está configurado para solicitar su

dirección IP al servidor cuando la tarjeta de interfaz de red se inicializa. El

procedimiento usa un concepto muy simple en un intervalo de tiempo

controlable. Esto facilita la instalación de nuevas máquinas clientes.

Método de asignación en DHCP:

1. El cliente hace un broadcast de un mensaje DHCPDISCOVER en su subred

física. El mensaje DHCPDISCOVER puede incluir algunas opciones como

sugerencias de la dirección de red, duración del arrendamiento, etc.

2. Cada servidor puede responder con un mensaje DHCPOFFER que incluye una

dirección de red disponible y otras opciones de configuración.

3. El cliente recibe uno o más mensaje DHCPOFFER de uno o más servidores.

Elige uno basándose en los parámetros de configuración ofertados y hace un

broadcast de un mensaje DHCPREQUEST que incluye la opción identificadora

del servidor para indicar qué mensaje ha seleccionado.

4. Los servidores reciben el broadcast de DHCPREQUEST del cliente. Los

servidores no seleccionados utilizan el mensaje como notificación e que el

cliente ha declinado su oferta. El servidor seleccionado vincula al cliente al

almacenamiento persistente y responde con un mensaje DHCPACK que

contiene los parámetros de configuración para el cliente. La combinación de las

direcciones hardware y asignada del cliente constituyen un identificador único

de su arrendamiento y las usan tanto el cliente como el servidor para identificar

cualquier arrendamiento al que se haga referencia en un mensaje DHCP. El

campo "your IP address" en los mensaje DHCPACK se rellena con la dirección

de red seleccionada.

5. El cliente recibe el mensaje DHCPACK con parámetro de configuración.

Realiza un chequeo final de estos parámetros, por ejemplo con ARP para la

dirección de red asignada, y registra la duración del arrendamiento y el cookie

de identificación de éste especificado en el mensaje DHCPACK. En este punto,

el cliente está configurado. Si el cliente detecta un problema con los parámetros

en el mensaje DHCPACK, envía un mensaje DHCPDECLINE al servidor y

reinicia el proceso de configuración. El cliente debería esperar un mínimo de

diez segundos antes de reiniciar este proceso para evitar un exceso de tráfico en

la red en caso de que se produzca algún bucle.

54


Si el cliente recibe un mensaje, reinicia el proceso de configuración.

6. Puede elegir renunciar a su arrendamiento enviando un mensaje

DHCPRELEASE al servidor. El cliente especifica el arrendamiento al que

renuncia incluyendo sus direcciones hardware y de red

Fig. 6.11. Protocolo DHCP.

En nuestro caso se trata de una red con un número elevado de equipos y muchas

VLANs para los diferentes servicios que se ofrecen. Por lo que este servicio de DHCP

nos será muy práctico para la asignación de las direcciones IP de los diferentes equipos

que se conecten a la red, de forma que cuando un usuario conecte su equipo este

automáticamente se le asigne una dirección IP. El switch multilayer será el encargado

de actuar como servidor DHCP de nuestra red y un aspecto a tener en cuenta deberá ser

las diferentes VLANs que conforman nuestra red.

En el switch multilayer lo primero que hay que hacer es asignar una dirección IP a

cada interfaz de las distintas VLANs correspondientes con el rango IP que le

corresponde. Lo siguiente será crear los diferentes pool DHCP para los diferentes

rangos de direcciones IP que se desean asignar para cada una de las VLANs, y por

último, las IPs de exclusión que no se desean ser asignadas.

Una vez realizada la configuración anterior activaremos el switch multilayer como

servidor DHCP.

Este sería el proceso por el cual se asignarían las diferentes IP a los equipos mediante

DHCP. Los comandos que se deben introducir se pueden encontrar en el anexo

correspondiente a configuración DHCP.

Por otro lado, el switch multilayer también actuará como cliente DHCP de cara al

ISP para poder obtener una dirección IP en la interfaz que conecta con la red exterior

(Internet).

Podemos encontrar los comandos necesarios para configurar este servicio en el anexo

correspondiente a DHCP.

55


Servicio NAT 6.6.2

La traducción de direcciones de red o NAT (del inglés Network Address Translation)

es un mecanismo utilizado por routers IP para intercambiar paquetes entre dos redes que

asignan mutuamente direcciones incompatibles. Consiste en convertir, en tiempo real,

las direcciones utilizadas en los paquetes transportados. También es necesario editar los

paquetes para permitir la operación de protocolos que incluyen información de

direcciones dentro de la conversación del protocolo.

El tipo más simple de NAT proporciona una traducción una-a-una de las direcciones

IP. La RFC 2663 se refiere a este tipo de NAT como NAT Básico, también se le conoce

como NAT una-a-una. Es corriente ocultar un espacio completo de direcciones IP,

normalmente son direcciones IP privadas, detrás de una única dirección IP (o pequeño

grupo de direcciones IP) en otro espacio de direcciones (normalmente público).

Entonces, mientras que el servidor de DHCP asigna direcciones IP dinámicas a los

dispositivos que se encuentran dentro de la red, los routers habilitados para NAT

retienen una o varias direcciones IP de Internet válidas fuera de la red. Cuando el cliente

envía paquetes fuera de la red, NAT traduce la dirección IP interna del cliente a una

dirección externa. Para los usuarios externos, todo el tráfico que entra a la red y sale de

ella tiene la misma dirección IP o proviene del mismo conjunto de direcciones.

Su uso más común es permitir utilizar direcciones privadas para acceder a Internet.

Existen rangos de direcciones privadas que pueden usarse libremente y en la cantidad

que se quiera dentro de una red privada. Si el número de direcciones privadas es muy

grande puede usarse solo una parte de direcciones públicas para salir a Internet desde la

red privada. De esta manera simultáneamente sólo pueden salir a Internet con una

dirección IP tantos equipos como direcciones públicas se hayan contratado. Esto es

necesario debido al progresivo agotamiento de las direcciones IPv4. Se espera que con

el advenimiento de IPv6 no sea necesario continuar con esta práctica.

Fig. 6.13. Protocolo NAT.

NAT tiene muchas formas de funcionamiento, entre las que destacan:

56


NAT Estático. Conocida también como NAT 1:1, es un tipo de NAT en el que

una dirección IP privada se traduce a una dirección IP pública, y donde esa

dirección pública es siempre la misma. Esto le permite a un host, como un

servidor Web, el tener una dirección IP de red privada, pero aun así ser visible

en Internet.

Dinámica. Es un tipo de NAT en la que una dirección IP privada se mapea a una

IP pública basándose en una tabla de direcciones de IP registradas (públicas).

Normalmente, el router NAT en una red mantendrá una tabla de direcciones IP

registradas, y cuando una IP privada requiera acceso a Internet, el router elegirá

una dirección IP de la tabla que no esté siendo usada por otra IP privada. Esto

permite aumentar la seguridad de una red dado que enmascara la configuración

interna de una red privada, lo que dificulta a los hosts externos de la red el poder

ingresar a ésta. Para este método se requiere que todos los hosts de la red

privada que deseen conectarse a la red pública posean al menos una IP pública

asociada.

Sobrecarga. La más utilizada es la NAT de sobrecarga, conocida también como

PAT (Port Address Translation - Traducción de Direcciones por Puerto), NAPT

(Network Address Port Translation - Traducción de Direcciones de Red por

Puerto), NAT de única dirección o NAT multiplexado a nivel de puerto.

Solapamiento. Cuando las direcciones IP utilizadas en la red privada son

direcciones IP públicas en uso en otra red, el encaminador posee una tabla de

traducciones en donde se especifica el reemplazo de éstas con una única

dirección IP pública. Así se evitan los conflictos de direcciones entre las

distintas redes.

Los dispositivos NAT no tienen un comportamiento uniforme y se ha tratado de

clasificar su uso en diferentes clases. Existen cuatro tipos de NAT:

NAT de cono completo (Full-Cone NAT). En este caso de comunicación

completa, NAT mapeará la dirección IP y puerto interno a una dirección y

puerto público diferentes. Una vez establecido, cualquier host externo puede

comunicarse con el host de la red privada enviando los paquetes a una dirección

IP y puerto externo que haya sido mapeado. Esta implementación NAT es la

menos segura, puesto que una atacante puede adivinar qué puerto está abierto.

NAT de cono restringido (Restricted Cone NAT). En este caso de la conexión

restringida, la IP y puerto externos de NAT son abiertos cuando el host de la red

privada quiere comunicarse con una dirección IP específica fuera de su red. El

NAT bloqueará todo tráfico que no venga de esa dirección IP específica.

NAT de cono restringido de puertos (Port-Restricted Cone NAT). En una

conexión restringida por puerto NAT bloqueará todo el tráfico a menos que el

host de la red privada haya enviado previamente tráfico a una IP y puerto

57


especifico, entonces solo en ese caso ésa IP:puerto tendrán acceso a la red

privada.

NAT Simétrico (Symmetric NAT). En este caso la traducción de dirección IP

privada a dirección IP pública depende de la dirección IP de destino donde se

quiere enviar el tráfico.

En la red interna, habrá un router proporcionado por el proveedor de servicio o, en su

defecto, habrá un router 2621XM, que será el que separa la parte inside de la outside,

por lo que habrá que configurar dicho router para que implemente el servicio de NAT.

Deberemos configurar el interfaz del router que conecta con internet que será outside y

una interfaz que conecta con nuestra red (conectada al switch multilayer), que será

inside. Tras definir los diferentes interfaces, deberemos crear una lista de acceso para

indicar las IPs que queremos traducir del lado inside al lado outside. Al tener VPNs,

deberemos considerar traducir todas las IPs de la forma 192.168.0.0/16.

Los diferentes comandos que hay que usar para configurar este servicio se

encuentran en el anexo correspondiente a la configuración de NAT.

Servicio NTP 6.6.3

Network Time Protocol (NTP) es un protocolo de Internet para sincronizar los

relojes de los sistemas informáticos a través del enrutamiento de paquetes en redes con

latencia variable. NTP utiliza UDP como su capa de transporte, usando el puerto 123.

Está diseñado para resistir los efectos de la latencia variable.

NTP utiliza el Algoritmo de Marzullo con la escala de tiempo UTC, incluyendo

soporte para características como segundos intercalares. NTPv4 puede mantenerse

sincronizado con una diferencia máxima de 10 milisegundos (1/100 segundos) a través

de Internet, y puede llegar a acercarse hasta 200 microsegundos (1/5000 segundos) o

más en redes de área local sobre condiciones ideales.

El demonio NTP de Unix es un proceso de nivel de usuario que se ejecuta

continuamente en la máquina que soporta NTP, y la mayor parte del protocolo está

implementado en este proceso de usuario. Para obtener el mejor rendimiento de NTP, es

importante tener un reloj NTP estándar con lazo de seguimiento de fase implementado

en el kernel del Sistema operativo, en vez de sólo usar la intervención de un demonio

NTP externo.

NTP utiliza un sistema de jerarquía de estratos de reloj, en donde los sistemas de

estrato 1 están sincronizados con un reloj externo tal como un reloj GPS ó algún reloj

atómico. Los sistemas de estrato 2 de NTP derivan su tiempo de uno ó más de los

sistemas de estrato 1, y así consecutivamente (cabe mencionar que esto es diferente de

los estratos de reloj utilizados en los sistemas de telecomunicaciones).

Las estampas de tiempo utilizadas por NTP consisten en un segundo de 32-bit y una

parte fraccional de 32-bit, dando con esto una escala de 232 segundos (136 años), con

una resolución teórica de 2−32 segundos (0.233 nanosegundos). Aunque las escalas de

tiempo NTP se redondean cada 232 segundos, las implementaciones deberían

desambiguar el tiempo NTP utilizando el tiempo aproximado de otras fuentes. Esto no

58


es un problema en la utilización general ya que esto solamente requiere un tiempo

cercano a unas cuantas décadas.

Hay una forma menos compleja de NTP que no requiere almacenar la información

respecto a las comunicaciones previas que se conoce como Protocolo Simple de Tiempo

de Red ó SNTP. Ha ganado popularidad en dispositivos incrustados y en aplicaciones

en las que no se necesita una gran precisión.

Para nuestra red la configuración de este servicio se realiza en el switch multilayer,

que es el que se encuentra antes de la red exterior y se realizara siguiendo los comandos

que se encuentran en el anexo correspondiente a la configuración de NTP.

6.7 Interconexión con ISP

Sin duda alguna, a día de hoy, no se puede concebir un evento de este tipo sin

conexión a Internet ya sea para consultas, juegos con necesidad de conexión online, etc.

La solución tecnológica que se usará para conectar nuestra LPP con la red exterior

(Internet) será FTTH con una velocidad de 100 Mbps. Dicha tecnología se basa en la

utilización de cables de fibra óptica y sistemas de distribución ópticos adaptados para la

distribución de servicios avanzados.

Esta tecnología se basa en la utilización de fibra óptica hasta el usuario o cliente. La

red de acceso entre el cliente y el último nodo de distribución puede realizarse con una

o dos fibras ópticas dedicadas a cada cliente (una conexión punto-punto que resulta en

una topología en estrella) o una red óptica pasiva (del inglés Passive Optical Network,

PON) que usa una estructura arborescente con una fibra en el lado de la red y varias

fibras en el lado usuario.

Las ventajas que tiene esta tecnología es la enorme capacidad de transmisión de la

información, la baja atenuación permitiendo largas distancias sin necesidad de

repetidores y facilidad de instalación. En nuestro caso su instalación se hará de forma

muy sencilla conectando el conector del cable facilitado por el CSIRC de la universidad

de Granada al router que se encuentra en la frontera de nuestra red.

En la siguiente figura se ejemplifica el esquema de conexión a Internet a partir del

ISP con nuestra red interna.

59


Fig. 6.14. Conexión con ISP.

6.8 Seguridad

La seguridad en la red es un nivel de seguridad que garantiza el óptimo

funcionamiento de todas las máquinas de dicha red, y que todos los usuarios que se

encuentren en la misma no vean afectados los recursos que les han sido concedidos.

Hay que garantizar tanto la seguridad física como la lógica, además de garantizar la

privacidad de la información de los usuarios de la red.

La planificación de la seguridad en el diseño de la red es de suma importancia, pues

de esto depende el buen funcionamiento de la red y evita a los administradores trabajo

posterior y pérdida de datos.

En el caso de la LPP, también se deben tener en cuenta todos estos aspectos para

proteger la privacidad de los usuarios y mejorar la experiencia de juego de los mismos.

Como se ha descrito anteriormente, la estructura de la LPP sigue un diseño

jerárquico, es decir, la estructura está dividida en tres “capas”, aunque en este caso,

debido al tamaño reducido de la red, son solo dos. Estos dos niveles de jerarquía son

acceso y distribución. Se puede implementar seguridad en ambos niveles. Por otra parte,

algunos de los juegos que se implementan en la LPP requieren conexión a Internet, por

lo tanto también se implementa seguridad en el acceso a Internet.

Seguridad en nivel de acceso 6.8.1

6.8.1.1.1 Control de tormenta de broadcast

Los broadcast son indispensables en la comunicación entre los equipos de

networking y otros dispositivos. Son utilizados para determinar a quién corresponde una

MAC escpecíficamente o hacer la relación IP-MAC. Cuando se envían demasiados

broadcast, el elevado ancho de banda que consumen puede llegar a ralentizar el flujo de

tráfico, presentando una alta utilización de ancho de banda en las interfaces.

Internet

R_2621XM

SW Multilayer

60


Implementando el control de tormenta de broadcast, los switches son capaces de

limitar los efectos que este tipo de tramas provocan en la red, como el aumento del

retardo. Para ello, se definen unos umbrales máximos, para las tramas de broadcast y

multicast. Cuando se rebase este umbral, se hace shutdown al puerto o se envía un

mensaje SNMP al sistema de gestión.

En el diseño de la LPP el sistema que se usa como método de monitorización es el

protocolo SNMP, por lo tanto se configurarán los switches para que envíen un mensaje

SNMP (trap) al sistema de gestión, cuando el tráfico broadcast del canal sea un 50%

del ancho de banda total del canal. Los comandos a introducir se detallarán en el anexo.

6.8.1.1.2 Seguridad por MAC

El acceso a los puertos por parte de cada usuario puede ser controlado por medio de

la MAC. Existen una lista de MAC seguras asociadas a cada puerto, aunque hay un

máximo. Uno de los problemas de seguridad que se solventan usando este tipo de

seguridad es el problema de la suplantación de equipos, además de impedir la conexión

de equipos “no controlados” por los administradores. Hay varios tipos de MAC seguras:

- Dynamic: las direcciones MAC se aprenden mediante switching aunque no se

guardan en la configuración.

- Static: las direcciones MAC se configuran manualmente en el switch y se

guardan en la configuración.

- Sticky: las direcciones MAC se aprenden dinámicamente y se guardan.

Cuando se detecta una violación de MAC segura se pueden llevar a cabo varias

acciones:

- Shutdown: El puerto se apaga y manda un mensaje SNMP al gestor.

- Protect: Se corta todo el tráfico hasta que el número de MAC cae por debajo del

número configurado.

- Restrict: Igual que “protect” y además se envía una trap SNMP.

Las MAC configuradas en cada puerto pueden ser eliminadas de dos formas: tras

pasar un tiempo determinado (Absolute) o tras un tiempo de inactividad determinado

(Inactivity).

En la implementación de la LPP, el conjunto de puertos dedicados a un juego en

concreto va a ser siempre el mismo, es decir, serán los jugadores con su equipo portátil

los que vayan cambiando de sitio, dificultando así el acceso por MAC segura. Por lo

tanto, se puede elegir entre dos opciones para solucionar este problema. Como primera

solución se pueden crear en el switch correspondiente tantas MAC seguras

(dinámicamente) como jugadores haya en el juego en ese momento, para después,

cuando haya un cambio de jugadores, eliminar estas MAC de la configuración del

switch. La segunda opción sería establecer un número de MAC seguras bastante alto

como para que no se colapse durante toda la duración de la LPP. Preferiblemente se

intentará llevar a cabo la primera solución.

61


Las MAC seguras se eliminarán tras un tiempo determinado de inactividad. Los

comandos a introducir se detallarán en el anexo.

6.8.1.1.2.1 Monitorización de puertos

En la configuración del switch podemos indicar que un puerto sea monitorizado, y

copiar todos los paquetes del puerto monitorizado en otro puerto llamado SPAN. Hay

varios tipos de SPAN:

- SPAN local: Origen y destino están en el mismo switch.

- SPAN basado en VLAN: El origen no es un puerto sino una VLAN.

- SPAN remoto: Origen y destino están en distintos switch.

En la implementación de la LPP, el gestor puede usar la monitorización de puertos

para monitorizar a un usuario en particular cuando este tenga un problema, y así poder

diagnosticarlo de forma más efectiva. Para ello, usará alguno de los PCs de gestión del

aula 3.4 que han sido habilitados para tal fin, o con su equipo portátil, si el switch en el

que se encuentra el puerto a monitorizar tiene algún puerto libre al que copiar el tráfico.

Una vez que el tráfico haya sido copiado al PC o portátil correspondiente este podrá

ser analizado mediante algún programa destinado a tal fin, por ejemplo, Wireshark. Los

comandos a introducir se detallarán en el anexo.

Seguridad en nivel de distribución 6.8.2

6.8.2.1 Listas de acceso

En el nivel de distribución es donde se realizan las labores de filtrado mediante listas

de acceso. Generalmente este filtrado es realizado por routers, aunque si se dispone de

un switch multilayer (de capa 3), este también puede contener y crear listas de acceso,

puesto que implementa todas las funcionalidades de un router. Se puede filtrar el tráfico

de la red según en qué esté basada la lista de acceso, IP, puerto, protocolos… A

continuación, se detallan los tipos de listas de acceso que existen:

- Standard (1-99): Están basadas en la IP origen y destino.

- Extendida (100-199): Basadas en IP, protocolos y puertos de capa 4 (TCP,

UDP).

- Named: Similar a extendida pero se las puede nombrar.

- Dinámicas: Si un usuario quiere que su tráfico progrese a través de un router,

dicho usuario tiene que hacer telnet al router. El tráfico progresa mientras el

telnet este activo.

- Time-based: Permite que las listas de acceso se apliquen en franjas de tiempo.

- Context-based: Inspecciona los paquetes y permite aperturas temporales en las

listas de acceso.

62


A continuación se detalla el funcionamiento de las listas de acceso, en concreto las

que usa Cisco IOS.

Veamos el proceso completo:

1. Cuando entra una trama a través de una interfaz, el router verifica si la dirección

de capa 2 (MAC) concuerda o si es una trama de broadcast.

2. Si se acepta la dirección de la trama, la información de la trama se elimina y el

router busca una ACL en la interfaz entrante.

3. Si existe una ACL se comprueba si el paquete cumple las condiciones de la

lista.

4. Si el paquete cumple las condiciones, se ejecuta la acción de aceptar o

rechazar el paquete.

5. Si se acepta el paquete en la interfaz, se compara con las entradas de la tabla de

enrutamiento para determinar la interfaz destino y conmutarlo a aquella interfaz.

Luego el router verifica si la interfaz destino tiene una ACL.

6. Si existe una ACL, se compara el paquete con las sentencias de la lista y si

el paquete concuerda con una sentencia, se acepta o rechaza el paquete según

se indique.

7. Si no hay ACL o se acepta el paquete, el paquete se encapsula en el

nuevo protocolo de capa 2 y se envía por la interfaz hacia el dispositivo

siguiente.

Fig. 6.15. Listas de acceso.

En el diseño y puesta en marcha de la LPP, las listas de acceso representan una de las

aplicaciones de seguridad más importantes, si no la que más, de todas las vistas. Se

aplicarán listas de acceso a la hora de permitir, por ejemplo, los flujos de algunos juegos

que usen TCP o UDP como protocolo de transporte, permitiendo que estos flujos vayan

solo a los usuarios conectados a los puertos que estén usando dicho juego, es decir, que

no puedan salir de la VLAN asignada a dicho juego. Las listas de acceso también

permitirán que los usuarios de la LPP puedan acceder a Internet o a un servidor de

almacenamiento. Todo esto será introducido en la configuración del switch multilayer.

63


Esta aplicación de seguridad es complementaria a las VLANs en cuanto a la

implementación de juegos en la LPP se refiere. Estas listas de acceso se harán en

referencia a la descripción de las VLANs en la tabla (1) y al direccionamiento IP. A

continuación se detalla la función de las distintas listas de acceso, describiendo a qué

VLANs hace referencia cada una.

VLAN SERVICIO LISTA DE

ACCESO DESCRIPCION

VLAN1 Subred de gestión 101

Todos los equipo

implementarán esta

VLAN

VLAN10 Hearthstone 102

Permitir el tráfico TCP,

UDP dentro de la

VLAN, y el acceso a

internet.

VLAN20 Counter Strike 103

Permitir el tráfico TCP

y UDP dentro la

VLAN20.

VLAN30 League of Legends 104

Permitir el tráfico UDP

y TCP dentro de la

VLAN30 e IP. Acceso

a Internet

VLAN40 Minecraft 105

Permitir el tráfico TCP

dentro de la VLAN40 e

IP. Acceso a Internet

VLAN50 Team Fortress 2 106


y TCP dentro de la

VLAN50 e IP. Acceso

a Internet

VLAN60 Street Fighter y Fifa 107


y TCP dentro de la

VLAN60 e IP. Acceso

a Internet

VLAN80 Sistema de

videovigilancia 108

Permitir el tráfico IP en

la VLAN80

VLAN100 Servidor OwnCloud 109

VLAN101 Equipos gestores

VLAN110 Gestion 101

Tabla 6.12. Descripción VLANs.

Adicionalmente, se configurará otra VLAN extra en la cual estará alojado el servidor

de almacenamiento Owncloud.

Configuración sistemas gestores

Para la configuración de los sistemas gestores se seguirán los tres pasos siguientes:

1) Configurar VLAN101 para las estaciones gestoras, estas estaciones deberán

tener conectividad con toda la red, es decir, con los equipos hardware (switches

y multilayer) y con el resto de usuarios. Para configurar esto, en las listas de

acceso de cada VLAN, en el multilayer, se introducirán dos líneas extra, que

permitan la conectividad de la propia VLAN con la VLAN101, en ambos

sentidos.

2) Configurar VLAN110 en todos los switches y en el multilayer, para asignarles

una IP y así permitir su gestión. Este paso se llevará a cabo creando una lista de

64


acceso nueva dentro del switch multilayer. Esta lista permitirá la conmutación

entre las VLANs 101 y 110, permitiendo que los equipos de gestión puedan

hacer TELNET o SSH a todos los switches de acceso y al multilayer.

3) En las listas de acceso de cada switch, se deberá denegar el protocolo TELNET,

SSH e ICMP a la VLAN110, a fin de que los usuarios no puedan acceder a los

switches. Para esto se deberán añadir dos líneas nuevas en cada lista de acceso

de los switches, con lo que denegaremos el tráfico IP en los puertos

correspondientes a TELNET y SSH.

Siguiendo estos pasos se consigue implantar un sistema de gestión seguro y eficiente.

En todas las VLANS, a la hora de realizar el direccionamiento IP, se han llevado a

cabo las siguientes consideraciones: las direcciones IP del tipo 192.168.X.1 están

reservadas para ser asignadas a la VLAN en sí. Además en el caso de los juegos cuyos

servidores se encuentran dentro de la red, las direcciones IP asignadas a dichos

servidores serán de la forma 192.168.X.2.

La descripción de todas las listas de acceso configuradas se pueden encontrar en el

anexo del documento.

Seguridad en Internet 6.8.3

Cuando se habla de seguridad, no sólo es importante implementarla en la parte

“interna” de la red, que es la parte que se ha descrito anteriormente, sino que también es

necesario implementar aplicaciones de seguridad en la parte “externa” de la red. Esto se

hace con el fin de evitar agujeros de seguridad que pueda tener la red. En el diseño de la

LPP se tendrán en cuenta principalmente dos aspectos de seguridad: la zona

desmilitarizada (DMZ) y el firewall.

6.8.3.1 Zona desmilitarizada (DMZ)

En seguridad informática, una zona desmilitarizada es una zona segura que se ubica

entre la red interna de una organización y la red externa, es decir, Internet. El objetivo

de la DMZ es que las conexiones desde la red interna y la externa a la DMZ estén

permitidas, mientras que las conexiones desde la DMZ solo pueden hacerse a la red

externa. La DMZ se usa habitualmente para situar servidores que es necesario que sean

accedidos desde fuera, como servidores de correo electrónico, Web y DNS.

Las conexiones que se realizan desde la red externa hacia la DMZ se controlan

generalmente utilizando “port address translation” (PAT). Una DMZ se crea a menudo

a través de las opciones de configuración del cortafuegos, donde cada red se conecta a

un puerto distinto de éste. Esta configuración se llama cortafuegos en trípode. Existen

múltiples configuraciones para la DMZ, se puede permitir uno, varios o ningún

protocolo para que los usuarios de la red local accedan a la DMZ.

Para el diseño de la LPP se implementará una DMZ en la cual se alojará el servidor

de almacenamiento Owncloud. Este servicio podrá ser accedido exclusivamente por los

usuarios participantes por la LPP, este es el motivo principal por el cual este servidor se

encontrará alojado en la DMZ.

65


6.8.3.2 Firewall

Un cortafuegos es una parte de un sistema o una red que está diseñada para bloquear

el acceso no autorizado a la red, permitiendo al mismo tiempo comunicaciones

autorizadas. Los cortafuegos pueden ser implementados en hardware o software. Todos

los mensajes que entren o salgan de la intranet pasan a través del cortafuegos, que

examina cada mensaje y bloquea aquellos que no cumplen con los requisitos de

seguridad establecidos. Existen varios tipos de cortafuegos:

Nivel de aplicación de pasarela: Aplica mecanismos de seguridad para

aplicaciones específicas, tales como servidores FTP y Telnet. Esto es muy

eficaz, pero puede imponer una degradación del rendimiento.

Circuito a nivel de pasarela: Aplica mecanismos de seguridad cuando una

conexión TCP o UDP es establecida. Una vez que la conexión se ha hecho, los

paquetes pueden fluir entre los anfitriones sin más control. Permite el

establecimiento de una sesión que se origine desde una zona de mayor seguridad

hacia una zona de menor seguridad.

Cortafuegos de capa de red: Funciona a nivel de red (capa 3 del modelo OSI,

capa 2 del stack de protocolos TCP/IP) como filtro de paquetes IP. A este nivel

se pueden realizar filtros según los distintos campos de los paquetes IP:

dirección IP origen, dirección IP destino. A menudo en este tipo de cortafuegos

se permiten filtrados según campos de nivel de transporte (capa 3 TCP/IP, capa

4 Modelo OSI), como el puerto origen y destino, o a nivel de enlace de datos (no

existe en TCP/IP, capa 2 Modelo OSI) como la dirección MAC.

Cortafuegos de capa de aplicación: Trabaja en el nivel de aplicación, de manera

que los filtrados se pueden adaptar a características propias de los protocolos de

este nivel. Un cortafuegos a nivel 7 de tráfico HTTP suele denominarse proxy, y

permite que los ordenadores de una organización entren a Internet de una forma

controlada. Un proxy oculta de manera eficaz las verdaderas direcciones de re.

Cortafuegos personal: Es un caso particular de cortafuegos que se instala como

software en un ordenador, filtrando las comunicaciones entre dicho ordenador y

el resto de la red. Se usa por tanto, a nivel personal.

Es frecuente conectar el cortafuegos a una tercera red, la DMZ, en la que se ubican

los servidores que deben permanecer accesibles desde la red exterior, como se ha

comentado anteriormente.

En la implementación de la LPP, debido a la limitación de los equipos de los que se

dispone, no es posible usar la conocida herramienta iptables para implementar el

firewall y la DMZ, esta solución sería la más completa y ofrecería más posibilidades de

implementación. Por este motivo, la solución que se propone es la de configurar un

cortafuegos en trípode, como se observa en la imagen de abajo. El cortafuegos no estará

implementado en su plenitud en una única lista de acceso, sino que en las listas de

acceso de cada VLAN se incluirá una línea en la cual se permitirá el acceso a Internet

por parte de cada usuario.

66


De forma análoga a lo anterior, es decir, en la implementación de las listas de acceso

para cada VLAN se contemplará el acceso por parte de los usuarios de la LPP al

servidor Owncloud ubicado en la DMZ.

Fig. 6.16. Firewall.

Que los usuarios puedan acceder desde fuera no es un problema importante, ya que la

solución de este problema radica en la implementación de NAT en nuestra red. Al

implementar NAT solo el mínimo número de puertos permanecerán abiertos,

imposibilitando ser accedidos desde Internet por cualquier usuario. Aunque NAT no se

ha implementado con este fin, su propio funcionamiento aporta esta medida de

seguridad.

6.9 Comportamiento de servicios y disponibilidad

La primera prioridad que se tiene cuando se comienza a dar un servicio es predecir su

comportamiento a lo largo de la vida del mismo, con el fin de estar preparados ante

posibles eventualidades que puedan propiciar un fallo en la disponibilidad del servicio.

Para evitar esta clase de problemas descritos, especificaremos a continuación ciertas

técnicas o recomendaciones que se podrán usar a la hora de la configuración de los

sistemas de forma que consigamos nuestro objetivo.

Técnicas de compartición de carga, y balanceo. 6.9.1

Cuando se habla de técnicas de compartición de carga y balanceo, se hace referencia

al conjunto de operación de gestión y/o configuración que nos permite elegir la cantidad

de tráfico que transcurrirá por cada uno de los enlaces de nuestra red.

Por ello, a continuación se definirá un conjunto de protocolos de red que en cierta

medida nos asegurarán un balanceo apropiado de la carga en la red. Además en dichas

tecnologías se indicarán ventajas e inconvenientes teniendo en cuenta el enfoque de

nuestro proyecto.

6.9.1.1 Distribución de tráfico en el Etherchannel

Se utiliza con el fin de que el balanceo de carga no provoque que un mismo flujo de

datos no tome caminos distintos, debido a que es posible que se haya configurado

balanceo de carga en una red pero que para los casos en los que solo existe una

comunicación para un origen y un destino. Esta tecnología nos permite así la agrupación

67


lógica de varios enlaces físicos Ethernet de forma que podamos tener un enlace de

mayor velocidad nominal.

Fig. 6.17. Etherchannel.

Entre las ventajas más importantes que se tienen usando esta tecnología, tenemos la

posibilidad del reparto de carga, el aumento de la capacidad de enlace y la robustez y

convergencia rápida, debido a que si un enlace fallara, Etherchannel redirige el tráfico

del enlace fallido a los otros enlaces, proporcionando una recuperación automática

mediante la redistribución de la carga entre los enlaces restantes. La convergencia es

completamente transparente para los usuarios y las aplicaciones de red, de forma que en

el caso que nos concierne puede sernos de gran utilidad.

Aunque también presenta inconvenientes en caso de no estar ante un escenario ideal

en el que, por ejemplo, se produzca un efecto de no balanceo debido a que existe una

comunicación dominante.

6.9.1.2 STP - Spanning Tree Protocol

Este protocolo, conocido ya por su funcionalidad para el correcto enrutamiento con

la garantía de que se no se tendrán bucles en la red, adquiere para nosotros una nueva

dimensión en la que nos permite manejar los flujos de tráfico.

Esto se hace mediante la configuración del switch, en la que mediante el

establecimiento de la prioridad de árbol de expansión de cada switch en el menor valor,

se selecciona el switch como puente principal para la VLAN asociada. Se puede

establecer la prioridad de switch para cualquier instancia de árbol de expansión. Esta

configuración afecta a la posibilidad de que un switch se elija como puente raíz.

De esta forma se puede establecer para cada una de las VLANs que componen

nuestra red, un camino distinto o no dependiendo de nuestro propio criterio de balanceo

de carga y teniendo en cuenta consideraciones específicas como son el ancho de banda

que consumirá cada una de las VLANs, si la configuración será permanente o temporal,

etc.

Este protocolo nos ofrece además la facilidad de la recuperación automática de la

ruta en caso de que cierto enlace se caiga por cualquier motivo, es decir, detecta

cambios en la topología de red. De esta forma, pasados 20 segundos sin recibir ningún

mensaje de tipo Hello, se entiende que la red ha cambiado y quizás algún puerto debe

pasar a bloquearse.

68


Una de las opciones que STP nos brinda es PortFast. Esta opción solo se usa en

switches o enlaces troncales que están conectados a una sola estación o host, para

permitir a dichos dispositivos conectarse directamente en vez de esperar la transición de

los estados de aprendizaje y escuchar al estado forwarding.

6.9.1.3 GLBP (Gateway Load Balancing Protocol)

Es un protocolo propiedad de Cisco que ante la complejidad para el balanceo de

carga con protocolos como HSRP o VRRP nos ofrece una forma más sencilla, sin tanta

configuración como es necesaria para dichos protocolos.

Para ello, se parte de que todos los routers reenvían paquetes en un grupo dado y que

todos los hosts de la red son configurados con la misma IP virtual del DG, de forma que

el balanceo se consigue asignando distintos proxy ARP a las peticiones ARP de los

hosts, es decir, asignando distintas MAC virtuales a cada uno de los hosts.

Dentro del grupo GLBP, se elige un Active Virtual Gateway (AVG), que será el de

mayor prioridad o, en su defecto, el de mayor IP, el cual responde todas las peticiones

ARP y asigna las MAC virtuales antes comentadas a cada uno de los routers activos del

grupo, pudiéndose hasta cuatro. Estos routers son los AVF (Active Virtual Forwader) y

realmente esta asignación que el AVG hace de AVF es lo que constituye en sí el

balanceo de carga.

Para esta asignación encontramos tres modos o disciplinas que se siguen:

- Round Robin: distribución homogénea entre los AVF.

- Weighted: Más peso del AVF, lo que lleva a más repuestas ARP con la MAC

del AVF. Los pesos varían mediante el tracking de interfaces, de forma que cada

vez que el interfaz de un router se cae, este decrementa su peso.

- Host –dependent: cada Host recibirá siempre el mismo AVF

Recomendaciones para redundancia. 6.9.2

Cuando un host en una red quiere acceder a una red externa, necesita un Default

Gateway (DG) que haga de Proxy ARP. Si el DG cae, todos los hosts de esa red pierden

la conectividad hacia afuera de su red o hacia cualquier otra parte de una red más

grande.

Para ello, se proponen métodos que ofrezcan redundancia al nivel del DG, los cuales

suelen implementarse al nivel de distribución con equipos MLS.

6.9.2.1 HSRP (Hot Stand-by Router Protocol)

Este protocolo, propiedad de Cisco, necesita para funcionar de forma óptima que

para una subred haya dos interfaces de dos routers conectados, de forma que nos

permita disponer de un DG y varios de backup, en caso de que el primero deje de

funcionar o caiga por cualquier circunstancia.

69


Esos dos routers deben formar un grupo HSRP y que entre sí se monitoricen

mediante mensajes de tipo de hello, de forma que pudiendo estar en tre estados

diferentes (activo, standby y backup), si el activo dejase de funcionar, el que está en

backup pase al estado activo asumiendo instantáneamente todas sus funciones. De

nuevo, esta operación es totalmente transparente para los hosts a los que los routers dan

servicio siendo beneficioso para nuestro caso. HSRP tiene además una funcionalidad

muy útil, como es el tracking de interfaces, el cual permite decrementar la prioridad en

función de la fiabilidad de una interfaz concreta de ese router.

Al igual que con STP, este protocolo nos permite conseguir balanceo de carga por

VLAN, mediante la definición de grupos HSRP con distintas prioridades. Pero, de

igual forma, la capacidad de los enlaces se desaprovecha, ya que el único interfaz que

enruta paquetes desde la red de los hosts es el del HSRP activo.

6.9.2.2 VRRP (Virtual Router Redundancy Protocol)

Este protocolo es la versión no propietaria que más se parece a HSRP, con algunas

diferencias. Se tiene un Master router que hace las mismas funciones que el router

activo, de igual forma, existen grupos y prioridades. La comunicación entre routers se

realiza también mediante mensajes de tipo hello enviados cada 1s.

Como inconvenientes, se resalta el hecho de que VRRP no realiza tracking de

interfaces, privándonos de una más que interesante funcionalidad.

Por defecto está en modo preempt en el que un router que está en Active, permanece

en Active hasta que falle, aunque otro router tenga prioridad más alta y no es compatible

con HSRP, es decir, no pueden coexistir en el mismo router.

Conclusión 6.9.3

Tras ponderar todas las opciones disponibles con las que contamos, descritas en este

documento de la forma más concisa posible, pero sin olvidar los aspectos importantes,

finalmente nos decantamos por STP (Spanning Tree Protocol) como protocolo tanto de

balanceo como de recuperación de enlaces ante posibles caídas o errores.

Las principales razones de nuestra elección se basan en su facilidad de configuración,

puesto que es un protocolo fácil de implementar en la red. Por otro lado, tras haber

estudiado el tráfico que generan los servicios que vamos a prestar, vemos que están

acotados, de forma que haciendo uso de STP, es decir, priorizando distintos tráficos por

VLANs en nuestra red, vemos que será suficiente para obtener la calidad y la seguridad

suficiente para nuestro proyecto.

6.10 Inventario de Hardware y software de equipos que componen la

red

El inventario necesario para el despliegue de la infraestructura de red se recoge en

este punto, en el que se tendrá en cuenta tanto el hardware como el software que se

requerirá para la puesta en funcionamiento de los equipos, juegos, etc.

70


Como ya se ha descrito en la propuesta definitiva de red, tendremos a nuestra

disposición tres zonas correspondientes a tres aulas de la tercera planta: una zona

principal desde donde controlaremos el correcto funcionamiento de la red y dos zonas

secundarias donde estarán los equipos usuarios.

A continuación, mostramos en la siguiente tabla el número de equipos o elementos

de red que se necesitarán en cada una de las zonas, recogiendo así todos los

componentes que se han elegido en la propuesta de red.

Zonas Equipos de

red

Equipos de

usuario/gestión Cámaras Servidores Cableado

Principal 3(1) 4 1 4 54,2 m

Secundaria 1 3 22 2 - 197,6 m

Secundaria 2 3 22 2 - 197,6 m

Tabla 6.13. Equipamiento.

Con el fin de especificar el hardware necesario, trasladamos la información de la

tabla a la siguiente lista de inventario:

Inventario total de la infraestructura de red:

8 Switchs Catalyst 2950-12. Seis de ellos para las dos zonas secundarias y otros

dos para la zona principal.

Multilayer Cisco WS-C3550-24-SMI.

44 equipos de usuario.

equipos de gestión de red.

cámaras IP con el fin de vigilar que se siguen las normas establecidas además de

por la seguridad física de los equipos en las zonas.

equipos servidores de juegos disponibles para los usuarios.

500 metros de cableado UTP CAT 6.

200 conectores RJ45

Si se quiere hacer diferenciación por zonas, se tendrían las que aparecen a

continuación.

Zona Principal:

Switchs Catalyst 2950-12; en estos tendremos las cámaras y los equipos de

gestión de la red además de los puertos reservados y de uplink.

Switch Multilayer Cisco WS-C3550-24-SMI, del que colgarán los servidores de

juegos, los dos switchs anteriores y los demás encargados del acceso de los

equipos usuario.

Cámara IP.

71


Cuatro servidores, uno para cada juego (Minecraft, Counter, Team Fortress) y

un cuarto que será un servidor Owncloud, con el fin de cubrir las demandas de

los jugadores actuales, contando con muestras limitaciones.

Cuatro ordenadores cuyo único uso será el de la gestión centralizada de la red.

Cableado de 54,2 metros.

26 conectores RJ45

Zona Secundaria (Laboratorio 3.3):

Switchs Catalyst 2950-12. Uno por cada banca de equipos de usuario.

22 equipos de usuario

cámaras IP, una en cada esquina del laboratorio.

197,6 metros de cableado de las mismas características que se han descrito

anteriormente.

60 conectores RJ45.

Zona Secundaria (Laboratorio 3.5):

Switchs Catalyst 2950-12. Uno por cada banca de equipos de usuario.

22 equipos de usuario

cámaras IP, una en cada esquina del laboratorio.

197,6 metros de cableado de las mismas características que se han descrito

anteriormente.

60 conectores RJ45.

En esta última lista se especifica exactamente el número de dispositivos, equipos o

artículos hardware que se tiene previsto utilizar en cada una de las zonas que

compondrán la LPP, por lo que en el inventario total es donde sí se han tenido en cuenta

soluciones en caso de que, por ejemplo, se necesiten más conectores RJ45.

Adicionalmente se incluyen en este inventario artículos que se tendrán que comprar y

que necesitaremos para el despliegue de la red:

Kit de herramientas para redes. Con ellas se realizarán la formación de los cables

necesarios para la red. (3 unidades)

Tiras de velcro para cableado para hacer módulos de cables y que estos puedan

ir juntos. (100 unidades)

Soporte adhesivo para bridas. (100 unidades)

72


Cinta americana. (50 metros)

Protector conector RJ45. (25 unidades)

6.11 Presupuesto

Una vez se ha realizado el inventario necesario para la puesta en marcha de la LAN

Party, pasamos al presupuesto. En este presupuesto, no se tiene en cuenta el precio de

los equipos disponibles en el laboratorio 3.4.

En cuanto a la seguridad física, se tienen dos opciones, designar a una o varias

personas de nuestro equipo para dicha tarea o la contratación de un guarda mediante una

empresa de seguridad, se reflejará el precio en caso de la subcontratación.

Teniendo en cuenta lo dicho anteriormente, vemos que el grueso de nuestro

presupuesto irá destinado al cableado, debido a que debemos interconectar los tres

laboratorios de la manera que en apartados anteriores se ha descrito. Con el fin de que

nuestro proyecto esté a la vanguardia en reducción de emisiones de gases contaminantes

y de sustancias tóxicas, en este apartado se tomaran en cuenta opciones en las que el

cableado se haya fabricado de forma respetuosa con el medio ambiente o que estos sean,

en la medida de lo posible, biodegradables.

Como ya se ha descrito en el apartado de propuestas de red y se ha definido

finalmente en el inventario, se necesitarán 550 metros de cable UTP CAT 6 y 200

conectores RJ-45. Se utilizará esta categoría de cable para garantizar con creces el

10BaseTx que se pide como requisito, pudiendo ofrecer hasta 100BaseTx y mejorando

así las características del cableado de red. Al igual que se han tomado más conectores

RJ45 de los necesarios con el fin de tener de sobra para que en el caso de que alguno

este defectuoso o que se estropee en el montaje de los cables, para el cableado se han

tomado aproximadamente unos 100 metros de más, con el mismo fin que con los

conectores macho.

A continuación, en la siguiente tabla proponemos el presupuesto con IVA incluido

para el cableado de la LPP ecológica:

EMPRESA ARTÍCULO UNIDADES PRECIO TOTAL

pccomponentes

Conector red RJ-45 Cat. 6

UTP Macho con Guias (100

uds)

2 19.25 € 38.5 €

pccomponentes

Bobina 305 m Cable de Red

Rígido UTP Cat.6 Libre de

halógenos

3 89 € 267 €

pccomponentes Protector conector RJ45 (25

uds) 8 3.95 € 31.6 €

Amazon Kit de herramientas para

redes 3 16.5 € 49.5 €

73


Amazon Tiras de velcro para

cableado (100 uds) 1 5.89 € 5.89 €

Amazon Soporte autoadhesivo para

bridas (100 uds) 1 4.59 € 4.59 €

Amazon Cinta americana Tesa

blanca (50 m) 1 8.38 € 8.38 €

TOTAL CON IVA 405.46 €

Tabla 6.14. Presupuesto.

De entre todas las empresas consultadas, se han seleccionado las arriba mencionadas,

debido a que ofrecían el precio más económico teniendo en cuenta el requisito de

sostenibilidad, pero a la vez se han buscado aquellos que nos proporcionen calidad

suficiente.

A continuación, se describe la mano de obra. Los cálculos de tiempo trabajado de

cada persona se han obtenido en el punto 12 del presente documento.

Presupuesto mano de obra 6.11.1

Tipo Cantidad Precio Total

Mano de obra

5h30min Ingenieros Junior 25 20€/h 2750€

Mano de obra

5h30min Ingenieros Senior 3 35€/h 577,5€

Mano de obra 3327,5€

Tabla 6.11.2 Presupuesto de la mano de obra.

Finalmente, se ha querido separar el presupuesto en dos partes, parte física en la que

se detalla los artículos y hardware necesario y la parte de mano de obra necesaria para la

implementación del proyecto de la LPP. De esta forma, se desea facilitar al lector los

distintos tipos de inversiones a realizar.

74


Juegos y aplicaciones 7

7.1 Minecraft

Información detallada del juego 7.1.1

Minecraft es un juego se tipo «mundo abierto» o sandbox desarrollado por Mojan y

comprado recientemente por Microsoft. Es el segundo juego más vendido de la historia.

Fig. 7.1. Pantalla inicial del juego.

7.1.1.1 Mojan

Es una compañía de videojuegos (anteriormente independiente) de origen sueco, que

actualmente es una subsidiaria de entera propiedad de Microsoft ya que la compró por

2.500 millones de dólares.

Fue fundada por Markus Persson, el cual también desarrolló Minecraft así como

otros juegos.

Funcionamiento 7.1.2

El funcionamiento del juego es bastante sencillo, es un mundo abierto compuesto por

bloques de diferentes tipos, cada bloque tiene unas características que permite

desarrollar nuevos bloques, objetos,…Estos a su vez te permiten hacer otros nuevos, y

así sucesivamente.

Además hay diferentes mobs (criaturas controladas por el ordenador) que pueden ser

buenos (Animales como vacas, ovejas,...) o malos (Zombies, esqueletos, brujas,…).

Cuando se mata a un mob, este puede dejar objetos varios dependiendo del tipo de mob,

por ejemplo una vaca puede dejar carne, un esqueleto huesos,….

Finalmente hay determinadas acciones que dan experiencia (Como matar mobs,

conseguir determinados materiales,…) y también logros (Primera vez que consigues

madera, hierro, diamantes,…)

75


Modos de juego 7.1.3

7.1.3.1 Supervivencia

El modo supervivencia se basa en la vida real a la vez con un poco de fantasía y se

trata de la supervivencia al ataque de las múltiples criaturas que surgen en la oscuridad

o de noche y de alimentarse. El máximo aguante que tienen los personajes consta de 10

corazones, (20 puntos de salud)

Fig. 7.2. Modo supervivencia.

7.1.3.2 Creativo

En el modo creativo) se centra enteramente en el aspecto de la construcción libre.

Los jugadores poseen un suministro ilimitado de todos los bloques y objetos del juego,

que pueden colocar y destruir de forma instantánea. Además, no son atacados por los

monstruos, no pueden recibir daño (aunque pueden morir cayendo al vacío) y pueden

volar libremente por el escenario. En este modo no se pueden romper bloques con una

espada de cualquier material, (esto sirve para no destruir el entorno cuando el jugador

golpea o ataca).

Fig. 7.3. Modo creativo.

7.1.3.3 Aventura

El modo aventura está destinado a los jugadores que se dediquen a crear mapas para

usuarios que deseen jugar en línea o solos, este modo de juego se basa en los siguientes

criterios que afectan al jugador en distintos sentidos:

El jugador solo puede romper un bloque si tiene la herramienta adecuada.

En algunas versiones la dificultad no puede ser modificada.

El jugador debe ir por un camino predefinido por el creador del mapa

(opcional).

Plataformas 7.1.4

Actualmente Minecraft se encuentra disponible para multitud de plataformas

incluidas las principales como Xbox 360, Xbox One, PlayStation 3 y PlayStation 4, así

76


como para PC, para los principales sistemas operativos; Microsoft Windows, OS X y

Linux; y dispositivos móviles; Android, iOS y Windows Phone.

Para la LPP se usarán ordenadores para jugar, sin importar el sistema operativo.

Requisitos 7.1.5

Los requisitos de Minecraft son muy variados ya que dependen de las ampliaciones,

conocidas como Mods, que se tienen instaladas. Para una instalación limpia como la que

usaremos en la LPP los requisitos serían los siguientes:

7.1.5.1 Requisitos mínimos

Procesador: Intel P4/NetBurst o su equivalente en AMD (AMD K7)

Memoria: 2GB de RAM

Tarjeta gráfica: Intel GMA 950 o su equivalente en AMD

Disco duro: Por lo menos 90 MB para los archivos de sonido y el juego

Otros: Se requiere Java Runtime Environment (JRE) 6 o superior para poder

ejecutar el juego.

7.1.5.2 Requisitos recomendados

Procesador: Intel Pentium D o AMD Athlon 64 (K8) 2.6 GHz

Memoria: 4GB RAM

Tarjeta Gráfica: GeForce 6xxx o ATI Radeon 9xxx con soporte para OpenGL

2 (Excluyendo los chipsets integrados)

Disco duro: 150MB de espacio libre

Dispositivos/software necesario 7.1.6

Simplemente un ordenador y el juego instalado. El juego cuesta 20€ pero mucha

gente lo tiene sin licencia ya que al menos Mojan no perseguía demasiado la piratería.

De hecho, el servidor es gratuito, se descarga desde la página oficial y uno de los

parámetros es si se aceptan versiones sin licencia o no. (Muestra de la permisividad de

Mojan respecto a este tema)

Licencias/Modo de operación 7.1.7

Como se ha comentado anteriormente, se puede usar tanto con o sin licencia, ya que

así lo permite el servidor.

El modo de operación, se hará en local (más limitado ya que se deben crear los

mapas) donde el problema no es tanto la velocidad de la conexión, sino, la potencia

requerida por el servidor. Esto se va a solucionar limitando el número de usuarios que

juegan concurrentemente a 4.

Técnicas de virtualización empleadas 7.1.8

Minecraft es un juego que exige muchos recursos a nivel hardware, sobre todo en lo

que a memoria RAM se refiere, por lo que no es recomendable virtualizarlo.

77


Plan de contingencia en caso de fallo 7.1.9

El servidor como tal de Minecraft ocupa muy poco y no requiere de ninguna

configuración previa.

Por tanto, el mejor plan de contingencia sería tener el servidor en un pendrive y

ejecutarlo desde allí. Si el ordenador cae, sólo se tendría que poner el pendrive en otro

ordenador, y volver a levantarlo. Esto no llevaría más de 2 minutos hacerlo.

Instrucciones para arrancar Minecraft en el servidor local 7.1.10

1. Se inicia el servidor “minecraft_server.1.8.8.jar”.

2. Se inicia el juego “Minecraft.exe”

a. Play (Hay que asegurarse de ejecutar la versión del servidor en Edit

Profiles)

b. Multijugador (Se pasa al punto c. si ya tenemos el servidor agregado)

i. Añadir servidor

1. Nombre: el que se quiera.

2. Dominio: La dirección ip donde se encuentre el servidor o

el dominio, en la prueba “localhost”.

ii. Hecho

c. Entrar al servidor

Servidor y propiedades 7.1.11

Junto con el servidor hay un fichero de configuración donde se pueden ajustar

multitud de parámetros.

Para ver la estructura básica de un fichero de configuración consultar anexos:

Caracterización del tráfico LAN/WAN generado 7.1.12

Minecraft usa TCP y consume de media unos 4Mbps con picos de hasta 10/12Mbps

por jugador. En el peor de los casos con 4 jugadores se necesitan unos 40Mbps.

Gráfica de Wireshark con comprobación empírica de los resultados:

Fig. 7.4. Capturas de tráfico de Minecraft.

78


Sigue una arquitectura cliente servidor, y el servidor está en local, los enlaces son de

100 Mbps, en el peor de los casos, el enlace que llegue al servidor tendría que soportar

40 Mbps, como los enlaces que tenemos son de 100 Mbps, en ningún momento se

deberían sufrir cortes de ningún tipo.

Implementación de QoS 7.1.13

Observando el tráfico generado por los usuarios y la capacidad de los enlaces

creemos que no es necesario una QoS diferencial para Minecraft ya que podríamos tener

hasta el doble de personas. Por otro lado, darle una QoS diferencial a Minecraft podría

hacer que otras aplicaciones no fuesen bien.

7.2 Hearthstone

Información detallada del juego 7.2.1

Hearthstone: Heroes of Warcraft es un juego de cartas coleccionables en línea creado

por la empresa Blizzard Entertainment. Hearthstone es un juego de descarga gratis,

centrado en el universo de Warcraft, con compras opcionales para acelerar el ritmo de

colección de cartas y aceso a contenidos extra. El juego actualmente está disponible

para Windows, OS X y dispositivos móviles iOS y Android.

Desarrollo del juego 7.2.2

Hearthstone es un juego de cartas coleccionables en línea que se basa en partidas por

turnos entre dos oponentes, operado a través del Battle.net de Blizzard.4 Los jugadores

pueden escoger entre diferentes modos de juego que ofrecen diferentes experiencias.

El juego presenta nueve héroes, cada uno de ellos representando una clase distinta

dentro del universo de Warcraft. Cada héroe presenta habilidades o los denominados

poderes de héroe.

Las partidas de Hearthstone son una batalla uno contra uno entre dos oponentes

basada en turnos. En cada turno el jugador puede utilizar cartas de su mano, hechizos,

equipar armas o invocando "esbirros". La partida puede ser entre dos personas o entre

una persona y un oponente controlado por ordenador.

El modo de juego que se jugará en el torneo será el modo “Jugar”. Consiste en

combatir con jugadores reales usando el mazo de cartas previamente personalizado o

con el mazo predeterminado de cada héroe. En este modo se puede disputar de dos

formas: normal y por rango, en este segundo existen una enorme cantidad de rangos

para alcanzar, pero para eso se deben ir obteniendo estrellas, las cuales solo se pueden

obtener por medio de ganar partidas, perder partidas puede quitar estrellas dependiendo

del rango en que uno se encuentre (sólo en Rango madera 25-21 no se pierden estrellas),

se obtienen estrellas más rápidamente al obtener más victorias consecutivas, por otro

lado la dificultad de los oponentes se incrementa junto al rango, por lo que mayor rango

significa más dificultad para subir.

79


A continuación, podemos ver una captura del juego.

Fig. 7.5. Captura del juego Hearthstone.

Dispositivos/software necesario 7.2.3

El juego es completamente gratuito. Los jugadores pueden bajárselo de la misma

página del juego. Cada jugador debe llevarlo instalado en su PC. Es necesario disponer

de Internet para poder mantener una partida online. No se pueden mantener partidas de

área local. Dado que no existe ningún servidor en nuestra red local, no es necesaria

ninguna herramienta de virtualización.

Licencias para llevar a cabo el torneo 7.2.4

En la página http://wcs.battle.net/sc2/en/about/community-tournaments vemos las

licencias necesarias. Un resumen de los requisitos para poder hacer un torneo es:

- Se pueden organizar torneos siempre que los premios sean inferiores a 10.000 $.

- Se puede emitir la partida online, pero no podemos cobrar por verla.

- Sí que se puede cobrar por ingresar al torneo a jugar, excepto a residentes de

Dakota del Norte, Connecticut, Maryland o Arizona, a los que no se les puede

permitir la entrada.

- No se pueden hacer apuestas por jugadores.

- Se debe informar de que no es un torneo no oficial de Blizzard.

80


Tráfico generado 7.2.5

Hearthstone usa TCP. Cuando el juego se inicia, ha de establecer comunicación con

sus servidores, alcanzando un pico de unos 5 Mbps. Sin embargo, este solo sucede al

inicio del juego; tras esto, el tráfico medio generado es de menos de 500 kbps, el cual es

una valor bastante reducido. No posee voz sobre IP, pero sí mensajes de texto, que irán

encapsulados en los mismos paquetes del juego, por lo que no es necesaria QoS.

Mostramos la gráfica de Wireshark con los resultados obtenidos.

Fig. 7.6. Tráfico generado en Hearthstone

En la imagen, vemos los dos primeros minutos de una partida. En torno al segundo

40, se establece la comunicación con el servidor, dando lugar al pico ya mencionado.

Sin embargo, como puede verse, el tráfico del resto de la partida es muy reducido.

7.3 Implementación de la QoS

La LPP dispone de un enlace a Internet de 100 Mbps. A pesar de que con el ancho de

banda del que los videojuegos no llegarían a consumir todo este ancho de banda, la

descarga de ficheros por parte de los usuarios sí que podría consumirlos rápidamente.

Por ello, si se suman el conjunto de los flujos de las diferentes aplicaciones como las

cámaras IP, el servidor de Owncloud y los juegos, la red podría llegar a saturarse.

Por ello, resulta necesario implementar calidad de servicio (QoS), de tal forma que

los usuarios tengan limitada la capacidad para las distintas aplicaciones, de modo que si

algún usuario intenta descargar cualquier fichero de gran tamaño (Torrent, descarga

directa, etc) durante un tiempo prolongado, no provoque una ralentización en el tráfico

de los demás usuarios.

Para ello se crearán distintas listas de acceso en los switches de acceso para cada

usuario y para cada flujo de tráfico. Dependiendo de las necesidades que tenga cada

juego, se le proporcionará a cada usuario más o menos bit-rate.

De esta forma un usuario tendrá una velocidad máxima para la navegación web y

para jugar. De este modo, se asegura la integridad de la red en caso de que algún usuario

intente hacer un uso excesivo de ella. Además, los demás usuarios no notarán que otro

jugador consume más o menos ancho de banda, ya que se crea una lista de acceso para

cada puesto, con lo cual solamente se le limitaría la velocidad a dicho jugador.

Existen distintos tipos de usuarios en nuestra LPP, dependiendo de a qué juego

decidan jugar. En estos tipos de usuarios basaremos las listas de acceso necesarias y las

restricciones que crearemos. Así, los distintos tipos de usuario son: jugador de LoL,

jugador de Counter Strike, jugador de Team Fortress, jugador de Hearthstone y jugador

81


de Minecraft. Como puede verse, no se están teniendo en cuenta los jugadores de FIFA

ni Street Fighter, pues esos jugadores no tendrán ningún acceso a Internet más que el

del mismo juego, pues jugarán en la Play Station. Tampoco se está teniendo en cuenta el

tráfico generado por las cámaras IP, pero será suficientemente reducido para que no

haya problema de sobrecarga en la red; además, su tráfico será constante.

En total, hay 42 puestos que podrán tener acceso a Internet (incluyendo los puestos

de reserva). En general, todos los tipos de usuarios que necesitan acceso a Internet,

juegan a juegos que consumen poco ancho de banda, del orden de Kbps, exceptuando el

Minecraft, que necesita unos 8 Mbps. Por este motivo, se creará una lista de acceso

especial para los jugadores que jueguen a este juego. Sin embargo, el tráfico de

Minecraft es interno, de manera que podrá ser diferenciado fácilmente del tráfico que

salga a Internet.

Dado que se dispone de unos 100 Mbps de acceso a Internet, se asignará a cada

usuario 1 Mbps de tasa media y una tasa máxima de 2 Mbps. De este modo, si todos

consumieran el máximo permitido, se tendría un consumo de ancho de banda de 84

Mbps, de tal manera que no se estaría alcanzando el límite máximo, puesto que no

deseamos saturar la red.

En resumen, se limitará el tráfico de Internet a todos los usuarios a 1 Mbps de media

y 2 Mbps de tasa máxima, incluído el Minecraft. Adicionalmente, a un jugador de

Minecraft le será restringido el tráfico del juego a 8 Mbps de tasa media y 12 Mbps de

pico. Este jugador también contará con 1 Mbps de media y 2 Mbps como máximo de

acceso a Internet, a parte de la restricción del tráfico que genera el juego.

Una opción para poder implementar lo comentado anteriormente, es limitar el tráfico

por VLANs. Así, si deseamos que cada usuario de un juego tenga 1 Mbps y existen 6

usuarios en esa VLAN, habría 6 Mbps disponibles para esa VLAN. Sin embargo, esta

opción no es la ideal, pues si un usuario decidiera hacer uso de esos 6 Mbps, podría

hacerlo, de manera que está limitando el tráfico del resto de usuarios pertenecientes a

esa VLAN.

Por este motivo, se ha decidido limitar el tráfico directamente a las interfaces de los

switches de acceso. Dado que cada interfaz de estos switches está asignada a un usuario,

estaremos limitando el tráfico por usuario. En el anexo que se presenta al final del

documento, se encuentran todos los comandos necesarios para poder implementar todos

los parámetros de calidad de servicio.

82


Monitorización y gestión de red 8

Monitorizar los sistemas de información es algo fundamental, ya que con este tipo de

aplicaciones no se tiene que estar constantemente verificando que los sistemas marchan

o que no se han caído y, simplemente, actuar cuando el sistema detecte alguna alarma

que indique que algo ha dejado de funcionar.

8.1 Protocolos

SNMP 8.1.1

8.1.1.1 Descripción

El Protocolo Simple de Administración de Red o SNMP (del inglés Simple Network

Management Protocol) es un protocolo de la capa de aplicación que facilita el

intercambio de información de administración entre dispositivos de red. Los

dispositivos que normalmente soportan SNMP incluyen routers, switches, servidores,

estaciones de trabajo, impresoras, bastidores de módem y muchos más. Permite a los

administradores supervisar el funcionamiento de la red, buscar y resolver sus

problemas, y planear su crecimiento.

SNMP es un componente de la suite de protocolo de Internet como se define por el

IETF. Se compone de un conjunto de normas para la gestión de la red, incluyendo una

capa de aplicación del protocolo, una base de datos de esquema (MIB), y un conjunto de

objetos de datos

8.1.1.2 Implementación

Para configurar el protocolo SNMP en los dispositivos conmutadores y enrutadores

se utilizará la interfaz de comandos en línea (Command-Line Inteface o CLI) del

sistema operativo de Cisco: el IOS (Internetworking Operating System). Para ello, se

accederá vía telnet a los dispositivos.

Los switches que se utilizarán en la LPP implementan el protocolo SNMP en sus

versiones 1 y 2. Es el protocolo de gestión de red estándar. El problema de este

protocolo es que en estas versiones no está cifrado, por lo que como se quiere separar

del resto del tráfico (Juegos, usuarios de acceso,…) se creará una VLAN únicamente de

gestión

Se configurará este protocolo en los switchs de modo que puedan enviar traps. Las

traps son notificaciones asíncronas emitidas desde los dispositivos gestionados

(Switches) hacia la estación gestora ante eventos para los que han sido configurados.

Algunos ejemplos de posibles eventos son: intentos fallidos de autenticación para una

comunidad o caídas inesperadas de alguna de las interfaces del dispositivo gestionado.

También se configurará The Dude en el equipo de gestión para que reciba e

interprete los datos que le lleguen de los dispositivos que ejecutan SNMP.

83


Port Mirroring 8.1.2


El puerto espejo o port mirroring es utilizado con un switch de red para enviar copias

de paquetes de red vistos en un puerto del switch (o una VLAN entera) a una conexión

de red monitoreada en otro puerto del switch. Esto es comúnmente utilizado para

aplicaciones de red que requieren monitorear el tráfico de la red, tal como una intrusión-

detección al sistema.


Se usarán al menos dos enlaces del Multilayer para poder copiar todo el tráfico que

pase por él, para posteriormente poder sacar estadísticas de la LPP y como ha

funcionado todo.

8.2 Aplicaciones

The Dude 8.2.1


The Dude es un sistema de monitorización de redes ampliamente utilizado, gratuito,

que vigila los equipos (hardware) y servicios (software) que se especifiquen, alertando

cuando el comportamiento de los mismos no sea el deseado. Entre sus características

principales figuran la monitorización de servicios de red, la monitorización de los

recursos de sistemas hardware (carga del procesador, uso de los discos, memoria, estado

de los puertos...), independencia de sistemas operativos…

Se trata de un software que proporciona una gran versatilidad para consultar

prácticamente cualquier parámetro de interés de un sistema, y genera alertas, que

pueden ser recibidas por los responsables correspondientes mediante (entre otros

medios) correo electrónico, cuando estos parámetros exceden de los márgenes definidos

por el administrador de red.


En el equipo de gestión se instalará The Dude cuando toda la red esté creada, se

descubrirá de manera automática.

Antes de esto, el protocolo SNMP debería está funcionando en todos los routers, ya

que si no, The Dude reconocerá los equipos pero no dará información sobre ellos.

Se crearán enlaces simulando la topología de la red, se asignarán las velocidades que

tenemos en los enlaces de tal manera que si estos llegan al límite de su capacidad avise

de que hay congestión.

8.3 Medición cuellos de botella en segmentos/enlaces de acceso y troncales

Los cuellos de botella se intentarán suplir asegurándose mediante la simulación, la

medición del tráfico generado por los juegos y las aplicaciones y con las técnicas de

optimización de la red que se han llevado a cabo, como la creación de VLAN‟s que

limitan el tráfico de broadcast, no pueda existir ningún cuello de botella, o sean lo

mínimos posibles.

84


Esto tampoco se puede predecir al 100% ya que la simulación no es real, los juegos

pueden tener más o menos tráfico dependiendo de ciertos parámetros, actualizaciones

que hagan que no se corresponda el tráfico generado en la LPP con el medido…

Para evitar este problema, los enlaces se sobredimensionaran, de modo que si el

tráfico generado, respecto al esperado, es mayor, tampoco haya ningún cuello de

botella.

Todos estos datos, serán medidos mediante The dude y se guardarán para su futuro

análisis.

8.4 Medición de parámetros típicos de QoS: pérdidas de paquetes,

latencias y jitters.

Para medir la pérdida de paquetes, las latencias y el jitters se hará con un ping

continuo desde un equipo de gestión a uno de los switch‟s de modo que si durante la

LPP se observan pérdidas de paquetes, o un retardo mayor de un milisegundo se

detectaría que hay un problema y con las otras herramientas de gestión, como con The

Dude, se intentaría solucionar.

8.5 Monitorización y seguimiento de estaciones conflictivas.

Para la monitorización y seguimiento de estaciones conflictivas se usará una vez más

The Dude, de modo que si se ve que una estación genera más tráfico del esperado se

podría ir a revisar si todo está bien, si se está produciendo un ataque o si un equipo se ha

roto o desconfigurado.

En este último caso se tendrán equipos preparados, previamente configurados, para

que en el caso de que un equipo se rompa, se pueda cambiar por otro inmediatamente

minimizando así el tiempo que se ha dejado de dar servicio.

85


Consumo eléctrico 9

En esta parte se va a analizar el consumo de potencia eléctrica que se va a producir

durante el evento.

En primer lugar, se van a contabilizar los equipos electrónicos que se van a usar tanto

en las dos Zonas Secundarias como en la Zona Principal.

En ambas zonas secundarias se van a utilizar los mismos equipos electrónicos: 22

equipos de usuario para jugar (21 ordenadores portátiles y una PS3), tres switches

Catalyst 2950-12, dos cámaras IP, y para suministrar luz a cada laboratorio se usan 4

bombillas de bajo consumo y 8 tubos LEDs fluorescentes de bajo consumo.

En la zona principal se van a situar tres servidores de juegos y un servidor de carga y

descarga de ficheros, dos equipos de monitorización y dos equipos de gestión. Todos

ellos van a ser ordenadores portátiles. Además, se va a situar un switch multilayer

Catalyst WS-C3550-24-SMI y dos switches Catalyst 2950-12. También, se van a usar 4

bombillas y 8 tubos fluorescentes LEDs de bajo consumo para suministrar luz al

laboratorio.

A continuación, se va a analizar la potencia que consume cada uno de los equipos

electrónicos que se van a usar para implementar la LAN Party. Además, se va analizar

en detalle el consumo de un ordenador de sobremesa que suelen utilizar los jugadores de

este tipo de eventos (gamers) para poder compararlo con el consumo de un ordenador

portátil, y así poder explicar por qué se ha decidido que los usuarios deban jugar con un

ordenador portátil en lugar de utilizar un ordenador de sobremesa con una tarjeta gráfica

de alto rendimiento.

Los ordenadores de sobremesa consumen hasta diez veces más que un ordenador

portátil en promedio, y la LAN Party que se propone se debe caracterizar por ser de

carácter ecológico.

El consumo de un ordenador de sobremesa es muy variable, ya que depende de los

componentes del equipo. El consumo de cada componente de un ordenador de

sobremesa típico de jugadores de LAN Partys es aproximadamente:

Microprocesador: un procesador Intel Core i7 con 8 MB de memoria caché y

una velocidad de reloj de 4 GHz consume una potencia de 65 vatios por hora.

Disco duro: disco duro 1 TB Seagate SATA3 7200 64 MB Barracuda

consume una potencia igual a 6.2 vatios por hora.

Memoria RAM: una memoria RAM DDR3 2x2GB Kingston HyperX Blu

consume una potencia igual a 3.6 vatios por hora.

Tarjeta gráfica: las tarjetas gráficas de los jugadores con ordenador de

sobremesa suelen ser muy potentes, ya que los juegos exigen un gran

rendimiento en cuanto a memoria gráfica. Una tarjeta gráfica típica de los

jugadores es una Radeon R9 390, tal y como es la MSI R9 390 G1 Gaming de

86


8 GB GDDR5 con una potencia de consumo de 275 vatios por hora de

funcionamiento. En la actualidad, esta es la potencia de consumo más típica

de las tarjetas gráficas de mayor rendimiento.

Placa base: una placa basa MSI 970 Gaming consume una potencia igual a 90

vatios por hora.

Fuente de alimentación: proporciona potencia al equipo pero a la vez también

consume energía. Su consumo ronda los 10 vatios por hora.

Monitor: un monitor LG LED IPS de 22 pulgadas con resolución 1920x1080

consume una potencia igual a 24 vatios por hora.

Sumando el consumo de todos estos componentes de un ordenador de sobremesa que

suelen ser utilizados por los jugadores, se obtiene una potencia igual a 473.9 vatios por

cada hora de encendido.

Sin embargo, un ordenador portátil consume como máximo 120 vatios por cada hora

de carga de la batería.

Un requisito de diseño es que cada usuario de la LPP no puede consumir más de 250

vatios por cada hora. Por tanto, los usuarios deben utilizar ordenadores portátiles debido

a que la potencia consumida por un ordenador de sobremesa está muy por encima de la

potencia máxima que puede consumir cada usuario en el evento.

Por otro lado, se van a utilizar ocho switches Catalyst 2950-12 que consume cada

uno una potencia máxima igual a 675 vatios por hora. También, estos switches pueden

consumir 375 y 300 vatios cuando la carga de trabajo es más reducida. Sin embargo,

todos ellos van a estar funcionando a pleno rendimiento debido a que tienen la mayoría

de sus puertos ocupados, y por tanto, se debe considerar que el consumo de potencia de

cada uno es 675 W/hora.

Además, también se va a usar un switch multilayer Catalyst WS-C3550-24-SMI que

consume una potencia igual a 525 vatios por hora.

En cuanto a las cámaras IP, se propone utilizar cinco unidades para vigilar el evento.

Según el diseño lógico y físico, se propone situar dos cámaras IP en cada una de las dos

Zonas Secundarias y una cámara IP en la Zona Principal.

Por último, se van a usar un total de 4 bombillas de bajo consumo, las cuales

consumen alrededor de 18 vatios por hora, y 8 tubos fluorescentes LEDs de bajo

consumo, los cuales necesitan consumir 24 vatios por hora.

En la tabla 9.1 se recoge el consumo máximo de potencia eléctrica que se va a

realizar en cada uno de los laboratorios por cada hora de duración del evento. Cabe

destacar que se ha considerado que todos los ordenadores portátiles van a estar

conectados a su fuente de alimentación durante todo el evento, y que el consumo de

potencia de cada portátil es el máximo (120 vatios por hora).

87


Como se puede observar en dicha tabla, se obtiene que cada Zona Secundaria va a

consumir una potencia total de 5.0049 kW/h, y que la Zona Principal consume 2.904

kW/h. En total, la máxima potencia que se va a poder consumir durante el evento es

igual a 12.914 kW/h.

Laboratorio Equipo

Máx.

Consumo

Potencia

(W/h)

Unidades Consumo

Total (W/h)

Laboratorio 3.5

(Zona Secundaria

1)

Ordenador portátil 120 21 2520

PS3 185.9 1 185.9

Cámara IP 5 2 10

Switch Catalyst 2950-12 675 3 2025

Bombilla de bajo consumo 18 4 72

Tubo fluorescente LED de

bajo consumo 24 8 192

Suma 5004.9

Laboratorio 3.3

(Zona Secundaria

2)

Ordenador portátil 120 21 2640

PS3 185.9 1 185.9

Cámara IP 5 2 10





Suma 5004.9

Laboratorio 3.4

(Zona Principal)

Servidor

(Ordenador portátil) 120 4 480

Equipo de monitorización


Equipo de gestión


Cámara IP 5 1 5

Switch multilayer WS-

C3550-24-SMI 525 1 525





Suma 2904 W

Total (ZP + 2 ZS) 12.914 kW/h

Tabla 9.1. Consumo de potencia eléctrica de cada equipo electrónico y de cada laboratorio.

88


Planificación 10

En este apartado, se discute sobre la lista de tareas necesarias para poder

implementar la LPP. Además, también se incluye la cantidad de personas que serían

necesarias para realizar cada tarea.

Cada una de las tareas queda descrita mediante una ficha que ha de rellenar el

encargado de la tarea, con el nombre de los responsables que la han llevado a cabo.

Además, cada ficha incluye el protocolo de validación, que ha de firmar el encargado

responsable una vez terminada la tarea. Cada ficha queda descrita según el código de la

tarea, el título de la misma, una breve descripción, el tiempo máximo de realización y

las personas que la realizan (rellenado por el encargado).

Este apartado también incluye un diagrama de Gantt, que indica el momento de

inicio y fin de cada tarea, junto con su código. Los colores utilizados sirven para

diferenciar los distintos bloques de tareas. Además, una línea vertical verde indica la

tarea o tareas que han de completarse para poder iniciar la siguiente. Cada cuadrito

sombreado indica un tiempo de media hora. De este modo, una tarea con cuatro

cuadritos sombreadas indica que esa tarea podrá durar un tiempo máximo de dos horas.

Cabe mencionar que algunas tareas se dividen en subtareas, que también quedan

descritas en las fichas. Además, hay algunas tareas que pueden llevarse a cabo en

paralelo, con la consecuente reducción de tiempo que conllevará.

El diagrama de Gantt se encuentra al final de este apartado y las fichas de las tareas

están en el Anexo.

10.1 Tareas

En este apartado, se comenta de forma ampliada cada una de las tareas.

En primer lugar, la primera tarea de todas (tarea A) será analizar el estado actual del

laboratorio 3.4. Es necesario realizar un plano de la red del laboratorio y un inventario

de cables y etiquetas, para poder dejar el laboratorio al final de la LPP tal y como lo

encontramos (subtarea A1). Es importante que el plano sea lo suficientemente

meticuloso como para que el equipo encargado de volver a montarlo lo entienda

perfectamente. El encargado será responsable de validar los planos de cada isla.

Posteriormente, se procede a desmontar el laboratorio (subtarea A2). Se han de

desmontar solamente los equipos necesarios y han de almacenarse adecuadamente

según las etiquetas y según la isla. El encargado tendrá que validar que los cables se han

almacenado correctamente y tendrá que comprobar que se han desconectado todos los

equipos necesarios. Para esta tarea se requieren cuatro personas que realicen los planos,

el inventario, el almacenaje de los cables y que desmonten los equipos, además del

encargado.

La segunda tarea consistirá en montar los equipos, y solamente los equipos pues los

cables se estarán preparando mientras se realizan estas tareas, desmontados del

laboratorio 3.4 en los laboratorios 3.3 y 3.5, además de tener que montarlos también en

el laboratorio 3.4, según las indicaciones ofrecidas por los planos de este proyecto. Esta

89


tarea (tarea B) se divide en tres subtareas (B1, B2 y B3), correspondientes al montaje de

los laboratorios 3.3, 3.5 y 3.4. Los tres laboratorios se pueden montar en paralelo. Se

requieren dos personas y un encargado para cada subtarea y estos equipos (de 3

personas) han de ser distintos, pues los montajes se realizan en paralelo. La duración

total de esta tarea ha de ser como máximo de una hora.

La tercera tarea consistirá en preparar los cables (tarea C). Esta tarea se divide en

otras tres subtareas: cortar los cables según las medidas proporcionadas en este proyecto

(subtarea C1), añadirles los conectores RJ45 necesarios (subtarea C2) y etiquetar los

cables según las tablas (subtarea C3). Se requiere que el mismo encargado vaya

comprobando que las medidas de los cables son las correctas, que los conectores se

colocan adecuadamente y que los cables se etiquetan según las tablas. Además del

encargado, se requieren cuatro personas para realizar las tres subtareas. Estas tres

subtareas tendrán una duración de cinco horas como máximo y el comienzo de una

subtarea depende de la finalización de la anterior.

La cuarta tarea consiste en la interconexión de cables y equipos de los tres

laboratorios (tarea D). Se divide en tres subtareas (D1, D2 y D3), correspondientes a las

interconexiones de los laboratorios 3.3, 3.4 y 3.5. Sin embargo, tan solo se pueden

llevar a cabo en paralelo las conexiones de los laboratorios 3.3 y 3.5, pues el laboratorio

3.4 no se podrá conectar hasta que no hayan sido validados los montajes de los otros dos

laboratorios, con el fin de evitar errores. Dado que se montarán en paralelo, se necesitan

3 equipos de dos personas más un encargado. Estos tres encargados deberán ir

validando las conexiones de acuerdo a las tablas. Esta tarea global tendrá una duración

máxima de tres horas y solo podrá dar comienzo una vez acabas las tareas B y C.

La quinta tarea será el montaje lógico de toda la red (tarea E). Se ha de establecer la

red desde los equipos de gestión del laboratorio 3.4, introduciendo los comandos que se

encuentran en el anexo. El equipo encargado de esta tarea estará formado por cuatro

personas y un encargado, que deberá validar mediante otro equipo de gestión que el

montaje se está realizando de acuerdo al proyecto. La duración máxima de esta tarea

será de 4 horas y solamente podrá comenzar una vez terminada la interconexión de los

equipos (tarea D).

La sexta tarea consiste en llevar a cabo una batería de pruebas (tarea F). En esta

tarea, se han de realizar todas las pruebas necesarias para que la LPP funcione, es decir,

se han de comprobar las VLANs, probar los videojuegos, la seguridad, etc. Esta tarea se

realizará mediante un equipo de cuatro personas y un encargado, que deberá ir

constatando que las pruebas realizadas son correctas. En el apartado “Notas”, el

encargado deberá anotar las pruebas realizadas. Esta tarea tendrá una duración máxima

de 3 horas y será la última tarea que se llevará a cabo antes de que la LPP dé comienzo.

La séptima tarea, la primera tras la finalización de la LPP, será la desconexión de los

cables, su agrupación por medidas y su almacenaje (tarea G). Esta tarea se divide en tres

subtareas (G1, G2 y G3), correspondientes a cada laboratorio. Se requerirán tres equipos

de dos personas y un encargado (un equipo por laboratorio), cuya función será validar

que los cables se han almacenado adecuadamente. Esta tarea tendrá una duración

máxima de una hora y media.

90


La octava y última tarea consistirá en montar de nuevo el laboratorio 3.4 (tarea H). El

laboratorio ha de quedar tal y como lo encontramos antes de comenzar la LPP, con el

fin de que no haya problemas a la hora de que los profesores del siguiente cuatrimestre

(y posteriores) impartan sus clases en este laboratorio. Para ello, se han de seguir los

planos realizados en la tarea A1. El encargado ha de certificar que el laboratorio se ha

establecido según los planos por un equipo de otras cuatro personas. La duración

máxima de esta tarea será de tres horas.

10.2 Diagrama de Gantt

En la siguiente página, se presenta el diagrama de Gantt. Analizándolo, podemos ver

que la duración total de las tareas, sin contar la duración del evento, es de 18 horas

como máximo (15 horas en los días anteriores al evento y 3 horas tras la finalización del

evento). De este modo, si las tareas se fueran acabando rápidamente, sería posible

realizar todo el despliegue anterior al evento el miércoles día 10 de febrero, pudiendo

durar la LPP dos días (11 y 12 de febrero). En caso contrario, sería necesario tomar los

días 10 y 11 de febrero para desplegar todo lo necesario para la LPP, de modo que la

LPP solo tendría lugar el día 12 de febrero. En cualquier caso, son necesarias al menos

tres horas para poder recoger todo y montar de nuevo el laboratorio 3.4 tras la

finalización de la LPP.

91


Diagrama de Gantt

Cada casilla sombreada representa media hora

A. Análisis 3.4

A1. Plano 3.4

A2. Desmontaje 3.4

B. Montaje equipos

B1. Montaje 3.3

B2. Montaje 3.5

B3. Montaje 3.4

C. Cables

C1. Cortar cables

C2. Añadir conectores

C3. Etiquetar cables

D. Interconexión

D1. Conexión 3.3

D2. Conexión 3.5

D3. Conexión 3.4

E. Montaje lógico

F. Batería de pruebas

Evento

G. Desconexión

G1. Desconexión 3.3



H. Montaje 3.4

92


10.3 Tablas de validación de tareas

Tarea: A. Análisis del laboratorio 3.4 Duración: 2.5 horas

Subtarea: A1. Plano del laboratorio 3.4

Descripción: Hacer un plano de la red del laboratorio 3.4, además de un

inventario de cables junto con sus etiquetas, con el fin de dejarlo tal

y como nos lo encontramos, tras la finalización del evento. El plano

debe ser lo suficientemente claro como para que el equipo encargado

de volver a montarlo lo entienda perfectamente

Responsables: 4 personas y un encargado

Validación: El encargado validará los planos de cada isla

Firma del encargado:

Notas:

Subtarea: A2. Desmontaje del laboratorio 3.4

Descripción: Se han de desmontar únicamente los equipos necesarios y se han de

almacenar adecuadamente los cables según el etiquetado, según la

isla

Responsables: Mismos responsables de la subtarea A1

Validación: El encargado validará que los cables se han almacenado

adecuadamente y tendrá que comprobar que se han desconectado

todos los equipos necesarios


Notas:

93


Tarea: B. Montaje de los equipos según planos Duración: 1 hora

Descripción: Se han de montar los equipos de la LPP según los planos. Las tareas

B1, B2 y B3 se pueden llevar a cabo a la par.

Subtarea: B1. Montaje del laboratorio 3.3


Validación: El encargado validará el montaje según los planos


Notas:





Notas:





Notas:

94


Tarea: C. Preparación de los cables Duración: 5 horas

Descripción: En esta tarea, se han de cortar los cables, añadir los conectores y

etiquetar los cables. Se requerirán 4 personas y un encargado. Los

mismos responsables se mantendrán para las tres tareas.

Subtarea: C1. Cortar cables


Validación: El encargado irá validando que las medidas se van haciendo

adecuadamente


Notas:

Subtarea: C2. Añadir conectores

Responsables: Mismos responsables de la subtarea C1

Validación: El encargado irá comprobando que todas los conectores se han

colocado adecuadamente


Notas:

Subtarea: C3. Etiquetado de los cables

Responsables: Mismos responsables de la subtarea C1 y C2

Validación: El encargado irá comprobando que las etiquetas son las correctas y

que no falta ninguna etiqueta en ningún cable


Notas:

95


Tarea: D. Interconexión de cables y equipos Duración: 3 horas

Descripción: Una vez completadas las tareas B y C, se puede proceder a

interconectar los equipos montados en la tarea B mediante los cables

terminados de la tarea C. Los laboratorios 3.3 y 3.5 se pueden

montar en paralelo, pero el laboratorio 3.4 no se podrá montar hasta

que los otros dos no estén validados

Subtarea: D1. Conexión del laboratorio 3.3


Validación: El encargado irá validando de acuerdo a las tablas de conexiones que

los montajes se han realizado correctamente


Notas:






Notas:






Notas:

96


Tarea: E. Montaje lógico de toda la red Duración: 4 horas

Descripción: En esta tarea, se ha de establecer toda la red, desde el laboratorio

3.4, mediante los equipos de gestión. Los comandos del Anexo se

han de introducir en los distintos equipos en esta tarea


Validación: El encargado validará mediante otro equipo de gestión que el montaje

se está realizando de acuerdo al proyecto


Notas:

97


Tarea: F. Batería de pruebas Duración: 3 horas

Descripción: En esta tarea, se han de realizar todas las pruebas necesarias para

que la LPP funcione, es decir, se han de comprobar las VLANs,

probar los videojuegos que habrá, la seguridad, las WebCams, la

monitorización, etc.


Validación: El encargado deberá ir constatando que las pruebas realizadas por los

4 responsables son correctas


Notas: Se deben anotar las pruebas que se han llevado a cabo

98


Tarea: G. Desconexión, agrupación y almacenaje Duración: 1.5 horas

Descripción: Se han de desconectar todos los equipos de los cables.

Posteriormente, se han de agrupar los cables por medidas.

Finalmente, se han de almacenar.

Subtarea: G1. Desconexión agrupación y almacenaje del laboratorio 3.3


Validación: El encargado ha de comprobar que los cables se han almacenado

adecuadamente según las medidas


Notas:






Notas:






Notas:

99


Tarea: H. Montaje del laboratorio 3.4 Duración: 3 horas

Descripción: Esta tarea final consiste en montar de nuevo el laboratorio 3.4 y

dejarlo tal y como lo encontramos, según los planos realizados en la

subtarea A1.


Validación: El encargado de certificar que el laboratorio se ha establecido según

los planos


Notas:

100


Verificación y validación de la LPP 11

Para la validación y la verificación de la LPP se va a proceder a simular la red que ha

sido diseñada con un simulador denominado GNS3. Sin embargo, esta herramienta no

está lo suficientemente desarrollada por lo que presenta distintas dificultades que se va a

intentar ir superando.

En primer lugar, se comprueba que en el switch multilayer no se tienen puertos

suficientes para la cantidad de equipos que se desean conectar. Esto es así ya que los

switches de la simulación son en realidad routers c3725 que tienen sólo 18 puertos, y

que se están usando con funcionalidad de switches.

Por lo tanto, de cara a la simulación, se ha decidido que los dos equipos de gestión,

van a estar conectados al switch 7. Como este problema de falta de puertos no se tiene

en el laboratorio, ya que los switches tienen 48 puertos, se podrá conectar los equipos de

gestión directamente al router (switch multilayer en esta simulación) para poder utilizar,

por ejemplo, SNMP.

De este modo, se consigue tener en el switch multilayer puertos suficientes para darle

conexión a internet y para poder conectar el servidor del juego Minecraft que necesita

un ancho de banda muy alto.

Otra de las limitaciones es el nombre de las interfaces de los switches. Es por esto

que la configuración de los switches del programa GNS3 no va a ser exactamente igual

que la configuración que necesitan los equipos que tenemos en los laboratorios. Esta

configuración está adjuntada en el anexo.

En la siguiente imagen se puede visualizar la red completa, que representa a los

equipos de los laboratorios, así como sus conexiones.

101


Fig. 11.1. Diseño de la red.

102


11.1 Conmutación entre VLANs

Para la configuración de la interconexión de VLANs, se debe asignar una dirección

IP a cada una de las VLANs, que coincidirá con la puerta de enlace de los equipos. Por

ejemplo, para la VLAN 10 debemos asignar la dirección IP: 192.168.10.2 (dirección IP

de la puerta de enlace de los equipos pertenecientes a esta VLAN).

Una vez activamos el servicio, cuando un equipo perteneciente a una VLAN X

quiera comunicarse con un equipo perteneciente a la VLAN Y, la petición llegará al

Switch Multilayer, en donde se conmutará de forma adecuada.

En la siguiente imagen se puede ver cómo el equipo el equipo H39, con dirección IP

192.168.30.11 /24 y con puerta de enlace 192.168.30.2 se puede comunicar con otro

equipo perteneciente a otra VLAN, y con dirección IP 192.168.10.11.

Fig. 11.2. Ping entre dos equipos de distinta VLAN.

11.2 Balanceo de Carga mediante STP

El escenario que se presenta a continuación se utiliza para la comprobación del

balanceo de carga realizado mediante el protocolo STP. Por un lado, se tiene el equipo

H39 situado en la VLAN 30 del SW6 del laboratorio 3.3 con la dirección IP

192.168.30.12 (obtenida previamente por DHCP). Desde este equipo, se hace un ping al

host H17 situado en el SW3 del laboratorio 3.5 con dirección IP 192.168.30.11 (misma

VLAN).

Se ha configurado el protocolo STP de forma que se realice balanceo de carga,

mediante la asignación de prioridades en los puertos del Switch Multilayer.

Concretamente, para este caso, de los dos enlaces troncales que parten del SW3 hacia el

SW Multilayer, uno de ellos se dedica a las VLANs 30 y 20 (fastEthernet 1/12) y el otro

para la VLAN 70 (fastEthernet 1/11).

Para comprobar que realmente se está llevando a cabo el balanceo de forma correcta,

se hace un ping continuo entre estos equipos y se desactiva en el SW Multilayer el

enlace por el que pasan los paquetes icmp (fastEthernet 1/12). De esta forma, y como se

puede ver en la siguiente figura, el ping se corta cuando el enlace se cae y se vuelve a

recuperar al cabo de un tiempo. Realmente, el protocolo STP recalcula la ruta para las

VLANs 30 y 20 de forma que todo su tráfico se envíe por el otro enlace troncal

(fastEthernet 1/11).

103


Fig. 11.3. Recuperación del ping entre H39 y H17.

Como se puede comprobar en la configuración del SW Multilayer, para la VLAN 30

se tienen distintas prioridades según la interfaz:

FastEthernet 1/6 y FastEthernet 1/12 Prioridad 64.

FastEthernet 1/5 y FastEthernet 1/11 Prioridad 128

Siempre que fluya el tráfico perteneciente a la VLAN 30 por este switch, se enviará

por las interfaces 6 y 12, ya que son las que presentan una menor prioridad. Si por

cualquier caso cayera por ejemplo la FE 1/6, el tráfico se reencaminará (al cabo de un

tiempo) por la FE 1/5.

104


Fig. 11.4. Prioridades de las interfaces en el SW Multilayer para la VLAN 30.

A continuación, comprobamos también la configuración del SW3. Se puede ver

claramente en la siguiente figura cómo el puerto FE 1/11 está bloqueado para la

VLAN30. Por tanto, todo el tráfico perteneciente a esta VLAN se reencamina por la FE

1/12, como ya se ha comentado.

Fig. 11.5. Puertos designados y bloqueados en el SW 3 para la VLAN 30.

105


11.3 DHCP

El metodo de verificacion del correcto funcionamiento de la asignacion de

direcciones IP a los equipos de los usuarios mediante el uso del protocolo DHCP sera el

uso del comando: show ip dhcp binding.

Usando dicho comando en el switch multilayer nos mostrara una tabla con la

asignación de las direcciones que han sido asignadas a los diferentes equipos según a la

VLAN que corresponde.

En la siguiente figura se puede ver cómo el equipo H29 perteneciente a la VLAN 40

ha obtenido una dirección IP y una máscara a través de DHCP.

Fig. 11.6. Comprobación DHCP.

Utilizando el comando mencionado anteriormente (show ip dhcp binding) se puede

ver las direcciones ip que hasta el momento, el servidor DHCP, en este caso el switch

multilayer ha asignado. En el momento de la captura, el servidor había asignado dos

direcciones IP a la VLAN 30 y una dirección IP a la VLAN 40. Como se sabe, el rango

de direcciones IP para asignar mediante DHCP comienza en la dirección

192.168.VLAN.11. Por regla general, el servidor asignará las direcciones de forma

consecutiva desde la 11 en adelante, como se puede apreciar en la siguiente imagen. Si

otro equipo de la VLAN 30, por ejemplo, pidiera por DHCP una dirección IP, se la

asignaría muy posiblemente la 192.168.30.13/24 (no tendría por qué ser así).

Además, se puede ver la fecha y hora de validez de la dirección IP. Si un equipo

dejara de usar su dirección IP, al llegar a ese tiempo, dicha dirección volvería a quedar

disponible.

Fig. 11.7. Comprobación fecha y hora.

106


Tarea: Protocolos y Servicios de Red. DHCP

Subtarea: Comprobar el correcto funcionamiento del protocolo DHCP

Descripción: Comprobar si la configuración del servicio de DHCP se ha

aplicado de forma correcta en nuestra red


Validación: Para ello, conectarse desde un equipo de gestión al switch

multilayer donde está configurado dicho servicio y mediante el comando: show ip

dhcp binding obtener la tabla de direcciones asignadas por DHCP comprobando

asi la correcta asignación


Notas:

107


11.4 NAT

Para verificar el correcto funcionamiento del protocolo NAT será necesario ver la

correcta conversión de direcciones inside local y global local. Debido a que el switch

multilayer que hemos usado en la simulación no nos permite configurar NAT hemos

llevado a cabo una prueba con otro router de manera que hemos podido comprobar su

correcto funcionamiento. La manera de comprobar que la conversión NAT se ha llevado

a cabo satisfactoriamente es comprobar dicha conversión con el comando show ip nat

translation que nos mostrara una tabla con las diferentes conversiones que se han

realizado como se puede mostrar en la imagen siguiente:

Fig. 11.8. Comprobación NAT.

Tarea: Protocolos y Servicios de Red. NAT

Subtarea: Comprobar el correcto funcionamiento del protocolo NAT

Descripción: Comprobar si la configuración del servicio NAT se ha aplicado

de forma correcta en nuestra red



multilayer donde está configurado dicho servicio y mediante el comando: show ip

nat translation obtener la tabla de traducción de direcciones inside y outside

comprobando su correcto funcionamiento.


Notas:

108


11.5 NTP

El metodo de verificacion del correcto funcionamiento de NTP sera comprobando la

hora y fecha que se configurado en los equipos tras realizar la peticion al servidor NTP

en Internet.

Tarea: Protocolos y Servicios de Red. NTP

Subtarea: Comprobar el correcto funcionamiento del protocolo NTP

Descripción: Comprobar si la configuración del servicio NTP se ha aplicado de

forma correcta en nuestra red



multilayer donde está configurado dicho servicio y mediante el comando: show

clock obtener la hora y fecha que se ha obtenido de realizar la petición NTP,

comprobar que dicha hora y fecha es correcta.


Notas:

11.6 Control de tormentas de broadcast

Para verificar el correcto funcionamiento del control de tormentas de broascast será

necesario medir en nivel de broadcast en todos los enlaces que forman la LPP, tanto los

de acceso como los troncales, para evitar que sobrepasen un límite. Si el límite es

sobrepasado se enviará una trap al sistema gestor avisando del suceso. En el simulador

está prueba es muy difícil de llevar a cabo, ya que sería necesario simular PCs con

máquinas virtuales y que estos generasen muchos flujos de tráfico para elevar el nivel

de broadcast de forma considerable. Por lo que usando los comandos disponibles en el

anexo, se realizarán las pruebas de verificación correspondiente durante el montaje de la

LPP.

109


Tarea: Seguridad. Control tormenta broadcast

Subtarea: Medir nivel de broadcast

Descripción: Medir nivel de broadcast de todos los enlaces, para que no se

supere el límite establecido.


Validación: Para ello, conectarse desde el equipo portátil al switch de la VLAN

que se quiere comprobar y medir el tráfico broadcast.


Notas:

11.7 Listas de acceso

Para comprobar el correcto funcionamiento de las listas de acceso una vez hayan sido

configuradas, he llevarán a cabo varias pruebas de verificación.

Por una parte, se comprobará que las VLANs no tienen conexión entre ellas

mediante el comando “ping”, el cual se usa para comprobar la conectividad entre dos

equipos.

Otra tarea a comprobar será el acceso al servidor de almacenamiento de Owncloud.

Antes se ha comentado que las VLANs no conmutarán entre sí, pero aquí hay una

excepción, todas las VLANs deben poder conmutar con la VLAN 100, donde estará

alojado el servidor Owncloud, para garantizar su correcto funcionamiento.

Por último, se hará una prueba de verificación para comprobar el acceso a internet.

Las listas de acceso deben permitir la conexión a internet, pero no que cualquier usuario

de fuera pueda acceder a la LPP, este problema queda resuelto al hacer NAT, ya que

sólo estarán abiertos los puertos indispensables.

110


Subtarea: Seguridad. Listas de Acceso (Ping)

Descripción: Se ha de comprobar que no existe conectividad entre VLANs en

cualquier momento.

Responsables: 4 responsables y un encargado

Validación: Una vez que las listas de acceso han sido configuradas en el switch

multilayer, se deberá probar la conexión entre VLANs mediante un ping ICMP

entre dos VLANs distintas.


Notas:

Subtarea: Seguridad. Listas de Acceso (Owncloud)

Descripción: Se ha de comprobar que los participantes de la LPP pueden

acceder al servidor de almacenamiento de forma correcta.

Responsables: Mismos encargados que en la tarea anterior.

Validación: El servidor Owncloud puede ser accedido de forma correcta desde

cada una de las VLANs configuradas en la LPP.


Notas:

Subtarea: Seguridad. Listas de Acceso (Ping)

Descripción: Comprobar que cualquiera de los participantes puede acceder a

Internet sin ningún problema.

Responsables: 4 responsables y un encargado

Validación: La página principal de la LPP puede ser accedida de forma

correcta desde cualquier puesto de usuario.


Notas:

111


Gestión y administración 12

12.1 Organización de la LPP

La organización del evento es el sistema principal sobre el que se rige nuestra LAN

Party, diseñada para el correcto funcionamiento del evento, incluyendo todas las

posibles variables a tratar.

Vamos a implementar un organigrama jerárquico con descripción de

responsabilidades y cargos, incluyendo la realización de tareas y el plan de validación.

Nuestro equipo de trabajo está compuesto por: un Mentor, tres Team Leaders, ocho

Encargados y dieciséis alumnos encargados de desarrollar cada tarea.

- Mentor: Miguel Ángel López Gordo.

- Team Leader o Leaders de cada equipo

- Encargados de cada tarea

- Resto de personal (Alumnos restantes)

Cargo ocupado Puestos

Mentor: Miguel Ángel López Gordo.

1

Team Leader 3

Encargados de Tareas y subtareas 14

Resto de personal 11

Fig. 12.1: Tabla de cargos de la LPP

El reparto de trabajo se ha ajustado en función al número de horas total estipuladas

en el Punto 10 del presente documento.

Número total de horas (h) 137.00

Número total de alumnos 28.00

Número de horas por alumno (h) 5.48 h

Fig. 12.2: Tabla de horas de trabajo de la LPP

Para calcular el número de horas de trabajo por alumno, no hemos incluido a los

Team Leaders, los cuales se encargarán en todo momento de la organización y

supervisión de la LPP en general, y en caso necesario de apoyo a cualquier Tarea o

subtarea que lo requiera (por lo tanto, el número total de alumnos será de 25 personas

para las tareas descritas en el punto 10 de este documento). Para ello, la siguiente

ecuación fija el número horas a trabajar por cada alumno de media:

Por lo tanto, hemos repartido las tareas en función del número de horas a trabajar por

cada persona.

112


Alumno Encargado en tareas Trabajador en tareas Horas totales (h)

Alumno 1 A1 y A2 D1 5.50

Alumno 2 D1 A1 y A2 5.50



Alumno 5 - A1, A2 y D1 5.50

Alumno 6 - B1, D2 y G1 5.50

Alumno 7 B1 D2 y G1 5.50



Alumno 10 G1 B1 y F 5.50



Alumno 13 - G3, B3 y F 5.50

Alumno 14 F B3 y G3 5.50

Alumno 15 C1, C2 y C3 - 5.00

Alumno 16 - C1, C2 y C3 5.00

Alumno 17 - C1, C2 y C3 5.00

Alumno 18 - C1, C2 y C3 5.00

Alumno 19 - C1, C2 y C3 5.00

Alumno 20 E - 4.00

Alumno 21 - E y H 7.00




Alumno 25 H - 3.00

Fig. 12.3: Tabla de asignaciones de puestos de la LPP

Hemos intentado que el trabajo sea lo más equitativo posible, pero debido a la

dificultad para que todas las personas trabajaran de media las mismas horas, vemos

como, por ejemplo, el alumno 25 trabaja solo 3.00h en contra del alumno 24, el cuál

llega a trabajar hasta 7 horas.

Los resultados aquí expuestos, son meramente indicativos, por lo que, en la

implementación real de nuestra LPP habrá que considerar además actividades de

supervisión y mantenimiento de la misma, por lo que el alumno 25 y 20 deberán de

sufragar esta falta de horas con este tipo de actividades.

113


Organigrama Jerárquico 12.1.1

Mentor

Team Leader 1

Tarea A

A1 A2

R1

R2

R3 R4

R5

Tarea B

R6 R7

R8

B1 B2 B3

R9 R10

R11

R12

R13 R14

Tarea G

G1 G2 G3

R15

R16 R17

R18 R19

R20

R21

R22 R23

Team Leader 2 Team Leader 3

Tarea C

C1 C2 C3

Tarea D

D1 D2 D3

Tarea E Tarea F

R24 R25

R26

R27

R28

R29 R30

R31

R32

R33

Tarea H

R48

R49 R50

R51

R52

R39

R40

R41

R42 R43

R44

R45

R46

R47

R34

R35

R36 R37

R38

114


Reglamento Interno 12.1.2

La creación del Reglamento Interno, es decir, el conjunto de normas que regulan el

funcionamiento de la organización para la correcta implementación de nuestro evento,

ha sido llevada a cabo por la organización y el Mentor.

A fecha de 28 de diciembre de 2015 la organización de la LAN Party ha resuelto las

siguientes normas para el correcto desarrollo del evento.

CAPÍTULO PRIMERO

DECLARACIONES GENERALES

CLÁUSULA PRIMERA. - Para la interpretación del presente Reglamento, se

entenderá por:

"REGLAMENTO”. - El presente Reglamento Interno

"LEY”. - La Ley Federal del Trabajo vigente.

"CONTRATO”. - El Contrato Individual Académico respectivo.

“MENTOR”. – Miguel Ángel López Gordo

“ORGANIZACIÓN”. – Conjunto de personas encargadas de la planificación,

organización e implementación del evento.

"INSTALACIONES”. - Todas las que integran y se encuentran en el interior de la

Escuela Técnica Superior de Ingeniería Informática y de Telecomunicaciones (ETSIIT)

de la Universidad de Granada. Específicamente, los materiales y equipos contenidos en

las aulas 3.3, 3.4 y 3.5 de la ETSIIT.

CLÁUSULA SEGUNDA. - Las disposiciones contenidas en el presente

“REGLAMENTO", son de aplicación general y observancia obligatoria, para todos los

trabajadores que desempeñan cualquier tipo de actividad para el evento, aun cuando su

ingreso sea anterior al depósito del presente "REGLAMENTO", ante las Autoridades

Académicas de la ETSIIT.

CAPÍTULO SEGUNDO

DEL INGRESO

CLÁUSULA TERCERA. - Todas las personas que presten servicios para el evento,

deberán hacerlo una vez firmada La carta de participación de la LAN Party. Para todos

los efectos legales, el “MENTOR” únicamente reconocerá como “trabajadores” a

quienes hubieren firmado dicho instrumento.

CLÁUSULA CUARTA. - Previo el ingreso y aceptación de cualquier persona con el

carácter de “Trabajador”, el aspirante, deberá cumplir con el llenado o entrega de una

solicitud de participación por escrito.

CLÁUSULA QUINTA. - Todo aspirante deberá demostrar las aptitudes y

conocimientos requeridos, para desempeñar las labores propias del puesto o cargo que

pretenda desempeñar. Para ello, se someterá a exposiciones y/o evaluaciones, tanto

teóricas como prácticas, que juzgue necesarios el “MENTOR” del evento, así como la

“ORGANIZACIÓN”.

115


CAPÍTULO TERCERO

DEL LUGAR Y TIEMPO DE TRABAJO

CLÁUSULA SEXTA. - Los voluntarios iniciarán y terminarán sus labores los días

indicados en la Escuela Técnica Superior de Ingeniería Informática y de

Telecomunicaciones (ETSIIT) de la Universidad de Granada, y deberán atender a

cualquier otra actividad conexa a su ocupación principal.

CLÁUSULA SEPTIMA. – La fecha y hora de entrada al evento será de la siguiente

manera:

Día 12 de Febrero desde las 10:00 hasta las 19:00 ininterrumpidamente.

CLÁUSULA OCTAVA. - La jornada de trabajo aludida anteriormente, deberá ser

prestada de forma eficiente por los trabajadores, evitando cualquier pérdida de tiempo.

CLÁUSULA NOVENA. - Al inicio de la jornada diaria, los trabajadores deberán

registrar su hora de entrada, por los medios que establezca y ponga a su disposición la

“ORGANIZACIÓN”. Iguales obligaciones tendrán al término de la jornada.

CLÁUSULA DÉCIMO. - Los trabajadores que ingresen a sus labores después de la

hora de entrada, serán sancionados conforme a lo previsto en el presente

"REGLAMENTO".

CAPÍTULO CUARTO

DE LA JORNADA DE TRABAJO

CLÁUSULA DÉCIMO PRIMERA. - La jornada de trabajo será normalmente de

unas 4 o 5 horas para todos los turnos, a excepción de la presentación de obligaciones

académicas y/o de otra índole que serán valoradas por el “MENTOR”.

CLÁUSULA DÉCIMO SEGUNDA. - El horario de entrada y salida al trabajo será el

especificado en la Cláusula SÉPTIMA, con la salvedad siguiente: el horario señalado,

podrá ser modificado a petición del “MENTOR” y por necesidades, cuando así lo

estime pertinente, sin mayor trámite.

CLÁUSULA DÉCIMO TERCERA. - Los trabajadores sin excepción alguna,

deberán estar en sus lugares de operación e iniciar sus labores exactamente en la hora

señalada en la Cláusula anterior; sin embargo, se dará una tolerancia de 10 minutos para

casos excepcionales y no como derecho permanente.; al personal que llegue después de

esta hora, será potestativo para la "MENTOR" el recibirlo o no. Si el trabajador no fuera

admitido, se le anotará la correspondiente falta de asistencia injustificada, para todos los

efectos Legales a que haya lugar.

El “MENTOR” se reserva el derecho de considerar el retardo como justificado

previo análisis del justificante presentado por el trabajador.

CLÁUSULA DÉCIMO CUARTA. - Para el efecto de computar los retardos, el

“MENTOR” tendrá la total potestad para sancionar académicamente a los trabajadores

que no cumplan con su jornada de trabajo.

116


CLÁUSULA DÉCIMO QUINTA. - La “ORGANIZACIÓN” proporcionará tiempo

para que los trabajadores tomen sus alimentos, de acuerdo a lo siguiente:

Comida entre las 13:15 h y las 15:30h.

Dichos horarios podrán modificarse.

CLÁUSULA DÉCIMO SEXTA. - Será obligación personal de los trabajadores,

registrar su entrada y asistencia. El incumplimiento de esta disposición, originará que se

tenga una falta de asistencia.

CLÁUSULA DÉCIMO SEPTIMA. - Cada trabajador es responsable de reportarse

con el gerente de turno.

CAPÍTULO QUINTO

HIGIENE Y SEGURIDAD

CLÁUSULA DÉCIMO OCTAVA. - La "ORGANIZACIÓN" podrá adoptar las

medidas de Higiene y Seguridad que estime pertinentes y las que las Autoridades

competentes señalen.

CLÁUSULA DÉCIMO NOVENA. - Para los efectos de este Capítulo, se formará en

la "ORGANIZACIÓN” una Comisión Mixta Permanente de Higiene y Seguridad, en

términos de “LEY”.

CLÁUSULA VIGÉSIMA. - Serán atribuciones obligatorias de la Comisión Mixta

Permanente de Higiene y Seguridad:

a) Proponer o sugerir medidas para prevenir riesgos de trabajo y vigilar que éstas se

cumplan puntualmente. Asimismo, propondrá días y horas para limpieza y aseo de las

áreas de trabajo.

b) Vigilará que la "ORGANIZACIÓN" proporcione a los trabajadores, los equipos

de protección que sean necesarios.

c) De supervisar que los usuarios y trabajadores se abstengan de realizar cualquier

acto que pueda poner en riesgo su propia seguridad o la de sus compañeros.

d) Verificar que los extintores estén completamente cargados, que se encuentren

instalados en los lugares apropiados y que las salidas de emergencia se encuentren

despejadas.

e) Verificar que el botiquín de primeros auxilios cuente con lo necesario para atender

una emergencia como son: gasas, alcohol, vendas, agua oxigenada, bandas adhesivas,

antiácidos, analgésicos, pomadas para quemaduras, heridas y raspones.

g) Vigilar que en caso de accidente o siniestro se proporcionen al lesionado los

primeros auxilios.

h) Verificar que el personal de la empresa asista a la capacitación sobre seguridad e

higiene en el trabajo y de protección civil que se programe, así como nombrar a la

brigada de primeros auxilios que atenderá en caso de emergencia.

i) Supervisar que las instalaciones y equipos se encuentre en buen estado y sugerir

medidas correctivas necesarias a las instalaciones y equipos en general.

j) Informar a la administración el resultado de las anteriores peticiones u

observancias.

117


CLÁUSULA VIGÉSIMO PRIMERA. - En todos los lugares donde se designe la

colocación de extintores y botiquín se encontrará la señal correspondiente para

información de los clientes o de personas ajenas a la empresa.

CAPÍTULO SEXTO

PERMISOS

CLÁUSULA VIGÉSIMA SEGUNDA. - Los trabajadores están obligados a solicitar

los permisos para faltar a sus labores, directamente al “MENTOR”, mínimo con dos

días de anticipación.

Toda falta no justificada, se computará como injustificada.

CLÁUSULA VIGÉSIMA TERCERA. - Para los días de permiso justificados, los

trabajadores deberán ajustarse a las normas establecidas por el “MENTOR”.

CAPÍTULO SEPTIMO

OBLIGACIONES DE LOS TRABAJADORES

CLÁUSULA VIGÉSIMA CUARTA. - Además de las obligaciones de “LEY” el

personal tendrá de manera específica, las siguientes:

a) Cumplir estrictamente todas las disposiciones de este "REGLAMENTO".

b) Realizar su trabajo con eficiencia, responsabilidad y cuidado.

c) Respetar y atender a los usuarios con un servicio de calidad, respetándolo en todo

momento.

d) Utilizar los recursos que proporciona la “ORGANIZACIÓN” de manera

responsable.

e) También deberán guardar todo el material y/o equipo proporcionado, en su lugar

de resguardo asignado previamente.

f) Manipular los productos herramientas o equipos con precaución, cuidado y de

manera responsable que no merme o dañe de los mismos.

g) No distraer a sus compañeros con actos o conversaciones ajenas a su labor.

h) No separarse de su área de trabajo.

i) Ser disciplinado y observar buena conducta en el desempeño de sus labores.

m) Cooperar plenamente en las actividades que se estimen oportunas en el evento.

q) Reportar al “MENTOR” los desperfectos e irregularidades que se noten en la

maquinaria o en sus “INSTALACIONES Y EQUIPOS”

r) Usar las máquinas, herramientas y material propiedad de la ETSIIT en la forma

que el “MENTOR” señale.

s) Prestar auxilio inmediato, cuando peligren las personas o intereses del evento, o de

sus compañeros de trabajo.

t) Usar los sanitarios para el fin específico

CAPÍTULO OCTAVO

PROHIBICIONES

CLÁUSULA VIGÉSIMA QUINTA. - Queda estrictamente prohibido al personal de

la "ORGANIZACIÓN":

a) Hacer comentarios inapropiados, revisar información o realizar cualquier actividad

que viole la privacidad de los compañeros o usuarios del evento.

118


b) Solicitar al usuario acreditación mediante su inscripción en la “hoja de

inscripciones” a su entrada al evento. La desobediencia de esto, acarreará la

correspondiente expulsión del evento.

c) Extraer material o equipos de la Escuela sin previa autorización.

d) Cambiar turno sin autorización del “MENTOR”, esto solo podrá hacerse mínimo

con un día de anticipación y previa autorización.

e) Portar objetos prohibidos de cualquier clase dentro de la ETSIIT.

f) Intervenir sin autorización expresa de la “ORGANIZACIÓN” o del “MENTOR”,

en la reparación de maquinaria o equipos de cualquier tipo, sin conocimiento de causa.

g) Realizar cualquier acto que ponga en peligro su seguridad o integridad física, la de

sus compañeros de labores o que pueda causar algún perjuicio o daño al mobiliario,

equipo, maquinaria o instalaciones propiedad de la ETSIIT.

h) Suspender sus labores o abandonarlas sin permiso previo o causa plenamente

justificada.

i) Presentarse en estado de ebriedad, inconveniente o bajo la influencia de algún

narcótico o droga; así como introducirlos e ingerirlos en la propia Escuela.

j) Obstaculizar o entorpecer en cualquier forma, las labores o actividades normales

del evento.

k) Extraer de la ETSIIT documentos, útiles, herramientas, materiales u objetos

propiedad de ésta, o que estén bajo su cuidado o custodia.

l) Introducir en las aulas del evento objetos ajenos a la misma, como aparatos

eléctricos o cualquier otro equipo o accesorio que puedan obstaculizar el normal

desarrollo del evento.

m) Introducirse dentro de las áreas de la ETSIIT o permanecer en ella, fuera de las

horas laborables o una vez terminado el evento.

n) Alterar o modificar, cualquier Registro de Control implementado por la

"ORGANIZACIÓN”

o) Fumar, mascar, comer y beber en las aulas.

p) Realizar actos que atenten a la moral y el normal desarrollo del evento.

q) Realizar cualquier tipo de actividad en lugares peligrosos o insalubres.

r) Introducir en la ETSIIT amigos o familiares y toda persona ajena a la misma.

s) Todos aquellos actos que impliquen una prohibición derivada de alguna

disposición Legal, contractual o reglamentaria.

t) Queda estrictamente limitada la entrada de animales domésticos en el espacio de la

Escuela, lo cual implica introducirlos o que se introduzcan solos.

CAPÍTULO NOVENO

SANCIONES

CLÁUSULA VIGÉSIMA SEXTA. - Son causas de expulsión del evento, así como

de no superación de la asignatura académica “Laboratorio de Telemática” para los

alumnos matriculados en ella, las expuestas a continuación:

I. Ocasionar intencionalmente, perjuicios materiales durante el desempeño de las

labores o con motivo de ellas, en los edificios, obras, maquinaria, instrumentos, y demás

objetos proporcionados para el evento.

II. Comprometer por imprudencia o descuido inexcusable, la seguridad del

establecimiento o de las personas que se encuentran en él.

III. Ser alumno de la asignatura y tener más de dos faltas de asistencia sin causa

justificada.

IV. Desobedecer a la “ORGANIZACIÓN” o al “MENTOR” sin causa justificada.

119


V. Negarse a adoptar las medidas preventivas o a seguir los procedimientos

indicados para evitar accidentes

VI. Concurrir a sus labores en estado de embriaguez o bajo la influencia de algún

narcótico o droga, salvo que, en este último caso, exista prescripción médica. Antes de

iniciar su servicio, deberá poner el hecho en conocimiento del “MENTOR” y presentar

la prescripción suscrita por el médico.

CLÁUSULAS ADICIONALES

CLÁUSULA VIGÉSIMA SÉPTIMA. - La “ORGANIZACIÓN” llevará a cabo las

siguientes acciones:

I. Proporcionar sanitarios limpios y en buen estado para el personal.

III. Proporcionar los equipos y materiales necesarios para que se lleve a cabo la

implementación de la LAN Party.

IV. Instalar y adoptar las medidas de seguridad e higiene que fijen las leyes y los

reglamentos para prevenir accidentes.

V. Disponer de los medicamentos y materiales de curación necesarios para brindar

los primeros auxilios en caso de accidente.

CLÁUSULAS TRANSITORIAS.

CLÁUSULA PRIMERA.- El presente "REGLAMENTO" ha sido formulado de

común acuerdo entre el “MENTOR” y la “ORGANIZACIÓN”.

CLÁUSULA SEGUNDA.- El presente "REGLAMENTO" se hará del conocimiento

de todo el personal y se fijará en lugares visibles de la Escuela.

CLÁUSULA TERCERA.- Este "REGLAMENTO" entrará en vigor a partir del día

NUEVE DE ENERO DE DOS MIL DIECISEIS y su observancia es de carácter

obligatorio para todo el personal.

CLÁUSULA CUARTA.- Este "REGLAMENTO" podrá ser modificado o

adicionado, de común acuerdo entre las partes, notificándose tanto a los miembros de la

“ORGANIZACIÓN” como a los usuarios que van a asistir al evento.

Así lo suscribieron y ratificaron por el “MENTOR” y la “ORGANIZACIÓN”, a

fecha de Veintinueve de Diciembre de Dos Mil Quince en la Ciudad de Granada

Miguel Ángel López Gordo

“ORGANIZACIÓN”

Firma: Firma:

120


Reglas de juegos y torneos 12.1.3

En esta parte se van a describir las reglas y los torneos de cada uno de los juegos, y

se va a proponer un posible horario a partir de una suposición de jugadores participantes

en cada uno de los torneos.

12.1.3.1 Horario

El horario que se propone es el siguiente:

Tabla 12.4. Horario de torneos propuesto.

Minecraft Hearth

Stone LOL FIFA

Street

Fighter

Counter

Strike

Team

Fortress

9:00 - 9:20

Q1

OC1 - T1 OC1 - T1

9:20 - 9:40 SM1 – T1

DS1,2,3 - T1 OC2 - T1 OC2 - T1 Q1 - T1

9:40 - 10:00 DS4,5,6 - T1 OC3 - T1 OC3 - T1 Q1 - T1

10:00 - 10:20 SM2 – T1

DS7,8,9 - T1

Q2

OC4 - T1 OC4 - T1 Q2 - T1

10:20 - 10:40 DS10,11,12 - T1 OC5 - T1 OC5 - T1 Q2 - T1

10:40 - 11:00 DS13,14,15 - T1 OC6 - T1 OC6 - T1 Q3 - T1

11:00 - 11:20 F – T1

DS16 - T1

Q3

OC7 - T1 OC7 - T1 Q3 - T1

11:20 - 11:40 OC1,2,3 - T1 OC8 - T1 OC8 - T1 Q4 - T1

11:40 - 12:00 OC4,5,6 - T1 Q1 - T1 Q1 - T1 Q4 - T1

12:00 - 12:20 OC7,8 - T1

Q4

Q2 - T1 Q2 - T1 SM1 - T1

12:20 - 12:40

T2

Q1,2 - T1 Q3 - T1 Q3 - T1 SM1 - T1

12:40 - 13:00 Q3,4 - T1 Q4 - T1 Q4 - T1 SM2 - T1

13:00 - 13:20 SM1,2 - T1

SM1

SM1 - T1 SM1 - T1 SM2 - T1

13:20 - 13:40 SM2 - T1 SM2 - T1 F - T1

13:40 - 14:00 F - T1 F - T1 F - T1 F - T1

14:00 - 14:20

Descanso 14:20 - 14:40

14:40 - 15:00

15:00 - 15:20

T3

DS1,2,3 - T2

SM2

OC1 - T2 Q1 - T2

15:20 - 15:40 DS4,5,6 - T2 OC2 - T2 Q1 - T2

15:40 - 16:00 DS7,8,9 - T2 OC3 - T2 Q2 - T2

16:00 - 16:20 DS10,11,12 - T2 OC4 - T2 Q2 - T2

16:20 - 16:40 DS13,14,15 - T2 OC5 - T2 Q3 - T2

16:40 - 17:00 DS16 - T2 OC6 - T2 Q3 - T2

17:00 - 17:20

T2

OC1,2,3 - T2

F1

OC7 - T2 Q4 - T2

17:20 - 17:40 OC4,5,6 - T2 OC8 - T2 Q4 - T2

17:40 - 18:00 OC7,8 - T2 Q1 - T2 SM1 - T2

18:00 - 18:20 Q1,2 - T2

F2

Q2 - T2 SM1 - T2

18:20 - 18:40 Q3,4 - T2 Q3 - T2 SM2 - T2

18:40 - 19:00 SM1,2 - T2 Q4 - T2 SM2 - T2

19:00 - 19:20

F3

SM1 - T2 F - T2

19:20 - 19:40 F – T2 SM2 - T2 F - T2

19:40 - 20:00 F - T2

121


La leyenda para entender el horario es:

Sigla Significado

DS Dieciseisavos

OC Octavos

Q Cuartos de final

SM Semifinales

F Final

T1 Torneo 1

T2 Torneo 2

T3 Torneo 3

Tabla 12.5. Leyenda de horario.

Por ejemplo, si en una zona horaria aparece para un determinado torneo la secuencia

DS1, 2,3 - T1 significa que en la franja horaria indicada se van a disputar las tres

primeras rondas de dieciseisavos (ronda 1, 2 y 3 de dieciseisavos) del torneo 1.

12.1.3.2 Reglas generales de juegos y torneos

Reglamento General

El Reglamento General de la LAN PARTY se ha decidido por parte de la

Organización. Esta es la encargada de moderar, organizar y gestionar las distintas

competiciones. La Organización se reserva el derecho a modificar estas reglas en

cualquier momento y sin previo aviso.

Es obligación de todos los usuarios y/o jugadores haberse leído y entendido el

reglamento, ya que el desconocimiento no exime de culpa al infractor.

Aplicación del Reglamento

Los usuarios aceptan todas y cada una de las reglas aquí expuestas, así como las

condiciones generales de uso, uso de cookies y normas de comportamiento expuestas en

otros apartados.

Las nuevas normas indicadas en la información de cada torneo/copa prevalecerán

sobre las aquí expuestas. Por lo tanto, el usuario, al inscribirse en torneos, acepta todas y

cada una de las reglas aquí expuestas, así como también las indicadas en la información

de cada evento, por lo que se ven obligados a cumplirlas.

El no cumplimiento de alguno de los puntos aquí o allí expuestos podría suponer la

expulsión de la competición.

La organización se guarda el derecho de tomar decisiones sobre los puntos no

cubiertos en el reglamento con el fin de mantener la competencia.

12.1.3.2.1 Penalizaciones

Sanciones

La organización del torneo se guarda el derecho a determinar la gravedad de la

sanción tomando la decisión según las acciones realizadas por los integrantes partícipes.

122


Todos los programas de “cheats” están totalmente prohibidos y será expulsado del

evento todo aquel jugador que los utilice. Por supuesto, el uso de “bugs” o fallos del

juego, para sacar provecho de la situación, está totalmente prohibido y se tomarán las

mismas medidas.

Cualquier tipo de falsificación de cuentas de juego o cualquier otra acción que pueda

alterar la veracidad de la competición serán castigadas con la expulsión inmediata de la

competición y probablemente de los posteriores torneos.

Infringir cualquiera de las normas significará la descalificación inmediata del

participante o pérdida parcial o total de la partida o partido.

La organización se reserva el derecho a modificar a su criterio el reglamento antes

del inicio de la competición sin previo aviso, así como disponer ajustes y correcciones

durante el torneo para solucionar cualquier incidencia.

12.1.3.2.2 Reglas de partidos

Antes del partido:

Ficha del partido

Antes de iniciar el partido, los jugadores deberán firmar la ficha indicando que se va

a dar comienzo dicho partido.

Juego individual

Juego: Hora:

Oponente 1:

Oponente 2:

Resultado final: .

Vencedor: .

Firma Oponente 1: Firma Oponente 2:

123


Juego por parejas

Juego: Hora:

Pareja 1:

Pareja 2:

Resultado final: .

Vencedores: .

Firmas Pareja 1: Firmas Pareja 2:

Tiempo de espera / no presentado

Cuando uno de los dos jugadores no se presente, se conceden 10 minutos de cortesía

para que se presente. Si después de este tiempo no aparece, se le adjudicará una victoria

por defecto (defwin) al jugador que está presente en ese enfrentamiento. Dicho jugador

presente, debe hacer constar a los organizadores, mediante una protesta del tipo

"Oponente no presentado", haciendo saber a los árbitros que su rival no ha aparecido

para que ellos actúen en consecuencia.

Durante el partido

Interrupción de la partida

Si un jugador se desconecta y no puede volver a reconectar se dará automáticamente

derrota de la partida en juego.

Abandono voluntario de la partida

No está permitido que ningún jugador abandone un partido en curso. Si se produce

sin una justificación valida, el enfrentamiento se le dará por perdido y se le aplicará una

sanción oportuna.

Cuando el problema afecte a ambos jugadores (caída de los servidores del juego,

etc.), la partida en juego queda anulada y deberá ser jugada de nuevo.

124


Después del partido

Introducir resultado

Al finalizar el partido, el jugador se deberá dirigir a la ficha del partido e introducir el

resultado. Cuando el resultado sea introducido, el jugador oponente deberá confirmar

dicho resultado.

Si ambos jugadores confirmáis el resultado se dará por concluido el encuentro,

introduciendo en la siguiente ronda al equipo que haya salido victorioso.

Si existe un desacuerdo en el resultado final, los jugadores deberán aportar pruebas

donde se aclare el resultado del encuentro. Si por el contrario nadie aporta ninguna

prueba, el encuentro se dará por nulo a los diez minutos, por lo que ningún jugador

pasará a la siguiente ronda.

Solicitud de investigación

Cuando un jugador se sienta víctima de una violación de las reglas durante el partido,

éste no debe interrumpir el partido en ese momento, ya que no ha finalizado. Una vez el

partido haya terminado, el jugador puede solicitar una investigación formal con los

organizadores del torneo.

Así mismo, en la misma ficha del partido, deberá de abrir una protesta, en la que él,

su oponente y los árbitros podrán comentar de forma privada. Se recomienda

proporcionar la información más detalladamente posible, incluyendo pruebas como

fotos o grabaciones de la partida si las hay, para ayudar en su investigación.

12.1.3.2.3 Aclaraciones

Se aconseja utilizar lo mínimo el chat entre jugadores/equipos. Los comentarios

pueden verse malinterpretados por lo que, para no causar problemas, es preferible no

hacer comentarios agresivos o que puedan llevar a un malentendido.

Se vigilará el respeto de los jugadores/equipos hacia sus competidores o cualquier

miembro de la administración. Si esto no ocurre se le expulsará o baneará de las

competiciones futuras a dicho jugador/equipo.

Horarios

Todos los horarios expuestos en este documento y en la web, salvo que se indique lo

contrario, indican la hora española (CEST, UTC/GMT +1 hora en horario de invierno,

UTC/GMT +2 horas en horario de verano).

Requerimiento de cuentas y contraseñas

Ningún administrador de la LAN Party está autorizado para pedir al usuario las

claves de sus cuentas personales.

125


12.1.3.3 Descripción de juegos, torneos y reglas específicas

12.1.3.3.1 Minecraft

Minecraft es un juego de tipo «mundo abierto» o sandbox desarrollado por Mojan, y

comprado recientemente por Microsoft. Es el segundo juego más vendido de la historia.

El funcionamiento del juego es bastante sencillo, es un mundo abierto compuesto por

bloques de diferentes tipos, en donde cada bloque tiene unas características que permite

desarrollar nuevos bloques, objetos, etc.

Además, hay diferentes mobs (criaturas controladas por el ordenador) que pueden ser

buenos (animales como vacas, ovejas, etc) o malos (zombies, esqueletos, brujas, etc).

Cuando se mata a un mob, éste puede dejar objetos varios dependiendo del tipo de

mob. Por ejemplo, una vaca puede dar carne, un esqueleto puede dar huesos, etc.

Finalmente, hay determinadas acciones que dan experiencia como matar mobs y

conseguir determinados logros como, por ejemplo, alcanzar una determinada

coordenada o conseguir materiales (madera, diamantes, etc).

A. Reglas de torneos

Cada jugador se debe inscribir de forma individual en cada uno de los tres torneos

que se proponen para este juego.

Al inscribirse en alguno de los torneos, el participante acepta todas las normas aquí

expuestas, o las que se pueden añadir posteriormente, de forma que el incumplimiento

de alguna de ellas puede llevar sanción y suponer la expulsión en el torneo.

Las reglas específicas en los tres torneos son:

No está permitido el uso de mobs.

Los usuarios se deben ajustar a la versión del servidor.

No está permitido el aprovechamiento de bugs del juego, y se debe informar a

los organizadores en caso de encontrar alguno.

Debido a la capacidad que debe tener el servidor interno y a la popularidad de este

juego, se han reservado solamente 4 puestos de usuario entre las dos zonas secundarias

para participar en cada uno de los tres torneos que se proponen. Por tanto, el número

máximo de participantes jugando instantáneamente en cada torneo es cuatro.

B. Torneos

Se proponen tres torneos en donde los objetivos son muy diferentes. Los tres torneos

se desarrollarán según el horario establecido en este documento y en la página web.

i. Torneo 1: Modo extremo

126


En este torneo se va a suponer que participan 8 jugadores. Sin embargo, se puede

reducir o aumentar el número de jugadores, siempre que el número total sea múltiplo de

cuatro.

Suponiendo los ochos jugadores participantes, el torneo consiste en dos rondas de

semifinal y una ronda final. El modo de juego es individual, y gana aquel jugador que

sea capaz de sobrevivir. Entonces, los dos jugadores que sobrevivan más tiempo en cada

semifinal pasarán a la ronda final.

La duración de cada partida suele rondar 20 minutos, pero se han reservado 40

minutos por si los participantes tienen gran experiencia en el juego y son capaces de

sobrevivir más tiempo del esperado.

ii. Torneo 2: Modo logros

Este torneo consiste en una partida única donde participan 4 jugadores. El ganador de

la partida es el que consiga más puntos.

La asignación de puntos va a ser realizada por los coordinadores de la Lan Party al

final de la partida en función de los logros que se proponen:

- Encontrar diamantes: 50 puntos.

- Conseguir una armadura completa de hierro: 30 puntos.

- Llegar al Nether: 70 puntos.

La duración de la partida va a estar limitada a 1 hora y 40 minutos, de manera que al

final de la partida se sumarán los puntos de cada jugador para decidir el ganador.

iii. Torneo 3: Modo coordenadas

Este torneo también consiste en una partida única donde participan 4 jugadores. El

ganador de la partida es el que llegue en el menor tiempo posible a las coordenadas

indicadas por los organizadores del evento.

Los cuatro jugadores van a estar jugando sobre el mismo mapa, de forma que se

pueden hacer trampas para matarse entre ellos. En caso de que un jugador muera,

comienza automáticamente desde el principio para llegar al punto objetivo.

La duración prevista para esta partida es 1 hora, pero se ha reservado 1 hora y 40

minutos por si el mapa elegido es muy complejo y los jugadores no tienen suficiente

habilidad.

12.1.3.3.2 HearthStone

Hearthstone es un juego de cartas coleccionables en línea que se basa en partidas por

turnos entre dos oponentes, operado a través del Battle.net de Blizzard. Los jugadores

pueden escoger entre diferentes modos de juego que ofrecen diferentes experiencias.

127


El juego presenta nueve héroes, cada uno de ellos representando una clase distinta

dentro del universo de Warcraft. Cada héroe presenta habilidades o los denominados

poderes de héroe.

Las partidas de Hearthstone son una batalla uno contra uno entre dos oponentes

basada en turnos. En cada turno el jugador puede utilizar cartas de su mano, hechizos,

equipar armas o invocando "esbirros". La partida puede ser entre dos personas o entre

una persona y un oponente controlado por ordenador.

El modo de juego que se jugará en el torneo será el modo “Jugar”. Consiste en

combatir con jugadores reales usando el mazo de cartas previamente personalizado o

con el mazo predeterminado de cada héroe. En este modo se puede disputar de dos

formas: normal y por rango, en este segundo existen una enorme cantidad de rangos

para alcanzar, pero para eso se deben ir obteniendo estrellas, las cuales solo se pueden

obtener por medio de ganar partidas, perder partidas puede quitar estrellas dependiendo

del rango en que uno se encuentre (sólo en Rango madera 25-21 no se pierden estrellas),

se obtienen estrellas más rápidamente al obtener más victorias consecutivas, por otro

lado la dificultad de los oponentes se incrementa junto al rango, por lo que mayor rango

significa más dificultad para subir.


Cada jugador se debe inscribir de forma individual en cada uno de los dos torneos

que se proponen para este juego.

Al inscribirse en alguno de los torneos, el participante acepta todas las normas aquí

expuestas, o las que se pueden añadir posteriormente, de forma que el incumplimiento

de alguna de ellas puede llevar sanción y suponer la expulsión en el torneo.

Cada jugador dispone de un battletag único, que se trata de una identificación única.

Es del tipo: nickname#1234. Ese battletag se le debe dar a la organización del evento

antes del inicio del torneo, que se encargará de que el emparejamiento sea el correcto.

Para poder disputar partidas multijugador con alguien específico, ha de introducirse ese

battletag y “retarle”, de forma que los organizadores del evento van a publicar en la

página web los diferentes battletags de los jugadores, y también se indicarán los

battlelags en la ficha del partido que deberán firmar ambos jugadores antes del

comienzo del partido.

Debido a la popularidad de este juego, se han reservado seis puestos de usuario para

los participantes de los dos torneos que se proponen. Por tanto, el número máximo de

participantes jugando instantáneamente en cada torneo es seis.

B. Torneos

Se proponen dos torneos totalmente idénticos que se desarrollarán en horario

diferente. De hecho, los dos torneos se desarrollarán según el horario establecido en este

documento y en la página web.

128


i. Torneo 1

En este torneo se va a suponer que participan 32 jugadores. Este es en juego muy

popular con partidas de corta duración, y por ello, es probable que puedan participar 32

jugadores.

El torneo consistiría en diversas partidas de 1 vs. 1 con los propios mazos que cada

jugador haya ido obteniendo desde que juega a Hearthstone, o con mazos estándar. Los

jugadores empiezan emparejados en fases eliminatorias, de forma que una partida

ganada supone pasar a la siguiente ronda. Suponiendo que hay 32 jugadores

participantes, el torneo consiste en rondas de dieciseisavos, octavos, cuartos de final,

semifinal y final.

La duración de cada partida suele rondar 15 minutos, pero se han reservado 20

minutos por si se alarga la duración de la partida.

ii. Torneo 2

Es un torneo idéntico al torneo 1, pero se va disputar en distinto horario.

12.1.3.3.3 League of Legends (LOL)

League of Legends (LOL) es un videojuego de género multilayer online battle arena

(MOBA).

Los jugadores, llamados invocadores, se enfrentan entre ellos dividiéndose en dos

equipos de 5 jugadores cada uno. El escenario que se va a usar en el torneo es „La grieta

del Invocador‟, ya que se considera el estándar en el juego competitivo.

Antes de empezar la partida, los jugadores deben escoger un personaje, llamado

campeón, con el cual jugarán toda la partida hasta su conclusión. Actualmente, hay 127

campeones disponibles.

Una vez que se termina la fase de selección de campeón la partida comienza. Los

jugadores de cada equipo aparecen en su respectiva área del mapa, dentro de su base,

situadas ambas diametralmente opuestas. Es en la base de cada equipo donde se

encuentra su nexo. El objetivo del juego, y lo que determina el equipo ganador, es

destruir el nexo del equipo rival. Previamente, es necesario acceder a la base enemiga

eliminando sus inhibidores que a la vez son protegidos por torretas distribuidas a lo

largo de las líneas.

En cada base aparecen cada 30 segundos oleadas de súbditos, personajes no jugadores

de inferior ataque y vida, los cuales avanzan por las líneas apoyando los asedios. En la

jungla (secciones que no forman parte ni de las bases ni de los carriles) hay criaturas

neutrales que se mueven poco o nada de su posición y que aparecen y reaparecen cada

cierto tiempo, algunos de los cuales ofrecen bonificaciones temporales o permanentes.

Cada jugador puede matar súbditos, torretas y campeones enemigos, así como criaturas

neutrales, para obtener oro y experiencia. Con el oro se compran objetos para aumentar

estadísticas (ataque, defensa, vida, etc.) y con los niveles se mejoran las habilidades del

campeón.

https://es.wikipedia.org/wiki/Personaje_no_jugador

129


A. Reglas del torneo

Cada jugador se debe inscribir de forma individual en el torneo que se propone para

este juego. Además, en dicha inscripción debe indicar su nombre real, su nombre de

invocador (nombre de la cuenta de League of Legends que va a usar) y el nombre del

equipo de 5 jugadores con el que va a participar.

Al inscribirse en el torneo, el participante acepta todas las normas aquí expuestas, o

las que se pueden añadir posteriormente, de forma que el incumplimiento de alguna de

ellas puede llevar sanción y suponer la expulsión en el torneo.

Cada partida tiene adjudicado un código de torneo para establecer la sala y unir a los

10 jugadores. Este código han de usarlo todos sus jugadores en su plataforma de juego

League of Legends.

Por tanto, se han reservado 10 puestos de usuario entre las dos zonas secundarias, de

forma que solo puede haber una partida simultáneamente.

B. Torneos

Se propone un único torneo que tiene el horario establecido en este documento y en

la página web.

i. Torneo 1

En este torneo deben participar un número mínimo de 8 equipos de 5 jugadores

debido a que el servidor es externo, y establece esta regla para poder alojar la partida.

Lo modalidad del torneo es conocida como „Grieta del Invocador‟ en el que 2

equipos de 5 integrantes compiten con el objetivo de destruir el nexo del equipo rival en

un mapa de tres carriles. También hay una jungla con varios campamentos de criaturas

que se pueden matar.

Entonces, el torneo consiste en fases eliminatorias: cuartos de final, semifinal y final.

De esta manera, el equipo ganador de cada ronda pasa a la siguiente. La final se realiza

al mejor de tres partidas.

La duración media de las partidas está comprendida entre 30 y 45 minutos, pero se

ha reservado 1 hora a cada partida por si se extiende más de la duración media.

12.1.3.3.4 FIFA

FIFA es un juego de simulación de partidos de fútbol. Permite jugar partidos

amistosos o competiciones organizadas dentro del propio juego. Además, se pueden

elegir clubes o selecciones para jugar los partidos.

Se puede jugar de manera individual (1 vs. 1) o por parejas (2 vs. 2), y se puede jugar

tanto en un ordenador como en una PS3/4. En este evento se va a utilizar una PS3 y se

va a organizar un torneo para jugar de forma individual, y otro para jugar por parejas.

130



Cada jugador se debe inscribir de forma individual en alguno de los dos torneos que

se proponen para este juego. Además, en dicha inscripción debe indicar su nombre, y en

el caso de participar en el torneo por parejas, debe indicar también el nombre de su

compañero y el nombre del equipo que forman.




El modo de juego consiste en elegir un partido amistoso, en donde cada jugador o

pareja de jugadores debe elegir cualquier club de fútbol de todos los disponibles en el

juego. Además, el equipo que selecciona un jugador para una ronda puede ser diferente

con respecto al equipo que eligió en la ronda anterior, y también se permite que los dos

jugadores elijan el mismo equipo para enfrentarse. La duración de cada parte del partido

que se debe escoger en la configuración debe ser igual a 5 minutos, y también se debe

elegir el horario de noche y las condiciones climatológicas despejadas.

En caso de empate en el partido, se debe elegir la opción de jugar una prórroga

completa, y en caso de igualdad en la prórroga, se debe elegir la opción de lanzamiento

de penaltis para desempatar el partido.

Cada Zona Secundaria cuenta con una PS3 en la zona central, que se conectará al

proyector para poder disputar el partido.

B. Torneos

Se proponen dos torneos con modalidades diferentes y en horario distinto, tal y como

se indica en la tabla de horarios.

i. Torneo 1

Este torneo consiste en partidos individuales (1 vs. 1) que se disputan sobre la misma

PS3 utilizando dos mandos. En concreto, se va a utilizar la PS3 del laboratorio 3.5.

El número de jugadores que se suponen para este torneo es 16 jugadores, aunque

también se podría llevar a cabo con un número menor de jugadores. Sin embargo,

debido a la limitación de horario no pueden participar más de 16 jugadores.

Entonces, el torneo consiste en fases eliminatorias: octavos, cuartos de final,

semifinal y final. De esta manera, el jugador ganador de cada ronda pasa a la siguiente.

La duración de cada partida va a ser aproximadamente igual a 10 minutos, pero se

puede extender debido a que en caso de empate se debe disputar una prórroga de 4

minutos. Además, también es posible que se disputen penaltis para desempatar el

partido.

Por ello, se ha reservado a cada partido una duración de 20 minutos.

131


ii. Torneo 2

Este torneo consiste en partidos por parejas que se disputan utilizando las dos PS3s

que hay entre las dos zonas secundarias. Además, es necesario utilizar dos mandos en

cada PS3 para que puedan jugar los 4 participantes de cada partido.

El número de equipos que se suponen para este torneo es 16 equipos (32 jugadores),

aunque también se podría llevar a cabo con un número menor de equipos. Al igual que

antes, debido a la limitación de horario no pueden participar más de 16 equipos.


semifinal y final. De esta manera, la pareja ganadora de cada ronda pasa a la siguiente.


puede extender debido a que en caso de empate se debe disputar una prórroga de 4

minutos. Además, también es posible que se disputen penaltis para desempatar el

partido.

Por ello, se ha reservado a cada partido una duración de 20 minutos.

12.1.3.3.5 Street Fighter

Street Fighter es un videojuego de lucha. Permite realizar combates una contra uno

que se disputan utilizando combinaciones de botones para ejecutar golpes especiales.

A este juego se puede jugar tanto en un ordenador como en una PS3/4. En este

evento se va a utilizar una PS3 y se va a organizar un torneo para jugar de forma

individual (1 vs. 1).


Cada jugador se debe inscribir de forma individual en el torneo que se propone para

este juego. En dicha inscripción debe indicar su nombre.




El modo de juego consiste en elegir un combate amistoso en el que gana el mejor a 3

sets, es decir, el primero que consiga dos victorias gana el combate y pasa a la siguiente

ronda.

El laboratorio 3.3 cuenta con una PS3 en la zona central, que se conectará al

proyector para poder disputar el combate.

B. Torneos

Se propone un único torneo que tendrá lugar según el horario establecido.

132


i. Torneo 1

Este torneo consiste en combates individuales (1 vs. 1) que se disputan sobre la

misma PS3 utilizando dos mandos. En concreto, se va a utilizar la PS3 del laboratorio

3.3.

El número de jugadores que se suponen para este torneo es 16 jugadores, aunque

también se podría llevar a cabo con un número menor de jugadores. Sin embargo,

debido a la limitación de horario no pueden participar más de 16 jugadores.


semifinal y final. De esta manera, el jugador ganador de cada ronda pasa a la siguiente.


puede extender en caso de que los jugadores tengan bastante experiencia.

Por ello, se ha reservado a cada partida una duración de 20 minutos.

12.1.3.3.6 Counter Strike

Counter Strike es un juego de tipo primera persona multijugador. La acción de

Counter-Strike se desarrolla en rondas de una duración elegida, en la cual un equipo de

terroristas se enfrenta a un equipo de antiterroristas. El equipo victorioso es el que

cumpla todos sus objetivos de victoria, de situación o la eliminación de todos los

jugadores del otro equipo. Si al final de la ronda no hay victoria directa de uno de los

dos equipos, el equipo que no realizó sus objetivos pierde por eliminación.

Todos los jugadores comienzan con la misma cantidad de puntos de vida y la

cantidad de puntos de armadura que consiguieron conservar durante la ronda anterior

siempre y cuando no compren una nueva. Cuando los daños son causados por los

disparos de sus adversarios o sus compañeros -si hay fuego amigo- (los compañeros

causan menos daño, pero pueden matar igualmente), así como por una caída violenta los

puntos de vida del jugador disminuyen. Los disparos se pueden localizar en diferentes

partes del cuerpo (brazo derecho e izquierdo, pierna derecha e izquierda, torso, y

cabeza), y causan más o menos daños según el lugar afectado, sabiendo que un disparo

en la cabeza es a menudo mortal. La pérdida de puntos de vida solo causa una pequeña

disminución en los movimientos del terrorista o antiterrorista que haya recibido el daño.

Cuando la totalidad de los puntos de vida se terminan, el jugador muere.

Los jugadores que deseen participar en alguno de los dos torneos que se proponen

deben tener instalado Counter Strike Global Offensive. Por supuesto, la organización no

se hace responsable de los posibles fallos que cada usuario pueda experimentar debido a

la instalación del software. Se recomienda utilizar el software con licencia original.



se proponen para este juego. Además, en dicha inscripción debe indicar su nombre y el

nombre del equipo de 5 jugadores en el que va a participar.

https://es.wikipedia.org/wiki/Terroristas

https://es.wikipedia.org/wiki/Antiterrorista

https://es.wikipedia.org/wiki/Armadura_%28combate%29

https://es.wikipedia.org/wiki/Brazo

https://es.wikipedia.org/wiki/Pierna

https://es.wikipedia.org/wiki/Tronco_%28anatom%C3%ADa%29

https://es.wikipedia.org/wiki/Cabeza

https://es.wikipedia.org/wiki/Cabeza

133





El modo de juego consiste en partidas de dos equipos de 5 jugadores que se

enfrentan. Deben ponerse de acuerdo para que un equipo sea el grupo terrorista y otro el

antiterrorista. El número máximo de equipos va a ser 8, y se van a utilizar las siguientes

fases eliminatorias: cuartos de final, semifinales y final.

Para este torneo se han reservado 10 equipos de usuario, 5 en cada zona secundaria,

de tal forma que un equipo jugará en la Zona Secundaria 1 y el otro equipo en la Zona

Secundaria 2.

B. Torneos

Se proponen dos torneos idénticos con horario diferente, tal y como se establece en la

tabla de horarios.

i. Torneo 1

En este torneo se va a suponer que participan 8 equipos de 5 jugadores cada uno.

Las partidas consisten en el enfrentamiento de 2 equipos de 5 integrantes que

compiten por alcanzar los objetivos que el propio juego les va estableciendo.

El torneo consiste en fases eliminatorias: cuartos de final, semifinal y final. De esta

manera, el equipo ganador de cada ronda pasa a la siguiente.

La duración que se establece para cada partida es igual a 15 minutos, pero se han

reservado 20 minutos a cada partida para tener en cuenta el tiempo de las

configuraciones previas a la partida.

ii. Torneo 2

Este torneo tiene exactamente el mismo formato que el primer torneo, pero se va a

disputar en horario diferente.

12.1.3.3.7 Team Fortress 2

Team Fortress 2 es un videojuego de disparos en primera persona multijugador con

elementos de estrategia y juego en equipos. Team Fortress 2 tiene ocho modos de juego

oficiales. Inicialmente el juego se lanzó con tres modos: Captura la Bandera, Puntos de

Control y Control Territorial. Las nuevas actualizaciones han añadido cinco modos:

Carga Explosiva, Arena, Rey de la Colina, Carrera de Vagonetas y Modo Medieval.

Estos modos de juego están a lo largo de 49 mapas oficiales y ofrecen una gran variedad

de estilos y jugabilidad.

Los jugadores que deseen participar en alguno de los dos torneos que se proponen

deben tener instalado Team Fortress 2 en su propio equipo. Por supuesto, la

organización no se hace responsable de los posibles fallos que cada usuario pueda

134


experimentar debido a la instalación del software. El software es gratuito y se encuentra

disponible en la plataforma Steam.



se proponen para este juego. Además, en dicha inscripción debe indicar su nombre y el

nombre del equipo de 5 jugadores en el que va a participar.




El modo de juego consiste en partidas de dos equipos de 5 jugadores que se

enfrentan. Dependiendo del torneo, se utilizará un modo de juego u otro. El número

máximo de equipos va a ser 8, y se van a utilizar las siguientes fases eliminatorias:

cuartos de final, semifinales y final.

Para este torneo se han reservado 10 equipos de usuario, 5 en cada zona secundaria,

de tal forma que un equipo jugará en la Zona Secundaria 1 y el otro equipo en la Zona

Secundaria 2.

B. Torneos

Se proponen dos torneos diferentes en distinto horario, tal y como se establece en la

tabla de horarios.

i. Torneo 1

En este torneo se va a suponer que participan 8 equipos de 5 jugadores cada uno.

Las partidas consisten en el enfrentamiento de 2 equipos de 5 integrantes que

compiten por alcanzar los objetivos que el propio juego les va estableciendo. En este

torneo, el modo de juego va a ser el modo Captura la Bandera.

El torneo consiste en fases eliminatorias: cuartos de final, semifinal y final. De esta

manera, el equipo ganador de cada ronda pasa a la siguiente fase.

La duración que se establece para cada partida es igual a 15 minutos, pero se han

reservado 20 minutos a cada partida para tener en cuenta el tiempo de las

configuraciones previas a la partida.

ii. Torneo 2

Este torneo tiene exactamente el mismo formato que el primer torneo, pero el modo

de juego es el modo Puntos de Control.

135


12.2 Gestión de usuarios

Reglamentos y reglas de la LPP 12.2.1

12.2.1.1 Preámbulo

La organización está compuesta por alumnos de la asignatura de Laboratorio de

Telemática del Grado en Ingeniería de Tecnologías de Telecomunicación de la

Universidad de Granada, quienes se encargarán en todo momento en ocupar su tiempo

en crear, organizar e intentar que este evento salga adelante. Por ello pedimos

comprensión, así como que se sigan las indicaciones que estos os den ya que siempre

serán, según su criterio, para crear la mejor experiencia posible durante toda la Party

Lan.

12.2.1.2 Inscripción

“ETSIIT LAN Party” empezará el 12 de Febrero a las 10:00 horas y acabará el

mismo día a las 19:00 horas, ambas fechas del presente 2016.

Las inscripciones abrirán el día 10 de Febrero y finalizarán el día 11. Plazas

limitadas a 44 personas, estudiantes de la ETSIIT, siendo ocupadas por orden

de inscripción. Tendrán preferencia en participar los alumnos de la asignatura

que así lo deseen.

Toda la información del evento estará disponible en la página web del evento.

Cualquier cambio de normativa, eventos o de otra índole se publicará en la

página web.

A tu llegada a la LAN Party registraremos todo el material que traes para tu

propia Seguridad. La Organización no se hace cargo de las pérdidas sufridas,

por lo que cada persona debe de estar pendiente de sus pertenencias.

La Organización se reserva el derecho de adoptar criterios de admisión

alternativos en determinadas circunstancias sin previo aviso.

La Inscripción en este evento da derecho a una silla, un puesto en una mesa, un

punto de luz y el acceso al resto de evento.

Los datos facilitados por los participantes se conservarán y utilizarán

exclusivamente por la organización para tareas derivadas de la gestión de este

evento y de los que vengan de la misma índole en el futuro.

La inscripción y participación en la “ETSIIT LAN Party” implica la aceptación

de todos los términos y normas que aquí exponemos.

136


12.2.1.3 Participación

Es absolutamente necesario llevar siempre encima un documento oficial de la

Universidad de Granada (Carnet de estudiante, bonobús Universitario, etc.) el

cual deberás llevar contigo durante todo el evento.

Una vez acreditados, deberás llevar visible la acreditación. No estar acreditado

supone la no entrada en la zona LAN. La organización se reserva el derecho de

pedir el Carnet Universitario, DNI u otro equivalente en cualquier momento del

evento.

Cada participante deberá llevar su propio ordenador, monitor, cableado y todo

aquello necesario para que su máquina funcione, inclusive un cable de Ethernet.

Debido a las limitaciones de potencia de la ETSIIT, únicamente se podrá llevar

un ordenador portátil (laptop).

Se aconseja llevar una regleta para poder enchufar su equipo, pues solo se

habilita un punto de luz por participante.

Los participantes podrán traer su ordenador a partir de las 9:00 horas de la

mañana del 12 de febrero.

La Organización tendrá un servicio técnico para solucionar cualquier problema

que pueda haber en la red (tanto eléctrica como de datos) pero no más allá. Por lo

que se aconseja tener actualizado el sistema operativo, firewall, antivirus y

cualquier elemento que podáis necesitar.

12.2.1.4 Normas

Cada participante es único responsable del cuidado y protección de sus

pertenecías personales. Aunque la organización pondrá medidas de seguridad, no

se hará responsable de los hurtos o robos de materiales o de cualquier otro enser

personal de los participantes en el evento.

Cada participante del evento, deberá de cumplir todas las normas de la ETSIIT.

No se permite el uso de programas de descarga p2p (emule, ares, bitTorrent…)

Queda prohibido:

- Comer dentro de la zona LAN. Se habilitarán zonas para ello.

- Beber ninguna bebida sin tapón en la Zona LAN, así como la entrada de

cristal a ella.

- El uso de cualquier tipo de electrodoméstico

- Fumar dentro del recinto.

- Consumir alcohol.

- Consumir estupefacientes.

- Usar altavoces o equipos de música personales.

- Agresiones físicas o verbales.

- Poseer algún tipo de arma.

- No llevar acreditación alguna.

137


- Ocupar zonas de paso, pasillos o zonas comunes, para no molestar al resto

de alumnos de la Escuela, debido a que en esas fechas estaremos en época

de Exámenes.

- La venta no autorizada de cualquier tipo de bien, ya sea físico o digital.

- Malware de cualquier tipo.

- No hacer caso a las indicaciones de la organización.

- Se aconseja no beber en la Zona LAN. La organización no se hace cargo de

ningún desperfecto que puedas ocasionar a ti o a tus compañeros.

- Las visitas dentro de la zona LAN por personas no acreditadas queda

prohibida.

La organización no se hace responsable del software que puedan utilizar los

participantes. En el caso de que se detecte algún tipo de anomalía causada por

un usuario (ataques de red, uso de bots, generación de virus, gusanos,

servidores DHCP, software malicioso, etc.) que sea detectado por la

Organización será sancionado, pudiendo llegar a expulsarse al infractor y/o

alertar a las autoridades competentes.

No está permitida la manipulación ni ningún tipo de actuación sobre los

elementos relacionados con la infraestructura de la LAN Party, tales como

cableado, elementos de la red (switches, cables, puntos de luz), etc.

La organización se reserva el derecho de expulsar a cualquier participante que

incurra en cualquier tipo de comportamiento que impida el correcto

transcurso del evento, así como ofensivo o molesto para el resto de

participantes. Será motivo de expulsión directa cualquier tipo de abuso de los

recursos de red, así como las actuaciones sobre equipos informáticos ajenos al

participante que atenten contra la confidencialidad, disponibilidad o

integridad de los mismos. Tampoco se permitirá ningún tipo de discusión,

violencia ni actos vandálicos. Aquellos que no cumplan con estas

indicaciones serán inmediatamente expulsados del evento y si fuera necesario

tomadas las medidas legales pertinentes.

Administración y perfil de usuarios 12.2.2

El perfil de usuario es una colección de opciones de configuración que hacen que el

equipo tenga el aspecto y funcione de la manera deseada en nuestro evento. Contiene la

configuración para que cada equipo se conecte adecuadamente a la Red de nuestra LPP.

Debido a que se cada usuario utilizará su propio ordenador portátil, la organización no

podrá crear un Perfil de usuario común para todos. Esto solo sería posible si se

utilizarán los ordenadores de las aulas de la ETSIIT.

Por lo tanto, antes del comienzo de los torneos, explicaremos a todos los usuarios del

evento, como deberán de configurar su equipo para poder participar. Entre las

configuraciones necesarias, estarán la configuración de red, firewall, etc. Este hecho no

llevará más de 15 minutos, para que cada usuario posea el mayor tiempo posible para

participar en torneos.

138


La Organización asignará un número a cada usuario del evento (números asignados

del 1 al 44), cada número llevará incluido:

- Un puesto físico del que cada usuario asignado a ese puesto, será el encargado de

mantener el buen mantenimiento del mismo. (Leer Reglamentos y Reglas de la

LPP).

- Una dirección IP privada para cada usuario y cada equipo, por lo que cualquier

infracción en línea quedará registrada con esa dirección IP.

- La posibilidad de participar en cualquiera de los eventos organizados por la LPP

(excluyendo los eventos simultáneos).

- En cada torneo, se asignarán los emparejamientos al azar, basándose en el número

asignado a cada participante.

Como se ha mencionado en los Reglamentos y Reglas de la LPP, únicamente podrán

acceder a la LPP, alumnos de la ETSIIT, quedando prohibida la entrada a cualquier

alumno ajeno a la misma.

La administración de los usuarios será llevada a cabo por personas pertenecientes a

la Organización.

Se encargarán de apuntar en una ficha los datos de cada Participante de la

competición, con el número asignado a cada uno, así como junto con todos sus datos:

- Nombre y Apellidos

- Titulación cursada

- Curso

- Torneos y actividades en los que participará

Cada usuario registrado en la LPP deberá de firmar su ficha de datos de la

competición, constatando que acepta todas las normas expuestas en la misma.

12.3 Aspectos legales

Seguridad física 12.3.1

Cuando hablamos de seguridad física nos referimos a todos aquellos mecanismos de

prevención y detección destinados a proteger físicamente cualquier recurso del evento,

en nuestro caso cualquier elemento hardware (switches, ordenadores, cables, etc.)

Es por ello que a continuación proponemos una serie de medidas a llevar a cabo por

todos los participantes y organizadores del evento:

A) CONTROL DE ACCESO FÍSICO

El principal elemento de control de acceso físico involucra la identificación positiva

del personal que entra o sale del área bajo un estricto control.

Para ello, los organizadores del evento que haya en ese momento en la sala deberán

de elegir a una persona, junto con el Mentor, en la que se le deleguen los cargos de

control de acceso físico. Esto es, a cada persona que intente acceder a la LAN Party se

le pedirá:

139


- Carnet Universitario

- DNI, Pasaporte o equivalente.

Se detallará una base de datos con la hora de acceso, hardware portado, Nombre y

Apellidos que deberá de firmar, aceptando todas las normas y bases del evento.

Cuando la persona quiera salir definitivamente del evento, se lo comunicará a la

Organización y está pondrá su hora de salida.

B) CONTROL DE RIESGOS

Debido a que nos encontraremos en un recinto que cumple toda la normativa pública

de Seguridad, no necesitaremos instalar ningún tipo de equipamiento contra riesgos ni

desastres naturales (incendio, etc.) así como la implementación de Sistemas Eléctricos

de protección.

Sí que se deberá velar por la seguridad de los equipos instalados y realizar un

mantenimiento de los mismos, evitando posibles usos “no razonables” por parte de los

usuarios como, por ejemplo:

- Robos

- Actos Vandálicos tanto físicos como contra el sistema de red de nuestra LPP.

- Sabotaje hacia la LPP.

Protección de datos 12.3.2

La Organización de la LPP se compromete a cumplir la normativa de la Ley

Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal.

La Constitución Española establece en su artículo 18 el derecho a la intimidad de las

personas cuando dice:

18.1. Se garantiza el derecho al honor, a la intimidad personal y familiar y a la propia

imagen.

18.4. La Ley limitará el uso de la Informática para garantizar el honor y la intimidad

personal y familiar de los ciudadanos y el pleno ejercicio de sus derechos.

El objeto de la Ley Orgánica 15/1999, del 13 de diciembre, de Protección de Datos

de Carácter Personal (en adelante LOPD), que derogó la antigua LORTAD de 1992, es

garantizar y proteger, en lo que concierne al tratamiento de los datos personales, las

libertades públicas y los derechos fundamentales de las personas físicas, especialmente

con la finalidad de preservar el honor, intimidad personal y familiar y el pleno ejercicio

de los derechos personales frente a su alteración, pérdida, tratamiento o acceso no

autorizado. Todo esto es aplicable a los datos de carácter personal registrados en

cualquier tipo de soporte físico susceptible de ser tratado (ya sea informático o manual).

Por lo tanto, con motivo de la entrada en vigor de la LOPD surgen una serie de

obligaciones para aquellas Entidades Públicas o Privadas que posean ficheros con datos

de carácter personal. Asimismo, el Reglamento de desarrollo de la LOPD (R.D.

1720/2007) establece la obligación para todas las organizaciones de poner en marcha

diversas medidas destinadas a garantizar la protección de dichos datos, afectando a

sistemas informáticos, locales, soportes de almacenamiento, personal, procedimientos

operativos, etc.

140


Únicamente utilizaremos los datos de los Usuarios para realizar un Control de

Seguridad en el evento, nunca para proporcionar datos a terceras empresas.

Por lo que la Organización se compromete a utilizar los datos personales de los

alumnos participantes de una manera lícita y legal. Para ello no utilizaremos una base de

datos informatizada con los datos de los mismos, para evitar posibles robos y perdidas

por problemas de seguridad.

Uso de Licencias 12.3.3

Cada usuario de la LPP es el único responsable del uso de licencias legales sobre los

juegos y programas que se van a usar en ella. El objetivo de la LPP es crear un evento

en el que los usuarios puedan participar en competiciones de determinadas plataformas

entre ellos, es decir, somos un mero conector entre usuarios, por lo que no tenemos

ningún derecho a distribuir licencias de los videojuegos utilizados en la competición ni

somos responsables del uso “fraudulento” del mismo.

Cada usuario se hace responsable de las medidas legales a tomar por las compañías

en caso de denuncia por no utilizar software lícito.

Conexión a redes P2P y compartición de contenidos 12.3.4

Las redes P2P, no son ilegales como tal, simplemente son un modo de compartir

archivos valiéndose de las oportunidades que ofrece Internet. Estas redes simplemente

son redes de transmisión de datos entre los distintos usuarios de Internet, no vulneran en

principio ningún derecho de Propiedad Intelectual.

La sentencia del juzgado mercantil número 7 de Barcelona; Procedimiento N° 401/09

E AUTO N° 138/09, entre otras, estableció que en la actual Ley de Propiedad

Intelectual no se prohíben, con carácter general, las redes P2P. Y que, los

comportamientos y actividades que se desarrollan en estas redes no encuentran un

acomodo claro y específico en los comportamientos que prohíbe la ley, en especial la

reproducción, distribución y comunicación pública sin autorización.

El problema surge respecto del uso de estas redes; a la hora de que archivos se están

transmitiendo; resulta necesario delimitar claramente obras protegidas y

comportamientos que pueden infringir la LPI. El art 14 de la ley establece que

corresponde al autor decidir si su obra ha de ser divulgada y en qué forma. Y los art 17 a

23 recogen los distintos derechos de explotación, que podrían verse vulnerados.

Ateniéndonos a la LPI, sólo existiría alguna vulneración de los derechos de autor, si

mediante las redes P2P, se transmite algún archivo que contenga obras protegidas por

derechos de autor, sin el consentimiento correspondiente de este.

Por lo tanto, para evitar la compartición de archivos protegidos por derechos de

autor, y demás clase de archivos ilícitos no permitiremos el uso de redes P2P en la LPP.

Para ello deshabilitaremos el puerto correspondiente para evitar que haya uso de este

tipo de Redes en nuestra LAN Party.

141


12.4 Planes de contingencia

A continuación, se presentan distintos escenarios y situaciones que podrían darse

durante el diseño o ejecución de la LPP y que podría afectar al evento. Debe incluir una

solución basada en la estructura organizativa descrita en este capítulo.

Incendio o Fuego

Grado de Negatividad: Muy Severo

Frecuencia de Evento: Aleatorio

Grado de Impacto: Alto

Situación Actual Acción Correctiva

La ETSIIT cuenta con un extintor cargado,

ubicado muy cerca de las aulas. Cada planta

cuenta con un extintor debidamente cargado

Se cumple

No se ha ejecutado un programa de

capacitación sobre el uso de elementos de

seguridad y primeros auxilios, a los organizadores

Realizar una charla breve sobre las medidas a

tomar en caso de incendio

Tabla 12.6. Descripción del plan de Incendio o Fuego

Analizando el riesgo de, incendio, lo primero que debemos de proteger es la

seguridad física de los usuarios de la LPP. Uno de los dispositivos más usados para

contrarrestar la contingencia de incendio, son los extinguidores. Su uso conlleva a

colocarlos cerca de las posibles áreas de riesgo que se debe proteger, por lo que

eventualmente, debido al número de personas que participarán en la LPP se podría pedir

una autorización para trasladar extintores a la tercera planta para futura prevención.

Robo Común de Equipos y Archivos

Grado de Negatividad: Grave


Grado de Impacto: Moderado


Debido a la alta cantidad de usuarios en la

LPP, puede ser que en algún momento de la

misma no se pueda controlar a todas las personas

debidamente

Se requiere que cada persona antes de salir de

la misma nos muestre sus posesiones Hardware y

ver si coinciden con las que se apuntaron en un

principio en la hoja de Inscripción.

Autorización por parte del Mentor para la

salida o traslado de equipos de un Aula o de la

ETSIIT.

Se cumple por medio del formato establecido

para la salida o translación de equipos.

Tabla 12.7. Descripción del plan de Robo

Para evitar los robos de Equipos deberá siempre haber un número mínimo de 2

personas por aula de la LPP que se ocupen de la seguridad de la misma. En caso de

agresión y robo de cualquier tipo de material se avisará a las autoridades denunciando el

hecho.

Fallo en los Equipos



Grado de Impacto: Grave

142



Los fallos en los equipos o el material muchas

veces se deben a golpes en el traslado de los

mismos, o a falta de mantenimiento y limpieza.

Realizar un traslado de los equipos de manera

correcta sin dañarlos y realizar un mantenimiento

preventivo de los mismos.

El fallo en el hardware de los equipos o del

material requiere de remplazo de repuestos de

forma inmediata (switches, cables, etc.)

Contar con material de repuesto o equipos de

repuesto en caso de requerir remplazo de piezas o

de equipos

El daño de equipos por fallas en la energía

eléctrica, requiere contar con dispositivos que

suministren energía alternativa.

Se cumple. La ETSIIT cuenta con un sistema

de energía alternativa por si hay posibles fallos de

la red eléctrica convencional.

Tabla 12.8. Descripción del plan de Fallos

Teniendo en cuenta la importancia de la red eléctrica para el funcionamiento de la

LPP, puesto que los dispositivos en los que se trabaja dependen de la corriente eléctrica

para su desempeño. Si el corte eléctrico dura poco tiempo las operaciones no se ven

afectadas gravemente, pero si el corte se prolongara por tiempo indefinido provocaría

un trastorno en las operaciones del evento, por lo que necesitaríamos cancelarlo o

aplazarlo.

Equivocaciones en el manejo del sistema

Grado de Negatividad: Moderado

Frecuencia de Evento: Periódico

Grado de Impacto: Moderado


Equivocaciones que se producen de

forma involuntaria, con respecto al

manejo de software y equipos.

Los alumnos de la asignatura de LT

tienen conocimientos para reparar el

sistema en caso de fallos de utilización.

De todas formas, se realizará una charla

inicial con los fundamentos principales

para configurar los equipos.

Fallo en la implementación del

sistema de software en la LPP

El Mentor se encargará de dar el visto

bueno a todas las configuraciones

realizadas a switchers.

Fallo en la implementación del

cableado

El Mentor supervisará la instalación

de la LPP. Tabla 12.9. Descripción del plan de Equivocaciones

Acción de Virus y Sabotaje Informático

Grado de Negatividad: Severo

Frecuencia de Evento: Continuo


143



Se tiene acceso restringido al servidor,

únicamente es el administrador de la red el

encargado de cambiar configuraciones y anexar

nuevos equipos

Antes de incluir una maquina a la red, se debe

comprobar la existencia de virus en la misma, así

como la comprobación de credenciales para

acceder al servidor.

Posible sabotaje por parte de usuarios a los

equipos de nuestra LPP

Para ello se implementará un sistema de

seguridad software, imposibilitando la entrada al

sistema a aquellos usuarios que no tengan

permisos.

Posible introducción de virus en el sistema Incluir sistemas de protección como antivirus,

firewall, etc.

Tabla 12.10. Descripción del plan de virus y sabotaje

Accesos No Autorizados





Se controla el acceso al evento mediante un

usuario o grupo de usuarios encargados del

control de acceso rellenando una hoja de

Admisión en la que se detalla el acceso y salida

de los usuarios

Se cumple

En algún momento determinado puede ser que

pase alguna persona no autorizada a la misma

Las personas encargadas del control de acceso

se encargarán de revisar cada cierto tiempo la

lista, para ver si hay el mismo número de

personas en la clase y en la lista. Si esto no fuera

así, se deberán de pedir los datos y ver qué

persona no está autorizada.

Tabla 12.11. Descripción del plan de Accesos no autorizados

Ausencia del personal de Organización





En todo momento debe de haber personal

encargado en la LPP Se cumple.

En algún momento determinado solo quedan

dos personas de la Organización dentro del Aula

Nunca debe de haber un número menor de 2

personas controlando el evento, por lo que, a no

ser por fuerza mayor, no se deberá abandonar el

evento hasta que no lo autorice el Mentor.

Tabla 12.12. Descripción del plan de ausencia de personal

144


Consideraciones ECO 13

En este parte se van a citar todas las propuestas de carácter ecológico que se pueden

implementar en el evento de la LAN Party.

En primer lugar, se propone utilizar un cableado libre de halógenos. Los halógenos

son elementos de la tabla periódica muy reactivos (flúor, cloro, bromo, yodo, etc) que

no se encuentran libres en la naturaleza, sino que se encuentran mezclados con otros

elementos. El resultado de la combustión de materiales halógenos es una gran cantidad

de humos corrosivos, tóxicos y opacos. Por ello, se propone utilizar cables con

aislamiento libre de halógenos que no contiene ninguno de esos elementos, y que se

comportan mucho mejor en caso de incendio.

Desde 2003, los cables libre de halógenos son obligatorios en los edificios de nueva

construcción. Entre sus ventajas, destacan la resistencia al fuego y una excelente

capacidad para no propagar el incendio.

Las principales características de estos cables son:

No se propaga el incendio.

La emisión de gases tóxicos y halógenos es reducida.

Emanación de humos no opacos.

Emisión de gases menos tóxicos.

Por tanto, al no propagar el fuego, se amplía el tiempo disponible para evacuar un

edificio, reducen los riesgos por inhalación de gases, limitan el efecto corrosivo del

humo en los equipos y circuitos electrónicos, y facilitan la visibilidad de acceso a los

focos de incendio a los bomberos.

En segundo lugar, se propone utilizar equipos de usuario que consumen poca energía

eléctrica. Por ello, se va a exigir a todos los usuarios que traigan su propio ordenador

portátil, en lugar de utilizar ordenadores de sobremesa de gran rendimiento que

consumen una gran cantidad de energía. De hecho, un ordenador portátil consume como

máximo 120 vatios por cada hora de carga de la batería, y un típico ordenador de

sobremesa utilizado por los jugadores consume una potencia alrededor de 470 vatios.

En promedio, un ordenador portátil consumo hasta diez veces menos que un ordenador

de sobremesa debido a que consume cuatro veces menos cuando se está cargando el

portátil, y puede tener hasta 6 o 7 horas de autonomía. Sin embargo, el ordenador de

sobremesa consume potencia siempre que está encendido.

En conclusión, los equipos de usuario van a ser ordenadores portátiles para que se

consuma mucha menos energía eléctrica durante el evento.

En tercer lugar, se propone utilizar bombillas de bajo consumo en lugar de bombillas

estándares. Una bombilla de bajo consumo Philips Genie ESaver consume una potencia

igual a 18 vatios por hora. Sin embargo, el consumo de una bombilla estándar es muy

variable, siendo típicos los valores de consumo igual a 40, 60, 100 y 150 vatios por hora

145


de funcionamiento. Por tanto, las bombillas de bajo consumo presentan una gran ventaja

ecológica con respecto a las bombillas de consumo estándar.

En cuarto lugar, la fecha del evento es el 12/02/2016, de forma que no va a ser

necesario utilizar aire acondicionado para disminuir la temperatura de las habitaciones.

Los aparatos de aire acondicionado consumen una gran cantidad de energía eléctrica y

serían necesarios si el evento se celebrara en verano, debido a que la temperatura en

Granada durante el verano es demasiado alta. Esto es una ventaja ecológica con respecto

a otros muchos eventos de LAN Party que se celebran en verano con muy altas

temperaturas, y que necesitan usar aparatos eléctricos para disminuir la temperatura.

Debido a que la estación de celebración del evento es el invierno, se va a usar

calefacción con una caldera y con radiadores de agua, de manera que se transmite calor

al agua mediante la quema de gas natural. La combustión del gas natural produce menos

gases de efecto invernadero que otros combustibles fósiles como los derivados

petrolíferos (fuelóleo, gasóleo o gasolina) y especialmente que el carbón. Además, es un

combustible que se quema de forma más limpia, eficiente y segura, y que no produce

dióxido de azufre (causante de la lluvia ácida) ni partículas sólidas. En conclusión, se va

a usar calefacción que utiliza el combustible que tiene menor impacto medioambiental.

Relacionado con la energía, se puede proponer utilizar placas solares para la

obtención de la energía eléctrica que se va a consumir durante el evento. Sin embargo,

la infraestructura eléctrica del edificio es propia de la Escuela Técnica de Ingeniería

Informática y de Telecomunicaciones de la Universidad de Granada, y el evento se debe

adaptar al proceso de obtención de energía eléctrica que utiliza esta universidad para la

cual se va a organizar el evento.

Por otro lado, el número de usuarios que van a asistir al evento es reducido en

comparación con otras LAN Partys. En concreto, va a asistir un número total de 44

usuarios, por lo que esta LAN Party presenta una ventaja ecológica en cuanto a

consumo eléctrico en comparación con otras donde asisten un elevado número de

usuarios.

Además, la duración del evento es un único día que incluye mañana y tarde. Por

tanto, todos los torneos están organizados para que se desarrollen durante un máximo de

12 horas, lo cual significa que el número de horas que van a estar los usuarios

conectados con la alimentación de sus ordenadores portátiles es mucho menor que otros

eventos que tienen una duración de un fin de semana.

En conclusión, se han citado ocho propuestas que se podrían implementar, de las que

algunas es seguro que se van a implementar por la propia naturaleza del evento que se

va a organizar, y que quedan recogidas en el siguiente listado:

Cableado libre de halógenos. Su implementación es altamente probable

debido a que el coste de este cableado en comparación con el coste del

cableado estándar es muy similar.

Uso de ordenadores portátiles. Esta propuesta es uno de los requisitos del

evento debido a que cada usuario puede consumir un máximo de 250 vatios

por hora. Por tanto, esta propuesta va a ser implementada en el evento con

146


toda seguridad, y supone una gran ventaja ecológica con respecto a otras

LAN Partys.

Bombillas de bajo consumo. Esta propuesta se va a llevar a cabo debido a que

los laboratorios en los que se va a organizar el evento ya disponen de este tipo

de bombillas.

Fecha del evento. Una LAN Party organizada en invierno tiene una ventaja

ecológica con respecto a otras organizadas en verano, debido a que el uso de

calefacción tiene un menor coste medioambiental que el uso de aire

acondicionado.

Calefacción de caldera con quema de gas natural. Existen varios tipos de

calefacción: eléctrica por acumulación, eléctrica por convectores, radiadores

de aceite, suelo radiante, caldera con radiadores de agua, bomba de calor

(equivalente al aire acondicionado) y calefacción de gas. La ETSIIT utiliza

una calefacción basada en una caldera con radiadores de agua que quema gas

natural, de tal forma que se trata de uno de los sistemas de calefacción con

menor impacto medioambiental.

Placas solares para la obtención de la energía eléctrica consumida durante el

evento. Esta propuesta está descartada debido a que la ETSIIT tiene su propio

contrato con una compañía eléctrica para proveer de electricidad a todo el

edificio.

Número de usuarios reducido. Solamente van a asistir 44 usuarios al evento

de forma que se va a consumir menos energía eléctrica que en otros eventos

donde acuden muchos más usuarios.

Número de horas del evento. El evento está organizado desde las 9.00 hasta

las 21.00 horas, es decir, tiene una duración igual a 12 horas. Otros eventos

de LAN Partys tienen una duración de 36 horas, de manera que el número de

horas de consumo eléctrico es mucho mayor en dichos eventos.

147


Servicios LPP 14

14.1 Cámara IP

Introducción 14.1.1

Las cámaras IP son vídeo cámaras de vigilancia que tienen la particularidad de enviar

las señales de video (y en muchos casos audio), pudiendo estar conectadas directamente

a un Router ADSL, o bien a un concentrador de una Red Local, para poder visualizar en

directo las imágenes bien dentro de una red local (LAN), o a través de cualquier equipo

conectado a Internet (WAN) pudiendo estar situado en cualquier parte del mundo.

Para la LPP se contará con 5 cámaras IP que harán las funciones de seguridad de

videovigilancia. Para ello se pondrán dos cámaras IP en cada Zona Secundaria y una

más en la Zona Principal, de esta forma se tendrá controlado en todo momento el acceso

a las sala.

Esto permitirá por un lado, evitar la tentación que pueda tener la gente de intentar

sustraer algo, y por otro lado, en caso de que se sustraiga, poder identificar a la persona.

Funcionamiento básico 14.1.2

Lo primero que se debe hacer es conectar la cámara a la alimentación y a un puerto

Ethernet.

A continuación por DHCP se le asigna una IP, una máscara y una puerta de enlace.

La dirección IP sale en la pantalla de la cámara, por lo que se podrá acceder a ella

colocando la IP en el navegador. Solicitará un usuario y contraseña, ambos son

“admin”. Hecho esto, se podrá acceder al panel de control de la cámara.

14.1.2.1 Panel de control

Justo al acceder a la cámara aparece la siguiente imagen:

Fig. 14.1: Panel de control de la cámara Ip.

148


Como se puede ver, la cámara puede moverse en vertical y horizontal, así como

izquierda y derecha.

14.1.2.2 Configuración básica

Fig. 14.2: Configuración básica de la cámara Ip.

La configuración básica permite cambiar el nombre de la cámara y la descripción de

esta, así como la hora y la ubicación. También da acceso a la configuración de red,

donde permite cambiar la IP, máscara de red, la puerta de enlace y los DNS.

Finalmente se puede cambiar el punto de acceso Wifi que genera la cámara para

conectarse a ella.

149


14.1.2.3 Configuración avanzada

Fig. 14.3: Configuración avanzada de la cámara Ip.

En esta pestaña se pueden modificar aspectos de los protocolos multimedia como

RTP y RSTP, el servicio web por el que se entra y asignar QoS.

14.1.2.4 Usuarios

Se permite activar o desactivar la autenticación, también permite cambiar el usuario

y la contraseña del administrador y agregar hasta 20 usuarios adicionales que no son

administradores.

Fig. 14.4: Administración de los usuarios de la cámara Ip.

150


14.1.2.5 Mantenimiento

Fig. 14.5: Panel de control de mantenimiento de la cámara Ip.

En el apartado de mantenimiento, se podrían restaurar los valores por defecto si fuese

necesario, actualizar la cámara y guardar la configuración.

14.1.2.6 Video

Fig. 14.6: Configuración del video de la cámara Ip.

151


En el apartado de vídeo, se puede ajustar la calidad de este en función de 5

posibilidades, desde muy bajo hasta muy alto, también se puede ajustar la resolución y

los fps. Y todo esto tanto para el formato MPEG4 como para el MJPEG. También

permite el Streaming para móvil.

Para que el ancho de banda no sea excesivo, la calidad, la resolución y los fps se

ajustarán de tal modo que no suponga un problema.

14.1.2.7 Audio

Fig. 14.7: Configuración del audio de la cámara Ip.

En el apartado de audio, este puede ser activado o desactivado. También se puede

permitir hablar o escuchar solo, hablar y escuchar pero no simultáneamente, o hablar y

escuchar a la vez.

Tráfico generado 14.1.3

Tras capturar tráfico con Wireshark, se observa como el tráfico se genera con una

tasa de hasta 8.3 Mbps a máxima calidad (640x480 a 30 fps y calidad máxima).

Para reducir el ancho de banda se ha configurado la cámara a 640x480 y a 30 fps

pero con baja calidad. De esta manera se genera una tasa de tráfico de 1,3 Mbps, lo que

permitiría la emisión web.

Fig. 14.8: Estadísticas de tráfico de la cámara Ip.

152


Implementación 14.1.4

Para la implementación de las cámaras web, se han reservado dos puertos en los

switches de las Zonas Secundarias y uno en la Zona Principal.

Por otro lado, en el ordenador de gestión, se accederá a ellas a través del navegador

web y se vigilará en todo momento la LPP. Para ello se ha asignado una VLAN

únicamente para las cámaras IP, de esta manera se evita que otras personas de la LPP

puedan acceder a las cámaras. Aunque también tienen seguridad implementada, de

modo que aunque alguien consiguiese llegar a la cámara, no podría entrar al panel de

control.

Finalmente, como se necesita saber las IP‟s para poder entrar a ver las cámaras,

estas se asignaran manualmente y no por DHCP.

14.2 Servicio de almacenamiento en nube Owncloud

Objetivos y directrices 14.2.1

Crear una nube privada que permita el intercambio de archivos, usando

OwnCloud. Usar herramientas “open source” para llevar a cabo el desarrollo del servicio.

Para llevar a cabo esta práctica se han seguido los siguientes directrices:

1. Configuración del multilayer. (configuración de una IP estática accesible desde nuestra intranet).

2. Instalación del servidor Apache, la base de datos MySql y PHP en el servidor, para lo cual instalaremos el paquete LAMP.

3. Instalación de OwnCloud.

Arquitectura 14.2.2

Los elementos más importantes que conforman esta arquitectura son:

OwnCloud Server: Servidor donde se ejecuta el servicio de almacenamiento. PC servidor donde se ejecutara el Owncloud. ETSIIT Multilayer: Switch multilayer del aula 3.4 a través del cual se conecta el

cliente. PC del cliente: PC desde el que accedemos a los archivos almacenados en la

nube.

Configuración 14.2.3

Para el correcto funcionamiento del servicio a prestar, se tendrá que configurar la IP

del equipo que funcione como servidor como estática, de forma que en cualquier

momento todos los PCs de las zonas secundarias y principal puedan acceder a él. Este

servidor será uno de los equipos de la zona principal que contengan ya uno de los

servidores necesarios para la LPP, como puede ser el servidor web.

Para ello se instala el paquete LAMP en ese mismo equipo. LAMP es el acrónimo de

Linux + Apache + MySQL + PHP, y describe una plataforma de desarrollo web que

http://en.wikipedia.org/wiki/LAMP_%28software_bundle%29

153


utiliza Linux como Sistema Operativo, Apache como servidor Web, MySQL como

Sistema Gestor de Bases de Datos relacional y PHP como lenguaje de programación.

$ sudo apt-get install lamp-server^

$ sudo mysql_secure_installation

$ sudo apt-get install php5-gd php-xml-parser php5-intl smbc

$ sudo a2enmod rewrite

$ sudo a2enmod headers

Por último se edita la configuración de Apache2 para que las normas rewrite de

ownCloud funcionen.

$ sudo nano /etc/apache2/apache2.conf

Una vez allí se busca una sección llamada <directory /var/www/> en la que se sustituirá

AllowOverride None por AllowOverride All, pulsando la combinación de teclas Ctrl+x,

se guardará el archivo y se reiniciará Apache2 para que se carguen los cambios.

$ sudo service apache2 restart

Finalmente una vez se ha instalado el paquete se pasa a instalar Owncloud de la

siguiente forma:

$ cd /var/www/html

$ sudo wget https://download.owncloud.org/community/owncloud-8.1.3.tar.bz2

$ sudo tar -xjvf owncloud-81.3.tar.bz2

$ sudo rm owncloud-8.1.3.tar.bz2

Para acabar con la instalación se va a crear la base de datos de ownCloud. Primero, en

MySQL se introduce:

$ mysql -u root -p

Se crea la base de datos:

> CREATE DATABASE owncloud;

Se asigna la base de datos al usuario owncloud con la contraseña (pass) que queráis:

> GRANT ALL ON owncloud.* TO 'owncloud'@'localhost' IDENTIFIED BY 'pass';

Por último se sale de la aplicación con quit.

Ya se puede entrar en Owncloud a través del navegador (http://host/owncloud) haciendo

uso de la cuenta en la que se podrá cambiar el directorio distinto al que se indica por

omisión; de la siguiente forma:

http://es.wikipedia.org/wiki/GNU/Linux

http://es.wikipedia.org/wiki/Sistema_operativo

http://es.wikipedia.org/wiki/Servidor_HTTP_Apache

http://es.wikipedia.org/wiki/MySQL

http://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_bases_de_datos

http://es.wikipedia.org/wiki/PHP

154


$ sudo chown -R www-data:www-data/ruta/al/directorio/de/datos/de/owncloud

Más ajustes 14.2.4

Se necesita configurar php para que admita archivos grandes. Se puede hacer a través

del terminal editando los archivos. /etc/php5/apache2/php.ini /etc/php5/cli/php.ini pero

es más cómodo y seguro hacerlo a través del módulo de webmin.

Para instalar webmin, en http://webmin.com, se descarga el instalador con el comando

wget. En el momento actual la última versión es la 1.650

wget

http://switch.dl.sourceforge.net/project/webadmin/webmin/1.710/webmin_1.710_all.deb

Se instalan algunos paquetes necesarios:

sudo apt-get install perl libnet-ssleay-perl openssl libauthen-pam-perl libpam-

runtime libio-pty-perl apt-show-versions python

Se instalan webmin y se borra el paquete.

sudodpkg -i webmin_1.710_all.debsudo rm webmin_1.710_all.deb

Ahora ya se puede acceder al interface de webmin a través del navegador, en la

dirección

https://ipservidor:10000 (si accedemos desde el propio servidor https://localhost:10000).

Se introduce el usuario y password y ya se está dentro.

En el menú otros, se selecciona PHP Configuration: enlace Manage, y después en

Resource Limits se modifica cada uno de los ficheros para que quede así.

Fig. 14.10: Modificación de Resource limits

http://webmin.com/

https://localhost:10000/

http://i2.wp.com/www.pacorabadan.com/wp-content/uploads/2013/08/phpconf2.jpg

155


Como maximum memory allocation, se recomienda poner una cuarta parte de la ram del

servidor.

Ajustes del .htaccess 14.2.5

Se abre el .htaccess de Owncloud con el siguiente comando:

sudo nano /var/www/html/owncloud/.htaccess

Se modifican las siguientes líneas:

php_value upload_max_filesize 513Mphp_value post_max_size 513Mphp_value

memory_limit 512M

Para que queden como los valores que se modificaron en php.

php_value upload_max_filesize 20000Mphp_value post_max_size 20000Mphp_value

memory_limit 2048M

Por último se reinicia apache:

sudo service apache2 restart

14.3 Servicio de mensajería instantánea

Uno de los servicios que es necesario implementar es el servicio de mensajería

instantánea. Mediante este servicio, disponible en la web del evento, los moderadores

podrán comunicarse con los usuarios de la LPP, para poder asistirles o para notificarles

sobre cualquier suceso importante.

A este chat solamente pueden acceder usuarios registrados de la LPP, así como los

moderadores. En todo momento, debe haber un moderador conectado al chat, como

método de prevención.

El chat ha sido creado mediante la web chatango.com, y su aspecto es el siguiente:

156


Fig. 14.11: Chat de la página web de la LPP

Los moderadores han de tener el avatar con la letra “M” para que se les identifique

adecuadamente, como vemos en la imagen.

Los usuarios publican y reciben los mensajes en el chat mediante el protocolo TCP y

el tráfico medio generado no supera los 50 kbits/s, con picos de 100 kbits/s como

máximo, como podemos ver en esta gráfica.

Fig. 14.12: Tráfico TCP generado por uso del chat

14.4 Facebook

Para publicitar la LPP, se decide crear un evento en Facebook. En este evento se

publicará toda la información necesaria para los participantes, del mismo modo que en

Twitter. A continuación, se muestra una captura del evento creado.

157


Fig. 14.13: Perfil de Facebook de la LPP

14.5 Twitter

Además de Facebook, se decide crear un Twitter para publicitar el evento, pues

Twitter es también una plataforma muy directa y extendida entre el público objetivo. A

continuación, se muestra una captura del Twitter creado.

Fig. 14.14: Perfil de Twitter de la LPP

158


14.6 Página web

A continuación se describe otro servicio que se ha incluido en la LAN Party Piloto,

la construcción de una página web que aloje toda la información sobre el evento. Esta

web permitirá que los asistentes se inscriban en los torneos que lo deseen así como

consultar el horario y los ganadores de cada competición.

Puesto que se desea que la página web esté disponible días antes de la LAN Party se

ha decidido alojarla en un servidor externo, puesto que si se alojara en un servidor web

interno dentro de la zona principal, esto es, en el laboratorio 3.4 sólo estaría activa el día

que tiene lugar el evento. Por este motivo, se alojará en el servidor de la herramienta

que se emplee para construir la página web.

Para la construcción de la página web se ha utilizado la herramienta “wix”, que

consiste en una aplicación online de creación de páginas web. En primer lugar, es

necesario darse de alta con un usuario y contraseña y a continuación escoger el dominio

deseado. Para que la URL de la página web sea lo más descriptiva posible se ha

escogido el siguiente dominio: www.lanpartypiloto.wix.com/lpp-etsiit. Es fácil saber a

partir de la URL que la página web estará alojada en un servidor externo propiedad de

“wix”.

Respecto al diseño de la página web, se han creado siete pestañas: inicio, inscripción,

calendario, torneos, servicios, más información y contacto. En todas ellas se detallan las

últimas noticias sobre el evento, el reglamento y normas que deben cumplirse en la

duración del mismo y alguna información adicional que será útil para los participantes.

Inicio. En esta primera página se muestra una breve introducción a las LAN

Parties y en concreto a la que se desarrollará en este proyecto. Esta información

puede resultar de ayuda para aquellos visitantes que estén introduciéndose en el

mundo de las LAN Parties y por tanto necesiten cierta información básica para

decidir si se apuntarán o no al evento. Además es posible ver los videojuegos en

los que se competirá en la LPP así como la implementación de un servicio de

mensajería instantánea para que los usuarios del evento puedan comunicarse

fácilmente entre ellos y con usuarios que no han podido asistir al evento.

Inscripción. En esta segunda pestaña se pretende facilitar a los usuarios la

inscripción al evento, siempre de forma gratuita. Para ello, se indica la forma en

la que deben apuntarse y los requisitos que deben cumplir para que su

inscripción se complete con éxito. Por último, al final de la página se puede ver

el formulario en el que deben inscribirse los participantes. En él, deben indicarse

ciertos campos obligatorios como el torneo al que deben apuntarse, el nombre

completo, e-mail y usuario de Twitter y/o Facebook para que a través de las

redes sociales pueda seguirse el evento y convocar a los participantes. Además

se incluye un campo opcional “Observaciones” para que los usuarios indiquen si

tienen algún problema o incompatibilidad horaria con actividades externas a la

LAN Party Piloto.

http://www.lanpartypiloto.wix.com/lpp-etsiit

159


Calendario. A continuación se muestra un horario en el que se indican las

diferentes fases de cada torneo y la hora en la que se desarrollarán. Al final de la

página se vuelve a incorporar un botón que llevará al usuario a la pestaña de

inscripción en caso de que lo desee.

Torneos. Esta pestaña del menú se divide a su vez en un sub menú que incluye

cada uno de los juegos, describiendo brevemente en qué consisten y cómo se

desarrollarán los torneos. Además, se incluye una pestaña en este sub menú que

permitirá a los usuarios ver la clasificación a tiempo real.

Servicios. En esta pestaña se incluyen los servicios adicionales explicados en

este mismo apartado, tales como el servicio de mensajería instantánea o de

intercambio de información OwnCloud. Es necesario destacar que estos

servicios sólo podrán disfrutarlos aquellos usuarios que estén registrados en la

página web.

Más información. En esta pestaña el usuario podrá consultar las bases y reglas

de los torneos y de asistencia al evento.

Contacto. Por último, el usuario podrá ponerse en contacto con los

organizadores en caso de tener cualquier pregunta, problema o queja. Además,

se indica la localización exacta del evento y un correo electrónico y teléfono de

contacto.

160


Anexos 15

15.1 Comandos para el direccionamiento IP estáticos

SERVIDOR counter strike

VPCS>ip 192.168.20.3/24

VPCS>save Servidor_Counter

SERVIDOR minecraft

VPCS>ip 192.168.40.3/24

VPCS>save Servidor_Minecraft

SERVIDOR Team Fortress

VPCS>ip 192.168.50.3/24

VPCS>save Servidor_Team_Fortress

CÁMARA 1

C1> ip 192.168.70.1/24

C1> save C1

CÁMARA 2

C2> ip 192.168.70.2/24

C2> save C2

CÁMARA 3

C3> ip 192.168.70.3/24

C3> save C3

CÁMARA 4

C4> ip 192.168.70.4/24

C4> save C4

CÁMARA 5

C5> ip 192.168.70.5/24

C5> save C5

Direcciones IP estáticas de los equipos de gestión. En realidad, se tendrá que ir a la

parte de redes en panel de control y asignar las direcciones de forma estática.

G1> ip 192.168.110.1 255.255.255.0

G1> save G1

G2> ip 192.168.110.2 255.255.255.0

G2> save G2

G3> ip 192.168.110.3 255.255.255.0

G3> save G3

G4> ip 192.168.110.4 255.255.255.0

G4> save G4

161


15.2 Comandos para configuración de VLANs y troncales

Laboratorio 3.5

Switch 3

SW3#configure terminal

SW3(config)# vlan 20

SW3(config-vlan)#exit







SW3(config)#interface fastEthernet 0/1

SW3(config-if)# switchport access vlan 30

SW3(config-if)#exit



SW3(config-if)#exit



SW3(config-if)#exit



SW3(config-if)#exit



SW3(config-if)#exit



SW3(config-if)#exit



SW3(config-if)#exit


SW3(config)# interface fastEthernet 0/11

SW3(config-if)# switchport mode trunk

SW3(config-if)#exit



SW3(config-if)#exit

Switch 2




162










SW2(config-if)#exit



SW2(config-if)#exit



SW2(config-if)#exit



SW2(config-if)#exit



SW2(config-if)#exit



SW2(config-if)#exit



SW2(config-if)#exit



SW2(config-if)#exit

SW2(config)#exit




SW2(config-if)#exit



SW2(config-if)#exit

Switch 1










163




SW1(config-if)#exit



SW1(config-if)#exit



SW1(config-if)#exit



SW1(config-if)#exit



SW1(config-if)#exit



SW1(config-if)#exit



SW1(config-if)#exit



SW1(config-if)#exit




SW1(config-if)#exit



SW1(config-if)#exit

Laboratorio 3.3

Switch 6












SW6(config-if)#exit



164


SW6(config-if)#exit



SW6(config-if)#exit



SW6(config-if)#exit



SW6(config-if)#exit



SW6(config-if)#exit



SW6(config-if)#exit




SW6(config-if)#exit



SW6(config-if)#exit

Switch 5












SW5(config-if)#exit



SW5(config-if)#exit



SW5(config-if)#exit



SW5(config-if)#exit



165


SW5(config-if)#exit



SW5(config-if)#exit



SW5(config-if)#exit



SW5(config-if)#exit

SW5(config)#exit




SW5(config-if)#exit



SW5(config-if)#exit

Switch 4












SW4(config-if)#exit



SW4(config-if)#exit



SW4(config-if)#exit



SW4(config-if)#exit



SW4(config-if)#exit



SW4(config-if)#exit

166




SW4(config-if)#exit



SW4(config-if)#exit




SW4(config-if)#exit



SW4(config-if)#exit

Laboratorio 3.4

Switch 7








SW7(config-if)#exit



SW7(config-if)#exit




SW7(config-if)#exit



SW7(config-if)#exit

Switch 8










167




SW8(config-if)#exit



SW8(config-if)#exit



SW8(config-if)#exit




SW8(config-if)#exit



SW8(config-if)#exit

Switch Multilayer

SWMultilayer#configure terminal

SWMultilayer(config)#vlan 10

SWMultilayer(config-vlan)#exit

















SWMultilayer(config)# interface fastEthernet 0/1

SWMultilayer(config-if)# switchport mode trunk

SWMultilayer(config-if)#exit










168







































SWMultilayer(config-if)# switchport access vlan 1








SWMultilayer(config)#exit

Se asignan a los switches una dirección IP en la VLAN 110:

169


SW 1


SW1(config)# interface vlan 110

SW1(config-if)# ip address 192.168.110.1 255.255.255.0

SW1(config-if)#exit

SW 2




SW2(config-if)#exit

SW 3




SW3(config-if)#exit

SW 4




SW4(config-if)#exit

SW 5




SW5(config-if)#exit

SW 6




SW6(config-if)#exit

SW 7




SW7(config-if)#exit

SW 8




SW8(config-if)#exit


SWMultilayer (config) # interface vlan 110

170


SWMultilayer (config-if)# ip address 192.168.110.10 255.255.255.0

15.3 Configuración de balanceo de carga

Switch Multilayer


SWMultilayer(config)#interface fastEthernet 0/1

SWMultilayer(config-if)#spanning-tree vlan 70 port priority 64









































171















15.4 Configuración DHCP

Switch Multilayer


SWMultilayer(config)# int Vlan10

SWMultilayer (config-if)#ip addr 192.168.10.1 255.255.255.0

SWMultilayer (config-if)#exit
















SWMultilayer (config)#ip dhcp pool Vlan10

SWMultilayer (dhcp-config)#network 192.168.10.0 255.255.255.0

SWMultilayer (dhcp-config)#default-router 192.168.10.2

SWMultilayer (dhcp-config)#exit










172













SWMultilayer (config)#ip dhcp excluded-address 192.168.10.1 192.168.10.10







SWMultilayer (config)#service dhcp

SWMultilayer (config)#exit

%Comprueba las asignaciones DHCP que hace el multilayer

SWMultilayer#show ip dhcp binding

15.5 Configuración NAT

Switch Multilayer

SWMultilayer #configure terminal

SWMultilayer (config)# interface fastEthernet 0/0

SWMultilayer (config-if)# ip nat inside

SWMultilayer (config-if)# exit

SWMultilayer (config)# interface fastEthernet 1/0

SWMultilayer (config-if)# ip nat outside

SWMultilayer (config-if)# exit

SWMultilayer (config)# ip nat pool PUBLICO <direccion publica> netmask <mascara

publica>

SWMultilayer (config)# access-list 1 permit 192.168.0.0 0.0.255.255

SWMultilayer (config)# ip nat inside source list 1 pool PUBLICO

SWMultilayer (config)# exit

SWMultilayer# show ip nat translation % %para comprobar tablas de traduccion nat

realizadas

173


15.6 Configuración NTP

Switch Multilayer

SWMultilayer # configure terminal

SWMultilayer (config)# ntp server hora.rediris.es

SWMultilayer (config) exit

SWMultilayer#show clock %%para comprobar hora

15.7 Configuración para control de tormentas de broadcast

En cada switch:

Switch# configure terminal

Switch (config-if)# interface fastEthernet XX (repetir en todas las interfaces)

Switch (config-if)# storm-control broadcast level 60

Switch (config-if)# storm-control action trap

15.8 Configuración para seguridad por MAC

En cada switch:

Switch# configure terminal

Switch (config-if)# interface fastEthernet XX (repetir en todas las interfaces donde haya

usuarios)

Switch (config-if)# switchport mode access

Switch (config-if)# switchport port-security

Switch (config-if)# switchport port-security maximum (número de MACs)

Switch (config-if)# switchport port-security violation restrict

Switch (config-if)# switchport port-security mac-address sticky

% Si es necesario asignar las MACs de forma dinámica.

switchport port-security aging {static | time time | type {absolute | inactivity}}

15.9 Configuración de listas de acceso

DMZ (VLAN 100) Access-List 109 Servidor Owncloud

Router(config)# access-list 109 permit ip 192.168.0.0 0.0.255.255 192.168.100.0

0.0.0.255

Router(config)# access-list 109 permit ip 192.168.100.0 0.0.0.255 192.168.0.0

0.0.255.255

Router(config-if)# int fastEthernet 0/2 (interfaz conectada al servidor)

Router(config-if)# ip access-group 109 in

102) VLAN10Hearthstone

SWM# configure terminal

174


SWM(config)# access-list 102 permit tcp 192.168.10.0 0.0.0.255 192.168.10.0

0.0.0.255

SWM(config)#access-list 102 permit udp 192.168.10.0 0.0.0.255 192.168.10.0

0.0.0.255

SWM(config)#access-list 102 permit ip 192.168.100.3 0.0.0.255 192.168.10.0 0.0.0.255




SWM(config)# access-list 102 deny ip 192.168.20.0 0.0.0.255 192.168.0.0 0.0.255.255

SWM(config)# access-list 102 permit ip any any (para el acceso a internet)

SWM(config)# interface VLAN10

SWM(config-if)# ip Access-group 102 in

SWM(config-if)# exit

103) VLAN20 Counter Strike



0.0.0.255

SWM(config)# access-list 103 permit udp 192.168.20.0 0.0.0.255 192.168.20.0

0.0.0.255

SWM(config)# Access-list 103 permit ip 192.168.20.0 0.0.0.255

(dirección_servidor_owncl)







SWM(config-if)# ip access-group 103 in


104) VLAN30League of Legends



0.0.0.255


0.0.0.255

SWM(config)# Access-list 104 permit ip 192.168.30.0 0.0.0.255 192.168.100.0

0.0.0.255








175



105) VLAN40 Minecraft



0.0.0.255


0.0.0.255


0.0.0.255






SWM(config)# interface Vlan40



106) VLAN50Team Fortress 2



0.0.0.255


0.0.0.255


0.0.0.255









107) VLAN60 Street Fighter y FIFA



0.0.0.255


0.0.0.255


0.0.0.255



176








108) VLAN70 Sistema de videovigilancia


SWM(config)# access-list 108 permit ip 192.168.0.0 0.0.255.255 192.168.0.0

0.0.255.255




101) VLAN110 Gestión



0.0.0.255


0.0.0.255




15.10 Configuración de calidad de servicio QoS:

Switch1:

SW1> R>enable


SW1 (config)# access

SW1 (config)#! Team Fortress 2

SW1 (config)# access-list 120 deny ip 192.168.50.0 0.0.0.255 any eq 23


SW1 (config)# access-list 120 permit tcp any any

SW1 (config)# access-list 120 permit udp any any

SW1 (config)# interface range FastEthernet 0/1-0/5

SW1 (config-if)# rate-limit output access-group 125 1000000 1500000 2000000

conform-action set-prec-transmit 5 exceed-action drop

SW1 (config-if)#exit

SW1 (config)#! # Minecraft



SW1 (config)# access-list 121 permit tcp any any eq 25565


177









Switch2:

SW2> R>enable



SW2 (config)#! Hearthstone






R(config-if)# rate-limit output access-group 120 1000000 1500000 2000000 conform-

action set-prec-transmit (QoS para el Hearthstone) exceed-action drop

R(config-if)#exit

SW2 (config)#! Counter Strike









Switch3:

SW3> R>enable



SW3 (config)#! LOL













178



SW3 (config)# interface FastEthernet 0/6




Switch4:

SW4> R>enable



SW4 (config)#! Team Fortress 2









SW4 (config)#! # Minecraft

SW4 (config)# access-list 121 permit tcp any any eq 25565











Switch5:

SW5> R>enable



SW5 (config)#! Hearthstone






R(config-if)# rate-limit output access-group 120 1000000 1500000 2000000 conform-

action set-prec-transmit (QoS para el Hearthstone) exceed-action drop

R(config-if)#exit



179







Switch6:

SW6> R>enable



SW6 (config)#! LOL












SW6 (config)# interface FastEthernet 0/6




180


15.11 Configuración del servidor Minecraft

La estructura básica para la configuración de un servidor de Minecraft se muestra a

continuación:

#Minecraft server properties

#Mon Jan 11 17:44:02 CET 2016

spawn-protection=16

max-tick-time=60000

generator-settings=

force-gamemode=false

allow-nether=true

gamemode=0

enable-query=false

player-idle-timeout=0

difficulty=1

spawn-monsters=true

op-permission-level=4

resource-pack-hash=

announce-player-achievements=true

pvp=true

snooper-enabled=true

level-type=DEFAULT

hardcore=false

enable-command-block=false

max-players=20

network-compression-threshold=256

max-world-size=29999984

server-port=25565

server-ip=

spawn-npcs=true

allow-flight=false

level-name=world

view-distance=10

resource-pack=

spawn-animals=true

white-list=false

generate-structures=true

online-mode=false

max-build-height=256

level-seed=

motd=A Minecraft Server

enable-rcon=false

Además, los parámetros específicos que se pueden utilizar para una configuración

muy exhaustiva se muestran también a continuación:

181


Código Tipo Valor por

defecto Descripción

allow-flight Boolean false

Permite que los usuarios puedan volar en tu

servidor de supervivencia si tienen

una modificación que les permita hacerlo.

Con allow-flight activado, puede haber

más griefers, ya que hacer su trabajo les

resultará más fácil. Es inútil en modo creativo.

false: No está permitido volar (los jugadores

que estén más de 5 segundos en el aire serán

expulsados).

true: Está permitido volar si el jugador tiene la

modificación instalada.

allow-nether Boolean true

Permite que los jugadores puedan viajar

el Inframundo.

false: Los portales al Inframundo no

funcionarán.

true: Los portales al Inframundo sí

funcionarán.

announce-

player-

achievements

Boolean true Muestra en el servidor los logros adquiridos

por un jugador.

difficulty Integer

(0-3) 1

Define la dificultad (daño causado por

criaturas hostiles, hambre y efecto de

pociones) del servidor.

0: Pacifico

1: Fácil

2: Normal

3: Difícil

enable-query Boolean false

Activa el protocolo de servidor GameSpy4.

Empleado para obtener información acerca del

servidor.

enable-rcon Boolean false Activa y desactiva el acceso remoto a la

consola del servidor.

enable-

command-

block

Boolean false Activa y desactiva los bloques de comandos.

force-

gamemode Boolean false

Obliga a los jugadores a unirse al modo de

juego predeterminado.

false: Los jugadores se unirán al modo de

182


juego en el que se salen.

true: Los jugadores se unirán siempre al modo

de juego predeterminado.

gamemode Integer

(0-3) 0

Define el modo de juego.

0: Supervivencia

1: Creativo

2: Aventura

3: Espectador

generate-

structures Boolean true

Define la generación de estructuras (como

aldeas).

false: No se generarán estructuras.

true: Se generarán estructuras.

Note: Las mazmorras y fortalezas del

Inframundo no dejarán de generarse bajo

ningún concepto.

generator-

settings String blank Se generará un terreno extraplano.

hardcore Boolean false

Simula el modo extremo. Si se establece

en true, se prohibirá la entrada a los jugadores

que mueran.

level-name String world

El valor "level-name" se emplea como nombre

del mundo y de la carpeta. Puedes copiar la

carpeta de una partida guardada y cambiar el

nombre al de una cargada en su lugar.

Algunos caracteres, como el apóstrofo ('), se

deben acompañar de una barra invertida (\).

level-seed String blank

Añade una semilla generadora a tu mundo,

como en un jugador.

Algunos ejemplo son: minecraft, 404, 1a2b3c.

level-type String DEFA

ULT

Determina el tipo de mapa generado.

DEFAULT: Mundo estándar, con colinas,

agua, etc.

FLAT: Mundo plano. Pensado para la

construcción.

LARGEBIOMES: Mundo estándar, con

biomas más grandes.

AMPLIFIED: Mundo estándar, con terrenos

más altos.

183


CUSTOMIZED: Desde la snapshot 14w21b,

los servidores son compatibles con terrenos

personalizados. Primero hay que generar un

mundo personalizado en un jugador y copiarlo

al servidor.

max-build-

height Integer 256

Altura máxima a la que se permite construir.

El terreno puede crecer hasta el máximo de

altura.

max-players

Integer

(0-

2147483647)

20

Número máximo de jugadores que pueden

entrar al servidor al mismo tiempo. Cuantos

más jugadores haya, más recursos se

consumirán. Los administradores no cuentan,

pero un administrador no puede entrar a un

servidor lleno. Si se establece un valor muy

elevado, el cliente del juego puede colgarse.

max-tick-time

Integer

(0–(2^63 -

1))

60000

Número máximo de milisegundos en un solo

tick antes de que el servidor se detenga con un

mensaje, Un solo tick ha tardado 60 segundos

(máximo: 0,05). Al considerar que se haya

colgado, el servidor se apagará

automáticamente. A esta medida se le llama

System.exit(1).

-1: desactiva dicha medida (la opción de

desactivarla se añadió en 14w32a)

max-world-

size

Integer

(1-

29999984)

299999

84

Esto establece el tamaño máximo posible del

borde del mundo en bloques, expresado en un

radio. Al agrandar el borde del mundo, los

comandos se completarán con éxito, pero el

borde no se moverá. Al aumentar el max-

world-size, no parece que haga nada.

Ejemplos:

Estableciendo max-world-size en 1000 te

permitirá tener un borde del mundo de 2000 x

2000.

Estableciendo max-world-size en 4000 te

proporcionará un borde del mundo de 8000 x

8000.

motd String

Un

servidor de

Minecraft

en español

MOTD, por sus siglas en inglés "Message of

the day", en español "Mensaje del día".

Este es el mensaje que mostrará el servidor en

la lista del cliente, bajo el nombre.

El MOTD es compatible con códigos de color

y formato.

Si el MOTD tiene más de 59 caracteres, la

184


lista de servidores dará error de comunicación.

network-

compression-

threshold

Integer 256

By default it allows packets that are n-1 bytes

big to go normally, but a packet that n bytes or

more will be compressed down. So, lower

number means more compression but

compressing small amounts of bytes might

actually end up with a larger result than what

went in.

-1: Desactiva completamente la compresión

0: Comprime todo

Nota: Los requisitos de Ethernet incluye que

los paquetes menores de 64 bytes se

conviertan a 64 bytes, por lo que no es

recomendable establecer un valor menor a 64

bytes. Tampoco es recomendable superar el

límite de 1.500 bytes.

online-mode Boolean true

El servidor comprueba desde la base de datos

de Minecraft las cuentas de los jugadores que

se conectan. Establécelo en false si tu

servidor no está conectado a Internet. ¡Los

piratas con cuentas falsas podrán conectarse si

está en false! Si minecraft.net está caído o

inaccesible, nadie podrá conectarse si está

en true. Desactivar esta propiedad se

consider crackear el servidor, ya que permite

entrar a gente con copias de Minecraft.

true: Activado. El servidor comprueba la

conexión a Internet y la cuenta de cada

jugador.

false Desactivado. El servidor no comprueba la

conexión a Internet ni la cuenta de los

jugadores.

op-

permission-

level

Integer

(1-4) 4

Establece los niveles de permiso de

administración.

1: Los administradores pueden violar la

protección de aparición.

2: Los administradores pueden usar los

comandos /clear, /difficulty, /effect,

/gamemode, /gamerule, /give, y /tp, así como

editar bloques.

3: Los administradores pueden usar los

comandos /ban, /deop, /kick, y /op.

4: Los administradores pueden usar el

185


comando /stop.

player-idle-

timeout Integer 0

Si no es cero, los jugadores serán expulsados

del servidor si están ausentes durante unos

minutos.

Note: El tiempo de ausente se reinicia al

detectar alguno de los siguientes movimientos:

102 (0x66) WindowClick (clic en la

ventana)

108 (0x6c) ButtonClick (pulsación de un

botón)

130 (0x82) UpdateSign ()

14 (0xe) BlockDig (picar un bloque)

15 (0xf) Place (colocar un bloque)

16 (0x10) BlockItemSwitch (cambiar de

objeto/arma)

18 (0x12) ArmAnimation (animación de

los brazos)

19 (0x13) EntityAction (acción de entidad)

205 (0xcd) ClientCommand (comando del

cliente)

3 (0x3) Chat (usar el chat)

7 (0x7) UseEntity (utilizar entidad)

pvp Boolean true

Activa el PvP (jugador contra jugador) en el

servidor. Las flechas entre jugadores solo

harán daño si el PvP está activado.

true: Los jugadores podrán matarse entre ellos.

false: Los jugadores solo podrán matar

criaturas (conocido como PvE (jugador contra

la máquina).

Nota: Las fuentes de daño indirectas

generadas por jugadores

(como lava, fuego, TNT o agua, arena y grava)

podrá causar la muerte a otro jugador.

query.port Integer

(1-65534) 25565

Establece el puerto del servidor (véase enable-

query).

rcon.password String blank Establece la contraseña del rcon.

rcon.port Integer

(1-65534) 25575 Establece el puerto del rcon.

186


resource-pack String blank

resource-

pack-hash String blank

server-ip String blank

Con esto puede proporcionar una IP particular

a tu servidor. ¡Se recomienda dejar esta opción

en blanco si no controlas del tema!

server-port Integer

(1-65534) 25565

Cambia el puerto en el que se ejecuta el

servidor. Este puerto será remitido si el

servidor se ejecuta en otra red utilizando NAT.

snooper-

enabled Boolean true

Permite que el servidor registre y envía

regularmente los datos

a http://snoop.minecraft.net o no.

false: Desactiva el registro.

true: Activa el registro.

spawn-

animals Boolean true

Determina si habrá animales.

true: Habrá animales.

false: Los animales desaparecerán

inmediatamente.

Consejo: si el servidor tiene poco rendimiento,

es aconsejable desactivar esta opción.

spawn-

monsters Boolean true

Determina si habrá monstruos.

true: Habrá monstruos. Aparecerán por la

noche y en zonas oscuras.

false No habrá monstruos.

Si la dificultad es 0 (pacífico) no habrá

monstruos. Consejo: si el servidor tiene poco

rendimiento, es aconsejable desactivar esta

opción.

spawn-npcs Boolean true

Determina si habrá aldeanos.

true: Habrá aldeanos.

false: No habrá aldeanos.

spawn-

protection Integer 16

Determina el radio de la protección de

aparición. Si establecemos 0 no habrá. El 0 tan

solo protegerá el bloque sobre el que

aparecemos. El 1 protegerá una zona de 3x3,

manteniendo el centro sobre el punto en el que

aparecemos. El 2 lo hará en una zona de 5x5,

el 3 de 7x7, etc. Esta opción se genera cuando

se une el primer jugador al servidor. Si no

hay administradores, la protección estará

187


desactivada.

view-distance Integer

(3-15) 10

Establece la cantidad de datos del mundo que

el servidor envía al cliente, calculado en

chunks en cada dirección del jugador (en radio,

no en diámetro). Determina la distancia de

visión del servidor. La distancia "Lejos" es de

16 chunks, enviando 1089 chunks en total

(dicha cantidad aparece en los datos de F3). La

distancia "Normal" es 8, con 289 chunks.

10 es el valor predeterminado y recomendad.

Si tienes poco rendimiento, redúcelo.

white-list Boolean false

Activa una lista de permitidos en el servidor.

Con una lista de permitidos activada, solo

podrán unirse aquellos jugadores que estén

añadidos. Está pretendido para servidores

privados, de amigos o comunidades cerradas.

false: Sin lista de permitidos.

true: Se usa el archivo white-list.txt para

generarla.

Nota: Los administradores están en la lista

automáticamente, no es necesario añadirlos.

15.12 Comandos para configurar SNMP

Configuración de la estación gestora para las Traps 15.12.1

1) Ruta para poner la MIB:

/usr/share/snmp/mibs

2) Activar servicio snmptrapd para las traps para que vayan al archivo de log:

snmptrapd -Lf logs/file.txt -m ALL

3) Activar terminal que actualice automáticamente fichero de log (Abrir en un nuevo

terminal):

tail -500f logs/file.txt

Comandos auxiliaries 15.12.2

1) Parar servicio snmptrapd:

service snmptrapd stop

188


2) Snmpget ejemplo:

snmpget -v 2c -c CCOm 172.16.3.100 system.sysDescr.0

3) Snmpset ejemplo:

snmpset -v 2c -c COM2 172.16.3.101 system.sysDescr.0 s holicaracoli

4) Ver si se está ejecutando el proceso snmptrapd:

ps -ef | grep snmptrapd

Configuración de los dispositivos gestionados (Switches) 15.12.3

Para poner en cada Switch

R1>enable

R1#configure terminal

R1(config)#snmp-server community public ro 1

R1(config)#snmp-server enable traps

R1(config)#snmp-server host (Ip del equipo de gestión) version 2c COM1

15.13 Configuración de Port Mirroring

SwitchMultilayer 1>enable

SwitchMultilayer 1#configure terminal

SwitchMultilayer(config)#monitor session 1 source interface fastEthernet 1/1

SwitchMultilayer (config)#monitor session 1 source interface fastEthernet 1/2















SwitchMultilayer (config)#monitor session 1 destination interface fastEthernet 1/17

lpp trabajo final - WordPress.com · 2016-04-10 · 2 Historia de las LAN Party. En primer lugar,...

Documents

Transcript of lpp trabajo final - WordPress.com · 2016-04-10 · 2 Historia de las LAN Party. En primer lugar,...