ESCUELA POLITÉCNICA NACIONAL FACULTAD DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA
IMPLEMENTACIÓN IMPLEMENTACIÓ N DE PROTOCOLOS DE ENRUTAMIENTO MEDIANTE UN ENRUTADOR BASADO EN SOFTWARE DE CÓDIGO ABIERTO BAJO LINUX
PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN ELECTRÓNICA Y TELECOMUNICACIONES
JULIO ALEXANDER ULLOA MÁRQUEZ
DIRECTOR: ING. PABLO HIDALGO
Quito, Octubre 2007
DECLARACIÓN
Yo, Julio Alexander Ulloa Márquez. Declaro bajo juramento que el trabajo aquí descrito es de mi autoría; que no ha sido previamente presentado para ningún grado o calificación profesional; y, que he consultado las referencias bibliográficas que se incluyen en este documento. La Escuela Politécnica Nacional, puede hacer uso de los derechos correspondientes a este trabajo, según lo establecido por la Ley de Propiedad Intelectual, por su reglamento y por la normativa institucional vigente.
______________ _______________________ ____________ ___ Julio Alexander Ulloa Márquez
CERTIFICACIÓN
Certifico que el presente trabajo fue desarrollado por Julio Alexander Ulloa Márquez, bajo mi supervisión.
_________________ ________________________ _________ Ing. Pablo Hidalgo DIRECTOR DEL PROYECTO
AGRADECIMIENTO
A mis padres Janneth Márquez y Segundo Ulloa, por estar presente en todos los momentos importantes de mi vida y brindarme amor, cariño, comprensión y apoyo incondicional. A mis amigos, que han sido un pilar importante en mi desarrollo personal e intelectual.
DEDICATORIA
A mis hermanos Vladimir Esteban y Jorge Andrés, por su esfuerzo y dedicación diaria para llegar a ser hombres de bien. Confío en que sus virtudes y defectos lleguen a convertirse en herramientas para conseguir la felicidad.
I
CONTENIDO CONTENIDO..................................................................................................................................................... I ÍNDICE DE FIGURAS ................................................................................................................................... VI ÍNDICE DE TABLAS..................................................................................................................................... IX ÍNDICE DE TABLAS..................................................................................................................................... IX RESUMEN........................................................................................................................................................X PRESENTACIÓN........................................................................................................................................... XI
CAPÍTULO 1. INTRODUCCIÓN AL ENRUTAMIENTO........................................................................ 1 1.1. INTRODUCCIÓN................................................................................................................................. 1 1.2. CARACTERÍSTICAS PRINCIPALES ................................................................................................. 2 1.2.1. MODELO DE REFERENCIA ISO – OSI....................................................................................... 3 1.2.2. MODELO DE REFERENCIA TCP / IP......................................................................................... 5 1.2.3. ENRUTADORES............................................................................................................................ 7
1.2.3.1. Enrutadores Basados en Hardware......................................................................................... 9 1.2.3.2. Enrutadores Basados en Software .........................................................................................10 1.3. ENRUTAMIENTO...............................................................................................................................11 1.3.1. DEFINICIONES ...........................................................................................................................12
1.3.1.1.
Nodo......................................................................................................................................12
1.3.1.2. Topología de Red ..................................................................................................................12 1.3.1.3. Métrica ..................................................................................................................................12 1.3.1.4. Algoritmo de Enrutamiento...................................................................................................12 1.3.1.5. Protocolo de Enrutamiento....................................................................................................13 1.3.1.6. Protocolos Enrutables............................................................................................................13 1.3.1.7. Sistema Autónomo................................................................................................................14 1.3.2. ENRUTAMIENTO ESTÁTICO .....................................................................................................14 1.3.3. ENRUTAMIENTO DINÁMICO ....................................................................................................16
1.3.3.1. Algoritmo de Vector Distancia..............................................................................................16 1.3.3.2. Algoritmo de Estado de Enlace.............................................................................................18 1.3.3.2.1. Descubrir a sus vecinos y conocer sus direcciones de red.............................................19 1.3.3.2.2. Medición del costo de la línea .......................................................................................19 1.3.3.2.3. Construcción de los paquetes de estado de enlace.........................................................19 1.3.3.2.4. Distribución de los paquetes de estado de enlace..........................................................20 1.3.3.2.5. Cálculo de nuevas rutas.................................................................................................20 1.4. IPV4 VS. IPV6.......................................................................................................................................20 1.4.1. PROTOCOLO IPv4 ......................................................................................................................20 1.4.2. DIRECCIONAMIENTO IPv4 .......................................................................................................23
II
1.4.3. PROTOCOLO IPv6 ......................................................................................................................27 1.4.4. DIRECCIONAMIENTO IPV6.......................................................................................................31
1.5. PROTOCOLOS DE ENRUTAMIENTO DINÁMICO.........................................................................34 1.5.1. RIP (ROUTING INFORMATION PROTOCOL) ..........................................................................35
1.5.1.1. RIPv1 ....................................................................................................................................35 1.5.1.2. RIPv2 ....................................................................................................................................37 1.5.1.3. RIPng ....................................................................................................................................38 1.5.2. IGRP y EIGRP..............................................................................................................................39
1.5.2.1. IGRP ( INTERIOR GATEWAY ROUTING PROTOCOL)......................................................39 1.5.2.2. EIGRP (ENHANCED INTERIOR GATEWAY ROUTING PROTOCOL) .............................40 1.5.3. OSPF (OPEN SHORTEST PATH FIRST) ....................................................................................41 1.5.4. BGP (BORDER GATEWAY PROTOCOL) ...................................................................................44
REFERENCIAS CAPÍTULO 1 ...................................................................................................................45
CAPÍTULO 2. HERRAMIENTAS PARA ENRUTADORES BASADAS EN SOFTWARE..................47 2.1. SISTEMAS OPERATIVOS PARA ENRUTAMIENTO......................................................................47 2.1.1. DEFINICIONES ...........................................................................................................................47
2.1.1.1. Sistema Operativo .................................................................................................................47 2.1.1.2. Shell ......................................................................................................................................49 2.1.1.3.
Proceso..................................................................................................................................49
2.1.1.3.1. Sistemas Operativos Monotarea ....................................................................................49 2.1.1.3.2. Sistemas Operativos Multitarea.....................................................................................49 2.1.1.4.
Usuario..................................................................................................................................50
2.1.1.4.1. Sistemas operativos monousuarios................................................................................50 2.1.1.4.2. Sistemas operativos multiusuarios.................................................................................50 2.1.2. SISTEMAS OPERATIVOS MÁS UTILIZADOS ............................................................................50
2.1.2.1. Windows ...............................................................................................................................51 2.1.2.1.1. MPR ..............................................................................................................................54 2.1.2.1.2. RRAS ............................................................................................................................56 2.1.2.2. Linux .....................................................................................................................................57 2.1.2.3. Cisco IOS ..............................................................................................................................59 2.2. HERRAMIENTAS BAJO LINUX .......................................................................................................61 2.2.1. FREESCO.....................................................................................................................................62 2.2.2.
LEAF.............................................................................................................................................63
2.2.3.
IPROUTE......................................................................................................................................64
2.2.4.
ROUTED.......................................................................................................................................65
2.2.5.
GATED..........................................................................................................................................65
2.2.6. XORP ............................................................................................................................................66 2.2.7. ZEBRA – QUAGGA ......................................................................................................................67
III
2.3. OTROS USOS DEL ENRUTAMIENTO .............................................................................................70 2.3.1.
NAT...............................................................................................................................................70
2.3.2.
VPN...............................................................................................................................................72
REFERENCIAS CAPÍTULO 2 ...................................................................................................................73
CAPÍTULO 3. MÁQUINAS VIRTUALES Y SIMULADORES ...............................................................75 3.1. VIRTUALIZACIÓN.............................................................................................................................75 3.1.1. VIRTUALIZACIÓN DE RECURSOS ............................................................................................76 3.1.2. VIRTUALIZACIÓN DE PLATAFORMA.......................................................................................78
3.1.2.1. Máquina Virtual ....................................................................................................................78 3.1.2.1.1. Microsoft Virtual PC .....................................................................................................81 3.1.2.1.2. VMware.........................................................................................................................84 3.1.2.2. Máquinas virtuales como enrutadores...................................................................................87 3.2.
SIMULADORES..................................................................................................................................89
3.3. MÁQUINAS VIRTUALES VS. SIMULADORES ..............................................................................93 REFERENCIAS CAPÍTULO 3 ...................................................................................................................97
CAPÍTULO 4. IMPLEMENTACIÓN Y PRUEBAS DEL ENRUTADOR...............................................98 4.1. IMPLEMENTACIÓN DEL ENRUTADOR.........................................................................................98 4.1.1.
INSTALACIÓN..............................................................................................................................99
4.1.2. CONFIGURACIÓN ....................................................................................................................107
4.1.2.1. Configuración básica de los diferentes demonios ...............................................................110 4.1.2.2. Configuración de enrutamiento estático IPv4 utilizando el demonio Zebra........................111 4.1.2.3. Configuración de enrutamiento estático IPv6 utilizando el demonio Zebra........................114 4.1.2.4. Configuración de enrutamiento dinámico IPv4 utilizando el demonio ripd........................117 4.1.2.5. Configuración de enrutamiento dinámico IPv6 utilizando el demonio ripngd....................122 4.1.2.6. Configuración de enrutamiento dinámico IPv4 utilizando el demonio ospfd ................. ....129 4.1.2.7. Configuración de enrutamiento dinámico IPv6 utilizando el demonio ospf6d ................. ..134 4.1.2.8. Configuración de enrutamiento dinámico IPv4 utilizando el demonio bgpd ......................141 4.1.2.9. Configuración de enrutamiento dinámico IPv6 utilizando el demonio bgpd ......................148 4.2. PRUEBAS DE FUNCIONALIDAD, SIMULACIÓN Y COSTO ......................................................155 4.2.1. SIMULACIÓN DE ESCENARIOS ..............................................................................................155 4.2.2. PRUEBAS DE FUNCIONALIDAD DEL ENRUTADOR............................................................157 4.2.3. COSTO DEL ENRUTADOR .......................................................................................................158
4.2.3.1. Costo del proyecto...............................................................................................................158 4.2.3.2. Precio del producto..............................................................................................................160 REFERENCIAS CAPÍTULO 4 .................................................................................................................165
IV
CAPÍTULO 5. DESARROLLO DE LAS PRÁCTICAS DE LABORATORIO.....................................166 5.1. ELABORACIÓN E IMPLEMENTACIÓN DE LAS PRÁCTICAS...................................................166 5.1.1. PRÁCTICA 1: CAMINO MÁS CORTO CON RIP ......................................................................166
5.1.1.1. Objetivo...............................................................................................................................166 5.1.1.2. Descripción .........................................................................................................................167 5.1.1.3. Desarrollo............................................................................................................................167 5.1.2. PRÁCTICA 2: SELECCIÓN DE LA MEJOR RUTA...................................................................170
5.1.2.1. Objetivo...............................................................................................................................170 5.1.2.2. Descripción .........................................................................................................................170 5.1.2.3. Desarrollo............................................................................................................................171 5.1.3. PRÁCTICA 3: NAT .....................................................................................................................174
5.1.3.1. Objetivo...............................................................................................................................174 5.1.3.2. Descripción .........................................................................................................................174 5.1.3.3. Desarrollo............................................................................................................................175 5.1.4. PRÁCTICA 4: CONTROL BÁSICO DE ACCESO......................................................................179
5.1.4.1. Objetivo...............................................................................................................................179 5.1.4.2. Descripción .........................................................................................................................179 5.1.4.3. Desarrollo............................................................................................................................180 5.1.5. PRÁCTICA 5: PRUEBAS DE ACCESO REMOTO ....................................................................182
5.1.5.1. Objetivo...............................................................................................................................182 5.1.5.2. Descripción .........................................................................................................................183 5.1.5.2.1. Parte A: Acceso remoto con direccionamiento IPv4 ...................................................183 5.1.5.2.2. Parte B: Acceso remoto con direccionamiento IPv6 ...................................................184 5.1.5.3. Desarrollo............................................................................................................................184 5.1.5.3.1. Desarrollo Parte A.......................................................................................................184 5.1.5.3.2. Desarrollo Parte B .......................................................................................................186 5.1.6. PRÁCTICA 6: PRUEBAS CON TRANSFERENCIA DE ARCHIVOS.........................................188
5.1.6.1. Objetivo...............................................................................................................................188 5.1.6.2. Descripción .........................................................................................................................188 5.1.6.3. Desarrollo............................................................................................................................189 5.1.7. PRÁCTICA 7: CONTROL DETALLADO DE ACCESO.............................................................190
5.1.7.1. Objetivo...............................................................................................................................190 5.1.7.2. Descripción .........................................................................................................................190 5.1.7.3. Desarrollo............................................................................................................................192 5.1.8. PRÁCTICA 8: CONFIGURACIÓN DE UN ENLACE PPP........................................................195
5.1.8.1. Objetivo...............................................................................................................................195 5.1.8.2. Descripción .........................................................................................................................195 5.1.8.3. Desarrollo............................................................................................................................196 5.1.9. PRÁCTICA 9: TROUBLESHOOTING .......................................................................................198
V
5.1.9.1. Objetivo...............................................................................................................................198 5.1.9.2. Descripción .........................................................................................................................199 5.1.9.3. Desarrollo......................................................................................................................................... 199 5.2. ANÁLISIS DE LOS RESULTADOS OBTENIDOS..........................................................................201 5.3. PRÁCTICAS UTILIZANDO SIMULADORES ................................................................................201 5.3.1. PRÁCTICA A: CONFIGURACIÓN DE IGRP............................................................................202
5.3.1.1. Objetivo...............................................................................................................................202 5.3.1.2. Descripción .........................................................................................................................202 5.3.1.3. Desarrollo............................................................................................................................203 5.3.2. PRÁCTICA B: CONFIGURACIÓN DE EIGRP .........................................................................205
5.3.2.1. Objetivo...............................................................................................................................205 5.3.2.2. Descripción .........................................................................................................................205 5.3.2.3. Desarrollo............................................................................................................................206 REFERENCIAS CAPÍTULO 5 .................................................................................................................208
CAPÍTULO 6. CONCLUSIONES Y RECOMENDACIONES................................................................210 6.1. CONCLUSIONES..............................................................................................................................210 6.2. RECOMENDACIONES.....................................................................................................................214 BIBLIOGRAFÍA............................................................................................................................................216 REFERENCIAS ELECTRÓNICAS...............................................................................................................217 ANEXO A ....................................................................................................................................................A - 1 ANEXO B ....................................................................................................................................................B - 1 ANEXO C ....................................................................................................................................................C - 1 ANEXO D ....................................................................................................................................................D - 1 ANEXO E.....................................................................................................................................................E - 1
VI
ÍNDICE DE FIGURAS FIGURA 1-1. MODELO DE REFERENCIA ISO – OSI ................................................................................. 3 FIGURA 1-2. MODELO ISO – OSI VS. TCP / IP........................................................................................... 5 FIGURA 1-3. DIAGRAMA DE ENRUTAMIENTO....................................................................................... 8 FIGURA 1-4. COMPONENTES INTERNOS DE UN ENRUTADOR CISCO..............................................10 FIGURA 1-5. TIPOS DE TOPOLOGÍAS........................................................................................................13 FIGURA 1-6. SELECCIÓN DE LA MEJOR RUTA.......................................................................................15 FIGURA 1-7. EJEMPLO DE ALGORITMO DE VECTOR DISTANCIA.....................................................17 FIGURA 1-8. CONTEO AL INFINITO ..........................................................................................................18 FIGURA 1-9. EJEMPLO DE ALGORITMO DE ESTADO DE ENLACE ....................................................19 FIGURA 1-10. ESTRUCTURA DEL PAQUETE IP ......................................................................................21 FIGURA 1-11. DIVISIONES DE RED Y DE HOST EN UNA DIRECCIÓN IP...........................................24 FIGURA 1-12. CLASES EN LAS DIRECCIONES IP ...................................................................................24 FIGURA 1-13. ESTRUCTURA DE LA CABECERA IPv6 [7]......................................................................30 FIGURA 1-14. ESTRUCTURA DE SUBNETING EN IPv6. .........................................................................33 FIGURA 1-15. PROTOCOLOS IGP Y EGP...................................................................................................34 FIGURA 1-16. FORMATO DEL PAQUETE RIPv1 ......................................................................................36 FIGURA 1-17. FORMATO DEL PAQUETE RIPv2 ......................................................................................37 FIGURA 1.18. FORMATO DEL PAQUETE RIPng.......................................................................................38 FIGURA 1-19. FORMATO DEL CAMPO RTE DEL PROTOCOLO IPv6...................................................39 FIGURA 1-20. FORMATO DE LA CABECERA OSPFv2 ............................................................................43 FIGURA 1-21. FORMATO DE LA CABECERA OSPFv3. ...........................................................................44 FIGURA 2-1. SISTEMA DE CÓMPUTO.......................................................................................................48 FIGURA 2-2. ENRUTAMIENTO CON MPR EN WINDOWS NT ...............................................................55 FIGURA 2-3. ENRUTAMIENTO CON RRAS ..............................................................................................56 FIGURA 2-4. ESTRUCTURA DE LOS MODOS DE TRABAJO DE UN ENRUTADOR CISCO ..............61 FIGURA 2-5. NAT...........................................................................................................................................71 FIGURA 2-6. RED PRIVADA VIRTUAL......................................................................................................72
VII
FIGURA 3-1. VIRTUALIZACIÓN DE RECURSOS – RAID........................................................................77 FIGURA 3-2. VIRTUALIZACIÓN DE RECURSOS – CHANNEL BONDING...........................................77 FIGURA 3-3. MÁQUINA VIRTUAL – MONITOR DE MÁQUINA VIRTUAL (VMM) ............................79 FIGURA 3-4. MÁQUINAS VIRTUALES EN UN MISMO HARDWARE...................................................80 FIGURA 3-5. VIRTUAL PC ...........................................................................................................................82 FIGURA 3-6. OPCIONES DE SISTEMAS OPERATIVOS EN VIRTUAL PC 2007....................................83 FIGURA 3-7. OPCIONES DE SISTEMAS OPERATIVOS EN VMWARE SERVER..................................85 FIGURA 3-8. MÁQUINAS VIRTUALES COMO ENRUTADORES ...........................................................88 FIGURA 3-9. ENRUTADORES EN MÁQUINAS VIRTUALES..................................................................89 FIGURA 3-10. DISEÑO DE UNA RED EN EL SIMULADOR BOSON NETSIM ......................................91 FIGURA 3-11. INTERFAZ GRÁFICA DEL SIMULADOR PACKET TRACER.........................................92 FIGURA 4-1. INSTALACIÓN DE FEDORA CORE 5 ..................................................................................99 FIGURA 4-2. MENÚ DEL UTILITARIO SETUP........................................................................................102 FIGURA 4-3. SELECCIÓN DE LOS SERVICIOS.......................................................................................103 FIGURA 4-4. ESCENARIO PARA ENRUTAMIENTO IPv4 ESTÁTICO..................................................112 FIGURA 4-5. ESCENARIO PARA ENRUTAMIENTO IPv6 ESTÁTICO..................................................114 FIGURA 4-6. ESCENARIO PARA ENRUTAMIENTO DINÁMICO IPv4 CON RIP................................117 FIGURA 4-7. ESCENARIO PARA ENRUTAMIENTO DINÁMICO IPv6 CON RIPng............................122 FIGURA 4-8. ESCENARIO PARA ENRUTAMIENTO DINÁMICO IPv4 CON OSPF.............................129 FIGURA 4-9. ESCENARIO PARA ENRUTAMIENTO DINÁMICO IPv6 CON OSPFv3.........................134 FIGURA 4-10. ESCENARIO PARA ENRUTAMIENTO DINÁMICO CON BGP.....................................141 FIGURA 4-11. ESCENARIO PARA ENRUTAMIENTO DINÁMICO IPv6 CON BGP.............................148 FIGURA 4-12. SIMULACIÓN ESCENARIO ENRUTAMIENTO CON MÁQUINAS VIRTUALES .......156 FIGURA 4-13. DESARROLLO DEL PROYECTO EN EL TIEMPO..........................................................159 FIGURA 5-1. ESCENARIO PRÁCTICA 1...................................................................................................167 FIGURA 5-2. CAMINO MÁS CORTO.........................................................................................................168 FIGURA 5-3. REESTRUCTURACIÓN DE LA TABLA DE ENRUTAMIENTO ......................................169 FIGURA 5-4. ESCENARIO PRÁCTICA 2...................................................................................................170 FIGURA 5-5. SELECCIÓN DE LA MEJOR RUTA.....................................................................................171 FIGURA 5-6. REESTRUCTURACIÓN DE LA RUTA................................................................................173
VIII
FIGURA 5-7. REESTRUCTURACIÓN DEBIDO A FALLA DE ENLACE ...............................................174 FIGURA 5-8. ESCENARIO PRÁCTICA 3...................................................................................................175 FIGURA 5-9. ESCENARIO PRÁCTICA 4...................................................................................................180 FIGURA 5-10. ESCENARIO PRÁCTICA 5.A.............................................................................................183 FIGURA 5-11. ESCENARIO PRÁCTICA 5.B .............................................................................................184 FIGURA 5-12. ESCENARIO PRÁCTICA 6.................................................................................................188 FIGURA 5-13. ESCENARIO PRÁCTICA 7.................................................................................................191 FIGURA 5-14. ESCENARIO PRÁCTICA 8.................................................................................................196 FIGURA 5-15. ESCENARIO PRÁCTICA A................................................................................................203 FIGURA 5-16. ESCENARIO PRÁCTICA B ................................................................................................206 FIGURA A-1. MENÚ DE TEXTO PARA CONFIGURACIÓN DEL KERNEL ...................................... A - 3 FIGURA A-2. MENÚ GRÁFICO PARA COMPILACIÓN DEL KERNEL ............................................. A - 4
IX
ÍNDICE DE TABLAS TABLA 1-1. DESCRIPCIÓN DE LAS CAPAS DEL MODELO TCP / IP ..................................................... 6 TABLA 1-2. EJEMPLO DE DIRECCIÓN IP .................................................................................................23 TABLA 1-3. FORMATOS DE DIRECCIÓN..................................................................................................25 TABLA 1-4. MÁSCARAS DE SUBRED DE CADA CLASE .......................................................................26 TABLA 1-5. DIRECCIONES DE RED PRIVADAS......................................................................................27 TABLA 1-6. DIRECCIONES RESERVADAS EN IPv4 ................................................................................28 TABLA 1-7. PREFIJOS DE DIRECCIONES IPv6.........................................................................................32 TABLA 2-1. REQUERIMIENTOS BÁSICOS DE LAS VERSIONES DE WINDOWS ...............................54 TABLA 2-2. PUERTOS UTILIZADOS POR LOS DEMONIOS EN ZEBRA...............................................68 TABLA 3-1. CARACTERÍSTICAS DE HARDWARE DEL VIRTUAL PC 2007........................................83 TABLA 3-2. CARACTERÍSTICAS DE HARDWARE DEL VMWARE SERVER......................................86 TABLA 3-3. COMPARACIÓN DE CARACTERÍSTICAS ENTRE ENRUTADORES SOBRE MÁQUINAS VIRTUALES Y SIMULADORES.......................................................................95 TABLA 4-1. ESQUEMA DE PARTICIONAMIENTO DEL ENRUTADOR ..............................................100 TABLA 4-2. ESQUEMA DE DIRECTORIOS DE QUAGGA.....................................................................104 TABLA 4-3. RESULTADOS DE LAS PRUEBAS DE CONECTIVIDAD Y DE RUTA...........................158 TABLA 4-4. DURACIÓN DEL PROYECTO...............................................................................................159 TABLA 4-5. COSTO DEL PROYECTO.......................................................................................................160 TABLA 4-6. PRECIO FINAL DEL ENRUTADOR .....................................................................................161 TABLA 4-7. PRECIO DE INSTALACIÓN Y CONFIGURACIÓN DEL EQUIPO ....................................162 TABLA 4-8. COMPARACIÓN ENTRE ENRUTADORES.........................................................................163 TABLA 4-9. COMPARACIÓN DE PRECIOS ENTRE ENRUTADORES .................................................164 TABLA 5-1. RESULTADOS PRÁCTICA 4.................................................................................................182 TABLA 5-2. RESULTADOS PRÁCTICA 7.................................................................................................195
X
RESUMEN El presente proyecto de titulación pretende realizar la implementación de los protocolos enrutamiento, utilizando herramientas de código abierto bajo el sistema operativo Linux, con fines didácticos y con fines de producción. Comprende 6 capítulos en los cuales se realiza un análisis teórico del enrutamiento, de los sistemas operativos, herramientas de enrutamiento y las herramientas de virtualización y simulación, para luego presentar una parte práctica donde se puede observar la implementación y configuración del enrutador y su funcionamiento frente a algunos escenarios. En el primer capítulo se describe de una manera teórica a los diferentes algoritmos y protocolos de enrutamiento y su funcionamiento. El segundo capítulo pretende describir los sistemas operativos utilizados para enrutamiento, así como también las herramientas más importantes para el enrutamiento IP. El tercer capítulo destaca la importancia de utilizar máquinas virtuales en ambientes de enrutamiento. Además se presenta la importancia de utilizar simuladores frente a máquinas virtuales en ambientes de enrutamiento. En el cuarto capítulo se presenta la implementación del enrutador y una descripción detallada de su configuración. El quinto capítulo tiene información de prácticas de laboratorio en escenarios de enrutamiento utilizando el enrutador bajo Linux, para analizar su funcionamiento. El sexto capítulo presenta las conclusiones y recomendaciones referentes al presente proyecto de titulación. Al final incluye una sección de Anexos donde constan la compilación del Kernel, el manual de Quagga, así como las pruebas y archivos de configuración.
XI
PRESENTACIÓN En la actualidad es necesario estar familiarizado con la implementación y configuración de enrutadores, pero debido a las condiciones del medio no se disponen de recursos para cumplir con este propósito, puesto que los cursos y los equipos son muy costosos. El presente proyecto de titulación pretende dar una solución de bajo costo a esta problemática a través de la implementación de enrutadores bajo un sistema operativo libre y bajo herramientas de código abierto que permitan realizar enrutamiento tanto estático como dinámico. Es importante estar familiarizado con cada uno de los protocolos de enrutamiento dinámico, ya que de esto va a depender una decisión adecuada para la selección del mismo en el diseño de una red de datos. Además de esto, es importante tener presente cómo se configuran los diferentes equipos dentro de la red ya sea para realizar la implementación, para realizar modificaciones o para solucionar problemas. Dentro de las herramientas de código abierto para enrutamiento se destaca Quagga por su entorno de configuración de línea de comandos muy similar al que se tiene en los equipos CISCO, lo que permite que se puedan configurar los diferentes equipos debido a sus similitudes. Por otra parte la implementación de estos enrutadores en máquinas virtuales va a permitir que no se tenga que hacer inversiones costosas en equipos si se dispone de un laboratorio de computación; es más, no se necesitaría cambiar la configuración de los equipos ni cambiar el sistema operativo ya que todo se manejaría a través de máquinas virtuales. Es importante destacar que los ambientes a implementarse son reales y se está trabajando y analizando el funcionamiento real de los equipos y los procesos de enrutamiento, y lo que pretende además este proyecto es guiar y mostrar de una manera más didáctica y con la ayuda de un laboratorio de cómputo la realización de pruebas reales de enrutamiento.
CAPÍTULO 1 INTRODUCCIÓN AL ENRUTAMIENTO
1
CAPÍTULO 1. INTRODUCCIÓN AL ENRUTAMIENTO
Este capítulo describe las principales características de enrutamiento donde se destacan los modelos de referencia para los sistemas de comunicaciones, con el fin de poder describir dónde se produce el enrutamiento; además se presenta la clasificación de los enrutadores. Se realiza una breve explicación de los algoritmos de enrutamiento y también se destacan y describen los sistemas de direccionamiento más utilizados en la actualidad. Finalmente se presentan los principales protocolos de enrutamiento y una descripción breve de los mismos.
1.1. INTRODUCCIÓN Una red de datos está básicamente compuesta de elementos de software y hardware que brindan conectividad a distancias cortas o largas. Las redes de datos son utilizadas para el intercambio de recursos, servicios e información, siendo éstas esenciales para el desarrollo del mundo actual. Los elementos de software, en una red de datos, permiten al usuario la elaboración o ejecución de varias tareas utilizando los recursos que no se encuentran localmente sino en algún sitio remoto. Aplicaciones de correo electrónico o de compartición de archivos son claros ejemplos de la utilización de los recursos que ofrece una red de datos en beneficio del usuario. Las aplicaciones generalmente se presentan transparentes para el usuario, es decir que el usuario no se tiene que preocupar de los elementos de la red que le brindan conectividad siempre y cuando su aplicación funcione en perfecto estado; es aquí donde hay que hacer un análisis de la importancia que tienen estos equipos que brindan conectividad, y las funciones que desempeñan en la red de datos.
2
En lo que respecta a la parte física de la red de datos, en ésta se encuentran los computadores finales, los equipos de conectividad y los medios de propagación. Los computadores finales tienen sus sistemas operativos a través de los cuales el usuario puede interactuar y sobre los cuales se encuentran las diferentes aplicaciones. Los medios de propagación pueden ser guiados (medios físicos) o no guiados (medios inalámbricos). Por otro lado se encuentran los equipos de conectividad donde se encuentran los hubs , bridges , switches , modems y routers o enrutadores. Los enrutadores son los encargados de establecer el camino adecuado para que la información llegue al destino requerido. Los enrutadores no necesariamente tienen que ser equipos especializados para dicho propósito, pero si se debe considerar que entre más funcionalidad se requiera tener en un enrutador, éste debe ser más especializado para su función específica. Existen equipos que son desarrollados para desempeñar funciones exclusivas de un enrutador siendo su rendimiento muy bueno frente a otras soluciones y además brindan mucha más funcionalidad. Estos equipos al ser exclusivos para su propósito en particular tienen como desventaja su alto costo. Una solución al problema del alto costo de dichos equipos es la implementación de enrutadores a nivel de software en computadores personales de bajo costo. Esto se lo puede hacer con paquetes computacionales específicos que permitan el manejo del enrutamiento.
1.2. CARACTERÍSTICAS PRINCIPALES Dentro del enrutamiento se pueden destacar varias características importantes, pero para esto hay que describir en una manera sencilla la pila de capas que presentan el modelo de referencia ISO – OSI 1 y el modelo de referencia TCP / IP. 1
Modelo de referencia de Interconexión de Sistemas Abiertos (OSI) creado por la Organización Internacional de Estandarización (ISO) cuyo objetivo fue crear un conjunto de estándares para garantizar la interoperabilidad entre los tipos de tecnología producidas por los distintos fabricantes
3
1.2.1. MODELO DE REFERENCIA ISO – OSI
El modelo de referencia ISO – OSI está constituido por 7 capas donde cada una realiza una función concreta. Este modelo a pesar de no ser una arquitectura para una tecnología definida, sirve de referencia y de guía para el establecimiento de la comunicación entre los equipos de conectividad de los distintos fabricantes. Este modelo no se lo pude considerar como una arquitectura ya que no define el protocolo a utilizar en cada una de las capas. Las capas que conforman el modelo de referencia ISO – OSI son la capa física, de enlace, de red, de transporte, de sesión, de presentación y aplicación tal como se muestra en la Figura 1-1.
Fuente: http://www.geocities.com/txmetsb/el_modelo_de_referencia_osi.htm Figura 1-1. Modelo de Referencia ISO – OSI
La Capa Física es la encargada de la transmisión de la información a través de los medios de transmisión como por ejemplo el par de cobre, el cable coaxial, la fibra óptica, microonda, señales de radio entre otros. Aquí también se define la codificación, el tipo de señal, modulación, voltajes, corriente y todo aquello que
4
tiene que ver con el medio de transmisión como los conectores y conversores de medio. [1] La Capa de Enlace es la encargada de que la información se transmita sin errores agrupando los bits de información en tramas. Estas tramas se construyen de tal manera de que tengan una secuencia y una delimitación definida para su reconocimiento. La capa de enlace además se encarga del control de flujo de la información. La Capa de Red es la encargada de hacer que la información llegue del origen a su destino, estableciendo el camino y utilizando para este propósito tablas de enrutamiento, que pueden ser estáticas o dinámicas. En esta capa también se encuentran el control de la congestión de la red; además esta capa es la encargada de la interconexión entre redes heterogéneas. [1] La Capa de Transporte se encarga de tomar los datos de la capa superior, capa de sesión, y dividirlos en paquetes más pequeños; además se encarga de garantizar que dichos paquetes lleguen a su destino sin ningún problema. A diferencia de las 3 primeras capas ésta establece una conexión virtual extremo a extremo como se puede observar en la Figura 1-1. La Capa de Sesión como su nombre lo indica permite establecer una sesión de comunicación entre los extremos, es decir entre el origen y el destino. Esta capa es la que coordina y organiza el diálogo entre los extremos. La Capa de Presentación se encarga de la estructura de los datos; es decir, se encarga de los formatos de los datos para que éstos puedan ser interpretados o entendidos por la aplicación. La Capa de Aplicación define los diferentes protocolos para el intercambio de información, tales como los protocolos para correo electrónico o Terminal virtual.
5
1.2.2. MODELO DE REFERENCIA TCP / IP
El modelo de referencia TCP / IP nace a partir de una investigación del Departamento de Defensa de los Estados Unidos que pretendía diseñar una red que pudiera sobrevivir diversas condiciones incluyendo conflictos bélicos. Esta investigación sirvió para que este modelo pueda ser usado ya sea con cables de cobre, fibra óptica, enlaces satelitales, o enlaces de radio, entre otros medios. TCP / IP nació como un conjunto de protocolos que dio lugar a la arquitectura y al modelo que actualmente se conoce, y tiene este nombre por los dos protocolos más importantes que lo conforman IP ( Internet Protocol ) y TCP (Transfer Control Protocol ). El modelo TCP / IP es la base del Internet, siendo el más popular a nivel mundial, por el mismo hecho de que el Internet es la red de redes. A diferencia del modelo ISO – OSI, el modelo TCP / IP sí es una arquitectura ya que en cada una de las capas se define el protocolo a utilizarse. En la Figura 1-2 se puede observar las capas del modelo TCP / IP y las diferencias respecto al modelo ISO – OSI. Las capas presentes en el modelo TCP / IP son las capas Host – Red, Internet, Transporte y Aplicación.
Fuente: http://neo.lcc.uma.es/evirtual/cdd/tutorial/modelos/Mtcp.html Figura 1-2. Modelo ISO – OSI vs. TCP / IP
6
En la Tabla 1-1 se especifican las capas del modelo TCP / IP y una descripción de cada una de ellas y algunos de los protocolos que utiliza. Capa
Descripción
Protocolos
Aplicación Define los protocolos de aplicación TCP/IP y cómo se HTTP, Telnet, FTP, conectan los programas de host a los servicios del nivel de TFTP, SNMP, DNS, transporte para utilizar la red. SMTP, X Windows y otros protocolos de aplicación Transporte Permite administrar las sesiones de comunicación entre TCP, UDP, RTP equipos host. Define el nivel de servicio y el estado de la conexión utilizada al transportar datos. Internet
Empaqueta los datos en datagramas IP, que contienen IP, ICMP, ARP, RARP información de las direcciones IP de origen y destino utilizada para reenviar los datagramas entre hosts y a través de redes. Realiza el enrutamiento de los datagramas IP.
Host - Red Especifica información detallada de cómo se envían Ethernet, Token Ring, físicamente los datos a través de la red, que incluye cómo FDDI, X.25, Frame se realiza la señalización eléctrica de los bits mediante los Relay dispositivos de hardware que conectan directamente con un medio de red, como un cable coaxial, un cable de fibra óptica o un cable de cobre de par trenzado.
Fuente: http://www.microsoft.com/technet/prodtechnol/windowsserver2003 Tabla 1-1. Descripción de las capas del modelo TCP / IP
Una de las características importantes del modelo TCP / IP es que en la capa física (Host-Red) no está definido un protocolo específico, por lo que se pueden utilizar varias tecnologías de redes LAN o WAN 2 tales como Ethernet, FDDI, Frame Relay, etc.
2
LAN (Local Area Network ) o redes de área local son redes locales que cubren una distancia de unos cuantos kilómetros y permiten el intercambio de información y recursos mientras que WAN (Wide Area Network ) o redes de área extendida son redes que abarcan extensiones geográficas extensas y generalmente interconectan LANs. Cada una de éstas tiene sus propias tecnologías definidas para cumplir sus propósitos como por ejemplo Ethernet en redes LAN y Frame Relay en redes WAN.
7
1.2.3. ENRUTADORES
Los enrutadores son dispositivos de interconexión de redes o segmentos de redes que pueden estar desarrollados tanto en software o en hardware, y cuyo objetivo es definir y establecer el camino para que los datos lleguen desde su origen a su destino. Los enrutadores funcionan como puntos intermedios en la red de datos, en donde se toman decisiones respecto a los caminos que deben seguir los paquetes de información para llegar a su destino. Los enrutadores trabajan en la capa de red del modelo de referencia ISO – OSI, pues en esta capa se produce el enrutamiento. Cada una de las capas del modelo ISO – OSI proporciona servicios 3 a las capas que están sobre ellas, y en el caso de la capa de red no es la excepción puesto que ésta entrega sus servicios a la capa de transporte a través de la interfaz 4 que se encuentra entre ambas. Los servicios que se pueden definir en la capa de red son dos: Servicios orientados a conexión Servicios no orientados a conexión
Las redes cuyos servicios son orientados a conexión utilizan circuitos virtuales en donde se pretende establecer un solo camino durante toda la transmisión de información; este único camino es seleccionado cuando se establece la conexión. El problema de este tipo de redes es que si se pierde la comunicación en alguno de los puntos del circuito (en un enrutador por ejemplo) se tiene que establecer nuevamente la conexión y el nuevo circuito. Por otro lado las redes cuyos servicios no son orientados a la conexión utilizan datagramas o paquetes de información que toman su propio camino para llegar a su destino, es decir no se establece un camino definido para cada paquete de información. Aquí la ventaja radica en que si se perdió un punto intermedio se
3
“Servicio es un conjunto de primitivas que una capa ofrece a su capa superior.”[2] Las primitivas pueden ser de Petición, Indicación, Respuesta y Confirmación. 4 Interfaz es el grupo normas de intercomunicación de las capas
8
puede elegir otro camino para el envío del paquete de información sin perder la comunicación. Los enrutadores utilizan tablas de enrutamiento para cumplir su propósito de dirigir a los datos a su destino. Estas tablas de enrutamiento pueden ser dinámicas o estáticas según sea el caso. Un enrutador trabaja como un nexo o como un punto de conexión entre redes distintas, y las tablas de enrutamiento se llenan de acuerdo a direcciones, siendo el caso particular de redes TCP / IP la dirección IP la que sirve para llenar dichas tablas. Se puede observar en la Figura 1-3 cómo se encuentra estructurada una tabla de enrutamiento para llegar a los diferentes destinos.
Figura 1-3. Diagrama de enrutamiento
Dentro de los enrutadores se pueden diferenciar dos clases bien definidas, los enrutadores basados en hardware y los enrutadores basados en software.
9
1.2.3.1. Enrutadores Basados en Hardware
Los enrutadores basados en hardware son equipos que fueron diseñados para cumplir las funciones de enrutadores, es decir que sus componentes de hardware fueron escogidos para que cumplan un papel específico en lo que concierne al enrutador, como son la memoria, las interfaces, el procesador, etc. Los enrutadores basados en hardware son computadores especializados para su propósito que es el enrutamiento, y al igual que los computadores personales disponen de un sistema operativo que es quien tiene la información necesaria para el manejo de sus componentes de hardware como las interfaces y la memoria; además dispone de las funciones necesarias para el manejo del enrutamiento en general aparte de otras funciones específicas como el control de ancho de banda y controles de acceso. Este sistema operativo es el encargado de poner en marcha los algoritmos de enrutamiento de los diferentes protocolos para que se puedan escoger los caminos más adecuados por donde debe ir la información. Actualmente existen varios fabricantes de enrutadores quienes día a día siguen investigando para darles mayor funcionalidad a sus equipos, para que el usuario se sienta conforme y satisfecho con su funcionamiento. Algunos de los fabricantes más conocidos son Cisco Systems, Nortel, 3Com, Alcatel, Motorola, Huawei Technologies. En la Figura 1-4 se puede apreciar las partes de hardware que conforman un enrutador Cisco. Los equipos Cisco utilizan como sistema operativo el Cisco IOS que viene de las siglas Cisco Internetwork Operating System y que será descrito en el siguiente capítulo. La selección del equipo a utilizar va a depender de las necesidades y de las circunstancias para las cuales va a ser utilizado y también de la funcionalidad que
10
tenga el enrutador además del costo, puesto que entre más funciones y entre más especializado sea el equipo su costo va a elevarse. No siempre se hace la selección del equipo adecuadamente ya que de acuerdo a las necesidades éstos están subutilizados, por lo que habría que buscar soluciones que puedan brindar las mismas ventajas para los requerimientos específicos pero a un menor costo.
Fuente: http://cisco.netacad.net Figura 1-4. Componentes internos de un enrutador Cisco
1.2.3.2. Enrutadores Basados en Software
Los enrutadores basados en software son esencialmente computadores personales con un sistema operativo estándar donde se encuentran instalados paquetes computacionales que permiten el manejo del enrutamiento. Estos paquetes computacionales pueden ser parte del sistema operativo estándar o pueden ser paquetes desarrollados para determinado sistema o sistemas operativos cuyo objetivo específico es el manejo de los protocolos de enrutamiento. Los enrutadores basados en software no poseen elementos de hardware especializado para el propósito de encaminar la información, sino que más bien son computadores personales a los cuales se les ha dado la característica de poder enrutar utilizando programas que ejecutan los diferentes algoritmos de enrutamiento y se adaptan a las características de hardware que poseen estos computadores. Es por este motivo que hay que tener en cuenta que el
11
rendimiento de estos enrutadores, va a depender de las características de hardware que tiene el computador personal sobre el cual se está instalando el paquete computacional, y también hay que tener en cuenta las características del sistema operativo sobre el cual se está instalando el paquete. Estos paquetes computacionales son desarrollados por empresas, que como en todo software, pueden ser de código abierto o pueden ser comerciales. De aquí parte la decisión respecto a la utilización de estos paquetes. Lo interesante de los mismos es que se puede obtener mucho soporte e información en el Internet ya que existen foros desarrollados solo para dicho propósito y se puede conseguir información en los sitios web de los programas. Como ejemplo de estos paquetes se pueden mencionar a XORP, Zebra, Quagga, Routed y Freesco que son de herramientas de código abierto y a Gated que es una herramienta comercial. La selección del software de enrutamiento a utilizar así como del sistema operativo va a depender de la utilidad que va a tener este enrutador, y además como es de suponer va a depender del costo del sistema operativo y del paquete de enrutamiento. Algunos sistemas operativos estándar como Windows XP o Windows 2003 por ejemplo tienen sistemas integrados de enrutamiento como la “Conexión Compartida a Internet” que son muy sencillos de configurar, pero su funcionalidad es limitada ya que no manejan protocolos de enrutamiento. De igual manera hay paquetes que solo manejan rutas estáticas y que en ciertos casos va a ser suficiente según las necesidades y el uso que se le de al enrutador.
1.3. ENRUTAMIENTO Enrutamiento o encaminamiento a breves rasgos es dirigir algo hacia su destino a través de un camino determinado; sin embargo en lo que se refiere a las redes de datos se define al enrutamiento como al proceso de determinar el mejor camino de entre las posibilidades existentes para que el paquete de información llegue a su destino. [8]
12
La función de enrutamiento la realizan los enrutadores, quienes utilizan tablas de rutas para cumplir su propósito. Las tablas de rutas se las puede llenar estáticamente o dinámicamente a través de algoritmos de enrutamiento. 1.3.1. DEFINICIONES
Es necesario establecer algunas definiciones para poder entender de mejor manera lo que es el enrutamiento y los protocolos de enrutamiento. 1.3.1.1. Nodo
Punto donde confluyen varios elementos de la red; un nodo puede ser un computador personal, un servidor o un enrutador. 1.3.1.2. Topología de Red
Se define como topología de red a la disposición lógica que determina cómo se encuentran distribuidos los nodos en la red. Se pueden tener algunos tipos de topologías como se observa en la Figura 1-5. 1.3.1.3. Métrica
La métrica es un valor o un conjunto de valores que permiten comparar rutas y a partir de esto decidir cuál es la mejor. Estos valores pueden estar dados por el ancho de banda, costo de la comunicación, retardo, número de saltos, carga, MTU (unidad máxima de transferencia), costo de ruta, y confiabilidad. Los protocolos de enrutamiento establecen las métricas que utilizan. 1.3.1.4. Algoritmo de Enrutamiento
“El algoritmo de enrutamiento es aquella parte de software de la capa de red encargada de decidir la línea de salida por la que se transmitirá un paquete de entrada. Si la subred usa datagramas internamente, esta decisión debe hacerse
13
cada vez que llega un paquete de datos de entrada, dado que la mejor ruta podría haber cambiado desde la última vez.” [1]
Figura 1-5. Tipos de Topologías
1.3.1.5. Protocolo de Enrutamiento
Los protocolos de enrutamiento son un conjunto de normas y estándares que trabajan en la capa de red del modelo de referencia ISO – OSI y que permiten a los enrutadores compartir información de la topología y estado de la red; este intercambio de información sirve para el mantenimiento de las tablas de enrutamiento. 1.3.1.6. Protocolos Enrutables
Los protocolos enrutables son un conjunto de normas y estándares que sirven para el direccionamiento del tráfico; estos protocolos enrutables proveen de la
14
información necesaria en su cabecera para que el paquete pueda ser enviado de un sitio a otro basándose generalmente en un esquema de direccionamiento; en otras palabras un protocolo enrutable proporciona un esquema de direccionamiento utilizable por un protocolo de enrutamiento. [3] 1.3.1.7. Sistema Autónomo
Es un conjunto de redes y de enrutadores que se encuentran bajo la administración de una entidad y que tienen una política de enrutamiento. [7] En general el Internet está conformado por un conjunto grande de sistemas autónomos. 1.3.2. ENRUTAMIENTO ESTÁTICO
El enrutamiento estático parte de una configuración manual realizada por el administrador, siendo éste el que decide cuál va a ser la ruta más adecuada para los paquetes de datos de acuerdo a la topología y a las características de la red; esta ruta va a permanecer inalterable durante el proceso de enrutamiento hasta que el administrador la vuelva a cambiar de una manera manual. Generalmente se utiliza este tipo de enrutamiento cuando se tiene un alto conocimiento de la red y cuando la misma no es muy compleja. [8] El administrador de la red debe llenar manualmente la tabla de enrutamiento del enrutador, siendo ésta la base del enrutamiento estático. Hay que destacar que si hay cambios en la red, es el administrador quien debe hacer los cambios en las rutas, ya que en este caso los enrutadores no toman decisiones; también hay que destacar que entre más grande y compleja sea la red más tiempo de administración va a requerir. El administrador, para escoger la ruta estática más adecuada, puede utilizar algoritmos para dicho propósito, que pueden ser realizados manualmente o valiéndose de herramientas computacionales, como el algoritmo de la ruta más corta, en donde se escoge la mejor ruta estableciéndose una métrica determinada
15
como por ejemplo en número de saltos o el tráfico o el retardo. En la Figura 1-6 se puede observar lo expuesto; en el primer gráfico se escoge una ruta, en la que la métrica es el número de saltos para llegar de A a G. Mientras la segunda parte de la Figura 1-6 se escoge la ruta considerando la carga, es decir es un enrutamiento basado en flujo.
E B F A
D G C
15
E B
12
10
115 45 15
F 20
A 100
50
D
18
120
G C
Figura 1-6. Selección de la mejor ruta
Otro algoritmo que se puede utilizar es el de inundación, donde se envía los paquetes entrantes por todas las rutas de salida; esta opción genera muchos paquetes duplicados y mucho tráfico por lo que no suele ser usada, aunque en redes que necesitan ser muy robustas puede ser una alternativa. Una variante de este algoritmo es la inundación selectiva en la cual se inundan las rutas que posiblemente sean las correctas.
16
1.3.3. ENRUTAMIENTO DINÁMICO
El enrutamiento dinámico parte de un conjunto de algoritmos que determinan la mejor ruta utilizando las métricas necesarias para dicho propósito; aquí se llenan las tablas de enrutamiento de acuerdo a los resultados que brindan dichos algoritmos. Las tablas de enrutamiento varían de acuerdo a las condiciones de la red, y los encargados de dar a conocer a los demás enrutadores la topología y las condiciones de la red son los protocolos de enrutamiento. La administración en el enrutamiento dinámico es más sencilla puesto que el algoritmo es el que se encarga de encontrar el mejor camino, y el administrador únicamente tiene que configurar los protocolos que se van a utilizar para la determinación de la mejor ruta; además ante cualquier cambio en la red como aumento o disminución de nodos, incremento de retardo, variaciones en el tráfico o fallas en la topología, etc., el algoritmo de enrutamiento lo resuelve sin tener que depender de una configuración manual extra del administrador. Entre las características que se pueden mencionar del enrutamiento dinámico se tienen las siguientes [1]: Escalabilidad Robustez Simplicidad Rápida convergencia Provee siempre las mejores trayectorias 5
Entre los principales algoritmos de enrutamiento dinámico se tienen al algoritmo de vector distancia y al algoritmo de estado de enlace. 1.3.3.1. Algoritmo de Vector Distancia
El algoritmo de vector distancia conocido también como algoritmo de Bellman – Ford realiza una actualización de las tablas de rutas a través del intercambio de
5
La mejor trayectoria en función a la métrica a utilizarse y dependiendo del protocolo
17
tablas entre enrutadores vecinos, donde se encuentran las mejores distancias conocidas para llegar a determinado destino; además estas tablas incluyen las líneas por la que se deben dirigir los paquete para llegar al destino. La mejor ruta va a depender de la métrica que se esté utilizando, ésta puede ser tiempo de retardo o número de saltos y el enrutador se va a centrar en analizar esa información. La tabla de enrutamiento se va formar de dos partes, la distancia (que va a depender de la métrica utilizada) y la línea de salida. En la Figura 1-7 se puede observar cómo se van estructurando las tablas de enrutamiento si se quiere llegar del nodo K al nodo I; la métrica tomada para el ejemplo es el número de saltos por lo que la distancia que va a tener K a sus vecinos B, E, H va a ser siempre 1. B
E
H
Distancia
Línea
A
1
2
3
2
B
B
0
1
2
1
B
C
2
2
3
3
BoE
D
1
1
3
2
BoE
E
1
0
2
1
E
F
2
1
1
2
EoH
G
3
2
2
3
EoH
H
2
2
0
1
H
I
4
3
2
3
H
J
3
2
1
2
H
K
1
1
1
0
-
Figura 1-7. Ejemplo de algoritmo de vector distancia
Este algoritmo es bastante sencillo pero tiene problemas ya que su convergencia cuando un nodo desaparece es muy lenta. Un problema muy conocido es el del conteo al infinito y para explicar este problema se tomará en cuenta la Figura 1-8, considerando que la métrica utilizada es el número de saltos para que la explicación sea más sencilla.
18
Figura 1-8. Conteo al infinito
En un principio el nodo A se encuentra activo por lo que el nodo B conoce que A y C se encuentran a 1 salto, mientras que el nodo C intercambia tablas con B y actualiza su tabla registrando que A se encuentra a 2 saltos. El momento en que el nodo A desaparece (por alguna falla por ejemplo), B actualiza su tabla de enrutamiento con la información que le entrega C, por lo que B sabe que A se encuentra a 2 saltos de C y actualiza su tabla registrando que A se encuentra a 3 saltos. Después C sabe que B y D tienen un trayectoria a A de 3 saltos por lo que actualiza su tabla registrando que la distancia a A es de 4 saltos y así sucesivamente dando lugar a un crecimiento de las distancias sin limitaciones. Para solucionar el problema del conteo al infinito se han planteado muchas soluciones, de donde una de las más conocidas pero no la más efectiva es la del Horizonte Dividido. En esta solución cuando un enrutador recibe un paquete, marca como infinito al origen para que así no se pueda regresar y también se actualizan las tablas de los demás enrutadores como que este enrutador es inalcanzable; esto evita el conteo al infinito pero no es aplicable a todas las topologías. 1.3.3.2. Algoritmo de Estado de Enlace
El algoritmo de estado de enlace nace a partir de que los enlaces no tenían el mismo ancho de banda y además porque el algoritmo de vector distancia era muy lento en converger. Para que se cumpla el algoritmo de estado de enlace se deben cumplir 5 etapas [1]:
19
1.3.3.2.1. Descubrir a sus vecinos y conocer sus direcciones de red
Se utiliza un paquete especial llamado Hello que se envía por todas las líneas; cada uno de los enrutadores vecinos devuelve el paquete con una dirección única. 1.3.3.2.2. Medición del costo de la línea
En este punto se mide el retardo que existe entre el enrutador y sus vecinos enviando un paquete de ECO (ECHO); dicho paquete es regresado por los enrutadores y se calcula en tiempo que se demoró en ir y venir, luego este valor se divide para dos para tener el valor del retardo del paquete. Esta prueba se la puede hacer varias veces y obtener un promedio para conseguir mejores resultados. 1.3.3.2.3. Construcción de los paquetes de estado de enlace
En esta parte cada enrutador elabora las tablas de enrutamiento con los valores de retardo a sus vecinos, como se puede observar en la Figura 1-9.
Fuente: TANENBAUM, Andrew S.; Redes de Computadoras. Cuarta Edición. Figura 1-9. Ejemplo de algoritmo de estado de enlace
20
La decisión importante en este proceso es el momento de la construcción de las tablas donde las opciones de actualización pueden ser periódicamente o cuando existan cambios en la red. 1.3.3.2.4. Distribución de los paquetes de estado de enlace
Para la distribución de los paquetes de estado de enlace, que sirve para que los enrutadores vecinos actualicen sus rutas, se utiliza la inundación pero con ciertas consideraciones. En cada paquete se establece una secuencia que es revisada por los enrutadores, si el paquete es duplicado se descarta, si es nuevo se reenvía por todas las líneas excepto por la que llegó, y si es de secuencia menor se lo rechaza. 1.3.3.2.5. Cálculo de nuevas rutas
Después de todos los pasos anteriores se tiene la información completa para poder construir la tabla definitiva de rutas de donde se escogen las mejores para que se pueda producir el enrutamiento.
1.4. IPv4 VS. IPv6 El protocolo IP es un protocolo enrutable y es el más utilizado en la actualidad ya que éste es la parte esencial del Internet; por este motivo es necesario hacer una descripción del protocolo IP y del direccionamiento IP en sus dos versiones más populares y utilizadas en la actualidad IPv4 e IPv6. 1.4.1. PROTOCOLO IPv4
El protocolo IPv4 es la versión 4 del Protocolo de Internet y ésta fue su primera versión, normalmente se menciona a este protocolo sólo como IP. El protocolo IP pertenece a la capa de Internet del modelo de referencia TCP / IP y es un protocolo no orientado a conexión. Este protocolo es un protocolo enrutable siendo éste el responsable del direccionamiento y de la fragmentación de los
21
datos. [4] El Internet utiliza el modelo TCP / IP en toda su estructura dando lugar a la importancia de dicho protocolo. El protocolo IP define a los paquetes IP y a su estructura; en la Figura 1-10 se puede ver cómo se encuentra conformado dicho paquete [4]. Esta estructura está definida en el RFC 6 791. El datagrama IP está conformado por la Cabecera y los Datos. La cabecera tiene una longitud fija de 20 octetos y una parte variable destinada para opciones.
Figura 1-10. Estructura del Paquete IP
A continuación se describen cada uno de los campos del paquete IP.
Versión: Está conformada por 4 bits e indica la versión del protocolo IP. Para la estructura presentada en la Figura 1.10 se utiliza la versión 4. Tamaño de Cabecera: Conformada por 4 bits presenta la longitud de la cabecera expresada en múltiplos de 32 bits. El valor mínimo es 5, correspondiente a 160 bits = 20 bytes. Tipo de servicio: Está conformado por 8 bits que a su vez se dividen en : Prioridad (3 bits). Un valor de 0 indica baja prioridad y un valor de 7, prioridad máxima. ▫
6
Request For Comments
22
Los siguientes tres bits indican cómo se prefiere que se transmita el mensaje; estos bits son Bit D ( Delay ), Bit T (Throughput ) y Bit R (Reliability ) Los dos bits restantes no tienen uso. Longitud total: Conformado por 16 bits expresa la longitud total del paquete expresado en bytes. Como el campo tiene 16 bits, la máxima longitud posible de un datagrama será de 65535 bytes. Identificación: Constituido por 16 bits, presenta un número de secuencia que junto a la dirección origen, dirección destino y el protocolo utilizado, identifica de manera única un paquete en toda la red. Si se trata de un paquete fragmentado, llevará la misma identificación que el resto de fragmentos. Indicadores o Banderas: Compuesto por 3 bits aunque solo 2 están utilizados; el bit que no está utilizado siempre debe estar en 0. El bit MF (Más fragmentos) indica que existen más paquetes, y el bit de NF (No fragmentar) prohíbe o autoriza la fragmentación del paquete. Posición del fragmento: Constituido por 13 bits indica la posición en la cual se insertará el fragmento el momento de reconstruir el paquete. Si el paquete no está fragmentado, este campo tiene el valor de cero. Tiempo de vida o TTL: Constituido por 8 bits, representa el número máximo de segundos que puede estar un paquete en la red. A este número se le resta 1 por cada vez que se atraviesa un enrutador. Cuando llegue a cero, el paquete se descarta y se devuelve un mensaje ICMP 7 de tipo "tiempo excedido" para informar al origen de la incidencia. Protocolo: Compuesto por 8 bits indica el protocolo utilizado en el campo de datos. Checksum: Conformado por 16 bits, contiene la suma de comprobación de errores sólo para la cabecera del datagrama. Las capas superiores son las encargadas de la verificación de los errores en los datos. ▫
▫
7
ICMP es Protocolo de Control de Mensajes de Internet ( Internet Control Message Protocol ) definido en el RFC 792 y es el protocolo de determinación y de notificación de errores del protocolo IP. [7]
23
Dirección origen: Conformada por 32 bits, contiene la dirección IP del origen. Dirección destino: Constituida por 32 bits, contiene la dirección IP del destino. Opciones IP: No es un campo obligatorio generalmente utilizado para pruebas de red y depuración. Relleno: Si existiese el campo de Opciones IP y éstas no completan un múltiplo de 32 bits se completa hasta conseguir dicho múltiplo.
Como se puede ver en la estructura, una de las partes esenciales del paquete IP es el direccionamiento, en el cual se establece la dirección de destino y la de origen. El direccionamiento al ser una parte importante para el enrutamiento requiere ser estudiado y analizado de una manera adecuada. 1.4.2. DIRECCIONAMIENTO IPv4
El direccionamiento IP es importante en el enrutamiento para determinar hacia donde debe dirigirse el paquete de datos, ya que cada uno de los paquetes IP contiene las direcciones de origen y destino. Las direcciones IP son un conjunto de 32 bits separadas por un punto después de cada octeto, por lo que se tienen 4 octetos en las direcciones IP. Generalmente se representan a los octetos en notación decimal dando como resultado valores de cada octeto entre 0 y 255. Un ejemplo de una dirección IP en formato decimal con su correspondiente formato binario se muestra en la Tabla 1-2. Formato Decimal
Formato Binario
200.32.55.20
11001000.00100000.00110111.00010100 Tabla 1-2. Ejemplo de dirección IP
Las direcciones IP están conformadas de dos partes, una parte que corresponde al identificador de red (los primeros bits de la dirección IP) y otra al identificador
24
de host (los últimos bits de la dirección IP) como se puede observar en la Figura 1-11. Esta separación sirve para determinar el número de estaciones que se tiene en una red y el número de redes en total.
Fuente: http://cisco.netacad.net Figura 1-11. Divisiones de Red y de Host en una Dirección IP
En un principio a las direcciones de red se las clasificó en 5 clases de acuerdo a sus identificadores de red. Esta clasificación se la hizo tomando como base los octetos; así se tiene la clase A para las redes cuyo identificador de red pertenece al primer octeto, clase B para las que el identificador de red pertenece al primero y segundo octeto y clase C a las que el identificador pertenece a los tres primeros octetos. La clase D es aquella que es utilizada para multicast ; la clase E es usada para fines reservados de investigación. En la Figura 1-12 se puede observar de mejor manera esta división por clases.
Fuente: http://cisco.netacad.net Figura 1-12. Clases en las direcciones IP
25
En la Tabla 1-3 se puede observar los rangos de direcciones para cada una de las clases.
Clase
Dirección Desde
hasta
A
1.0.0.0
127.255.255.255
B
128.0.0.0
191.255.255.255
C
192.0.0.0
223.255.255.255
D
224.0.0.0
239.255.255.255
E
240.0.0.0
247.255.255.255
Tabla 1-3. Formatos de dirección [1]
Además de la dirección IP se tiene un número de 32 bits, de igual manera separado en octetos por puntos llamado Máscara de Subred, que permite determinar o delimitar una subred. Este número a diferencia de la dirección IP está conformado por un 1s y 0s ordenados consecutivamente; los 1s se encuentran al lado izquierdo de la máscara y los 0s al lado derecho. Un ejemplo de una máscara de red es 11111111.11111111.11111111.00000000 o en notación decimal 255.255.255.0. Para determinar el número de hosts que va a tener determinada subred es necesario considerar el número de 0s que tiene la máscara de subred, de donde el número de hosts 8 se obtienen elevando a la potencia 2 al número de 0s. Por otro lado los 1s permiten establecer el número de subredes que se pueden tener. En la Tabla 1-4 se pueden observar las máscaras de subred de cada una de las clases. La relación que se establece entre la dirección IP y la máscara de subred es un AND lógico; con esta operación se puede obtener la red a la que pertenece determinada dirección IP.
8
Es necesario tomar en cuenta que para calcular el número de hosts efectivos se debe quitar la dirección de subred y la dirección de broadcast .
26
Clase
Formato binario
A B C
11111111.00000000.00000000.00000000 11111111.11111111.00000000.00000000 11111111.11111111.11111111.00000000
Formato decimal
Número de Hosts
255.0.0.0 16777214 255.255.0.0 65534 255.255.255.0 254
Tabla 1-4. Máscaras de Subred de cada Clase
Actualmente esta clasificación por clases ha quedado relegada debido a la gran demanda de direcciones IP y al desperdicio de direcciones que se presenta al tener una máscara de subred no adecuada; por ejemplo si se necesitan 5 hosts en una clase C y se está utilizando una máscara de 255.255.255.0 se tendrá la opción de 254 direcciones 9 para host , por lo que se tendrían 249 sin utilizar. La solución a este problema es las máscaras de subred de tamaño variable o VLSM10. En realidad VLSM es bastante sencillo puesto que se vuelven a subdividir las redes en redes de menor tamaño de acuerdo a las necesidades. En el ejemplo anterior ya no se tomaría una máscara de 255.255.255.0 sino que se tomaría una máscara de 255.255.255.248 que permiten asignar 6 hosts. VLSM también es muy útil en el enrutamiento ya que se pueden agrupar redes o dividirlas de tal manera que sea más fácil la administración; el proceso de dividir a las subredes se conoce como subneting y el proceso de agrupar redes se conoce como superneting . A la máscara de subred se la puede representar con un número entero llamado CIDR, siendo éste el número de 1s que la máscara de subred disponga; así por ejemplo se tiene que a una máscara 255.255.255.0 o en binario 11111111.1111111.11111111.00000000 se la puede representar como /24. Una dirección IP con su máscara en formato de CIDR sería 172.16.40.6 /24. 9
En total son 254 direcciones debido a que la primera dirección es la dirección de red y la última es la dirección de broadcast . 10 VLSM en inglés viene de Variable Length Subnet Mask
27
Una de las soluciones para resolver el problema de la escasez de direcciones IP en el Internet fue la definición de un grupo de direcciones para redes privadas que puedan ser reutilizadas dentro de ambientes locales, pero que no pueden ser enrutables en el Internet. Estas redes no forman parte del Internet pero pueden ser utilizadas como un esquema de direccionamiento interno para una red privada y generalmente se utilizan en redes de área local. Este grupo de direcciones está especificado en el RFC 1918. [5] En la Tabla 1-5 se pueden identificar los diferentes rangos para las direcciones privadas así como las máscaras para las mismas; cabe destacar que a estas direcciones privadas se las puede dividir de acuerdo a las necesidades de hosts y redes. Rango
Máscara
CIDR
10.0.0.0 - 10.255.255.255
255.0.0.0
/8
172.16.0.0 - 172.31.255.255
255.240.0.0
/12
192.168.0.0 - 192.168.255.255
255.255.0.0
/16
Tabla 1-5. Direcciones de red privadas
Además de las redes privadas existen un conjunto de redes que tienen usos específicos; en la Tabla 1-6 se puede observar un resumen del conjunto de direcciones reservadas y especiales y el RFC donde se definieron. 1.4.3. PROTOCOLO IPv6
El protocolo IP versión 6 conocido también como IPng (IP next generation ), nace como una solución al problema de direccionamiento existente con la versión 4, ya que no se pensó que esta versión iba a tener tanta acogida y que iba a ser la base del Internet. El crecimiento desproporcionado del Internet dio como lugar la búsqueda de soluciones al agotamiento de direcciones. Una de estas soluciones fue la implementación de un nuevo esquema de direccionamiento que provea de un número suficiente de direcciones para cubrir las necesidades de los usuarios
28
de Internet a nivel mundial, pensando además en un crecimiento bastante considerable. Direcciones Reservadas Bloque de direcciones
Descripción
RFC
0.0.0.0/8
Red Actual
RFC 1700
10.0.0.0/8
Red privada
RFC 1918
14.0.0.0/8
Redes públicas
RFC 1700
127.0.0.0/8
Loopback o red local RFC 3330
128.0.0.0/16
Reservada (IANA) 11 RFC 3330
169.254.0.0/16
Enlace Local
RFC 3927
172.16.0.0/12
Red Privada
RFC 1918
191.255.0.0/16
Reservada (IANA)
RFC 3330
192.0.0.0/24
Reservada (IANA)
RFC 3330
192.0.2.0/24
Red de prueba
RFC 3330
192.88.99.0/24
IPv6 a IPv4 relay
RFC 3068
192.168.0.0/16
Red Privada
RFC 1918
198.18.0.0/15
Red de prueba
RFC 2544
223.255.255.0/24
Reservada (IANA)
RFC 3330
224.0.0.0/4
Multicasts
RFC 3171
240.0.0.0/4
Reservada
RFC 1700
255.255.255.255
Broadcast Fuente: http://en.wikipedia.org/wiki/IPv4
Tabla 1-6. Direcciones reservadas en IPv4 11
IANA (Internet Assigned Numbers Authority ) era la entidad que registraba los protocolos de Internet que desde 1998 pasó a ser la ICANN ( Internet Corporation for Assigned Names and Numbers )
29
Experimentalmente existió una versión 5 del protocolo IP que quedó como eso, una versión experimental. Después nace el protocolo IPv6 luego de algunos años de investigación y receptando propuestas de investigadores; la propuesta en un principio se llamó SIPP ( Simple Internet Protocol Plus ). Las especificaciones detalladas del protocolo IPv6 se definen en el RFC 1883 y luego fueron modificadas detallándose en el RFC 2460. La principal duda que se tuvo en un principio es la incompatibilidad que se presentaba con los diferentes protocolos de enrutamiento, pero estos inconvenientes se fueron solucionando con el desarrollo inmediato de los protocolos. Como primer punto lo que se pretendió resolver es el agotamiento de direcciones, lo cual se solucionó sin ningún problema ya que las direcciones de IPv6 están conformadas por 128 bits, y no de 32 bits como el caso de IPv4; este tipo de direccionamiento da un total de 2 128 direcciones. Otra ventaja que se tuvo con el protocolo IPv6 es que la cabecera disminuyó de 13 campos a 8 campos lo que permite un procesamiento más rápido. También una de las mejoras que se tiene con este protocolo es la seguridad. [1] En la Figura 1-13 se puede observar la estructura de la cabecera de un paquete IPv6, donde se pueden apreciar sus campos que están conformando 40 octetos obligatorios a diferencia de los 20 octetos en IPv4. A continuación se describen cada uno de los campos: Versión: Se refiere a la versión del protocolo, en este caso es un número de 4 bits con un valor de 6. Prioridad: Constituido por 4 bits representa la prioridad de los paquetes respecto a otros provenientes de la misma fuente. Etiqueta de Flujo: Es un campo conformado por 24 bits y utilizado por los enrutadores que soportan este protocolo para dar un tratamiento especial a los paquetes.
30
Longitud de la carga útil: Conformado por 16 bits, representa la longitud en bytes del paquete sin contar con la cabecera. Siguiente cabecera: Está conformado por 8 bits e indica el tipo de cabecera opcional puede seguir a la cabecera principal. Límite de saltos: Está conformado por 8 bits y sirve para controlar la existencia del paquete. Este valor de 8 bits disminuye cada vez que el paquete atraviesa un nodo. Dirección de Origen: Constituida por 128 bits y como su nombre indica, contiene a la dirección de origen del paquete. Dirección de Destino: Contiene a la dirección IPv6 de destino del paquete y está conformada por 128 bits.
Figura 1-13. Estructura de la cabecera IPv6 [7]
Dentro de las cabeceras de extensión se tienen 6 tipos (estas cabeceras son opcionales) Opciones de salto por salto: Aquí se encuentra información utilizada por los enrutadores. El código utilizado es 0. Enrutamiento: Aquí se encuentra la ruta a seguir del paquete, ésta puede ser total o parcial. El código utilizado es 43 Fragmentación: Contiene información de fragmentación y de reensamblaje. El código utilizado es el 44. Verificación de autenticidad: Aquí se verifica la identidad del transmisor. El código utilizado es 51.
31
Carga útil cifrada de seguridad: Provee privacidad y contiene la información del contenido cifrado de los datos. El código utilizado es el 50 Opciones de destino: Contiene información adicional que debe ser analizada por el destino del datagrama. El código utilizado es el 60.
Se pudo observar que algunos de los campos de la cabecera IPv6 son muy parecidos a los de las cabeceras IPv4; de igual manera es importante analizar cómo están estructuradas las direcciones IPv6 y cómo pueden ser éstas utilizadas para propósitos de enrutamiento. 1.4.4. DIRECCIONAMIENTO IPV6
Las direcciones IPv6 están conformadas por 128 bits que se encuentran divididos en 8 grupos de 16 bits; cada grupo está separado por “:” y se los representa en formato hexadecimal de tal manera que existan 4 caracteres hexadecimales por cada grupo. Un ejemplo de una dirección IPv6 es la siguiente 2001:0db8:85a3:08d3:1a19:8f67:0370:736a Si uno o más grupos son nulos 12 se los puede omitir siempre y cuando no existan confusiones de cuántos grupos nulos existen; por ejemplo la dirección 2001:0db8:85a3:0000:0000:0000:0000:736a puede ser escrita como 2001:0db8:85a3::736a. Se pueden utilizar direcciones IPv4 en los 32 bits menos significativos de la dirección IPv6; por ejemplo si la dirección IPv4 es 172.16.40.12 la dirección IPv6 compatible 13 será ::172.16.40.12 y la dirección IP mapeada 14 será ::FFFF.172.16.40.12.
12
Un grupo nulo es un grupo conformado por ceros así 0000 IPv6 compatible con IPv4 cuando se quiere utilizar direcciones IPv4 en tráfico IPv6 14 IPv4 mapeada en IPv6 cuando los nodos no usan direccionamiento IPv6 13
32
Para identificar los tipos de direcciones se debe tomar en cuenta los prefijos de las mismas (los primeros bits de la dirección); estos prefijos se los puede observar en la Tabla 1-7.
Espacio
Prefijo
0000.0000
Reservada (aquí se incluyen las de IPv4)
0000.0001
No asignada
0000.001
Reservadas para NSAP
0000.010
Reservada para IPX
0000.011
No asignada
0000.1
No asignada
0001
No asignada
001
No asignada
010
Direcciones basadas en el proveedor
011
No asignada
100
Direcciones basadas geográficamente
101
No asignada
110
No asignada
1110
No asignada
1111.0
No asignada
1111.10
No asignada
1111.110
No asignada
1111.1110.0
No asignada
1111.1110.10
Direcciones de uso local
1111.1110.11
Direcciones de sitio local
1111.1111
Direcciones de multicast
Fuente: STALLINGS, William; Comunicaciones y Redes de Computadoras. Séptima Edición. Tabla 1-7. Prefijos de direcciones IPv6
33
Se puede encontrar algunos tipos de direcciones IPv6: Unicast : Un identificador para una sola interfaz cuando el paquete se entrega a un solo destino; estas direcciones se las asigna con los 64 bits menos significativos de la dirección IPv6. Multicast : Un identificador para un conjunto de interfaces y se entrega a todos ellos. Anycast : Un identificador para un conjunto de interfaces pero se entrega al más cercano.
Existen direcciones especiales como las siguientes:
::1 dirección de loopbak ::0 dirección no definida FF00:: /8 direcciones de multicast FE80:: /10 direcciones de enlace local FEC0:: /10 direcciones de sitio local FE01::1 es una dirección de multicast a todos los nodos 15
Las subredes IPv6 son un grupo de direcciones contiguas que se describen usando la notación CIDR 16. En IPv6 lo común es que para una red se asigne un /48, donde se fijan los primeros 48 bits, los 16 restantes para hacer subredes (por tanto, 65.535 posibles subredes) y los 64 restantes para la asignación de los hosts . En la Figura 1-14 se puede observar como se asignan los bits de subred en una dirección.
Figura 1-14. Estructura de subneting en IPv6 15
La dirección de broadcast no existe en IPv6. Para el CIDR en IPv6 se aplica el mismo concepto que en IPv4 tomando en cuenta que ahora son 128 bits para cada dirección. 16
34
1.5. PROTOCOLOS DE ENRUTAMIENTO DINÁMICO En la capa de Internet del modelo de referencia TCP / IP se produce el enrutamiento; en esta capa se encuentran los protocolos enrutables como IP o IPX y los protocolos de enrutamiento como RIP, OSPF o BGP entre otros. Los protocolos de enrutamiento son los encargados de manejar la información para que se produzca el enrutamiento entre nodos; estos protocolos permiten la creación y el intercambio de las tablas de enrutamiento para que se pueda definir en cada uno de los enrutadores la topología de la red y así poder determinar la mejor ruta a través del uso de métricas. A los protocolos se los puede dividir en dos grupos.
Protocolos de puerta de enlace interna (IGP 17) Protocolos de puerta de enlace externa (EGP 18)
Los protocolos IGP son aquellos que realizan el enrutamiento dentro de un mismo sistema autónomo, es decir que todos los enrutadores pertenecen a un mismo sistema autónomo.
Figura 1-15. Protocolos IGP y EGP 17 18
IGP viene de Internal Gateway Protocol EGP viene de Exterior Gateway Protocol
35
Los protocolos EGP son aquellos que realizan enrutamiento entre sistemas autónomos. En la Figura 1-15 se puede apreciar de mejor manera lo mencionado para estos protocolos. A continuación se describen algunos de los protocolos de enrutamiento más importantes. 1.5.1. RIP ( ROUTING INFORMATION PROTOCOL)
RIP es el Protocolo de Información de encaminamiento y es un protocolo IGP. Básicamente RIP utiliza el algoritmo de vector distancia, donde la métrica que utiliza es el número de saltos entre los enrutadores, estableciendo un máximo de 15 saltos antes de descartar el paquete. Existen 3 versiones de RIP que están definidas muy claramente: RIPv1 RIPv2 RIPng
1.5.1.1. RIPv1
RIPv1 es la primera versión del protocolo especificada en el RFC 1058; es un protocolo que funciona en dominios de redes con clase y está limitado a redes pequeñas. El intercambio de tablas lo realiza periódicamente cada 30 segundos o cuando la topología tenga algún cambio. Debido a que es un protocolo que utiliza el algoritmo de vector distancia es un protocolo que converge lentamente lo que puede generar problemas. El máximo número de saltos establecido en 15 evita que se produzcan lazos infinitos. Las rutas en sus tablas tienen una duración de 180 segundos; si éstas no se actualizan a través del intercambio de tablas en este tiempo como máximo, se eliminan de la tabla.
36
El formato del paquete RIPv1 se lo puede observar en la Figura 1-16.
Figura 1-16. Formato del paquete RIPv1
A continuación se detallan los campos, indicando de antemano que los campos donde se encuentra ceros son campos nulos llenos de ceros: Comando: Indica si el paquete es una solicitud o una respuesta; está conformado por 8 bits Versión: Indica la versión de RIP que se utiliza; está constituido por 8 bits Identificador de la Familia de Direcciones: Especifica la dirección utilizada19, en el caso de IP este campo toma un valor de 2. Dirección IP: Especifica la dirección IP para la entrada Métrica: Indica cuántos saltos ha tenido el paquete, por lo que su valor está entre 1 y 15. Si el valor es 16 se toma como destino inalcanzable.
La versión 1 de este protocolo trabaja con clases de direcciones por lo que no se puede tener subneting ni superneting , tampoco se pueden utilizar los CIDR ya que la información de las máscaras no se incluyen en este protocolo; tampoco soporta ningún mecanismo de autenticación.
19
RIP está diseñado para portar información de enrutamiento de diferentes protocolos
37
1.5.1.2. RIPv2
Al igual que la versión 1 utiliza el algoritmo de vector distancia con una métrica de número de saltos. Las especificaciones de RIPv2 se encuentran en el RFC 2453. Establece un máximo de 15 saltos, las actualizaciones se las realiza cada 30 segundos o cuando haya cambios en la red. La segunda versión del protocolo RIP tiene algunas mejoras ya que soporta subredes y las direcciones con CIDR. También establece mecanismos de autenticación. El formato del paquete RIPv2 se lo puede observar en la Figura 1-17.
Figura 1-17. Formato del paquete RIPv2
A continuación se describen cada uno de los campos del protocolo RIPv2: Comando: Indica si es un paquete de solicitud o de respuesta. Versión: Especifica la versión del protocolo RIP. En este caso es la segunda versión. Identificador de la familia de direcciones: Especifica el tipo de direcciones que se utiliza.
38
Etiqueta de ruta: Sirve para distinguir entre rutas internas o externas. Esto suele ser utilizado por otros protocolos Dirección IP: Indica la dirección IP de la entrada Máscara de subred: Contiene la máscara de subred para la entrada; si el valor es cero indica que no se ha especificado la máscara. Siguiente salto: Indica la dirección IP del próximo salto Métrica: al igual que RIPv1 establece el número de saltos que lleva el paquete; estableciendo como máximo 15 porque al 16 se lo marca como red inalcanzable.
Hay que destacar que RIPv2 soporta actualizaciones de RIPv1 y no viceversa. 1.5.1.3. RIPng
RIPng es un protocolo IGP que utiliza el algoritmo de vector distancia para realizar enrutamiento y está estandarizado en el RFC 2080. De igual manera que las versiones anteriores utiliza como métrica el número de saltos. La diferencia importante con las anteriores es que este protocolo realiza enrutamiento con redes que utilizan direcciones IPv6. RIPng no utiliza autenticación. El formato del paquete RIPng se puede observar en la Figura 1-18.
Figura 1.18. Formato del paquete RIPng
39
A continuación se describen cada uno de los campos: Comando: Indica si el paquete es de solicitud o de respuesta. Conformado por 8 bits. Versión: Indica la versión del protocolo RIPng, en este caso es la versión 1. Constituido por 8 bits. Entrada RTE: Tabla de ruta de entrada, pueden existir varias en el paquete y cada una consta de 20 bytes.
El campo RTE se lo analiza en la Figura 1-19.
Figura 1-19. Formato del campo RTE del protocolo IPv6
A continuación se describen los campos: Prefijo IPv6: Dirección IPv6 para el destino. Conformada por 128 bits. Etiqueta de Ruta: Campo utilizado por los enrutadores para la discriminación de rutas internas y externas. Constituida por 16 bits. Longitud del prefijo: Constituida por 8 bits describe el número de bits significantes en el prefijo. Métrica: Se identifica el número de saltos entre 1 y 15 que lleva el paquete. Constituida por 8 bits.
1.5.2. IGRP y EIGRP 1.5.2.1. IGRP ( INTERIOR GATEWAY ROUTING PROTOCOL)
IGRP es el Protocolo de enrutamiento de puerta de enlace interior desarrollado por CISCO con el objetivo de ser el sucesor de RIP. Es un protocolo que se lo
40
utiliza como IGP aunque puede ser utilizado como EGP para enrutamiento entre sistemas autónomos. El protocolo IGRP utiliza el algoritmo de vector distancia pero a diferencia de RIP utiliza una métrica compuesta. Esta métrica evalúa varios parámetros para establecer la mejor ruta, estos parámetros son: [8] Ancho de banda Retardo Confianza Carga MTU (Maximum Transfer Unit )
IGRP es un protocolo que maneja Direcciones IP con clase, por lo que el subneting y superneting no es posible con este protocolo de enrutamiento. 1.5.2.2. EIGRP ( ENHANCED INTERIOR GATEWAY ROUTING PROTOCOL)
EIGRP es la versión mejorada de IGRP y funciona con el algoritmo DUAL que es una mezcla del algoritmo de vector distancia y el algoritmo de estado de enlace. Es un protocolo propietario de CISCO por lo que solo se lo encuentra en enrutadores de esta marca. Es un protocolo muy bien desarrollado y tiene muchas características importantes como la compatibilidad con IGRP. Es fácil de configurar, administra mejor el ancho de banda ya que utiliza unicast y multicast para las actualizaciones de las rutas, se puede balancear la carga cambiando los valores de las métricas manualmente. Una de las características más importantes es que es un protocolo que se adapta muy fácilmente a los protocolos enrutables debido a que trabaja de una manera modular; esto ha permitido que este protocolo se adapte al direccionamiento IPv6. El cálculo de la métrica de este protocolo se la realiza de la misma manera que IGRP.
41
EIGRP maneja 3 tablas que le permiten la selección de la ruta más adecuada. Tabla de vecinos: Es una tabla en la que mantiene información de los enrutadores vecinos. Tabla de topología: Esta tabla es el resultado de la selección de la mejor ruta hacia los diferentes destinos de la red y se la estructura con la información proporcionada por los enrutadores vecinos. Tabla de encaminamiento: Es la tabla donde se encuentran las mejores rutas de la red y se la estructura a través de la tabla de topología.
1.5.3. OSPF ( OPEN SHORTEST PATH FIRST )
OSPF es uno de los protocolos más populares en la actualidad debido a su funcionalidad y al manejo de rutas. Este protocolo utiliza el algoritmo de estado de enlace y es un protocolo IGP. El protocolo OSPF basa su selección de la mejor ruta en el costo de la misma, el cual va a depender de parámetros como retardo, ancho de banda, etc. Lo que hace OSPF en redes muy grandes es separarlas por áreas más pequeñas donde sea más fácil el enrutamiento, y luego estas áreas se enrutan entre ellas a través de un área de backbone . Por este motivo se puede hablar de 4 tipos de enrutadores OSPF [1].
Enrutadores internos que realizan el enrutamiento dentro de un área Enrutadores de borde que conectan dos o más áreas dentro de un mismo Sistema autónomo Enrutadores de backbone que se encuentra en el área de backbone que es donde se interconectan las áreas. Enrutadores de frontera que se comunican con otros Sistemas Autónomos.
Un enrutador puede pertenecer a más de una clase, por ejemplo un enrutador interno puede ser también de backbone .
42
OSPF utiliza paquetes de Hello para identificar los enrutadores vecinos; este protocolo permite elegir un enrutador designado que es el que va a ser el encargado de transmitir la información entre enrutadores de redes distintas; además se elige un enrutador designado de respaldo en caso de que exista algún problema con el principal. El enrutador designado evita que se envíen paquetes innecesarios entre redes ya que éste será el único enrutador autorizado para hacerlo y lo hace empleando multicast a los enrutadores OSPF a través de la dirección 224.0.0.5. Cada vez que un interfaz recibe un paquete Hello el enrutador se entera que existe un vecino, luego utilizando estos paquetes Hello los enrutadores tratan de establecer una comunicación bidireccional. Esta comunicación bidireccional no permite el intercambio de información. Para poder intercambiar información entre enrutadores se deben establecer adyacencias que son comunicaciones avanzadas entre enrutadores OSPF donde no solo se intercambian paquetes Hello sino que también se intercambian otro tipo de paquetes. Para poder conseguir adyacencias se eligen entre los dos enrutadores vecinos el maestro y esclavo, después de esto ya se puede intercambiar la información de enrutamiento. Luego de este proceso se producen intercambios de paquetes de estados de enlace LSR 20, LSU21, LSA22, LSAcks23, para poder obtener información mucho más completa. Luego de esto los enrutadores conforman una tabla de datos llamada tabla de adyacencia que es la que contiene toda la información para el manejo de las rutas. Existen algunas versiones de OSPF, donde las más conocidas son la versión 2 y la versión 3. En la versión 3 se incluye el soporte para IPv6. El formato de la cabecera del paquete OSPFv2 se puede observar en la Figura 1-20.
20
LSR son las siglas de Link State Requirement LSU son las siglas de Link State Update 22 LSA son las siglas de Link State Advertisement 23 LSAcks son las siglas de Link State Acknowledgement 21
43
Figura 1-20. Formato de la cabecera OSPFv2
Los campos se describen a continuación:
Versión: Indica la versión del protocolo OSPF. Es un campo de 8 bits Tipo: Describe el tipo de paquete a enviarse como Hello, LSA, LSR, LSU, LSAcks, Database Description . Es un campo de 8 bits. Longitud del paquete: Indica la longitud del paquete OSPF en bytes incluyendo la cabecera. ID del Enrutador: Indica el identificador del enrutador de origen del paquete. Conformado por 32 bits. ID del Área: Indica el identificador del área al que pertenece el paquete. Es un campo de 32 bits. Checksum: Se chequea toda la cabecera excluyendo los 64 bits de autenticación. Está conformado por 16 bits. Tipo de autenticación: Establece el tipo de autenticación a utilizarse. Campo de 16 bits Autenticación: Es un campo de 64 bits que consta de la información para la autenticación.
El formato de la cabecera del protocolo OSPFv3 se lo puede observar en la Figura 1-21.
44
Figura 1-21. Formato de la cabecera OSPFv3
Los campos se describen a continuación: Versión: Indica la versión del protocolo OSPF. Es un campo de 8 bits Tipo: Describe el tipo de paquete a enviarse como Hello, LSA, LSR, LSU, LSAcks, Database Description . Es un campo de 8 bits. Longitud del paquete: Indica la longitud del paquete OSPF en bytes incluyendo la cabecera. ID del Enrutador: Indica el identificador del enrutador de origen del paquete. Conformado por 32 bits. ID del Área: Indica el identificador del área al que pertenece el paquete. Es un campo de 32 bits. Checksum: Se chequea toda la cabecera. Está conformado por 16 bits. Instancia ID: Identificador de instancia que se habilita para enlaces simples.
1.5.4. BGP ( BORDER GATEWAY PROTOCOL)
BGP son las siglas de Protocolo de puerta de enlace de borde y es un protocolo EGP, es decir que a diferencia de OSPF o RIP realizan enrutamiento entre sistemas autónomos. Este enrutamiento es muy importante ya que aquí se manejan políticas de enrutamiento que no forman parte del protocolo en sí pero que son útiles, ya que los sistemas autónomos pertenecen a distintas compañías u organizaciones. Un ejemplo de esto es que se pueden establecer políticas para
45
evitar tráfico de tránsito en los enrutadores de borde, porque no es interesante para determinada compañía. Se pueden tener tres tipos de redes de acuerdo al tipo de enrutador BGP [1] que disponga la red los cuales se describen a continuación: Redes de punta: Son aquellas que disponen de una sola interfaz BGP por lo tanto no pueden manejar tránsito BGP Redes multiconectadas: Tienen muchas interfaces corriendo BGP y pueden funcionar de tránsito pero generalmente se establecen restricciones en éstas. Redes de tránsito: Son redes que manejan el tránsito BGP pero de igual manera se pueden considerar varias restricciones.
BGP utiliza el algoritmo de vector distancia pero funciona de mejor manera que en RIP; cada enrutador maneja un registro de las trayectorias seguidas y no actualiza periódicamente sino les da a todos sus vecinos la trayectoria exacta que está usando. Luego de recibir todas las trayectorias de sus vecinos, elimina las que no sirven y se queda con las mejores. BGP es utilizado por la mayoría de ISPs para el manejo de tráfico de enrutamiento, además es un protocolo que soporta direccionamiento sin clase lo cual lo hace muy bueno en las redes actuales. La versión que actualmente se utiliza es la versión 4 y está estandarizada en el RFC 4271. Actualmente BGP tiene soporte para direccionamiento IPv6.
REFERENCIAS CAPÍTULO 1 [1]
TANENBAUM, Andrew S.; Redes de Computadoras. Cuarta Edición. Prentice Hall. 2003
[2]
ANÓNIMO, Redes y servicios http://trajano.us.es/~isabel/publicaciones/OSI.pdf
46
Último acceso: 2007 – 04 – 15 [3]
COLLADO, Eduardo, Cisco CCNA – CCNP http://www.eduangi.com/documentos Último acceso: 2007 – 08 – 16
[4]
RFC 791 – Internet Protocol – Protocol Specification, septiembre 1981
[5]
RFC 1918 - Address Allocation for Private Internets, febrero 1996
[6]
RFC 2460 – Internet protocol, version 6, diciembre 1998
[7]
Wikipedia, IPv4 http://en.wikipedia.org/wiki/IPv4 Último acceso: 2007 – 04 – 16
[8]
STALLINGS, William; Comunicaciones y Redes de Computadoras. Séptima Edición. Prentice Hall. 2004
[9]
CISCO Systems, Programa de la academia de Networking de CISCO, 2003
[10]
RFC 2328 – OSPF version 2, abril 1998
[11]
RFC 2740 – OSPF for IPv6, diciembre 1999
[12]
RFC 4271 – A Border Gateway Protocol 4, enero 2006
[13]
RFC 2545 - Use of BGP-4 Multiprotocol Extensions for IPv6 InterDomain Routing, marzo 1999
CAPÍTULO 2 HERRAMIENTAS PARA ENRUTADORES BASADAS EN SOFTWARE
47
CAPÍTULO 2. HERRAMIENTAS
PARA
ENRUTADORES
BASADAS EN SOFTWARE
En este capítulo se hace una descripción breve de los sistemas operativos, y se presentan aquellos más utilizados para realizar enrutamiento IP. También se incluye una descripción de las herramientas más destacadas para enrutamiento IP bajo el sistema operativo Linux. Por otro lado se describen de una manera rápida y sencilla otros usos que puede tener el enrutamiento dentro de las redes de datos.
2.1. SISTEMAS OPERATIVOS PARA ENRUTAMIENTO Para poder definir a los sistemas operativos para enrutamiento más utilizados e importantes primero se deben establecer algunas definiciones. 2.1.1. DEFINICIONES 2.1.1.1. Sistema Operativo
El sistema operativo es un elemento de software encargado de tomar en cuenta los elementos de hardware de un sistema de cómputo (memoria, discos, impresoras, teclado, pantalla, dispositivos de red, procesador o procesadores y otros dispositivos); su labor es administrar dichos elementos de una manera eficiente. El sistema operativo es el software que se encuentra interactuando de manera directa con el hardware y que sirve de interfaz para que los programas de usuario se comuniquen de una manera más sencilla con el hardware. En la Figura 2-1 se puede observar un sistema de cómputo y dónde se encuentra ubicado el sistema operativo.
48
Fuente: TANENBAUM, Andrew S.; Sistemas Operativos Modernos. Segunda Edición. Figura 2-1. Sistema de Cómputo
Entre las características de los sistemas operativos se puede ver que este software administra los elementos de hardware de un sistema de cómputo; estos elementos de hardware formarán parte útil en lo que se refiere al enrutamiento ya que es el sistema operativo el que va a gestionar las tarjetas de red, la memoria y el procesamiento. Dentro de los sistemas operativos se pueden destacar tres funciones [3]: Gestión de los recursos del computador Ejecución de los servicios para los programas Ejecución de los mandatos de los usuarios
La parte encargada de gestionar los recursos de un sistema de cómputo es el núcleo o kernel, el cual es el nexo entre las aplicaciones y los elementos de hardware, se puede decir que es la parte de software que se encuentra más próxima al hardware [1].
56
2.1.2.1.2. RRAS
El Servicio de Enrutamiento y Acceso Remoto, RRAS, se lo implementó desde Windows NT 4.0 y permite elaborar enrutamiento con protocolos como RIP y OSPF. En realidad este servicio nace como dos servicios separados MPR (Multiprotocol Routing ) y RAS (Remote Access Service ), pero luego se los integró para darles mayor funcionalidad. Como MPR no tenía soporte para OSPF, con esta nueva herramienta RRAS se solucionó integrando soporte para este protocolo. [9] RRAS puede enrutar IP o IPX a través de segmentos de red locales o que se acceden por líneas telefónicas. Una de las ventajas más destacadas de RRAS es el soporte que brinda a las diferentes tarjetas de red que pueden ser ISDN, WAN, o Ethernet, siempre y cuando estas tarjetas sean soportadas por el sistema operativo; en general las tarjetas de este tipo vienen con sus propios controladores para ser instaladas en los sistemas operativos Windows. En la Figura 2-3 se puede observar un esquema de enrutamiento con RRAS.
Figura 2-3. Enrutamiento con RRAS
49
Sobre el kernel se encuentran los compiladores, editores, intérpretes de comandos, gestores de ventanas. 2.1.1.2. Shell
El intérprete de comandos denominado shell, es un programa basado en texto a través del cual el usuario puede interactuar con el software de sistema. El shell trabaja como un lazo infinito donde los pasos son los siguientes [3]: Esperar la orden del usuario Analizar la orden y si es correcta ejecutarla utilizando los servicios del sistema operativo 24 Concluir la orden y volver a esperar
2.1.1.3. Proceso
Se puede definir como proceso a “un programa en ejecución” [3], no se debe confundir solo con el programa ya que éste es un conjunto de instrucciones. Los sistemas operativos se los puede clasificar de acuerdo al número de procesos que ejecuta, así: 2.1.1.3.1. Sistemas Operativos Monotarea
Son también llamados monoprocesos y son aquellos que permiten la ejecución de un único proceso en cada instante. 2.1.1.3.2. Sistemas Operativos Multitarea
Son también conocidos como multiprocesos y permiten la ejecución de varios procesos a la vez, o mientras se están ejecutando otros procesos.
24
Los servicios del sistema operativo son la gestión de procesos, gestión de memoria, gestión de entrada y salida, gestión de archivos y directorios, comunicación y sincronización entre procesos y seguridad y protección.
50
2.1.1.4. Usuario
En lo que se refiere a sistemas operativos se menciona como usuarios no a las personas que manejan el sistema sino a la cuenta de usuario. En este caso un usuario es la cuenta autorizada para utilizar el sistema. A los sistemas operativos se los puede clasificar según el número de usuarios, así se tiene: 2.1.1.4.1. Sistemas operativos monousuarios
Son aquellos sistemas que únicamente soportan a un usuario trabajando al mismo tiempo. 2.1.1.4.2. Sistemas operativos multiusuarios
Son aquellos sistemas que soportan varios usuarios trabajando al mismo tiempo; al tener varios usuarios simultáneamente es obvio suponer que este tipo de sistemas deben ser multitarea ya que se deben ejecutar varios procesos a la vez. 2.1.2. SISTEMAS OPERATIVOS MÁS UTILIZADOS
A través de la historia se han desarrollado gran cantidad de sistemas operativos que a su vez han ido evolucionando de acuerdo al desarrollo de la tecnología y de las necesidades de los usuarios. Actualmente se tiene una gran cantidad de sistemas operativos a disposición de los usuarios, ya sea para adquirirlos o de libre distribución, y la decisión del tipo de sistema operativo a utilizar va a depender de la funcionalidad del mismo y de acuerdo del tipo de hardware sobre el cual va a funcionar, sin olvidarse del costo. Se pueden tener sistemas operativos para servidores, para computadores personales o para PDAs (Asistente Personal Digital), y también se puede tener
51
sistemas operativos para determinado hardware de equipos especializados que cumplen funciones específicas como es el caso de los enrutadores. Los sistemas operativos más populares son los sistemas operativos basados en UNIX25 como son Linux, Solaris, Mac OS, AIX, entre otros; y los desarrollados por la empresa Microsoft como son MS-DOS, Windows 95, 98, Me, NT, 2000, XP, 2003 y Vista. También se destaca entre los sistemas operativos especializados el CISCO IOS. Para el presente proyecto de titulación se van a describir los sistemas operativos Windows, Linux y CISCO IOS. 2.1.2.1. Windows
Windows es uno de los sistemas operativos más populares de la actualidad, siendo éste desarrollado por la Compañía Microsoft en sus diferentes versiones. Su popularidad se debe a su interfaz de usuario muy fácil de manejar para computadores personales en sus aplicaciones de oficina y aplicaciones de hogar, y también por el soporte existente. Windows nace en 1985 no como un sistema operativo sino como una interfaz gráfica para el sistema operativo MS-DOS que era la versión actual de ese momento. La versión 1 y 2 no tuvieron tanto impacto mientas que la versión 3 con sus sucesores 3.1 y 3.11 tuvieron gran acogida. En 1995 aparece Windows 95 ya como un sistema operativo aunque todavía tiene rezagos de su antecesor MS-DOS; de igual manera fue muy popular ya que este sistema tenía todas las funciones de un sistema operativo, como la administración de memoria y de procesos, además de tener una interfaz fácil de manejar para los usuarios.
25
UNIX es un sistema operativo multitarea y multiusuario, desarrollado en principio por un grupo de empleados de los laboratorios Bell de AT&T.
52
En 1998 sale al mercado Windows 98 donde una de sus características más importantes fue soporte para algunos dispositivos como USB, DVD, Firewire. En 1999 salió al mercado la segunda edición de Windows 98 cuya característica más importante era la compartición de una conexión de Internet a través de una línea telefónica. En el año 2000 salió al mercado la versión Millenium (Me) que tuvo muchos errores por lo que su paso en el mercado fue fugaz. Esta versión traía soporte para mensajería instantánea y aplicaciones multimedia, también incluía soporte para conexiones de banda ancha como modems de Cable y ADSL. A la par de las versiones anteriormente mencionadas se desarrollaba Windows NT (Nueva Tecnología) que era un sistema operativo moderno de 32 bits. En su primera versión, Windows NT 3.1, su interfaz de usuario era muy similar a la de Windows 3.1 y no tuvo la acogida esperada a pesar de que se lo planteó como el sucesor de Windows 3.1. De igual manera se desarrollaron otras versiones como Windows NT 3.5 y NT 3.51. En 1996 sale al mercado la versión NT 4.0 cuya interfaz de usuario era muy parecida a la de Windows 95, este sistema tuvo mucha más acogida que la versión anterior aunque no fue la esperada pues no marcaba la pauta de ser el sucesor de Windows 95. En el año 2000 después del lanzamiento de Windows Me sale al mercado Windows 2000 que era la versión 5 de Windows NT, pero su estrategia era marcarlo como el sucesor de Windows 98. Este sistema operativo tuvo algunas versiones, tanto para estaciones de trabajo como para servidores. Entre sus características principales era el soporte a dispositivos Plug & Play y soporte de red mejorado donde se podía tener directorios activos 26, balanceo de carga, acceso remoto y enrutamiento, así como también servicios para instalación desatendida y redes privadas virtuales.[1]
26
Un Directorio Activo es la manera como describe Microsoft al servicio LDAP ( Lightweight Directory Access Protocol ) que permite establecer políticas respecto a los recursos de red de un dominio.
53
En el 2001 sale al mercado Windows XP que es una mezcla entre Windows 98 y Windows 2000, donde se destaca una nueva interfaz y un soporte mucho más amplio a componentes multimedia, así como también soporte a redes inalámbricas y mejoras en redes de datos para facilitar al usuario en su manejo. Tiene versiones para usuarios de hogar como para usuarios corporativos y además añade soporte para procesadores de doble núcleo. Windows XP trae soporte para IPv6, mientras que para las versiones anteriores se tienen que instalar paquetes adicionales para que soporte este protocolo. En el 2003 se lanza Windows Server 2003 que funciona con el mismo núcleo de XP pero que está desarrollado para uso en servidores donde se deshabilitan funciones del sistema XP y se añaden otras para el mejor rendimiento como servidor. Entre sus características principales está el manejo de directorios activos y enrutamiento. Este sistema operativo es considerado también como la evolución de Windows Server 2000 ya que trae muchas de sus características pero mejoradas. Windows Vista fue lanzado en enero de 2007 y es la última versión del sistema operativo Windows donde se hicieron muchas mejoras y cambios respecto a los sistemas operativos anteriores. Los cambios radican tanto en la interfaz gráfica como en la interfaz de programación de aplicaciones. Windows Vista está diseñado para computadores de escritorio y actualmente se está desarrollando un sistema operativo con las características de Windows Vista pero para servidores. Este sistema operativo tiene soporte para IPv6, se puede utilizar en redes privadas (VPNs) pero solo como cliente. [6] Los sistemas operativos de Microsoft no son sistemas de código abierto y tienen un costo por su utilización. En la Tabla 2-1 se puede observar los requisitos mínimos de hardware para las principales distribuciones de Windows:
54
Sistema Operativo
Procesador
Windows 95
486DX
Windows
486DX
98 Windows Me
150 MHz
Windows NT
Pentium Compatible
Windows 2000
133 MHz
Windows
233 MHz
XP
(P2)
Windows Server 2003
233 MHz (P2)
Windows Vista
RAM
16MB
Espacio en Disco
Periféricos
Otros
120 MB
Monitor compatible, ratón, teclado
Diskettera 3.5 pulgadas
Monitor
Unidad de CD-ROM
16MB
120MB
compatible, ratón, teclado
y Diskettera de 3.5 pulgadas
32 MB
320 MB (espacio
Monitor compatible,
Unidad de CD-ROM y Diskettera de 3.5
libre)
ratón, teclado
pulgadas
110 MB
Monitor compatible,
Unidad de CD-ROM y Diskettera de 3.5
ratón, teclado
pulgadas
64 MB
2 GB con 650 de espacio libre
Monitor compatible, ratón, teclado
Unidad de CD-ROM y Diskettera de 3.5 pulgadas
64 MB
4 GB con 1.5 de espacio libre
Monitor compatible, ratón, teclado
Unidad de CD-ROM y Diskettera de 3.5 pulgadas
128 MB
4 GB con 1.5 de espacio libre
Monitor compatible, ratón, teclado
Unidad de CD-ROM y Diskettera de 3.5 pulgadas
16 MB
Monitor 800 MHz
512 MB
15 GB libres
compatible, ratón, teclado
Unidad de DVDROM
Tabla 2-1. Requerimientos básicos de las versiones de Windows
De los sistemas mencionados anteriormente se puede destacar que los sistemas Windows NT desde su versión 3.51 SP2, Windows 2000 y Windows Server 2003 tienen soporte para enrutamiento con la utilización de herramientas como MPR y RRAS. [7][8] 2.1.2.1.1. MPR
MPR es el Enrutador de Protocolo Múltiple y está disponible en Service Pack 2 para Windows NT 3.51. Esta herramienta permite manejar lo siguiente:
55
RIP para TCP/IP El agente de retransmisión BOOTP (Protocolo Boot) para el Servidor DHCP (Protocolo de Configuración Dinámica de Host) RIP para IPX
Windows NT enrutará estos protocolos e intercambiará dinámicamente información de enrutamiento con otros enrutadores que ejecutan el protocolo RIP. El agente de retransmisión de BOOTP permitirá al enrutador de Windows NT que reenvíe peticiones DHCP a servidores de otras subredes DHCP. Esto permite que el servidor DHCP atienda varias subredes IP. RIP para IP se ejecuta como un servicio, se puede detener e iniciar en los servicios del panel de control. Para ver las rutas hay que escribir el comando route print en el símbolo del sistema de Windows NT. Esto mostrará las rutas que Windows NT crea de forma predeterminada y que se obtuvieron a través de RIP. Si se instala RIP para IP en un equipo que tiene sólo una tarjeta de red, se lo configura en modo silencioso. En modo silencioso, Windows NT escucha difusiones RIP, actualiza su tabla de enrutamiento pero no anuncia sus propias rutas. Si una tarjeta de red adicional se instala más tarde en el equipo, RIP desactivará Modo silencioso automáticamente y permitirá enrutamiento IP. [7] En la Figura 2-2 se puede observar cómo se tendría un enrutador con MPR.
Fuente: http://www.microsoft.com/latam/TechNet/articulos/200001/art01 Figura 2-2. Enrutamiento con MPR en Windows NT
57
2.1.2.2. Linux
El sistema operativo Linux 27 está basado en UNIX y fue desarrollado como un núcleo para procesadores Intel. La idea original era buscar un sustituto al sistema Minix, desarrollado por Andrew Tanenbaum con fines académicos, y que pueda ser utilizado en los procesadores Intel de una manera genérica. Este reto lo tomó Linus Trovalds y su desarrollo lo basó en el sistema UNIX existente en ese entonces. [10] Este núcleo desarrollado por Trovalds sirvió para que el proyecto GNU completara un sistema operativo similar al funcionamiento de UNIX pero totalmente de código abierto. El proyecto GNU ya tenía muchas herramientas listas como compiladores, depuradores, shell, etc., y el núcleo fue lo que cerró el sistema operativo. Linux es un sistema operativo multiusuario, multitarea y de libre distribución por lo que se pueden encontrar todos los programas necesarios para su funcionamiento así como archivos de configuración en multitud de servidores en Internet. La tarea de reunir todos los archivos y programas necesarios fue tomada por varias empresas y organizaciones y de aquí nacieron las llamadas distribuciones de Linux. Una distribución no es otra cosa, que una recopilación de programas y archivos, organizados y preparados para su instalación. Estas distribuciones se pueden obtener a través de Internet, o comprando los CDs o DVDs de las mismas, los cuales contendrán todo lo necesario para instalar un sistema Linux bastante completo. Casi todos los principales distribuidores de Linux, ofrecen la posibilidad de descargarse sus distribuciones sin ningún costo.
27
Linux o GNU/Linux son las denominaciones que se le da a este sistema operativo debido a que se utiliza el núcleo de Linux desarrollado por Linus Trovalds y utiliza aplicaciones del proyecto GNU cuyo fundador es Richard Satllman. Para propósito de este proyecto se va a denominar Linux al sistema operativo en su conjunto a pesar de tener paquetes de GNU.
58
A continuación se enumeran algunas de las distribuciones más importantes: RedHat Fedora Debian Suse Slackware Gentoo Ubuntu CentOS
Para el propósito de este proyecto de titulación se va a utilizar FedoraCore en su versión 5. FedoraCore es una distribución de Linux promovida por el proyecto Fedora que es auspiciado por la compañía RedHat. Esta distribución está basada en RedHat y se ha vuelto popular en el medio debido a que la comunidad es quien provee las pautas para el desarrollo de esta distribución y de ahí sirve de base para RedHat Linux Enterprise. Actualmente se encuentra en la versión 6 y se está probando la versión 7. De acuerdo a las palabras del Proyecto Fedora, “Fedora Core es un Sistema Operativo y de plataforma, basado en Linux, es y siempre será libre para que cualquier persona lo use, modifique y distribuya, ahora y por siempre. Fedora es desarrollado por un gran número de personas de la comunidad que se esfuerza en proveer y mantener lo mejor del software libre, el software de código abierto y de los estándares. Fedora Core es parte del Proyecto Fedora y es patrocinado por Red Hat, Inc.” [4] La ventaja de utilizar este sistema operativo es que se encuentra gran cantidad de información en libros y sobre todo en foros en el Internet que generalmente son las fuentes más actuales para este tipo de información. Además al ser de código abierto se puede personalizar el sistema de acuerdo a las necesidades del usuario.
59
Otra ventaja es que es un sistema operativo gratuito y se puede implementar en cualquier computador sin necesidad de adquirir licencias, es decir se abaratan los costos en la implementación. FedoraCore 5 conocida con el nombre de Bordeaux es una versión totalmente probada y que ha tenido resultados esperados en varios escenarios tanto como estación de trabajo o como servidores. En esta distribución se encuentra soporte para enrutamiento y se podrán utilizar herramientas desarrolladas para dicho propósito. Estas herramientas se las describirán posteriormente. El kernel o núcleo que se va a utilizar para este proyecto de titulación será la versión 2.6.18.2 que fue liberada el 4 de noviembre de 2006. El kernel se lo puede descargar del sitio Web http://www.kernel.org. Este kernel tiene que ser recompilado para que se adapte a las necesidades específicas del enrutador. 2.1.2.3. Cisco IOS
El Cisco IOS es el Sistema Operativo de Interconexión de Redes (Internetwork Operating System ) desarrollado por la compañía Cisco Systems como sistema operativo de sus equipos especializados para enrutamiento así como para otros equipos producidos en esta empresa. Este sistema operativo funciona como un solo programa que controla los procesos, gestión de memoria, dispositivos, etc. Los procesos en este sistema operativo comparten el mismo espacio de memoria por lo que errores en el sistema operativo pueden causar modificaciones en los datos utilizados por otros procesos. Actualmente se está desarrollando el sistema operativo como módulos para evitar este tipo de problemas sobre todo en aquellos equipos de alto rendimiento donde un sistema operativo sin ningún tipo de error es crucial. El Cisco IOS es desarrollado para cada versión de equipo en específico y tiene una característica muy conocida que es la interfaz de línea de comandos (CLI),
60
que actualmente es copiada por muchos otros sistemas y por paquetes para enrutamiento.[5] El Cisco IOS es el sistema operativo que se encarga de administrar las funciones de enrutamiento en un enrutador, es aquí donde se ejecutan los algoritmos de enrutamiento, y es también el encargado de implementar los protocolos de enrutamiento. Los protocolos a implementarse van a depender de la versión de sistema operativo y de las características físicas del enrutador. Como se mencionó en el capítulo 1, Cisco ha desarrollado sus propios protocolos de enrutamiento por lo que los implementa en su sistema operativo sin ningún problema, pues es el propietario de los mismos; además de los protocolos propietarios implementa protocolos de enrutamiento no propietarios que permiten la compatibilidad con otros equipos de enrutamiento que no sean Cisco. El Cisco IOS tiene tres modos de trabajo: Modo de ejecución de usuario Modo de privilegios Modo de configuración global
En el modo de ejecución de usuario se pueden consultar aspectos básicos de la configuración del enrutador. En el modo de privilegios se puede obtener información del enrutador un poco más especializada, información que no se puede ver en el primer modo. En el modo de configuración global se pueden establecer todos los parámetros de configuración del enrutador para que funcione de acuerdo a nuestras necesidades. En la Figura 2-2 se puede apreciar de mejor manera un diagrama de bloques con la estructura de los modos del Cisco IOS. El Cisco IOS va a tener soporte para IPv4 e IPv6 como para otros protocolos enrutables, claro que va a depender de la
61 versión 28 de sistema que se esté ejecutando y de las características físicas del equipo como son memoria y procesador.
Fuente: http://en.wikipedia.org/wiki/Cisco_IOS Figura 2-4. Estructura de los modos de trabajo de un enrutador Cisco
2.2. HERRAMIENTAS BAJO LINUX El enrutamiento puede ser manejado utilizando diferentes métodos como son, con equipos especializados como los enrutadores que tienen sus sistemas operativos propios o con sistemas operativos estándar que tienen la funcionalidad de enrutamiento como es el caso de Windows y Linux. Sin embargo existen programas especializados para cumplir el papel de enrutamiento que pueden ser instalados bajo sistemas operativos estándar.
28
Las versiones del Cisco IOS se van actualizando con el tiempo, además cada versión está diseñada para un modelo de equipo en específico ya que la estructura de hardware en los diferentes modelos suelen ser diferentes; esto garantiza un mejor desempeño.
62
En el caso particular de Linux existen paquetes gratuitos y pagados que están diseñados para el propósito de enrutar, muchos de ellos con una funcionalidad básica para situaciones de enrutamiento no muy complicadas; generalmente solo suelen manejar rutas estáticas, y otros con una programación mucho más extendida donde se pueden observar la implementación de los diferentes protocolos de enrutamiento. Dentro de estas herramientas a continuación se listan y detallan las más destacadas e importantes debido a su funcionalidad y características específicas así como debido a su popularidad. FREESCO LEAF IPRoute Routed Gated XORP Zebra – Quagga
2.2.1. FREESCO
FREESCO más que un programa o herramienta, es una distribución en la cual se ha pretendido compilar el kernel de Linux hasta hacerlo tan pequeño para que esta distribución pueda ser grabada en un diskette. Su nombre viene de Free y Cisco, con el cual pretende hacer notar que es un enrutador libre. Esta distribución funciona sin la necesidad de tener un disco duro, y tiene la facilidad del manejo de rutas estáticas, con lo cual se puede tener un enrutador básico sin tener que adquirir equipos muy costosos y además su configuración es muy sencilla. Entre las ventajas que presenta esta distribución es que se puede instalar en un computador prácticamente obsoleto sin necesidad de tener un disco duro, lo cual permite abaratar costos frente a un enrutador costoso. Esta distribución puede ser
63
implementada en un computador con procesador 486 sin ningún problema, sin tener necesidad de un disco duro; esto permite utilizar computadores que se han dado por obsoletos o inútiles y convertirlos en unos funcionales enrutadores. Esta distribución soporta hasta 9 tarjetas de red, pero el problema es encontrar un computador que las tenga, y lo que se suele hacer es utilizar tarjetas con multipuertos de red. La desventaja que presenta FREESCO es que no tiene soporte para muchos elementos de hardware de las diferentes marcas existentes, y la desventaja más grande es que solo funciona con rutas estáticas y no se pueden implementar protocolos de enrutamiento dinámico. Además de las opciones de enrutamiento que se puede encontrar con esta distribución, se pueden levantar servicios como DHCP, DNS y servidor de acceso remoto. La versión actual es la 0.3.7 que fue liberada en marzo del 2007, y se la pude descargar del sitio oficial que es http://www.freesco.org. [11] 2.2.2. LEAF
LEAF viene del acrónimo Linux Embedded Appliance Firewall y es un proyecto que nace del proyecto LPR o Linux Router Proyect , muy similar a FREESCO, ya que era una distribución que podía ser arrancada desde un diskette. De igual manera es una distribución de código abierto por lo que se la puede utilizar sin la necesidad de adquirir ninguna licencia. Esta pequeña distribución tiene una funcionalidad tanto de enrutamiento como de firewall por lo que se volvió muy popular. Pero de igual manera que FREESCO solo se pueden implementar rutas estáticas en esta distribución, es decir que no presenta la funcionalidad de enrutamiento dinámico. La última versión de LEAF es la 3.1 y fue liberada en marzo del 2007, y puede ser descargada desde el sitio Web http://leaf.sourceforge.net. [12]
64
2.2.3. IPROUTE
IPRoute es un paquete desarrollado por Alexey Kuznetsov que consiste en un conjunto de herramientas muy potentes para administrar interfaces de red y conexiones TCP/IP en sistemas Linux. Este paquete tiene características de enrutamiento y de control de tráfico. Este paquete se lo puede encontrar en distribuciones con kernel superior a la versión 2.2. Entre las funciones que puede realizar este paquete se describen las siguientes: Calidad de servicio (QoS) donde se priorizan distintos tipos de tráfico. Gestión de múltiples tablas de enrutamiento por diferentes puertas de enlaces conectadas a distintos dispositivos. Balanceo de carga donde se le asigna determinada cantidad de tráfico a cada una de las interfaces de red en el computador. Implementación de túneles que permiten el encapsulamiento de paquetes en un formato IPv4. Esto puede ser útil para encapsulamiento de paquetes IPv6 en paquetes IPv4.
La desventaja que tiene este paquete es que no se manejan protocolos de enrutamiento como tal sino más bien se establecen rutas estáticas que pueden ser a través de las interfaces o de las direcciones de red; se pueden trabajar con varias redes teniendo en cuenta el número de interfaces de red en el computador, siendo esto importante en el caso de compartir conexiones entre dos o más redes. También es útil como mecanismo de seguridad ya que se puede evitar el acceso a determinada red. Una ventaja muy sobresaliente es el balanceo de carga y el control de tráfico que en ciertas circunstancias pude ser muy útil de acuerdo al tipo de tráfico y de conexión que se tiene.
65
2.2.4. ROUTED
Routed es uno de los paquetes de enrutamiento estándar disponibles para Linux, que se caracteriza por soportar RIPv1. Routed es el demonio 29 que administra este protocolo y funciona de una manera muy simple, pues cuando el demonio se está ejecutando envía señales de broadcast de sus tablas de enrutamiento a los enrutadores vecinos, lo cual da como resultado una tabla completa de enrutamiento que tiene entradas para cada destino en la red. Para poder poner en marcha este demonio primero se deben configurar las direcciones IPs de las interfaces a través del comando ifconfig; luego se deben definir rutas estáticas con el comando route add y a continuación se debe poner en marcha el demonio utilizando el comando
routed .
Esta herramienta puede ser muy útil siempre y cuando se tengan redes no muy complejas con el protocolo RIPv1 configurado. Además esta herramienta funciona con direcciones con clase por lo que no se podría utilizar subneting o superneting en estas redes. En general esta herramienta suele ser muy utilizada debido a que es fácil de configurar en redes pequeñas y no se necesita mucha experiencia para hacerlo. 2.2.5. GATED
Gated es un paquete comercial muy conocido debido a su soporte y a su funcionalidad. Este paquete implementa todos los protocolos de enrutamiento RIPv1, RIPv2, OSPF y BGP, pero se necesita una configuración avanzada para su correcto funcionamiento. Gated comenzó como una herramienta de código abierto, pero luego sus derechos fueron adquiridos por la empresa NetHop Technologies [13], es por este motivo que se desarrollaron varios proyectos para poder tener una herramienta que sea de código abierto y que tenga la
29
Los demonios o daemons son programas cuyos procesos se encuentran ejecutándose en modo background o en segundo plano.
66
funcionalidad de manejar protocolos de enrutamiento dinámico. El demonio que administra el conjunto de protocolos se llama gated . Actualmente la empresa que tiene los derechos de este proyecto se ha encargado de ofrecer al mercado enrutadores con esta herramienta instalada. 2.2.6. XORP
XORP viene del acrónimo Extensible Open Router Platform , y es un programa de código abierto que sirve para enrutamiento, que nace como un proyecto fundado por Mark Handley en el año 2000, aunque su primera versión se liberó en el 2004. Actualmente el proyecto está dirigido por Atanu Ghosh [14] y la última versión que se encuentra actualmente es la versión 1.4. Este paquete está totalmente escrito en C++ y se lo considera como uno de los proyectos de enrutamiento que plantea mayor expectativa por su flexibilidad, ya que puede ser implementado tanto en ambientes Linux como Windows Server 2003 30. XORP maneja protocolos de enrutamiento como RIP, OSPF, BGP, PIM, IGMP, MLD. Se puede implementar enrutamiento tanto con direccionamiento IPv4 así como con direccionamiento IPv6. XORP tiene una versión para ser instalada y una versión en Live CD con lo cual se inicializa un sistema operativo desde el CD y se puede tener un enrutador sin la necesidad de instalar el paquete; en este tipo de enrutador se guardan los archivos de configuración en un diskette con lo cual la próxima vez que se inicialice el enrutador desde un Live CD se cargan los archivos de configuración salvados.
30
Puede ser Implementado en Windows Server 2003 pero solo en su versión para IPv4.
67
El shell que maneja a XORP es una interfaz de línea de comandos conocida como xorpsh, donde el usuario puede interactuar con este programa de enrutamiento y realizar las configuraciones respectivas. La configuración de XORP se la hace por línea de comandos, y es bastante sencilla de utilizar, para ello existen manuales que permiten ver el funcionamiento y configuración de un enrutador basado en este paquete. Hay que tener en cuenta que el tipo de comandos no son los mismos que los de un enrutador Cisco por lo que es necesario aprender el funcionamiento previo de este paquete antes de comenzar a configurarlo. Muchas compañías como Microsoft están interesadas en este producto y se encuentran en conversaciones para adquirirlo ya que tiene una gran proyección a futuro. 2.2.7. ZEBRA – QUAGGA
Zebra es un paquete de código abierto para enrutamiento TCP/IP que puede ser instalado sobre plataformas Linux. En un principio este programa fue desarrollado por Kunihiro Ishiguro, quien vio la necesidad de desarrollar un programa que pueda establecer los algoritmos de enrutamiento dentro de plataformas Linux y que sobre todo sea de código abierto; es así como nace el proyecto Zebra. Este programa fue escrito en su totalidad en C y soporta protocolos como RIPv1, RIPv2, RIPng, OSPFv2, OSPFv3 y BGPv4, además soporta SNMP. [15] Otra característica importante de Zebra es que tiene soporte para direccionamiento IPv4 y direccionamiento IPv6. Una de las características más destacadas de este paquete es su interfaz de línea de comandos, que es muy similar a la interfaz de línea de comandos de un enrutador CISCO, inclusive sus comandos de configuración son similares.
68
Otra característica importante de Zebra es que está estructurado por módulos en los cuales se tiene un demonio para administrar a cada uno de los protocolos; Zebra es el demonio que administra el funcionamiento de todos estos demonios de enrutamiento. El demonio Zebra es el encargado de administrar las tablas de enrutamiento del kernel. Cada uno de los módulos lee un archivo de configuración que se va generando el momento de configurar el enrutador, en este archivo se van guardando las instrucciones con las cuales debe funcionar el enrutador configurado. Los archivos de configuración tienen un formato de texto simple y también pueden ser generados de forma manual tomando en cuenta el orden y formato para su interpretación por el programa. Además Zebra puede ser configurada a través de una herramienta que integra a todos los demonios, esta herramienta es el vtysh, que más allá de ser una herramienta es un shell para configurar en conjunto a todos los demonios de Zebra. Zebra está diseñado para kernel de Linux 2.0.37 o superior para enrutamiento con IPv4 y, se necesita un kernel de Linux 2.2 o superior para enrutamiento con direccionamiento IPv6. Se tienen otras ventajas en Zebra como por ejemplo el acceso remoto para la configuración utilizando telnet, como en un enrutador CISCO, pero con la característica que se debe hacer telnet en cada uno de los puertos de cada uno de los demonios. A continuación se detalla en la Tabla 2-2 los demonios y los puertos utilizados por los mismos:
Demonio nio Pu Pueerto rto
Protocolo de transporte
zebra
2601
TCP
ripd
2602
TCP
ripngd
2603
TCP
ospfd
2604
TCP
bgpd
2605
TCP
Tabla 2-2. Puertos utilizados por los demonios en zebra
69
La última versión del paquete de software Zebra fue lanzada el 27 de noviembre del 2003, por lo que actualmente se considera una versión antigua y con muchos errores, además con el desarrollo de las diferentes distribuciones, se necesitan muchas más consideraciones en este paquete; es por eso que nace el proyecto QUAGGA [16] que es una bifurcación del proyecto Zebra, siendo éste el encargado de ir desarrollando a Zebra a través de los diferentes errores y problemas que presentaba este paquete. Quagga es un paquete de software de código abierto por lo que se pueden hacer modificaciones en el código y se puede además utilizar dicho paquete sin tener que pagar ninguna licencia. Actualmente Quagga es un paquete que ha tomado toda la arquitectura del paquete Zebra y ha ido añadiendo y mejorando su funcionalidad a través de los diferentes errores encontrados en el paquete original. Aparte de eso se le ha venido dando la funcionalidad necesaria para cada una de las distribuciones que soportan este paquete y también se han solucionado problemas de seguridad que se han encontrado. Al igual que Zebra, Quagga soporta protocolos de enrutamiento dinámico como RIP, OSPF y BGP tanto en sus versiones para direccionamiento en IPv4 como para direccionamiento IPv6, y se tiene planificado que para futuras versiones tenga soporte para enrutamiento multicast . La última versión estable de Quagga es la versión 0.98.6 y fue lanzada en junio del 2005 y la versión más actual es la 0.99.8 liberada el 27 de julio de 2007. Cada una de estas versiones se las puede encontrar en el sitio Web de Quagga que es http://www.quagga.net, al igual que se puede encontrar la documentación necesaria para la configuración de este paquete, así como también información sobre los cambios que han tenido las diferentes versiones. Quagga puede ser instalado en distribuciones con núcleo de Linux 2.2.0 o superior, o también puede ser instalado en otras plataformas como:
70
FreeBSD 4.x o superior NetBSD 1.6 o superior OpenBSD 2.5 o superior Solaris 2.6 o superior 31
Hay que destacar que Zebra y Quagga no van a tener toda la funcionalidad que tiene un enrutador Cisco pero si va a cumplir el propósito de enrutamiento que es su función principal; además no soporta protocolos de enrutamiento propietarios como EIGRP.
2.3. OTROS USOS DEL ENRUTAMIENTO Dentro de las redes de datos se puede también utilizar al enrutamiento como medio para realizar otro tipo de funciones como por ejemplo poner una barrera de ingreso a determinadas redes ( firewall ), ), o simplemente para el establecimiento de redes privadas virtuales (VPNs). Además se puede utilizar NAT para intercambiar paquetes entre redes de direccionamiento incompatible. 2.3.1. NAT
NAT viene del acrónimo Traducción de Direcciones de Red ( Network Address Translation ) y es muy utilizado en direccionamiento IPv4 ya que fue creada debido al agotamiento de las direcciones públicas IPv4 en el Internet. NAT tiene como función la traducción de direcciones de una red a otra, para que estas dos redes se puedan comunicar. Estas traducciones son guardadas en una tabla de traducción, lo que permite una comunicación entre dos puntos de redes diferentes. En general su uso se ha implementado en redes privadas para acceso al Internet cuando no se disponen de direcciones públicas suficientes; es decir que las 31
Para que Solaris tenga soporte para IPv6 se necesita instalar un parche adicional.
71
direcciones privadas pueden acceder al Internet a través de una única dirección pública utilizando este método de traducción de direcciones. A este tipo de traducción se la conoce como PAT ( Port Address Translation ) ya que arma la tabla de traducción con la información de las conexiones TCP y UDP en los diferentes puertos tanto de entrada y salida, esto permite que los paquetes que ingresen sean direccionados adecuadamente. NAT también puede ser aplicada de una manera estática donde se tienen conexiones de host a host , es decir cuando se quiere tener una comunicación entre dos equipos que se encuentra en redes diferentes atravesando el Internet por ejemplo. En la Figura 2-3 se puede observar cómo NAT sirve de enlace entre la red interna y el Internet
Fuente: http://www.skullbox.net/firewalls Figura 2-5. NAT
Dentro de Linux la herramienta más utilizada para la configuración de NAT es IPTABLES, que no solo sirve para la traducción de direcciones sino que es un poderoso firewall . Con esta herramienta se puede realizar el filtrado de paquetes que puede ser un complemento ideal a un enrutador, es decir puede funcionar muy bien como complemento a herramientas como Quagga o XORP.
72
2.3.2. VPN
Las Redes Privadas Virtuales, VPNs, son mecanismos muy utilizados ya que permiten un acceso remoto desde una red hacia otra de una manera segura. Un ejemplo claro de una VPN es cuando una persona quiere ingresar a la red de su oficina desde el computador de su casa utilizando el Internet; para esto se necesita tener una manera segura de hacerlo. Generalmente en este tipo de redes está presente la autenticación, la autorización y la codificación de los datos. En general al hacer una conexión con una VPN es como estar dentro de la red a la cual nos estamos conectando pero desde un sitio remoto. Para este tipo de redes se tienen soluciones tanto en software como en hardware. Fabricantes como Cisco, Nortel, D-Link, etc. ofrecen soluciones en hardware para el establecimiento de redes privadas virtuales; mientras que sistemas operativos como Windows y Linux presentan soluciones para la elaboración de redes privadas virtuales a través de software. De igual manera que la mayoría de soluciones de software existen aquellas que son de código abierto y aquellas por las cuales hay que pagar una licencia para utilizarlas. En la Figura 2-4 se puede observar cómo se forman túneles virtuales a través del Internet cuando se realiza una conexión a través de una VPN.
Fuente: http://www.miscascos.com/graficos/img_categoria Figura 2-6. Red Privada Virtual
73
Una de las ventajas de utilizar VPNs es que no se necesita establecer un camino físico directo, que suele ser costoso, para acceder remotamente a una red, sino que se puede utilizar la infraestructura del Internet para poder realizar la conexión remota.
REFERENCIAS CAPÍTULO 2 [1]
TANENBAUM, Andrew S.; Sistemas Operativos Modernos. Segunda Edición. Prentice Hall. 2003
[2]
NUTT, Gary; Sistemas Operativos. Tercera Edición. Pearson.
[3]
CARRETERO, Jesús; GARCÍA, Félix; ANASAGASTI, Pedro de Miguel; PÉREZ, Fernando, Sistemas Operativos – Una visión aplicada. McGraw Hill. Primera Edición. 2001
[4]
Fedora Proyect http://fedoraproject.org Último acceso: 2007 – 08 – 16
[5]
White Paper: Cisco IOS Reference Guide http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_whit e_paper09186a008018305e.shtml Último acceso: 2007 – 05 – 07
[6]
Windows Vista http://www.microsoft.com/spain/windows/default.mspx Último acceso: 2007 – 05 – 08
[7]
Fundamentos del enrutamiento TCP/IP para Windows NT http://support.microsoft.com/kb/140859/es Último acceso: 2007 – 05 – 08
74
[8]
Instalación de enrutador biblioteca de red multiprotocolo y configuración http://support.microsoft.com/kb/138793/es Último acceso: 2007 – 05 – 08
[9]
Routing and Remote Access http://www.microsoft.com/technet/network/rras/default.mspx Último acceso: 2007 – 05 – 08
[10]
TACKETT, Jack; GUNTER, David. Linux. Tercera Edición. Prentice Hall.
[11]
FREESCO http://www.freesco.org Último acceso: 2007 – 05 – 09
[12]
LEAF http://leaf.sourceforge.net Último acceso: 2007 – 05 – 09
[13]
GATED http://www.gated.org Último acceso: 2007 – 05 – 09
[14]
XORP http://www.xorp.org Último acceso: 2007 – 05 – 09
[15]
Zebra http://www.zebra.org Último acceso: 2007 – 08 – 16
[16]
Quagga http://www.quagga.net Último acceso: 2007 – 08– 16
CAPÍTULO 3 MÁQUINAS VIRTUALES Y SIMULADORES
75
CAPÍTULO 3. MÁQUINAS VIRTUALES Y SIMULADORES
En este capítulo se destacan las principales características de la virtualización y sus tipos. Se detalla además el concepto de máquina virtual y su utilidad para propósitos de enrutamiento, así como también se detallan las herramientas más destacadas para su implementación. Por otro lado se presenta una descripción de los simuladores de las redes de datos, sus principales características y se describen los más utilizados. Se expone además un detalle, a manera de comparación, de las principales ventajas y desventajas del uso de enrutadores en máquinas virtuales y del uso de simuladores de redes de datos con motivos de aprendizaje para la creación de ambientes de enrutamiento.
3.1. VIRTUALIZACIÓN En forma general, la virtualización se refiere a producir un efecto de existencia aparente y no real; pero ya de manera más específica, en computación la virtualización es un proceso a través del cual se pueden dividir los recursos de un computador en varios ambientes de ejecución, aplicando conceptos como particionamiento del hardware y del software, compartición de tiempo, simulación y emulación. En otras palabras la virtualización es el proceso de presentar un agrupamiento lógico de recursos computacionales, tal que puedan ser utilizados en modos distintos de la configuración original, entregando de esta manera nuevos y distintos beneficios. Dentro de la virtualización existen dos tipos bien definidos: Virtualización de recursos Virtualización de plataforma
76
3.1.1. VIRTUALIZACIÓN DE RECURSOS
La Virtualización de recursos se refiere a la agrupación de recursos individuales comunes de un sistema de cómputo, para crear la idea de un solo recurso con mejores y mayores características. Entre los principales beneficios de la virtualización de recursos se pueden indicar la mejora de la utilización de los recursos, incremento de la flexibilidad, rebaja del costo total, así como la mejora de la disponibilidad y fiabilidad de los entornos. Utilizando virtualización de recursos los costos pueden resultar más bajos, ya que se pueden utilizar elementos de características similares y de bajo costo, que en su conjunto pueden llegar a conformar un elemento de características superiores, y sobre todo su costo total no llega a ser igual al de un recurso con las mismas características pero fabricado con dicho propósito específico o especializado. Esto permite ahorros importantes en empresas o compañías; además al ser una agrupación de recursos en caso de alguna falla no se tiene que reemplazar todo sino solo la parte afectada. Los discos RAID32 son un claro ejemplo de una virtualización de recursos ya que implementa un arreglo de discos de bajo costo, para presentar en su conjunto un gran elemento de características importantes; aquí se puede tener información redundante que suele ser beneficioso para el manejo adecuado de la información. Existen varios tipos de arreglos RAID de acuerdo a sus características y número de discos que lo conforman; así mismo la utilización de cada uno de estos tipos va a depender de las necesidades y del factor económico. En la Figura 3-1 se puede observar los diferentes tipos de arreglos RAID que se disponen y que se pueden implementar.
32
RAID viene del acrónimo en inglés Redundant Array of Inexpensive Disks , lo que quiere decir que es un Arreglo Redundante de Discos Baratos.
77
Fuente: Linux System Administration I: Implementation Figura 3-1. Virtualización de Recursos – RAID
Los Clusters y los Grids también son ejemplos de virtualización de recursos, ya que la unión de varios computadores permite conformar un sistema que brinde mejores prestaciones para determinada aplicación. Otro ejemplo de virtualización de recursos es el Channel Bonding que a breves rasgos es la agrupación de varios canales de datos para tener un canal con un ancho de banda mayor. En la Figura 3-2 se puede observar un ejemplo de Channel Bonding con líneas telefónicas para tener un solo enlace con mayor ancho de banda.
Fuente: http://www.remotesatellite.com/other_products_multiplexers_v100_isdn_terminal.php Figura 3-2. Virtualización de Recursos – Channel Bonding
78
3.1.2. VIRTUALIZACIÓN DE PLATAFORMA
La virtualización de plataforma, conocida también como virtualización de software, es la creación de un ambiente virtual utilizando los elementos de hardware y software de un computador; este ambiente virtual es la emulación de un hardware de cómputo completo donde puede ser instalado un sistema operativo completo que se ejecuta como si estuviera en una plataforma de hardware autónoma. Este ambiente virtual puede emular a un CPU (puede ser más de uno), BIOS, tarjeta gráfica, memoria RAM, tarjeta de red, sistema de sonido, conexión USB, disco duro (pueden ser más de uno), etc. Una definición interesante respecto a la virtualización de plataforma es la presentada en un artículo de la revista Technology@Intel: “La virtualización de plataforma se puede definir como la creación de un sistema de cómputo dividido de forma lógica que se ejecuta sobre una plataforma presente. Aunque la virtualización se ha aplicado al almacenamiento y a los servidores, el concepto de virtualización de plataforma se extiende para incluir todas las capas de la plataforma; desde las aplicaciones y el software operativo hasta los componentes, procesadores e interconexiones de la plataforma.” [1] La virtualización de plataforma se ha vuelto muy popular en los últimos años, y como se menciona en el párrafo anterior se aplica principalmente en servidores y almacenamiento. La virtualización actualmente se ha estado usando para darle a determinado equipo de cómputo un mejor uso tratando de optimizar de mejor manera los recursos y aprovecharlos al máximo. 3.1.2.1. Máquina Virtual
Dentro de la definición de virtualización de plataforma calza la definición de máquina virtual que no es otra cosa más que un computador virtual ( guest o invitado) corriendo sobre un computador real ( host o anfitrión); o de forma más clara una máquina virtual da la idea de tener un computador dentro de otro computador.
79
Existen dos tipos de máquinas virtuales: Máquina Virtual por Proceso Máquina Virtual por Sistema
La Máquina Virtual por Proceso es aquella máquina virtual que crea un entorno para que determinada aplicación se ejecute. Un claro ejemplo de este tipo de máquinas virtuales es la Máquina Virtual de Java que crea un entorno para que las aplicaciones Java se ejecuten en los diferentes sistemas operativos. La Máquina Virtual por Sistema 33 ofrece un entorno de ejecución completo, es decir que se crea un entorno de hardware completo para que se ejecute un sistema operativo completo. En la Figura 3-3 se puede observar la estructura de una máquina virtual en una máquina real donde se destaca el Monitor de Máquina Virtual (VMM), el cual permite que se ejecuten varias máquinas virtuales sobre una plataforma de hardware única. El monitor de máquina virtual opera como anfitrión y controla el microprocesador y el hardware del sistema; además este software puede tener el control selectivo de algunos recursos del procesador, de la memoria física, de la gestión de interrupciones y de los accesos de entrada/salida. El Monitor de Máquina Virtual puede interactuar directamente con el hardware del computador real o puede interactuar de forma indirecta a través del sistema operativo del sistema anfitrión.
Fuente: http://www.hwupgrade.it Figura 3-3. Máquina Virtual – Monitor de Máquina Virtual (VMM)
33
En este documento al hablar de Máquina Virtual se refiere a Máquina Virtual por sistema
80
El computador virtual está emulado en software dando las características físicas de un computador real; esta emulación permite tener elementos de hardware como discos duros, dispositivos de red, unidades de CD, memoria, procesadores, etc., todo esto se lo realiza con programas virtualizadores. Los virtualizadores utilizan los elementos de hardware del computador real, si es necesario, para poder interactuar con el medio exterior, o pueden emular componentes físicos que no se encuentran disponibles como por ejemplo discos SCSI, tarjetas de red, unidad de CD o disquetera. De igual manera se pueden añadir discos duros a la máquina virtual siendo estos ficheros generados por el virtualizador. Hay que tener en cuenta que la memoria y los discos duros no se pueden añadir desmedidamente ya que los virtualizadores utilizan la memoria física y la disponibilidad de espacio de disco duro. En otras palabras no se puede crear una máquina virtual con 2GB de memoria RAM si la máquina física solo dispone de 1GB; de igual manera con los discos duros, no se puede crear una máquina virtual con 30 GB de disco duro si solo se dispone de 10 GB de espacio en disco. Se puede tener más de una máquina virtual en un mismo computador como se muestra en la Figura 3-4 y esto va a depender de las características físicas del computador real, es decir la disponibilidad de memoria RAM y el espacio en disco duro; con esto se pueden tener varios sistemas operativos en un mismo equipo corriendo al mismo tiempo.
Fuente: http://www.arcos.inf.uc3m.es/~jdaniel/seminarios/ssooa06/maquinas-virtuales.ppt Figura 3-4. Máquinas virtuales en un mismo hardware
81
Existen varias herramientas de software para virtualización algunas, que pueden instalarse en Linux, otras en Windows y otras en ambos sistemas; de estas se destacan las siguientes: Bochs CoLinux Microsoft Virtual PC y Microsoft Virtual Server Parallels Workstation QEMU Simics Virtual Iron VM from IBM VMware (ESX Server, Fusion, Virtual Server, Workstation, Player y ACE) Xen KVM VirtualBox
En el presente proyecto de titulación se van a describir Microsoft Virtual PC y VMWare. 3.1.2.1.1. Microsoft Virtual PC
Microsoft Virtual PC es una herramienta para virtualización, que en un principio fue desarrollada por la empresa Connectix y fue adquirida por Microsoft en el 2003. Una de las ventajas que para muchos es una de las más importantes es que es gratuita y se puede descargar de la página de Microsoft. Existen versiones para Mac y para Windows. Este software crea un entorno virtual en el cual se emula un computador con todas sus características de hardware para que en éste pueda ser instalado un sistema operativo. Este software puede crear varios ambientes virtuales dependiendo de la cantidad de memoria y espacio en disco, siendo cada uno de estos ambientes llamados máquinas virtuales. Cada una de las máquinas virtuales puede usar los recursos del computador físico. En la Figura 3-5 se puede observar a dos máquinas virtuales con sistema operativo Windows XP corriendo sobre un computador con sistema operativo Windows XP.
82
Fuente: The Racional Guide to Microsoft Virtual PC 2004 Figura 3-5. Virtual PC
Actualmente la versión que se está utilizando es el Virtual PC 2007, pero se debe considerar que existió el Virtual PC 2004 y el Virtual Server 2005 que cumplían las mismas funciones de crear máquinas virtuales. El virtual PC 2007 viene incluido en Windows Vista como solución a aplicaciones que no están soportadas en este sistema operativo; además el Virtual PC 2007 puede ser instalado en Windows XP y Windows Server 2003. Los equipos virtuales creados por Microsoft Virtual PC 2007 tienen las características de hardware mostradas en la Tabla 3.1. Virtual PC 2007 puede ser instalado en computadores con procesadores con 400 MHz como mínimo y pueden ser del tipo AMD Athlon/Duron, Intel Celeron, Intel Pentium II, Intel Pentium III, Intel Pentium 4, Intel Core Duo, e Intel Core 2 Duo. Con Virtual PC 2007 se pueden instalar sistemas operativos que son propietarios de Microsoft, así como otros sistemas operativos como Linux o UNIX. En la Figura 3-6 se pueden observar las opciones que presenta este programa.
83
Dispositivo
Característica
Tipo de Procesador
Procesador del equipo anfitrión
Chipset
Intel 82440BX
Tipo de BIOS Memoria RAM
American Megatrends Inc. (AMI 02/22/06) Memoria asignada en la creación del equipo virtual
Tarjeta gráfica
S3 Trio32/64 PCI (8 MBytes)
Tarjeta de sonido
Creative Labs Sound Blaster SB16 PnP
Tarjeta de red
Digital Equipment Corporation DEC-21140 (Adaptador Fast Ethernet PCI basado en Intel 21140 "Genérico")
Disquetera
Disquetera del equipo anfitrión (También admite capturar imágenes VFD, IMG, IMA y DSK de disquete)
Discos duros
Virtual HD (discos virtuales asignados en la creación del equipo virtual)
Lector CD/DVD ROM
Lector CD/DVD ROM del equipo anfitrión (También admite capturar imágenes ISO de CD/DVD) Fuente: Virtualización con Microsoft Virtual PC 2007
Tabla 3-1. Características de hardware del Virtual PC 2007
Figura 3-6. Opciones de Sistemas Operativos en Virtual PC 2007
84
Para nuestro caso en particular la opción “Otro” será la utilizada para instalar el sistema operativo Linux, el cual servirá para cumplir las funciones de enrutador. El Virtual PC 2007 incluye un módulo de ayuda en el cual se pueden despejar muchas dudas respecto a su instalación y utilización; además en el sitio Web de Microsoft se puede encontrar gran cantidad de soporte para cualquier inconveniente que se presente. 3.1.2.1.2. VMware
VMware es una familia de productos de cómputo virtual empresarial que ha venido creciendo muy rápido a nivel mundial por sus características y funcionalidad. Básicamente sus productos permiten que se instalen y ejecuten varias máquinas virtuales en un mismo computador. Lo anterior ofrece la versatilidad de poder consolidar diferentes servidores físicos en uno sólo, representando importantes ahorros económicos y de administración y asegurando la disponibilidad de los mismos. La virtualización con VMware acelera los tiempos de instalación de servidores o estaciones de trabajo, ya que todas las máquinas virtuales son transportables entre equipos bajo la plataforma VMware. Dentro del ambiente de Máquinas Virtuales de VMware, es posible instalar y ejecutar cualquier combinación de sistemas operativos y versiones que sean compatibles y estén certificadas para operar correctamente. Actualmente hay una gran lista de sistemas operativos y versiones que van desde DOS hasta las últimas versiones de Windows Server 2003 y Windows Vista, así como también las más recientes distribuciones de Linux (Fedora, Red Hat Enterprise, Suse, etc.). La limitante que se tiene en este respecto es la capacidad de RAM, Disco y CPU del equipo en el que se instale y operen los producto VMware. El uso de recursos recomendados para cada uno de los sistemas operativos bajo VMware es muy similar a los recursos estándar y recomendados por sus
85
fabricantes. Se deberá tomar en cuenta que VMware necesita de algunos recursos de RAM para poder realizar una correcta administración y monitoreo de las Máquinas Virtuales en ejecución, que dependerá de los ambientes que se deseen instalar y ejecutar de manera simultánea. VMware es un producto comercial pero se tienen algunos productos que son gratuitos lo cual permite una utilización de los mismos sin necesidad de adquirir ninguna licencia. Entre los productos gratuitos se destaca VMware Server que prácticamente tiene las mismas características de Virtual PC, es decir que es un programa que se instala sobre un sistema operativo anfitrión y con este programa se procede a crear las máquinas virtuales, pero a diferencia de Virtual PC, VMware Server es un programa que se puede instalar tanto en sistemas operativos Windows como Linux, y se pueden instalar una gran cantidad de sistemas operativos invitados; en la Figura 3-7 se observan las opciones que da VMware Server para los sistemas operativos invitados.
Figura 3-7. Opciones de Sistemas Operativos en VMware Server
Con el VMware Server se crea un hardware virtual que tiene las características que se muestran en la Tabla 3-2.
86
Dispositivo
Característica
Tipo de Procesador
Procesador del equipo anfitrión
Chipset
Intel 440BX-based motherboard
Tipo de BIOS Memoria RAM
PhoenixBIOS Memoria asignada en la creación del equipo virtual
Tarjeta de red
AMD PCnet-PCI II compatible
Disquetera
Disquetera del equipo anfitrión (se puede utilizar imágenes en lugar de disqueteras físicas)
Discos duros
Virtual HD
Lector CD/DVD ROM
Lector CD/DVD ROM del equipo anfitrión (También admite capturar imágenes ISO de CD/DVD)
Fuente: Restoring Suspect Physical and Compressed Images with VMWare Tabla 3-2. Características de hardware del VMware Server
VMware puede ejecutar las máquinas virtuales creadas con Virtual PC lo cual es de ayuda cuando se tengan máquinas instaladas con cualquiera de los dos tipos de virtualizadores. Otra característica importante de VMware Server es el soporte que presenta para máquinas virtuales con sistemas operativos de 32 y 64 bits. Entre los requerimientos mínimos para instalar el VMware Server están procesadores con una velocidad mayor a 733 MHz (desde procesadores Pentium II hasta los más actuales, pues cuenta con soporte para procesadores de doble núcleo). Por otro lado los requerimientos de memoria RAM van a depender de la cantidad de memoria que se adjudique a los equipos virtuales, empleando el mismo criterio para el espacio en disco duro. Información acerca del funcionamiento e instalación de este producto se puede encontrar en la página de VMWARE, http://www.vmware.com, o se puede acudir a la ayuda que presenta el programa después de ser instalado.
87
3.1.2.2. Máquinas virtuales como enrutadores
En el capítulo 1 se mencionó que los enrutadores por software pueden ser instalados en sistemas operativos estándar, pudiendo tener un desempeño aceptable de los mismos; para poder hacer este tipo de enrutadores se necesita un computador al cual se le debe instalar un sistema operativo y luego configurarlo de tal manera que funcione con el propósito deseado. Si se necesita solo un enrutador es factible, pues se puede tener un computador en el cual se lo pueda instalar; pero en el caso que se necesiten muchos enrutadores para equipar un laboratorio donde se van a hacer prácticas de enrutamiento, es más difícil conseguir tantos equipos. Si se tiene un Centro de Cómputo con computadores con sistemas operativos Windows o Linux, se puede plantear la alternativa de utilizar máquinas virtuales para instalar y configurar los enrutadores, sin tener que cambiar la configuración de los equipos del centro de cómputo. Desde el punto de vista práctico, si se desea implementar un enrutador por software en cualquier computador ya sea con sistemas operativos Windows o Linux, se pueden utilizar herramientas de virtualización para hacerlo sin tener que modificar nada del sistema operativo anfitrión. Esto va a permitir dar mayor funcionalidad al centro de cómputo ya que éste no va a estar dedicado única y exclusivamente a propósitos de pruebas de enrutamiento. Una máquina virtual desempeñando las funciones de enrutador va a permitir que los usuarios puedan realizar las pruebas correspondientes de enrutamiento utilizando los componentes de hardware disponibles en un centro de cómputo. Además se pueden tener muchas máquinas virtuales como enrutadores en un mismo equipo, dependiendo de las características de hardware (memoria RAM y Disco Duro) del equipo anfitrión; esto va a permitir realizar pruebas de enrutamiento en un mismo equipo como si se tuvieran varios enrutadores físicos a la vez. Las herramientas como Virtual PC o VMware Server van a permitir que se implementen dichos enrutadores teniendo a disponibilidad los componentes
88
físicos del computador anfitrión, para realizar pruebas reales de enrutamiento entre varios equipos de cómputo como si éstos estuvieran utilizados única y exclusivamente para este propósito. Al implementar un enrutador en una máquina virtual no se van a tener a disposición todos los recursos de hardware del computador anfitrión, ya que dichos recursos van a ser utilizados por el sistema operativo anfitrión como son la memoria RAM y el espacio en Disco, pero esto no es una limitante para un buen desempeño de los mismos. En la Figura 3-8 se puede observar un esquema de dos máquinas virtuales en las cuales están instalados los paquetes de enrutamiento.
Figura 3-8. Máquinas virtuales como enrutadores
En la Figura 3-9 se puede ver a dos computadores con máquinas virtuales desempeñando las funciones de enrutadores.
89
Figura 3-9. Enrutadores en máquinas virtuales
De los dos gráficos anteriores se observa que se pueden implementar los enrutadores en máquinas virtuales y establecer escenarios de enrutamiento en un mismo computador, es decir varias máquinas virtuales como enrutadores en un mismo computador, sin interactuar con las interfaces físicas del computador local. Por otro lado se pueden implementar escenarios de enrutamientos con varios computadores con una máquina virual por computador (donde se encuentra el enrutador) e interactuar a través de las interfaces físcas, dando como resultado un escenario real de enrutamiento.
3.2. SIMULADORES Dentro del mundo de las redes de la información los simuladores son programas computacionales diseñados para crear ambientes de comunicaciones con características muy similares a la realidad; es decir que los simuladores permiten diseñar redes de datos en un programa y ver su comportamiento. Los simuladores permiten analizar el comportamiento de las redes de datos ante cambios de topología dependiendo del tipo de protocolo implementado (RIP, BGP, OSPF, etc.). Estos programas tienen desarrollados, a nivel de software, los elementos de hardware que una red de datos dispone como son switches , enrutadores,
90
computadores, etc., esto permite que se puedan establecer todos los parámetros de comportamiento de una determinada red de datos. Cada uno de estos elementos puede ser configurado como si se estuviera trabajando en un equipo real, y de acuerdo a la configuración que se le brinde se podrá simular el comportamiento que una red pueda tener. Generalmente los simuladores tratan de utilizar características de los enrutadores Cisco para su configuración, presentando una consola con la cual se puede configurar a los equipos simulados similar a la que presentan los enrutadores de esta marca, pudiendo utilizar los comandos con los que se puede configurar estos enrutadores en la realidad. Un simulador resulta útil previa la implementación de determinada red de datos para hacer un análisis de las mejores opciones que se puedan presentar. Por otro lado los simuladores suelen ser utilizados con motivo de aprendizaje cuando no se dispone de los equipos reales debido a su costo. Se pueden encontrar simuladores muy variados y que cumplen distintos propósitos y desarrollados en diferentes lenguajes de programación; su elección va a depender de las necesidades o requerimientos que el usuario presente. Así mismo se pueden encontrar simuladores que son gratuitos y simuladores que se deben adquirir para poder utilizarlos. Generalmente los simuladores más elaborados y que disponen de mayores facilidades, mejores características y mayor cantidad de componentes son los que tienen un costo elevado. Entre los simuladores más importantes se pueden mencionar los siguientes como los más populares y funcionales: Boson NetSim Packet Tracer RouterSim KivaNS OPNET ( su versión gratuita es OMNET++)
De los simuladores mencionados anteriormente se destaca el simulador Boson NetSim como uno de los más completos, pues fue desarrollado con propósitos de
91
aprendizaje como complemento a los cursos que brinda la empresa CISCO para sus diferentes certificaciones en manejo de dispositivos de redes de datos. Este no es un simulador gratuito, pero su funcionalidad es lo más destacado y sus características permiten que se analicen redes de datos casi como si se estuviera trabajando en la realidad. Boson NetSim presenta una consola similar a la de los enrutadores CISCO y toda su configuración se la realiza de la misma manera como si se estuviera trabajando con equipos reales. En la Figura 3-10 se puede observar cómo se estructuran las redes de una manera gráfica para luego pasar a la configuración de los elementos vía consola.
Figura 3-10. Diseño de una red en el simulador Boson NetSim
El simulador Packet Tracer es un simulador propietario de la empresa Cisco que se distribuye como material para las certificaciones; éste es un simulador que carece de muchos elementos, y no dispone de todas las características de enrutamiento, sin embargo es un simulador importante que puede permitir analizar el desempeño de redes no muy complicadas. De igual manera tiene una interfaz gráfica con la que se diseñan las redes para luego poder configurar cada uno de sus elementos vía consola o a través del entorno gráfico que dispone. En la Figura 3-11 se puede observar la interfaz de este simulador.
92
Figura 3-11. Interfaz Gráfica del simulador Packet Tracer
Otro simulador importante de mencionar es el simulador OPNET que es un programa muy utilizado para modelar y simular sistemas de comunicaciones; permite diseñar y estudiar redes, dispositivos, protocolos y aplicaciones, brindando escalabilidad y flexibilidad, lo que permite trabajar en procesos de investigación y desarrollo. A diferencia de Boson Netsim y de Packet Tracer no tiene un ambiente de configuración de consola para los equipos, sino más bien este simulador pretende analizar el comportamiento del conjunto de la red. Se tiene una versión gratuita de este simulador llamada OMNET++ que tiene fines académicos y no comerciales y su principal aplicación es la de simular redes, aunque también es usado en sistemas complejos de telecomunicaciones, estudio de sistemas de colas o arquitecturas hardware.; está basado en el uso de módulos, creados mediante C++. Al igual que su versión comercial no se dispone de un modo de configuración de consola para los equipos pues se pretende analizar la red en su conjunto.
93
3.3. MÁQUINAS VIRTUALES VS. SIMULADORES Tanto las máquinas virtuales y los simuladores tienen sus características propias, así como se pueden encontrar similitudes de acuerdo a su utilidad de enrutamiento; en otras palabras las máquinas virtuales pueden ser utilizadas para simular ambientes de enrutamiento en un laboratorio de cómputo, siendo esto útil para el aprendizaje si no se disponen de los enrutadores físicos. Esto permite comparar tanto a los simuladores como a las máquinas virtuales en un ambiente de simulación de enrutamiento. La principal semejanza entre las dos opciones es que se puede utilizar a ambas para analizar el desempeño de una red de datos, con sus características particulares y los diferentes protocolos de enrutamiento. A esta semejanza se puede presentar una diferencia muy grande que es la de los recursos, ya que una máquina virtual necesita gran cantidad de recursos de memoria y disco para poder funcionar; entre más enrutadores se necesiten en la simulación más cantidad de recursos serían necesarios en un computador. Por otro lado un simulador puede simular muchos enrutadores sin consumir muchos recursos de memoria ni de espacio en disco. En otras palabras un simulador permite construir una red mucho más grande para su simulación en un mismo equipo de cómputo mientras que con enrutadores en máquinas virtuales se necesitarían varios computadores para realizar una simulación de una red grande. Una segunda semejanza es que tanto el simulador como el enrutador en una máquina virtual permiten la configuración a través de una línea de comandos similar a la de un enrutador Cisco. Otra semejanza es que con un simulador y con un enrutador en una máquina virtual se pueden simular redes con los diferentes protocolos de enrutamiento estático y dinámico que se describieron en el capítulo 1.
94
Entre las diferencias se puede destacar que un simulador no puede implementar un ambiente de red real; un simulador no interactúa con las tarjetas de red de un computador para poder utilizar a los mismos dentro de un ambiente real de enrutamiento. Un simulador permite única y exclusivamente el análisis de una red de datos en un programa destinado para ello. Un enrutador en una máquina virtual en cambio, permite que se interactúe con las tarjetas de red del computador siendo esto importante si se quiere ver el comportamiento de dicho enrutador en una red de datos real. Al poder interactuar con una red real se pueden utilizar varios enrutadores ya sean de hardware o de software (en una máquina real o virtual) para comunicarse entre sí, esto permite que se pueda analizar el comportamiento de una red de datos en un ambiente totalmente real. Desde el punto de vista práctico esto puede ser útil si se desea implementar en un centro de cómputo un ambiente de enrutamiento, en el cual se puedan realizar las pruebas pertinentes y se pueda hacer el análisis respectivo al enrutamiento sin necesidad de cambiar el sistema operativo, sino que instalando enrutadores con máquinas virtuales en cada uno de los computadores. También esto puede ser útil en el caso de no disponer de un computador extra para poder instalar un enrutador por software, es decir que se puede utilizar cualquier computador con las características necesarias utilizando máquinas virtuales; esto ahorraría el uso de un computador adicional. Una ventaja importante de un enrutador en una máquina virtual para un ambiente de simulación es el costo, ya que al implementarse en herramientas de virtualización gratuitas con sistemas operativos de código abierto, no resulta costoso; en cambio, utilizando un simulador de buenas características se tendría que pagar las licencias para su utilización para cada uno de los equipos de cómputo sobre los cuales se quiera implementar. En la Tabla 3-3 se puede observar en forma comparativa las ventajas y desventajas que presentan simuladores de enrutadores frente a enrutadores sobre máquinas virtuales.
95
Característica
Simuladores de enrutadores
Enrutadores sobre máquinas virtuales
Puede ser utilizado Si, se puede analizar el Si, es posible analizar el con propósitos de comportamiento de los protocolos comportamiento de los protocolos aprendizaje
en escenarios de enrutamiento.
de enrutamiento.
Puede simular Si, se pueden crear ambientes con Si, pero la restricción respecto al ambientes de muchos enrutadores y también se número de equipos virtuales va a enrutamiento en un pueden incluir otros equipos como depender de las características de mismo computador
switches y computadores.
hardware del equipo anfitrión.
Puede establecer No, un simulador es un programa Si, una máquina virtual pude ambientes reales de computacional que simula a los interactuar con los componentes enrutamiento equipos y no puede ser parte de físicos de un computador, lo que una red de datos real.
permite establecer comunicaciones con otros equipos, lo que permitiría establecer ambiuentes reales de enrutamiento.
Pueden configurarse Si, dependiendo del simulador que No, la implementación de un todos los protocolos se utilice, en general un simulador enrutador con Quagga de enrutamiento
completo como el Boson Netsim independiente de si está en una puede implementer protocolos máquina virtual o no, solo permite propietarios como IGRP y EIGRP.
el manejo de los protocolos estándar y no de los protocolos propietarios.
Puede configurarse Si, algunos simuladores manejan Si, Quagga tiene su propia interfaz a través de línea de una interfaz como la de los equipos de línea de comandos, que es muy comandos
Cisco, aunque otros simuladores similar a la que presentan los tienen ambientes simulación.
Necesita licenciamiento
gráficos
de equipos Cisco.
Si, se necesitan adquirir licencias No, existen herramientas de que suelen ser costosas para tener virtualización gratuitas, y el características importantes de enrutador es de código abierto bajo enrutamiento presenta el NetSim.
como las que Linux por lo que no se necesita simulador Boson pagar nada por su utilización.
Tabla 3-3. Comparación de características entre enrutadores sobre máquinas virtuales y simuladores
96
Para la realización de las prácticas de laboratorio planteadas en el presente proyecto de titulación se presentan algunas opciones ya sea utilizando máquinas reales, máquinas virtuales o simuladores como se detalla a continuación:
Utilizando varios computadores destinados únicamente para enrutamiento, donde el sistema operativo está instalado en la máquina real, y a través de las cuales se establecen los diferentes escenarios de enrutamiento Utilizando varias máquinas virtuales con enrutadores instaladas en un mismo computador y establecer los escenarios de enrutamiento. Utilizando varios computadores como anfitriones de un solo enrutador en una máquina virtual, e interactuar físicamente entre ellos, es decir que las tarjetas virtuales interactuan directamente con las reales de sus anfitriones, para así establecer comunicación entre las máquinas virtuales si se interconectan las máquinas reales. Utilizando simuladores y establecer escenarios de enrutamiento a través de ellos.
La utilización de estas opciones va a depender de la situación o disponibilidad de equipos, así como también de los protocolos de enrutamiento a implementarse. Si se quiere tener un rendimiento adecuado, la mejor opción es utilizar un equipo dedicado exclusivamente para cumplir funciones de enrutador, sin embargo esta opción es poco práctica en un laboratorio de computación ya que cambiar constantemente las configuraciones de los computadores causaría problemas. La mejor opción en este caso es utilizar una máquina virtual por computador e interactuar físicamente entre ellos. Si no se dispone de un laboratorio de computación se pueden hacer las prácticas en un mismo computador utilizando varias máquinas virtuales interconectadas entre ellas, pero para ello se necesita un computador con características de hardware bastante buenas. La última opción es realizar las prácticas utilizando simuladores, que puede ser útil para analizar el funcionamiento de protocolos de enrutamiento que son propietarios.
97
La desventaja de esta opción es que los simuladores suelen ser costosos y que no se pueden utilizar en ambientes reales de enrutamiento.
REFERENCIAS CAPÍTULO 3 [1]
BRUENING, Francis, RAMANATHAN, R.M.; Virtualización: Virtualización: más flexibilidad y nuevas funciones para las plataformas de computación, Technology@Intel, Julio 2004
[2]
Análisis Virtualización: Virtualizaci ón: Menos complejidad, mayor rendimiento http://www.cientec.com/analisis http://www.cientec.com/analisis/Virtualiza /Virtualizacion.asp cion.asp Último acceso: 2007 – 05 – 20
[3]
BARAHONA, BARAHONA , Eugenio; Virtualización Virtualizaci ón o cómo disponer de más de un ordenador virtual sobre uno físico, 2006 http://www.idg.es/pcworldtech/mo http://www.idg.es/pcworldtech/mostrarArticulo.a strarArticulo.asp?id=2 sp?id=29276130 92761308&secci 8&secci on=infraestructura Último acceso: 2007 – 05 – 20
[4]
Sistemas Operativos Avanzados, Máquinas Virtuales http://www.arcos.inf.uc3m.es/~jd http://www.arcos.inf.uc3m.es/~jdaniel/semi aniel/seminars.html nars.html Último acceso: 2007 – 05 – 20
[5]
MANN, Anthony; The Racional Guide to Microsoft Virtual PC 2004. Rarional Press. 2004
[6]
FERNANDEZ, Óscar; Virtualización Virtualización con Microsoft Virtual PC 2007. Primera Edición. 2007
[7]
SHAVERS, Brett, Restoring Suspect Physical and Compressed Images with VMware. Computer Technology Investigators Network.
CAPÍTULO 4 IMPLEMENTACIÓN Y PRUEBAS DEL ENRUTADOR
98
CAPÍTULO 4. IMPLEMENTACIÓN IMPLEMENTACIÓN
Y
PRUEBAS
DEL
ENRUTADOR
En este capítulo se va a describir la implementación del enrutador basado en software, a partir de la instalación del sistema operativo, pasando por la compilación del kernel y la selección de los servicios, para posteriormente proceder con la instalación del paquete de enrutamiento. Además se incluye la configuración básica de Quagga para el enrutamiento estático, y para cada uno de los protocolos de enrutamiento dinámico; se presentarán resultados de pruebas realizadas después de haber elaborado una simulación de escenarios propuestos. Por otro lado se presentará un análisis de costos del enrutador y se hará una comparación con otras soluciones que brindan los mismos beneficios.
4.1. IMPLEMENTACIÓN DEL ENRUTADOR Para poder implementar un enrutador basado en software se requiere tomar en cuenta varios aspectos relacionados con la parte física y la parte de software; es decir, hay que establecer las características de hardware del computador sobre el cual se va a proceder a instalar el sistema operativo y sobre éste el paquete de enrutamiento. Hay que definir tanto la versión de sistema operativo a utilizar, la versión del núcleo del sistema con el cual se va a trabajar y el paquete de enrutamiento y versión con el cual se va a establecer el enrutamiento. Se va a utilizar Fedora Core 5 como sistema operativo para el enrutador, los requerimientos mínimos de este sistema operativo son los que van a limitar el hardware. En general Fedora Core 5 en modo texto necesita ser instalado como mínimo en un computador Pentium de 200 MHz, 64 MB de memoria RAM, disco duro de 2.5 GB. Respecto a dispositivos adicionales, se necesitará una unidad de CD-ROM para su instalación.
99
Para la implementación del enrutador se recompilará el Kernel con la versión 2.6.18.2 liberada el 4 de Noviembre de 2006. Por otro lado el paquete de enrutamiento a utilizarse será Quagga cuya versión a utilizarse será la 0.99.4 liberada 13 de mayo de 2007. 4.1.1. INSTALACIÓN
El proceso de instalación se lo realiza utilizando los discos de instalación del sistema operativo Fedora Core 5. Luego de arrancar con la instalación se escoge el modo en que se quiere instalar, ya sea en modo gráfico o en modo texto, como se muestra en la Figura 4-1. Es recomendable, si no se dispone de muchos recursos en el computador que se utilice el modo texto; sin embargo se puede utilizar el modo gráfico para la instalación, tomando en cuenta que el momento de elegir los paquetes a instalar no se seleccionará ninguna opción gráfica, pues lo que pretende el enrutador es utilizar la mayor cantidad de recursos en el proceso de enrutamiento. Además la configuración y las pruebas de Quagga se las hará en modo de consola.
Figura 4-1. Instalación de Fedora Fe dora Core 5
100
Después de haber elegido el modo de instalación, se escoge el idioma y la configuración de teclado a utilizar, para luego proceder a seleccionar el esquema de particionamiento del disco duro. La selección de las particiones para el caso específico del enrutador se las ha elegido tomando en cuenta los aspectos de seguridad del sistema operativo, así como también tomando en cuenta aspectos de espacio; esto se debe a que va a considerar como espacio máximo en disco duro 10 GB. Partición
Tamaño
Descripción
/
4000
El directorio raíz es el directorio principal y es el que contiene a los demás directorios.
/swap
128
El espacio swap en Linux es usado cuando la cantidad de memoria RAM está llena; si el sistema necesita más recursos de memoria y la memoria física está llena, las páginas inactivas de la memoria se mueven al espacio swap . Generalmente se recomienda que sea del doble del tamaño de la memoria RAM, aunque eso va a depender de la experiencia en la instalación y del uso que se le va a dar al sistema operativo.
/boot
100
Esta partición contiene la imagen del kernel de Linux y los archivos necesarios para el arranque del sistema operativo. En general esta partición no es de gran tamaño pues solo contiene información para el arranque del sistema operativo.
/tmp
1000
Ésta es una partición temporal, donde se almacenarán archivos temporales en caso de ser necesario. Está establecida como una partición separada por conceptos de seguridad.
/var
2000
Es una partición de contenido variable; aquí se almacenan los logs del sistema, y se tendrán también los logs del paquete de enrutamiento.
/usr/local
1000
Es la partición destinada a contener los programas que no se incluyen en la distribución, en el caso particular del enrutador va a contener a la versión de Quagga a utilizar.
/home
1000
Es el directorio destinado a los archivos de los usuarios. Se tiene una partición separada por motivos de seguridad. Tabla 4-1. Esquema de particionamiento del enrutador
101
En la Tabla 4-1 se puede observar el esquema de particionamiento y el uso específico de cada partición para el enrutador. Después de haber elaborado el esquema de particionamiento se procede a seleccionar el gestor de arranque, la hora del sistema y la contraseña de root . Para terminar, se procede a seleccionar una instalación personalizada, donde se escogen los componentes del sistema operativo a ser instalados. En el caso particular del enrutador se seleccionan los componentes mínimos, como editores de texto, compiladores, herramientas de sistema y herramientas administrativas. No se seleccionan entornos gráficos ni aplicaciones de ofimática ya que no serían necesarias para este propósito. Después de seleccionar los componentes se procede a instalar, y con esto culminaría la instalación del sistema operativo. Luego del proceso de instalación del sistema operativo se procede a recompilar el kernel. La compilación del kernel se la realiza para escoger el soporte a los componentes necesarios a utilizarse para el propósito particular del enrutador. Por ejemplo no se necesita soporte para dispositivos de juegos como Joystics en un enrutador, o tampoco se necesita soporte para tarjetas de sonido. También se recompila el kernel para escoger soporte a determinados elementos de hardware que por defecto no vienen compilados, como por ejemplo soporte para interfaces WAN. Tener soporte para muchos componentes que no son necesarios hace que se consuma mucha más memoria y hace que el inicio del sistema operativo sea más largo. Las diferentes versiones del kernel se las puede obtener de la página web http://www.kernel.org. En el Anexo A se presenta el proceso de recompilación del kernel. Una vez recompilado el kernel se procede a seleccionar los elementos de software que se requiere se inicialicen conjuntamente con el sistema operativo, para esto se utiliza el utilitario setup. # setup
102
Este utilitario despliega un menú con varias opciones como se muestra en la Figura 4-2.
Figura 4-2. Menú del utilitario setup
Se selecciona la opción Servicios de Sistema y se despliega un nuevo menú, en el cual se pueden elegir los servicios que se quieren se inicialicen el momento de arrancar el enrutador. En la Figura 4-3 se puede observar el menú con el cual se eligen los servicios. Los servicios que deberían estar habilitados para que se inicialicen automáticamente son:
anacron atd crond gpm irqbalance network readahead readahead_early sendmail smartd
103
syslog telnet xinetd
Figura 4-3. Selección de los servicios
La instalación de Quagga se la realiza utilizando el RPM que se lo puede obtener de la página de Web http://www.quagga.net. Ya descargado el paquete se procede a instalarlo de la siguiente manera: # rpm –ivh quagga-0.99.4.fc5.i386.rpm
La estructura de directorios que resulta de esta instalación se la presenta en la Tabla 4-2 donde se muestran los directorios y una breve descripción de los mismos. Quagga maneja sus propios demonios para cada protocolo de enrutamiento; para poder inicializar los distintos demonios se necesita tener elaborados los archivos de configuración de cada uno de ellos que se leen por defecto del directorio /etc/quagga. El archivo de configuración del demonio Zebra es zebra.conf.
104
Directorio
Descripción
/etc/quagga/
Se encuentran los archivos de configuración.
/etc/rc.d/init.d/
Aquí se incluyen los scripts para el manejo de los demonios de Quagga.
/etc/sysconfig/ /usr/bin/
Se encuentra el archivo ejecutable del Terminal vtysh para la configuración de Quagga
/usr/lib/
Se encuentran las librerías que utilizan los diferentes demonios
/usr/sbin/
Se encuentran los ejecutables de los demonios
/usr/share/doc/quagga-0.98.6/
Se encuentran archivos de documentación de Quagga, así como archivos de ejemplo de configuración de los demonios
/usr/share/man
Se encuentran los archivos de manuales de los diferentes demonios
/var/log/quagga/
Se encuentran los archivos de logs de los demonios siempre y cuando esta opción esté configurada
/var/run/
Se encuentra los identificadores de procesos de cada uno de los demonios Tabla 4-2. Esquema de directorios de Quagga
En la instalación del paquete se crean archivos de configuración de ejemplo, los cuales pueden ser utilizados como base para poder continuar con la configuración; así el archivo de configuración de ejemplo tiene el siguiente formato: ! -*- zebra -*! ! zebra sample configuration file ! ! $Id: zebra.conf.sample,v 1.1.1.1 2002/12/13 20:15:30 paul Exp $ ! hostname Router password zebra enable password zebra ! ! Interface's description. ! !interface lo ! description test of desc. ! !interface sit0
105
! multicast ! ! Static default route sample. ! !ip route 0.0.0.0/0 203.181.89.241 ! !log file zebra.log
Las líneas precedidas por “!” son líneas comentadas, y las líneas que no tienen este signo son líneas válidas. Se puede observar que los archivos de configuración tienen una semejaza bastante grande con los archivos de configuración de los enrutadores Cisco. Para inicializar el demonio Zebra, el cual es necesario para la inicialización de los demás demonios de enrutamiento, se utiliza la siguiente sentencia: # service zebra start
Dependiendo del protocolo a utilizar, se va a inicializar el demonio necesario de la misma manera que Zebra; por ejemplo si se quiere utilizar RIP se inicializa de la siguiente manera # service ripd start
Para detener alguno de los demonios, se utiliza la siguiente sentencia con el demonio correspondiente: # service zebra stop
Para reiniciar algún demonio, se utiliza la siguiente sentencia con el demonio correspondiente: # service zebra restart
106
Es necesario tomar en cuenta que para que el enrutador funcione debe estar habilitada la opción de ip forward , tanto en el direccionamiento con IPv4 como en el direccionamiento con IPv6, ya que ésta es la opción del kernel con la que el tráfico IP puede ser reenviado de una interfaz a otra. Por defecto esta opción se encuentra deshabilitada y para habilitarla permanentemente hay que hacer un cambio en el archivo /etc/sysctl.conf. La opción net.ipv4.ip_forward debe estar establecida en un valor de
1
direccionamiento IPv4 y la opción
para que el enrutamiento sea posible con net.ipv6.conf.all.forwarding
debe
estar en un valor de 1 para que sea posible el enrutamiento IPv6. Esto se puede apreciar en la siguiente salida de pantalla del archivo /etc/sysctl.conf: # Kernel sysctl configuration file for Red Hat Linux # # For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and # sysctl.conf(5) for more details. # Controls IP packet forwarding net.ipv4.ip_forward = 1 # Controls source route verification net.ipv4.conf.default.rp_filter = 1 # Do not accept source routing net.ipv4.conf.default.accept_source_route = 0 # Controls the System Request debugging functionality of the kernel kernel.sysrq = 0 # Controls whether core dumps will append the PID to the core filename. # Useful for debugging multi-threaded applications. kernel.core_uses_pid = 1 # Controls the use of TCP syncookies net.ipv4.tcp_syncookies = 1 # IPv6 forwarding net.ipv6.conf.all.forwarding = 1
Por otro lado para que el demonio se inicialice cada vez que se reinicie el equipo es necesario ejecutar el siguiente comando: # chkconfig zebra on # chkconfig “demonio
a
on utilizarse”
107
Hay que tomar en cuenta que se deben inicializar siempre el demonio Zebra y el demonio del protocolo que se va a utilizar. 4.1.2. CONFIGURACIÓN
Al inicializar cada demonio se lee el archivo de configuración, este archivo se lo puede generar utilizando la consola de configuración a la cual se puede acceder utilizando Telnet 34 en el puerto de cada uno de los demonios. Hay que tomar en cuenta que para poder hacer esto debe existir una contraseña de acceso preconfigurada. Para acceder vía consola desde el mismo equipo y poder configurar el archivo de Zebra se tiene que hacer telnet al puerto 2601 y como dirección se utiliza la de loopback o el nombre del equipo, que en este caso en particular es localhost como se puede observar en la siguiente pantalla: # telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: Router>
Esta consola es similar a la que presentan los enrutadores Cisco, y en esencia tienen los mismos comandos básicos de configuración; así, se disponen de 3 modos de configuración:
34
Telnet es el nombre de un protocolo que sirve para acceder remotamente a una máquina en una red de datos, para manejarla como si se estuviera sentado delante de ella. Sólo sirve para acceder en modo terminal, sin gráficos, pero es una herramienta muy útil para arreglar problemas o fallas a distancia, sin necesidad de estar físicamente en el mismo sitio que la máquina.
108
Modo de ejecución de usuario Modo de privilegios Modo de configuración global
El modo de ejecución de usuario permite examinar un limitado conjunto de opciones que no permiten hacer cambios en el funcionamiento del programa; únicamente sirve para consultar determinada información. Para ver qué opciones permite utilizar se puede emplear el comando “ ?” lo cual despliega la siguiente pantalla: Router> echo enable exit help list quit show terminal who Router>
Echo a message back to the vty Turn on privileged mode command Exit current mode and down to previous mode Description of the interactive help system Print command list Exit current mode and down to previous mode Show running system information Set terminal line parameters Display who is on vty
En el modo de privilegios se tienen opciones más avanzadas que en el modo anterior; aquí se pueden hacer cambios en ciertas partes de la configuración, así como también se encuentran los comandos para guardar los archivos de configuración después de haber elaborado los cambios. Para pasar del modo de ejecución de usuario al modo de privilegios se utiliza el comando enable y luego se procede a digitar la contraseña de acceso a este modo. Las opciones que se encuentran en este modo se las puede observar después de haber utilizado el comando “ ?”: Router> enable Password: Router# configure Configuratio n from vty interface copy Copy configuration debug Debugging functions (see also 'undebug') disable Turn off privileged mode command echo Echo a message back to the vty end End current mode and change to enable mode. exit Exit current mode and down to previous mode help Description of the interactive help system list Print command list
109
logmsg no quit show terminal who write Router#
Send a message to enabled logging destinations Negate a command or set its defaults Exit current mode and down to previous mode Show running system information Set terminal line parameters Display who is on vty Write running configurati on to memory, network, or terminal
Por último en el modo de configuración global se encuentran las opciones para configurar interfaces, enrutamiento estático, contraseñas, logs entre otras cosas. Para cambiar del modo de privilegios al modo de configuración global se utiliza el comando configure terminal. El menú de opciones se presenta en la siguiente salida de pantalla después de haber utilizado el comando “ ?”. Router# configure terminal Router(config)# access-list Add an access list entry banner Set banner string debug Debugging functions (see also 'undebug') enable Modify enable password parameters end End current mode and change to enable mode. exit Exit current mode and down to previous mode help Description of the interactive help system hostname Set system's network name interface Select an interface to configure ip IP information ipv6 IPv6 information line Configure a terminal line list Print command list log Logging control no Negate a command or set its defaults password Assign the terminal connection password quit Exit current mode and down to previous mode router-id Manually set the router-id service Set up miscellane ous service show Show running system information table Configure target kernel routing table write Write running configuration to memory, network or terminal Router(config)#
Se puede acceder a la configuración de cada uno de los demonios de la misma manera como se presentó anteriormente, tomando en cuenta que el puerto de acceso a cada uno de ellos varía. Es importante estar claros qué tipo de enrutamiento se va a establecer, ya sea estático o dinámico; y en el caso del enrutamiento dinámico se tiene que establecer el tipo de protocolo a utilizarse.
110
4.1.2.1. Configuración básica de los diferentes demonios
Como en un enrutador Cisco se pueden configurar ciertos parámetros que son importantes, como son las contraseñas de acceso o los nombres de los equipos, estas configuraciones se las debe hacer en cada uno de los demonios, ya que como se mencionó anteriormente éstos funcionan por separado y su acceso se lo realiza de igual manera por separado. Como ejemplo de esta configuración se va elegir el demonio Zebra y se va a proceder a configurar el nombre del equipo, la contraseña de acceso al modo de ejecución de usuario y la contraseña de acceso al modo de privilegios, así como también se va a configurar el demonio para que estas contraseñas estén encriptadas. En un inicio se va a modificar el archivo zebra.conf que por defecto se encuentra en el directorio /etc/quagga/ de la siguiente manera:
! -*- zebra -*! ! zebra sample configuration file ! ! $Id: zebra.conf.sample,v 1.1.1.1 2002/12/13 20:15:30 paul Exp $ ! hostname ENRUTADOR
--→ aquí se incluye el nombre del enrutador
password master20
--→ aquí se incluye la contraseña de acceso al modo de ejecución
enable password master20 --→ aquí se incluye la contraseña de acceso al modo de privilegios ! ! Interface's description. ! !interface lo ! description test of desc. ! !interface sit0 ! multicast ! ! Static default route sample. ! !ip route 0.0.0.0/0 203.181.89.241 ! !log file zebra.log
111
Luego de haber modificado este archivo se puede acceder al enrutador utilizando las contraseñas establecidas. Para encriptar las contraseñas y que éstas no se almacenen en claro en el archivo de configuración, se procede a ingresar al modo de configuración global y se utiliza el comando que se detalla a continuación: ENRUTADOR(config)# service password-encryption
Para archivar los cambios realizados a través de la consola se utiliza el siguiente comando que puede ser aplicado desde cualquier modo de la consola excepto del modo de ejecución: ENRUTADOR(config)# write
O se puede también utilizar el comando que se muestra a continuación que sólo puede ser utilizado desde el modo de privilegios: ENRUTADOR# copy running-config startup-config
4.1.2.2. Configuración de enrutamiento estático IPv4 utilizando el demonio Zebra
Se puede utilizar el demonio Zebra para la configuración de rutas estáticas; para esto se va a plantear un escenario sencillo en el cual se podrá visualizar de mejor manera la configuración; el escenario propuesto se muestra en la Figura 4-4. Se pretende establecer comunicación entre el Usuario 1 y el Usuario 2 que se encuentran en redes distintas, para eso se utilizarán dos enrutadores con el demonio Zebra activado. A través del demonio Zebra se pueden configurar rutas estáticas, después de haber configurado cada una de las interfaces con sus respectivas direcciones IP y máscaras de subred. A continuación se describe cómo se configura el enrutador para manejo de rutas estáticas:
112
Figura 4-4. Escenario para enrutamiento IPv4 estático
Enrutador A Ingresar en el modo de configuración global
ROUTER_A> ROUTER_A> enable Password: ROUTER_A# configure terminal
Configurar las interfaces
ROUTER_A(config)# interface eth0 ROUTER_A(config-if)# ip address 192.168.102.1/24 ROUTER_A(config-if)# no shutdown ROUTER_A(config-if)# exit ROUTER_A(config)# interface eth1 ROUTER_A(config-if)# ip address 192.168.101.1/24 ROUTER_A(config-if)# no shutdown ROUTER_A(config-if)# exit
Configurar la ruta estática tomando en cuenta la red de destino con su respectiva máscara de subred y la interfaz de salida o la dirección IP de salida.
ROUTER_A(config)# ip route 192.168.103.0/24 192.168.102.2 ROUTER_A(config)# exit
Verificar que las rutas estén correctamente configuradas
ROUTER_A# show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route C>* 127.0.0.0/8 is directly connected, lo K>* 169.254.0.0/16 is directly connected, lo
113
C>* 192.168.101.0/24 is directly connected, eth1 C>* 192.168.102.0/24 is directly connected, eth0 S>* 192.168.103.0/24 [1/0] via 192.168.102.1, eth0 ROUTER_A#
Enrutador B Ingresar en el modo de configuración global
ROUTER_B> ROUTER_B> enable Password: ROUTER_B# configure terminal
Configurar las interfaces
ROUTER_B(config)# interface eth0 ROUTER_B(config-if)# ip address 192.168.102.2/24 ROUTER_B(config-if)# no shutdown ROUTER_B(config-if)# exit ROUTER_B(config)# interface eth1 ROUTER_B(config-if)# ip address 192.168.103.1/24 ROUTER_B(config-if)# no shutdown ROUTER_B(config-if)# exit ROUTER_B(config)#
Configurar la ruta estática tomando en cuenta la red de destino con su respectiva máscara de subred y la interfaz de salida o la dirección IP de salida.
ROUTER_B(config)# ip route 192.168.101.0/24 192.168.102.1 ROUTER_B(config)# exit ROUTER_B#
Verificar que las rutas estén correctamente configuradas
ROUTER_B# show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route C>* K>* C>* C>* S>*
127.0.0.0/8 is directly connected, lo 169.254.0.0/16 is directly connected, lo 192.168.103.0/24 is directly connected, eth1 192.168.102.0/24 is directly connected, eth0 192.168.101.0/24 [1/0] via 192.168.102.2, eth0
ROUTER_B#
114
Usuario 1 El Usuario 1 debe estar configurado con los siguientes parámetros: Dirección IP
192.168.101.2
Máscara de Subred
255.255.255.0
Puerta de enlace
192.168.101.1
Usuario 2 El Usuario 2 debe estar configurado con los siguientes parámetros: Dirección IP
192.168.103.2
Máscara de Subred
255.255.255.0
Puerta de enlace
192.168.103.1
4.1.2.3. Configuración de enrutamiento estático IPv6 utilizando el demonio Zebra
Al igual que con el direccionamiento IPv4 se puede utilizar el demonio Zebra para realizar enrutamiento estático con direccionamiento IPv6. Para poder ver de manera más sencilla la configuración se plantea un escenario de enrutamiento; este escenario se lo puede ver en la Figura 4-5.
Figura 4-5. Escenario para enrutamiento IPv6 estático
115
Hay que establecer la comunicación entre el usuario 1 y 2 que se encuentran en redes diferentes, los cuales disponen de direccionamiento IPv6. Los enrutadores A y B son los encargados de establecer la comunicación utilizando el demonio Zebra de la siguiente manera: Enrutador A Ingresar en el modo de configuración global
ROUTER_IPv6_A> ROUTER_IPv6_A> enable Password: ROUTER_IPv6_A# configure terminal
Configurar las interfaces
ROUTER_IPv6_A(config)# interface eth0 ROUTER_IPv6_A(config-if)# ipv6 address 2000:2::1/32 ROUTER_IPv6_A(config-if)# no shutdown ROUTER_IPv6_A(config-if)# exit ROUTER_IPv6_A(config)# interface eth1 ROUTER_IPv6_A(config-if)# ipv6 address 2000:1::1/32 ROUTER_IPv6_A(config-if)# no shutdown ROUTER_IPv6_A(config-if)# exit
Configurar la ruta estática tomando en cuenta la red de destino y la interfaz de salida o la dirección IP de salida.
ROUTER_IPv6_A(config)# ipv6 route 2000:3::/32 2000:2::2 ROUTER_IPv6_A(config)# exit
Verificar que las rutas estén correctamente configuradas
ROUTER_IPv6_A# show ipv6 route Codes:K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - ISIS, B - BGP, * - FIB route. C>* ::1/128 is directly connected, lo K * 2000:1::/32 is directly connected, eth1 C>* 2000:1::/32 is directly connected, eth1 K * 2000:2::/32 is directly connected, eth0 C>* 2000:2::/32 is directly connected, eth0 S>* 2000:3::/32 [1/0] via 2000:2::2, eth0 K * fe80::/64 is directly connected, eth1 C * fe80::/64 is directly connected, eth1 C>* fe80::/64 is directly connected, eth0 K>* ff00::/8 is directly connected, eth1 ROUTER_IPv6_A#
116
Enrutador B Ingresar en el modo de configuración global
ROUTER_IPv6_B> ROUTER_IPv6_B> enable Password: ROUTER_IPv6_B# configure terminal
Configurar las interfaces
ROUTER_IPv6_B(config)# interface eth0 ROUTER_IPv6_B(config-if)# ipv6 address 2000:2::2/32 ROUTER_IPv6_B(config-if)# no shutdown ROUTER_IPv6_B(config-if)# exit ROUTER_IPv6_B(config)# interface eth1 ROUTER_IPv6_B(config-if)# ipv6 address 2000:3::1/32 ROUTER_IPv6_B(config-if)# no shutdown ROUTER_IPv6_B(config-if)# exit
Configurar la ruta estática tomando en cuenta la red de destino y la interfaz de salida o la dirección IP de salida.
ROUTER_IPv6_B(config)# ipv6 route 2000:1::/32 2000:2::1 ROUTER_IPv6_B(config)# exit
Verificar que las rutas estén correctamente configuradas
ROUTER_IPv6_B# show ipv6 route Codes: K - kernel route, C - connected, S - static, R - RIPng, O OSPFv3, I - ISIS, B - BGP, * - FIB route. C>* ::1/128 is directly connected, lo S>* 2000:1::/32 [1/0] via 2000:2::1, eth0 K * 2000:2::/32 is directly connected, eth0 C>* 2000:2::/32 is directly connected, eth0 K * 2000:3::/32 is directly connected, eth1 C>* 2000:3::/32 is directly connected, eth1 K * fe80::/64 is directly connected, eth1 C * fe80::/64 is directly connected, eth1 C>* fe80::/64 is directly connected, eth0 K>* ff00::/8 is directly connected, eth1 ROUTER_IPv6_B#
Usuario 1 El Usuario 1 debe estar configurado con los siguientes parámetros: Dirección IPv6
2000:1::2/32
Puerta de enlace
2000:1::1
117
Usuario 2 El Usuario 2 debe estar configurado con los siguientes parámetros: Dirección IPv6
2000:3::2/32
Puerta de enlace
2000:3::1
4.1.2.4. Configuración de enrutamiento dinámico IPv4 utilizando el demonio ripd
El demonio ripd es el demonio encargado de administrar el enrutamiento dinámico utilizando el protocolo RIP. Para que pueda funcionar el demonio ripd es necesario que el protocolo Zebra esté inicializado previamente ya que éste es el demonio que administra a los demás demonios de enrutamiento; además es necesario configurar ciertos aspectos en el demonio Zebra como las interfaces para poder luego hacer funcionar el enrutamiento dinámico. El demonio ripd fuciona en el puerto 2602 y de igual manera que Zebra se puede configurar a través de Telnet en el puerto correspondiente. El archivo de configuración es leído por defecto del directorio /etc/quagga/ y su nombre es ripd.conf. Para poder explicar de una manera más sencilla se va a plantear un escenario donde se analizará la configuración del demonio ripd; el escenario se lo puede observar en la Figura 4-6:
Figura 4-6. Escenario para enrutamiento dinámico IPv4 con RIP
118
Lo que se pretende con este escenario es establecer la comunicación entre el Usuario 1 y el Usuario 2 utilizando RIP en los enrutadores A y B; para esto es necesario en primera instancia configurar el demonio Zebra que va a incluir la información de la interfaces, sus direcciones IP y sus máscaras de subred; esto se lo consigue de la siguiente manera: Enrutador A Ingresar al modo de configuración de consola
# telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_A>
Ingresar en el modo de configuración global
ROUTER_A> ROUTER_A> enable Password: ROUTER_A# configure terminal
Configurar las interfaces
ROUTER_A(config)# interface eth0 ROUTER_A(config-if)# ip address 192.168.20.1/24 ROUTER_A(config-if)# no shutdown ROUTER_A(config-if)# exit ROUTER_A(config)# interface eth1 ROUTER_A(config-if)# ip address 192.168.10.1/24 ROUTER_A(config-if)# no shutdown ROUTER_A(config-if)# exit
Enrutador B Ingresar al modo de configuración de consola
# telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
119
User Access Verification Password: ROUTER_B>
Ingresar en el modo de configuración global
ROUTER_B> ROUTER_B> enable Password: ROUTER_B# configure terminal
Configurar las interfaces
ROUTER_B(config)# interface eth0 ROUTER_B(config-if)# ip address 192.168.20.2/24 ROUTER_B(config-if)# no shutdown ROUTER_B(config-if)# exit ROUTER_B(config)# interface eth1 ROUTER_B(config-if)# ip address 192.168.11.1/24 ROUTER_B(config-if)# no shutdown ROUTER_B(config-if)# exit
Luego de tener las interfaces configuradas es necesario configurar RIP a través del demonio ripd; esta configuración se la puede realizar a través de la consola de configuración de ripd, como se observa a continuación: Enrutador A Ingresar al modo de configuración de consola
# telnet localhost 2602 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_RIP_A>
Ingresar en el modo de configuración global
ROUTER_RIP_A > ROUTER_RIP_A > enable Password: ROUTER_RIP_A # configure terminal
120
Configurar las redes para RIP
ROUTER_RIP_A(config)# router rip ROUTER_RIP_A(config-router)#network 192.168.20.0/24 ROUTER_RIP_A(config-router)#network 192.168.10.0/24 ROUTER_RIP_A(config-router)#exit ROUTER_RIP_A(config)#exit
Enrutador B Ingresar al modo de configuración de consola
# telnet localhost 2602 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_RIP_B>
Ingresar en el modo de configuración global
ROUTER_RIP_B > ROUTER_RIP_B > enable Password: ROUTER_RIP_B # configure terminal
Configurar las redes para RIP
ROUTER_RIP_B(config)# router rip ROUTER_RIP_B(config-router)#network 192.168.20.0/24 ROUTER_RIP_B(config-router)#network 192.168.11.0/24 ROUTER_RIP_B(config-router)#exit ROUTER_RIP_B(config)#exit
A continuación se procede a verificar que las rutas consten en las tablas de enrutamiento: Enrutador A # telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'.
121
Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_A> ROUTER_A> enable Password: ROUTER_A# configure terminal ROUTER_A# show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route C>* 127.0.0.0/8 is directly connected, lo K>* 169.254.0.0/16 is directly connected, lo C>* 192.168.10.0/24 is directly connected, eth1 R>* 192.168.11.0/24 [120/2] via 192.168.20.2, eth0, 01:11:09 C>* 192.168.20.0/24 is directly connected, eth0 ROUTER_A#
Enrutador B # telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_B> ROUTER_B> enable Password: ROUTER_B# configure terminal ROUTER_B# show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route C>* 127.0.0.0/8 is directly connected, lo K>* 169.254.0.0/16 is directly connected, lo C>* 192.168.10.0/24 is directly connected, eth1 R>* 192.168.10.0/24 [120/2] via 192.168.20.1, eth0, 01:18:05 C>* 192.168.20.0/24 is directly connected, eth0 ROUTER_A#
Por otro lado los usuarios deben tener la siguiente configuración:
122
Usuario 1 El Usuario 1 debe estar configurado con los siguientes parámetros: Dirección IP
192.168.10.2
Máscara de Subred
255.255.255.0
Puerta de enlace
192.168.10.1
Usuario 2 El Usuario 2 debe estar configurado con los siguientes parámetros: Dirección IP
192.168.11.2
Máscara de Subred
255.255.255.0
Puerta de enlace
192.168.11.1
4.1.2.5. Configuración de enrutamiento dinámico IPv6 utilizando el demonio ripngd
El demonio ripngd es el encargado de administrar el enrutamiento RIPng; para poder acceder a la configuración de este demonio se necesita hacer Telnet al puerto 2603. Hay que tomar en cuenta que la dirección de loopback en IPv6 es ::1/128. Antes de configurar el demonio ripng es necesario que las interfaces estén configuradas a través del demonio Zebra. Para poder analizar la configuración de este demonio se presenta un escenario en donde se necesitará utilizar este protocolo de enrutamiento; el escenario se muestra en la Figura 4-7:
Figura 4-7. Escenario para enrutamiento dinámico IPv6 con RIPng
123
Se requiere comunicar los usuarios 1 y 2 utilizando RIPng en los enrutadores A, B y C; para conseguir este propósito es necesario en primer lugar configurar el demonio Zebra que va a incluir la información de las interfaces y esto se lo consigue de la siguiente manera: Enrutador A Ingresar al modo de configuración de consola
# telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_A>
Ingresar en el modo de configuración global
ROUTER_IPv6_A> ROUTER_IPv6_A> enable Password: ROUTER_IPv6_A# configure terminal
Configurar las interfaces
ROUTER_IPv6_A(config)# interface eth0 ROUTER_IPv6_A(config-if)# ipv6 address 2000:2::1/32 ROUTER_IPv6_A(config-if)# no shutdown ROUTER_IPv6_A(config-if)# exit ROUTER_IPv6_A(config)# interface eth1 ROUTER_IPv6_A(config-if)# ipv6 address 2000:1::1/32 ROUTER_IPv6_A(config-if)# no shutdown ROUTER_IPv6_A(config-if)# exit
Enrutador B Ingresar al modo de configuración de consola
# telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
124
User Access Verification Password: ROUTER_IPv6_B>
Ingresar en el modo de configuración global
ROUTER_IPv6_B> ROUTER_IPv6_B> enable Password: ROUTER_IPv6_B# configure terminal
Configurar las interfaces
ROUTER_IPv6_B(config)# interface eth0 ROUTER_IPv6_B(config-if)# ipv6 address 2000:2::2/32 ROUTER_IPv6_B(config-if)# no shutdown ROUTER_IPv6_B(config-if)# exit ROUTER_IPv6_B(config)# interface eth1 ROUTER_IPv6_B(config-if)# ipv6 address 2000:3::1/32 ROUTER_IPv6_B(config-if)# no shutdown ROUTER_IPv6_B(config-if)# exit
Enrutador C Ingresar al modo de configuración de consola
# telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_C>
Ingresar en el modo de configuración global
ROUTER_IPv6_C> ROUTER_IPv6_C> enable Password: ROUTER_IPv6_C# configure terminal
Configurar las interfaces
ROUTER_IPv6_C(config)# interface eth0 ROUTER_IPv6_C(config-if)# ipv6 address 2000:3::2/32 ROUTER_IPv6_C(config-if)# no shutdown
125
ROUTER_IPv6_C(config-if)# exit ROUTER_IPv6_C(config)# interface eth1 ROUTER_IPv6_C(config-if)# ipv6 address 2000:A::1/32 ROUTER_IPv6_C(config-if)# no shutdown ROUTER_IPv6_C(config-if)# exit
Ahora se configura el protocolo RIPng que es administrado por el demonio ripngd; esta configuración se la puede realizar a través de la consola de configuración de ripngd, como se observa a continuación: Enrutador A Ingresar al modo de configuración de consola
# telnet ::1 2603 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_RIPNG_A>
Ingresar en el modo de configuración global
ROUTER_IPv6_RIPNG_A> ROUTER_IPv6_RIPNG_A> enable Password: ROUTER_IPv6_RIPNG_A# configure terminal
Configurar las redes para RIP
ROUTER_IPv6_RIPNG_A(config)# router ripng ROUTER_IPv6_RIPNG_A(config-router)#network 2000:1::/32 ROUTER_IPv6_RIPNG_A(config-router)#network 2000:2::/32 ROUTER_IPv6_RIPNG_A(config-router)#exit ROUTER_IPv6_RIPNG_A(config)#exit
Enrutador B Ingresar al modo de configuración de consola
# telnet ::1 2603 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'.
126
Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al. User Access Verification Password: ROUTER_IPv6_RIPNG_B>
Ingresar en el modo de configuración global
ROUTER_IPv6_RIPNG_B> ROUTER_IPv6_RIPNG_B> enable Password: ROUTER_IPv6_RIPNG_B# configure terminal
Configurar las redes para RIP
ROUTER_IPv6_RIPNG_B(config)# router ripng ROUTER_IPv6_RIPNG_B(config-router)#network 2000:2::/32 ROUTER_IPv6_RIPNG_B(config-router)#network 2000:3::/32 ROUTER_IPv6_RIPNG_B(config-router)#exit ROUTER_IPv6_RIPNG_B(config)#exit
Enrutador C Ingresar al modo de configuración de consola
# telnet ::1 2603 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al. User Access Verification Password: ROUTER_IPv6_RIPNG_C>
Ingresar en el modo de configuración global
ROUTER_IPv6_RIPNG_C> ROUTER_IPv6_RIPNG_C> enable Password: ROUTER_IPv6_RIPNG_C# configure terminal
Configurar las redes para RIP
ROUTER_IPv6_RIPNG_C(config)# router ripng ROUTER_IPv6_RIPNG_C(config-router)#network 2000:3::/32 ROUTER_IPv6_RIPNG_C(config-router)#network 2000:A::/32 ROUTER_IPv6_RIPNG_C(config-router)#exit ROUTER_IPv6_RIPNG_C(config)#exit
127
A continuación se procede a hacer la verificación de que las rutas consten en las tablas de enrutamiento: Enrutador A # telnet localhost zebra Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_A> enable Password: ROUTER_IPv6_A# ROUTER_IPv6_A# show ipv6 route Codes:K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - ISIS, B - BGP, * - FIB route. C>* ::1/128 is directly connected, lo C>* 2000:1::/32 is directly connected, eth1 K * 2000:1::/32 is directly connected, eth1 C>* 2000:2::/32 is directly connected, eth0 K * 2000:2::/32 is directly connected, eth0 R>* 2000:3::/32 [120/2] via fe80::20c:29ff:fe3a:550f, eth0, 00:53:13 R>* 2000:a::/32 [120/3] via fe80::20c:29ff:fe3a:550f, eth0, 00:51:44 C>* fe80::/64 is directly connected, eth1 K * fe80::/64 is directly connected, eth1 K>* ff00::/8 is directly connected, eth1 ROUTER_IPv6_A#
Enrutador B # telnet localhost zebra Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_B> enable Password: ROUTER_IPv6_B# ROUTER_IPv6_B# show ipv6 route ROUTER_IPv6_B# show ipv6 route Codes:K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - ISIS, B - BGP, * - FIB route.
128
C>* ::1/128 is directly connected, lo R>* 2000:1::/32 [120/2] via fe80::20c:29ff:fed0:2896, eth0, 00:56:22 C>* 2000:2::/32 is directly connected, eth0 K * 2000:2::/32 is directly connected, eth0 C>* 2000:3::/32 is directly connected, eth1 K * 2000:3::/32 is directly connected, eth1 R>* 2000:a::/32 [120/2] via fe80::20c:29ff:fe13:500b, eth1, 00:54:50 C>* fe80::/64 is directly connected, eth1 K * fe80::/64 is directly connected, eth1 K>* ff00::/8 is directly connected, eth1 ROUTER_IPv6_B#
Enrutador C # telnet localhost zebra Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_C> enable Password: ROUTER_IPv6_C# ROUTER_IPv6_C# show ipv6 route Codes:K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - ISIS, B - BGP, * - FIB route. C>* ::1/128 is directly connected, lo R>* 2000:1::/32 [120/3] via fe80::20c:29ff:fe3a:5519, eth0, 00:56:25 R>* 2000:2::/32 [120/2] via fe80::20c:29ff:fe3a:5519, eth0, 00:56:25 C>* 2000:3::/32 is directly connected, eth0 K * 2000:3::/32 is directly connected, eth0 C>* 2000:a::/32 is directly connected, eth1 K * 2000:a::/32 is directly connected, eth1 C * fe80::/64 is directly connected, eth1 C>* fe80::/64 is directly connected, eth0 K * fe80::/64 is directly connected, eth1 K>* ff00::/8 is directly connected, eth1 ROUTER_IPv6_C#
Por otro lado los usuarios deben tener la siguiente configuración:
129
Usuario 1 El Usuario 1 debe estar configurado con los siguientes parámetros: Dirección IPv6
2000:1::2/32
Puerta de enlace
2000:1::1
Usuario 2 El Usuario 2 debe estar configurado con los siguientes parámetros: Dirección IPv6
2000:A::2/32
Puerta de enlace
2000:A::1
4.1.2.6. Configuración de enrutamiento dinámico IPv4 utilizando el demonio ospfd Enrutador A Usuario 2 Eth0:192.168.15.1/30 Eth1: 172.16.40.1/24 172.16.41.12/24
RED A RED B 172.16.40.2/24 Eth1: 172.16.41.11/24 Eth0: 192.168.15.2/30
Usuario 1 Enrutador B
Figura 4-8. Escenario para enrutamiento dinámico IPv4 con OSPF
El demonio ospfd es el encargado de permitir que se efectúe el enrutamiento utilizando el protocolo OSPF. La configuración de este demonio se la realiza de la misma manera que se hace con ripd y con Zebra; se utiliza el modo de configuración de consola utilizando Telnet al puerto 2604. Para poder utilizar el demonio ospfd es necesario que esté activado el demonio Zebra y que se encuentren configuradas las interfaces. Para presentar la manera de configurar enrutamiento con OSPF se presenta un escenario sencillo en el cual se puede analizar varios aspectos. El escenario presentado se lo puede analizar en la Figura 4-8.
130
Se quiere establecer comunicación entre el Usuario 1 y 2 utilizando como protocolo de enrutamiento OSPF; para esto se debe configurar tanto el enrutador A y el B con dicho protocolo a través del demonio ospfd. Primero se deben configurar las interfaces utilizando el modo de configuración de consola del demonio Zebra de la siguiente manera: Enrutador A Ingresar al modo de configuración de consola
# telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_A>
Ingresar en el modo de configuración global
ROUTER_A> ROUTER_A> enable Password: ROUTER_A# configure terminal
Configurar las interfaces
ROUTER_A(config)# interface eth0 ROUTER_A(config-if)# ip address 192.168.15.1/30 ROUTER_A(config-if)# no shutdown ROUTER_A(config-if)# exit ROUTER_A(config)# interface eth1 ROUTER_A(config-if)# ip address 172.16.40.1/24 ROUTER_A(config-if)# no shutdown ROUTER_A(config-if)# exit
Enrutador B Ingresar al modo de configuración de consola
# telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
131
User Access Verification Password: ROUTER_B>
Ingresar en el modo de configuración global
ROUTER_B> ROUTER_B> enable Password: ROUTER_B# configure terminal
Configurar las interfaces
ROUTER_B(config)# interface eth0 ROUTER_B(config-if)# ip address 192.168.15.2/30 ROUTER_B(config-if)# no shutdown ROUTER_B(config-if)# exit ROUTER_B(config)# interface eth1 ROUTER_B(config-if)# ip address 172.16.41.11/24 ROUTER_B(config-if)# no shutdown ROUTER_B(config-if)# exit
El siguiente paso es configurar el demonio ospfd con las respectivas redes en las interfaces de la siguiente manera: Enrutador A Ingresar al modo de configuración de consola
# telnet localhost 2604 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_OSPF_A>
Ingresar en el modo de configuración global
ROUTER_OSPF_A> ROUTER_OSPF_A> enable Password: ROUTER_OSPF_A#
132
Configurar la información para OSPF
ROUTER_OSPF_A(config)# ROUTER_OSPF_A(config)# router ROUTER_OSPF_A(config-router)# ROUTER_OSPF_A(config-router)# ROUTER_OSPF_A(config-router)# ROUTER_OSPF_A(config-router)#
ospf network 172.16.40.0/24 area 0 network 192.168.15.0/30 area 0 exit
Enrutador B Ingresar al modo de configuración de consola
# telnet localhost 2604 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_OSPF_B>
Ingresar en el modo de configuración global
ROUTER_OSPF_B> ROUTER_OSPF_B> enable Password: ROUTER_OSPF_B#
Configurar la información para OSPF
ROUTER_OSPF_B(config)# ROUTER_OSPF_B(config)# router ROUTER_OSPF_B(config-router)# ROUTER_OSPF_B(config-router)# ROUTER_OSPF_B(config-router)# ROUTER_OSPF_B(config-router)#
ospf network 172.16.41.0/24 area 0 network 192.168.15.0/30 area 0 exit
Para ver si las rutas se encuentran en las tablas de enrutamiento de cada uno de los enrutadores se hace la siguiente verificación: Enrutador A # telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4).
133
Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_A> enable Password: ROUTER_A# show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route C>* 127.0.0.0/8 is directly connected, lo K>* 169.254.0.0/16 is directly connected, lo O 172.16.40.0/24 [110/10] is directly connected, eth1, 02:02:19 C>* 172.16.40.0/24 is directly connected, eth1 O>* 172.16.41.0/24 [110/20] via 192.168.15.2, eth0, 02:00:16 O 192.168.15.0/30 [110/10] is directly connected, eth0, 02:01:44 C>* 192.168.15.0/30 is directly connected, eth0 ROUTER_A#
Enrutador B # telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_B> enable Password: ROUTER_B# show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route C>* 127.0.0.0/8 is directly connected, lo K>* 169.254.0.0/16 is directly connected, lo O>* 172.16.40.0/24 [110/20] via 192.168.15.1, eth0, 02:05:29 O 172.16.41.0/24 [110/10] is directly connected, eth1, 02:05:22 C>* 172.16.40.0/24 is directly connected, eth1 O 192.168.15.0/30 [110/10] is directly connected, eth0, 02:05:35 C>* 192.168.15.0/30 is directly connected, eth0 ROUTER_A#
Finalmente los usuarios deben tener configurado el siguiente direccionamiento:
134
Usuario 1 Dirección IP
172.16.40.2
Máscara de Subred
255.255.255.0
Puerta de enlace
172.16.40.1
Dirección IP
172.16.41.12
Máscara de Subred
255.255.255.0
Puerta de enlace
172.16.41.11
Usuario 2
4.1.2.7. Configuración de enrutamiento dinámico IPv6 utilizando el demonio ospf6d
Figura 4-9. Escenario para enrutamiento dinámico IPv6 con OSPFv3
El demonio ospf6d es el encargado de que se efectúe el enrutamiento utilizando el protocolo OSPFv3 para direccionamiento IPv6. La configuración de este demonio se la realiza de la misma manera que se hace con los demás demonios, empleando el modo de configuración de consola utilizando Telnet al puerto 2606. Para poder utilizar el demonio ospf6d es necesario que esté activado el demonio Zebra y que se encuentren configuradas las interfaces. En la Figura 4-9 se presenta un escenario que va a permitir describir de mejor manera la configuración de dicho demonio.
135
Como en los demonios anteriores se procede a configurar en primera instancia el demonio Zebra que contiene la información de direccionamiento de las interfaces para eso se hace lo siguiente: Enrutador A Ingresar al modo de configuración de consola
# telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_A>
Ingresar en el modo de configuración global
ROUTER_IPv6_A> ROUTER_IPv6_A> enable Password: ROUTER_IPv6_A# configure terminal
Configurar las interfaces
ROUTER_IPv6_A(config)# interface eth0 ROUTER_IPv6_A(config-if)# ipv6 address 2000:2::1/32 ROUTER_IPv6_A(config-if)# no shutdown ROUTER_IPv6_A(config-if)# exit ROUTER_IPv6_A(config)# interface eth1 ROUTER_IPv6_A(config-if)# ipv6 address 2000:1::1/32 ROUTER_IPv6_A(config-if)# no shutdown ROUTER_IPv6_A(config-if)# exit
Enrutador B Ingresar al modo de configuración de consola
# telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification
136
Password: ROUTER_IPv6_B>
Ingresar en el modo de configuración global
ROUTER_IPv6_B> ROUTER_IPv6_B> enable Password: ROUTER_IPv6_B# configure terminal
Configurar las interfaces
ROUTER_IPv6_B(config)# interface eth0 ROUTER_IPv6_B(config-if)# ipv6 address 2000:2::2/32 ROUTER_IPv6_B(config-if)# no shutdown ROUTER_IPv6_B(config-if)# exit ROUTER_IPv6_B(config)# interface eth1 ROUTER_IPv6_B(config-if)# ipv6 address 2000:3::1/32 ROUTER_IPv6_B(config-if)# no shutdown ROUTER_IPv6_B(config-if)# exit
Enrutador C Ingresar al modo de configuración de consola
# telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_C>
Ingresar en el modo de configuración global
ROUTER_IPv6_C> ROUTER_IPv6_C> enable Password: ROUTER_IPv6_C# configure terminal
Configurar las interfaces
ROUTER_IPv6_C(config)# interface eth0 ROUTER_IPv6_C(config-if)# ipv6 address 2000:3::2/32 ROUTER_IPv6_C(config-if)# no shutdown ROUTER_IPv6_C(config-if)# exit ROUTER_IPv6_C(config)# interface eth1 ROUTER_IPv6_C(config-if)# ipv6 address 2000:A::1/32
137
ROUTER_IPv6_C(config-if)# no shutdown ROUTER_IPv6_C(config-if)# exit
Luego de tener configurado el demonio Zebra, se procede a configurar el demonio ospf6d con la información necesaria para que se produzca el enrutamiento; esta configuración se la hace de la siguiente manera: Enrutador A Ingresar al modo de configuración de consola
# telnet ::1 2606 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_OSPF6_A>
Ingresar en el modo de configuración global
ROUTER_IPv6_OSPF6_A> ROUTER_IPv6_OSPF6_A> enable Password: ROUTER_IPv6_OSPF6_A#
Configurar la información para OSPFv3
ROUTER_IPv6_OSPF6_A(config)# ROUTER_IPv6_OSPF6_A(config)# router ospf6 ROUTER_IPv6_OSPF6_A(config-ospf6)# ROUTER_IPv6_OSPF6_A(config-ospf6)# router-id 0.0.0.1 ROUTER_IPv6_OSPF6_A(config-ospf6)# interface eth0 area 0.0.0.0 ROUTER_IPv6_OSPF6_A(config-ospf6)# interface eth1 area 0.0.0.0 ROUTER_IPv6_OSPF6_A(config-ospf6)# exit
Enrutador B Ingresar al modo de configuración de consola
# telnet ::1 2606 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
138
User Access Verification Password: ROUTER_IPv6_OSPF6_B>
Ingresar en el modo de configuración global
ROUTER_IPv6_OSPF6_B> ROUTER_IPv6_OSPF6_B> enable Password: ROUTER_IPv6_OSPF6_B#
Configurar la información para OSPFv3
ROUTER_IPv6_OSPF6_B(config)# ROUTER_IPv6_OSPF6_B(config)# router ospf6 ROUTER_IPv6_OSPF6_B(config-ospf6)# ROUTER_IPv6_OSPF6_B(config-ospf6)# router-id 0.0.0.2 ROUTER_IPv6_OSPF6_B(config-ospf6)# interface eth0 area 0.0.0.0 ROUTER_IPv6_OSPF6_B(config-ospf6)# interface eth1 area 0.0.0.0 ROUTER_IPv6_OSPF6_B(config-ospf6)# exit
Enrutador C Ingresar al modo de configuración de consola
# telnet ::1 2606 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_OSPF6_C>
Ingresar en el modo de configuración global
ROUTER_IPv6_OSPF6_C> ROUTER_IPv6_OSPF6_C> enable Password: ROUTER_IPv6_OSPF6_C#
Configurar la información para OSPFv3
ROUTER_IPv6_OSPF6_C(config)# ROUTER_IPv6_OSPF6_C(config)# router ospf6 ROUTER_IPv6_OSPF6_C(config-ospf6)#
139
ROUTER_IPv6_OSPF6_C(config-ospf6)# ROUTER_IPv6_OSPF6_C(config-ospf6)# ROUTER_IPv6_OSPF6_C(config-ospf6)# ROUTER_IPv6_OSPF6_C(config-ospf6)#
router-id 0.0.0.3 interface eth0 area 0.0.0.0 interface eth1 area 0.0.0.0 exit
A continuación se procede a verificar las tablas de enrutamiento de cada uno de los enrutadores: Enrutador A # telnet localhost zebra Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_A> enable Password: ROUTER_IPv6_A# ROUTER_IPv6_A# show ipv6 route Codes: K - kernel route, C - connected, S - static, R - RIPng, O OSPFv3, I - ISIS, B - BGP, * - FIB route. C>* ::1/128 is directly connected, lo O 2000:1::/32 [110/1] via ::1, lo, 01:21:19 C>* 2000:1::/32 is directly connected, eth1 K * 2000:1::/32 is directly connected, eth1 O 2000:2::/32 [110/1] is directly connected, eth0, 01:21:19 C>* 2000:2::/32 is directly connected, eth0 K * 2000:2::/32 is directly connected, eth0 O>* 2000:3::/32 [110/2] via fe80::20c:29ff:fe3a:550f, eth0, 01:20:43 O>* 2000:a::/32 [110/3] via fe80::20c:29ff:fe3a:550f, eth0, 01:20:38 C>* fe80::/64 is directly connected, eth1 K * fe80::/64 is directly connected, eth1 K>* ff00::/8 is directly connected, eth1 ROUTER_IPv6_A#
Enrutador B # telnet localhost zebra Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
140
User Access Verification Password: ROUTER_IPv6_B> enable Password: ROUTER_IPv6_B# ROUTER_IPv6_B# show ipv6 route Codes: K - kernel route, C - connected, S - static, R - RIPng, O OSPFv3, I - ISIS, B - BGP, * - FIB route. C>* ::1/128 is directly connected, lo O>* 2000:1::/32 [110/2] via fe80::20c:29ff:fed0:2896, eth0, 01:22:18 O 2000:2::/32 [110/1] is directly connected, eth0, 01:22:24 C>* 2000:2::/32 is directly connected, eth0 K * 2000:2::/32 is directly connected, eth0 O 2000:3::/32 [110/1] is directly connected, eth1, 01:21:50 C>* 2000:3::/32 is directly connected, eth1 K * 2000:3::/32 is directly connected, eth1 O>* 2000:a::/32 [110/2] via fe80::20c:29ff:fe13:500b, eth1, 01:21:46 C>* fe80::/64 is directly connected, eth1 K * fe80::/64 is directly connected, eth1 K>* ff00::/8 is directly connected, eth1 ROUTER_IPv6_B#
Enrutador C # telnet localhost zebra Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_C> enable Password: ROUTER_IPv6_C# ROUTER_IPv6_C# show ipv6 route Codes: K - kernel route, C - connected, S - static, R - RIPng, O OSPFv3, I - ISIS, B - BGP, * - FIB route. C>* O>* O>* O C>* K * O C>* K * C>* K * K>*
::1/128 is directly connected, lo 2000:1::/32 [110/3] via fe80::20c:29ff:fe3a:5519, eth0, 01:22:25 2000:2::/32 [110/2] via fe80::20c:29ff:fe3a:5519, eth0, 01:22:25 2000:3::/32 [110/1] is directly connected, eth0, 01:22:31 2000:3::/32 is directly connected, eth0 2000:3::/32 is directly connected, eth0 2000:a::/32 [110/1] via ::1, lo, 01:22:31 2000:a::/32 is directly connected, eth1 2000:a::/32 is directly connected, eth1 fe80::/64 is directly connected, eth1 fe80::/64 is directly connected, eth1 ff00::/8 is directly connected, eth1
141
ROUTER_IPv6_C#
Los usuarios deben estar configurados con un direccionamiento IPv6 como se muestra a continuación: Usuario 1 Dirección IPv6
2000:1::2/32
Puerta de enlace
2000:1::1
Dirección IPv6
2000:a::2/32
Puerta de enlace
2000:a::1
Usuario 2
4.1.2.8. Configuración de enrutamiento dinámico IPv4 utilizando el demonio bgpd
Figura 4-10. Escenario para enrutamiento dinámico con BGP
Para poder tener enrutamiento con BGP es necesario utilizar el demonio bgpd y el demonio Zebra. Al igual que los otros demonios, Zebra es el encargado de
142
administrar las interfaces y bgpd es el encargado de la configuración de la administración del enrutamiento con este protocolo. BGP es un protocolo para enrutamiento entre sistemas autónomos, por lo cual es muy utilizado sobre todo en ISPs. Para poder ver de una manera clara cómo se configura dicho demonio se puede ver el escenario en la Figura 4-10. Se pretende establecer comunicación entre los usuarios 1 y 2 que se encuentran en diferentes Sistemas Autónomos, para esto se utiliza el protocolo de enrutamiento BGP en los enrutadores A, B y C. Inicialmente se debe configurar las interfaces de cada uno de los enrutadores utilizando el demonio Zebra de la siguiente manera: Enrutador A Ingresar al modo de configuración configuraci ón de consola
# telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_A>
Ingresar en el modo de configuración global global
ROUTER_A> ROUTER_A> enable Password: ROUTER_A# configure terminal
Configurar las interfaces
ROUTER_A(config)# ROUTER_A(config)# interface eth0 ROUTER_A(config-if)# ROUTER_A(config-if)# ip address 192.168.15.1/30 ROUTER_A(config-if)# ROUTER_A(config-if)# no shutdown ROUTER_A(config-if)# ROUTER_A(config-if)# exit ROUTER_A(config)# ROUTER_A(config)# interface eth1 ROUTER_A(config-if)# ROUTER_A(config-if)# ip address 172.16.20.2/24 ROUTER_A(config-if)# ROUTER_A(config-if)# no shutdown ROUTER_A(config-if)# ROUTER_A(config-if)# exit
143
Enrutador B Ingresar al modo de configuración configuraci ón de consola
# telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_B>
Ingresar en el modo de configuración global global
ROUTER_B> ROUTER_B> enable Password: ROUTER_B# configure terminal
Configurar las interfaces
ROUTER_B(config)# ROUTER_B(config)# interface eth0 ROUTER_B(config-if)# ROUTER_B(config-if)# ip address 192.168.15.2/30 ROUTER_B(config-if)# ROUTER_B(config-if)# no shutdown ROUTER_B(config-if)# ROUTER_B(config-if)# exit ROUTER_B(config)# ROUTER_B(config)# interface eth1 ROUTER_B(config-if)# ROUTER_B(config-if)# ip address 192.168.15.5/30 ROUTER_B(config-if)# ROUTER_B(config-if)# no shutdown ROUTER_B(config-if)# ROUTER_B(config-if)# exit
Enrutador C Ingresar al modo de configuración configuraci ón de consola
# telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_C>
Ingresar en el modo de configuración global global
ROUTER_C> ROUTER_C> enable Password:
144
ROUTER_C# configure terminal
Configurar las interfaces
ROUTER_C(config)# ROUTER_C(config)# interface eth0 ROUTER_C(config-if)# ROUTER_C(config-if)# ip address 192.168.15.6/30 ROUTER_C(config-if)# ROUTER_C(config-if)# no shutdown ROUTER_C(config-if)# ROUTER_C(config-if)# exit ROUTER_C(config)# ROUTER_C(config)# interface eth1 ROUTER_C(config-if)# ROUTER_C(config-if)# ip address 172.16.60.2/24 ROUTER_C(config-if)# ROUTER_C(config-if)# no shutdown ROUTER_C(config-if)# ROUTER_C(config-if)# exit
Luego de la configuración de las interfaces se procede a configurar el demonio bgpd de la siguiente manera: Enrutador A Ingresar al modo de configuración configuraci ón de consola
# telnet localhost bgpd Trying 127.0.0.1... Connected to localhost.localdomain localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_BGP_A>
Ingresar en el modo de configuración global global
ROUTER_BGP_A> ROUTER_BGP_A> enable Password: ROUTER_BGP_A# ROUTER_BGP_A# configure terminal ROUTER_BGP_A(config)#
Configurar la información para BGP
ROUTER_BGP_A(config)# ROUTER_BGP_A(config)# ROUTER_BGP_A(config)# router ROUTER_BGP_A(config-router)# ROUTER_BGP_A(config-rout ROUTER_BGP_A(config-router)# er)# ROUTER_BGP_A(config-rout ROUTER_BGP_A(config-router)# er)# ROUTER_BGP_A(config-rout ROUTER_BGP_A(config-router)# er)#
bgp 100 network 172.16.20.0/24 172.16.20.0/24 neighbor 192.168.15.2 remote-as 200 exit
145
Enrutador B Ingresar al modo de configuración configuraci ón de consola
# telnet localhost bgpd Trying 127.0.0.1... Connected to localhost.localdomain localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al. User Access Verification Password: ROUTER_BGP_B>
Ingresar en el modo de configuración global global
ROUTER_BGP_B> ROUTER_BGP_B> enable Password: ROUTER_BGP_B# ROUTER_BGP_B# configure terminal ROUTER_BGP_B(config)#
Configurar la información para BGP
ROUTER_BGP_B(config)# ROUTER_BGP_B(config)# ROUTER_BGP_B(config)# router ROUTER_BGP_B(config-router)# ROUTER_BGP_B(config-rout ROUTER_BGP_B(config-router)# er)# ROUTER_BGP_B(config-rout ROUTER_BGP_B(config-router)# er)# ROUTER_BGP_B(config-rout ROUTER_BGP_B(config-router)# er)#
bgp 200 neighbor 192.168.15.1 remote-as 100 neighbor 192.168.15.6 remote-as 300 exit
Enrutador C Ingresar al modo de configuración configuraci ón de consola
# telnet localhost bgpd Trying 127.0.0.1... Connected to localhost.localdomain localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al. User Access Verification Password: ROUTER_BGP_C>
Ingresar en el modo de configuración global global
ROUTER_BGP_C> ROUTER_BGP_C> enable Password: ROUTER_BGP_C# ROUTER_BGP_C# configure terminal ROUTER_BGP_C(config)#
146
Configurar la información para BGP
ROUTER_BGP_C(config)# ROUTER_BGP_C(config)# ROUTER_BGP_C(config)# router ROUTER_BGP_C(config-router)# ROUTER_BGP_C(config-rout ROUTER_BGP_C(config-router)# er)# ROUTER_BGP_C(config-rout ROUTER_BGP_C(config-router)# er)# ROUTER_BGP_C(config-rout ROUTER_BGP_C(config-router)# er)#
bgp 300 network 172.16.60.0/24 172.16.60.0/24 neighbor 192.168.15.5 remote-as 200 exit
Se procede a continuación a verificar el estado de las rutas de la siguiente manera: Enrutador A # telnet localhost zebra Trying 127.0.0.1... Connected to localhost.localdomain localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_A> enable Password: ROUTER_A# ROUTER_A# show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route C>* 127.0.0.0/8 is directly connected, lo K>* 169.254.0.0/16 is directly connected, lo C>* 172.16.20.0/24 is directly connected, eth1 B>* 172.16.60.0/24 [20/0] via 192.168.15.2, 192.168.15.2, eth0, 00:04:19 C>* 192.168.15.0/30 is directly connected, eth0 ROUTER_A#
Enrutador B # telnet localhost zebra Trying 127.0.0.1... Connected to localhost.localdomain localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al. User Access Verification Password: ROUTER_B> enable Password:
147
ROUTER_B# ROUTER_B# show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route C>* 127.0.0.0/8 is directly connected, lo K>* 169.254.0.0/16 is directly connected, lo B>* 172.16.20.0/24 [20/0] via 192.168.15.1, eth0, 03:24:14 B>* 172.16.60.0/24 [20/0] via 192.168.15.6, eth1, 03:23:56 C>* 192.168.15.0/30 is directly connected, eth0 C>* 192.168.15.4/30 is directly connected, eth1 ROUTER_B#
Enrutador C # telnet localhost zebra Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_C> enable Password: ROUTER_C# ROUTER_C# show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route C>* 127.0.0.0/8 is directly connected, lo K>* 169.254.0.0/16 is directly connected, lo B>* 172.16.20.0/24 [20/0] via 192.168.15.5, eth0, 03:24:43 C>* 172.16.60.0/24 is directly connected, eth1 C>* 192.168.15.4/30 is directly connected, eth0 ROUTER_C#
Los usuarios deben tener configurado el siguiente direccionamiento: Usuario 1 Dirección IP
172.16.20.1
Máscara de Subred Puerta de enlace
255.255.255.0 172.16.20.2
148
Usuario 2 Dirección IP
172.16.60.1
Máscara de Subred
255.255.255.0
Puerta de enlace
172.16.60.2
4.1.2.9. Configuración de enrutamiento dinámico IPv6 utilizando el demonio bgpd
El protocolo de enrutamiento BGP puede funcionar con direccionamiento IPv6 y esto se lo puede conseguir a través del demonio bgpd. Al igual que los demonios anteriores se necesita configurar en primera instancia el demonio Zebra con la información correspondiente de las interfaces. Para poder comprender de mejor manera la configuración de este demonio con direccionamiento IPv6, se va a plantear el escenario que se muestra en la Figura 4-11.
Figura 4-11. Escenario para enrutamiento dinámico IPv6 con BGP
149
Se necesita establecer comunicación entre dos redes que se encuentran en sistemas autónomos diferentes, el usuario 1 debe comunicarse con el usuario 2; para dicho propósito en primer lugar se procede a configurar el demonio Zebra de la siguiente manera: Enrutador A Ingresar al modo de configuración de consola
# telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_A>
Ingresar en el modo de configuración global
ROUTER_IPv6_A> ROUTER_IPv6_A> enable Password: ROUTER_IPv6_A# configure terminal
Configurar las interfaces
ROUTER_IPv6_A(config)# interface eth0 ROUTER_IPv6_A(config-if)# ipv6 address 2000:2::1/32 ROUTER_IPv6_A(config-if)# no shutdown ROUTER_IPv6_A(config-if)# exit ROUTER_IPv6_A(config)# interface eth1 ROUTER_IPv6_A(config-if)# ipv6 address 2000:1::1/32 ROUTER_IPv6_A(config-if)# no shutdown ROUTER_IPv6_A(config-if)# exit
Enrutador B Ingresar al modo de configuración de consola
# telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al. User Access Verification
150
Password: ROUTER_IPv6_B>
Ingresar en el modo de configuración global
ROUTER_IPv6_B> ROUTER_IPv6_B> enable Password: ROUTER_IPv6_B# configure terminal
Configurar las interfaces
ROUTER_IPv6_B(config)# interface eth0 ROUTER_IPv6_B(config-if)# ipv6 address 2000:2::2/32 ROUTER_IPv6_B(config-if)# no shutdown ROUTER_IPv6_B(config-if)# exit ROUTER_IPv6_B(config)# interface eth1 ROUTER_IPv6_B(config-if)# ipv6 address 2000:3::1/32 ROUTER_IPv6_B(config-if)# no shutdown ROUTER_IPv6_B(config-if)# exit
Enrutador C Ingresar al modo de configuración de consola
# telnet localhost 2601 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_C>
Ingresar en el modo de configuración global
ROUTER_IPv6_C> ROUTER_IPv6_C> enable Password: ROUTER_IPv6_C# configure terminal
Configurar las interfaces
ROUTER_IPv6_C(config)# interface eth0 ROUTER_IPv6_C(config-if)# ipv6 address 2000:3::2/32 ROUTER_IPv6_C(config-if)# no shutdown ROUTER_IPv6_C(config-if)# exit ROUTER_IPv6_C(config)# interface eth1 ROUTER_IPv6_C(config-if)# ipv6 address 2000:A::1/32
151
ROUTER_IPv6_C(config-if)# no shutdown ROUTER_IPv6_C(config-if)# exit
La configuración de BGP- 4+ a través del demonio bgpd se hace de la siguiente manera: Enrutador A Ingresar al modo de configuración de consola
# telnet localhost bgpd Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_BGP_A>
Ingresar en el modo de configuración global
ROUTER_IPv6_BGP_A> enable Password: ROUTER_IPv6_BGP_A# ROUTER_IPv6_BGP_A# configure terminal ROUTER_IPv6_BGP_A(config)#
Configurar la información para BGP
ROUTER_IPv6_BGP_A(config)# ROUTER_IPv6_BGP_A(config)# router bgp 100 ROUTER_IPv6_BGP_A(config-router)# ROUTER_IPv6_BGP_A(config-router)# neighbor 2000:2::2 remote-as 200 ROUTER_IPv6_BGP_A(config-router)# ipv6 bgp network 2000:1::/32 ROUTER_IPv6_BGP_A(config-router)# address-family ipv6 unicast ROUTER_IPv6_BGP_A(config-router-af)# neighbor 2000:2::2 activate ROUTER_IPv6_BGP_A(config-router-af)# exit-address-family ROUTER_IPv6_BGP_A(config-router)# bgp router-id 0.0.0.1 ROUTER_IPv6_BGP_A(config-router)# exit
Enrutador B Ingresar al modo de configuración de consola
# telnet localhost bgpd Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1).
152
Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_BGP_B>
Ingresar en el modo de configuración global
ROUTER_IPv6_BGP_B> enable Password: ROUTER_IPv6_BGP_B# ROUTER_IPv6_BGP_B# configure terminal ROUTER_IPv6_BGP_B(config)#
Configurar la información para BGP
ROUTER_IPv6_BGP_B(config)# ROUTER_IPv6_BGP_B(config)# router bgp 200 ROUTER_IPv6_BGP_B(config-router)# ROUTER_IPv6_BGP_B(config-router)# neighbor 2000:2::1 remote-as 100 ROUTER_IPv6_BGP_B(config-router)# neighbor 2000:3::2 remote-as 300 ROUTER_IPv6_BGP_B(config-router)# address-family ipv6 unicast ROUTER_IPv6_BGP_B(config-router-af)# neighbor 2000:2::1 activate ROUTER_IPv6_BGP_B(config-router-af)# neighbor 2000:3::2 activate ROUTER_IPv6_BGP_B(config-router-af)# exit-address-family ROUTER_IPv6_BGP_B(config-router)# bgp router-id 0.0.0.2 ROUTER_IPv6_BGP_B(config-router)# exit
Enrutador C Ingresar al modo de configuración de consola
# telnet localhost bgpd Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_BGP_C>
Ingresar en el modo de configuración global
ROUTER_IPv6_BGP_C> enable Password: ROUTER_IPv6_BGP_C#
153
ROUTER_IPv6_BGP_C# configure terminal ROUTER_IPv6_BGP_C(config)#
Configurar la información para BGP
ROUTER_IPv6_BGP_C(config)# ROUTER_IPv6_BGP_C(config)# router bgp 300 ROUTER_IPv6_BGP_C(config-router)# ROUTER_IPv6_BGP_C(config-router)# neighbor 2000:3::1 remote-as 200 ROUTER_IPv6_BGP_C(config-router)# ipv6 bgp network 2000:A::/32 ROUTER_IPv6_BGP_C(config-router)# address-family ipv6 unicast ROUTER_IPv6_BGP_C(config-router-af)# neighbor 2000:3::1 activate ROUTER_IPv6_BGP_C(config-router-af)# exit-address-family ROUTER_IPv6_BGP_C(config-router)# bgp router-id 0.0.0.3 ROUTER_IPv6_BGP_C(config-router)# exit
Se procede a verificar que las rutas se encuentren en las tablas de enrutamiento de la siguiente manera: Enrutador A # telnet localhost zebra Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_A> enable Password: ROUTER_IPv6_A# ROUTER_IPv6_A# show ipv6 route Codes:K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - ISIS, B - BGP, * - FIB route. C>* ::1/128 is directly connected, lo C>* 2000:1::/32 is directly connected, eth1 K * 2000:1::/32 is directly connected, eth1 C>* 2000:2::/32 is directly connected, eth0 K * 2000:2::/32 is directly connected, eth0 B>* 2000:a::/32 [20/0] via fe80::20c:29ff:fe3a:550f, eth0, 00:07:56 C>* fe80::/64 is directly connected, eth1 K * fe80::/64 is directly connected, eth1 K>* ff00::/8 is directly connected, eth1 ROUTER_IPv6_A#
154
Enrutador B # telnet localhost zebra Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_B> enable Password: ROUTER_IPv6_B# ROUTER_IPv6_B# show ipv6 route Codes:K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - ISIS, B - BGP, * - FIB route. C>* ::1/128 is directly connected, lo B>* 2000:1::/32 [20/0] via fe80::20c:29ff:fed0:2896, eth0, 00:09:58 C>* 2000:2::/32 is directly connected, eth0 K * 2000:2::/32 is directly connected, eth0 C>* 2000:3::/32 is directly connected, eth1 K * 2000:3::/32 is directly connected, eth1 B>* 2000:a::/32 [20/0] via fe80::20c:29ff:fe13:500b, eth1, 00:09:49 C>* fe80::/64 is directly connected, eth1 K * fe80::/64 is directly connected, eth1 K>* ff00::/8 is directly connected, eth1 ROUTER_IPv6_B#
Enrutador C # telnet localhost zebra Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: ROUTER_IPv6_C> enable Password: ROUTER_IPv6_C# ROUTER_IPv6_C# show ipv6 route Codes:K - kernel route, C - connected, S - static, R - RIPng, O - OSPFv3, I - ISIS, B - BGP, * - FIB route. C>* B>* C>* K * C>*
::1/128 is directly connected, lo 2000:1::/32 [20/0] via fe80::20c:29ff:fe3a:5519, eth0, 00:10:53 2000:3::/32 is directly connected, eth0 2000:3::/32 is directly connected, eth0 2000:a::/32 is directly connected, eth1
155
K * 2000:a::/32 is directly connected, eth1 C>* fe80::/64 is directly connected, eth1 K * fe80::/64 is directly connected, eth1 K>* ff00::/8 is directly connected, eth1 ROUTER_IPv6_C#
Por último se presenta cómo debe estar configurado el direccionamiento de los usuarios. Usuario 1 El Usuario 1 debe estar configurado con los siguientes parámetros: Dirección IPv6
2000:1::2/32
Puerta de enlace
2000:1::1
Usuario 2 El Usuario 2 debe estar configurado con los siguientes parámetros: Dirección IPv6 Puerta de enlace
2000:a::2/32 2000:a::1
4.2. PRUEBAS DE FUNCIONALIDAD, SIMULACIÓN Y COSTO 4.2.1. SIMULACIÓN DE ESCENARIOS
Para poder levantar los escenarios expuestos para cada caso de enrutamiento presentado anteriormente, y debido a que no se disponen de tantos equipos para poder realizar las pruebas pertinentes y comprobar la funcionalidad del enrutador, fue necesario utilizar máquinas virtuales como se describió en el capítulo anterior; es decir, que cada uno de los escenarios fueron simulados a través de la utilización de máquinas virtuales en un mismo computador utilizando el programa VMWare Server. Cada enrutador de los escenarios es una máquina virtual; de igual manera los usuarios son máquinas virtuales y las pruebas aplicadas se hicieron sobre estos equipos.
156
Cada máquina virtual fue instalada y configurada de igual manera, es decir tanto la instalación del sistema operativo (Fedora Core 5) así como también la compilación del kernel y la instalación del paquete Quagga se la realizó de la misma manera para todos. Los usuarios finales en cambio son usuarios Linux con una configuración de escritorio. La configuración de cada enrutador se la realizó de una manera independiente, de acuerdo a las necesidades de cada escenario y dependiendo del esquema de direccionamiento presentado. Hay que destacar que cada máquina virtual tiene un comportamiento muy similar al de una máquina real y estas máquinas funcionarían de igual manera que si se tuvieran el mismo número de equipos disponibles para la realización de las pruebas. Por esta razón se puede decir con certeza que los resultados obtenidos de las pruebas reflejan lo que sucedería en un ambiente con máquinas totalmente reales. En la Figura 4-12 se puede apreciar cómo se plantearon los escenarios con máquinas virtuales.
Figura 4-12. Simulación de escenario de enrutamiento con máquinas virtuales
157
4.2.2. PRUEBAS DE FUNCIONALIDAD DEL ENRUTADOR
Cada uno de los enrutadores presentados en los escenarios anteriormente planteados deben cumplir un propósito que es establecer la conectividad entre las máquinas de las redes indicadas; hasta el momento sólo se han presentado las configuraciones de los enrutadores y de los usuarios pero no se han presentado resultados de dichos escenarios. La mejor manera de comprobar que los enrutadores están cumpliendo su propósito, es probando la conectividad de extremo a extremo (de usuario a usuario) utilizando el protocolo ICMP (Protocolo de Mensajes de Control de Internet) a través del utilitario ping , y verificando el camino que siguen los paquetes empleando el utilitario traceroute que se basa de igual manera en el protocolo ICMP. A través del utilitario ping se puede constatar si de un usuario a otro existe conectividad ya que éste utiliza mensajes echo y respuesta de echo definidos en el protocolo ICMP. Este utilitario es muy usado para verificar si existen errores en redes de datos. Hay que destacar que ping no siempre es una guía útil ya que a través de firewalls se puede bloquear este tipo de paquetes. En nuestro caso en particular, es útil ya que para los escenarios planteados no se dispone de ningún firewall y solo se va a constatar que exista conectividad. El utilitario traceroute sirve para diagnosticar redes de datos y permite seguir el camino de un paquete desde un punto hacia otro. Al igual que ping es muy utilizado para control de errores en redes de datos, pero así mismo puede ser bloqueado por firewalls por motivos de seguridad. Para los escenarios de enrutamiento planteados anteriormente para cada uno de los protocolos de enrutamiento dinámico, así como para el enrutamiento estático, se hicieron las pruebas tanto de conectividad como de ruta en los usuarios Linux finales. Los resultados de las pruebas se los puede observar en la Tabla 4-3 y el detalle de cada una de dichas pruebas se las puede analizar en el Anexo B.
158
Enrutamiento Protocolo Demonio Direccionamiento
Prueba Prueba Ping Traceroute
Estático
-
zebra
IPv4
OK
OK
Estático
-
zebra
IPv6
OK
OK
Dinámico
RIP
ripd
IPv4
OK
OK
Dinámico Dinámico
RIPng OSPFv2
ripngd ospfd
IPv6 IPv4
OK OK
OK OK
Dinámico
OSPFv3
ospf6d
IPv6
OK
OK
Dinámico
BGP-4
bgpd
IPv4
OK
OK
Dinámico
BGP-4+
bgpd
IPv6
OK
OK
Tabla 4-3. Resultados de las pruebas de conectividad y de ruta
En la Tabla 4-3 se puede observar que cada esquema de enrutamiento ha pasado con éxito las pruebas aplicadas, tomando en cuenta los escenarios planteados para cada uno de los protocolos que se han configurado, utilizando los demonios correspondientes y el esquema de direccionamiento adecuado. 4.2.3. COSTO DEL ENRUTADOR
Antes de establecer un precio al producto final, es necesario definir ciertos parámetros respecto a los costos del proyecto. Para ello se va a hacer un detalle de dichos costos tomando en cuenta toda la parte investigativa, así como la elaboración de la documentación de la misma. 4.2.3.1. Costo del proyecto
El presente proyecto ha tenido varias etapas en las cuales se deben considerar costos involucrados de cada una de ellas. Para este proyecto se ha tomado en consideración que el período laboral es de 4 horas diarias. En la Tabla 4-4 se puede observar el tiempo y las actividades que se realizaron para poder elaborar el enrutador, tomando en cuenta el tiempo de investigación así como también tomando en cuenta el tiempo necesario para la instalación del mismo.
159
Tareas Investigación Recopilación de la información Tratamiento de la información Documentación Ejecución Instalación del sistema operativo Recompilación de Kernel Instalación del Quagga Pruebas preliminares Pruebas de funcionamiento Pruebas de enrutamiento
Duración 38 días 50 horas 42 horas 60 horas 11 días 12 horas 16 horas 16 horas 18 días 26 horas 46 horas
Proyecto Elaboración Enrutador
67 días
Tabla 4-4. Duración del proyecto
En la Figura 4-13 se puede observar el desarrollo de las diferentes etapas en el tiempo detallado por días.
Figura 4-13. Desarrollo del proyecto en el tiempo
Para poder establecer el costo total del proyecto se va a poner como valor de trabajo por hora 12 dólares por lo que en conjunto se tienen los costos presentados en la Tabla 4-5.
160
Tareas Investigación Recopilación de la información Tratamiento de la información Documentación Ejecución Instalación del sistema operativo Recompilación de Kernel Instalación del Quagga Pruebas preliminares Pruebas de funcionamiento Pruebas de enrutamiento Proyecto Elaboración Enrutador
Duración
Unidad
Costo Unidad
Costo Total
50 42 60
horas horas horas
$ 12,00 $ 12,00 $ 12,00
$ 600,00 $ 504,00 $ 720,00
12 16 16
horas horas horas
$ 12,00 $ 12,00 $ 12,00
$ 144,00 $ 192,00 $ 192,00
26 46
horas horas
$ 12,00 $ 12,00
$ 312,00 $ 552,00
268
horas
$ 3.216,00
Tabla 4-5. Costo del proyecto
4.2.3.2. Precio del producto
El precio del producto final, es decir el precio del enrutador bajo Linux en el mercado se lo define de acuerdo al costo del equipo y al costo del trabajo realizado. Además se incluyen costos de documentación, instalación, configuración y capacitación. En la Tabla 4-6 se puede apreciar el detalle de dichos costos. Es importante notar que el precio del computador y el tipo de equipo, es el más barato que se encuentra en el mercado, además es el equipo de menores características que se puede conseguir. Esto aumenta un poco los costos, pero se puede buscar equipos usados de menores características y en buen funcionamiento que permitirían que se abaraten dichos costos. Una ventaja de tener un equipo de mejores características que las requeridas, es la funcionalidad extra que se le puede dar al mismo, pues se puede instalar otro tipo de servicios como filtrado de contenidos o un firewall a nivel de Linux. Otro punto importante a destacar es que para obtener el precio final del producto se han reducido las horas de trabajo en la implementación, configuración e instalación respecto a las horas que se incluyen en el costo del proyecto, esto se debe a la experiencia que se ha adquirido, además las pruebas previas para
161
comprobar buen funcionamiento del paquete Quagga se realizaron en el proyecto original y no es necesario volver a ejecutarlas en cada equipo; por otro lado la idea es realizar producción en serie lo que facilita y acelera el paso de implementación, instalación y configuración. Costo Cantidad Unidad Unidad
Item Equipo Computador Pentium III, 733 Mhz, 256MB RAM, 20GB Disco Duro Tarjeta de red (CNET PCI 10/100) Implementación del Enrutador Instalación del sistema operativo Recompilación de Kernel Instalación del Quagga Instalación y configuración Instalación Configuración Pruebas preliminares Pruebas de enrutamiento Documentación Documentación Capacitación Capacitación
Costo Total
1
unidad $ 220,00
$ 180,00
3
unidad
$ 3,80
$ 11,40
2 3 2
hora hora hora
$ 12,00 $ 12,00 $ 12,00
$ 24,00 $ 36,00 $ 24,00
2 2
hora hora
$ 12,00 $ 12,00
$ 24,00 $ 24,00
1
hora
$ 12,00
$ 12,00
1
unidad
$ 30,00
$ 30,00
4
hora
$ 15,00
$ 60,00
Precio Final al Mercado
$ 425,40 Tabla 4-6. Precio final del enrutador
El producto final que puede ser comercializado consta de un computador con las características mínimas de hardware para poder ser instalado el sistema operativo como se detalló al comienzo de este capítulo. Además consta de la instalación del sistema operativo y el paquete de enrutamiento, así como la instalación del equipo en el lugar a ser utilizado con sus respectivas pruebas. Por otro lado se incluye la documentación de funcionamiento y uso del equipo, así como también los correspondientes archivos de configuración. Además se incluye el manual de configuración del enrutador que se adjunta en el Anexo C. Otro punto importante
162
que se incluye en el precio final del producto es la capacitación básica del manejo del equipo. Si se tiene un equipo con buenas características se pueden tener varios enrutadores en un mismo equipo, lo cual sería útil para implementacion de escenarios con fines didácticos; esto permitiría que los costos se reduzcan para ya que no habría que utilizar varios computadores, sino que varias máquinas virtuales como enrutadores. Es necesario tomar en cuenta que si la persona o empresa que desee el producto dispone de un equipo con las características mencionadas para que funcione el enrutador, se considerará únicamente el precio de instalación documentación y capacitación como se muestra en la Tabla 4-7. Item Implementación del Enrutador Instalación del sistema operativo Recompilación de Kernel Instalación de Quagga Instalación y configuración Instalación Configuración Pruebas preliminares Pruebas de enrutamiento Documentación Documentación Capacitación Capacitación
Costo Cantidad Unidad Unidad
Costo Total
2 3 2
hora hora hora
$ 15,00 $ 15,00 $ 15,00
$ 30,00 $ 45,00 $ 30,00
2 2
hora hora
$ 12,00 $ 12,00
$ 24,00 $ 24,00
1
hora
$ 12,00
$ 12,00
unidad $ 30,00
$ 30,00
1 4
hora
$ 15,00
Precio Final al Mercado
$ 60,00 $ 255,00
Tabla 4-7. Precio de instalación y configuración del equipo
Los costos por hora aumentan en la implementación, si el cliente proporciona el equipo debido a que se necesita instalar el enrutador en otro sitio y se tiene que hacer una revisión previa del mismo para comprobar su buen estado físico.
163
Es necesario comparar el enrutador Quagga con un enrutador comercial para analizar los beneficios, ventajas y desventajas de una solución frente a otra; para ello se ha seleccionado el enrutador Cisco 871-K9 que tiene características comparables al enrutador implementado en el presente proyecto de titulación. En la Tabla 4-8 se puede apreciar una comparación general entre las dos soluciones. Característica Memoria RAM Almacenamiento Protocolo de direccionamiento
Enrutador Cisco 871 K9 128 MB 24 MB Memoria Flash OSPF, RIP-1, RIP-2, BGP, EIGRP Ethernet, Fast Ethernet, Protocolo de interconexión IEEE 802.11b, IEEE de datos 802.11g Protocolo de gestión remota SNMP, Telnet, HTTP Protección firewall, autosensor por dispositivo, soporte de DHCP, soporte de NAT, alimentación mediante Ethernet (PoE), VPN, soporte para PAT, WCCP 1.0, señal ascendente automática Características (MDI/MDI-X automático), activable, Intrusion Detection System (IDS), filtrado de dirección MAC, soporte IPv6, Sistema de prevención de intrusiones (IPS), filtrado de URL, Automatic Route Processing (AutoRP) Alimentación CA 120/230 V Tecnología de conectividad
Inalámbrico, cableado
Enrutador Quagga 256 MB 20 GB Disco Duro OSPF, RIP-1, RIP-2, RIPng, BGP Ethernet, Fast Ethernet, (según el dispositivo) SSH, Telnet, SNMP
Firewall a través de iptables, puede configurarse DHCP*, NAT,VPN*, PAT, IDS*, Filtrado de dirección MAC a través de iptables*, soporte IPv6, filtrado de contenidos*
CA 120/240 V Cableado, (inalámbrico instalando tarjetas wireless*)
IEEE 802.1Q, IEEE 802.11b, IEEE 802.11d, Va a depender de la Cumplimiento de normas: IEEE 802.11g, IEEE 802.1x, Tecnología a utilizarse Wi-Fi CERTIFIED 4 x red - Ethernet 10BaseT/100Base-TX - RJ-45 ¦ 1 x 4 x red FastEthernet red - Ethernet 10Base(pueden ser instaladas otro Interfaces T/100Base-TX - RJ-45 tipo de tarjetas compatibles (WAN) ¦ 1 x gestión con Linux) consola - RJ-45 ¦ 1 x red Radio-Ethernet * Para tener estas opciones se debe instalar y/o configurar adicionalmente Tabla 4-8. Comparación entre enrutadores
164
Se puede observar que hay características que tiene el enrutador Cisco que no se disponen en el enrutador Quagga, aunque algunas de ellas pueden ser implementadas configurando paquetes adicionales como el caso de DHCP, filtrado de contenidos y el manejo de VPNs. El enrutador Cisco 871 K9 tiene soporte para conectividad inalámbrica; si se desea configurar tarjetas inalámbricas en el enrutador bajo Linux, es necesario considerar que se deben adquirir tarjetas inalámbricas con soporte para este sistema operativo. Por otro lado los enrutadores Quagga no disponen de los protocolos de enrutamiento IGRP y EIGRP ya que son propietarios de CISCO. En la Tabla 4-9 se presenta una comparación de precios entre el enrutador Cisco 871 K9 y el enrutador Quagga. La correspondiente cotización del equipo Cisco se adjunta en el Anexo E. Enrutador CISCO 871 K9 Enrutador Quagga Precio Precio Precio Precio Item Cantidad Descripción Unitario Total Unitario Total 1 1 Enrutador $ 655,90 $ 655,90 $ 275,40 $ 275,40 Instalación y 2 1 Configuración $ 500,00 $ 500,00 $ 150,00 $ 150,00 TOTAL
$ 1.155,90 TOTAL
$ 425,40
Tabla 4-9. Comparación de precios entre enrutadores
El precio del enrutador Quagga incluyendo instalación y configuración es menor que la mitad que el precio de un enrutador Cisco 871 K9 incluyendo instalación y configuración, pero hay que destacar que un enrutador Cisco tiene algunas características adicionales que el enrutador Quagga no incluye, además es importante señalar que el desempeño de un equipo diseñado específicamente para ser enrutador es superior, debido a que ha sido objeto de estudios por una empresa dedicada a esto y con una gran experiencia en el medio. Por otro lado es importante señalar que el enrutador Quagga es una solución de bajo costo y puede ser implementada sin ningún problema en un ambiente de enrutamiento con buenos resultados.
165
REFERENCIAS CAPÍTULO 4 [1]
ISHIGURO, Kunihiro, Quagga, A routing software package for TCP/IP networks, Julio 2006
[2]
IBM, Linux System Administration I: Implementation, IBM, Noviembre 2005
[3]
IBM, Linux Power User, IBM, Septiembre 2005
[4]
IBM, Linux Network Administration I: TCP/IP and TCP/IP services, IBM, Octubre 2005
[5]
IBM, Linux Network Administration II: Security and Firewalls, IBM, Noviembre 2004
[6]
COLLADO, Eduardo, Cisco CCNA – CCNP http://www.eduangi.com/documentos Último acceso: 2007 – 08 – 16
[7]
Fedora Proyect http://fedoraproject.org Último acceso: 2007 – 08 – 16
[8]
Zebra http://www.zebra.org Último acceso: 2007 – 08 – 16
[9]
Quagga http://www.quagga.net Último acceso: 2007 – 08 – 16
CAPÍTULO 5 DESARROLLO DE LAS PRÁCTICAS DE LABORATORIO
166
CAPÍTULO 5. DESARROLLO DE LAS PRÁCTICAS DE LABORATORIO
En este capítulo se pretende mostrar determinados escenarios que pueden ser implementados en el laboratorio para el mejor entendimiento del enrutamiento, así como también familiarizarse con la configuración de los enrutadores basados en Linux. También se pretende mostrar que es posible realizar prácticas de laboratorio con máquinas virtuales, ya que éstas permiten que se ejecuten varias máquinas en una misma. Además se muestra en este capítulo qué situaciones, que no pueden ser configuradas con el demonio Quagga, pueden ser soportadas por otras herramientas como iptables . Por último se muestra que con fines didácticos la utilización de simuladores puede ser útil sobre todo para situaciones que no pueden ser configuradas con el paquete Quagga.
5.1. ELABORACIÓN E IMPLEMENTACIÓN DE LAS PRÁCTICAS En el capítulo anterior se muestra la configuración de cada uno de los demonios y protocolos del paquete Quagga para ambientes sencillos de conectividad, sin embargo no se puso a consideración un análisis profundo del comportamiento de dichos protocolos. Para ello se plantearán diferentes prácticas que consisten en un conjunto de situaciones propias de cada protocolo. 5.1.1. PRÁCTICA 1: CAMINO MÁS CORTO CON RIP 5.1.1.1. Objetivo
Analizar el comportamiento del protocolo RIP utilizando el demonio ripd del paquete Quagga ante un ambiente de varios nodos y comprobar que el camino utilizado sea el de menor número de saltos.
167
5.1.1.2. Descripción
En la Figura 5-1 se puede observar una red de datos que se encuentra configurada con el protocolo de enrutamiento RIP; se pretende comprobar que la comunicación entre el usuario 1 y el usuario 2 utiliza el menor número de saltos como, establece la teoría de dicho protocolo. Enrutador B
Eth1: 192.168.15.5/30 Eth0: 192.168.15.2/30
Enrutador C
Eth0: 192.168.15.6/30 Eth1: 192.168.15.9/30
Eth1: 192.168.15.1/30 Eth2: 192.168.15.14/30 Eth0: 172.16.0.2/24
Usuario 2
Eth0: 192.168.15.10/30 Eth1: 192.168.15.13/30
Eth2: 172.16.1.2/24
Usuario 1 Enrutador A Enrutador D 172.168.1.1/24 172.16.0.1/24
Figura 5-1. Escenario Práctica 1
Luego de haber comprobado que se produzca el menor número de saltos, se procederá a eliminar el enlace de datos existente entre el enrutador A y el enrutador D, para así observar la reestructuración de la tabla de enrutamiento y comprobar que esta reestructuración de la tabla se realiza dinámicamente, sin tener que hacer ninguna configuración manual adicional. 5.1.1.3. Desarrollo
La configuración básica de cada uno de los enrutadores, es decir el manejo de contraseñas, el nombre del equipo y el direccionamiento de las interfaces se la hace con el demonio Zebra como se describió en el capítulo anterior. Los archivos de configuración de cada uno de ellos se puede observar en el Anexo D.
168
La configuración del protocolo RIP se la hace a través del demonio ripd como se presentó en el capítulo anterior y se puede observar los archivos de configuración de cada enrutador en el Anexo D. El protocolo RIP establece el menor número de saltos para llegar al destino final por lo que se hace una traza desde el usuario 1 al usuario 2 para verificar dicha situación. USUARIO1# traceroute 172.16.1.1 traceroute to 172.16.1.1 (172.16.1.1), 30 hops max, 40 byte packets 1 172.16.0.2 (172.16.0.2) 0.693 ms 0.916 ms 0.104 ms 2 192.168.15.13 (192.168.15.13) 0.775 ms 0.351 ms 0.631 ms 3 172.16.1.1 (172.16.1.1)(H!) 0.373 ms (H!) 0.454 ms (H!) 0.930 ms USUARIO1#
El camino tomado se puede observar en la Figura 5-2; además se puede comprobar que este camino es aquel que contiene menor número de saltos.
Figura 5-2. Camino más corto
Ahora si se elimina el enlace existente entre el enrutador A y el enrutador D, se reestructuran las tablas de enrutamiento y se tiene la siguiente traza: USUARIO1# traceroute 172.16.1.1 traceroute to 172.16.1.1 (172.16.1.1), 30 hops max, 40 byte packets 1 172.16.0.2 (172.16.0.2) 0.148 ms 0.100 ms 0.056 ms
169
2 192.168.15.2 (192.168.15.2) 2.056 ms 0.309 ms 0.575 ms 3 192.168.15.6 (192.168.15.6) 0.769 ms 0.865 ms 1.065 ms 4 192.168.15.10 (192.168.15.10) 1.250 ms 0.698 ms 2.586 ms 5 172.16.1.1 (172.16.1.1)(H!) 4.132 ms (H!) 3.644 ms (H!) 7.473 ms USUARIO1#
El camino tomado se puede observar en la Figura 5-3, después de haberse reestructurado la tabla de enrutamiento dinámicamente.
Figura 5-3. Reestructuración de la tabla de enrutamiento
Si el enlace entre el enrutador A y el enrutador D se vuelve a reestablecer la tabla de rutas se reestructura nuevamente escogiendo el camino más corto, es decir se vuelve a la ruta original. Esto se puede observar en la traza que se muestra a continuación: USUARIO1# traceroute 172.16.1.1 traceroute to 172.16.1.1 (172.16.1.1), 30 hops max, 40 byte packets 1 172.16.0.2 (172.16.0.2) 0.316 ms 0.111 ms 0.246 ms 2 192.168.15.13 (192.168.15.13) 0.315 ms 0.442 ms 0.415 ms 3 172.16.1.1 (172.16.1.1)(H!) 0.926 ms (H!) 0.806 ms (H!) 1.918 ms USUARIO1#
170
5.1.2. PRÁCTICA 2: SELECCIÓN DE LA MEJOR RUTA 5.1.2.1. Objetivo
Comprobar que el protocolo de enrutamiento OSPF funciona adecuadamente, a través del demonio ospfd, haciendo cambios en los parámetros de los enlaces. 5.1.2.2. Descripción
Uno de los parámetros tomados para la selección de la mejor ruta con OSPF es el ancho de banda del enlace, sin tomar en cuenta el número de saltos que pueda tener la ruta para llegar al destino; es por esto que se plantea el escenario que se muestra en la Figura 5-4, en donde se tienen 3 enrutadores configurados con el protocolo OSPF y que en primera instancia todos los enlaces son de las mismas características.
Figura 5-4. Escenario Práctica 2
Después de definir la mejor ruta se procede a hacer cambios en el ancho de banda de uno de los enlaces, para así comprobar cómo se reestructura la nueva tabla de enrutamiento y comprobar que el protocolo OSPF a través del paquete Quagga funciona correctamente.
171
5.1.2.3. Desarrollo
La configuración básica de cada enrutador se la realiza como se indicó en el capítulo anterior y se pueden observar los correspondientes archivos de configuración del demonio Zebra en el Anexo D. Para configurar el protocolo OSPF se lo hace a través del demonio ospfd como se mostró en el capítulo anterior y se pueden observar los archivos de configuración de este demonio en el Anexo D. El protocolo OSPF elige la mejor ruta de acuerdo al estado del enlace tomando en cuenta varios parámetros, en este caso en particular los enlaces son de las mismas características por lo que se tiene por resultado la siguiente traza desde el usuario 1 al usuario 2: USUARIO1# traceroute 200.5.10.1 traceroute to 200.5.10.1 (200.5.10.1), 30 hops max, 40 byte packets 1 10.1.1.2 (10.1.1.2) 21.844 ms 18.042 ms 13.867 ms 2 192.168.15.10 (192.168.15.10) 11.707 ms 6.673 ms 2.944 ms 3 200.5.10.1 (200.5.10.1) 37.466 ms 21.659 ms 26.528 ms USUARIO1#
Esta traza se la puede apreciar de mejor manera en la Figura 5-5.
Figura 5-5. Selección de la mejor ruta
172
Después de haber comprobado la mejor ruta, se procede a cambiar las características del enlace entre el enrutador A y el enrutador C. Además de cambiar las características del enlace es necesario indicar a los enrutadores el nuevo ancho de banda ya que por defecto el ancho de banda está definido en 100 Mbps. Es necesario hacer este cambio ya que las decisiones que toma OSPF se basan en este valor. Para poder hacer estos cambios se necesita ingresar vía consola al demonio Zebra, y luego ingresar a la interfaz que se desea hacer el cambio; en este caso en particular para el enrutador A se cambiará en la interfaz Eth2 y en el enrutador C en la interfaz Eth1 y los cambios se los efectúan de la siguiente manera: Enrutador A A# configure terminal A(config)# interface eth2 A(config-if)# bandwidth 56 A(config-if)# exit
Enrutador C C# configure terminal C(config)# interface eth1 C(config-if)# bandwidth 56 C(config-if)# exit
El valor del ancho de banda está definido en Kbps. Hay que destacar que el valor indicado en la configuración es un valor referencial, es decir que este valor no va a cambiar las características de enlace, sólo permite al protocolo OSPF definir la mejor ruta; en otras palabras si se cambia este valor a cualquiera que éste sea, el desempeño del enlace no va a cambiar ya que las características físicas del mismo no se han modificado. Luego de haber hecho este cambio con el enlace se procede a verificar la traza con lo que se tiene los siguientes resultados:
USUARIO1# traceroute 200.5.10.1 traceroute to 200.5.10.1 (200.5.10.1), 30 hops max, 40 byte packets 1 10.1.1.2 (10.1.1.2) 1.636 ms 6.231 ms 0.200 ms 2 192.168.15.2 (192.168.15.2) 4.175 ms 3.773 ms 0.828 ms
173
3 192.168.15.10 (192.168.15.10) 13.387 ms 11.433 ms 7.548 ms 4 200.5.10.1 (200.5.10.1) 8.780 ms 1.098 ms 1.114 ms USUARIO1#
En la Figura 5-6 se puede apreciar de mejor manera la nueva ruta seleccionada debido al cambio de los parámetros.
Figura 5-6. Reestructuración de la ruta
Ahora, si se tiene una falla en el enlace entre el enrutador A y B, la tabla de enrutamiento se reestructura de tal manera que el usuario 1 y 2 se puedan comunicar y esto sucede a través del enlace de 56 Kbps. Esta reestructuración se elabora dinámicamente lo que permite tener siempre conectividad entre los usuarios finales. Esta reestructuración se puede observar en la Figura 5-7 y su traza se muestra a continuación: USUARIO1# traceroute 200.5.10.1 traceroute to 200.5.10.1 (200.5.10.1), 30 hops max, 40 byte packets 1 10.1.1.2 (10.1.1.2) 5.042 ms 0.340 ms 0.264 ms 2 192.168.15.10 (192.168.15.10) 0.549 ms 0.323 ms 1.817 ms 3 200.5.10.1 (200.5.10.1) 2.217 ms 1.200 ms 2.296 ms USUARIO1#
174
Figura 5-7. Reestructuración debido a falla de enlace
5.1.3. PRÁCTICA 3: NAT 5.1.3.1. Objetivo
Realizar la configuración de un enrutador basado en Linux, que permita el uso de NAT para el acceso al Internet desde una red interna. 5.1.3.2. Descripción
Se tiene una red privada en la cual se encuentra configurado el protocolo RIP para el enrutamiento interno, y se tiene un dirección pública con la cual se desea tener acceso a Internet utilizando NAT en el enrutador B como se puede apreciar en la Figura 5-8. Previa a la configuración de NAT es necesario configurar una ruta por defecto en el enrutador A para que todo el tráfico que no sea interno salga a Internet; esta ruta por defecto tiene que ser anunciada a los otros enrutadores a través del protocolo RIP. Luego de haber configurado la ruta por defecto se hacen las pruebas correspondientes de direccionamiento utilizando ping y tcpdump 35 para verificar el 35
Tcpdum es una herramienta que permite capturar en tiempo real paquetes que se transmiten y se reciben en una red. Esta herramienta es útil para resolver problemas en una red, además suele ser utilizada para la captura de contraseñas no cifradas en algunos protocolos como Telnet.
175
origen de las peticiones ICMP; posteriormente se configura NAT y se comprueba nuevamente el origen de las peticiones ICMP.
Figura 5-8. Escenario Práctica 3
5.1.3.3. Desarrollo
La configuración básica de los enrutadores, tanto el demonio Zebra como el demonio ripd, se la realiza como se indicó en el capítulo anterior y los archivos de configuración se los puede observar en el Anexo D. Para el acceso a Internet es necesario establecer una ruta por defecto en el enrutador A; esta ruta se la configura a través del demonio Zebra en el modo de configuración global de la siguiente manera: A# configure terminal A(config)# ip route 0.0.0.0 0.0.0.0 eth0 A(config)#
176
Como el protocolo RIP se encuentra configurado en la red interna es necesario anunciar esta ruta por defecto a los demás enrutadores de la red interna, para esto es necesario añadir la siguiente opción en el demonio ripd del enrutador A: A_RIP_NAT# configure terminal A_RIP_NAT(config)# router rip A_RIP_NAT(config-router)# default-information originate A_RIP_NAT(config-router)#
Ahora para hacer las pruebas correspondientes, previa la configuración de NAT, se asume que la máquina llamada Internet es un destino cualquiera en el Internet, al cual se va a hacer pruebas de conectividad utilizando ping desde cualquier usuario de la red, por ejemplo el Usuario 3 como se observa a continuación: USUARIO3# ping -c 5 200.50.10.2 PING 200.50.10.2 (200.50.10.2) 56(84) 64 bytes from 200.50.10.2: icmp_seq=1 64 bytes from 200.50.10.2: icmp_seq=2 64 bytes from 200.50.10.2: icmp_seq=3 64 bytes from 200.50.10.2: icmp_seq=4 64 bytes from 200.50.10.2: icmp_seq=5
bytes of data. ttl=62 time=10.9 ttl=62 time=2.13 ttl=62 time=2.13 ttl=62 time=1.80 ttl=62 time=1.17
ms ms ms ms ms
--- 200.50.10.2 ping statistics --5 packets transmitted, 5 received, 0% packet loss, time 4016ms rtt min/avg/max/mdev = 1.179/3.634/10.913/3.656 ms USUARIO3#
La salida después de utilizar tcpdump se muestra a continuación, y se puede apreciar que el origen del paquete ICMP es la dirección privada 172.16.41.2 y el destino es 200.50.10.2. INTERNET# tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 01:13:30.985837 IP 172.16.41.2 > 200.50.10.2: ICMP echo request, id 24583, seq 1, length 64 01:13:30.985957 IP 200.50.10.2 > 172.16.41.2: ICMP echo reply, id 24583, seq 1, length 64 01:13:31.962864 IP 172.16.41.2 > 200.50.10.2: ICMP echo request, id 24583, seq 2, length 64 01:13:31.963003 IP 200.50.10.2 > 172.16.41.2: ICMP echo reply, id 24583, seq 2, length 64
177
01:13:33.022391 IP 172.16.41.2 24583, seq 3, length 64 01:13:33.022447 IP 200.50.10.2 seq 3, length 64 01:13:34.003123 IP 172.16.41.2 24583, seq 4, length 64 01:13:34.003182 IP 200.50.10.2 seq 4, length 64 01:13:35.032202 IP 172.16.41.2 24583, seq 5, length 64 01:13:35.032265 IP 200.50.10.2 seq 5, length 64
> 200.50.10.2: ICMP echo request, id > 172.16.41.2: ICMP echo reply, id 24583, > 200.50.10.2: ICMP echo request, id > 172.16.41.2: ICMP echo reply, id 24583, > 200.50.10.2: ICMP echo request, id > 172.16.41.2: ICMP echo reply, id 24583,
10 packets captured 20 packets received by filter 0 packets dropped by kernel INTERNET#
Luego de esto se procede a realizar la configuración de NAT en el enrutador A con la ayuda de iptables 36. En primera instancia es necesario iniciar el servicio de esta herramienta lo cual se hace de la siguiente manera: # service iptables start
Para que iptables se inicie, siempre que se reinicie el computador se digita el siguiente comando: # chkcongig iptables on
Existe gran cantidad de información para la configuración de esta herramienta, y la configuración de NAT es una configuración que se presenta para el propósito de esta práctica; es recomendable analizar la situación de configuración según el caso y las necesidades. Se tiene en la interfaz eth0 del enrutador A configurada la dirección pública por lo que se va a realizar la traducción en esa interfaz; esto se lo realiza de la siguiente manera:
36
Iptables es una de las herramientas más populares en sistemas Linux para el filtrado de paquetes, aunque otra de sus funciones puede ser la traducción de direcciones de red (NAT). Es una herramienta muy utilizada debido a que es muy potente y útil para la elaboración de cortafuegos basados en Linux.
178
#iptables –F #iptables –t nat -F #iptables –t nat –A POSTROUTING –o eth0 –d !172.16.40.0/24 –j MASQUERADE #iptables –t nat –A POSTROUTING –o eth0 –d !192.168.15.0/30 –j MASQUERADE #service iptables save
Las reglas de iptables se almacenan en el archivo /etc/sysconfig/iptables; este archivo se lo puede observar en el Anexo D. Luego de haber configurado NAT se procede a verificar en la máquina INTERNET que el origen de los paquetes ICMP provienen de la dirección pública del enrutador A de la siguiente manera: USUARIO3# ping -c 5 200.50.10.2 PING 200.50.10.2 (200.50.10.2) 56(84) 64 bytes from 200.50.10.2: icmp_seq=1 64 bytes from 200.50.10.2: icmp_seq=2 64 bytes from 200.50.10.2: icmp_seq=3 64 bytes from 200.50.10.2: icmp_seq=4 64 bytes from 200.50.10.2: icmp_seq=5
bytes of data. ttl=62 time=3.69 ttl=62 time=1.52 ttl=62 time=1.00 ttl=62 time=1.75 ttl=62 time=1.69
ms ms ms ms ms
--- 200.50.10.2 ping statistics --5 packets transmitted, 5 received, 0% packet loss, time 4012ms rtt min/avg/max/mdev = 1.006/1.934/3.696/0.919 ms USUARIO3#
INTERNET# tcpdump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 01:54:29.223122 IP 200.50.10.1 > 200.50.10.2: ICMP echo request, id 16649, seq 1, length 64 01:54:29.293953 IP 200.50.10.2 > 200.50.10.1: ICMP echo reply, id 16649, seq 1, length 64 01:54:30.202418 IP 200.50.10.1 > 200.50.10.2: ICMP echo request, id 16649, seq 2, length 64 01:54:30.202462 IP 200.50.10.2 > 200.50.10.1: ICMP echo reply, id 16649, seq 2, length 64 01:54:31.226139 IP 200.50.10.1 > 200.50.10.2: ICMP echo request, id 16649, seq 3, length 64 01:54:31.226183 IP 200.50.10.2 > 200.50.10.1: ICMP echo reply, id 16649, seq 3, length 64 01:54:32.190394 IP 200.50.10.1 > 200.50.10.2: ICMP echo request, id 16649, seq 4, length 64 01:54:32.190437 IP 200.50.10.2 > 200.50.10.1: ICMP echo reply, id 16649, seq 4, length 64 01:54:33.230692 IP 200.50.10.1 > 200.50.10.2: ICMP echo request, id 16649, seq 5, length 64 01:54:33.230740 IP 200.50.10.2 > 200.50.10.1: ICMP echo reply, id 16649, seq 5, length 64
179
10 packets captured 20 packets received by filter 0 packets dropped by kernel INTERNET#
Se puede observar que NAT se encuentra en funcionamiento y que la red interna puede tener comunicación con el Internet a través de este tipo de configuración. 5.1.4. PRÁCTICA 4: CONTROL BÁSICO DE ACCESO 5.1.4.1. Objetivo
Establecer políticas básicas de control de acceso en los enrutadores con la ayuda de la herramienta iptables y realizar las pruebas correspondientes. 5.1.4.2. Descripción
Una de las características importantes que presentan los enrutadores comerciales, como son los enrutadores Cisco, es el control de acceso que lo realizan a través de listas (ACLs), y se incluyen ya sea de entrada o salida en las interfaces y niegan o permiten el acceso de determinado tráfico. En el paquete Quagga existen listas de control de acceso, pero están destinadas al control y manejo de rutas; es decir que el control de acceso que realizan, es únicamente para permitir o negar el intercambio de tablas de enrutamiento. Es por esto que es necesaria la utilización de herramientas complementarias como iptables . Cabe destacar que iptables es una herramienta muy poderosa para el filtrado de paquetes, y su uso va a depender de la experiencia que se tenga con la misma y sobre todo va a depender de las necesidades. Es importante tener claro que en esta práctica se pretende establecer de manera muy básica el control de acceso a través de iptables y para esto se ha planteado un escenario que se puede observar en la Figura 5-9, posteriormente se hará un filtrado un poco más avanzado.
180
Figura 5-9. Escenario Práctica 4
En primer lugar se debe elegir un protocolo de enrutamiento para el escenario planteado y luego configurarlo. Posteriormente se configuran las reglas que se van a implementar en iptables según los parámetros establecidos a continuación: El tráfico del usuario 1 hacia el usuario 2 está permitido El tráfico del usuario 2 hacia el usuario 1 está permitido El tráfico del usuario 2 hacia el usuario 3 está negado El tráfico del usuario 3 hacia el usuario 2 está negado El tráfico del usuario 1 hacia el usuario 3 está negado El tráfico del usuario 3 hacia el usuario 1 está negado
Finalmente comprobar que no se tiene acceso según las reglas configuradas en iptables . 5.1.4.3. Desarrollo
Se ha seleccionado como protocolo de enrutamiento OSPF, aunque podría ser utilizado cualquier otro inclusive enrutamiento estático; sin embargo es importante
181
estar siempre practicando la configuración de los diferentes protocolos es por eso que se ha seleccionado éste. Como se presentó en el capítulo anterior la configuración del demonio Zebra y el demonio ospfd son bastante sencillos, y los archivos de configuración se los puede apreciar en el Anexo D. Para establecer el control de acceso se debe iniciar iptables de la siguiente manera: # service iptables start
Para que iptables se inicie, siempre que se reinicie el computador, se digita el siguiente comando: # chkcongig iptables on
Ahora es necesario borrar políticas previamente configuradas, para lo cual se ejecutan los siguientes comandos: # iptables -t nat -F # iptables -F # iptables -X
Es necesario establecer las políticas por defecto a las reglas establecidas para esta práctica, lo cual se realiza como se muestra a continuación: # iptables -P INPUT ACCEPT # iptables -P OUTPUT ACCEPT # iptables -P FORWARD ACCEPT
Las políticas según las indicaciones de esta práctica se las establecen de la siguiente manera: # iptables -A FORWARD -i eth1 -o eth2 -s 172.16.20.2 -d 172.16.30.2 -j DROP
182
# iptables DROP # iptables DROP # iptables DROP # iptables DROP # iptables DROP
-A FORWARD -i eth2 -o eth1 -s 172.16.30.2 -d 172.16.20.2 -j -A FORWARD -i eth0 -o eth2 -s 172.16.10.2 -d 172.16.30.2 -j -A FORWARD -o eth1 -i eth2 -d 172.16.20.2 -s 172.16.30.2 -j -A FORWARD -o eth2 -i eth1 -d 172.16.30.2 -s 172.16.20.2 -j -A FORWARD -o eth0 -i eth2 -d 172.16.10.2 -s 172.16.30.2 -j
Hay que destacar que ésta no es la única manera de establecer las políticas utilizando iptables ; el manejo de esta herramienta va a depender de la experiencia que se tenga con el uso de la misma y el tipo de filtrado que se desee realizar. Es necesario tener en cuenta además el escenario donde se va a aplicar el control de acceso; también hay que definir la política por defecto del acceso pues de aquí se puede partir para definir y configurar dichas políticas. La comprobación del escenario planteado después de establecidas las políticas de acceso se puede observar en la Tabla 5-1. Usuario
Usuario
Estado
Resultado
Usuario 1
→
Usuario 2
Permitido
OK
Usuario 2
→
Usuario 1
Permitido
OK
Usuario 2
→
Usuario 3
Negado
OK
Usuario 3
→
Usuario 2
Negado
OK
Usuario 1
→
Usuario 3
Negado
OK
Usuario 3
→
Usuario 1
Negado
OK
Tabla 5-1. Resultados Práctica 4
5.1.5. PRÁCTICA 5: PRUEBAS DE ACCESO REMOTO 5.1.5.1. Objetivo
Comprobar que el acceso remoto, tanto en direccionamiento IPv4 como IPv6, hacia un enrutador cualquiera, funciona en perfectas condiciones, y que puede ser utilizado para la realización de configuraciones en dichos enrutadores.
183
5.1.5.2. Descripción
Una de las situaciones más comunes en el ambiente de enrutamiento es el acceso remoto hacia los enrutadores, que permite la solución de errores o añadir configuraciones adicionales a los mismos. Para esto se tienen algunas alternativas de las cuales las más comunes son telnet y ssh 37. En esta práctica se va a plantear un escenario sencillo de enrutamiento, donde se va a acceder remotamente a un enrutador para poder configurar algunos de sus parámetros. El escenario planteado va a estar definido en primera instancia para direccionamiento IPv4 y luego para direccionamiento IPv6. 5.1.5.2.1. Parte A: Acceso remoto con direccionamiento IPv4
Para esta parte de la práctica se plantea el escenario que se puede observar en la Figura 5-10, donde también se incluye el esquema de direccionamiento IPv4. Además de esto se tiene configurado el protocolo de enrutamiento RIP a través del demonio ripd en los 3 enrutadores y lo que se pretende es acceder remotamente al enrutador A desde el usuario 2 y configurar parámetros básicos del mismo como descripción de las interfaces. La aplicación a utilizar para el acceso remoto será telnet.
Figura 5-10. Escenario Práctica 5.a
37
Secure Shell (ssh) es un protocolo y una herramienta que permiten el acceso remoto a un
equipo que dispone de esta aplicación y que a diferencia de telnet, permite que los datos que se transmiten viajen de manera cifrada. También este protocolo puede ser utilizado para la transferencia de archivos de forma segura.
184
5.1.5.2.2. Parte B: Acceso remoto con direccionamiento IPv6
Se requiere configurar el enrutador C desde el usuario 1 como se muestra en la Figura 5-11. El escenario tiene un direccionamiento IPv6 y el protocolo de enrutamiento configurado es RIPng a través del demonio ripngd. La aplicación a utilizarse para este caso es ssh. Los cambios a hacerse en el enrutador son las contraseñas de acceso.
Figura 5-11. Escenario Práctica 5.b
5.1.5.3. Desarrollo 5.1.5.3.1. Desarrollo Parte A
El escenario de la Figura 5-10 está configurado con RIP y se la realiza como se indicó en el capítulo cuarto; se pueden observar los archivos de configuración de Zebra y de ripd en el Anexo D. Para el acceso remoto con telnet es necesario crear un usuario en el computador a través del cual se va a acceder, por motivos de seguridad 38, ya que telnet es un 38
Acceder con la cuenta de root utilizando telnet es algo que se pretende evitar, ya que los datos viajan en claro; si alguien escucha estos datos puede acceder al equipo con fines maliciosos a través de esta cuenta que tiene todos los privilegios del equipo.
185
protocolo inseguro porque los datos viajan en claro. Para la creación del usuario en el equipo Linux se hace lo siguiente: # useradd remoto
Es necesario crear una contraseña de acceso al equipo para este usuario, y esto se lo hace de la siguiente manera: # passwd remoto Changing password for user remoto. New UNIX password: XXXXXXXX Retype new UNIX password: XXXXXXXX passwd: all authentication tokens updated successfully #
El servicio de telnet debe estar habilitado y para poder tener el acceso remoto desde cualquier equipo, es necesario instalarlo; el paquete de instalación se lo encuentra en los discos del sistema operativo. Una vez instalado, se procede a acceder remotamente al enrutador A desde el usuario 2 de la siguiente manera: USUARIO2# telnet 200.1.1.1 Trying 200.1.1.1… Conected to 200.1.1.1 (200.1.1.1). Escape carácter is ‘^]’ . login: remoto Password: XXXXXXXX
[email protected]$
Cuando se ha accedido remotamente se procede a trabajar como si se estuviera en el enrutador local, es decir se accede al modo de configuración del demonio Zebra y se puede hacer los cambios necesarios; en este caso en particular se van a poner descripciones a las interfaces de la siguiente manera:
[email protected]$ telnet localhost zebra Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification
186
Password: A> enable Password: A# A# configure terminal A(config)# interface eth0 A(config-if)# description A(config-if)# description HACIA USUARIO 1 A(config-if)# interface eth1 A(config-if)# description HACIA ENRUTADOR B A(config-if)# exit A(config)#
Para salir del equipo remoto solo se necesita estar en el promptuario del equipo Linux y digitar exit de la siguiente manera: A(config)# exit A# exit Connection closed by foreig host
[email protected]$ exit Connection closed by foreig host #
5.1.5.3.2. Desarrollo Parte B
En la Figura 5-11, se puede observar un escenario con direccionamiento IPv6 en el cual se va a realizar una configuración remota utilizando ssh. La configuración se hace desde el usuario 1 al enrutador C, y se van a modificar las contraseñas y el nombre del usuario en el demonio Zebra. El enrutamiento entre los enrutadores es RIPng y se configura como se indicó en el capítulo anterior. En el Anexo D se puede observar cómo se encuentra los archivos de configuración del demonio Zebra y ripngd de cada enrutador. Para acceder remotamente con ssh es necesario que el paquete esté instalado y el servicio esté activo. Luego de esto, por motivos de seguridad en el enrutador C se va a crear un usuario para el acceso, esto se lo hace de la siguiente manera: # useradd remoto
Es necesario crear una contraseña de acceso al equipo para este usuario, y esto se lo hace de la siguiente manera:
187
# passwd remoto Changing password for user remoto. New UNIX password: XXXXXXXX Retype new UNIX password: XXXXXXXX passwd: all authentication tokens updated successfully #
En el usuario 1 se va a acceder utilizando ssh como se muestra a continuación, teniendo en cuenta que en la primera vez que se acceda se hace el intercambio de las llaves de autenticación: # ssh remoto@2006::2 The authenticity of host '2006::2 (2006::2)' can't be established. RSA key fingerprint is f5:4d:85:04:4f:fd:65:0a:46:f3:73:40:e0:6e:67:30. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '2006::2' (RSA) to the list of known hosts. remoto@2006::2's password: remoto@2006::2$
Después de haber accedido remotamente se procede a configurar el enrutador como si se estuviera trabajando localmente; para este caso en particular se va a cambiar nombre del enrutador y las contraseñas de acceso como se muestra a continuación: remoto@2006::2$ telnet localhost zebra Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. Hello, this is Quagga (version 0.99.4). Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification Password: C> enable Password: C# configure terminal C(config)# C(config)# password acceso C(config)# enable password acceso C(config)# C(config)# hostname CAMBIO_DE_NOMBRE CAMBIO_DE_NOMBRE(config)# CAMBIO_DE_NOMBRE(config)#exit CAMBIO_DE_NOMBRE#
Para salir de la sesión de acceso remoto a través de ssh es necesario digitar exit en el promptuario del equipo Linux de la siguiente manera:
188
remoto@2006::2$ exit Connection to 2006::2 closed. #
5.1.6. PRÁCTICA 6: PRUEBAS CON TRANSFERENCIA DE ARCHIVOS 5.1.6.1. Objetivo
Realizar una transferencia de archivos entre usuarios que pasan a través de un ambiente de enrutamiento. 5.1.6.2. Descripción
Una de las aplicaciones más utilizadas actualmente sobre todo en el mundo del Internet es el ftp que es empleando para la transferencia de archivos aunque pueden utilizarse otras aplicaciones como ssh. Para la presente práctica utiliza ftp como aplicación para la transferencia de archivos, con el escenario que se muestra en la Figura 5-12.
Figura 5-12. Escenario Práctica 6
189
En el escenario se tiene planteado un esquema con protocolo de enrutamiento BGP, simulando un ambiente del Internet. Se requiere transferir un archivo desde el servidor al usuario 1. 5.1.6.3. Desarrollo
Para configurar un ambiente BGP se puede seguir las instrucciones presentadas en el capítulo anterior; y, los archivos de configuración pertenecientes a este escenario se los puede encontrar en el Anexo D. Para las pruebas de ftp se va a levantar este servidor con la ayuda de la herramienta vsftpd que es uno de lo más populares en el ambiente Linux y uno de los más utilizados, la instalación de este servidor es bastante sencilla y se la puede encontrar en la página oficial del mismo http://vsftpd.beasts.org. Para la prueba se van a establecer 4 conexiones ftp desde el usuario 1 hacia el servidor FTP, y se van descargar archivos diferentes en cada una de las conexiones. Los resultados esperados es la transferencia de los archivos pasando por el ambiente de enrutamiento sin tener ningún problema. El usuario de acceso será prueba y la contraseña prueba. El acceso al servidor vía ftp se lo realiza como se muestra a continuación, tomando en cuenta que se necesitarán 4 terminales de Linux 39 para tener 4 conexiones diferentes. ot@localhost ~]# ftp 172.16.60.1 Connected to 172.16.60.1. 220 SERVIDOR FTP PARA PRUEBAS DE QUAGGA. 530 Please login with USER and PASS. 530 Please login with USER and PASS. KERBEROS_V4 rejected as an authentication type Name (172.16.60.1:root): prueba 331 Please specify the password. Password:XXXXXX
39
Para cambiar entre terminales en un ambiente de consola de Linux se utiliza Alt+F1 para el primer Terminal, Alt+F2 para el segundo Terminal, Alt+F3 para tercer Terminal y así sucesivamente.
190
230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp>
Se pueden ver que las conexiones se han establecido verificando en el servidor de la siguiente manera: SERVER_FTP# netstat tcp 0 0 LISTEN tcp 0 0 LISTEN tcp 0 76744 ESTABLISHED tcp 0 0 ESTABLISHED tcp 0 0 ESTABLISHED tcp 0 0 ESTABLISHED tcp 0 0 ESTABLISHED SERVER_FTP#
-anult | grep 21 172.16.60.1:7021
0.0.0.0:*
0.0.0.0:21
0.0.0.0:*
172.16.60.1:7021
172.16.20.1:55011
172.16.60.1:21
172.16.20.1:49448
172.16.60.1:21
172.16.20.1:49450
172.16.60.1:21
172.16.20.1:49446
172.16.60.1:21
172.16.20.1:49447
Las conexiones fueron exitosas y se hicieron pruebas con transferencias de archivos que resultaron de igual manera exitosas. 5.1.7. PRÁCTICA 7: CONTROL DETALLADO DE ACCESO 5.1.7.1. Objetivo
Establecer políticas de acceso en los enrutadores para el filtrado de tráfico de determinadas aplicaciones. 5.1.7.2. Descripción
Como se mencionó en la práctica 4 iptables es una herramienta muy poderosa para el control de acceso. Es por eso que se pretende utilizar esta herramienta para establecer políticas de acceso de determinado tipo de tráfico, ya sea de un destino a otro o al mismo enrutador; en otras palabras, se pretende filtrar tráfico de determinadas aplicaciones como ftp de un sitio a otro o aplicaciones como
191
telnet de un sitio al enrutador. Para este propósito se ha definido el escenario de enrutamiento que se muestra en la Figura 5-13.
Figura 5-13. Escenario Práctica 7
Los enrutadores se encuentran configurados con el protocolo de enrutamiento RIP y las políticas se definen a continuación:
El usuario A es el único que debe acceder a los enrutadores vía telnet El usuario B tiene levantado un servidor FTP y a él deben tener acceso solo los usuarios D y C El usuario B no debe tener comunicación con el usuario C Solo el usuario C puede administrar vía ssh el enrutador Y El usuario B tiene levantado un sitio Web y a él solo debe tener acceso el usuario D No se debe permitir hacer ping a por las interfaces eth1 a los enrutadores. Todo el tráfico que no consta en esta lista debe ser aceptado
192
5.1.7.3. Desarrollo
El escenario muestra una configuración entre 2 enrutadores utilizando el protocolo RIP, para esto se utiliza el demonio zebra y ripd como se indicó en el capítulo anterior; los archivos respectivos de configuración se los puede apreciar en el Anexo D. Para hacer el control de acceso como indican las reglas propuestas es necesario iniciar iptables en el enrutador X y en el enrutador Y de la siguiente manera: # service iptables start
Para que iptables se inicie siempre que se reinicie el computador se digita el siguiente comando: # chkcongig iptables on
Para facilidad de configuración se crea un script en cada enrutador con las políticas a utilizarse; el script para el enrutador X se muestra a continuación, tomando en cuenta que las líneas que empiezan con “ #” son comentarios y brindan una breve explicación de cada una de las sentencias: #!/bin/sh # Script para el enrutador X # Se borran políticas previamente configuradas en caso de que existieran iptables -t nat -F iptables -F iptables -X #La #La #La #La #La #La #La #La #La #La #La #La #La #La
opción opción opción opción opción opción opción opción opción opción opción opción opcion opción
–P envía la sentencia al final del conjunto de reglas –A envía la sentencia al inicio del conjunto de reglas INPUT se refiere al tráfico de entrada OUTPUT se refiere al tráfico de salida FORWARD se refiere a tráfico reenviado de una interface a otra ACCEPT acepta el tráfico DROP descarta el tráfico –s se refiere a la dirección de origen –d se refiere a la dirección de destino –i se refiere a la interfaz de entrada –o se refiere a la interfaz de salida –-dport se refiere al puerto de destino –-sport se refiere al puerto de origen –j indica qué hacer si la regla coincide con la situación
193
#(-j DROP o –j ACCEPT) #Se establecen las políticas por defecto iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT #solo el usuario A puede hacer telnet al enrutador X #La siguiente regla descarta todo el tráfico tcp cuyo origen es #cualquiera excepto la dirección 192.168.10.1 si el destino es hacia el #puerto 23. iptables -A INPUT -s ! 192.168.10.1 -p tcp --dport 23 -j DROP #La siguiente regla descarta todo el tráfico tcp cuyo destino es #cualquiera excepto la dirección 192.168.10.1 si puerto de origen es #el 23 iptables -A OUTPUT -d ! 192.168.10.1 -p tcp --sport 23 -j DROP #el usuario A no puede hacer ftp al usuario B #la siguiente regla no reenvía de una interfaz a otra si el origen es de #la dirección 192.168.10.1 y el destino es la dirección 172.16.0.1 #y si el puerto de destino es el 21 iptables -A FORWARD -s 192.168.10.1 -d 172.16.0.1 -p tcp --dport 21 –j DROP #el usuario C no debe tener comunicación con el usuario B #La siguiente regla no reenvía el todo el tráfico que va desde la máquina #con dirección 200.0.0.1 hacia la máquina con dirección 172.16.0.1 iptables -A FORWARD -s 200.0.0.1 -d 172.16.0.1 -j DROP #no se permite hacer ping por las interfaces eth1 a los enrutadores #Las siguientes dos líneas descartan el tráfico icmp de entrada y salida #hacia el enrutador que ingresa por la interfaz eth1 iptables -A INPUT -i eth1 -p icmp -j DROP iptables -A OUTPUT -o eth1 -p icmp -j DROP
Por otro lado el script para el enrutador Y se muestra a continuación: #!/bin/sh # Script para enrutador Y # Se borran políticas previamente configuradas en caso de que existieran iptables -t nat -F iptables -F iptables –X #La #La #La #La #La #La #La #La #La #La #La #La
opción opción opción opción opción opción opción opción opción opción opción opción
–P envía la sentencia al final del conjunto de reglas –A envía la sentencia al inicio del conjunto de reglas INPUT se refiere al tráfico de entrada OUTPUT se refiere al tráfico de salida FORWARD se refiere a tráfico reenviado de una interface a otra ACCEPT acepta el tráfico DROP descarta el tráfico –s se refiere a la dirección de origen –d se refiere a la dirección de destino –i se refiere a la interfaz de entrada –o se refiere a la interfaz de salida –-dport se refiere al puerto de destino
194
#La opcion –-sport se refiere al puerto de origen #La opción –j indica qué hacer si la regla coincide con la situación #(-j DROP o –j ACCEPT) #Se establecen las políticas por defecto iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT #Solo el usuario A puede hacer telnet al enrutador Y #La siguiente regla descarta el tráfico tcp de entrada desde cualquier #dirección excepto la 192.168.10.1 si el puerto de destino es el 23 iptables -A INPUT -s ! 192.168.10.1 -p tcp --dport 23 -j DROP #La siguiente regla descarta el tráfico tcp de salida hacia cualquier #destino excepto la dirección 192.168.10.1 si el puerto de origen es 23 iptables -A OUTPUT -d ! 192.168.10.1 -p tcp --sport 23 -j DROP #El usuario B no debe tener comunicación con el usuario C #La siguiente regla no reenvía el tráfico de una interfaz a otra si el #origen es la dirección 172.16.0.1 y el destino es la dirección 200.0.0.1 iptables -A FORWARD -s 172.16.0.1 -d 200.0.0.1 -j DROP #solo el usuario C puede administrar vía ssh el enrutador Y #La siguiente regla descarta el tráfico tcp entrante cuyo origen es #cualquier dirección excepto la dirección 200.0.0.1 y si el puerto de #destino es 22 iptables -A INPUT -s ! 200.0.0.1 -p tcp --dport 22 -j DROP #La siguiente regla descarta el tráfico tcp saliente cuyo destino es #cualquier dirección excepto la dirección 200.0.0.1 y si el puerto de #origen es 22 iptables -A OUTPUT -d ! 200.0.0.1 -p tcp --sport 22 -j DROP #Solo el usuario D puede acceder al sitio web del usuario B #La siguiente regla descarta el reenvío de una interfaz a otra si el #origen es cuelquier dirección excepto la 10.0.0.1 y el destino es la #dirección 172.16.0.1 iptables -A FORWARD -s ! 10.0.0.1 -d 172.16.0.1 -j DROP #no se permite hacer ping por las interfaces eth1 a los enrutadores #Las siguientes dos líneas descartan el tráfico icmp de entrada y salida #hacia el enrutador que ingresa por la interfaz eth1 iptables -A INPUT -i eth1 -p icmp -j DROP iptables -A OUTPUT -o eth1 -p icmp -j DROP
Para ejecutar el script se hace lo siguiente: # chmod 777 script # ./script
Esto va a permitir que las reglas se apliquen; ahora es necesario guardarlas para que no se borren cuando se reinicie el sistema, para esto se ejecuta lo siguiente:
195
# service iptables save
Luego de esto se hacen las pruebas correspondientes donde se tienen los resultados que se puede apreciar en la Tabla 5-2. Regla
Resultado
El usuario A es el único que debe acceder a los enrutadores vía telnet
OK
El usuario B tiene levantado un servidor FTP y debe tener solo acceso los usuarios D y C
OK
El usuario B no debe tener comunicación con el usuario C
OK
Solo el usuario C puede administrar vía ssh el enrutador Y
OK
El usuario B tiene levantado un sitio Web y solo debe tener acceso el usuario D
OK
No se debe permitir hacer ping por las interfaces eth1 a los enrutadores
OK
Todo el tráfico que no consta en esta lista debe ser aceptado
OK
Tabla 5-2. Resultados Práctica 7
5.1.8. PRÁCTICA 8: CONFIGURACIÓN DE UN ENLACE PPP 5.1.8.1. Objetivo
Realizar la configuración de un enlace PPP entre dos computadores configurados como enrutadores utilizando interfaces RS-232, y realizar pruebas de enrutamiento básico utilizando enrutamiento estático. 5.1.8.2. Descripción
El protocolo PPP permite establecer comunicación a nivel de enlace en una red de datos, y se utiliza mucho para establecer conexiones con ISPs a través de módems telefónicos, aunque puede ser utilizado con tecnologías de banda ancha.
196
La presente práctica pretende establecer un enlace PPP entre dos enrutadores y realizar un enrutamiento estático; para esto se utilizará la interfaz RS-232 de los computadores dispuestos como enrutadores a través de una conexión nullmodem. En la Figura 5-14 se puede apreciar cóomo se encuentra estructurado este escenario.
P P P e a c l n E
Figura 5-14. Escenario Práctica 8
Se pretende establecer comunicación entre el Usuario 1 y el Usuario 2, después de haber configurado el enlace PPP que se encuentra permanente conectado. 5.1.8.3. Desarrollo
Se necesita configurar el enlace PPP, que en este caso en particular va a ser un enlace permanente que se necesita inicializar siempre que se reinicie el equipo a través de una conexión null-modem. Para esto se necesita modificar el archivo /etc/inittab añadiendo las siguientes opciones en cada enrutador: En el enrutador A # s0:2345:respawn:/usr/sbin/pppd –detach noauth crtscts 192.168.1.1:192.168.1.2 /dev/ttyS0 38400
197
En el enrutador B # s0:2345:respawn:/usr/sbin/pppd –detach noauth crtscts 192.168.1.2:192.168.1.1 /dev/ttyS0 38400
Luego es necesario verificar que el archive /etc/ppp/options solo tenga la opción lock.
Para que cada enrutador vuelva a leer el archivo inittab es necesario ejecutar lo siguiente en cada uno de los enrutadores: # kill –HUP 1
Se verifica que el enlace se encuentre establecido mediante ifconfig de la siguiente manera: # ifconfig ppp0 ppp0 Link encap:Point-to-Point Protocol inet addr:192.168.1.1 P-t-P:192.168.1.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:790 errors:0 dropped:0 overruns:0 frame:0 TX packets:853 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:49096 (47.9 KiB) TX bytes:52600 (51.3 KiB) #
Si se ha creado una nueva conexión llamada ppp0 con las características presentadas quiere decir que la conexión se ha establecido. Este enlace se va a inicializar siempre que se reinicien los equipos ya que es un enlace permanente. Por otro lado, luego de haber establecido este enlace se procede a configurar el demonio Zebra para la asignación de direcciones a las interfaces Ethernet. El enlace PPP ya tiene asignado su propio direccionamiento, por lo que lo que se procede a realizar la configuración de las rutas estáticas, de la siguiente manera: Enrutador A ROUTER_PPP_A(config)# ip route 192.168.20.0/24 192.168.1.2
198
Enrutador B ROUTER_PPP_B(config)# ip route 172.16.0.0/16 192.168.1.1
Para comprobar la conectividad se utiliza el utilitario ping desde cualquiera de los usuarios hacia el otro de la siguiente manera: USUARIO1# ping -c 8 192.168.20.1 PING 192.168.20.1 (192.168.20.1) 56(84) bytes 64 bytes from 192.168.20.1: icmp_seq=1 ttl=62 64 bytes from 192.168.20.1: icmp_seq=2 ttl=62 64 bytes from 192.168.20.1: icmp_seq=3 ttl=62 64 bytes from 192.168.20.1: icmp_seq=4 ttl=62 64 bytes from 192.168.20.1: icmp_seq=5 ttl=62 64 bytes from 192.168.20.1: icmp_seq=6 ttl=62 64 bytes from 192.168.20.1: icmp_seq=7 ttl=62 64 bytes from 192.168.20.1: icmp_seq=8 ttl=62
of data. time=83.1 time=38.2 time=31.8 time=30.2 time=29.6 time=33.8 time=41.8 time=40.7
ms ms ms ms ms ms ms ms
--- 192.168.20.1 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 7012ms rtt min/avg/max/mdev = 29.674/41.200/83.131/16.437 ms USUARIO2#
Para verificar la ruta se utiliza el utilitario traceroute para comprobar la ruta establecida desde un usuario hacia el otro. USUARIO1# traceroute 192.168.20.1 traceroute to 192.168.20.1 (192.168.20.1), 30 hops max, 40 byte packets 1 172.16.0.2 (172.16.0.2) 0.349 ms 0.172 ms 0.066 ms 2 192.168.1.2 (192.168.1.2) 76.515 ms 88.593 ms 115.074 ms 3 192.168.20.1 (192.168.20.1)(H!) 151.163 ms (H!) 159.148 ms (H!) 163.940 ms USUARIO2#
Los archivos de configuración de cada uno de los enrutadores se los puede apreciar en el Anexo D. 5.1.9. PRÁCTICA 9: TROUBLESHOOTING 5.1.9.1. Objetivo
Mostrar formas de solución de problemas con los enrutadores basados en Linux a través del paquete de enrutamiento Quagga
199
5.1.9.2. Descripción
Para la solución de problemas es necesario conocer cómo se encuentra estructurada la red de datos y el propósito del enrutamiento: además es importante tener claras cuáles son las políticas de acceso en determinado escenario. Una de las primeras indicaciones para la solución de problemas es revisar la parte física, es decir verificar que las conexiones estén bien realizadas, que los componentes de hardware se encuentren en buenas condiciones y sobre todo que sus componentes de hardware estén funcionando adecuadamente. Cuando se tiene problemas que no son de hardware se tienen que considerar las configuraciones lógicas; es decir lo primero que se debe hacer en una comprobación de configuración es verificar si las interfaces se encuentran levantadas y configuradas con el direccionamiento requerido. El siguiente paso es verificar las configuraciones de los protocolos de enrutamientos, las tablas de rutas, las listas de control de acceso, los servicios, y por último los archivos de logs, que son aquellos donde se almacena toda la información concerniente a determinado demonio. Esta práctica pretende describir los principales comandos y configuraciones para la comprobación de errores y problemas en determinado escenario de enrutamiento. 5.1.9.3. Desarrollo 5.1.9.3.1. Verificación del estado de las interfaces
Para comprobar el estado de una interfaz, solo basta con escribir el siguiente comando en el modo de privilegios del demonio zebra: ROUTER# show interfaces
200
Para verificar la configuración y comprobar que la misma esté correcta solo basta con digitar el siguiente comando en el modo de privilegios ROUTER# show running-config
Para verificar tablas de enrutamiento es necesario digitar el siguiente comando en el modo de privilegios ROUTER# show ip route
Para la verificación de los archivos de logs se debe definir en el demonio Zebra de la siguiente manera y se debe elegir el tipo de logs que se quiere tener: ROUTER# configure terminal ROUTER(config)# log file /var/log/quagga/zebra.log ROUTER(config)# log monitor emergencies
--→
nivel de log que se desea
También se puede configurar este archivo para ver eventos, paquetes de Zebra o paquetes del kernel, esto se consigue con el siguiente comando ROUTER(config)# debug zebra (events|packet|kernel)
Todas estas opciones pueden ser útiles para la solución de problemas, aunque también pueden ser útiles utilitarios como ping y ping6 para la comprobación de conectividad entre dos puntos; traceroute para la comprobación de la ruta por la que el paquete transita, y telnet para la verificación de las 7 capas del modelo OSI, y comprobar que una aplicación funciona en perfectas condiciones. Respecto al control de acceso hay que ser muy minucioso en la revisión del mismo, y sobre todo hay que tener en cuenta que para el control de acceso no solo existe una forma para hacer una política, sino que pueden existir varias, eso va a depender de la habilidad de quien las configura: lo importante está en saber cómo analizar los problemas y tratar de buscar soluciones a los mismos.
201
5.2. ANÁLISIS DE LOS RESULTADOS OBTENIDOS Las prácticas presentadas en este capítulo para la utilización de enrutadores basados en Linux con el paquete Quagga, han permitido demostrar una gran utilidad en el medio del enrutamiento, y permiten además comprobar el funcionamiento adecuado de estos protocolos con la ayuda de sus respectivos demonios. Las pruebas realizadas a cada protocolo y escenario planteado para las prácticas fueron exitosas, dando resultados positivos; se comprueba además que el objetivo de estos enrutadores basados en Linux cumple con las expectativas planteadas. Es importante destacar que las prácticas fueron posibles realizarlas en un mismo computador gracias a la ayuda de máquinas virtuales con VMware Server las cuales permitieron emular ambientes completos de enrutamiento. Además como resultado se tuvo una gran experiencia en el manejo de este paquete ante diferentes situaciones, tomando en cuenta soluciones de errores y cómo pueden ser útiles herramientas adicionales que complementan al paquete Quagga en su función principal de enrutar. Se pudo observar además que se pueden plantear muchos escenarios distintos, pero lo que se pretendía con las mismas es dar una idea muy clara de la utilidad de los protocolos de enrutamiento su funcionamiento y sobre todo dar a notar que se pueden realizar prácticas en ambientes reales sin la necesidad de tener varios equipos costosos como son los enrutadores de marca, sino pudiendo reemplazar éstos por equipos de bajo costo.
5.3. PRÁCTICAS UTILIZANDO SIMULADORES Hay que destacar que para ambientes muy grandes de enrutamiento donde se necesitan emular redes muy complejas y con muchos equipos es mejor utilizar
202
simuladores, ya que con máquinas virtuales se necesitaría un computador con características muy buenas, lo que elevaría en cierta manera costos. Además, con los simuladores se pueden tener otro tipo de experiencias, como determinadas configuraciones que no se pueden hacer con el paquete Quagga, como la configuración de un switch que suelen ser útiles en determinados escenarios. Por otra parte todas las prácticas realizadas con los enrutadores Quagga pueden ser elaboradas con simuladores teniendo resultados similares. Además como se habló en el capítulo 3, los simuladores suelen ser muy útiles para fines didácticos y educativos, y por lo tanto que tienen gran acogida; por este motivo y a diferencia de hacerlo con Quagga, no son máquinas reales sino solo son programas que simulan situaciones de enrutamiento. Por otro lado algunos simuladores tienen incluidos entre los protocolos de enrutamientos a aquellos que son propietarios como son IGRP y EIGRP. A continuación se presentan algunas prácticas utilizando simuladores con situaciones que no se pueden implementar con Quagga. 5.3.1. PRÁCTICA A: CONFIGURACIÓN DE IGRP 5.3.1.1. Objetivo
Realizar la configuración de un escenario sencillo IGRP con la utilización de un simulador. 5.3.1.2. Descripción
Se tiene un escenario de dos usuarios y dos enrutadores en los cuales se debe configurar el protocolo de enrutamiento IGRP como se muestra en la Figura 5-15. El simulador a utilizarse para la elaboración de esta práctica es Boson NetSim ya que es imprescindible que los equipos a utilizarse dentro de este simulador sean equipos Cisco debido a que los protocolos son propietarios de esta empresa.
203
Boson Netsim es una alternativa didáctica para simular escenarios de configuración de equipos Cisco.
Figura 5-15. Escenario Práctica A
Con esta práctica se pretende describir de una manera muy sencilla la configuración del protocolo IGRP con la ayuda de enrutadores, tomando en cuenta que el ambiente no es real. IGRP es un protocolo que no soporta VLSM por lo que es necesrio utilizar redes con clases, sin considerar el subneting . 5.3.1.3. Desarrollo
La configuración del enrutador A se la realiza de la siguiente manera: Router> enable Router# configure terminal Router(config)# interface ethernet 0 Router(config-if)# ip address 192.168.50.1 255.255.255.0 Router(config-if)# no shutdown Router(config-if)# interface ethernet 1 Router(config-if)# ip address 172.16.20.1 255.255.0.0 Router(config-if)# no shutdown Router(config)# router igrp 100 Router(config-router)# network 192.168.50.0 Router(config-router)# network 172.16.0.0 Router(config-router)# exit Router(config)# exit Router#
El enrutador B en cambio se configura de la siguiente manera: Router> enable
204
Router# configure terminal Router(config)# interface ethernet 0 Router(config-if)# ip address 192.168.50.2 255.255.255.0 Router(config-if)# no shutdown Router(config-if)# interface ethernet 1 Router(config-if)# ip address 172.17.10.1 255.255.0.0 Router(config-if)# no shutdown Router(config)# router igrp 100 Router(config-router)# network 192.168.50.0 Router(config-router)# network 172.17.0.0 Router(config-router)# exit Router(config)# exit Router#
Luego de configurados los enrutadores se realizaron pruebas de conectividad, con lo cual se obtuvieron los siguientes resultados: Desde el usuario 1 al usuario 2 C:>ping 172.17.10.2 Pinging 172.17.10.2 with 32 bytes of data: Reply Reply Reply Reply Reply
from from from from from
172.17.10.2: 172.17.10.2: 172.17.10.2: 172.17.10.2: 172.17.10.2:
bytes=32 bytes=32 bytes=32 bytes=32 bytes=32
time=60ms time=60ms time=60ms time=60ms time=60ms
TTL=241 TTL=241 TTL=241 TTL=241 TTL=241
Ping statistics for 172.17.10.2: Packets: Sent = 5, Received = 5, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 50ms, Maximum = 60ms, Average = 55ms C:>tracert 172.17.10.2
"Type escape sequence to abort." Tracing the route to 172.17.10.2 1 172.16.20.1 0 msec 16 msec 0 msec 2 192.168.50.2 20 msec 16 msec 16 msec 3 172.17.10.2 20 msec 16 msec * C:>
Desde el usuario 2 al usuario 1 C:>ping 172.16.20.2 Pinging 172.16.20.1 with 32 bytes of data: Reply Reply Reply Reply Reply
from from from from from
172.16.20.2: 172.16.20.2: 172.16.20.2: 172.16.20.2: 172.16.20.2:
bytes=32 bytes=32 bytes=32 bytes=32 bytes=32
time=60ms time=60ms time=60ms time=60ms time=60ms
TTL=241 TTL=241 TTL=241 TTL=241 TTL=241
205
Ping statistics for 172.16.20.2: Packets: Sent = 5, Received = 5, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 50ms, Maximum = 60ms, Average = 55ms C:>tracert 172.16.20.2
"Type escape sequence to abort." Tracing the route to 172.16.20.2 1 172.17.10.1 0 msec 16 msec 0 msec 2 192.168.50.1 20 msec 16 msec 16 msec 3 172.16.20.2 20 msec 16 msec * C:>
Se produjo la conectividad entre los usuarios y se pudo observar el funcionamiento de este protocolo. 5.3.2. PRÁCTICA B: CONFIGURACIÓN DE EIGRP 5.3.2.1. Objetivo
Configurar el protocolo de enrutamiento EIGRP en un simulador para el escenario propuesto. 5.3.2.2. Descripción
La configuración del protocolo EIGRP es muy similar a la configuración del protocolo IGRP, por lo que se va a plantear el mismo escenario anterior para la configuración pero con un cambio en el direccionamiento del enlace entre los enrutadores pues aquí se utilizará VLSM. Este escenario se lo puede observar en la Figura 5-16. De igual manera que en la práctica anterior se utilizará Boson NetSim para realizar esta simulación.
206
Figura 5-16. Escenario Práctica B
Se pretende con este protocolo establecer conectividad entre los usuarios 1 y 2. 5.3.2.3. Desarrollo
La configuración del enrutador A se la realiza de la siguiente manera Router> enable Router# configure terminal Router(config)# Router(config)# interface ethernet 0 Router(config-if)# Router(config-if)# ip address 192.168.50.1 255.255.255.252 Router(config-if)# Router(config-if)# no shutdown Router(config-if)# interface ethernet 1 Router(config-if)# Router(config-if)# ip address 172.16.20.1 255.255.0.0 Router(config-if)# Router(config-if)# no shutdown Router(config)# Router(config)# router eigrp 100 Router(config-router)# Router(config-router)# network 192.168.50.0 Router(config-router)# Router(config-router)# network 172.16.0.0 Router(config-router)# Router(config-router)# exit Router(config)# Router(config)# exit Router#
El enrutador B en cambio se configura de la siguiente manera: Router> enable Router# configure terminal Router(config)# Router(config)# interface ethernet 0 Router(config-if)# Router(config-if)# ip address 192.168.50.2 255.255.255.252 Router(config-if)# Router(config-if)# no shutdown Router(config-if)# interface ethernet 1 Router(config-if)# Router(config-if)# ip address 172.17.10.1 255.255.0.0 Router(config-if)# Router(config-if)# no shutdown Router(config)# Router(config)# router eigrp 100 Router(config-router)# Router(config-router)# network 192.168.50.0 Router(config-router)# Router(config-router)# network 172.17.0.0 Router(config-router)# Router(config-router)# exit Router(config)# Router(config)# exit Router#
207
Luego de configurados los enrutadores se realizaron pruebas de conectividad, con lo cual se obtuvieron los siguientes resultados: Desde el usuario 1 hacia el usuario 2 C:>ping 172.17.10.2 Pinging 172.17.10.2 with 32 bytes of data: Reply Reply Reply Reply Reply
from from from from from
172.17.10.2: 172.17.10.2: 172.17.10.2: 172.17.10.2: 172.17.10.2:
bytes=32 bytes=32 bytes=32 bytes=32 bytes=32
time=60ms time=60ms time=60ms time=60ms time=60ms
TTL=241 TTL=241 TTL=241 TTL=241 TTL=241
Ping statistics for 172.17.10.2: Packets: Sent = 5, Received = 5, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 50ms, Maximum = 60ms, Average = 55ms C:>tracert 172.17.10.2
"Type escape sequence to abort." Tracing the route to 172.17.10.2 1 172.16.20.1 0 msec 16 msec 0 msec 2 192.168.50.2 20 msec 16 msec 16 msec 3 172.17.10.2 20 msec 16 msec * C:>
Desde el usuario 2 al usuario 1 C:>ping 172.16.20.2 Pinging 172.16.20.2 with 32 bytes of data: Reply Reply Reply Reply Reply
from from from from from
172.16.20.2: 172.16.20.2: 172.16.20.2: 172.16.20.2: 172.16.20.2:
bytes=32 bytes=32 bytes=32 bytes=32 bytes=32
time=60ms time=60ms time=60ms time=60ms time=60ms
TTL=241 TTL=241 TTL=241 TTL=241 TTL=241
Ping statistics for 172.16.20.2: Packets: Sent = 5, Received = 5, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 50ms, Maximum = 60ms, Average = 55ms C:>tracert 172.16.20.2
"Type escape sequence to abort." Tracing the route to 172.16.20.2 1 172.17.10.1 0 msec 16 msec 0 msec 2 192.168.50.1 20 msec 16 msec 16 msec 3 172.16.20.2 20 msec 16 msec *
208
C:>
Las pruebas de conectividad y de rutas fueron exitosas, lo que demuestra la función principal del protocolo se ha cumplido.
REFERENCIAS CAPÍTULO 5 [1]
ISHIGURO, Kunihiro, Kunihiro, Quagga, A routing software package for TCP/IP networks, Julio 2006
[2]
IBM, Linux System Administration I: Implementation, IBM, Noviembre 2005
[3]
IBM, Linux Power User, IBM, Septiembre 2005
[4]
IBM, Linux Network Administration Administration I: TCP/IP and TCP/IP services, IBM, Octubre 2005
[5]
IBM, Linux Network Administration Administration II: Security and Firewalls, IBM, Noviembre 2004
[6]
COLLADO, Eduardo, Eduardo, Cisco CCNA – CCNP http://www.eduangi.com/documentos Último acceso: 2007 – 08 – 16
[7]
CISCO Systems, Programa de la academia de Networking Networkin g de CISCO, 2003
[8]
Zebra http://www.zebra.org Último acceso: 2007 – 08 – 16
[9]
Quagga
209
http://www.quagga.net Último acceso: 2007 – 08 – 16 [10]
Galli Granada, Ricardo. Iptables y NAT http://bulma.net/body.phtml?nIdNoticia=1522 Último acceso: 2007 – 08 – 30
[11]
Linux Firewalls Using iptables http://www.linuxhomenetworkin http://www.linuxhomenetworking.com/wiki/inde g.com/wiki/index.php/Quick_ x.php/Quick_HOWTO_:_ HOWTO_:_ Ch14_:_Linux_Firewalls_Using_iptables Último acceso: 2007 – 08 – 30
CAPÍTULO 6 CONCLUSIONES Y RECOMENDACIONES
210
CAPÍTULO 6. CONCLUSIONES Y RECOMENDACIONES
Este capítulo comprende las conclusiones del presente proyecto de titulación tomando en cuenta todos los aspectos previamente desarrollados, así como también se incluyen las recomendaciones pertinentes para que en lo futuro se pueda mejorar este proyecto.
6.1. CONCLUSIONES 1. Actualmente Linux es uno de los sistemas operativos más destacados debido a su gran versatilidad y funcionalidad frente a otras soluciones; además cada día que pasa aumenta la tendencia a utilizar sistemas que sean de código abierto, ya sea debido a que los costos se reducen o debido a que simplemente son sistemas más robustos. Otro punto importante que se puede destacar respecto a Linux es la gran cantidad de soporte que se encuentra disponible actualmente, y sobre todo la gran cantidad de información que se puede encontrar ya sea en libros o en el Internet que es el lugar donde se encuentra la información más actual referente a estos temas, además de las comunidades existentes a nivel mundial para tratar de corregir y solucionar problemas referente a sistemas de este tipo. 2. Conjuntamente a los sistemas operativos de código abierto se encuentran las aplicaciones de código abierto, que brindan gran funcionalidad en situaciones específicas con buenos resultados y sobre todo a bajos costos; estas herramientas permiten al usuario tener un control más detallado de las mismas con opciones de personalización o adaptabilidad a necesidades particulares. De igual manera se tiene como característica importante, el soporte y la gran cantidad de información que se puede encontrar.
211
3. Entre las herramientas de código abierto para enrutamiento más destacadas se encuentra el paquete Quagga, debido a que su ambiente de configuración de consola es muy parecido al que se tiene en los enrutadores comerciales Cisco. Este ambiente de configuración permite a los usuarios familiarizados con entornos de enrutamiento configurar enrutadores basados en Quagga de una manera sencilla; por otro lado las personas que no están familiarizadas con este tipo de equipos podrán aprender a hacerlo fácilmente, inclusive si no se tiene conocimientos muy avanzados de Linux, pues éste es un paquete fácil de instalar, de ejecutarlo y sobre todo de configurarlo. Además existe gran cantidad de información, sobre todo en Internet, respecto a la utilización y manejo de este paquete. Por otro lado al ser una herramienta de código abierto se puede adaptar la misma al gusto y necesidad del usuario. 4. Las características de hardware para la instalación de Quagga dependen de los requerimientos básicos del sistema operativo sobre el cual va a funcionar; para este proyecto de titulación se planteó hacer la configuración con Fedora Core 5 como sistema operativo, lo que limita el hardware a un computador Pentium 1. Por otro lado es importante destacar que se debe tener un claro conocimiento del hardware sobre el cual se va a instalar el sistema operativo para poder realizar una adecuada compilación del kernel, lo que va a permitir que el arranque del sistema operativo sea más rápido, así como también va a servir para que no se carguen módulos que son innecesarios en memoria. 5. En este proyecto de titulación se utilizaron tarjetas FastEthernet como interfaces para interconectar los enrutadores entre si y los enrutadores con los usuarios finales, sin embargo es posible utilizar otro tipo de tarjetas para diferentes tecnologías sin ningún problema, ya que el paquete Quagga no discrimina el tipo de tarjeta sino que trabaja a nivel de las interfaces activas. La instalación de las tarjetas va a depender de las características específicas de las mismas, aunque es importante resaltar que dichas tarjetas deben ser compatibles con Linux. Cabe destacar además que actualmente la tendencia en tecnologías WAN es el manejo de enrutamiento IP sobre Ethernet como es el caso de Metro-Ethernet.
212
6. Dentro de ambientes de laboratorio, se puede utilizar este paquete de enrutamiento con fines didácticos debido a que pueden ser instalados sobre cualquier computador con las características mínimas mencionadas, y se pueden establecer diferentes tipos de escenarios con el fin de entender de mejor manera el funcionamiento de los diferentes protocolos de enrutamiento soportados por Quagga. Además con la ayuda de las herramientas de virtualización, y si las características de hardware lo permiten, se pueden establecer escenarios de enrutamiento en un mismo computador. 7. Se ha comprobado que se pueden manejar los protocolos de enrutamiento tanto para direccionamiento IPv4 como para direccionamiento IPv6, lo cual es muy ventajoso debido a que poco a poco toda la estructura IPv4 montada actualmente va a ir migrando a un direccionamiento Ipv6. En la actualidad la tendencia mundial va orientada a uno migración total del direccionamiento IPv4 al direccionamiento IPv6, con lo cual se tiene cubierto este sector debido al soporte que brinda Linux y específicamente el paquete Quagga al direccionamiento IPv6. 8. Este enrutador al poder ser implementado sobre un sistema operativo de libre distribución y bajo herramientas de código abierto, así como también en computadores de bajas características, tiene un precio bajo, siendo una solución viable el momento de implementarlo dentro de una red pequeña o mediana. Hay que recalcar que este enrutador no pretende reemplazar a enrutadores de grandes características como son los enrutadores Cisco, sino más bien está planteado como una alternativa de bajo costo y de buen funcionamiento ante escenarios de enrutamiento. Además en el presente proyecto de titulación se lo ha planteado también como una solución de bajo costo para el aprendizaje de los protocolos de enrutamiento en ambientes de laboratorio. 9. La utilización de máquinas virtuales para la realización de este proyecto ha sido un factor importante, ya que se ha podido trabajar con varios equipos virtuales para establecer los diferentes escenarios de enrutamiento en un
213
mismo computador; también se han podido establecer escenarios utilizando varios computadores anfitriones y máquinas virtuales invitadas. Estas opciones van a permitir que la implementación de escenarios de enrutamiento en un laboratorio de computación sea más sencilla y que no se tenga que cambiar las configuraciones de los equipos anfitriones. 10. Los simuladores son herramientas válidas para el aprendizaje de los protocolos de enrutamiento pero lamentablemente son aplicaciones con licenciamiento y tienen costos relativamente elevados para ser adquiridos sobre todo aquellos que manejan la mayoría de protocolos de enrutamiento así como también el direccionamiento Ipv6. Es por eso que se plantea como alternativa la utilización de enrutadores basados en software con herramientas de libe distribución ya que pueden llegar a cumplir las expectativas planteadas. Por otro lado estos enrutadores permiten la elaboración de escenarios de enrutamiento reales y no solo simulados, lo cual es muy ventajoso ya que se puede interactuar directamente con situaciones reales y también se pueden complementar con otro tipo de aplicaciones para analizar diferentes comportamientos; es decir que se pueden utilizar servidores, o aplicaciones que permitan verificar su funcionamiento dentro de ambientes reales de enrutamiento sin necesidad de invertir tanto dinero en aquello. 11. Una ventaja de los simuladores frente a los enrutadores basados en software, cuando se trata de motivos de aprendizaje, es que los simuladores como el Boson NetSim si permite establecer escenarios con protocolos propietarios como IGRP y EIGRP; con ello se podría analizar su funcionamiento y su configuración. 12. El paquete de enrutamiento Quagga puede complementarse con herramientas de igual manera de código abierto, como Iptables, para convertirse en un sistema mucho más robusto y completo. 13. En las prácticas desarrolladas en el capítulo 5 se pudo observar el funcionamiento de los protocolos de enrutamiento implementados a través de
214
Quagga. Estas prácticas demuestran que estos enrutadores pueden ser implementados en ambientes reales sin ningún problema. Además se pudo constatar que las aplicaciones implementadas extremo a extremo como es el caso del servidor FTP y su usuario fueron exitosas, es decir que se pudieron ejecutar sin ningún problema dentro del ambiente de enrutamiento; también se pudo constatar que el acceso remoto funciona en buenas condiciones tanto en Ipv4 como en Ipv6. 14. Las características y funciones de un enrutador Quagga son comparables a las de un enrutador comercial (por ejemplo Cisco) aunque no se obtengan todas las funciones que ellos presentan. Esta carencia de determinadas funciones se las puede complementar con paquetes adicionales que se los puede configurar en Linux. Por otro lado hay características de un enrutador comercial que no se pueden incluir como por ejemplo PoE ( Power over Ethernet ) o protocolos propietarios. 15. El precio del Enrutador Quagga es bajo comparable al de un equipo Cisco que tienen características similares, aunque es importante destacar que el desempeño de una solución frente a otra es diferente por el mismo hecho de que los enrutadores comerciales son desarrollados para ese propósito en específico.
6.2. RECOMENDACIONES 1. Sería importante complementar este tipo de enrutadores basados en software con herramientas para control de ancho de banda y calidad de servicio, ya que dentro de una red pueden existir distintos tipos de tráfico, y si se quieren garantizar el correcto desempeño de determinadas aplicaciones que manejan por ejemplo voz o video se necesita establecer políticas de manejo de paquetes de acuerdo al tipo. El control de ancho de banda y calidad de servicio también se lo puede hacer a través de Linux de igual manera con herramientas de código abierto, lo cual sería muy útil para complementar y robustecer el enrutador.
215
2. Se recomienda tener en cuenta que un enrutador por si solo representa un punto de falla y se podría considerar este tipo de enrutadores basados en software como soluciones alternativas de redundancia o soluciones de contingencia ante eventuales fallos. 3. Se recomienda realizar el estudio de soluciones de acceso remoto bajo Linux como complemento a estos enrutadores basados en software para que en conjunto se llegue a una solución mucho más integral. En general se pretende integrar varias herramientas de código abierto para cumplir con todas las expectativas que debe disponer un equipo de enrutamiento básico y así también darle mucha mayor funcionalidad. 4. Se recomienda el uso de simuladores comerciales como el OPNET, pues es una herramienta muy interesante y muy buena para la realización de diseños de redes. Esta herramienta permite analizar el comportamiento de las redes ante situaciones determinadas, lo que permite y facilita el diseño de las mismas. Al simular el comportamiento de redes con este simulador se conseguiría reducir fallas el momento de diseños, sobre todo si estos son de gran magnitud.
216
BIBLIOGRAFÍA 1.
TANENBAUM, Andrews S., Redes de Computadoras. Cuarta Edición. Prentice Hall. 2003
2.
STALLINGS, William, Comunicaciones y Redes de Computadoras. Séptima Edición. Prentice Hall. 2004
3.
HALABI, Sam; McPHERSON, Danny, Arquitecturas de Enrutamiento en Internet. Segunda Edición. Cisco Systems. 2001
4.
NUTT, Gary; Sistemas Operativos. Tercera Edición. Pearson.
5.
CARRETERO, Jesús; GARCÍA, Félix; ANASAGASTI, Pedro de Miguel; PÉREZ, Fernando, Sistemas Operativos – Una visión aplicada. McGraw Hill. Primera Edición. 2001
6.
TACKETT, Jack; GUNTER, David. Linux. Tercera Edición. Prentice Hall.
7.
IBM, Linux System Administration I: Implementation, IBM Certified Course Material, Noviembre 2005
8.
IBM, Linux Power User, IBM Certified Course Material, Septiembre 2005
9.
IBM, Linux Network Administration I: TCP/IP and TCP/IP services, IBM Certified Course Material, Octubre 2005
10.
IBM, Linux Network Administration II: Security and Firewalls, IBM Certified Course Material, Noviembre 2004
11.
IBM, Linux System Administration I: Implementation, IBM Certified Course Material, Noviembre 2005
12.
IBM, Linux Power User, IBM Certified Course Material, Septiembre 2005
13.
IBM, Linux Network Administration I: TCP/IP and TCP/IP services, IBM Certified Course Material, Octubre 2005
217
14.
IBM, Linux Network Administration II: Security and Firewalls, IBM Certified Course Material, Noviembre 2004
15.
NEGUS, Christopher, Linux Bible. Willy Publishing. 2005
16.
CISCO Systems, Programa de la academia de Networking de CISCO, 2003
17.
ISHIGURO, Kunihiro, Quagga, A routing software package for TCP/IP networks, Julio 2006
18.
MANN, Anthony; The Racional Guide to Microsoft Virtual PC 2004. Rarional Press. 2004
19.
FERNANDEZ, Óscar; Virtualización con Microsoft Virtual PC 2007. Primera Edición. 2007
20.
SHAVERS, Brett, Restoring Suspect Physical and Compressed Images with VMware. Computer Technology Investigators Network.
REFERENCIAS ELECTRÓNICAS 1.
Zebra, http://www.zebra.org
2.
Quagga, http://www.quagga.net
3.
FREESCO, http://www.freesco.org
4.
LEAF, http://leaf.sourceforge.net
5.
GATED, http://www.gated.org
6.
XORP, http://www.xorp.org
7.
Galli Granada, Ricardo. Iptables y NAT, http://bulma.net/body.phtml?nIdNoticia=1522
218
8.
Linux Firewalls Using iptables, http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_C h14_:_Linux_Firewalls_Using_iptables
9.
ANÓNIMO, Redes y servicios, http://trajano.us.es/~isabel/publicaciones/OSI.pdf
10.
COLLADO, Eduardo, Cisco CCNA – CCNP, http://www.eduangi.com/documentos
11.
Fedora Proyect, http://fedoraproject.org
12.
White Paper: Cisco IOS Reference Guide, http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_white _paper09186a008018305e.shtml
13.
Windows Vista, http://www.microsoft.com/spain/windows/default.mspx
14.
Fundamentos del enrutamiento TCP/IP para Windows NT, http://support.microsoft.com/kb/140859/es
15.
Instalación de enrutador biblioteca de red multiprotocolo y configuración, http://support.microsoft.com/kb/138793/es
16.
Routing and Remote Access, http://www.microsoft.com/technet/network/rras/default.mspx
17.
Análisis Virtualización: Menos complejidad, mayor rendimiento, http://www.cientec.com/analisis/Virtualizacion.asp
18.
BARAHONA, Eugenio; Virtualización o cómo disponer de más de un ordenador virtual sobre uno físico, 2006, http://www.idg.es/pcworldtech/mostrarArticulo.asp?id=292761308&seccio n=infraestructura,
19.
Sistemas Operativos Avanzados, Máquinas Virtuales, http://www.arcos.inf.uc3m.es/~jdaniel/seminars.html
ANEXO A RECOMPILACIÓN DEL KERNEL
A-1
ANEXO A Recompilación del Kernel Para recompilar el kernel de Linux es necesario seguir los siguientes pasos: 1. Descarga del paquete binario
El paquete binario del kernel se lo puede encontrar en el Internet en varios sitos web, aunque oficialmente se lo encuentra en la página www.kernel.org; en esta página se puede encontrar la versión más actual del kernel así como también se pueden encontrar versiones anteriores que en algunos casos suelen ser útiles. Es importante que el kernel que se va a utilizar sea el adecuado, es decir que tenga el soporte a los dispositivos que se requieren; por eso generalmente la recomendación es utilizar un kernel actual ya que viene con soporte a los últimos dispositivos en el mercado. El archivo descargado tiene un formato de la siguiente manera linux- version .tar.gz o también puede ser linux- version .tar.bz2. 2. Descompresión del paquete binario
Previa a la descompresión del paquete se debe ubicarse en el directorio de la descompresión, este directorio es el /usr/src/. El acceso a este directorio se lo hace de la siguiente manera: # cd /usr/src/
Si el archivo tiene el formato linux- version .tar.gz se aplica el siguiente comando: # tar –zxvf linux-version.tar.gz
Si el archivo es del formato linux- version .tar.bz2 se aplica el siguiente comando:
A-2
# tar –jxvf linux-version.tar.bz2
Luego se procede a ubicarse en el directorio creado donde se descomprimió el paquete de la siguiente manera: # cd /usr/src/linux-version/
En este directorio se encuentran todos los archivos del kernel y la información necesaria para su compilación. 3. Limpiar configuraciones previas
Para asegurarse de que configuraciones previas puedan haber sido realizadas en el paquete descomprimido se utiliza el siguiente comando: # make mrproper
Este comando asegura que todas las configuraciones previas han sido eliminadas definitivamente del directorio donde se encuentra el kernel a compilar. 4. Configurar el kernel
Para configurar el kernel se tienen 3 opciones las cuales pueden ser usadas de acuerdo a las características del sistema operativo. Estas opciones permiten elegir que elementos se van a instalar en el kernel, es decir el soporte a determinados protocolos, elementos de hardware, etc. va a tener el nuevo kernel. Es importante tener claro lo que se necesita específicamente en el equipo ya que una de las razones para que se compile el kernel es darle el soporte a los dispositivos necesarios y eliminar aquel que no se necesite lo que va a permitir que el arranque del sistema sea más rápido y que no se consuman recursos en elementos innecesarios para determinado propósito. Si se ha hecho una instalación del sistema operativo mínima es probable que la única opción de configuración sea la de preguntas y respuestas en modo de texto que se la consigue a través del comando: # make config
A-3
Para tener un menú de texto y poder elegir de una manera más sencilla los componentes a instalarse en el kernel se puede utilizar el siguiente comando: # make menuconfig
En la Figura A-1 se puede apreciar el formato del menú que se tiene con este tipo de configuración:
Figura A-1. Menú de texto para configuración del kernel
Si se dispone de un modo gráfico se puede tener un menú en formato gráfico que permitirá de igual manera una configuración más fácil y sencilla, este menú se lo obtiene a través del siguiente comando: # make xconfig
En la Figura A-2 se puede apreciar el menú gráfico que nos presenta el comando anterior. Cualquiera de las tres opciones anteriores generan un archivo llamado .config que se encuentra dentro del directorio /usr/src/linux-version/ y que contiene toda la
A-4
información que se ha seleccionado para la compilación, es decir que en este archivo se encuentran las opciones que se escogieron para que estén disponibles en el kernel.
Figura A-2. Menú gráfico para compilación del kernel
5. Compilar el kernel
Previa la compilación es necesario limpiar archivos temporales que se puedan encontrar en el directorio resultado de previas compilaciones, esto se lo consigue con el comando: # make clean
Luego se procede a revisar las dependencias para ver si se necesita algo previa la compilación. # make dep
La compilación se la realiza con el comando: # make bzImage
Este comando es el encargado de compilar el kernel con la información establecida en el archivo .config. Este comando crea un archivo en el directorio
A-5
/usr/src/linux-version /arch/i386/boot/ llamado bzImage; esta es la imagen del kernel a utilizarse. La operación de la compilación puede demorar una hora aproximadamente, dependiendo obviamente de las características del equipo. Luego para compilar los módulos seleccionados en la configuración se utiliza el comando: # make modules
De igual manera la ejecución de este comando puede tardar algunos minutos. Se puede hacer que los comandos descritos anteriormente se ejecuten todos de una sola vez utilizando la siguiente sentencia: # make clean dep bzImage modules.
6. Instalar el kernel
Hay que copiar la imagen del kernel compilado en el directorio /boot de la siguiente manera: # cp /usr/src/linux-version/arch/i386/boot/bzImage
/boot/vmlinuz-version
Luego se copia el archivo System.map 40 al directorio /boot de la siguiente manera: # cp /usr/src/linux-version/System.map /boot/System.map-version
Luego se procede a instalar los módulos del kernel de la siguiente manera: # make modules_install
40
System.map es un archivo que contiene la ubicación de las subrutinas del kernel e información que puede ser útil si se produce algún problema en el kernel para poder depurarlo .
A-6
Como siguiente paso se tiene que crear el disco inicial de raíz (initrd) que se crea en el directorio /boot de la siguiente forma: # cd /boot/ # mkinitrd initrd-version.img version
El último paso es configurar el GRUB para que el nuevo kernel pueda ser seleccionado o para que inicie por defecto, y para lograrlo hay que modificar el archivo /boot/grub/menu.lst. # vi /boot/grub/menu.lst
# grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/sda8 # initrd /initrd-version.img #boot=/dev/sda default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title ROUTER (version) root (hd0,0) kernel /vmlinuz-version ro root=LABEL=/ rhgb quiet initrd /initrd-version.img title Fedora Core (2.6.15-1.2054_FC5) root (hd0,0) kernel /vmlinuz-2.6.15-1.2054_FC5 ro root=LABEL=/ rhgb quiet initrd /initrd-2.6.15-1.2054_FC5.img
Las líneas resaltadas son la que se agregaron para que el kernel compilado conste en el menú del GRUB.
ANEXO B PRUEBAS DE LOS ESQUEMAS DE ENRUTAMIENTO
B-1
ANEXO B Pruebas de los esquemas de enrutamiento 1. Pruebas de funcionalidad del enrutamiento estático IPv4
El la Figura 4-4 se puede ver el escenario planteado para este tipo de enrutamiento, las pruebas se las elaboraron de la siguiente manera: 1.1.
Pruebas conectividad
Se procede a hacer pruebas utilizando ping desde el usuario 1 al usuario 2 previa la configuración del enrutamiento estático y viceversa de lo cual se tiene los siguientes resultados: Usuario 1 USUARIO1# ping -c 8 192.168.103.2 PING 192.168.103.2 (192.168.103.2) 56(84) From 192.168.101.1 icmp_seq=1 Destination From 192.168.101.1 icmp_seq=2 Destination From 192.168.101.1 icmp_seq=3 Destination From 192.168.101.1 icmp_seq=4 Destination From 192.168.101.1 icmp_seq=5 Destination From 192.168.101.1 icmp_seq=6 Destination From 192.168.101.1 icmp_seq=7 Destination From 192.168.101.1 icmp_seq=8 Destination
bytes of data. Net Unreachable Net Unreachable Net Unreachable Net Unreachable Net Unreachable Net Unreachable Net Unreachable Net Unreachable
--- 192.168.103.2 ping statistics --8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 7003ms USUARIO1#
Usuario 2 USUARIO2# ping -c 8 192.168.101.2 PING 192.168.101.2 (192.168.101.2) 56(84) From 192.168.103.1 icmp_seq=1 Destination From 192.168.103.1 icmp_seq=2 Destination From 192.168.103.1 icmp_seq=3 Destination From 192.168.103.1 icmp_seq=4 Destination From 192.168.103.1 icmp_seq=5 Destination From 192.168.103.1 icmp_seq=6 Destination From 192.168.103.1 icmp_seq=7 Destination From 192.168.103.1 icmp_seq=8 Destination
bytes of data. Net Unreachable Net Unreachable Net Unreachable Net Unreachable Net Unreachable Net Unreachable Net Unreachable Net Unreachable
B-2
--- 192.168.101.2 ping statistics --8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 7002ms USUARIO2#
Se observa que no existe conectividad entre los usuarios; ahora se realizan las pruebas después de haber configurado las rutas estáticas y se tienen los siguientes resultados: Usuario 1 USUARIO1# ping -c 8 192.168.103.2 PING 192.168.103.2 (192.168.103.2) 56(84) bytes of data. 64 bytes from 192.168.103.2: icmp_seq=1 ttl=62 time=19.0 ms 64 bytes from 192.168.103.2: icmp_seq=2 ttl=62 time=1.11 ms 64 bytes from 192.168.103.2: icmp_seq=3 ttl=62 time=0.940 ms 64 bytes from 192.168.103.2: icmp_seq=4 ttl=62 time=0.946 ms 64 bytes from 192.168.103.2: icmp_seq=5 ttl=62 time=0.904 ms 64 bytes from 192.168.103.2: icmp_seq=6 ttl=62 time=0.966 ms 64 bytes from 192.168.103.2: icmp_seq=7 ttl=62 time=0.825 ms 64 bytes from 192.168.103.2: icmp_seq=8 ttl=62 time=0.884 ms --- 192.168.103.2 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 7008ms rtt min/avg/max/mdev = 0.825/3.200/19.027/5.982 ms USUARIO1#
Usuario 2 USUARIO2# ping -c 8 192.168.101.2 PING 192.168.101.2 (192.168.101.2) 56(84) bytes of data. 64 bytes from 192.168.101.2: icmp_seq=1 ttl=62 time=3.75 ms 64 bytes from 192.168.101.2: icmp_seq=2 ttl=62 time=3.26 ms 64 bytes from 192.168.101.2: icmp_seq=3 ttl=62 time=3.67 ms 64 bytes from 192.168.101.2: icmp_seq=4 ttl=62 time=0.751 ms 64 bytes from 192.168.101.2: icmp_seq=5 ttl=62 time=1.05 ms 64 bytes from 192.168.101.2: icmp_seq=6 ttl=62 time=0.720 ms 64 bytes from 192.168.101.2: icmp_seq=7 ttl=62 time=0.686 ms 64 bytes from 192.168.101.2: icmp_seq=8 ttl=62 time=3.63 ms
--- 192.168.101.2 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 7003ms rtt min/avg/max/mdev = 0.686/2.193/3.758/1.400 ms USUARIO2#
Se puede observar que después de haber configurado los enrutadores se establece conectividad entre las dos redes de los dos usuarios.
B-3
1.2.
Pruebas de ruta
Se procede a probar el camino que toma el paquete ICMP a través del utilitario traceroute; previa la configuración del enrutamiento estático. Usuario 1 USUARIO1# traceroute 192.168.103.2 traceroute to 192.168.103.2 (192.168.103.2), 30 hops max, 40 byte packets 1 192.168.101.1 (192.168.101.1)(N!) 4.076 ms (N!) 2.467 ms (N!) 0.205 ms USUARIO1#
Usuario 2 USUARIO2# traceroute 192.168.101.2 traceroute to 192.168.101.2 (192.168.101.2), 30 hops max, 40 byte packets 1 192.168.103.1 (192.168.103.1)(N!) 0.240 ms (N!) 0.168 ms (N!) 0.127 ms USUARIO2#
Se puede observar que el paquete no llega a su destino; ahora se procede a configurar el enrutamiento estático y se realizan nuevamente las pruebas de ruta. Usuario 1 USUARIO1# traceroute 192.168.103.2 traceroute to 192.168.103.2 (192.168.103.2), 30 hops max, 40 byte packets 1 192.168.101.1 (192.168.101.1) 0.814 ms 0.000 ms 0.100 ms 2 192.168.102.2 (192.168.102.2) 7.838 ms 0.000 ms 0.589 ms 3 192.168.103.2 (192.168.103.2)(H!) 4.146 ms (H!) 4.063 ms (H!) 1.349 ms USUARIO1#
Usuario 2 USUARIO2# traceroute 192.168.101.2 traceroute to 192.168.101.2 (192.168.101.2), 30 hops max, 40 byte packets 1 192.168.103.1 (192.168.103.1) 0.442 ms 0.152 ms 0.105 ms 2 192.168.102.1 (192.168.102.1) 0.686 ms 0.183 ms 0.257 ms 3 192.168.101.2 (192.168.101.2)(H!) 1.692 ms (H!) 1.786 ms (H!) 0.594 ms USUARIO2#
Se puede observar que el paquete ICMP ha seguido el camino de los enrutadores configurados estáticamente.
B-4
2. Pruebas de funcionalidad del enrutamiento estático IPv6
En la Figura 4-5 se puede ver el escenario planteado para el enrutamiento estático con IPv6, las pruebas del mismo se las presenta a continuación: 2.1.
Pruebas conectividad
Las pruebas de conectividad para IPv6 se hacen utilizando el utilitario ping6, los resultados de estas pruebas se muestran a continuación: Usuario 1 USUARIO1# ping6 -c 8 2000:3::2 PING 2000:3::2(2000:3::2) 56 data bytes From 2000:1::1 icmp_seq=0 Destination unreachable: From 2000:1::1 icmp_seq=1 Destination unreachable: From 2000:1::1 icmp_seq=2 Destination unreachable: From 2000:1::1 icmp_seq=3 Destination unreachable: From 2000:1::1 icmp_seq=4 Destination unreachable: From 2000:1::1 icmp_seq=5 Destination unreachable: From 2000:1::1 icmp_seq=6 Destination unreachable: From 2000:1::1 icmp_seq=7 Destination unreachable:
No No No No No No No No
route route route route route route route route
--- 2000:3::2 ping statistics --8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 7005ms USUARIO1#
Usuario 2 USUARIO2# ping6 -c 8 2000:1::2 PING 2000:1::2(2000:1::2) 56 data bytes From 2000:3::1 icmp_seq=0 Destination unreachable: From 2000:3::1 icmp_seq=1 Destination unreachable: From 2000:3::1 icmp_seq=2 Destination unreachable: From 2000:3::1 icmp_seq=3 Destination unreachable: From 2000:3::1 icmp_seq=4 Destination unreachable: From 2000:3::1 icmp_seq=5 Destination unreachable: From 2000:3::1 icmp_seq=6 Destination unreachable: From 2000:3::1 icmp_seq=7 Destination unreachable:
No No No No No No No No
route route route route route route route route
--- 2000:1::2 ping statistics --8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 7000ms USUARIO2#
Después de haber configurado el enrutamiento estático con IPv6 se tienen las siguientes salidas:
B-5
Usuario 1 USUARIO1# ping6 -c 8 2000:3::2 PING 2000:3::2(2000:3::2) 56 data bytes 64 bytes from 2000:3::2: icmp_seq=0 ttl=62 64 bytes from 2000:3::2: icmp_seq=1 ttl=62 64 bytes from 2000:3::2: icmp_seq=2 ttl=62 64 bytes from 2000:3::2: icmp_seq=3 ttl=62 64 bytes from 2000:3::2: icmp_seq=4 ttl=62 64 bytes from 2000:3::2: icmp_seq=5 ttl=62 64 bytes from 2000:3::2: icmp_seq=6 ttl=62 64 bytes from 2000:3::2: icmp_seq=7 ttl=62
time=11.9 ms time=3.46 ms time=1.87 ms time=0.968 ms time=0.767 ms time=1.83 ms time=2.09 ms time=1.85 ms
--- 2000:3::2 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 7016ms rtt min/avg/max/mdev = 0.767/3.106/11.999/3.446 ms, pipe 2 USUARIO1#
Usuario 2 USUARIO2# ping6 -c 8 2000:1::2 PING 2000:1::2(2000:1::2) 56 data bytes 64 bytes from 2000:1::2: icmp_seq=0 ttl=62 64 bytes from 2000:1::2: icmp_seq=1 ttl=62 64 bytes from 2000:1::2: icmp_seq=2 ttl=62 64 bytes from 2000:1::2: icmp_seq=3 ttl=62 64 bytes from 2000:1::2: icmp_seq=4 ttl=62 64 bytes from 2000:1::2: icmp_seq=5 ttl=62 64 bytes from 2000:1::2: icmp_seq=6 ttl=62 64 bytes from 2000:1::2: icmp_seq=7 ttl=62
time=2.45 ms time=0.960 ms time=3.61 ms time=6.14 ms time=1.25 ms time=0.899 ms time=1.18 ms time=1.20 ms
--- 2000:1::2 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 7007ms rtt min/avg/max/mdev = 0.899/2.214/6.145/1.724 ms, pipe 2 USUARIO2#
Se puede observar que después configurado el enrutamiento estático se consiguió el propósito de comunicar el usuario 1 con el usuario 2. 2.2.
Pruebas de ruta
Se verifica la ruta que toma el paquete al ser enviado utilizando el utilitario traceroute previa la configuración de las rutas de la siguiente manera: Usuario 1 USUARIO1# traceroute 2000:3::2 traceroute to 2000:3::2 (2000:3::2), 30 hops max, 40 byte packets 1 2000:1::1 (2000:1::1)(N!) 0.061 ms (N!) 0.182 ms (N!) 0.164 ms USUARIO1#
B-6
Usuario 2 USUARIO2# traceroute 2000:1::2 traceroute to 2000:1::2 (2000:1::2), 30 hops max, 40 byte packets 1 2000:3::1 (2000:3::1)(N!) 0.380 ms (N!) 0.154 ms (N!) 0.103 ms USUARIO2#
Se configuran las rutas y se procede a comprobar el camino tomado por el paquete: Usuario 1 USUARIO1# traceroute 2000:3::2 traceroute to 2000:3::2 (2000:3::2), 30 hops max, 40 byte packets 1 2000:1::1 (2000:1::1) 0.294 ms 0.754 ms 0.162 ms 2 2000:2::2 (2000:2::2) 1.093 ms 0.782 ms 0.457 ms 3 2000:3::2 (2000:3::2) 1.991 ms 1.526 ms 0.913 ms USUARIO1#
Usuario 2 USUARIO2# traceroute 2000:1::2 traceroute to 2000:1::2 (2000:1::2), 30 hops max, 40 byte packets 1 2000:3::1 (2000:3::1) 0.214 ms 3.776 ms 0.533 ms 2 2000:2::1 (2000:2::1) 0.796 ms 0.000 ms 0.280 ms 3 2000:1::2 (2000:1::2) 5.569 ms 4.949 ms 1.824 ms USUARIO2#
3. Pruebas de funcionalidad del enrutamiento dinámico IPv4 con RIP
En la Figura 4-6 se puede ver el escenario planteado para el enrutamiento dinámico IPv4 con RIP, las pruebas del mismo se las presenta a continuación: 3.1.
Pruebas conectividad
Las pruebas de conectividad para enrutamiento dinámico IPv4 con RIP al igual que con los demás protocolos dinámicos que utilizan direccionamiento IPv4 se hacen utilizando el utilitario ping, los resultados de estas pruebas se muestran a continuación: Usuario 1 USUARIO1# ping -c 8 192.168.103.2 PING 192.168.103.2 (192.168.103.2) 56(84) bytes of data. From 192.168.101.1 icmp_seq=1 Destination Net Unreachable From 192.168.101.1 icmp_seq=2 Destination Net Unreachable
B-7
From From From From From From
192.168.101.1 192.168.101.1 192.168.101.1 192.168.101.1 192.168.101.1 192.168.101.1
icmp_seq=3 icmp_seq=4 icmp_seq=5 icmp_seq=6 icmp_seq=7 icmp_seq=8
Destination Destination Destination Destination Destination Destination
Net Net Net Net Net Net
Unreachable Unreachable Unreachable Unreachable Unreachable Unreachable
--- 192.168.103.2 ping statistics --8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 6999ms USUARIO1#
Usuario 2 USUARIO2# ping -c 8 192.168.101.2 PING 192.168.101.2 (192.168.101.2) 56(84) From 192.168.103.1 icmp_seq=1 Destination From 192.168.103.1 icmp_seq=2 Destination From 192.168.103.1 icmp_seq=3 Destination From 192.168.103.1 icmp_seq=4 Destination From 192.168.103.1 icmp_seq=5 Destination From 192.168.103.1 icmp_seq=6 Destination From 192.168.103.1 icmp_seq=7 Destination From 192.168.103.1 icmp_seq=8 Destination
bytes of data. Net Unreachable Net Unreachable Net Unreachable Net Unreachable Net Unreachable Net Unreachable Net Unreachable Net Unreachable
--- 192.168.101.2 ping statistics --8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 7004ms USUARIO2#
Después de haber configurado el enrutamiento dinámico con RIP a través del demonio ripd se tienen las siguientes salidas: Usuario 1 USUARIO1# ping -c 8 192.168.103.2 PING 192.168.103.2 (192.168.103.2) 56(84) bytes of data. 64 bytes from 192.168.103.2: icmp_seq=1 ttl=62 time=2.63 ms 64 bytes from 192.168.103.2: icmp_seq=2 ttl=62 time=0.770 ms 64 bytes from 192.168.103.2: icmp_seq=3 ttl=62 time=2.47 ms 64 bytes from 192.168.103.2: icmp_seq=4 ttl=62 time=0.736 ms 64 bytes from 192.168.103.2: icmp_seq=5 ttl=62 time=0.672 ms 64 bytes from 192.168.103.2: icmp_seq=6 ttl=62 time=0.770 ms 64 bytes from 192.168.103.2: icmp_seq=7 ttl=62 time=0.718 ms 64 bytes from 192.168.103.2: icmp_seq=8 ttl=62 time=1.08 ms --- 192.168.103.2 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 7008ms rtt min/avg/max/mdev = 0.672/1.233/2.638/0.775 ms USUARIO2#
B-8
Usuario 2 USUARIO2# ping -c 8 192.168.101.2 PING 192.168.101.2 (192.168.101.2) 56(84) bytes of data. 64 bytes from 192.168.101.2: icmp_seq=1 ttl=62 time=3.85 ms 64 bytes from 192.168.101.2: icmp_seq=2 ttl=62 time=3.54 ms 64 bytes from 192.168.101.2: icmp_seq=3 ttl=62 time=0.986 ms 64 bytes from 192.168.101.2: icmp_seq=4 ttl=62 time=0.783 ms 64 bytes from 192.168.101.2: icmp_seq=5 ttl=62 time=0.752 ms 64 bytes from 192.168.101.2: icmp_seq=6 ttl=62 time=0.670 ms 64 bytes from 192.168.101.2: icmp_seq=7 ttl=62 time=0.848 ms 64 bytes from 192.168.101.2: icmp_seq=8 ttl=62 time=0.836 ms --- 192.168.101.2 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 7005ms rtt min/avg/max/mdev = 0.670/1.534/3.853/1.254 ms USUARIO2#
Se puede observar que después configurado el enrutamiento dinámico con RIP se consiguió el propósito de comunicar el usuario 1 con el usuario 2. 3.2.
Pruebas de ruta
Se verifica la ruta que toma el paquete al ser enviado utilizando el utilitario traceroute previa la configuración de las rutas de la siguiente manera: Usuario 1 USUARIO1# traceroute 192.168.103.2 traceroute to 192.168.103.2 (192.168.103.2), 30 hops max, 40 byte packets 1 192.168.101.1 (192.168.101.1)(N!) 0.267 ms (N!) 0.109 ms (N!) 0.211 ms USUARIO1#
Usuario 2 USUARIO2# traceroute 192.168.101.2 traceroute to 192.168.101.2 (192.168.101.2), 30 hops max, 40 byte packets 1 192.168.103.1 (192.168.103.1)(N!) 0.245 ms (N!) 0.105 ms (N!) 0.196 ms USUARIO2#
Se configuran las rutas y se procede a comprobar el camino tomado por el paquete: Usuario 1 USUARIO1# traceroute 192.168.103.2 traceroute to 192.168.103.2 (192.168.103.2), 30 hops max, 40 byte packets 1 192.168.101.1 (192.168.101.1) 0.192 ms 0.103 ms 0.132 ms
B-9
2 192.168.102.2 (192.168.102.2) 4.119 ms 5.763 ms 1.075 ms 3 192.168.103.2 (192.168.103.2)(H!) 1.711 ms(H!) 0.811 ms(H!) 3.069 ms USUARIO1#
Usuario 2 USUARIO2# traceroute 192.168.101.2 traceroute to 192.168.101.2 (192.168.101.2), 30 hops max, 40 byte packets 1 192.168.103.1 (192.168.103.1) 0.000 ms 0.073 ms 3.402 ms 2 192.168.102.1 (192.168.102.1) 4.255 ms 1.465 ms 1.434 ms 3 192.168.101.2 (192.168.101.2)(H!) 7.412 ms(H!) 3.579 ms(H!) 3.094 ms USUARIO2#
4. Pruebas de funcionalidad del enrutamiento dinámico IPv6 con RIPng
Se puede observar en la Figura 4-7 el escenario planteado para el enrutamiento dinámico IPv6 con RIPng, las pruebas del mismo se las presenta a continuación: 4.1.
Pruebas conectividad
Las pruebas de conectividad para enrutamiento dinámico IPv6 con RIPng al igual que con los demás protocolos dinámicos que utilizan direccionamiento IPv6 se hacen utilizando el utilitario ping6, los resultados de estas pruebas se muestran a continuación: Usuario 1 USUARIO1# ping6 -c 8 2000:a::2 PING 2000:a::2(2000:a::2) 56 data bytes From 2000:1::1 icmp_seq=0 Destination unreachable: From 2000:1::1 icmp_seq=1 Destination unreachable: From 2000:1::1 icmp_seq=2 Destination unreachable: From 2000:1::1 icmp_seq=3 Destination unreachable: From 2000:1::1 icmp_seq=4 Destination unreachable: From 2000:1::1 icmp_seq=5 Destination unreachable: From 2000:1::1 icmp_seq=6 Destination unreachable: From 2000:1::1 icmp_seq=7 Destination unreachable:
No No No No No No No No
route route route route route route route route
--- 2000:a::2 ping statistics --8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 7001ms USUARIO1#
Usuario 2 USUARIO2# ping6 -c 8 2000:1::2 PING 2000:1::2(2000:1::2) 56 data bytes
B - 10
From From From From From From From From
2000:a::1 2000:a::1 2000:a::1 2000:a::1 2000:a::1 2000:a::1 2000:a::1 2000:a::1
icmp_seq=0 icmp_seq=1 icmp_seq=2 icmp_seq=3 icmp_seq=4 icmp_seq=5 icmp_seq=6 icmp_seq=7
Destination Destination Destination Destination Destination Destination Destination Destination
unreachable: unreachable: unreachable: unreachable: unreachable: unreachable: unreachable: unreachable:
No No No No No No No No
route route route route route route route route
--- 2000:1::2 ping statistics --8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 7002ms USUARIO2#
Después de haber configurado el enrutamiento dinámico con RIPng a través del demonio ripngd se tienen las siguientes salidas: Usuario 1 USUARIO1# ping6 -c 8 2000:a::2 PING 2000:a::2(2000:a::2) 56 data bytes 64 bytes from 2000:a::2: icmp_seq=0 ttl=61 64 bytes from 2000:a::2: icmp_seq=1 ttl=61 64 bytes from 2000:a::2: icmp_seq=2 ttl=61 64 bytes from 2000:a::2: icmp_seq=3 ttl=61 64 bytes from 2000:a::2: icmp_seq=4 ttl=61 64 bytes from 2000:a::2: icmp_seq=5 ttl=61 64 bytes from 2000:a::2: icmp_seq=6 ttl=61 64 bytes from 2000:a::2: icmp_seq=7 ttl=61
time=19.6 ms time=3.82 ms time=1.54 ms time=3.57 ms time=3.34 ms time=0.974 ms time=3.81 ms time=3.79 ms
--- 2000:a::2 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 7003ms rtt min/avg/max/mdev = 0.974/5.060/19.616/5.599 ms, pipe 2 USUARIO1#
Usuario 2 USUARIO2# ping6 -c 8 2000:1::2 PING 2000:1::2(2000:1::2) 56 data bytes 64 bytes from 2000:1::2: icmp_seq=0 ttl=61 64 bytes from 2000:1::2: icmp_seq=1 ttl=61 64 bytes from 2000:1::2: icmp_seq=2 ttl=61 64 bytes from 2000:1::2: icmp_seq=3 ttl=61 64 bytes from 2000:1::2: icmp_seq=4 ttl=61 64 bytes from 2000:1::2: icmp_seq=5 ttl=61 64 bytes from 2000:1::2: icmp_seq=6 ttl=61 64 bytes from 2000:1::2: icmp_seq=7 ttl=61
time=2.02 time=2.76 time=1.20 time=2.12 time=1.00 time=1.33 time=3.56 time=2.36
ms ms ms ms ms ms ms ms
--- 2000:1::2 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 7012ms rtt min/avg/max/mdev = 1.006/2.049/3.568/0.808 ms, pipe 2 USUARIO2#
B - 11
Se puede observar que después configurado el enrutamiento dinámico con RIPng se consiguió el propósito de comunicar el usuario 1 con el usuario 2. 4.2.
Pruebas de ruta
Se verifica la ruta que toma el paquete al ser enviado utilizando el utilitario traceroute previa la configuración de las rutas de la siguiente manera: Usuario 1 USUARIO1# traceroute 2000:a::2 traceroute to 2000:a::2 (2000:a::2), 30 hops max, 40 byte packets 1 2000:1::1 (2000:1::1)(N!) 0.000 ms (N!) 0.108 ms (N!) 0.253 ms USUARIO1#
Usuario 2 USUARIO2# traceroute 2000:1::2 traceroute to 2000:1::2 (2000:1::2), 30 hops max, 40 byte packets 1 2000:a::1 (2000:a::1)(N!) 0.274 ms (N!) 0.133 ms (N!) 0.162 ms USUARIO2#
Se configuran las rutas y comprueba el camino tomado por el paquete: Usuario 1 USUARIO1# traceroute 2000:a::2 traceroute to 2000:a::2 (2000:a::2), 30 hops max, 40 byte packets 1 2000:1::1 (2000:1::1) 0.333 ms 0.155 ms 0.140 ms 2 2000:2::2 (2000:2::2) 1.907 ms 2.004 ms 1.032 ms 3 2000:3::2 (2000:3::2) 1.614 ms 1.017 ms 3.593 ms 4 2000:a::2 (2000:a::2) 6.077 ms 2.521 ms 1.464 ms USUARIO1#
Usuario 2 USUARIO2# traceroute 2000:1::2 traceroute to 2000:1::2 (2000:1::2), 30 hops max, 40 byte packets 1 2000:a::1 (2000:a::1) 0.284 ms 0.129 ms 1.022 ms 2 2000:3::1 (2000:3::1) 1.135 ms 2.503 ms 2.773 ms 3 2000:2::1 (2000:2::1) 2.997 ms 0.476 ms 0.581 ms 4 2000:1::2 (2000:1::2) 2.318 ms 5.127 ms 3.533 ms USUARIO2#
B - 12
5. Pruebas de funcionalidad del enrutamiento dinámico IPv4 con OSPF
En la Figura 4-8 se puede ver el escenario planteado para el enrutamiento dinámico IPv4 con OSPF, las pruebas del mismo se las presenta a continuación: 5.1.
Pruebas conectividad
Las pruebas de conectividad para enrutamiento dinámico IPv4 con OSPF se hacen utilizando el utilitario ping, los resultados de estas pruebas se muestran a continuación: Usuario 1 USUARIO1# ping -c PING 172.16.41.12 From 172.168.40.1 From 172.168.40.1 From 172.168.40.1 From 172.168.40.1 From 172.168.40.1 From 172.168.40.1 From 172.168.40.1 From 172.168.40.1
8 172.16.41.12 (172.16.41.12) 56(84) bytes of data. icmp_seq=1 Destination Net Unreachable icmp_seq=2 Destination Net Unreachable icmp_seq=3 Destination Net Unreachable icmp_seq=4 Destination Net Unreachable icmp_seq=5 Destination Net Unreachable icmp_seq=6 Destination Net Unreachable icmp_seq=7 Destination Net Unreachable icmp_seq=8 Destination Net Unreachable
--- 172.16.41.12 ping statistics --8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 7000ms USUARIO1#
Usuario 2 USUARIO2# ping -c 8 172.16.40.2 PING 172.16.40.2 (172.16.40.2) 56(84) bytes of data. From 172.16.41.11 icmp_seq=1 Destination Net Unreachable From 172.16.41.11 icmp_seq=2 Destination Net Unreachable From 172.16.41.11 icmp_seq=3 Destination Net Unreachable From 172.16.41.11 icmp_seq=4 Destination Net Unreachable From 172.16.41.11 icmp_seq=5 Destination Net Unreachable From 172.16.41.11 icmp_seq=6 Destination Net Unreachable From 172.16.41.11 icmp_seq=7 Destination Net Unreachable From 172.16.41.11 icmp_seq=8 Destination Net Unreachable --- 172.16.40.2 ping statistics --8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 7001ms USUARIO2#
B - 13
Después de haber configurado el enrutamiento dinámico con OSPF a través del demonio ospfd se tienen las siguientes salidas: Usuario 1 USUARIO1# ping -c 8 172.16.41.12 PING 172.16.41.12 (172.16.41.12) 56(84) bytes 64 bytes from 172.16.41.12: icmp_seq=1 ttl=62 64 bytes from 172.16.41.12: icmp_seq=2 ttl=62 64 bytes from 172.16.41.12: icmp_seq=3 ttl=62 64 bytes from 172.16.41.12: icmp_seq=4 ttl=62 64 bytes from 172.16.41.12: icmp_seq=5 ttl=62 64 bytes from 172.16.41.12: icmp_seq=6 ttl=62 64 bytes from 172.16.41.12: icmp_seq=7 ttl=62 64 bytes from 172.16.41.12: icmp_seq=8 ttl=62
of data. time=32.6 time=1.04 time=1.10 time=1.15 time=1.98 time=2.12 time=1.05 time=3.01
ms ms ms ms ms ms ms ms
--- 172.16.41.12 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 7009ms rtt min/avg/max/mdev = 1.045/5.521/32.694/10.291 ms USUARIO1#
Usuario 2 USUARIO2# ping -c 8 172.16.40.2 PING 172.16.40.2 (172.16.40.2) 56(84) 64 bytes from 172.16.40.2: icmp_seq=1 64 bytes from 172.16.40.2: icmp_seq=2 64 bytes from 172.16.40.2: icmp_seq=3 64 bytes from 172.16.40.2: icmp_seq=4 64 bytes from 172.16.40.2: icmp_seq=5 64 bytes from 172.16.40.2: icmp_seq=6 64 bytes from 172.16.40.2: icmp_seq=7 64 bytes from 172.16.40.2: icmp_seq=8
bytes of data. ttl=62 time=5.44 ms ttl=62 time=1.40 ms ttl=62 time=1.30 ms ttl=62 time=1.07 ms ttl=62 time=0.752 ms ttl=62 time=1.42 ms ttl=62 time=1.15 ms ttl=62 time=1.22 ms
--- 172.16.40.2 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 7007ms rtt min/avg/max/mdev = 0.752/1.721/5.442/1.421 ms You have new mail in /var/spool/mail/root USUARIO2#
Se puede observar que después configurado el enrutamiento dinámico con OSPF se consiguió el propósito de comunicar el usuario 1 con el usuario 2. 5.2.
Pruebas de ruta
Se verifica la ruta que toma el paquete al ser enviado utilizando el utilitario traceroute previa la configuración de las rutas de la siguiente manera:
B - 14
Usuario 1 USUARIO1# traceroute 172.16.41.12 traceroute to 172.16.41.12 (172.16.41.12), 30 hops max, 40 byte packets 1 172.16.40.1 (172.16.40.1)(N!) 2.140 ms (N!) 5.761 ms (N!) 0.650 ms USUARIO1#
Usuario 2 USUARIO2# traceroute 172.16.40.2 traceroute to 172.16.40.2 (172.16.40.2), 30 hops max, 40 byte packets 1 172.16.41.11 (172.16.41.11)(N!) 7.624 ms (N!) 2.532 ms (N!) 1.133 ms USUARIO2#
Se configuran las rutas y se comprueba el camino tomado por el paquete: Usuario 1 USUARIO1# traceroute 172.16.41.12 traceroute to 172.16.41.12 (172.16.41.12), 30 hops max, 40 byte packets 1 172.16.40.1 (172.16.40.1) 0.770 ms 0.238 ms 0.221 ms 2 192.168.15.2 (192.168.15.2) 1.075 ms 0.540 ms 0.949 ms 3 172.16.41.12 (172.16.41.12)(H!) 15.587 ms(H!) 15.326 ms(H!) 13.177 ms USUSARIO1#
Usuario 2 USUARIO2# traceroute 172.16.40.2 traceroute to 172.16.40.2 (172.16.40.2), 30 1 172.16.41.11 (172.16.41.11) 0.613 ms 2 192.168.15.1 (192.168.15.1) 3.982 ms 3 172.16.40.2 (172.16.40.2)(H!) 3.919 ms USUARIO2#
hops max, 40 byte packets 0.118 ms 0.181 ms 0.568 ms 0.314 ms (H!) 0.588 ms (H!) 4.070 ms
6. Pruebas de funcionalidad del enrutamiento dinámico IPv6 con OSPFv3
Se puede observar en la Figura 4-9 el escenario planteado para el enrutamiento dinámico IPv6 con OSPFv3, las pruebas del mismo se las presenta a continuación: 6.1.
Pruebas conectividad
Las pruebas de conectividad para enrutamiento dinámico IPv6 con OSPFv3 se hacen utilizando el utilitario ping6, los resultados de estas pruebas se muestran a continuación:
B - 15
Usuario 1 USUARIO1# ping6 -c 8 2000:a::2 PING 2000:a::2(2000:a::2) 56 data bytes From 2000:1::1 icmp_seq=0 Destination unreachable: From 2000:1::1 icmp_seq=1 Destination unreachable: From 2000:1::1 icmp_seq=2 Destination unreachable: From 2000:1::1 icmp_seq=3 Destination unreachable: From 2000:1::1 icmp_seq=4 Destination unreachable: From 2000:1::1 icmp_seq=5 Destination unreachable: From 2000:1::1 icmp_seq=6 Destination unreachable: From 2000:1::1 icmp_seq=7 Destination unreachable:
No No No No No No No No
route route route route route route route route
--- 2000:a::2 ping statistics --8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 7001ms USUARIO1#
Usuario 2 USUARIO2# ping6 -c 8 2000:1::2 PING 2000:1::2(2000:1::2) 56 data bytes From 2000:a::1 icmp_seq=0 Destination unreachable: From 2000:a::1 icmp_seq=1 Destination unreachable: From 2000:a::1 icmp_seq=2 Destination unreachable: From 2000:a::1 icmp_seq=3 Destination unreachable: From 2000:a::1 icmp_seq=4 Destination unreachable: From 2000:a::1 icmp_seq=5 Destination unreachable: From 2000:a::1 icmp_seq=6 Destination unreachable: From 2000:a::1 icmp_seq=7 Destination unreachable:
No No No No No No No No
route route route route route route route route
--- 2000:1::2 ping statistics --8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 7008ms USUARIO2#
Después de haber configurado el enrutamiento dinámico con OSPFv3 a través del demonio ospf6d se tienen las siguientes salidas: Usuario 1 USUARIO1# ping6 -c 8 2000:a::2 PING 2000:a::2(2000:a::2) 56 data bytes 64 bytes from 2000:a::2: icmp_seq=0 ttl=61 64 bytes from 2000:a::2: icmp_seq=1 ttl=61 64 bytes from 2000:a::2: icmp_seq=2 ttl=61 64 bytes from 2000:a::2: icmp_seq=3 ttl=61 64 bytes from 2000:a::2: icmp_seq=4 ttl=61 64 bytes from 2000:a::2: icmp_seq=5 ttl=61 64 bytes from 2000:a::2: icmp_seq=6 ttl=61 64 bytes from 2000:a::2: icmp_seq=7 ttl=61
time=12.5 time=2.12 time=2.03 time=88.6 time=1.98 time=1.00 time=2.35 time=4.27
ms ms ms ms ms ms ms ms
--- 2000:a::2 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 7018ms
B - 16
rtt min/avg/max/mdev = 1.001/14.363/88.616/28.276 ms, pipe 2 USUARIO1#
Usuario 2 USUARIO2# ping6 -c 8 2000:1::2 PING 2000:1::2(2000:1::2) 56 data bytes 64 bytes from 2000:1::2: icmp_seq=0 ttl=61 64 bytes from 2000:1::2: icmp_seq=1 ttl=61 64 bytes from 2000:1::2: icmp_seq=2 ttl=61 64 bytes from 2000:1::2: icmp_seq=3 ttl=61 64 bytes from 2000:1::2: icmp_seq=4 ttl=61 64 bytes from 2000:1::2: icmp_seq=5 ttl=61 64 bytes from 2000:1::2: icmp_seq=6 ttl=61 64 bytes from 2000:1::2: icmp_seq=7 ttl=61
time=7.34 time=2.62 time=2.61 time=2.68 time=2.68 time=2.79 time=1.51 time=3.40
ms ms ms ms ms ms ms ms
--- 2000:1::2 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 7013ms rtt min/avg/max/mdev = 1.518/3.208/7.342/1.636 ms, pipe 2 USUARIO2#
Se puede observar que después configurado el enrutamiento dinámico con OSPFv3 se consiguió el propósito de comunicar el usuario 1 con el usuario 2. 6.2.
Pruebas de ruta
Se verifica la ruta que toma el paquete al ser enviado utilizando el utilitario traceroute previa la configuración de las rutas de la siguiente manera: Usuario 1 USUARIO1# traceroute 2000:a::2 traceroute to 2000:a::2 (2000:a::2), 30 hops max, 40 byte packets 1 2000:1::1 (2000:1::1)(N!) 0.000 ms (N!) 0.171 ms (N!) 2.209 ms USUARIO1#
Usuario 2 USUARIO2# traceroute 2000:1::2 traceroute to 2000:1::2 (2000:1::2), 30 hops max, 40 byte packets 1 2000:a::1 (2000:a::1)(N!) 4.961 ms (N!) 10.881 ms (N!) 45.620 ms USUARIO2#
Se configuran las rutas y se procede a comprobar el camino tomado por el paquete:
B - 17
Usuario 1 USUARIO1# traceroute 2000:a::2 traceroute to 2000:a::2 (2000:a::2), 30 hops max, 40 byte packets 1 2000:1::1 (2000:1::1) 6.622 ms 5.140 ms 2.761 ms 2 2000:2::2 (2000:2::2) 2.531 ms 1.752 ms 1.583 ms 3 2000:3::2 (2000:3::2) 5.961 ms 4.214 ms 3.756 ms 4 2000:a::2 (2000:a::2) 18.333 ms 18.217 ms 16.063 ms USUARIO1#
Usuario 2 USUARIO2# traceroute 2000:1::2 traceroute to 2000:1::2 (2000:1::2), 30 hops max, 40 byte packets 1 2000:a::1 (2000:a::1) 0.399 ms 0.191 ms 0.867 ms 2 2000:3::1 (2000:3::1) 0.775 ms 2.348 ms 0.467 ms 3 2000:2::1 (2000:2::1) 2.741 ms 0.422 ms 1.453 ms 4 2000:1::2 (2000:1::2) 5.475 ms 2.460 ms 7.111 ms USUARIO2#
7. Pruebas de funcionalidad del enrutamiento dinámico IPv4 con BGP
En la Figura 4-10 se puede ver el escenario planteado para el enrutamiento dinámico IPv4 con BGP, las pruebas del mismo se las presenta a continuación: 7.1.
Pruebas conectividad
Las pruebas de conectividad para enrutamiento dinámico IPv4 con BGP se hacen utilizando el utilitario ping, los resultados de estas pruebas se muestran a continuación: Usuario 1 USUARIO1# ping -c 8 172.16.60.1 PING 172.16.60.1 (172.16.60.1) 56(84) bytes From 172.16.20.2 icmp_seq=1 Destination Net From 172.16.20.2 icmp_seq=2 Destination Net From 172.16.20.2 icmp_seq=3 Destination Net From 172.16.20.2 icmp_seq=4 Destination Net From 172.16.20.2 icmp_seq=5 Destination Net From 172.16.20.2 icmp_seq=6 Destination Net From 172.16.20.2 icmp_seq=7 Destination Net From 172.16.20.2 icmp_seq=8 Destination Net
of data. Unreachable Unreachable Unreachable Unreachable Unreachable Unreachable Unreachable Unreachable
--- 172.16.60.1 ping statistics --8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 7002ms USUARIO1#
B - 18
Usuario 2 USUARIO2# ping -c 8 172.16.20.1 PING 172.16.20.1 (172.16.20.1) 56(84) bytes From 172.16.60.2 icmp_seq=1 Destination Net From 172.16.60.2 icmp_seq=2 Destination Net From 172.16.60.2 icmp_seq=3 Destination Net From 172.16.60.2 icmp_seq=4 Destination Net From 172.16.60.2 icmp_seq=5 Destination Net From 172.16.60.2 icmp_seq=6 Destination Net From 172.16.60.2 icmp_seq=7 Destination Net From 172.16.60.2 icmp_seq=8 Destination Net
of data. Unreachable Unreachable Unreachable Unreachable Unreachable Unreachable Unreachable Unreachable
--- 172.16.20.1 ping statistics --8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 7018ms USUARIO2#
Después de haber configurado el enrutamiento dinámico con BGP a través del demonio bgpd se tienen las siguientes salidas: Usuario 1 USUARIO1# ping -c 8 172.16.60.1 PING 172.16.60.1 (172.16.60.1) 56(84) bytes of data. 64 bytes from 172.16.60.1: icmp_seq=1 ttl=61 time=3.49 ms 64 bytes from 172.16.60.1: icmp_seq=2 ttl=61 time=3.77 ms 64 bytes from 172.16.60.1: icmp_seq=3 ttl=61 time=4.20 ms 64 bytes from 172.16.60.1: icmp_seq=4 ttl=61 time=3.73 ms 64 bytes from 172.16.60.1: icmp_seq=5 ttl=61 time=3.76 ms 64 bytes from 172.16.60.1: icmp_seq=6 ttl=61 time=3.63 ms 64 bytes from 172.16.60.1: icmp_seq=7 ttl=61 time=4.24 ms 64 bytes from 172.16.60.1: icmp_seq=8 ttl=61 time=3.75 ms --- 172.16.60.1 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 6999ms rtt min/avg/max/mdev = 3.499/3.826/4.248/0.246 ms USUARIO1#
Usuario 2 USUARIO2# ping -c 8 172.16.20.1 PING 172.16.20.1 (172.16.20.1) 56(84) 64 bytes from 172.16.20.1: icmp_seq=1 64 bytes from 172.16.20.1: icmp_seq=2 64 bytes from 172.16.20.1: icmp_seq=3 64 bytes from 172.16.20.1: icmp_seq=4 64 bytes from 172.16.20.1: icmp_seq=5 64 bytes from 172.16.20.1: icmp_seq=6 64 bytes from 172.16.20.1: icmp_seq=7 64 bytes from 172.16.20.1: icmp_seq=8
bytes of data. ttl=61 time=3.32 ttl=61 time=2.93 ttl=61 time=2.70 ttl=61 time=2.60 ttl=61 time=2.73 ttl=61 time=3.23 ttl=61 time=2.74 ttl=61 time=2.10
ms ms ms ms ms ms ms ms
--- 172.16.20.1 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 7021ms rtt min/avg/max/mdev = 2.105/2.796/3.322/0.362 ms USUARIO2#
B - 19
Se puede observar que después configurado el enrutamiento dinámico con BGP se consiguió el propósito de comunicar el usuario 1 con el usuario 2. 7.2.
Pruebas de ruta
Se verifica la ruta que toma el paquete al ser enviado utilizando el utilitario traceroute previa la configuración de las rutas de la siguiente manera: Usuario 1 USUARIO1# traceroute 172.16.60.1 traceroute to 172.16.60.1 (172.16.60.1), 30 hops max, 40 byte packets 1 172.16.20.2 (172.16.20.2)(N!) 3.412 ms (N!) 8.090 ms (N!) 0.000 ms USUARIO1#
Usuario 2 USUARIO2# traceroute 172.16.20.1 traceroute to 172.16.20.1 (172.16.20.1), 30 hops max, 40 byte packets 1 172.16.60.2 (172.16.60.2)(N!) 0.788 ms (N!) 3.685 ms (N!) 0.093 ms USUARIO2#
Se configuran las rutas y se procede a comprobar el camino tomado por el paquete: Usuario 1 USUARIO1# traceroute 172.16.60.1 traceroute to 172.16.60.1 (172.16.60.1), 30 hops max, 40 byte packets 1 172.16.20.2 (172.16.20.2) 2.814 ms 0.139 ms 0.200 ms 2 192.168.15.2 (192.168.15.2) 0.962 ms 0.337 ms 1.319 ms 3 192.168.15.6 (192.168.15.6) 9.114 ms 6.711 ms 2.685 ms 4 172.16.60.1 (172.16.60.1)(H!) 2.135 ms (H!) 1.662 ms (H!) 3.608 ms USUARIO1#
Usuario 2 USUARIO2# traceroute 172.16.20.1 traceroute to 172.16.20.1 (172.16.20.1), 30 hops max, 40 byte packets 1 172.16.60.2 (172.16.60.2) 0.000 ms 0.000 ms 0.000 ms 2 192.168.15.5 (192.168.15.5) 3.659 ms 1.504 ms 3.318 ms 3 192.168.15.1 (192.168.15.1) 4.223 ms 2.571 ms 2.690 ms 4 172.16.20.1 (172.16.20.1)(H!) 35.941 ms(H!) 34.650 ms(H!) 30.120 ms USUARIO2#
B - 20
8. Pruebas de funcionalidad del enrutamiento dinámico IPv6 con BGP
Se puede observar en la Figura 4-11 el escenario planteado para el enrutamiento dinámico IPv6 con BGP, las pruebas del mismo se las presenta a continuación: 8.1.
Pruebas conectividad
Las pruebas de conectividad para enrutamiento dinámico IPv6 con BGP se hacen utilizando el utilitario ping6, los resultados de estas pruebas se muestran a continuación: Usuario 1 USUARIO1# ping6 -c 8 2000:a::2 PING 2000:a::2(2000:a::2) 56 data bytes From 2000:1::1 icmp_seq=0 Destination unreachable: From 2000:1::1 icmp_seq=1 Destination unreachable: From 2000:1::1 icmp_seq=2 Destination unreachable: From 2000:1::1 icmp_seq=3 Destination unreachable: From 2000:1::1 icmp_seq=4 Destination unreachable: From 2000:1::1 icmp_seq=5 Destination unreachable: From 2000:1::1 icmp_seq=6 Destination unreachable: From 2000:1::1 icmp_seq=7 Destination unreachable:
No No No No No No No No
route route route route route route route route
--- 2000:a::2 ping statistics --8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 7001ms USUARIO1#
Usuario 2 USUARIO2# ping6 -c 8 2000:1::2 PING 2000:1::2(2000:1::2) 56 data bytes From 2000:a::1 icmp_seq=0 Destination unreachable: From 2000:a::1 icmp_seq=1 Destination unreachable: From 2000:a::1 icmp_seq=2 Destination unreachable: From 2000:a::1 icmp_seq=3 Destination unreachable: From 2000:a::1 icmp_seq=4 Destination unreachable: From 2000:a::1 icmp_seq=5 Destination unreachable: From 2000:a::1 icmp_seq=6 Destination unreachable: From 2000:a::1 icmp_seq=7 Destination unreachable:
No No No No No No No No
route route route route route route route route
--- 2000:1::2 ping statistics --8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 7008ms USUARIO2#
B - 21
Después de haber configurado el enrutamiento dinámico con BGP a través del demonio bgpd se tienen las siguientes salidas: Usuario 1 USUARIO1# ping6 -c 8 2000:a::2 PING 2000:a::2(2000:a::2) 56 data bytes 64 bytes from 2000:a::2: icmp_seq=0 ttl=61 64 bytes from 2000:a::2: icmp_seq=1 ttl=61 64 bytes from 2000:a::2: icmp_seq=2 ttl=61 64 bytes from 2000:a::2: icmp_seq=3 ttl=61 64 bytes from 2000:a::2: icmp_seq=4 ttl=61 64 bytes from 2000:a::2: icmp_seq=5 ttl=61 64 bytes from 2000:a::2: icmp_seq=6 ttl=61 64 bytes from 2000:a::2: icmp_seq=7 ttl=61
time=12.6 time=2.11 time=2.03 time=82.6 time=1.98 time=3.00 time=2.35 time=4.36
ms ms ms ms ms ms ms ms
--- 2000:a::2 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 7018ms rtt min/avg/max/mdev = 1.981/14.363/82.656/28.276 ms, pipe 2 USUARIO1#
Usuario 2 USUARIO2# ping6 -c 8 2000:1::2 PING 2000:1::2(2000:1::2) 56 data bytes 64 bytes from 2000:1::2: icmp_seq=0 ttl=61 64 bytes from 2000:1::2: icmp_seq=1 ttl=61 64 bytes from 2000:1::2: icmp_seq=2 ttl=61 64 bytes from 2000:1::2: icmp_seq=3 ttl=61 64 bytes from 2000:1::2: icmp_seq=4 ttl=61 64 bytes from 2000:1::2: icmp_seq=5 ttl=61 64 bytes from 2000:1::2: icmp_seq=6 ttl=61 64 bytes from 2000:1::2: icmp_seq=7 ttl=61
time=7.31 time=2.72 time=2.51 time=2.68 time=2.58 time=2.89 time=1.52 time=3.40
ms ms ms ms ms ms ms ms
--- 2000:1::2 ping statistics --8 packets transmitted, 8 received, 0% packet loss, time 7013ms rtt min/avg/max/mdev = 1.528/3.208/7.314/1.636 ms, pipe 2 USUARIO2#
Se puede observar que después configurado el enrutamiento dinámico con BGP se consiguió el propósito de comunicar el usuario 1 con el usuario 2. 8.2.
Pruebas de ruta
Se verifica la ruta que toma el paquete al ser enviado utilizando el utilitario traceroute previa la configuración de las rutas de la siguiente manera:
B - 22
Usuario 1 USUARIO1# traceroute 2000:a::2 traceroute to 2000:a::2 (2000:a::2), 30 hops max, 40 byte packets 1 2000:1::1 (2000:1::1)(N!) 0.000 ms (N!) 0.171 ms (N!) 2.209 ms USUARIO1#
Usuario 2 USUARIO2# traceroute 2000:1::2 traceroute to 2000:1::2 (2000:1::2), 30 hops max, 40 byte packets 1 2000:a::1 (2000:a::1)(N!) 4.961 ms (N!) 10.881 ms (N!) 45.620 ms USUARIO2#
Se configuran las rutas y se procede a comprobar el camino tomado por el paquete: Usuario 1 USUARIO1# traceroute 2000:a::2 traceroute to 2000:a::2 (2000:a::2), 30 hops max, 40 byte packets 1 2000:1::1 (2000:1::1) 6.567 ms 4.160 ms 2.441 ms 2 2000:2::2 (2000:2::2) 6.531 ms 1.752 ms 1.583 ms 3 2000:3::2 (2000:3::2) 2.961 ms 3.214 ms 1.756 ms 4 2000:a::2 (2000:a::2) 11.323 ms 12.217 ms 10.063 ms USUARIO1#
Usuario 2 USUARIO2# traceroute 2000:1::2 traceroute to 2000:1::2 (2000:1::2), 30 hops max, 40 byte packets 1 2000:a::1 (2000:a::1) 1.392 ms 1.121 ms 1.827 ms 2 2000:3::1 (2000:3::1) 0.875 ms 2.318 ms 0.417 ms 3 2000:2::1 (2000:2::1) 2.721 ms 0.422 ms 1.453 ms 4 2000:1::2 (2000:1::2) 5.425 ms 3.q60 ms 8.211 ms USUARIO2#
ANEXO C MANUAL DEL PAQUETE DE ENRUTAMIENTO QUAGGA
ANEXO D ARCHIVOS DE CONFIGURACIÓN
D-1
ANEXO D Archivos de configuración 1. 1.1.
Práctica 1 Enrutador A
zebra.conf ! ! Zebra configuration saved from vty ! 2007/08/21 00:49:48 ! hostname A password master20 enable password master20 ! interface eth0 ip address 172.16.0.2/24 ipv6 nd suppress-ra ! interface eth1 ip address 192.168.15.1/30 ipv6 nd suppress-ra ! interface eth2 ip address 192.168.15.14/30 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip forwarding ipv6 forwarding ! line vty !
ripd.conf ! Zebra configuration saved from vty ! 2007/08/21 00:54:22 ! hostname A_RIP password master20 enable password master20 log stdout ! router rip network 172.16.0.0/24 network 192.168.15.0/30
D-2
network 192.168.15.12/30 ! line vty !
1.2.
Enrutador B
zebra.conf ! ! Zebra configuration saved from vty ! 2007/08/20 22:06:01 ! hostname B password master20 enable password master20 ! interface eth0 ip address 192.168.15.2/30 ipv6 nd suppress-ra ! interface eth1 ip address 192.168.15.5/30 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip forwarding ipv6 forwarding ! line vty !
ripd.conf ! ! Zebra configuration saved from vty ! 2007/08/20 22:09:30 ! hostname B_RIP password master20 enable password master20 log stdout ! router rip network 192.168.15.0/30 network 192.168.15.4/30 ! line vty !
1.3.
Enrutador C
D-3
zebra.conf ! ! Zebra configuration saved from vty ! 2007/08/21 00:58:11 ! hostname C password master20 enable password master20 ! interface eth0 ip address 192.168.15.6/30 ipv6 nd suppress-ra ! interface eth1 ip address 192.168.15.9/30 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip forwarding ipv6 forwarding ! line vty !
ripd.conf ! ! Zebra configuration saved from vty ! 2007/08/21 01:00:10 ! hostname C_RIP password master20 enable password master20 log stdout ! router rip network 192.168.15.4/30 network 192.168.15.8/30 ! line vty !
1.4.
Enrutador D
zebra.conf ! ! Zebra configuration saved from vty ! 2007/08/21 04:11:54 ! hostname D
D-4
password master20 enable password master20 ! interface eth0 ip address 192.168.15.10/30 ipv6 nd suppress-ra ! interface eth1 ip address 192.168.15.13/30 ipv6 nd suppress-ra ! interface eth2 ip address 172.16.1.2/24 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip forwarding ! line vty !
ripd.conf ! ! Zebra configuration saved from vty ! 2007/08/21 04:14:35 ! hostname D_RIP password master20 enable password master20 log stdout ! router rip network 172.16.1.0/24 network 192.168.15.8/30 network 192.168.15.12/30 ! line vty !
2. 2.1.
Práctica 2 Enrutador A
zebra.conf ! ! Zebra configuration saved from vty ! 2007/08/27 02:34:29 ! hostname A password master20 enable password master20 !
D-5
interface eth0 ip address 10.1.1.2/24 ipv6 nd suppress-ra ! interface eth1 ip address 192.168.15.1/30 ipv6 nd suppress-ra ! interface eth2 ip address 192.168.15.9/30 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip forwarding ipv6 forwarding ! line vty !
ospfd.conf ! ! Zebra configuration saved from vty ! 2007/08/27 02:43:27 ! hostname A_OSPF password master20 enable password master20 log stdout ! ! ! interface eth0 ! interface eth1 ! interface eth2 ! interface lo ! interface sit0 ! router ospf network 10.1.1.0/24 area 0.0.0.0 network 192.168.15.0/30 area 0.0.0.0 network 192.168.15.8/30 area 0.0.0.0 ! line vty !
D-6
2.2.
Enrutador B
zebra.conf ! ! Zebra configuration saved from vty ! 2007/08/27 02:44:59 ! hostname B password master20 enable password master20 ! interface eth0 ip address 192.168.15.2/30 ipv6 nd suppress-ra ! interface eth1 ip address 192.168.15.5/30 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip forwarding ipv6 forwarding ! line vty !
ospfd.conf ! ! Zebra configuration saved from vty ! 2007/08/27 02:46:12 ! hostname B_OSPF password master20 enable password master20 log stdout ! ! ! interface eth0 ! interface eth1 ! interface lo ! interface sit0 ! router ospf network 192.168.15.0/30 area 0.0.0.0 network 192.168.15.4/30 area 0.0.0.0 ! line vty !
D-7
2.3.
Enrutador C
zebra.conf ! ! Zebra configuration saved from vty ! 2007/08/27 01:48:06 ! hostname C password master20 enable password master20 ! interface eth0 ip address 192.168.15.6/30 ipv6 nd suppress-ra ! interface eth1 ip address 192.168.15.10/30 ipv6 nd suppress-ra ! interface eth2 ip address 200.5.10.2/24 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip forwarding ipv6 forwarding ! line vty !
ospfd.conf ! ! Zebra configuration saved from vty ! 2007/08/27 01:45:11 ! hostname C_OSPF password master20 enable password master20 log stdout ! ! ! interface eth0 ! interface eth1 ! interface eth2 ! interface lo ! interface sit0 !
D-8
router ospf network 192.168.15.4/30 area 0.0.0.0 network 192.168.15.8/30 area 0.0.0.0 network 200.5.10.1/24 area 0.0.0.0 ! line vty !
3. 3.1.
Práctica 3 Enrutador A
zebra.conf ! ! Zebra configuration saved from vty ! 2007/08/30 03:40:43 ! hostname A password master20 enable password master20 ! interface eth0 ipv6 nd suppress-ra ! interface eth1 ipv6 nd suppress-ra ! interface eth2 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip route 0.0.0.0/0 eth0 ! ip forwarding ipv6 forwarding ! line vty !
ripd.conf ! ! Zebra configuration saved from vty ! 2007/08/30 03:40:30 ! hostname A_RIP_NAT password master20 enable password master20 log stdout ! router rip default-information originate network 172.16.40.0/24 network 192.168.15.0/30
D-9
! line vty !
iptables # Generated by iptables-save v1.3.5 on Wed Aug 29 08:36:29 2007 *nat :PREROUTING ACCEPT [25:2012] :POSTROUTING ACCEPT [9:744] :OUTPUT ACCEPT [6:492] -A POSTROUTING -d ! 192.168.15.0/255.255.255.252 -o eth0 -j MASQUERADE -A POSTROUTING -d ! 172.16.40.0/255.255.255.0 -o eth0 -j MASQUERADE COMMIT # Completed on Wed Aug 29 08:36:29 2007 # Generated by iptables-save v1.3.5 on Wed Aug 29 08:36:29 2007 *filter :INPUT ACCEPT [14:1032] :FORWARD ACCEPT [82:5871] :OUTPUT ACCEPT [10:824] COMMIT # Completed on Wed Aug 29 08:36:29 2007
3.2.
Enrutador B
zebra.conf ! ! Zebra configuration saved from vty ! 2007/08/29 06:38:35 ! hostname B password master20 enable password master20 ! interface eth0 ip address 172.16.41.1/24 ipv6 nd suppress-ra ! interface eth1 ip address 192.168.15.2/30 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip forwarding ipv6 forwarding ! line vty !
D - 10
ripd.conf ! ! Zebra configuration saved from vty ! 2007/08/29 06:39:59 ! hostname B_RIP password master20 enable password master20 log stdout ! router rip network 172.16.41.0/24 network 192.168.15.0/30 ! line vty !
4. 4.1.
Práctica 4 Enrutador A
zebra.conf ! ! Zebra configuration saved from vty ! 2007/09/01 20:11:16 ! hostname A password master20 enable password master20 ! interface eth0 ip address 192.168.15.1/30 ipv6 nd suppress-ra ! interface eth1 ip address 172.16.20.1/24 ipv6 nd suppress-ra ! interface eth2 ip address 172.16.30.1/24 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip forwarding ipv6 forwarding ! line vty !
ospfd.conf ! ! Zebra configuration saved from vty
D - 11
! 2007/09/01 20:13:10 ! hostname A_OSPF_ACL password master20 enable password master20 log stdout ! ! ! interface eth0 ! interface eth1 ! interface eth2 ! interface lo ! interface sit0 ! router ospf network 172.16.20.0/24 area 0.0.0.0 network 172.16.30.0/24 area 0.0.0.0 network 192.168.15.0/30 area 0.0.0.0 ! line vty !
Iptables # Generated by iptables-save v1.3.5 on Sun Sep 2 07:07:00 2007 *nat :PREROUTING ACCEPT [9:756] :POSTROUTING ACCEPT [12:1012] :OUTPUT ACCEPT [3:256] COMMIT # Completed on Sun Sep 2 07:07:00 2007 # Generated by iptables-save v1.3.5 on Sun Sep 2 07:07:00 2007 *filter :INPUT ACCEPT [3:256] :FORWARD ACCEPT [12:1008] :OUTPUT ACCEPT [3:256] -A FORWARD -s 172.16.20.2 -d 172.16.30.2 -i eth1 -o eth2 -j DROP -A FORWARD -s 172.16.30.2 -d 172.16.20.2 -i eth2 -o eth1 -j DROP -A FORWARD -s 172.16.10.2 -d 172.16.30.2 -i eth0 -o eth2 -j DROP -A FORWARD -s 172.16.30.2 -d 172.16.20.2 -i eth2 -o eth1 -j DROP -A FORWARD -s 172.16.20.2 -d 172.16.30.2 -i eth1 -o eth2 -j DROP -A FORWARD -s 172.16.30.2 -d 172.16.10.2 -i eth2 -o eth0 -j DROP COMMIT # Completed on Sun Sep 2 07:07:00 2007
4.2.
Enrutador B
zebra.conf ! ! Zebra configuration saved from vty ! 2007/09/01 20:08:30
D - 12
! hostname B password master20 enable password master20 ! interface eth0 ip address 192.168.15.2/30 ipv6 nd suppress-ra ! interface eth1 ip address 172.16.10.1/24 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip forwarding ipv6 forwarding ! line vty !
ospfd.conf ! ! Zebra configuration saved from vty ! 2007/09/01 20:13:39 ! hostname B_OSPF_ACL password master20 enable password master20 log stdout ! ! ! interface eth0 ! interface eth1 ! interface lo ! interface sit0 ! router ospf network 172.16.10.0/24 area 0.0.0.0 network 192.168.15.0/30 area 0.0.0.0 ! line vty !
D - 13
5. Práctica 5 5.1. Parte A 5.1.1. Enrutador A
zebra.conf ! ! Zebra configuration saved from vty ! 2007/09/02 20:32:14 ! hostname A password master20 enable password master20 ! interface eth0 description HACIA USUARIO 1 ip address 172.16.0.2/16 ipv6 nd suppress-ra ! interface eth1 description HACIA ENRUTADOR B ip address 200.1.1.1/30 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip forwarding ipv6 forwarding ! line vty !
ripd.conf ! ! Zebra configuration saved from vty ! 2007/09/02 20:37:11 ! hostname A_RIP password master20 enable password master20 log stdout ! router rip network 172.16.0.0/16 network 200.1.1.0/30 ! line vty !
D - 14
5.1.2. Enrutador B
zebra.conf ! ! Zebra configuration saved from vty ! 2007/09/02 20:30:43 ! hostname B password master20 enable password master20 ! interface eth0 ip address 200.1.1.2/30 ipv6 nd suppress-ra ! interface eth1 ip address 200.1.1.5/30 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip forwarding ipv6 forwarding ! line vty !
ripd.conf ! ! Zebra configuration saved from vty ! 2007/09/02 20:37:49 ! hostname B_RIP password master20 enable password master20 log stdout ! router rip network 200.1.1.0/30 network 200.1.1.4/30 ! line vty !
5.1.3. Enrutador C
zebra.conf ! ! Zebra configuration saved from vty ! 2007/09/02 19:28:01 !
D - 15
hostname C password master20 enable password master20 ! interface eth0 ip address 200.1.1.6/30 ipv6 nd suppress-ra ! interface eth1 ip address 192.168.9.2/24 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip forwarding ipv6 forwarding ! line vty !
ripd.conf ! ! Zebra configuration saved from vty ! 2007/09/02 19:34:57 ! hostname C_RIP password master20 enable password master20 log stdout ! router rip network 192.168.9.0/24 network 200.1.1.4/30 ! line vty !
6. 6.1.
Práctica 6 Enrutador A
zebra.conf ! ! Zebra configuration saved from vty ! 2007/09/03 03:18:08 ! hostname A password master20 enable password master20 ! interface eth0 ip address 192.168.15.1/30 ipv6 nd suppress-ra
D - 16
! interface eth1 ip address 172.16.20.2/24 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip forwarding ipv6 forwarding ! line vty !
bgpd.conf ! ! Zebra configuration saved from vty ! 2007/09/03 03:25:36 ! hostname A_BGP password master20 enable password master20 log stdout ! router bgp 100 bgp router-id 172.16.20.2 network 172.16.20.0/24 neighbor 192.168.15.2 remote-as 200 ! line vty !
6.2.
Enrutador B
zebra.conf ! ! Zebra configuration saved from vty ! 2007/09/03 03:18:40 ! hostname B password master20 enable password master20 ! interface eth0 ip address 192.168.15.2/30 ipv6 nd suppress-ra ! interface eth1 ip address 192.168.15.5/30 ipv6 nd suppress-ra ! interface lo ! interface sit0
D - 17
ipv6 nd suppress-ra ! ip forwarding ipv6 forwarding ! line vty !
bgpd.conf ! ! Zebra configuration saved from vty ! 2007/09/03 03:26:28 ! hostname B_BGP password master20 enable password master20 log stdout ! router bgp 200 bgp router-id 192.168.15.5 neighbor 192.168.15.1 remote-as 100 neighbor 192.168.15.6 remote-as 300 ! line vty !
6.3.
Enrutador C
zebra.conf ! ! Zebra configuration saved from vty ! 2007/09/03 02:15:19 ! hostname C password master20 enable password master20 ! interface eth0 ip address 192.168.15.6/30 ipv6 nd suppress-ra ! interface eth1 ip address 172.16.60.2/24 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip forwarding ipv6 forwarding ! line vty !
D - 18
bgpd.conf ! ! Zebra configuration saved from vty ! 2007/09/03 02:34:01 ! hostname bgpd password zebra log stdout ! router bgp 300 bgp router-id 192.168.15.6 network 172.16.60.0/24 neighbor 192.168.15.5 remote-as 200 ! line vty !
7. 7.1.
Práctica 7 Enrutador X
zebra.conf ! ! Zebra configuration saved from vty ! 2007/09/03 07:42:21 ! hostname X password master20 enable password master20 ! interface eth0 ip address 192.168.15.1/30 ipv6 nd suppress-ra ! interface eth1 ip address 192.168.10.2/24 ipv6 nd suppress-ra ! interface eth2 ip address 200.0.0.2/24 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip forwarding ipv6 forwarding ! line vty !
ripd.conf ! ! Zebra configuration saved from vty
D - 19
! 2007/09/03 07:43:46 ! hostname X_RIP password master20 enable password master20 log stdout ! router rip network 192.168.10.0/24 network 192.168.15.0/30 network 200.0.0.0/24 ! line vty !
iptables # Generated by iptables-save v1.3.5 on Mon Sep 3 10:33:36 2007 *filter :INPUT ACCEPT [3:296] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [3:296] -A INPUT -s ! 192.168.10.1 -p tcp -m tcp --dport 25 -j DROP -A INPUT -i eth1 -p icmp -j DROP -A FORWARD -s 192.168.10.1 -d 172.16.0.1 -p tcp -m tcp --dport 21 -j DROP -A FORWARD -s 200.0.0.1 -d 172.16.0.1 -j DROP -A OUTPUT -d ! 192.168.10.1 -p tcp -m tcp --sport 25 -j DROP -A OUTPUT -o eth1 -p icmp -j DROP COMMIT # Completed on Mon Sep 3 10:33:36 2007 # Generated by iptables-save v1.3.5 on Mon Sep 3 10:33:36 2007 *nat :PREROUTING ACCEPT [0:0] :POSTROUTING ACCEPT [3:296] :OUTPUT ACCEPT [3:296] COMMIT # Completed on Mon Sep 3 10:33:36 2007
7.2.
Enrutador Y
zebra.conf ! ! Zebra configuration saved from vty ! 2007/09/03 07:44:32 ! hostname Y password master20 enable password master20 ! interface eth0 ip address 192.168.15.2/30 ipv6 nd suppress-ra ! interface eth1 ip address 172.16.0.2/16 ipv6 nd suppress-ra !
D - 20
interface eth2 ip address 10.0.0.2/24 ipv6 nd suppress-ra ! interface lo ! interface sit0 ipv6 nd suppress-ra ! ip forwarding ipv6 forwarding ! line vty !
ripd.conf ! ! Zebra configuration saved from vty ! 2007/09/03 07:45:56 ! hostname Y_RIP password master20 enable password master20 log stdout ! router rip network 10.0.0.0/24 network 172.16.0.0/16 network 192.168.15.0/30 ! line vty !
iptables # Generated by iptables-save v1.3.5 on Mon Sep 3 10:36:29 2007 *filter :INPUT ACCEPT [1:72] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -s ! 192.168.10.1 -p tcp -m tcp --dport 25 -j DROP -A INPUT -s ! 200.0.0.1 -p tcp -m tcp --dport 22 -j DROP -A INPUT -i eth1 -p icmp -j DROP -A FORWARD -s 172.16.0.1 -d 200.0.0.1 -j DROP -A FORWARD -s ! 10.0.0.1 -d 172.16.0.1 -j DROP -A OUTPUT -d ! 192.168.10.1 -p tcp -m tcp --sport 25 -j DROP -A OUTPUT -d ! 200.0.0.1 -p tcp -m tcp --sport 22 -j DROP -A OUTPUT -o eth1 -p icmp -j DROP COMMIT # Completed on Mon Sep 3 10:36:29 2007 # Generated by iptables-save v1.3.5 on Mon Sep 3 10:36:29 2007 *nat :PREROUTING ACCEPT [1:72] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT # Completed on Mon Sep 3 10:36:29 2007
D - 21
8. 8.1.
Práctica 8 Enrutador A
zebra.conf ! ! Zebra configuration saved from vty ! 2007/09/11 10:48:48 ! hostname ROUTER_PPP_A password master20 enable password master20 ! interface eth0 ip address 172.16.0.2/16 ipv6 nd suppress-ra ! interface lo ! interface ppp0 ipv6 nd suppress-ra ! interface sit0 ipv6 nd suppress-ra ! ip route 192.168.20.0/24 192.168.1.2 ! ip forwarding ! line vty !
/etc/inittab # # inittab # # # Author: # #
This file describes how the INIT process should set up the system in a certain run-level. Miquel van Smoorenburg ,
Modified for RHS Linux by Marc Ewing and Donnie Barnes
# Default runlevel. The runlevels used by RHS are: # 0 - halt (Do NOT set initdefault to this) # 1 - Single user mode # 2 - Multiuser, without NFS (The same as 3, if you do not have networking) # 3 - Full multiuser mode # 4 - unused # 5 - X11 # 6 - reboot (Do NOT set initdefault to this) # id:3:initdefault: # System initialization.
D - 22
si::sysinit:/etc/rc.d/rc.sysinit l0:0:wait:/etc/rc.d/rc l1:1:wait:/etc/rc.d/rc l2:2:wait:/etc/rc.d/rc l3:3:wait:/etc/rc.d/rc l4:4:wait:/etc/rc.d/rc l5:5:wait:/etc/rc.d/rc l6:6:wait:/etc/rc.d/rc
0 1 2 3 4 5 6
# Trap CTRL-ALT-DELETE ca::ctrlaltdel:/sbin/shutdown -t3 -r now # When our UPS tells us power has failed, assume we have a few minutes # of power left. Schedule a shutdown for 2 minutes from now. # This does, of course, assume you have powerd installed and your # UPS connected and working correctly. pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down" # If power was restored before the shutdown kicked in, cancel it. pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"
# Run gettys in standard runlevels 1:2345:respawn:/sbin/mingetty tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6 s0:2345:respawn:/usr/sbin/pppd -detach noauth crtscts 192.168.1.1:192.168.1.2 /dev/ttyS0 38400 # Run xdm in runlevel 5 x:5:once:/etc/X11/prefdm -nodaemon
8.2.
Enrutador B
zebra.conf ! ! Zebra configuration saved from vty ! 2007/09/11 10:48:48 ! hostname ROUTER_PPP_B password master20 enable password master20 ! interface eth0 ip address 192.168.20.2/24 ipv6 nd suppress-ra ! interface lo ! interface ppp0 ipv6 nd suppress-ra
D - 23
! interface sit0 ipv6 nd suppress-ra ! ip route 172.16.0.0/16 192.168.1.1 ! ip forwarding ! line vty !
/etc/inittab # # inittab # # # Author: # #
This file describes how the INIT process should set up the system in a certain run-level. Miquel van Smoorenburg , Modified for RHS Linux by Marc Ewing and Donnie Barnes
# Default runlevel. The runlevels used by RHS are: # 0 - halt (Do NOT set initdefault to this) # 1 - Single user mode # 2 - Multiuser, without NFS (The same as 3, if you do not have networking) # 3 - Full multiuser mode # 4 - unused # 5 - X11 # 6 - reboot (Do NOT set initdefault to this) # id:3:initdefault: # System initialization. si::sysinit:/etc/rc.d/rc.sysinit l0:0:wait:/etc/rc.d/rc l1:1:wait:/etc/rc.d/rc l2:2:wait:/etc/rc.d/rc l3:3:wait:/etc/rc.d/rc l4:4:wait:/etc/rc.d/rc l5:5:wait:/etc/rc.d/rc l6:6:wait:/etc/rc.d/rc
0 1 2 3 4 5 6
# Trap CTRL-ALT-DELETE ca::ctrlaltdel:/sbin/shutdown -t3 -r now # When our UPS tells us power has failed, assume we have a few minutes # of power left. Schedule a shutdown for 2 minutes from now. # This does, of course, assume you have powerd installed and your # UPS connected and working correctly. pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down" # If power was restored before the shutdown kicked in, cancel it. pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"
D - 24
# Run gettys in standard runlevels 1:2345:respawn:/sbin/mingetty tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6 s0:2345:respawn:/usr/sbin/pppd -detach noauth crtscts 192.168.1.2:192.168.1.1 /dev/ttyS0 38400 # Run xdm in runlevel 5 x:5:once:/etc/X11/prefdm -nodaemon
ANEXO E COTIZACIÓN DE EQUIPO CISCO
