lpp trabajo final - wordpress.com · 2016-04-10 · 2 historia de las lan party. en primer lugar,...
TRANSCRIPT
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
Fig. 5.2. Plano de la Zona Secundaria 1.
Fig. 5.3. Plano de la Zona Secundaria 2.
22
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
5.2 Segunda propuesta de diseño de red
Esta propuesta se basa en utilizar tres 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 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).
En cuanto al nivel de distribución, se propone utilizar dos cables troncales de uplink
por cada switch de acceso. Por tanto, se necesitan 12 cables troncales de uplink en total.
Esto significa que 12 de los 24 puertos del switch multilayer de distribución van a estar
ocupados de forma que solamente doce puertos quedan libres para conexión con los
servidores, equipos de monitorización y acceso a Internet.
Con esta propuesta se pueden albergar 22 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
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
LPP v1.0 DOCUMENTO FINAL
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).
En cuanto al número de puertos utilizados en los distintos equipos, se puede ver en la
tabla 5.3 que en los switches de acceso hay suficientes puertos de reserva disponibles
(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
LPP v1.0 DOCUMENTO FINAL
Tabla 5.4. Cables necesarios y longitud total de cable.
5.3 Tercera propuesta de diseño de red
Esta propuesta se basa en utilizar tres 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 situar los tres switches en la parte intermedia de la columna de bancas central.
En cuanto al nivel de distribución, se propone utilizar dos cables troncales de uplink
por cada switch de acceso. Por tanto, se necesitan 12 cables troncales de uplink en total.
Esto significa que 12 de los 24 puertos del switch multilayer de distribución van a estar
ocupados, de forma que 12 puertos quedan libres para conexión con los servidores,
equipos de monitorización y acceso a Internet.
Con esta propuesta se pueden albergar 24 puestos de usuario en la Zona Secundaria 1
(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
LPP v1.0 DOCUMENTO FINAL
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.
En cuanto al número de puertos utilizados en los distintos equipos, se puede ver en la
tabla 5.5 que en los switches de acceso hay suficientes puertos de reserva disponibles
(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
LPP v1.0 DOCUMENTO FINAL
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
Tabla 5.6. Cables necesarios y longitud total de cable.
29
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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.
33
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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)
Cámara IP FE 07 SW3_07-C4 (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
LPP v1.0 DOCUMENTO FINAL
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)
Cámara IP FE 09 SW4_09-C2 (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)
Cámara IP FE 07 SW6_07-C1 (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
LPP v1.0 DOCUMENTO FINAL
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)
Cámara IP FE 04 SW8_04-C3 (2 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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
Fig. 6.5. Distribución por VLANs del laboratorio 3.5.
Fig. 6.6. Distribución por VLANs del laboratorio 3.3.
46
LPP v1.0 DOCUMENTO FINAL
Fig. 6.7. Distribución por VLANs del laboratorio 3.4.
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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.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.40.3/24 y la de los hosts puede ser cualquiera a partir de
192.168.40.4/24.
VLAN 50 Team Fortress La dirección IP de la interfaz (VLAN) es
192.168.50.1/24, la dirección IP de la puerta de enlace es la 192.168.50.2/24, la del
servidor es la 192.168.50.3/24 y la de los hosts puede ser cualquiera a partir de
192.168.50.4/24.
50
LPP v1.0 DOCUMENTO FINAL
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
Equipo de gestión G2 192.168.101.2 /24
Equipo de gestión G3 192.168.101.3 /24
Equipo de gestión G4 192.168.101.4 /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
LPP v1.0 DOCUMENTO FINAL
Fig. 6.8. Distribución por VLANs del laboratorio 3.5.
Fig. 6.9. Distribución por VLANs del laboratorio 3.3.
52
LPP v1.0 DOCUMENTO FINAL
Fig. 6.10. Distribución por VLANs del laboratorio 3.4.
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
Permitir el tráfico UDP
y TCP dentro de la
VLAN50 e IP. Acceso
a Internet
VLAN60 Street Fighter y Fifa 107
Permitir el tráfico UDP
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
Port Mirroring 8.1.2
8.1.2.1 Descripción
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.
8.1.2.2 Implementación
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
8.2.1.1 Descripción
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.
8.2.1.2 Implementación
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
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.4
(Zona Principal)
Servidor
(Ordenador portátil) 120 4 480
Equipo de monitorización
(Ordenador portátil) 120 2 240
Equipo de gestión
(Ordenador portátil) 120 2 240
Cámara IP 5 1 5
Switch multilayer WS-
C3550-24-SMI 525 1 525
Switch Catalyst 2950-12 575 2 1150
Bombilla de bajo consumo 18 4 72
Tubo fluorescente LED de
bajo consumo 24 8 192
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
G2. Desconexión 3.4
G3. Desconexión 3.5
H. Montaje 3.4
92
LPP v1.0 DOCUMENTO FINAL
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
Firma del encargado:
Notas:
93
LPP v1.0 DOCUMENTO FINAL
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
Responsables: 2 personas y un encargado
Validación: El encargado validará el montaje según los planos
Firma del encargado:
Notas:
Subtarea: B2. Montaje del laboratorio 3.5
Responsables: 2 personas y un encargado
Validación: El encargado validará el montaje según los planos
Firma del encargado:
Notas:
Subtarea: B3. Montaje del laboratorio 3.4
Responsables: 2 personas y un encargado
Validación: El encargado validará el montaje según los planos
Firma del encargado:
Notas:
94
LPP v1.0 DOCUMENTO FINAL
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
Responsables: 4 personas y un encargado
Validación: El encargado irá validando que las medidas se van haciendo
adecuadamente
Firma del encargado:
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
Firma del encargado:
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
Firma del encargado:
Notas:
95
LPP v1.0 DOCUMENTO FINAL
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
Responsables: 2 personas y un encargado
Validación: El encargado irá validando de acuerdo a las tablas de conexiones que
los montajes se han realizado correctamente
Firma del encargado:
Notas:
Subtarea: D2. Conexión del laboratorio 3.5
Responsables: 2 personas y un encargado
Validación: El encargado irá validando de acuerdo a las tablas de conexiones que
los montajes se han realizado correctamente
Firma del encargado:
Notas:
Subtarea: D3. Conexión del laboratorio 3.5
Responsables: 2 personas y un encargado
Validación: El encargado irá validando de acuerdo a las tablas de conexiones que
los montajes se han realizado correctamente
Firma del encargado:
Notas:
96
LPP v1.0 DOCUMENTO FINAL
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
Responsables: 4 personas y un encargado
Validación: El encargado validará mediante otro equipo de gestión que el montaje
se está realizando de acuerdo al proyecto
Firma del encargado:
Notas:
97
LPP v1.0 DOCUMENTO FINAL
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.
Responsables: 4 personas y un encargado
Validación: El encargado deberá ir constatando que las pruebas realizadas por los
4 responsables son correctas
Firma del encargado:
Notas: Se deben anotar las pruebas que se han llevado a cabo
98
LPP v1.0 DOCUMENTO FINAL
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
Responsables: 2 personas y un encargado
Validación: El encargado ha de comprobar que los cables se han almacenado
adecuadamente según las medidas
Firma del encargado:
Notas:
Subtarea: G2. Desconexión agrupación y almacenaje del laboratorio 3.4
Responsables: 2 personas y un encargado
Validación: El encargado ha de comprobar que los cables se han almacenado
adecuadamente según las medidas
Firma del encargado:
Notas:
Subtarea: G3. Desconexión agrupación y almacenaje del laboratorio 3.5
Responsables: 2 personas y un encargado
Validación: El encargado ha de comprobar que los cables se han almacenado
adecuadamente según las medidas
Firma del encargado:
Notas:
99
LPP v1.0 DOCUMENTO FINAL
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.
Responsables: 4 personas y un encargado
Validación: El encargado de certificar que el laboratorio se ha establecido según
los planos
Firma del encargado:
Notas:
100
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
Fig. 11.1. Diseño de la red.
102
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
Responsables: 2 personas y un encargado
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
Firma del encargado:
Notas:
107
LPP v1.0 DOCUMENTO FINAL
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
Responsables: 2 personas y un encargado
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
nat translation obtener la tabla de traducción de direcciones inside y outside
comprobando su correcto funcionamiento.
Firma del encargado:
Notas:
108
LPP v1.0 DOCUMENTO FINAL
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
Responsables: 2 personas y un encargado
Validación: Para ello, conectarse desde un equipo de gestión al switch
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.
Firma del encargado:
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
LPP v1.0 DOCUMENTO FINAL
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.
Responsables: 4 personas y un encargado
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.
Firma del encargado:
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
LPP v1.0 DOCUMENTO FINAL
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.
Firma del encargado:
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.
Firma del encargado:
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.
Firma del encargado:
Notas:
111
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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 3 D2 A1 y A2 5.50
Alumno 4 D3 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 8 B2 D3 y G2 5.50
Alumno 9 B3 D3 y G2 5.50
Alumno 10 G1 B1 y F 5.50
Alumno 11 G2 B2 y F 5.50
Alumno 12 G3 B2 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 22 - E y H 7.00
Alumno 23 - E y H 7.00
Alumno 24 - 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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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.
A. Reglas de torneos
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
LPP v1.0 DOCUMENTO FINAL
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.
129
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
A. Reglas de torneos
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.
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.
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
LPP v1.0 DOCUMENTO FINAL
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.
Entonces, el torneo consiste en fases eliminatorias: octavos, cuartos de final,
semifinal y final. De esta manera, la pareja ganadora 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.
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).
A. Reglas de torneos
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.
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.
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
LPP v1.0 DOCUMENTO FINAL
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.
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 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.
A. Reglas del torneo
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 el
nombre del equipo de 5 jugadores en el que va a participar.
133
LPP v1.0 DOCUMENTO FINAL
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.
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
LPP v1.0 DOCUMENTO FINAL
experimentar debido a la instalación del software. El software es gratuito y se encuentra
disponible en la plataforma Steam.
A. Reglas del torneo
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 el
nombre del equipo de 5 jugadores en 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.
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
- 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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
- 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
LPP v1.0 DOCUMENTO FINAL
Ú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
LPP v1.0 DOCUMENTO FINAL
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
Frecuencia de Evento: Aleatorio
Grado de Impacto: Moderado
Situación Actual Acción Correctiva
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 Negatividad: Grave
Frecuencia de Evento: Aleatorio
Grado de Impacto: Grave
142
LPP v1.0 DOCUMENTO FINAL
Situación Actual Acción Correctiva
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
Situación Actual Acción Correctiva
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
Grado de Impacto: Grave
143
LPP v1.0 DOCUMENTO FINAL
Situación Actual Acción Correctiva
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
Grado de Negatividad: Grave
Frecuencia de Evento: Aleatorio
Grado de Impacto: Grave
Situación Actual Acción Correctiva
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
Grado de Negatividad: Grave
Frecuencia de Evento: Aleatorio
Grado de Impacto: Grave
Situación Actual Acción Correctiva
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
153
LPP v1.0 DOCUMENTO FINAL
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:
154
LPP v1.0 DOCUMENTO FINAL
$ 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
155
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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.
159
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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)# vlan 30
SW3(config-vlan)#exit
SW3(config)# vlan 70
SW3(config-vlan)#exit
SW3(config)# vlan 110
SW3(config-vlan)#exit
SW3(config)#interface fastEthernet 0/1
SW3(config-if)# switchport access vlan 30
SW3(config-if)#exit
SW3(config)#interface fastEthernet 0/2
SW3(config-if)# switchport access vlan 30
SW3(config-if)#exit
SW3(config)#interface fastEthernet 0/3
SW3(config-if)# switchport access vlan 30
SW3(config-if)#exit
SW3(config)#interface fastEthernet 0/4
SW3(config-if)# switchport access vlan 30
SW3(config-if)#exit
SW3(config)#interface fastEthernet 0/5
SW3(config-if)# switchport access vlan 30
SW3(config-if)#exit
SW3(config)#interface fastEthernet 0/6
SW3(config-if)# switchport access vlan 20
SW3(config-if)#exit
SW3(config)#interface fastEthernet 0/7
SW3(config-if)# switchport access vlan 70
SW3(config-if)#exit
SW3#configure terminal
SW3(config)# interface fastEthernet 0/11
SW3(config-if)# switchport mode trunk
SW3(config-if)#exit
SW3(config)# interface fastEthernet 0/12
SW3(config-if)# switchport mode trunk
SW3(config-if)#exit
Switch 2
SW2#configure terminal
SW2(config)# vlan 10
SW2(config-vlan)#exit
162
LPP v1.0 DOCUMENTO FINAL
SW2(config)# vlan 20
SW2(config-vlan)#exit
SW2(config)# vlan 60
SW2(config-vlan)#exit
SW2(config)# vlan 110
SW2(config-vlan)#exit
SW2(config)#interface fastEthernet 0/1
SW2(config-if)# switchport access vlan 10
SW2(config-if)#exit
SW2(config)#interface fastEthernet 0/2
SW2(config-if)# switchport access vlan 10
SW2(config-if)#exit
SW2(config)#interface fastEthernet 0/3
SW2(config-if)# switchport access vlan 10
SW2(config-if)#exit
SW2(config)#interface fastEthernet 0/4
SW2(config-if)# switchport access vlan 60
SW2(config-if)#exit
SW2(config)#interface fastEthernet 0/5
SW2(config-if)# switchport access vlan 20
SW2(config-if)#exit
SW2(config)#interface fastEthernet 0/6
SW2(config-if)# switchport access vlan 20
SW2(config-if)#exit
SW2(config)#interface fastEthernet 0/7
SW2(config-if)# switchport access vlan 20
SW2(config-if)#exit
SW2(config)#interface fastEthernet 0/8
SW2(config-if)# switchport access vlan 20
SW2(config-if)#exit
SW2(config)#exit
SW2#configure terminal
SW2(config)# interface fastEthernet 0/11
SW2(config-if)# switchport mode trunk
SW2(config-if)#exit
SW2(config)# interface fastEthernet 0/12
SW2(config-if)# switchport mode trunk
SW2(config-if)#exit
Switch 1
SW1#configure terminal
SW1(config)# vlan 40
SW1(config-vlan)#exit
SW1(config)# vlan 50
SW1(config-vlan)#exit
SW1(config)# vlan 70
SW1(config-vlan)#exit
SW1(config)# vlan 110
SW1(config-vlan)#exit
163
LPP v1.0 DOCUMENTO FINAL
SW1(config)#interface fastEthernet 0/1
SW1(config-if)# switchport access vlan 50
SW1(config-if)#exit
SW1(config)#interface fastEthernet 0/2
SW1(config-if)# switchport access vlan 50
SW1(config-if)#exit
SW1(config)#interface fastEthernet 0/3
SW1(config-if)# switchport access vlan 50
SW1(config-if)#exit
SW1(config)#interface fastEthernet 0/4
SW1(config-if)# switchport access vlan 50
SW1(config-if)#exit
SW1(config)#interface fastEthernet 0/5
SW1(config-if)# switchport access vlan 50
SW1(config-if)#exit
SW1(config)#interface fastEthernet 0/7
SW1(config-if)# switchport access vlan 40
SW1(config-if)#exit
SW1(config)#interface fastEthernet 0/8
SW1(config-if)# switchport access vlan 40
SW1(config-if)#exit
SW1(config)#interface fastEthernet 0/9
SW1(config-if)# switchport access vlan 70
SW1(config-if)#exit
SW1#configure terminal
SW1(config)# interface fastEthernet 0/11
SW1(config-if)# switchport mode trunk
SW1(config-if)#exit
SW1(config)# interface fastEthernet 0/12
SW1(config-if)# switchport mode trunk
SW1(config-if)#exit
Laboratorio 3.3
Switch 6
SW6#configure terminal
SW6(config)# vlan 20
SW6(config-vlan)#exit
SW6(config)# vlan 30
SW6(config-vlan)#exit
SW6(config)# vlan 70
SW6(config-vlan)#exit
SW6(config)# vlan 110
SW6(config-vlan)#exit
SW6(config)#interface fastEthernet 0/1
SW6(config-if)# switchport access vlan 30
SW6(config-if)#exit
SW6(config)#interface fastEthernet 0/2
SW6(config-if)# switchport access vlan 30
164
LPP v1.0 DOCUMENTO FINAL
SW6(config-if)#exit
SW6(config)#interface fastEthernet 0/3
SW6(config-if)# switchport access vlan 30
SW6(config-if)#exit
SW6(config)#interface fastEthernet 0/4
SW6(config-if)# switchport access vlan 30
SW6(config-if)#exit
SW6(config)#interface fastEthernet 0/5
SW6(config-if)# switchport access vlan 30
SW6(config-if)#exit
SW6(config)#interface fastEthernet 0/6
SW6(config-if)# switchport access vlan 20
SW6(config-if)#exit
SW6(config)#interface fastEthernet 0/7
SW6(config-if)# switchport access vlan 70
SW6(config-if)#exit
SW6#configure terminal
SW6(config)# interface fastEthernet 0/11
SW6(config-if)# switchport mode trunk
SW6(config-if)#exit
SW6(config)# interface fastEthernet 0/12
SW6(config-if)# switchport mode trunk
SW6(config-if)#exit
Switch 5
SW5#configure terminal
SW5(config)# vlan 10
SW5(config-vlan)#exit
SW5(config)# vlan 20
SW5(config-vlan)#exit
SW5(config)# vlan 60
SW5(config-vlan)#exit
SW5(config)# vlan 110
SW5(config-vlan)#exit
SW5(config)#interface fastEthernet 0/1
SW5(config-if)# switchport access vlan 10
SW5(config-if)#exit
SW5(config)#interface fastEthernet 0/2
SW5(config-if)# switchport access vlan 10
SW5(config-if)#exit
SW5(config)#interface fastEthernet 0/3
SW5(config-if)# switchport access vlan 10
SW5(config-if)#exit
SW5(config)#interface fastEthernet 0/4
SW5(config-if)# switchport access vlan 60
SW5(config-if)#exit
SW5(config)#interface fastEthernet 0/5
SW5(config-if)# switchport access vlan 20
165
LPP v1.0 DOCUMENTO FINAL
SW5(config-if)#exit
SW5(config)#interface fastEthernet 0/6
SW5(config-if)# switchport access vlan 20
SW5(config-if)#exit
SW5(config)#interface fastEthernet 0/7
SW5(config-if)# switchport access vlan 20
SW5(config-if)#exit
SW5(config)#interface fastEthernet 0/8
SW5(config-if)# switchport access vlan 20
SW5(config-if)#exit
SW5(config)#exit
SW5#configure terminal
SW5(config)# interface fastEthernet 0/11
SW5(config-if)# switchport mode trunk
SW5(config-if)#exit
SW5(config)# interface fastEthernet 0/12
SW5(config-if)# switchport mode trunk
SW5(config-if)#exit
Switch 4
SW4#configure terminal
SW4(config)# vlan 40
SW4(config-vlan)#exit
SW4(config)# vlan 50
SW4(config-vlan)#exit
SW4(config)# vlan 70
SW4(config-vlan)#exit
SW4(config)# vlan 110
SW4(config-vlan)#exit
SW4(config)#interface fastEthernet 0/1
SW4(config-if)# switchport access vlan 50
SW4(config-if)#exit
SW4(config)#interface fastEthernet 0/2
SW4(config-if)# switchport access vlan 50
SW4(config-if)#exit
SW4(config)#interface fastEthernet 0/3
SW4(config-if)# switchport access vlan 50
SW4(config-if)#exit
SW4(config)#interface fastEthernet 0/4
SW4(config-if)# switchport access vlan 50
SW4(config-if)#exit
SW4(config)#interface fastEthernet 0/5
SW4(config-if)# switchport access vlan 50
SW4(config-if)#exit
SW4(config)#interface fastEthernet 0/7
SW4(config-if)# switchport access vlan 40
SW4(config-if)#exit
166
LPP v1.0 DOCUMENTO FINAL
SW4(config)#interface fastEthernet 0/8
SW4(config-if)# switchport access vlan 40
SW4(config-if)#exit
SW4(config)#interface fastEthernet 0/9
SW4(config-if)# switchport access vlan 70
SW4(config-if)#exit
SW4#configure terminal
SW4(config)# interface fastEthernet 0/11
SW4(config-if)# switchport mode trunk
SW4(config-if)#exit
SW4(config)# interface fastEthernet 0/12
SW4(config-if)# switchport mode trunk
SW4(config-if)#exit
Laboratorio 3.4
Switch 7
SW7#configure terminal
SW7(config)# vlan 101
SW7(config-vlan)#exit
SW7(config)# vlan 110
SW7(config-vlan)#exit
SW7(config)#interface fastEthernet 0/1
SW7(config-if)# switchport access vlan 1
SW7(config-if)#exit
SW7(config)#interface fastEthernet 0/2
SW7(config-if)# switchport access vlan 1
SW7(config-if)#exit
SW7#configure terminal
SW7(config)# interface fastEthernet 0/11
SW7(config-if)# switchport mode trunk
SW7(config-if)#exit
SW7(config)# interface fastEthernet 0/12
SW7(config-if)# switchport mode trunk
SW7(config-if)#exit
Switch 8
SW8#configure terminal
SW8(config)# vlan 20
SW8(config-vlan)#exit
SW8(config)# vlan 50
SW8(config-vlan)#exit
SW8(config)# vlan 70
SW8(config-vlan)#exit
SW8(config)# vlan 110
SW8(config-vlan)#exit
167
LPP v1.0 DOCUMENTO FINAL
SW8(config)#interface fastEthernet 0/1
SW8(config-if)# switchport access vlan 20
SW8(config-if)#exit
SW8(config)#interface fastEthernet 0/3
SW8(config-if)# switchport access vlan 50
SW8(config-if)#exit
SW8(config)#interface fastEthernet 0/4
SW8(config-if)# switchport access vlan 70
SW8(config-if)#exit
SW8#configure terminal
SW8(config)# interface fastEthernet 0/11
SW8(config-if)# switchport mode trunk
SW8(config-if)#exit
SW8(config)# interface fastEthernet 0/12
SW8(config-if)# switchport mode trunk
SW8(config-if)#exit
Switch Multilayer
SWMultilayer#configure terminal
SWMultilayer(config)#vlan 10
SWMultilayer(config-vlan)#exit
SWMultilayer(config)#vlan 20
SWMultilayer(config-vlan)#exit
SWMultilayer(config)#vlan 30
SWMultilayer(config-vlan)#exit
SWMultilayer(config)#vlan 40
SWMultilayer(config-vlan)#exit
SWMultilayer(config)#vlan 50
SWMultilayer(config-vlan)#exit
SWMultilayer(config)#vlan 60
SWMultilayer(config-vlan)#exit
SWMultilayer(config)#vlan 70
SWMultilayer(config-vlan)#exit
SWMultilayer(config)#vlan 110
SWMultilayer(config-vlan)#exit
SWMultilayer(config)#vlan 101
SWMultilayer(config-vlan)#exit
SWMultilayer(config)# interface fastEthernet 0/1
SWMultilayer(config-if)# switchport mode trunk
SWMultilayer(config-if)#exit
SWMultilayer(config)# interface fastEthernet 0/2
SWMultilayer(config-if)# switchport mode trunk
SWMultilayer(config-if)#exit
SWMultilayer(config)# interface fastEthernet 0/3
SWMultilayer(config-if)# switchport mode trunk
SWMultilayer(config-if)#exit
SWMultilayer(config)# interface fastEthernet 0/4
SWMultilayer(config-if)# switchport mode trunk
SWMultilayer(config-if)#exit
168
LPP v1.0 DOCUMENTO FINAL
SWMultilayer(config)# interface fastEthernet 0/5
SWMultilayer(config-if)# switchport mode trunk
SWMultilayer(config-if)#exit
SWMultilayer(config)# interface fastEthernet 0/6
SWMultilayer(config-if)# switchport mode trunk
SWMultilayer(config-if)#exit
SWMultilayer(config)# interface fastEthernet 0/7
SWMultilayer(config-if)# switchport mode trunk
SWMultilayer(config-if)#exit
SWMultilayer(config)# interface fastEthernet 0/8
SWMultilayer(config-if)# switchport mode trunk
SWMultilayer(config-if)#exit
SWMultilayer(config)# interface fastEthernet 0/9
SWMultilayer(config-if)# switchport mode trunk
SWMultilayer(config-if)#exit
SWMultilayer(config)# interface fastEthernet 0/10
SWMultilayer(config-if)# switchport mode trunk
SWMultilayer(config-if)#exit
SWMultilayer(config)# interface fastEthernet 0/11
SWMultilayer(config-if)# switchport mode trunk
SWMultilayer(config-if)#exit
SWMultilayer(config)# interface fastEthernet 0/12
SWMultilayer(config-if)# switchport mode trunk
SWMultilayer(config-if)#exit
SWMultilayer(config)# interface fastEthernet 0/13
SWMultilayer(config-if)# switchport mode trunk
SWMultilayer(config-if)#exit
SWMultilayer(config)# interface fastEthernet 0/14
SWMultilayer(config-if)# switchport mode trunk
SWMultilayer(config-if)#exit
SWMultilayer(config)# interface fastEthernet 0/15
SWMultilayer(config-if)# switchport mode trunk
SWMultilayer(config-if)#exit
SWMultilayer(config)# interface fastEthernet 0/16
SWMultilayer(config-if)# switchport mode trunk
SWMultilayer(config-if)#exit
SWMultilayer(config)# interface fastEthernet 0/17
SWMultilayer(config-if)# switchport access vlan 1
SWMultilayer(config-if)#exit
SWMultilayer(config)# interface fastEthernet 0/18
SWMultilayer(config-if)# switchport access vlan 1
SWMultilayer(config-if)#exit
SWMultilayer(config)# interface fastEthernet 0/19
SWMultilayer(config-if)# switchport access vlan 40
SWMultilayer(config-if)#exit
SWMultilayer(config)#exit
Se asignan a los switches una dirección IP en la VLAN 110:
169
LPP v1.0 DOCUMENTO FINAL
SW 1
SW1#configure terminal
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#configure terminal
SW2(config)# interface vlan 110
SW2(config-if)# ip address 192.168.110.2 255.255.255.0
SW2(config-if)#exit
SW 3
SW3#configure terminal
SW3(config)# interface vlan 110
SW3(config-if)# ip address 192.168.110.3 255.255.255.0
SW3(config-if)#exit
SW 4
SW4#configure terminal
SW4(config)# interface vlan 110
SW4(config-if)# ip address 192.168.110.4 255.255.255.0
SW4(config-if)#exit
SW 5
SW5#configure terminal
SW5(config)# interface vlan 110
SW5(config-if)# ip address 192.168.110.5 255.255.255.0
SW5(config-if)#exit
SW 6
SW6#configure terminal
SW6(config)# interface vlan 110
SW6(config-if)# ip address 192.168.110.6 255.255.255.0
SW6(config-if)#exit
SW 7
SW7#configure terminal
SW7(config)# interface vlan 110
SW7(config-if)# ip address 192.168.110.7 255.255.255.0
SW7(config-if)#exit
SW 8
SW8#configure terminal
SW8(config)# interface vlan 110
SW8(config-if)# ip address 192.168.110.8 255.255.255.0
SW8(config-if)#exit
SWMultilayer#configure terminal
SWMultilayer (config) # interface vlan 110
170
LPP v1.0 DOCUMENTO FINAL
SWMultilayer (config-if)# ip address 192.168.110.10 255.255.255.0
15.3 Configuración de balanceo de carga
Switch Multilayer
SWMultilayer#configure terminal
SWMultilayer(config)#interface fastEthernet 0/1
SWMultilayer(config-if)#spanning-tree vlan 70 port priority 64
SWMultilayer(config-if)#exit
SWMultilayer(config)#interface fastEthernet 0/2
SWMultilayer(config-if)#spanning-tree vlan 40 port priority 64
SWMultilayer(config-if)#spanning-tree vlan 50 port priority 64
SWMultilayer(config-if)#exit
SWMultilayer(config)#interface fastEthernet 0/3
SWMultilayer(config-if)#spanning-tree vlan 10 port priority 64
SWMultilayer(config-if)#spanning-tree vlan 60 port priority 64
SWMultilayer(config-if)#exit
SWMultilayer(config)#interface fastEthernet 0/4
SWMultilayer(config-if)#spanning-tree vlan 20 port priority 64
SWMultilayer(config-if)#exit
SWMultilayer(config)#interface fastEthernet 0/5
SWMultilayer(config-if)#spanning-tree vlan 70 port priority 64
SWMultilayer(config-if)#exit
SWMultilayer(config)#interface fastEthernet 0/6
SWMultilayer(config-if)#spanning-tree vlan 20 port priority 64
SWMultilayer(config-if)#spanning-tree vlan 30 port priority 64
SWMultilayer(config-if)#exit
SWMultilayer(config)#interface fastEthernet 0/7
SWMultilayer(config-if)#spanning-tree vlan 70 port priority 64
SWMultilayer(config-if)#exit
SWMultilayer(config)#interface fastEthernet 0/8
SWMultilayer(config-if)#spanning-tree vlan 40 port priority 64
SWMultilayer(config-if)#spanning-tree vlan 50 port priority 64
SWMultilayer(config-if)#exit
SWMultilayer(config)#interface fastEthernet 0/9
SWMultilayer(config-if)#spanning-tree vlan 10 port priority 64
SWMultilayer(config-if)#spanning-tree vlan 60 port priority 64
SWMultilayer(config-if)#exit
SWMultilayer(config)#interface fastEthernet 0/10
SWMultilayer(config-if)#spanning-tree vlan 20 port priority 64
SWMultilayer(config-if)#exit
SWMultilayer(config)#interface fastEthernet 0/11
SWMultilayer(config-if)#spanning-tree vlan 70 port priority 64
SWMultilayer(config-if)#exit
SWMultilayer(config)#interface fastEthernet 0/12
SWMultilayer(config-if)#spanning-tree vlan 20 port priority 64
SWMultilayer(config-if)#spanning-tree vlan 30 port priority 64
SWMultilayer(config-if)#exit
171
LPP v1.0 DOCUMENTO FINAL
SWMultilayer(config)#interface fastEthernet 0/13
SWMultilayer(config-if)#spanning-tree vlan 101 port priority 64
SWMultilayer(config-if)#exit
SWMultilayer(config)#interface fastEthernet 0/14
SWMultilayer(config-if)#spanning-tree vlan 101 port priority 64
SWMultilayer(config-if)#exit
SWMultilayer(config)#interface fastEthernet 0/15
SWMultilayer(config-if)#spanning-tree vlan 70 port priority 64
SWMultilayer(config-if)#spanning-tree vlan 50 port priority 64
SWMultilayer(config-if)#exit
SWMultilayer(config)#interface fastEthernet 0/16
SWMultilayer(config-if)#spanning-tree vlan 40 port priority 64
SWMultilayer(config-if)#exit
15.4 Configuración DHCP
Switch Multilayer
SWMultilayer#configure terminal
SWMultilayer(config)# int Vlan10
SWMultilayer (config-if)#ip addr 192.168.10.1 255.255.255.0
SWMultilayer (config-if)#exit
SWMultilayer(config)# int Vlan20
SWMultilayer (config-if)#ip addr 192.168.20.1 255.255.255.0
SWMultilayer (config-if)#exit
SWMultilayer(config)# int Vlan30
SWMultilayer (config-if)#ip addr 192.168.30.1 255.255.255.0
SWMultilayer (config-if)#exit
SWMultilayer(config)# int Vlan40
SWMultilayer (config-if)#ip addr 192.168.40.1 255.255.255.0
SWMultilayer (config-if)#exit
SWMultilayer(config)# int Vlan50
SWMultilayer (config-if)#ip addr 192.168.50.1 255.255.255.0
SWMultilayer (config-if)#exit
SWMultilayer(config)# int Vlan60
SWMultilayer (config-if)#ip addr 192.168.60.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
SWMultilayer (config)#ip dhcp pool Vlan20
SWMultilayer (dhcp-config)#network 192.168.20.0 255.255.255.0
SWMultilayer (dhcp-config)#default-router 192.168.20.2
SWMultilayer (dhcp-config)#exit
SWMultilayer (config)#ip dhcp pool Vlan30
SWMultilayer (dhcp-config)#network 192.168.30.0 255.255.255.0
SWMultilayer (dhcp-config)#default-router 192.168.30.2
SWMultilayer (dhcp-config)#exit
SWMultilayer (config)#ip dhcp pool Vlan40
172
LPP v1.0 DOCUMENTO FINAL
SWMultilayer (dhcp-config)#network 192.168.40.0 255.255.255.0
SWMultilayer (dhcp-config)#default-router 192.168.40.2
SWMultilayer (dhcp-config)#exit
SWMultilayer (config)#ip dhcp pool Vlan50
SWMultilayer (dhcp-config)#network 192.168.50.0 255.255.255.0
SWMultilayer (dhcp-config)#default-router 192.168.50.2
SWMultilayer (dhcp-config)#exit
SWMultilayer (config)#ip dhcp pool Vlan60
SWMultilayer (dhcp-config)#network 192.168.60.0 255.255.255.0
SWMultilayer (dhcp-config)#default-router 192.168.60.2
SWMultilayer (dhcp-config)#exit
SWMultilayer (config)#ip dhcp excluded-address 192.168.10.1 192.168.10.10
SWMultilayer (config)#ip dhcp excluded-address 192.168.20.1 192.168.20.10
SWMultilayer (config)#ip dhcp excluded-address 192.168.30.1 192.168.30.10
SWMultilayer (config)#ip dhcp excluded-address 192.168.40.1 192.168.40.10
SWMultilayer (config)#ip dhcp excluded-address 192.168.50.1 192.168.50.10
SWMultilayer (config)#ip dhcp excluded-address 192.168.60.1 192.168.60.10
SWMultilayer (config)#ip dhcp excluded-address 192.168.70.1 192.168.70.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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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 permit ip 192.168.10.0 0.0.0.255 192.168.100.3 0.0.0.255
SWM(config)#access-list 102 permit ip 192.168.10.0 0.0.0.255 192.168.101.0 0.0.0.255
SWM(config)#access-list 102 permit ip 192.168.101.0 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
SWM# configure terminal
SWM(config)# access-list 103 permit tcp 192.168.20.0 0.0.0.255 192.168.20.0
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)#access-list 103 permit ip 192.168.100.3 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 192.168.101.0 0.0.0.255
SWM(config)#access-list 103 permit ip 192.168.101.0 0.0.0.255 192.168.20.0 0.0.0.255
SWM(config)# access-list 103 deny ip 192.168.20.0 0.0.0.255 192.168.0.0 0.0.255.255
SWM(config)# access-list 103 permit ip any any (para el acceso a internet)
SWM(config)# interface VLAN20
SWM(config-if)# ip access-group 103 in
SWM(config-if)# exit
104) VLAN30League of Legends
SWM# configure terminal
SWM(config)# access-list 104 permit tcp 192.168.30.0 0.0.0.255 192.168.30.0
0.0.0.255
SWM(config)# access-list 104 permit udp 192.168.30.0 0.0.0.255 192.168.30.0
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
SWM(config)#access-list 104 permit ip 192.168.100.3 0.0.0.255 192.168.30.0 0.0.0.255
SWM(config)#access-list 104 permit ip 192.168.30.0 0.0.0.255 192.168.101.0 0.0.0.255
SWM(config)#access-list 104 permit ip 192.168.101.0 0.0.0.255 192.168.30.0 0.0.0.255
SWM(config)# access-list 104 deny ip 192.168.30.0 0.0.0.255 192.168.0.0 0.0.255.255
SWM(config)# access-list 104 permit ip any any (para el acceso a internet)
SWM(config)# interface VLAN30
SWM(config-if)# ip access-group 104 in
175
LPP v1.0 DOCUMENTO FINAL
SWM(config-if)# exit
105) VLAN40 Minecraft
SWM# configure terminal
SWM(config)# access-list 105 permit tcp 192.168.40.0 0.0.0.255 192.168.40.0
0.0.0.255
SWM(config)# access-list 105 permit udp 192.168.40.0 0.0.0.255 192.168.40.0
0.0.0.255
SWM(config)# Access-list 105 permit ip 192.168.40.0 0.0.0.255 192.168.100.0
0.0.0.255
SWM(config)#access-list 105 permit ip 192.168.100.3 0.0.0.255 192.168.40.0 0.0.0.255
SWM(config)#access-list 105 permit ip 192.168.40.0 0.0.0.255 192.168.101.0 0.0.0.255
SWM(config)#access-list 105 permit ip 192.168.101.0 0.0.0.255 192.168.40.0 0.0.0.255
SWM(config)# access-list 105 deny ip 192.168.40.0 0.0.0.255 192.168.0.0 0.0.255.255
SWM(config)# access-list 105 permit ip any any (para el acceso a internet)
SWM(config)# interface Vlan40
SWM(config-if)# ip access-group 105 in
SWM(config-if)# exit
106) VLAN50Team Fortress 2
SWM# configure terminal
SWM(config)# access-list 106 permit tcp 192.168.50.0 0.0.0.255 192.168.50.0
0.0.0.255
SWM(config)# access-list 106 permit udp 192.168.50.0 0.0.0.255 192.168.50.0
0.0.0.255
SWM(config)# Access-list 106 permit ip 192.168.50.0 0.0.0.255 192.168.100.0
0.0.0.255
SWM(config)#access-list 106 permit ip 192.168.100.3 0.0.0.255 192.168.50.0 0.0.0.255
SWM(config)#access-list 106 permit ip 192.168.50.0 0.0.0.255 192.168.101.0 0.0.0.255
SWM(config)#access-list 106 permit ip 192.168.101.0 0.0.0.255 192.168.50.0 0.0.0.255
SWM(config)# access-list 106 deny ip 192.168.50.0 0.0.0.255 192.168.0.0 0.0.255.255
SWM(config)# access-list 106 permit ip any any (para el acceso a internet)
SWM(config)# interface VLAN50
SWM(config-if)# ip access-group 106 in
SWM(config-if)# exit
107) VLAN60 Street Fighter y FIFA
SWM# configure terminal
SWM(config)# access-list 107 permit tcp 192.168.60.0 0.0.0.255 192.168.60.0
0.0.0.255
SWM(config)# access-list 107 permit udp 192.168.60.0 0.0.0.255 192.168.60.0
0.0.0.255
SWM(config)# Access-list 107 permit ip 192.168.60.0 0.0.0.255 192.168.100.0
0.0.0.255
SWM(config)#access-list 107 permit ip 192.168.100.3 0.0.0.255 192.168.60.0 0.0.0.255
SWM(config)#access-list 107 permit ip 192.168.60.0 0.0.0.255 192.168.101.0 0.0.0.255
176
LPP v1.0 DOCUMENTO FINAL
SWM(config)#access-list 107 permit ip 192.168.101.0 0.0.0.255 192.168.60.0 0.0.0.255
SWM(config)# access-list 107 deny ip 192.168.60.0 0.0.0.255 192.168.0.0 0.0.255.255
SWM(config)# access-list 107 permit ip any any (para el acceso a internet)
SWM(config)# interface VLAN60
SWM(config-if)# ip access-group 107 in
SWM(config-if)# exit
108) VLAN70 Sistema de videovigilancia
SWM# configure terminal
SWM(config)# access-list 108 permit ip 192.168.0.0 0.0.255.255 192.168.0.0
0.0.255.255
SWM(config)# interface VLAN70
SWM(config-if)# ip access-group 108 in
SWM(config-if)# exit
101) VLAN110 Gestión
SWM# configure terminal
SWM(config)# access-list 101 permit ip 192.168.101.0 0.0.0.255 192.168.110.0
0.0.0.255
SWM(config)# access-list 101 permit ip 192.168.110.0 0.0.0.255 192.168.101.0
0.0.0.255
SWM(config)# interface VLAN110
SWM(config-if)# ip access-group 101 in
SWM(config-if)# exit
15.10 Configuración de calidad de servicio QoS:
Switch1:
SW1> R>enable
SW1#configure terminal
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 deny ip 192.168.50.0 0.0.0.255 any eq 22
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 deny ip 192.168.40.0 0.0.0.255 any eq 23
SW1 (config)# access-list 121 deny ip 192.168.40.0 0.0.0.255 any eq 22
SW1 (config)# access-list 121 permit tcp any any eq 25565
SW1 (config)# access-list 122 permit tcp any any
177
LPP v1.0 DOCUMENTO FINAL
SW1 (config)# access-list 122 permit udp any any
SW1 (config)# interface range FastEthernet 0/7-0/8
SW1 (config-if)# rate-limit output access-group 121 8000000 10000000 12000000
conform-action set-prec-transmit 5 exceed-action drop
SW1 (config-if)# rate-limit output access-group 122 1000000 1500000 2000000
conform-action set-prec-transmit 5 exceed-action drop
SW1 (config-if)#exit
Switch2:
SW2> R>enable
SW2#configure terminal
SW2 (config)# access
SW2 (config)#! Hearthstone
SW2 (config)# access-list 120 deny ip 192.168.10.0 0.0.0.255 any eq 23
SW2 (config)# access-list 120 deny ip 192.168.10.0 0.0.0.255 any eq 22
SW2 (config)# access-list 120 permit tcp any any
SW2 (config)# access-list 120 permit udp any any
SW2 (config)# interface range FastEthernet 0/1-0/3
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
SW2 (config)# access-list 121 deny ip 192.168.10.0 0.0.0.255 any eq 23
SW2 (config)# access-list 121 deny ip 192.168.10.0 0.0.0.255 any eq 22
SW2 (config)# access-list 121 permit tcp any any
SW2 (config)# access-list 121 permit udp any any
SW2 (config)# interface range FastEthernet 0/5-0/8
SW2 (config-if)# rate-limit output access-group 121 1000000 1500000 2000000
conform-action set-prec-transmit 5 exceed-action drop
SW2 (config-if)#exit
Switch3:
SW3> R>enable
SW3#configure terminal
SW3 (config)# access
SW3 (config)#! LOL
SW2 (config)# access-list 120 deny ip 192.168.30.0 0.0.0.255 any eq 23
SW2 (config)# access-list 120 deny ip 192.168.30.0 0.0.0.255 any eq 22
SW3 (config)# access-list 120 permit tcp any any
SW3 (config)# access-list 120 permit udp any any
SW3 (config)# interface range FastEthernet 0/1-0/5
SW3 (config-if)# rate-limit output access-group 120 1000000 1500000 2000000
conform-action set-prec-transmit 5 exceed-action drop
SW3 (config-if)#exit
SW3 (config)#! Counter Strike
SW2 (config)# access-list 121 deny ip 192.168.20.0 0.0.0.255 any eq 23
SW2 (config)# access-list 121 deny ip 192.168.20.0 0.0.0.255 any eq 22
SW3 (config)# access-list 121 permit tcp any any
178
LPP v1.0 DOCUMENTO FINAL
SW3 (config)# access-list 121 permit udp any any
SW3 (config)# interface FastEthernet 0/6
SW3 (config-if)# rate-limit output access-group 121 1000000 1500000 2000000
conform-action set-prec-transmit 5 exceed-action drop
SW3 (config-if)#exit
Switch4:
SW4> R>enable
SW4#configure terminal
SW4 (config)# access
SW4 (config)#! Team Fortress 2
SW4 (config)# access-list 120 permit tcp any any
SW4 (config)# access-list 120 permit udp any any
SW2 (config)# access-list 120 deny ip 192.168.50.0 0.0.0.255 any eq 23
SW2 (config)# access-list 120 deny ip 192.168.50.0 0.0.0.255 any eq 22
SW4 (config)# interface range FastEthernet 0/1-0/5
SW4 (config-if)# rate-limit output access-group 125 1000000 1500000 2000000
conform-action set-prec-transmit 5 exceed-action drop
SW4 (config-if)#exit
SW4 (config)#! # Minecraft
SW4 (config)# access-list 121 permit tcp any any eq 25565
SW2 (config)# access-list 121 deny ip 192.168.40.0 0.0.0.255 any eq 23
SW2 (config)# access-list 121 deny ip 192.168.40.0 0.0.0.255 any eq 22
SW4 (config)# access-list 122 permit tcp any any
SW4 (config)# access-list 122 permit udp any any
SW4 (config)# interface range FastEthernet 0/7-0/8
SW4 (config-if)# rate-limit output access-group 121 8000000 10000000 12000000
conform-action set-prec-transmit 5 exceed-action drop
SW4 (config-if)# rate-limit output access-group 122 1000000 1500000 2000000
conform-action set-prec-transmit 5 exceed-action drop
SW4 (config-if)#exit
Switch5:
SW5> R>enable
SW5#configure terminal
SW5 (config)# access
SW5 (config)#! Hearthstone
SW5 (config)# access-list 120 permit tcp any any
SW5 (config)# access-list 120 permit udp any any
SW2 (config)# access-list 121 deny ip 192.168.10.0 0.0.0.255 any eq 23
SW2 (config)# access-list 121 deny ip 192.168.10.0 0.0.0.255 any eq 22
SW5 (config)# interface range FastEthernet 0/1-0/3
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
SW5 (config)#! Counter Strike
SW5 (config)# access-list 121 permit tcp any any
179
LPP v1.0 DOCUMENTO FINAL
SW5 (config)# access-list 121 permit udp any any
SW5 (config)# interface range FastEthernet 0/5-0/8
SW5 (config-if)# rate-limit output access-group 121 1000000 1500000 2000000
conform-action set-prec-transmit 5 exceed-action drop
SW5 (config-if)#exit
Switch6:
SW6> R>enable
SW6#configure terminal
SW6 (config)# access
SW6 (config)#! LOL
SW6 (config)# access-list 120 permit tcp any any
SW6 (config)# access-list 120 permit udp any any
SW2 (config)# access-list 120 deny ip 192.168.30.0 0.0.0.255 any eq 23
SW2 (config)# access-list 120 deny ip 192.168.30.0 0.0.0.255 any eq 22
SW6 (config)# interface range FastEthernet 0/1-0/5
SW6 (config-if)# rate-limit output access-group 120 1000000 1500000 2000000
conform-action set-prec-transmit 5 exceed-action drop
SW6 (config-if)#exit
SW6 (config)#! Counter Strike
SW6 (config)# access-list 121 permit tcp any any
SW6 (config)# access-list 121 permit udp any any
SW6 (config)# interface FastEthernet 0/6
SW6 (config-if)# rate-limit output access-group 121 1000000 1500000 2000000
conform-action set-prec-transmit 5 exceed-action drop
SW6 (config-if)#exit
180
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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
LPP v1.0 DOCUMENTO FINAL
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 source interface fastEthernet 1/3
SwitchMultilayer (config)#monitor session 1 source interface fastEthernet 1/4
SwitchMultilayer (config)#monitor session 1 source interface fastEthernet 1/5
SwitchMultilayer (config)#monitor session 1 source interface fastEthernet 1/6
SwitchMultilayer (config)#monitor session 1 source interface fastEthernet 1/7
SwitchMultilayer (config)#monitor session 1 source interface fastEthernet 1/8
SwitchMultilayer (config)#monitor session 1 source interface fastEthernet 1/9
SwitchMultilayer (config)#monitor session 1 source interface fastEthernet 1/10
SwitchMultilayer (config)#monitor session 1 source interface fastEthernet 1/11
SwitchMultilayer (config)#monitor session 1 source interface fastEthernet 1/12
SwitchMultilayer (config)#monitor session 1 source interface fastEthernet 1/13
SwitchMultilayer (config)#monitor session 1 source interface fastEthernet 1/14
SwitchMultilayer (config)#monitor session 1 source interface fastEthernet 1/15
SwitchMultilayer (config)#monitor session 1 source interface fastEthernet 1/16
SwitchMultilayer (config)#monitor session 1 destination interface fastEthernet 1/17