RouterOSLibro de Estudio RouterOS v6.36.0 Ruteo Avanzado y Alta Disponibilidad con MikroTik RouterOS por Mauro Escalante Ruteo Estático Simple, ECMP OSPF,VLAN, QinQ VRRP, VPN RIB default-route connected-route FIB Ruteo Simple ECMP check-gateway distancia routing-mark route-policy Balanceo de Carga TTL next-hope recursivo scope target-scope OSPF hello-protocol database-distribution LSA AS Areas backbone stub NSSA ASBR ABR IR DR&BDR virtual-links Networks Neighbours Métrica Externa Type1 Type2 Costos Priority VLAN 802.1Q QinQ Direccionamento /30 /32 EoP&Brindging VRRP Master/Backup VPN pip eoip ppt Ruteo Avanzado y Alta Disponibilidad con MikroTik RouterOS v6.36.0.01 Libro de Estudio & Manual de Laboratorio ABC Xperts ® Network Xperts ® Academy Xperts ® Derechos de autor y marcas registradas Todos los derechos de autor y marcas registradas son propiedad del titular de los derechos de autor respectivo Derechos de autor © por Academy Xperts Todos los derechos reservados. Ninguna parte de este libro puede ser reproducido, almacenado, o transmitido por cualquier medio ya sea este un auditorio, medio gráfico, mecánico, o electrónico sin el permiso escrito del autor, excepto en los casos en que se utilicen breves extractos para usarlos en artículos o revisiones. La reproducción no autorizada de cualquier parte de este libro es ilegal y sujeta a sanciones legales. RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad con MikroTik RouterOS Tabla de Contenido Introducción ........................................................................................................................................................ iv Resumen ........................................................................................................................................................................... v Audiencia ........................................................................................................................................................................... v Convenciones usadas en este libro................................................................................................................................... v Comentarios y preguntas ................................................................................................................................................. vi Partners de Academy Xperts en Latinoamérica ............................................................................................. vii Empresas Asociadas ....................................................................................................................................................... vii Universidades e Institutos Superiores ............................................................................................................................. vii Deseas convertirte en Academia o ser Partner de Academy Xperts? ............................................................................ vii Un poco de Historia (Costa Rica) ................................................................................................................................... viii Cubriendo un País con MikroTik. ........................................................................................................................... viii Detalle de cambios en las cinco últimas versiones de RouterOS ................................................................. ix v6.36, 20/Julio/2016, 14:09 ...................................................................................................................................... ix v6.35.4, 09/Junio/2016, 12:02 ................................................................................................................................ xiii v6.35.3, 01/Junio/2016, 07:55 ................................................................................................................................ xiv v6.35.2, 02/Mayo/2016, 10:09 ................................................................................................................................ xiv v6.35.1, 26/Abril/2016, 09:29 .................................................................................................................................. xiv Capítulo 1: Ruteo en RouterOS .......................................................................................................................... 1 RIB – Routing Information Base ....................................................................................................................................... 1 Ruta por Default ....................................................................................................................................................... 2 Rutas Conectadas .................................................................................................................................................... 2 Ruta Multipath (ECMP) ............................................................................................................................................. 2 Rutas con interface como Gateway .......................................................................................................................... 2 Selección de Ruta .................................................................................................................................................... 2 Criterio para la sección de las rutas candidatas ....................................................................................................... 3 Nexthop lookup ......................................................................................................................................................... 3 FIB – Forwarding Information Base .................................................................................................................................. 4 Tabla de ruteo lookup ............................................................................................................................................... 4 Propiedades de la Tabla de Ruteo ................................................................................................................................... 5 Etiquetas de ruta ...................................................................................................................................................... 5 Propiedades generales ............................................................................................................................................. 6 Propiedades de solo-lectura ..................................................................................................................................... 7 Propiedades de Ruta BGP ....................................................................................................................................... 7 Propiedades de solo-lectura ..................................................................................................................................... 8 Capítulo 2: Ruteo Estático Simple ..................................................................................................................... 9 Ruteo Simple .................................................................................................................................................................... 9 Lab. 2.1 – Ruteo Estático ................................................................................................................................................. 9 Objetivos ................................................................................................................................................................... 9 Actividades a realizar ............................................................................................................................................... 9 Rutas ECMP (Equal Cost Multi Path) ............................................................................................................................. 11 Opción “Check-gateway” ........................................................................................................................................ 12 Lab. 2.2 – Ruteo ECMP.................................................................................................................................................. 12 Objetivos ................................................................................................................................................................. 12 Actividades a realizar ............................................................................................................................................. 12 Lab. 2.3.1 – Ruteo ECMP para balanceo de carga ........................................................................................................ 12 Objetivos ................................................................................................................................................................. 12 Actividades a realizar ............................................................................................................................................. 12 Lab. 2.3.2 – Ruteo ECMP para balanceo de carga Asimétrico ...................................................................................... 13 Objetivos ................................................................................................................................................................. 13 Actividades a realizar ............................................................................................................................................. 13 Opción “distancia”........................................................................................................................................................... 13 Lab. 2.4 – Distancia de ruta............................................................................................................................................ 13 Ejemplo de configuración ....................................................................................................................................... 14 Routing Mark .................................................................................................................................................................. 14 Lab.2.5 - Política de Ruteo (routing mark)...................................................................................................................... 14 Time To Live (TTL) ......................................................................................................................................................... 15 Resolviendo el Next-Hop Recursivo ............................................................................................................................... 16 Scope / Target-Scope ............................................................................................................................................. 16 Otras Opciones ....................................................................................................................................................... 16 Clean-up ................................................................................................................................................................. 16 Capítulo 3: OSPF ............................................................................................................................................... 17 Protocolo OSPF.............................................................................................................................................................. 17 Academy Xperts i RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad con MikroTik RouterOS Configurando OSPF en MikroTik ............................................................................................................................ 18 Métrica OSPF ......................................................................................................................................................... 25 Métrica Externa Type 1 .......................................................................................................................................... 26 Métrica Externa Type 2 .......................................................................................................................................... 26 Costo de Interface .................................................................................................................................................. 26 Systema Autónomo (AS) ................................................................................................................................................ 27 Áreas .............................................................................................................................................................................. 28 Área de Backbone .................................................................................................................................................. 28 Router de Backbone ............................................................................................................................................... 29 Área o Área Regular ............................................................................................................................................... 29 Router Interno ......................................................................................................................................................... 30 Router de Borde de Área (ABR: Area Border Router) ............................................................................................ 30 Router de Límite de Sistema Autónomo (ASBR: Autonomous System Boundary Router) .................................... 30 Stub Area ................................................................................................................................................................ 30 Totally Stub Area .................................................................................................................................................... 30 Not So Stubby Area (NSSA) ................................................................................................................................... 31 Base de Datos Topológica OSPF................................................................................................................................... 31 Tipos de Rutas OSPF..................................................................................................................................................... 31 Cómo trabaja OSPF ....................................................................................................................................................... 32 La cabecera OSPF ................................................................................................................................................. 32 Neighbor Discovery: Protocolo Hello (OSPF Packet Type 1)................................................................................. 33 Elección DR/BDR ................................................................................................................................................... 35 Estado de la Interface (Interface State) .................................................................................................................. 36 Relación de vecino (Neighbor Relationship) .......................................................................................................... 36 Intercambio de Base de Datos (Database Exchange) ........................................................................................... 36 Inundación (Flooding) de LSAs .............................................................................................................................. 40 Sumarización de Rutas .................................................................................................................................................. 40 Rutas por Default (Default Routes) ........................................................................................................................ 40 Virtual Links (Enlaces Virtuales) ..................................................................................................................................... 41 Stub Area, Totally Stubby Area, y Not So Stubby Area.................................................................................................. 42 Stub Area ................................................................................................................................................................ 42 Totally Stubby Area ................................................................................................................................................ 44 NSSAs .................................................................................................................................................................... 44 Redes NBMA .................................................................................................................................................................. 45 Diseño de una red OSPF ............................................................................................................................................... 46 Jerarquía OSPF ...................................................................................................................................................... 46 Direccionamiento IP ............................................................................................................................................... 46 Router ID ................................................................................................................................................................ 46 DR/BDR .................................................................................................................................................................. 46 Area de Backbone .................................................................................................................................................. 46 Número de routers en un Area ............................................................................................................................... 46 Número de vecinos ................................................................................................................................................. 46 Sumarización de rutas ............................................................................................................................................ 46 VLSM ...................................................................................................................................................................... 47 Stub Areas .............................................................................................................................................................. 47 Enlaces Virtuales (Virtual Links) ............................................................................................................................. 47 Timers OSPF .......................................................................................................................................................... 47 Haciendo Troubleshooting de OSPF .............................................................................................................................. 47 ID del Area OSPF ................................................................................................................................................... 47 OSPF no inicia ........................................................................................................................................................ 47 Verificar las relaciones del vecino .......................................................................................................................... 47 Sumarización de Ruta ............................................................................................................................................ 47 Routers Sobrecargados .......................................................................................................................................... 48 Exceso de SPF (Shortest Path First) ...................................................................................................................... 48 Usando la Base de Datos LS ................................................................................................................................. 48 Bitácora/registros (Logs) de Red ............................................................................................................................ 48 Laboratorio de OSPF...................................................................................................................................................... 48 Laboratorio Costos OSPF ...................................................................................................................................... 49 Laboratorio Costos OSPF + Nueva Ruta ............................................................................................................... 49 Laboratorio de Area OSPF ..................................................................................................................................... 50 Capítulo 4: Ruteo e Interface Point-to-point ................................................................................................... 51 Virtual LAN (802.1Q) ...................................................................................................................................................... 51 Creando una interfaz VLAN .................................................................................................................................... 51 VLAN en Switch.............................................................................................................................................................. 51 IPIP ......................................................................................................................................................................... 51 Academy Xperts ii RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad con MikroTik RouterOS Direccionamiento /30 .............................................................................................................................................. 52 Direccionamiento point-to-point .............................................................................................................................. 52 Tunel Ethernet Over IP (EoIP) ............................................................................................................................... 53 EOIP y Bridging ...................................................................................................................................................... 53 Capítulo 5: VRRP ............................................................................................................................................... 54 VRRP ...................................................................................................................................................................... 54 VRRP Master/Backup ............................................................................................................................................. 54 VRRP: Implementación Básica .............................................................................................................................. 54 VRRP + Internet (router)......................................................................................................................................... 55 VRRP + Internet (router)......................................................................................................................................... 55 VRRP + Internet (router)......................................................................................................................................... 56 VRRP + Internet (router)......................................................................................................................................... 56 VRRP + Internet (router)......................................................................................................................................... 57 Capítulo 6: Túneles ........................................................................................................................................... 58 Introducción .................................................................................................................................................................... 58 RouterOS y Túneles ....................................................................................................................................................... 58 /ppp profile (perfiles de usuario) ..................................................................................................................................... 58 /ppp secret (base de datos de usuario) .......................................................................................................................... 60 /ppp active (usuarios activos) ......................................................................................................................................... 61 /ppp aaa (AAA remoto) ................................................................................................................................................... 61 /ppp client (cliente PPP) ................................................................................................................................................. 61 /ip pool ............................................................................................................................................................................ 62 PPPoE ............................................................................................................................................................................ 63 Operación PPPoE .................................................................................................................................................. 64 Tipos de paquetes utilizados .................................................................................................................................. 64 MTU ........................................................................................................................................................................ 65 pppoe client (Cliente PPPoE) ................................................................................................................................. 65 Status ..................................................................................................................................................................... 66 Scanner .................................................................................................................................................................. 66 Configuración del Server PPPoE (Concentrador de Acceso) ................................................................................ 66 PPPoE Server (Servidor PPPoE) ........................................................................................................................... 67 PPTP .............................................................................................................................................................................. 68 PPTP Client (cliente pptp) ...................................................................................................................................... 70 PPTP Server (servidor pptp) .................................................................................................................................. 71 L2TP ............................................................................................................................................................................... 71 L2TP Client (cliente l2tp) ........................................................................................................................................ 72 L2TP Server (servidor l2tp) .................................................................................................................................... 72 Clientes y servidores SSTP ............................................................................................................................................ 73 Clientes y Servidores OpenVPN .................................................................................................................................... 73 Configuración de Rutas entre redes ............................................................................................................................... 74 Preguntas de repaso del Módulo 6................................................................................................................................. 74 7 – Repaso Laboratorios Detallados Túneles ................................................................................................. 75 Objetivos y Conceptos previos a túneles IPIP ................................................................................................................ 75 Objetivos: ................................................................................................................................................................ 75 Bases Conceptuales:.............................................................................................................................................. 75 Proceso Túnel IPIP ................................................................................................................................................. 77 Laboratorio 7.1 – Túnel IP-IP ......................................................................................................................................... 78 Laboratorio 7.2 – Túnel EoIP.......................................................................................................................................... 80 Objetivos: ................................................................................................................................................................ 80 Bases Conceptuales:.............................................................................................................................................. 80 Objetivos y Conceptos previos a túneles PPTP ............................................................................................................. 83 Objetivos: ................................................................................................................................................................ 83 Bases Conceptuales:.............................................................................................................................................. 83 Laboratorio 7.3 – Túnel PPTP (R1 Server – R2 Client).................................................................................................. 84 Laboratorio 7.4 – Túnel PPTP (R1 Client – R2 Server).................................................................................................. 87 Laboratorio 7.5 – Bridge a través de un túnel PPTP usando BCP ................................................................................. 89 Objetivos: ................................................................................................................................................................ 89 Bases Conceptuales:.............................................................................................................................................. 89 Requerimientos: ..................................................................................................................................................... 89 Academy Xperts iii RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad con MikroTik RouterOS Introducción MikroTik es una empresa que nace en Latvia (Letonia) en 1995 con el claro objetivo de proveer un sistema operativo de red altamente robusto y eficiente al cual llamó RouterOS en 1997. La evolución del mismo llevó a la creación y lanzamiento al mercado en el 2002 de un hardware que aprovechara al máximo sus grandes capacidades de multiprocesamiento simétrico y multi-núcleo, este hardware es el RouterBOARD. A lo largo de los años a partir del nacimiento del Internet, los administradores de red hemos visto desfilar varios fabricantes por nuestros racks, siendo Cisco el referente, sin embargo siempre había representado un costo más o menos importante a la hora de implementar una solución de red ruteada en especial si se trataba de un ISP/WISP. No es sino hasta hace una década aproximadamente en que MikroTik se empieza a hacer conocer en Latinoamérica y varios emprendedores, y por sobre entusiastas, se vuelcan a la implementación de soluciones basadas en RouterOS y RouterBOARD. Claro ejemplo de ello son nuestros grandes amigos de Index México (Ezequiel García) y REICO Costa Rica (Miguel Solís) quienes tomaron la iniciativa de confiar en los productos ofrecidos por MikroTik. Es muy interesante y gratificante conversar con ellos y escuchar los relatos sobre los primeros pasos del fabricante letón en tierras americanas. Estoy convencido de que MikroTik llegó no solo para quedarse sino para formar una parte muy importante en la historia del networking y de las telecomunicaciones. De hecho, cientos de miles (quizá millones a esta fecha - Junio 2015) obtienen su internet de banda ancha a un bajo costo a través de una red ruteada gracias a que los proveedores de Internet, pequeños y medianos, pueden estructurar e implementar redes sumamente complejas y completas usando los RouterBOARD. Las soluciones en RouterOS y RouterBOARD no se han quedado estancadas en las empresas de Telecom pequeñas, sino que han ido escalando en credibilidad en las empresa medianas y grandes en Latinoamérica, rompiendo paradigmas de fabricantes y costos de implementación. Este libro nace como un aporte a la comunidad tecnológica de habla hispana y latinoamericana que ha decidido incursionar en MikroTik y desea obtener un conocimiento formal. De igual manera queremos que esta guía constituya una fuente importante de aprendizaje para quienes empiezan a realizar sus primeras configuraciones en RouterOS. Mauro Escalante CEO Academy Xperts CEO Network Xperts Academy Xperts iv RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad con MikroTik RouterOS Resumen Este libro inicia con laboratorios de ruteo estático en los que aplicando diferentes parámetros de distancia, routing-mark, o haciendo uso de ECMP, se llega a la conclusión de que estas técnicas por si solas no son suficientes para proveer funciones como un failover confiable, o un ruteo dinámico automático. Se realizan varias pruebas valiosas con ECMP que sirven para usos posteriores como Balanceo de Carga con PCC. Si bien es cierto que hasta versión del libro no se profundiza en todos los conceptos que rigen OSPF, sin embargo se realizan sendos laboratorios donde se podrán plasmar las principales funciones del protocolo, no solo entre rutas y routers dentro del mismo área de backbone, sino también con un área externa al área de backbone. En las próximas versiones de este libro se están agregando puntos elementales de conocimiento y nuevos laboratorios de OSPF. Si dispones de este libro es seguramente porque lo has adquirido y tienes 12 meses garantizados de actualización a los textos, ejercicios y demás recursos a partir de tu compra. La alta disponibilidad del gateway se logra utilizando el protocolo estándar VRRP (Virtual Router Redundancy Protocol) y constituye una configuración obligatoria e indispensable en toda red de misión crítica. En este libro se presentan varios ejercicios VRRP con los cuales se intenta demostrar los diferentes escenarios y sus alternativas de solución. Finalmente la sección de túneles PPP se complementa con ejercicios muy elaborados, explicando al detalle los procesos involucrados y los escenarios de configuración. Hemos tenido un especial cuidado en ampliar la información de aquellos puntos que no se profundizan en los cursos de certificación, pero que resultan claves para el correcto entendimiento de la materia. La información aquí presentada se complementa con nuestros recursos en www.abcxperts.com y www.youtube.com/abcxperts Este libro no pretende reemplazar la interacción face-to-face con un instructor ya que su experiencia y conocimiento es invaluable y únicamente explotable a través del contacto interpersonal de un curso de certificación. Sin embargo, todo el material de apoyo junto con los videos tutoriales, webinars, tips, etc., representan un importante aporte para aquellos colegas que optan por leer un libro y estudiar a su propio ritmo. Esta es la primera revisión dedicada a la versión 6.33.5. Las posteriores revisiones al material y a los nuevos releases de RouterOS serán agregadas a esta edición y estarán a disponibilidad de las personas que compren la suscripción. Tenemos una tarea inmensa por delante pero estamos muy claros en nuestro objetivo de hacer de este libro la mejor guía de autoestudio MikroTik. Audiencia Las personas que leen este libro deben estar familiarizados con: • Operaciones de red en Capa 2 • Conjunto de protocolos IP, incluyendo TCP. UDP e ICMP Este libro está dirigido a: • Ingenieros y Técnicos en Redes, Telecomunicaciones y afines, que desea implementar y dar soporte a: § Redes Corporativas § Clientes WISP e ISP • Ingenieros de Redes involucrados en actividades de pre-venta y post-venta en soporte e instalación de redes corporativa y PYMES • Ingenieros de Redes, Administradores de Red, Técnicos en Soporte de Redes, y Técnicos de Soporte a Usuario (Help Desk) Convenciones usadas en este libro En este libro se utilizarán las siguientes convenciones tipográficas: Itálicas Indica comandos, direcciones de correo, claves, mensajes de error, nombres de archivos, énfasis, y el primer uso de términos técnicos Courier new Indica direcciones IP y ejemplos de línea de comando Courier new en itálica Indica texto que puede ser reemplazado Courier new en negrita Indica datos de entrada del usuario Este icono significa un consejo, sugerencia, o una nota general. Este icono indica una advertencia o precaución. Academy Xperts v RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad con MikroTik RouterOS Comentarios y preguntas Puede enviar sus comentarios y preguntas sobre este libro por correo tradicional a la siguiente dirección: Network Xperts S.A. Av. Juan T. Marengo y J. Orrantia Edificio Professional Center, Piso 5, Ofic. 507 Guayaquil, ECUADOR +593-4-600-8590 +593-9-9535-2132 A través del sitio web y por medio de su usuario y contraseña, tendrá acceso a las actualizaciones, ejemplos, e información adicional: http://cursos.abcxperts.com Puede enviarnos sus comentarios o preguntas técnicas sobre este libro enviándonos un email a:
[email protected] Para más información sobre libros, conferencias, centros de recursos, y la red educativa de Academy Xperts, visite nuestros Websites y canal de YouTube http://www.abcxperts.com http://www.academyxperts.com http://www.youtube.com/abcxperts Academy Xperts vi RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad con MikroTik RouterOS Partners de Academy Xperts en Latinoamérica Nuestro recorrido por América Latina nos ha comprometido de una manera muy importante con nuestros alumnos, amigos y socios. Y este compromiso conlleva la enorme responsabilidad de estar siempre a la vanguardia, de presentar a nuestros estudiantes el mejor y más completo material de estudio & laboratorio, y lo que es muy importante… que el contenido siempre esté actualizado. Nos encantaría estar presente en cada uno de los 14 países y las más de 40 ciudades que recorremos todos los años, pero el tiempo y la disponibilidad física nos es un obstáculo. Por este motivo hemos desarrollado un esquema de Partnership con empresas, universidades e institutos superiores en diferentes países que trabajan junto con nosotros en sus respetivos ambientes, y que entregan a sus estudiantes el contenido y el acceso a la suscripción anual de este libro (y todos sus recursos) por un cómodo valor. Empresas Asociadas Universidades e Institutos Superiores Deseas convertirte en Academia o ser Partner de Academy Xperts? • Si eres Universidad o Instituto Superior que cuenta con el respectivo acuerdo ministerial de tu país, puedes optar por convertirte en una Academia MikroTik. Escríbenos a
[email protected] para darte más información. • Si eres Trainer Partner y quieres explotar junto a tus alumnos nuestro material y portal de capacitación, te invitamos escribirnos a
[email protected] para proporcionarte los detalles. • Si deseas que organicemos cursos en tu ciudad/país de residencia, escríbenos a
[email protected] Academy Xperts vii RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad con MikroTik RouterOS Un poco de Historia (Costa Rica) Cubriendo un País con MikroTik. En el año 1998, estando en una empresa de servicios públicos en Costa Rica, el Ing. Miguel Solís en conjunto con el Ing. Paulino Solano, comenzaron a utilizar MikroTik con gran éxito en las telecomunicaciones de esta empresa. Se lograron 2 Mbps en una distancia de 8 Km, una velocidad record para aquellos tiempos en que la velocidad rondaba los 256 Kbps. En esta empresa de Servicios Públicos, se logró la interconexión de 52 sucursales mediante tecnología inalámbrica, todas bajo la misma marca MikroTik y su sistema operativo RouterOS. Dado el éxito alcanzado en este proyecto, ambos ingenieros en conjunto con uno más llamado Olman González, decidieron formar una empresa que se dedicara a solventar los problemas de telecomunicaciones en donde el cobre no fuera factible o se necesitara más velocidad. Esta empresa fue nombrada Redes Inalámbricas de Costa Rica S.A (REICO). Es así como a la fecha (Julio 2015), REICO, con solo Miguel Solís como propietario, tiene el liderato en telecomunicaciones inalámbricas en el país Centroamericano Costa Rica. REICO posee más de 3,800 Km de red troncal inalámbrica y más de 80,000 Km de red de acceso. Posee más de 100 radio bases instaladas estratégicamente para alcanzar una cobertura de más del 80% del territorio y a más del 90% de la población. La empresa se dedica 100% a proveer transporte de datos corporativos y sirve a sectores financieros, agroindustriales, turísticos, comerciales, etc. Su plataforma tiene una particularidad única en el mundo, con sus más de 1,000 clientes corporativos y empresariales y sus más de 1,500 equipos de acceso, CPE, transporte, Core secundario y Core primario: EL 100% SON MARCA MIKROTIK. REICO es un ejemplo del gran potencial que tiene MikroTik y RouterOS ya que esta empresa compite en el mercado con grandes de las telecomunicaciones y aun así mantiene una posición privilegiada, siendo el cuarto operador en Costa Rica en importancia en Transporte de Datos Corporativos, por debajo de ICE, Tigo y de RACSA pero por encima de Claro, Telefónica, Cables & Wireless, etc. Esto según el último informe de Estadísticas del Sector de Telecomunicaciones de Costa Rica 2014. Texto desarrollado por el Ing. Miguel Solís, a quien agradezco por su aporte histórico sobre los inicios de MikroTik en Latinoamérica. Academy Xperts viii RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad con MikroTik RouterOS Detalle de cambios en las cinco últimas versiones de RouterOS Para una revisión más amplia del histórico de cambios en la versión 6.x le recomendamos visitar el siguiente link: http://abcxperts.com/index.php/bitacora-de-cambios v6.36, 20/Julio/2016, 14:09 address • Permite que se agreguen múltiples direcciones IP ya sea que ninguna o solo una esté habilitada address-list • Hace que la opción dynamic=yes sea de solo lectura (read-only) arm • Se agregó el soporte para el Dude Server • Se corrigió una falla de kernel cuando se tiene baja memoria arp • Se agregó la opción arp-timeout por interface bonding • Se corrigió el modo de balanceo de carga 802.3ad sobre túneles • Se corrigió la asignación del esclavo primario del bonding para interfaces OPVN después del arranque • Se corrigió un problema de caída en la transmisión del tráfico RoMON • Se implementó que el valor l2mtu sea más pequeño que las interfaces l2mtu esclavas. capsman • Se corrigió un problema de caída cuando se ejecutaba sobre OVPN certificate • Se agregó un retardo de renovación automática scep después del arranque para evitar todos los requerimientos de acceso CA al mismo tiempo • Se cancela la renovación pendiente cuando el certificado válido después del cambio de fecha • Se muestra el emisor y el asunto (subject) en una falla de chequeo • No se sale después de un card-verify • Se fuerza la renovación scep en las actualizaciones del reloj del sistema (system clock) chr • Se corrigió un problema en el CHR en el que estaba viendo su propio disco de sistema montado como un disco de datos adicional clock • Se corrigió un problema de tiempo que tenían los equipos SXT ac, 911L, cAP, mAP lite, wAP • Se graba el tiempo actual a la configuración una vez por día, incluso si no hay ajustes de zona de tiempo (time zone) pendientes cloud • Se corrigió el orden del export console • Se corrigió un problema en que obtenía una función falsa Academy Xperts ix RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad con MikroTik RouterOS • Se muestra la fecha del mensaje en los mensajes de log echo defconf • Se cambió la extensión del canal a 20/40/80mhz para todas las tarjetas ac dhcp-pd • Se corrige el lista de servidor por línea de comandos dhcp-server • Se corrigió un problema de adición de una ruta enmarcada como radius después de hacer reboot en la renovación de un cliente dhcp6-client • Se corrigió una validación de ia lifetime cuando es configurado por el cliente dhcpv6 dhcpv6-relay • Se configura el paquete link-address únicamente cuando se configura manualmente dhcpv6-server • Se corrigió el binding de la última actualización vista (last-seen update) disk • Se agregó soporte para Plextor PX-G128M62(A) SSD en CCR1072 dude • Los cambios se discuten en este link: http://forum.mikrotik.com/viewtopic.php?f=8&t=110428 • El paquete del server se ha hecho más pequeño. La actualización del contenido del lado del cliente ahora se remueve de él, y es descargado directamente desde nuestra nube. Por lo tanto las estaciones de trabajo en el lado del cliente requerirán acceso WAN. Se puede realizar una actualización alternativa reinstalando el cliente en cada nuevo release. email • Se corrigió el problema de envío desde Winbox • Se removió el límite de longitud del asunto (subject) y del cuerpo (body) del mensaje ethernet • Se corrigió un problema de falla de memoria cuando se configura la interface sin cambiar la configuración • Se corrigió un problema de velocidad de enlace incorrecta en ether1 después de hacer reboot en los routers de la serie rb4xx fastpath • Se corrigió un problema de falla del kernel cuando el fastpath maneja el paquete con multicast dst-address fetch • Se agregó soporte tls para las extensión del nombre de host firewall • No se muestra el parámetro disabled=no en un export • Se agregaron los connection tracking helpers udplite, dccp, sctp • Se corrigió el deletreo del comentario construido en el firewall • Se agregó el menú “/interface list” con el cual se permite crear una lista de interfaces que puede ser usado como un matcher in/out-interface-list en el firewall y utilizarlo como un filtro en traffic-flow • Se agregó el filtro pre-connection tracking – raw table, que permite proteger el connection tracking de tráfico innecesario • Se permite agregar un nombre de dominio al address-list (las entradas dinámicas para las direcciones resultas se agregarán a la lista especificada) gps • Se corrigió un problema en la parte de longitud segundos health • Se corrigió un problema de fábrica en la data de calibración de voltaje para algunas tarjetas hAP ac • Se corrigió un problema de voltaje incorrecto después de que se ejecutaba un reboot en un RB2011UAS icmp • Se corrigió un problema de fallo en el kernel cuando el paquete icmp no podía procesarse cuando había una alta carga ippool6 • Se corrigió un problema de caída en la adquisición cuando la longitud de prefijo es igual que la longitud de prefijo del pool ipsec • Se corrigió un problema en mode-config export Academy Xperts x RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad con MikroTik RouterOS • Se corrigió un problema de desborde de route cache cuando se utiliza ipsec con el route cache deshabilitado • Se agregó la excepción de detección del dead ph2 para Windows msgid que no es compatible con el rfc • Se agregó la detección de dead ph2 reply • No se registra temporalmente el ph2 en el dead list • Se corrigió un problema en el iniciador modecfg dynamics dns • Se corrigió el AH con SHA2 • Se corrigió un problema en el chequeo antes de accesar a las opciones ph1 nat • Se corrigió un problema de chequeo en Windows msgid en dispositivos x86 • Se muestra la dirección peer remota en los mensajes de error cuando sea posible • Se almacena el tipo de encapsulación udp en proposal kernel • Se corrigió un posible problema de punto muerto cuando se utiliza el modem Sierra USB l2tp • Se corrigió un problema de caída cuando se hace reboot o se deshabilita el l2tp mientras hay todavía conexiones activas lcd • Se redujo el valor más bajo del backlight-timeout de 5 minutos a 30 segundos license • No expira la licencia demo después de una instalación nueva de x86 log • Se agregó la opción scep certificate chain print • Se incrementó el umbral de advertencia por excesivo multicast/broadcast cada vez que es enviado a bitácora (log) • Se hace que el proceso de logging sea menos agresivo al arranque lte • Utiliza únicamente creg result codes como indicadores de estatus de red • Se agregó la opción allow-roaming para dispositivos Huawei MU709, ME909s • Se agregó soporte para cinterion pls8 • Se agregó soporte para Huawei E3531 • Se agregó soporte para ZTE ZM8620 • Se agregó la opción use-peer-dns (trabajará únicamente combinado con add-default-route) • Se cambió la carga del driver para dispositivos rndis usb clase 2 • Se muestra el mensaje en lte, error log si no se recibe respuesta • Se muestra el mensaje en lte, error log cuando se requiere PIN • Se corrigió un problema de caída en SXT LTE cuando se resetea la tarjeta en alto tráfico • Se corrigió la tecnología de acceso logging • Se corrigió la conexión para Huawei sin la info celular • Se corrigió el modem init cuando se presenta el requerimiento de pin • Se corrigió el chequeo de versión de configuración de red del modem • Se corrigió el soporte network-mode después de hacer un downgrade • El Huawei MU609 debe usar el último firmware para trabajar correctamente • Se mejoró la identificación de múltiples módems del mismo modelo • Se muestra el uicc para módems Huawei mesh • Se corrigió un problema de una caída cuando la conexión referencia a una red mesh pero que ya no está disponinble modem • Se agregó soporte para Alcatel OneTouch X600 • Se agregó soporte para Quectel EC21 y EC25 • Se agregó soporte para modem SpeedUP SU-900U nand • Se mejoró la característica de nand refresh para mejorar la integridad de la data almacenada ovpn • Se habilitó el soporte perfect forwarding secrecy por default • Se corrigió la compatibilidad con OpenVPN 2.3.11 pppoe • Se permite configurar el MTU y MRU más alto que 1500 para PPPoE • No se permite enviar paquetes más grandes que l2mtu si se provee el mrru proxy Academy Xperts xi RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad con MikroTik RouterOS • Se limita el uso máximo de ram a 80% para dispositivos tile y x86 queue • Se resetea el queue type en las interfaces en las cuales el default queue type cambia a no-queue después del upgrade rb2011 • Se corrigió el flapping ether6-ether10 cuando dos puertos de ambos switch chips están en el mismo bridge rb3011 • Se corrigió un problema de port flapping en las interface ether6-ether10 • Se corrigió un problema de funcionabilidad en el botón reset • Se mejoró el desempeño cuando existe un alto uso del CPU • Se corrigió un problema de carga del driver usb • Se corrigió un problema de montaje del almacenamiento usb route • Se agregó soporte para más de 8 bits de opciones • Se corrigió un problema en ospf manejando prefijos ipv6 codificados con stray bits sniffer • Se corrigió un problema de matching de dirección ipv6 snmp • Se corrigió la función get para snmp >= v2 cuando el oid no existe • Se corrigió las estadísticas de interface de MikroTik MIB • Reporta la tecnología de acceso actual y el cell id de los módems lte • Reporta la memoria ram como ram en lugar de otro tipo de memoria ssh • Se agrega el parámetro rsa host key size ssh-keygen • Se agrega el parámetro rsa key size ssl • No se sale mientras hay todavía sesiones activas • Se corrige una fuga de memoria en ssl connect/disconnect (Fetch, ovpn, etc.) sstp • Se corrige el soporte de nombre dns en el campo connect-to si se especifica el http-proxy supout • Se elimina apropiadamente la data de pánico en Netinstall switch • Se corrigió el switch compact export timezone • Se actualiza la información del timezone de release tzdata2016e traffic-flow • Se agregó el soporte ipfix (RFC5101 y RFC5102) tunnel • Se agregó la opción para auto detectar la local-address del túnel • Se corrigió un raro problema de caída cuando se especificaba una longitud de cabecera mínima inmediatamente en la inicialización del túnel upnp • Se corrigió la regla de nat dst-nat haciéndola visible nuevamente usb • El dongle usb hub/ethernet I-tec U3GLAN3HUB ahora se muestra correctamente como una interface ethernet • Se implementó la posibilidad de reconocer los dongles usb hubs/ethernet (si los usb hubs/ethernet-dongles no son reconocidos en esta versión, por favor enviar un archivo supout.rif) userman • Se corrigió un problema de caída en la carga de la base de datos • Se usa ipnpb.paypal.com para la verificación de pago wap-ac Academy Xperts xii RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad con MikroTik RouterOS • Se corrigen problemas de desempeño con wireless 2.4GHz (se requiere un reboot adicional después de hacer el upgrade) webfig • No se permite presionar OK o Apply si los valores actuales de configuración todavía no se han cargado • Se reduce el tiempo de refresh de la tabla de registro wireless a 1 segundo winbox • Se agregó la banda 2ghz-g/n para wireless-rep • Se agregaron los íconos para las acciones de bridge filter similar a ip firewall • Se agregó soporte para ipv6 dhcp relay • Se permite reordenar las reglas de hotspot walled-garden & walled-garden-ip • No se permite especificar vlam-mode=no-tag en capsman datapath config • No se muestra el filtro para los campos combinados como bgp-vpn4 RD • No se muestra la configuración de modo para las interfaces WDS • Se corrige un problema de caída en la desconexión en modo seguro • Se corrige un problema de caída cuando se usa ctrl+d • Se corrige un problema en el modo safe • Se mejora el filtrado en los campos de lista • Se reporta correctamente los usuarios de Dude en la lista de usuarios activos • Se configura por default el valor de sa-learning a “yes” para las reglas CRS Ingress VLAN Translation • Se muestra la columna de acción como primera en bridge firewall • Se muestra error cuando telnet no está permitido debido a permisos wireless • Se corrigió un problema en que múltiples paquetes wireless se habilitaban al mismo tiempo después del upgrade • Se descontinúa wireless-fp. Es necesario que se desinstale/deshabilite antes de hacer el upgrade wireless-rep • Se agregó el soporte inicial API para snooper • Se corrigió un problema de caída al reconectar nv2 • Se corrigió un problema en un scan-list no configurado • Se trata el elemento missing SSID como hidden SSID v6.35.4, 09/Junio/2016, 12:02 address-list • Se hizo que dynamic=yes sea una opción read-only (solo lectura) bonding • Se corrigió un problema en el modo de balanceo 802.3ad sobre túneles • Se corrigió un problema de asignación del esclavo en el bonding primario para interfaces OVPN ñuego de que se inicia • Se corrigió un problema de caída en la transmisión de tráfico RoMON dhcpv6 client • Se corrigió un problema de validación ia lifetime cuando se configura por el cliente dhcpv6 disk • Se agregó soporte para Plextor PX-G128M6e(A) SSD en el CCR1072 ethernet • Se corrigió un problema de falla de memoria cuando se configura la interface sin cambiar la configuración firewall • No se muestra el parámetro disabled=no en un export health • Se corrigió un problema de fábrica en la data de calibración de voltaje para algunas tarjetas hAP ac • Se corrigió un problema de voltaje incorrecto después de que se ejecutaba un reboot en un RB2011UAS ipsec • Se corrigió un problema en mode-config export • Se corrigió un problema de desborde de route cache cuando se utiliza ipsec con el route cache deshabilitado lte • Utiliza únicamente creg result codes como indicadores de estatus de red ovpn • Se habilita el soporte perfect forwarding secrecy por default rb3011 Academy Xperts xiii RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad con MikroTik RouterOS • Se corrigió un problema de port flapping en las interface ether6-ether10 • Se corrigió un problema de funcionabilidad en el botón reset • Se mejoró el desempeño cuando existe un alto uso del CPU v6.35.3, 01/Junio/2016, 07:55 Fue un release únicamente de fábrica v6.35.2, 02/Mayo/2016, 10:09 discovery • Se corrigió un problema del descubrimiento de identidad (se introdujo en v6..35.1) firewall • Se corrigió un problema en las configuraciones de políticas de ruteo (se introdujo en v6.35rc38) log • Se corrigió un problema de ajuste del time zone (se introdujo en v6.35.1) queue • Se corrigió un problema del queue type en la interface para túneles OVPN snmp • Se corrigió un problema de timeout snmp (se introdujo en v6.35.1) vrrp • Se corrigió un problema de interfaces vrrp perdidas después de hacer un upgrade (se introdujo en v6.35.1) v6.35.1, 26/Abril/2016, 09:29 bonding • No se corrompen las estadísticas bonding en los cambios de configuración • Se corrigió un problema de caída cuando el MTU de la VLAN padre es más alto que el MTU del bonding ethernet • No se permite que el MTU sea más alto que el L2MTU, y que el L2MTU sea más alto que el MAX-L2MTU (se reduce automáticamente en el upgrade si es que estaba equivocado anteriormente) log • Se corrigieron los mensajes de log en el reboot LTE • No se permiten configurar múltiples modos cuando no está soportado • Se corrigió la adquisición de dirección (address acquisition) en las interfaces Huaweii LTE winbox • Se muestra el voltaje en Health únicamente si es el monitor de voltaje wireless • Se corrigió un problema cuando el CAPsMAN podía bloquear la interface CAPs Academy Xperts xiv RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 1: Ruteo en RouterOS Capítulo 1: Ruteo en RouterOS RIP, FIB, rutas Multipath, nexthop lookup En RouterOS el router almacena la información de ruteo (Routing) en varios espacios separados: • FIB (Forwarding Information Base).- Se utiliza para realizar las decisiones de reenvío de paquetes. El FIB contiene un copia de la información necesaria de ruteo. • Cada protocolo de ruteo (excepto BGP) posee sus propias tablas internas. Este es el sitio donde se realizan las decisiones de ruteo basadas por-protocolo. BGP no posee tablas internas de ruteo. BGP almacena la información completa de ruteo de todos los compañeros (peers) en el RIB. • RIB (Routing Information Base).- Contiene las rutas agrupadas en tablas de ruteo separadas basadas en sus valores de routing-mark. Todas las rutas que no poseen routing-mark se almacenan en la tabla principal de ruteo (main routing table). Estas tablas se utilizan para una mejor selección de ruta. La tabla principal (main) también se la utiliza para el nexthop lookup. RIB – Routing Information Base El RIB contiene la información completa de ruteo, incluyendo: • Las reglas de rutas estáticas definidas por el usuario • Las reglas de políticas de ruteo definidas por el usuario • La información de ruteo aprendida por los protocolos de ruteo • La información sobre las redes conectadas El RIB se utiliza para: • Filtrar la información de ruteo • Calcular la mejor ruta para cada prefijo de destino • Construir y actualizar la FIB (Forwarding Information Base) • Distribuir las rutas entre diferentes protocolos de ruteo Por default, la decisión de reenvío (forwarding) se basa únicamente en el valor de la dirección destino. Cada ruta tiene la propiedad dst-address, que especifica todas las direcciones destino en las que esta ruta puede ser usada. Si existen varias rutas que aplican para una dirección IP particular, se utiliza la más específica (la que tenga el netmask más largo). Esta operación (encontrar la ruta más específica que coincida con una dirección dada) se conoce como routing table lookup (tabla de enrutamiento de búsqueda). Si la tabla de ruteo contiene varias rutas con la misma dst-address, únicamente una ruta puede ser utilizada para el reenvío de los paquetes. Esta ruta se instala dentro del FIB y se marca como activa (active). Cuando la decisión de reenvío (forwarding decision) utiliza información adicional, como por ejemplo una dirección origen del paquete, se lo conoce como política de ruteo (policy routing). La política de ruteo se implementa como una “lista de políticas de reglas de ruteo”, que selecciona una diferente tabla de ruteo basado en la dirección destino, dirección origen, interface origen y marca de ruteo (routing mark) del paquete. La marca de ruteo puede ser cambiada por las reglas de mangle en firewall. Todas las rutas se graban por default en la tabla principal de ruteo (main routing table). Las rutas pueden ser asignadas a una tabla de ruteo específica configurando su propiedad routing-mark a nombre de otra tabla de enrutamiento. Las tablas de ruteo se referencian por su nombre, y se crean automáticamente cuando son referenciadas en la configuración. Cada tabla de ruteo puede tener solamente una ruta activa para cada valor de prefijo de dst-address IP. Existen diferentes grupos de rutas , basados en sus orígenes y propiedades: Academy Xperts 1 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 1: Ruteo en RouterOS • Rutas por default • Rutas conectadas • Rutas Multipath (ECMP) • Rutas con interface como Gateway Ruta por Default La ruta con dst-address=0.0.0.0/0 se aplica a todas las direcciones destino. Esta ruta se conoce como ruta por default. Si la tabla de ruteo contiene una ruta por default activa, entonces la tabla de enrutamiento de búsqueda (routing table lookup) en esta tabla nunca fallará. Rutas Conectadas Las rutas conectadas se crean automáticamente para cada red IP que tiene al menos una interface habilitada conectada. El RIB rastrea el estatus de las rutas conectadas, pero no las modifica. Para cada ruta conectada hay una dirección IP tal que: • Parte de la dirección del dst-address de la ruta conectada es igual a la network (red) de la dirección IP • Parte del netmask del dst-address de la ruta conectada es igual a parte del netmask del address de la dirección IP • El pref-src de la ruta conectada es igual a parte de la dirección del address de la dirección IP • La interface de la ruta conectada es igual al actual-interface de la dirección IP (similar a interface, excepto para los puertos de interface bridge) Ruta Multipath (ECMP) Para implementar algunas configuraciones, como por ejemplo balanceo de carga (load balancing) puede ser necesario utilizar más de un camino (path) hacia un destino dado. Sin embargo, no es posible tener más de una ruta activa hacia una destino en una tabla de ruteo simple. ECMP = Equal Cost Multi-Path = Múltiples trayectorias de costos iguales Las rutas ECMP tienen múltiples valores de gateway de siguiente salto (nexthop). Todos los nexthop (siguientes saltos) son copiados al FIB y utilizados en el reenvío de paquetes. El protocolo OSPF puede crear rutas ECMP. Estas rutas pueden también ser creadas manualmente. Puesto que los resultados de las decisiones de reenvío (forwarding) son almacenadas en caché, los paquetes con el mismo source address, destination address, source interface, routing mark y ToS, son enviados al mismo gateway. Esto significa que una conexión utilizará solamente un enlace en cada dirección, por lo tanto las rutas ECMP pueden ser usadas para implementar balanceo de carga por conexión (per-connection). Rutas con interface como Gateway El valor del gateway puede ser especificado como un nombre de interface en lugar de la dirección IP del próximo salto. Una ruta creada de esta forma tiene las siguientes propiedades especiales: • A diferencia de las rutas conectadas, las rutas que tienen como nexthop una interface, no se utilizan para el nexthop lookup • Es posible asignar varias interfaces como un valor de gateway, y crear una ruta ECMP. No se puede tener una ruta conectada con múltiples valores de gateway. Selección de Ruta Cada tabla de ruteo puede tener una ruta activa para prefijo destino. Esta ruta es instalada dentro del FIB. La ruta activa es seleccionada de todas las rutas candidatas con el mismo dst-address y routing-mark, que cumplen el criterio para ser Academy Xperts 2 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 1: Ruteo en RouterOS una ruta activa. Puede haber múltiples rutas de diferentes protocolos de ruteo y de configuración estática. La ruta candidata con la distancia (distance) más baja se convertirá en ruta activa. Si existe más de una ruta candidata con la misma distancia (distance), la selección de la ruta activa es arbitraria (excepto para las rutas BGP). BGP tiene el proceso de selección más complicado. Es importante notar que esta selección de protocolo interno se realiza únicamente después de que las rutas BGP son instaladas en la tabla principal de ruteo; esto significa que puede haber más de una ruta candidata para cada compañero (peer) BGP. También es importante notar que las rutas BGP de diferentes instancias BGP son comparadas por su distancia, igual que otras rutas. Criterio para la sección de las rutas candidatas Para participar en el proceso de selección de rutas, la ruta debe cumplir los siguientes criterios: • La ruta no debe estar deshabilitada • La distancia (distance) no debe ser 255. Las rutas que son rechazadas por el filtro de ruta tienen un valor de distancia (distance) 255 • pref-src no se ha configurado o es una dirección local válida del router • routing-mark no se ha configurado o está referida por el firewall o por las reglas de política de enrutamiento • Si el tipo de ruta es unicast y no es una ruta conectada, debe tener al menos un nexthop alcanzable Nexthop lookup El nexthop lookup (búsqueda del siguiente salto) es parte del proceso de selección de ruta. Las rutas que están instaladas en el FIB necesitan tener la interface asociada con cada dirección de gateway. La dirección de gateway (nexthop = próximo salto) tiene que ser directamente alcanzable a través de esta interface. La interface que debería ser usada para enviar los paquetes a cada dirección de gateway se encuentra haciendo nexthop lookup. Algunas rutas (por ejemplo iBGP) pueden tener una dirección de gateway que está varios saltos más allá de este router. Para instalar tales rutas en la FIB, es necesario encontrar la dirección del gateway alcanzable directamente (un nexthop inmediato), que debería ser usado para alcanzar la dirección de gateway de esta ruta. Las direcciones inmediatas del nexthop pueden también ser encontradas haciendo nexthop lookup. EL nexthop lookup se realiza únicamente en la tabla principal de ruteo, incluso para las rutas con un diferente valor de routing-mark. Es necesario restringir el conjunto de rutas que pueden ser usadas para buscar por nexthops inmediatos. Los valores de nexthop de las rutas RIP u OSPF, por ejemplo, se supone que son alcanzadas directamente y que deberían ser encontradas únicamente usando las rutas conectadas. Esto se puede lograr usando las propiedades scope y target- scope. • Las rutas que tienen un nombre de interface como gateway, no se pueden utilizar para el nexthop lookup. Si la ruta tiene ambos: interface nexthop y un nexthop con dirección IP activa, entonces se ignoran los nexthop de interface. • Las rutas con un scope mayor que el máximo valor aceptado no se utilizan para el nexthop lookup. Cada ruta especifica un valor de scope máximo aceptado para sus nexthops en la propiedad target-scope. El valor por default de esta propiedad permite el nexthop lookup únicamente a través de las rutas conectadas, con la excepción de las rutas iBGP que tienen un valor por default más grande y que pueden buscar por el nexthop a través de IGP y las rutas estáticas. La interface y el nexthop inmediato se seleccionan basado en el resultado del nexthop lookup: • Si la ruta activa más específica que el nexthop lookup encuentra es una ruta conectada, entonces la interface de esta ruta conectada es usada como la interface nexthop, y este gateway se marca como alcanzable (reachable). Puesto que el gateway es directamente alcanzable a través de esta interface (esto es exactamente lo que una ruta conectada significa), la dirección del gateway es usada como la dirección inmediata del nexthop. • Si la ruta activa más específica que el nexthop lookup encuentra tiene un nexthop que ya está resuelto, la dirección del nexthop resuelto y la interface es copiada del nexthop y este gateway es marcado como recursivo (recursive). Academy Xperts 3 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 1: Ruteo en RouterOS • Si la ruta activa más específica que el nexthop lookup encuentra es una ruta ECMP, entonces usa el primer gateway de esa ruta que es no inalcanzable (unreachable). • Si el nexthop no encuentra ninguna ruta, entonces este gateway es marcado como inalcanzable (unreachable). FIB – Forwarding Information Base El FIB contiene copia de la información que es necesaria para el reenvío del paquete (packet forwarding): • Todas las rutas activas • Reglas de políticas de ruteo Por default (cuando no se utilizan valores de routing-mark) todas las rutas activas están en la tabla principal, y existe una única regla implícita oculta (regla “catch all”) que usa la tabla principal para todos los lookup destinos. Tabla de ruteo lookup El FIB utiliza la siguiente información del paquete para determinar su destino: • Dirección origen • Dirección destino • Interface origen • Routing mark • ToS (no es utilizado por RouterOS en las reglas de políticas de ruteo, pero es una parte de la clave de lookup del caché de ruteo) Las posibles decisiones de ruteo son: • Recibir el paquete localmente • Descartar el paquete (ya sea silenciosamente o enviando un mensaje ICMP al originador del paquete) • Enviar un paquete a una dirección IP específica en una interface específica Los resultados de las decisiones de ruteo son recordadas en el caché de ruteo. Esto se realiza para mejorar el desempeño del forwarding. Cuando otro paquete con el mismo source address, destination address, source interface, routing mark y ToS es ruteado, se utilizan los resultados en caché. Esto también permite implementar el balanceo de carga por conexión (per-connection load balancing) usando rutas ECMP, puesto que los valores usados para encontrar la entrada en el cache de ruteo (routing cache) son los mismos para todos los paquetes que pertenecen a la misma conexión y van en la misma dirección. Si no existe una entrada en el routing cache para este paquete, entonces se la crea ejecutando una decisión de ruteo: • Se chequea que el paquete tiene que ser entregado localmente (la dirección destino es la dirección del router) • Procesar las reglas de políticas de ruteo implícitas • Procesar las reglas de políticas de ruteo agregadas por el usuario • Procesar la regla implícita “catch-all” que busca el destino en la tabla principal de ruteo • El retorno del resultado es “network unreachable” Academy Xperts 4 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 1: Ruteo en RouterOS Las reglas que no concuerdan con el paquete actual son ignoradas. Si la regla tiene la acción drop o unreachable, entonces se retorna como un resultado del proceso de la decisión de ruteo. Si la acción es lookup entonces la dirección destino del paquete es buscada en la tabla de ruteo que se especifica en la regla. Si la búsqueda falla (no existe una ruta que coincida con la dirección destino del paquete), entonces el FIB procede a la siguiente regla. Por otra parte: • Si el tipo de ruta es blackhole, prohibit o unreachable, entonces se retorna esta acción como el resultado de la decisión de ruteo • Si esta es una ruta conectada, un ruta con una interface como el valor de gateway, entonces se retorna esta interface y la dirección destino del paquete como el resultado de la decisión de ruteo • Si esta ruta tiene una dirección IP como el valor de gateway, entonces se retorna esta dirección y la interface asociada como el resultado de la decisión de ruteo • Si esta ruta tiene múltiples valores de nexthop, entonces se elige uno en un esquema round robin. El resultado de la decisión de ruteo se almacena en una nueva entrada del routing caché. El resultado de la decisión de ruteo puede ser: • Dirección IP del nexthop + interface • Interface punto-a-punto • Entrega local (local delivery) • Descartar (discard) • ICMP prohibido • ICMP host unreachable • ICMP network unreachable Propiedades de la Tabla de Ruteo Etiquetas de ruta • disabled (X).- Regla de ruteo está deshabilitada. No tiene ningún efecto sobre las otras rutas y no se utiliza de ninguna manera para reenvío (forwarding) o protocolos de ruteo. • active (A).- Ruta se utiliza para el reenvió de paquetes. Denota una ruta activa. • dynamic (D).- Regla de ruteo creada por el software y no por la interface de administración. No se exporta, y no puede ser modificado directamente. • connect (C).- Ruta conectada. Se genera cuando se configura una dirección IP en una interface activa • static (S).- Ruta estática. Ruta creada por el usuario de manera fija. Este método forzará el envío de paquetes a través de un gateway definido por el usuario/administrador • rip (r).- Ruta RIP • bgp (b).- Ruta BGP • ospf (o).- Ruta OSPF • mme (m).- Ruta MME • blackhole (B).- Descarta silenciosamente el paquete reenviado por esta ruta • unreachable (U).- Descarta los paquetes reenviados por esta ruta. Se notifica al originador del paquete por medio de un mensaje ICMP host unreachable (tipo 3, código 1) • prohibit (P).- Descarta los paquetes reenviados por esta ruta. Se notifica al originador del paquete por medio de un mensaje ICMP communication administratively prohibited (tipo 3, código 13) Academy Xperts 5 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 1: Ruteo en RouterOS Propiedades generales /ip route add bgp-as-path bgp-origin disabled route-tag vrf-interface bgp-atomic-aggregate bgp-prepend distance routing-mark bgp-communities check-gateway dst-address scope bgp-local-pref comment gateway target-scope bgp-med copy-from pref-src type • check-gateway (arp | ping; Default: "").- Periódicamente (cada 10 segundos) se chequea el gateway enviando ya sea un ICMP echo request (ping) o un ARP request (arp). Si no se recibe respuesta del gateway en 10 segundos, se solicita un tiempo de espera (request times out). Después de dos timeouts el gateway se considera inalcanzable (unreachable).- Después de recibir una respuesta del gateway se con considera alcanzable (reachable) y el contador de timeout se resetea. • comment (string; Default: "").- Es la descripción de una ruta particular • distance (integer[1..255]; Default: "1").- Valor usado en la selección de ruta. Las rutas con valores de distancia más pequeños tendrán preferencia. Si no se especifica el valor de esta propiedad, entonces el valor default depende del protocolo de ruteo: § connected routes: 0 (rutas conectadas) § static routes: 1 (rutas estáticas) § eBGP: 20 § OSPF: 110 § RIP: 120 § MME: 130 § iBGP: 200 • dst-address (IP prefix; Default: 0.0.0.0/0).- Prefijo IP de la ruta, especifica las direcciones destino para la que esta ruta puede ser utilizada. La parte netmask de esta propiedad especifica cuántos de los bits más significantes en la dirección del paquete destino deben coincidir con este valor. Si existen varias rutas activas que coinciden con la dirección destino del paquete , entonces se utilizará la más específica (el que tenga el valor de netmask más grande). • gateway (IP | interface | IP%interface | IP@table[, IP | string, [..]]; Default: "").- Arreglo de direcciones IP o nombres de interface. Especifica a cuál host o interface deberían ser enviados los paquetes. Las rutas conectadas y las rutas con tipo blackhole, unreachable o prohibit no tienen estas propiedad. Usualmente el valor de esta propiedad es una dirección IP sencilla de un gateway que puede alcanzado directamente a través de una de las interfaces del router. Las rutas ECMP tienen más de un valor de gateway. El valor puede ser repetido varias veces. • pref-src (IP; Default: "").- Cuál de las direcciones IP locales se utilizará para los paquetes originados localmente que son enviados a través de esta ruta. El valor de esta propiedad no tiene efecto en los paquetes reenviados. Si el valor de esta propiedad se configura con una dirección IP que no es la dirección local de este router, entonces la ruta se volverá inactiva. Si no se configura el valor pref-src, entonces para los paquetes originados localmente que son enviados usando esta ruta, el router elegirá una dirección local anexada a la interface de salida que coincida con el prefijo destino de la ruta. • route-tag (integer; Default: "").- Valor del atributo la etiqueta de ruta para RIP u OSPF. Para RIP los únicos valores válidos son 0..4294967295 • routing-mark (string; Default: "").- Nombre de la tabla de ruteo que contiene esta ruta. No se configura por default porque es el mismo que la tabla principal de ruteo. Los paquetes que son marcados por el firewall con este valor de routing-mark serán ruteados usando las rutas de esta tabla, a menos que sean anulados por las reglas de políticas de ruteo. No se puede usar más de 250 routing-mark por router. • scope (integer[0..255]; Default: "30").- Usado en la resolución del nexthop. La ruta puede resolver el nexthop únicamente a través de las rutas que tienen scope menor o igual al target-scope de esta ruta. El valor por default depende del protocolo de ruteo: § connected routes: 10 (si la interface está corriendo) § OSPF, RIP, MME routes: 20 Academy Xperts 6 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 1: Ruteo en RouterOS § static routes: 30 § BGP routes: 40 § connected routes: 200 (si la interface NO está corriendo) • target-scope (integer[0..255]; Default: "10").- Utilizado en la resolución del nexthop. Este es el valor máximo de scope para una ruta a través del cual un nexthop de esta ruta puede ser resuelto. Para iBGP el valor se configura por default en 30. • type (unicast | blackhole | prohibit | unreachable; Default: unicast).- Rutas que no especifican nexthop para los paquetes, pero que el cambio desarrollan alguna otra acción en los paquetes que tienen un tipo diferente del usual unicast. § blackhole – esta ruta descarta silenciosamente los paquetes § unreachable – envía el mensaje ICMP Destination Unreachable (código 1) a la dirección origen del paquete § prohibit – envía el mensaje ICMP Destination Unreachable (código 13) a la dirección origen del paquete • vrf-interface (string; Default: "10").- Nombre de la interface VRF Propiedades de solo-lectura • gateway-status (array).- Arreglo de gateways, estados de los gateway y cuál interface es usada para reenvío. Sintaxis del estado IP de la interface, por ejemplo 10.5.101.1 reachable bypass-bridge. El estado puede ser unreachable, reachable o recursive. • ospf-metric (integer).- Usado para la métrica OSPF para una ruta en particular. • ospf-type (string) Propiedades de Ruta BGP /ip route add bgp-as-path bgp-origin disabled route-tag vrf-interface bgp-atomic-aggregate bgp-prepend distance routing-mark bgp-communities check-gateway dst-address scope bgp-local-pref comment gateway target-scope bgp-med copy-from pref-src type These properties contain information that is used by BGP routing protocol. However, values of these properties can be set for any type of route, including static and connected. It can be done either manually (for static routes) or using route filters. bgp-as-path (string; Default: "") Value of BGP AS_PATH attribute. Comma separated list of AS numbers with confederation AS numbers enclosed in () and AS_SETs enclosed in {}. Used to check for AS loops and in BGP route selection algorithm: routes with shorter AS_PATH are preferred (but read how AS_PATH length is calculated). bgp-atomic-aggregate (yes | no; Default: ) Value of BGP ATOMIC_AGGREGATE attribute. bgp-communities (array of (integer:integer | internet | no-advertise | no-export |local-as; Default: ) Value of BGP communities list. This attribute can be used to group or filter routes. Named values have special meanings: internet - advertise this route to the Internet community (i.e. all routers) no-advertise - do not advertise this route to any peers no-export - do not advertise this route to EBGP peers local-as - same as no-export, except that route is also advertised to EBGP peers inside local confederation Academy Xperts 7 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 1: Ruteo en RouterOS bgp-local-pref (integer; Default: ) Value of BGP LOCAL_PREF attribute. Used in BGP route selection algorithm: routes with greater LOCAL_PREF value are preferred. If value is not set then it is interpreted as 100. bgp-med (integer; Default: ) Value of BGP MULTI_EXIT_DISC BGP attribute. Used in BGP route selection algorithm: routes with lower MULTI_EXIT_DISC value are preferred.. If value is not set then it is interpreted as 0. bgp-origin (igp | egp | incomplete; Default: ) Value of BGP ORIGIN attribute. Used in BGP route selection algorithm: igp routes are preferred over egp and egp over incomplete. bgp-prepend (integer [0..16]; Default: ) How many times to prepend router's own AS number to AS_PATH attribute when announcing route via BGP. Affects only routes sent to eBGP peers (for iBGP value 0 is always used). Propiedades de solo-lectura bgp-ext-communities (string) Value of BGP extended communities attribute bgp-weight (integer) Additional value used by BGP best path selection algorithm. Routes with higher weight are preferred. It can be set by incoming routing filters and is useful only for BGP routes. If value is not set then it is interpreted as 0. received-from (string) Name of the BGP peer from which route is received. Academy Xperts 8 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 2: Ruteo Estático Simple Capítulo 2: Ruteo Estático Simple Distancia, política de ruteo, ECMP, Scope, dead-end, recursividad Ruteo Simple Enrutamiento es el reenvío de tráfico de una red a otra, paquete por paquete. El Forwarding consiste en pasar la responsabilidad de un enrutador a otro, es decir, un enrutador decide como enviar un paquete y se desentiende de lo que le pueda pasar al mismo de ahí para adelante, todo esto basado en la información de la mejor ruta y la métrica (distancia) que este configurada. • Solo un gateway para una simple red • Las rutas más específicas en la tabla de ruteo tienen la prioridad más alta que las rutas menos específicas • La ruta con destino de red 0.0.0.0/0 significa “todo lo demás” también conocida como Ruta por Default Lab. 2.1 – Ruteo Estático Objetivos • Crear una red ruteada redundante sin usar protocolos de ruteo dinámicos • Rutear entre las redes locales participantes • Obtener acceso a otros grupos de redes Usando solamente Rutas Estáticas Simples se debe asegurar la conectividad entre las estaciones de trabajo (laptops). Esto significa que cada uno de los estudiantes deberá estar en capacidad de realizar un ping satisfactorio a los demás computadores en esta red. Por ejemplo, el Estudiante A deberá poder llegar con un ping a las laptops de los Estudiantes B, C y D. Es muy probable que las laptops de los estudiates posean restricciones por firewall o antivirus, y que estas restricciones pudieran no ser desactivadas. En este caso basta con que el ping se realice satisfactoriamente contra ladirección IP de las interfaces LAN (ether1) de los routers de los estudiantes remotos. Por ejemplo, el Estudante A (172.16.1.2) deberá poder llegar con ping a las interfaces ether1 de los routers remotos cuyas direcciones IP son 172.16.2.1 (ether1 router Estudiante B), 172.16.3.1 (ether1 router Estudiante C) y 172.16.4.1 (ether1 router Estudiante D) Actividades a realizar Paso 1 (backup) • Cada estudiante deberá hacer un respaldo (backup) de la configuración actual que provee acceso a internet a través del router asignado. Paso 2 (reset) • Cada estudiante debe ejecutar un /system reset-configuration no-defaults=yes de tal manera que la configuración del router quede completamente en blanco Paso 3 (solo direcciones IP) • Cade estudiante debe configurar únicamente las direcciones IP de las interfaces ether1, ether2 y ether3, y la dirección de su laptop según las especificaciones del la Fig.2.1.1 • De igual manera los estudiantes deberán conectar los cables de red en la forma en que está descrita en la Fig.2.1.1 • En este punto AUN NO se debe configurar las rutas para llegar a las redes remotas. • No debe existir nunguna regla de NAT en ninguno de los routers. Academy Xperts 9 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 2: Ruteo Estático Simple • Cuando todos los estudiantes de esta red hayan configurado las direcciones IP, cada uno de ellos deberá poder realizar un ping satisfactorio a las direcciones IP de las WAN remotas adyacentes (UNICAMENTE a las adyacentes) Escenario Paso 4 (rutas estáticas) • En este punto cada Estudiante debe configurar en su router asignado las rutas para llegar a las redes remotas • La asignación del gateway deberá realizarse siguiendo el sentido de las manecillas del reloj • La tabla de rutas de cada router debe quedar de la siguiente forma: Router dst-address Gateway 172.16.2.0/24 10.1.1.2 RA 172.16.3.0/24 10.1.1.2 172.16.4.0/24 10.1.1.2 172.16.3.0/24 10.1.1.6 RB 172.16.4.0/24 10.1.1.6 172.16.1.0/24 10.1.1.6 172.16.4.0/24 10.1.1.10 RC 172.16.1.0/24 10.1.1.10 172.16.2.0/24 10.1.1.10 172.16.1.0/24 10.1.1.14 RD 172.16.2.0/24 10.1.1.14 172.16.3.0/24 10.1.1.14 • Puede hacer ping a las redes LAN remotas? • Para este ejercicio es suficiente con que pueda realizar un ping a la dirección IP 172.16.x.1 que corresponde a la interface ether1 remota de cada router. • Puede hacer ping a las redes LAN remotas? Paso 5 (rutas estáticas – continuación) • Se debe agregar las siguientes entradas en la tabla de rutas de cada router: Router dst-address Gateway 172.16.2.0/24 10.1.1.2 172.16.3.0/24 10.1.1.2 RA 172.16.4.0/24 10.1.1.2 10.1.1.4/30 10.1.1.2 10.1.1.8/30 10.1.1.2 172.16.3.0/24 10.1.1.6 172.16.4.0/24 10.1.1.6 RB 172.16.1.0/24 10.1.1.6 10.1.1.8/30 10.1.1.6 10.1.1.12/30 10.1.1.6 172.16.4.0/24 10.1.1.10 172.16.1.0/24 10.1.1.10 RC 172.16.2.0/24 10.1.1.10 10.1.1.12/30 10.1.1.10 10.1.1.0/30 10.1.1.10 172.16.1.0/24 10.1.1.14 RD 172.16.2.0/24 10.1.1.14 Academy Xperts 10 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 2: Ruteo Estático Simple 172.16.3.0/24 10.1.1.14 10.1.1.0/30 10.1.1.14 10.1.1.4/30 10.1.1.14 • Puede hacer ping a las redes LAN remotas? • Que puede concluir en comparación con los resultados obtenidos en el paso 5? -------------------------------------------------------------------------------------------------------------------------------------------------------- ---- -------------------------------------------------------------------------------------------------------------------------------------------------------- ---- Paso 6 (rutas estáticas – ruta por default) • Se debe reemplazar las rutas esteatica anteriore por la ruta por default: Router dst-address Gateway RA 0.0.0.0/0 10.1.1.2 RB 0.0.0.0/0 10.1.1.6 RC 0.0.0.0/0 10.1.1.10 RD 0.0.0.0/0 10.1.1.14 • Puede hacer ping a las redes LAN remotas? • Que puede concluir en comparación con los resultados obtenidos en el paso 5 y en el paso 6? -------------------------------------------------------------------------------------------------------------------------------------------------------- ---- -------------------------------------------------------------------------------------------------------------------------------------------------------- ---- Rutas ECMP (Equal Cost Multi Path) Este mecanismo de ruteo habilita el ruteo de paquetes entre múltiples caminos (paths) y asegura el balanceo de carga. Con ruteo ECMP se puede usar más de un gateway para una red destino. Esto NO significa que provee Failover!!! Con ECMP un router tiene potencialmente varios Next-hops disponibles hacia un destino dado. Un nuevo gateway es elegido para cada nuevo par IP source/destination. Esto significa que, por ejemplo, una conexión FTP usará solo un enlace, pero una nueva conexión a un server diferente usará otro enlace. Una característica importante de ECMP es que los paquetes de conexión simple no son reordenados y por lo tanto no afecta al performance de TCP. Las rutas ECMP pueden ser creadas por protocolos de ruteo (RIP u OSPF), o añadiendo una ruta estática con múltiples gateways, separados con una coma. /ip route add gateway=192.168.0.1, 192.168.1.1 Los protocolos de ruteo pueden crear rutas dinámicas multi-path con igual costo de forma automática. Tiene los siguientes Puntos: • Las rutas ECMP tienen más de un gateway a la misma red remota • Los gateway serán usados en un esquema de combinación de direcciones Round Robin per SRC/DST. • El mismo gateway puede ser escrito muchas veces. Academy Xperts 11 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 2: Ruteo Estático Simple Opción “Check-gateway” • Se puede configurar el router para chequear la accesibilidad del gateway usando PROTOCOLOS ICMP (ping) o ARP • En Ruteo Simple, si un gateway no puede ser alcanzado, la ruta será declarada inactiva • En Ruteo ECMP, si un gateway no pude ser alcanzado, solamente los gateways disponibles serán usados en el algoritmo Round Robin • Si se habilita la opción Check-gateway en una ruta, se afectarán todas las rutas con ese gateway Lab. 2.2 – Ruteo ECMP Objetivos Usando rutas ECMP se debe asegurar la conectividad entre las estaciones de trabajo (laptops). Esto significa que cada uno de los estudiantes deberá estar en capacidad de realizar un ping satisfactorio a los demás computadores en esta red. Por ejemplo, el Estudiante A deberá poder llegar con un ping a las laptops de los Estudiantes B, C y D. Es muy probable que las laptops de los estudiates posean restricciones por firewall o antivirus, y que estas restricciones pudieran no ser desactivadas. En este caso basta con que el ping se realice satisfactoriamente contra ladirección IP de las interfaces LAN (ether1) de los routers de los estudiantes remotos. Por ejemplo, el Estudante A (172.16.1.2) deberá poder llegar con ping a las interfaces ether1 de los routers remotos cuyas direcciones IP son 172.16.2.1 (ether1 router Estudiante B), 172.16.3.1 (ether1 router Estudiante C) y 172.16.4.1 (ether1 router Estudiante D) Actividades a realizar Paso 1 • Cada estudiante deberá eliminar las rutas (en la tabla principal de rutas) generadas en el ejercicio anterior. Paso 2 (para evitar lazos o routing loops) • Solo un participante crea una ruta ECMP para cada red 172.16.x.0/24 con check-gateway=ping • Los otros participantes ajustan las rutas simples para alcanzar alcanzar al otro • Se debe chequear el funcionamiento de la redundancia • Recuerda usar traceroute para examinar la configuración • Como ejemplo, la siguiente sería la configuración que debe ejucutar el Estudiante A /ip route add dst-address=172.16.2.0/24 gateway=10.1.1.2,10.1.1.13 check-gateway=ping /ip route add dst-address=172.16.3.0/24 gateway=10.1.1.2,10.1.1.13 check-gateway=ping /ip route add dst-address=172.16.4.0/24 gateway=10.1.1.2,10.1.1.13 check-gateway=ping • Esta es la forma como se vería la tabla principal de rutas en el router del Estudiante A • Recuerde que los demás estudiantes deben crear y ajustar las rutas para llegar a las redes remotas SIN usar ECMP Paso 3 (para evitar lazos o routing loops, siguientes estudiantes) • Se debe proceder similar a lo ejecutado en el paso-2 con el siguiente participante, hasta que los 4 estudiantes puedan completar el ejercicio. Lab. 2.3.1 – Ruteo ECMP para balanceo de carga Objetivos Aplicar balanceo de carga usando ECMP Actividades a realizar Paso 1 • Se debe trabajar en grupos de 2 estudiantes • El instructor debe asignar otr router para que puedan completar la práctica Academy Xperts 12 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 2: Ruteo Estático Simple • El Instructor debe configurar 2 AP Virtuales. Cada AP debe tener una subred diferente. El instructor debe configurar un server DHCP en cada AP virtual, y debe asegurar la salida a internet de cada una de esas rubredes. • Los estudiantes deben configurar RA y RB como estaciones, recibir de manera dinámica UNICAMENTE la IP. Los valores de gateway y DNS no deben ser obtenidos del DHCP server. Esto se logra en la configuración del dhcp- cliente. • Los estudiantes deben configurar RC usando ECMP y obtener salida a internet. • Es importante que los estudiantes revisen y analicen el tráfico de las interfaces ether2 y ether3 en RC para que constaten el flujo de datos por ambas interfaces. • Los estudiantes deben también utilizar la herramienta TORCH para comprobar y analizar el tráfico que fluye por cada interface. Lab. 2.3.2 – Ruteo ECMP para balanceo de carga Asimétrico Objetivos Aplicar balanceo de carga usando ECMP y forzar a que el tráfico fluya en mayor demanda por una de las interfaces Actividades a realizar Paso 1 • Sin desarmar la configuración del Lab.2.3 se debe poner peso a uno de los gateways en la configuración ECMP • Para esto basta con agregar dos o más veces el gateway de la interface por al cual se desea tener más peso en el tráfico. Por ejemplo: / ip route add dst-address=0.0.0.0/0 gateway=171.16.4.5,10.1.2.1,10.1.2.1,10.1.2.1 check-gateway=ping • Es importante que los estudiantes revisen y analicen el tráfico de las interfaces ether2 y ether3 en RC para que constaten el flujo de datos por ambas interfaces. • Los estudiantes deben también utilizar la herramienta TORCH para comprobar y analizar el tráfico que fluye por cada interface. Opción “distancia” • Para priorizar una ruta sobre otra, si ambas apuntan a la misma red, se debe usar la opción “distancia2. • Cuando se envía un paquete, el router usara la ruta con la distancia más baja. Lab. 2.4 – Distancia de ruta • Crear 2 rutas separadas para cada participante de la red local según las especificaciones de la Fig.2.4.1 o Una ruta en dirección de las manecillas del reloj con distance=1 o Una ruta en dirección contraria a las manecillas del reloj con distance=2 Academy Xperts 13 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 2: Ruteo Estático Simple • Chequear la redundancia deshabilitando las direcciones IP del gateway en dirección de las manecillas del reloj • Usar traceroute para examinar la configuración Ejemplo de configuración Comportamiento Observado • El tráfico no tiene problemas para pasar en sentido horario • En el caso de falla “check-gateway” solamente el router afectado pasará el tráfico en sentido anti-horario. Todos los otros routers continuarán enviando en sentido horario • Solución: o Si el tráfico comienza a ir en sentido anti-horario, se debería establecer un ruteo anti-horario hasta que alcance su destino. Routing Mark • Para asignar tráfico específico a la ruta, el tráfico debe ser identificado por “routing mark” • Los Routing Marks pueden ser asignados por la opción Mangle del IP Firewall SOLAMENTE en reglas prerouting y output • Los paquetes con routing mark serán ignorados por la tabla de ruteo principal si es que existe por lo menos una ruta para ese routing mark. Si no hay ninguna ruta se usará la tabla de ruteo principal. • Cada paquete puede tener solo un routing mark Lab.2.5 - Política de Ruteo (routing mark) • Marcar todo el tráfico que pasa el router (chain prerouting) en dirección anti-horaria • Enrutar el tráfico anti-horario (usar la opción routing-mark) • Chequear la redundancia deshabilitando las direcciones IP del gateway en sentido horario • Usar traceroute para examinar la configuración. Academy Xperts 14 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 2: Ruteo Estático Simple Ejemplo de configuración Time To Live (TTL) • TTL es un límite de los dispositivos L3 que los paquetes IP pueden experimentar antes de que deban ser descartados • El valor default del TTL es 64 y cada router reduce el valor en uno antes de enviar su decisión • El TTL puede ser ajustado en la opción IP Firewall mangle • El router no pasará el tráfico al siguiente dispositivo si recibe un paquete con TTL=1 • Aplicación útil: eliminar la posibilidad de los clientes de crear redes enmascaradas Academy Xperts 15 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 2: Ruteo Estático Simple Cambiando el TTL Resolviendo el Next-Hop Recursivo Es posible especificar el gateway a una red incluso si el gateway no se puede alcanzar directamente. Esto se puede lograr usando Resolución de Next-Hop Recursivo desde cualquier ruta existente Esto es útil para configuraciones donde la sección media entre el router y el gateway no es constante. Por ejemplo en implementaciones iBGP Una ruta debe estar en el scope (al alcance) de otra ruta para que la Resolución de Next-Hop Recursivo funcione. Scope / Target-Scope El alcance de la ruta (scope) contiene todas las rutas que el valor de “scope” es menor o igual a su valor “target-scope” Ejemplo: 0 ADC dst-address=1.1.1.0/24 pref-src=1.1.1.1 interface=ether1 scope=10 target-scope=0 1 A S dst-address=2.2.2.0/24 gateway=1.1.1.254 interface=ether1 scope=30 target-scope=10 2 A S dst-address=3.3.3.0/24 pref-src=2.2.2.254 interface=ether1 scope=30 target-scope=30 Otras Opciones “Type” permite crear rutas Dead-end (blackhole/prohibit/unreachable) para bloquear algunas redes a ser ruteadas posterioremente en la red “Preferred Source” apunta a la dirección origen del router preferido para paquetes originados localmente. Clean-up • Eliminar todas las reglas de mangle • Eliminar todas las rutas IP • Dejar todas las direcciones IP y la estructura de red intacta. Academy Xperts 16 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Capítulo 3: OSPF Áreas, costos, enlaces virtuales, redistribución de rutas y agregación Protocolo OSPF OSPF obtiene su nombre del algoritmo SPF de Dijkstra. El prefijo “O” significa que es un protocolo Open (abierto) por lo que cualquier persona puede accesar. Las especificaciones del OSPF se pueden encontrar en el RFC-2328 por lo que múltiples fabricantes soportan OSPF. En contraste, los protocolos IGRP y EIGRP son propietarios de Cisco y son protocolos planos, lo cual significa que no hay jerarquía en la red, es decir que cada router pasa las rutas a cada destino en la red. Una arquitectura jerárquica permite soportar sistemas grandes ya que cada área se responsabiliza únicamente de sus rutas locales. Por otro lado RIP e IGRP no pueden soportar redes grandes porque el overhead del ruteo incrementa de una forma lineal conforme incrementa el tamaño de la red. Una diferencia principal entre OSPF y RIP/IGRP es que OSPF no es un protocolo basado en algoritmo de Vector Distancia, sino que OSPF se basa en el algoritmo de Dijkstra que es un algoritmo de Estado de Enlace (Link State) Para aclarar un poco los términos, un algoritmo de Vector Distancia (Distance Vector – DV) propaga la información de ruteo de un vecino a otro, esto quiere decir que si un router recibe la misma ruta proveniente de múltiple vecinos, elige la ruta con la métrica más baja. Todos los protocolos de Vector Distancia necesitan de estrategias robustas para poder hacer frente a la información de ruteo erróneo. Las rutas malas (rutas incorrectas) pueden persistir en una red cuando la información sobre la pérdida de una ruta no puede alcanzar algún router, por ejemplo debido a la pérdida de una ruta de paquete que se ha actualizado. El protocolo IGRP usa las mismas estrategias de conversión que RIP las cuales incluyen: • actualizaciones basadas en disparadores (triggers) • horizontes divididos (split horizon) • poison reverse, y • route hold-downs. Por otro lado en el Algoritmo de Estado de Enlace (Link State Algorithm) la palabra Enlace (link) se refiere a una interface del router, es decir la red a la cual está conectada. La palabra Estado (state) se refiere a las características del enlace tales como: • su dirección IP • subnet mask • costo (o métrica), y • estatus operacional (up o down). Los routers que ejecutan OSPF describen el estado de sus enlaces directamente conectados en los paquetes de anuncio de estado del enlace (LSA: Link State Advertisement packets) que se distribuyen a todos los otros routers. Cada router construye la topología de la red usando todos los paquetes LSA que reciben. La topología de la red se describe matemáticamente en la forma de un gráfico. Esta base de datos de la topología constituye la entrada para el algoritmo SPF (Shortest Path First) de Dijkstra. Consigo mismo como “root”, cada router ejecuta el algoritmo SPF para calcular el camino más corto (shortest path) a cada red en el gráfico. Cada router entonces usa su árbol de camino más corto para construir su tabla de ruteo. Protocolos DV (Vector Distancia) Algoritmo SPF • Estos protocolos propagan la rutas de router • Los routers que ejecutan este algoritmo a router y cada router elige la mejor ruta, a (SPF) necesitan garantizar la exactitud de cada destino, a partir de todas las rutas (hacia sus bases de datos LS (Link State) ese destino) que que el router escucha. • Cuando cada router tiene la información de la • La propagación de rutas de router a router se topología correcta, se puede utilizar el conoce también como “ruteo por rumor” algoritmo SPF para encontrar el camino más • Los protocolos DV deben configurar corto. mecanismos especiales para protegerse contra información producto de un “mal ruteo” que podría propagarse de router a router. El algoritmo de Dijkstra es costoso en términos de utilización de CPU. Esto significa que el costo de ejecutar este algoritmo se incrementa conforme crece la topología de la red, lo cual puede llegar a ser un problema. Sin embargo, dependiendo de la estructura jerárquica del OSPF, la red puede ser dividida en pequeñas áreas, por lo que el algoritmo SPF se ejecutará en cada router únicamente en la topología dentro de cada área. Para que dos áreas diferentes se comuniquen entre sí, cada área debe resumir sus rutas a un área especial llamada área de backbone o área 0 (cero). El área de backbone por su parte resume las rutas a todas las áreas adjuntas. Por lo tanto, el tráfico entre las dos áreas debe pasar a través del área de backbone. Academy Xperts 17 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Como ya lo revisamos, los protocolos RIP, IGRP y EIGRP son planos. OSPF es un protocolo jerárquico, pero no trabaja bien si la topología de la red crece de una manera desordenada y enmarañada. Configurando OSPF en MikroTik Con los datos de la Figura 3.2 configuraremos una red sencilla OSPF. Cada router deberá configurarse en forma independiente e iremos mostrando los pasos por cada dispositivo. Asignación de IPs en Router R1 Direccionamiento IP /ip address add address=172.16.252.2/24 interface=ether1 network=172.16.252.0 add address=172.16.100.1/24 interface=ether3 network=172.16.100.0 add address=172.16.251.2/24 interface=ether2 network=172.16.251.0 Academy Xperts 18 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Obsérvese en la tabla de rutas las entradas que han sido generadas dinámicamente cuando se asignaron las direcciones IP a las respectivas interfaces. [admin@R1] > ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADC 172.16.100.0/24 172.16.100.1 ether3 0 1 ADC 172.16.251.0/24 172.16.251.2 ether2 0 2 ADC 172.16.252.0/24 172.16.252.2 ether1 0 Asignación de IPs en Router R2 /ip address add address=172.16.1.1/24 interface=ether3 network=172.16.1.0 add address=172.16.250.1/24 interface=ether1 network=172.16.250.0 add address=172.16.251.1/24 interface=ether2 network=172.16.251.0 add address=192.168.1.1/24 interface=ether4 network=192.168.1.0 [admin@R2] > ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADC 172.16.1.0/24 172.16.1.1 ether3 0 1 ADC 172.16.250.0/24 172.16.250.1 ether1 0 2 ADC 172.16.251.0/24 172.16.251.1 ether2 0 3 ADC 192.168.1.0/24 192.168.1.1 ether4 0 Asignación de IPs en Router R3 /ip address add address=172.16.50.1/24 interface=ether3 network=172.16.50.0 add address=172.16.250.2/24 interface=ether1 network=172.16.250.0 add address=172.16.252.1/24 interface=ether2 network=172.16.252.0 [admin@R3] > ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADC 172.16.50.0/24 172.16.50.1 ether3 0 Academy Xperts 19 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF 1 ADC 172.16.250.0/24 172.16.250.2 ether1 0 2 ADC 172.16.252.0/24 172.16.252.1 ether2 0 El paso siguiente es configurar en cada router, en la sección network (/routing ospf network), el ID de cada red que estará involucrada en la red OSPF. Se asume en este ejemplo que todos los routers trabajarán en el área de backbone. Configuración de Network en Router R1 Es importante reconocer en R1 (al igual que en los demás routers) lo siguiente: • Se debe especificar el ID de la red. NO confundirse con la dirección IP de alguna de las interfaces. • Por lo tanto, para R1 las redes que participarán en OSPF son: 172.16.251.0/24 y 172.16.252.0/24 • La red 172.16.100.0/24 no se configura en /routing ospf network ya que no colinda con ningún otro router o red OSPF • Si se requiere que la red LAN se publique hacia los otros routers, entonces se debe realizar a través de /routing ospf instance Configuración en Network /routing ospf network add area=backbone network=172.16.251.0/24 add area=backbone network=172.16.252.0/24 Una vez que se ha configurado /routing ospf network, se puede revisar las Interfaces que se han creado automáticamente. Academy Xperts 20 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF [admin@R1] > routing ospf interface print Flags: X - disabled, I - inactive, D - dynamic, P - passive # INTERFACE COST PRIORITY NETWORK-TYPE AUTHENTICATION AUTHENTICATION- KEY 0 D ether2 10 1 broadcast none 1 D ether1 10 1 broadcast none Para redistribuir la red LAN se debe modificar en /routing ospf instance la instancia OSPF por default. NO se debe generar una nueva. Se debe configurar la Redistibución de las Rutas Conectadas como Type 1. De esta manera la red LAN será distribuida a los demás routers que formarán parte de la red OSPF. /routing ospf instance set [ find default=yes ] redistribute-connected=as-type-1 Revisaremos la tabla de rutas de R1 (y de los demás routers) para ir analizando el avance. Puesto que es el primer router que configuramos en la red OSPF, observaremos que la tabla de rutas aparece sin cambios. [admin@R1] > ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADC 172.16.100.0/24 172.16.100.1 ether3 0 1 ADC 172.16.251.0/24 172.16.251.2 ether2 0 2 ADC 172.16.252.0/24 172.16.252.2 ether1 0 Tampoco encontraremos información en la revisión de los Neighbors en OSPF, ya que no hay otros routers agregados. [admin@R1] > routing ospf neighbor print Configuración de Network en Router R2 Es importante reconocer en R2 (al igual que en los demás routers) lo siguiente: • Se debe especificar el ID de la red. NO confundirse con la dirección IP de alguna de las interfaces. • Por lo tanto, para R2 las redes que participarán en OSPF son: 172.16.251.0/24 y 172.16.250.0/24 • Las redes 172.16.1.0/24 y 192.168.1.0/24 no se configuran en /routing ospf network ya que no colindan con ningún otro router o red OSPF • Si se requiere que las redes LAN se publiquen hacia los otros routers, entonces se debe realizar a través de /routing ospf instance Configuración en Network Academy Xperts 21 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF /routing ospf network add area=backbone network=172.16.251.0/24 add area=backbone network=172.16.250.0/24 Una vez que se ha configurado /routing ospf network, se puede revisar las Interfaces que se han creado automáticamente. [admin@R2] > routing ospf interface print Flags: X - disabled, I - inactive, D - dynamic, P - passive # INTERFACE COST PRIORITY NETWORK-TYPE AUTHENTICATION AUTHENTICATION- KEY 0 D ether2 10 1 broadcast none 1 D ether1 10 1 broadcast none Para redistribuir la red LAN se debe modificar en /routing ospf instance la instancia OSPF por default. NO se debe generar una nueva. Se debe configurar la Redistibución de las Rutas Conectadas como Type 1. De esta manera la red LAN será distribuida a los demás routers que formarán parte de la red OSPF. /routing ospf instance set [ find default=yes ] redistribute-connected=as-type-1 Revisaremos la tabla de rutas de R2 (y de los demás routers) para ir analizando el avance. La siguiente es la tabla de rutas en R2. Puede observarse que ya aparecen los datos de las redes distribuidas por R1, tanto la red 172.16.252.0/24 como su red LAN 172.16.100.0/24 [admin@R2] > ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADC 172.16.1.0/24 172.16.1.1 ether3 0 Academy Xperts 22 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF 1 ADo 172.16.100.0/24 172.16.251.2 110 2 ADC 172.16.250.0/24 172.16.250.1 ether1 0 3 ADC 172.16.251.0/24 172.16.251.1 ether2 0 4 ADo 172.16.252.0/24 172.16.251.2 110 5 ADC 192.168.1.0/24 192.168.1.1 ether4 0 En la revisión de los Neighbors en OSPF en R2, ya podemos observar que aparece el ID del router R1. [admin@R2] > routing ospf neighbor print 0 instance=default router-id=172.16.100.1 address=172.16.251.2 interface=ether2 priority=1 dr-address=172.16.251.2 backup-dr-address=172.16.251.1 state="Full" state-changes=6 ls-retransmits=0 ls-requests=0 db-summaries=0 adjacency=11m35s Configuración de Network en Router R3 Es importante reconocer en R3 (al igual que en los demás routers) lo siguiente: • Se debe especificar el ID de la red. NO confundirse con la dirección IP de alguna de las interfaces. • Por lo tanto, para R3 las redes que participarán en OSPF son: 172.16.252.0/24 y 172.16.250.0/24 • La red 172.16.50.0/24 no se configura en /routing ospf network ya que no colinda con ningún otro router o red OSPF • Si se requiere que la red LAN se publique hacia los otros routers, entonces se debe realizar a través de /routing ospf instance Configuración en Network /routing ospf network add area=backbone network=172.16.250.0/24 add area=backbone network=172.16.252.0/24 Una vez que se ha configurado el Network OSPF, se puede revisar las Interfaces que se han creado automáticamente. [admin@R2] > routing ospf interface print Flags: X - disabled, I - inactive, D - dynamic, P - passive # INTERFACE COST PRIORITY NETWORK-TYPE AUTHENTICATION AUTHENTICATION- KEY 0 D ether1 10 1 broadcast none 1 D ether2 10 1 broadcast none Para redistribuir la red LAN se debe modificar la instancia OSPF por default. NO se debe generar una nueva. Se debe configurar la Redistibución de las Rutas Conectadas como Type 1. De esta manera la red LAN será distribuida a los demás routers que formarán parte de la red OSPF. Academy Xperts 23 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF /routing ospf instance set [ find default=yes ] redistribute-connected=as-type-1 Revisaremos la tabla de rutas de R3 (y de los demás routers) para ir analizando el avance. La siguiente es la tabla de rutas en R3. Puede observarse que ya aparecen los datos de las redes distribuidas por R1 y R2 [admin@R3] > ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADo 172.16.1.0/24 172.16.250.1 110 1 ADC 172.16.50.0/24 172.16.50.1 ether3 0 2 ADo 172.16.100.0/24 172.16.252.2 110 3 ADC 172.16.250.0/24 172.16.250.2 ether1 0 4 ADo 172.16.251.0/24 172.16.250.1 110 172.16.252.2 5 ADC 172.16.252.0/24 172.16.252.1 ether2 0 6 ADo 192.168.1.0/24 172.16.250.1 110 En la revisión de los Neighbors en OSPF en R3, ya podemos observar que aparecen los ID de los router R1 y R2. [admin@R3] > routing ospf neighbor print 0 instance=default router-id=172.16.100.1 address=172.16.252.2 interface=ether2 priority=1 dr-address=172.16.252.2 backup-dr-address=172.16.252.1 state="Full" state-changes=5 ls-retransmits=0 ls-requests=0 db-summaries=0 adjacency=7m42s 1 instance=default router-id=172.16.1.1 address=172.16.250.1 interface=ether1 priority=1 dr-address=172.16.250.1 backup-dr-address=172.16.250.2 state="Full" state-changes=5 ls-retransmits=0 ls-requests=0 db-summaries=0 adjacency=7m57s Luego de finalizada la configuración en los 3 equipos, revisaremos en conjunto los Neighbors en R1, R2 y R3 respectivamente. Se podrá observar que cada uno ve a los routers adyacentes como sus vecinos. Academy Xperts 24 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Observemos lo que registran las tablas de rutas de los 3 equipos, R1, R2 y R3 respectivamente: Métrica OSPF Cada router OSPF ejecuta el algoritmo SPF de Dijkstra para calcular la ruta más corta desde sí mismo a cada subred en su área. Sin embargo, el estándar RFC 2328 no especifica cómo un router debe calcular el costo de una red conectada. Este cálculo se lo deja al fabricante/vendedor. Por ejemplo, un fabricante podría calcular el coste de una red conectada de la siguiente manera: 8 costo = 10 / (ancho de banda de la interface en bits por segundo) Basado en esta definición, la tabla a continuación muestra el costo OSPF para algunos tipos de medios. El costo se redondea hacia abajo, al número entero más cercano. Academy Xperts 25 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Tipo de Medio Ancho de banda por default Costo OSPF por default Ethernet 10 Mbps 10 Fast Ethernet 100 Mbps 1 FDDI 100 Mbps 1 T-1 (interface serial) 1,544 kbps 64 Métrica Externa Type 1 Métrica Externa Type 2 Costo de Interface • Todas las interfaces tiene un costo por default de 100 • Para pasar por encima la configuración por default se debe añadir una nueva entrada en el menú de interface • Se debe elegir el correcto tipo de red para la interface Interfaces - Descripción Esta opción provee herramientas para una configuración adicional de parámetros específicos de la interface OSPF. No es necesario configurar las interfaces para que funcione OSPF. Academy Xperts 26 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF • Cost: (1..65535) Costo de la interface expresado como una métrica del estado de enlace • Priority: (0..255) Prioridad del router (default 1). Ayuda a determinar cual será el Router Designado (DR=Designated Router) de la red. Cuando 2 routers conectados a la red intentan ambos ser un DR, el router que tiene la prioridad más alta se convierte en DR. Si es “0” entonces el router NO es elegible para ser designado ni backup • Authentication Key: usado por los routers que trabajan con autenticación/clave (MD5 o Simple) • Interfaces – Descripción (cont.) • Retransmit Interval: (segs.) Es el tiempo que toma en retransmitir los anuncios de los estados de enlace perdidos. Cuando un router envía un LSA (Link State Advertisement) a sus vecinos, mantiene ese LSA hasta que recibe una respuesta de retorno (ackonwledgment). Si no recibe ningún acknowledgment en ese tiempo, el router retransmitirá el LSA. Se recomienda los siguientes parámetros: • Broadcast Network: 5 segundos • Point-to-point Network: 10 segundos • Transmit Delay: Es el tiempo estimado que toma en transmitir un paquete de actualización de estado de enlace en la interface • Hello Interval: Intervalo entre los “paquetes hello” que el router envía en la interface. Mientras más pequeño el intervalo, se detectarán más rápido de topología, pero, se producirá un mayor tráfico de ruteo. Este valor debe ser el mismo en cada lado adyacente, de otra forma la adyacencia no funcionará. • Router Dead Interval: Especifica el intervalo después del cual un vecino es declarado como “muerto” Este intervalo es anunciado en los paquetes “hello” del router. Este valor debe ser el mismo para todos los routers y servidores de acceso en una red específica. Routers Designados • Para reducir el tráfico OSPF en redes NBMA y broadcast, se introdujo una sola fuente para la actualización de rutas: Designated Router (DR) • DR mantiene una tabla completa de la topología de la red y envía las actualizaciones a los otros • El Router con la más alta prioridad (slide anterior) será elegido como DR • El Router con la siguiente prioridad será elegido como Backup DR (BDR) • Un Router con prioridad 0 nunca podrá ser DR o BDR. Systema Autónomo (AS) Un Sistema Autónomo (en inglés, Autonomous System: AS) se define como “un grupo de redes IP que poseen una política de rutas propia e independiente”. Esta definición hace referencia a la característica fundamental de un Sistema Autónomo: realiza su propia gestión del tráfico que fluye entre él y los restantes Sistemas Autónomos que forman Internet. Un número de AS o ASN se asigna a cada AS, el que lo identifica de manera única a sus redes dentro de Internet. • Un sistema autónomo es una colección de redes y routers IP bajo el control de una entidad (OSPF, iBGP, RIP) que presenta una política de ruteo común al resto de la red. • El AS es identificado por un número de 16 bits (0-65535) o El rango de 1 a 64511 se usa para internet o El rango de 64512 a 65535 es para uso privado Operación Los Sistemas Autónomos se comunican entre sí mediante routers, los que intercambian información para tener actualizadas sus tablas de ruteo mediante el protocolo BGP e intercambian el tráfico de Internet que va de una red a la otra. A su vez cada Sistema Autónomo es como una Internet en pequeño, ya que su rol se llevaba a cabo por una sola entidad, típicamente un Proveedor de Servicio de Internet (ISP) o una gran organización con conexiones independientes a múltiples redes, las cuales se apegaban a una sola y clara política de definición de trayectorias. El RFC 1771 describía la definición original (obsoleta) del Protocolo BGP (Border Gateway Protocol). Academy Xperts 27 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Áreas Puesto que el algoritmo de Dijkstra consume más recursos de CPU conforme la red crece, dicho algoritmo no es ideal para topologías grandes. Sin embargo OSPF provee una solución para esta situación y es dividir la red en áreas y ejecutar el algoritmo de Dijkstra en cada topología intra-area. Entonces, un área es un conjunto de redes contiguas y de routers que comparten un ID de área único. Cada área mantiene su propia base de datos topológica, y por lo tanto otras áreas no pueden ver ésta información topológica. El algoritmo SPF se ejecuta en los routers que están dentro de cada área . La red puede crecer casi sin límites con la incorporación de nuevas áreas. Si un área se vuelve demasiado grande, se puede dividir en dos o más áreas. Antes de que un router puede ejecutar el algoritmo SPF, debe tener la base de datos topológica más reciente para su área. Es importante tener en cuenta que un router puede tener interfaces en múltiples áreas. Cualquier cambio de topología en un área ocasionará que el SPF vuelva a calcular en todos los routers con interfaces en esa área. Los routers en otras áreas no se verán afectados por el cambio. Dividir una red en áreas es similar a dividir una red grande en redes más pequeñas e independientes. A diferencia de las redes planas como RIP e IGRP en el que cada router tiene las mismas responsabilidades y tareas, la jerarquía de OSPF impone una estructura en la que los routers e incluso las áreas se diferencian con respecto a sus funciones. • OSPF permite la colección de routers para que sean agrupados (<80 routers en un grupo) • La estructura de un área es invisible desde fuera del área. • Cada área ejecuta una copia separada del algoritmo de ruteo básico link-state. • Las áreas OSPF son identificadas por un número de 32-bit (4 bytes) (0.0.0.0-255.255.255.255) • El ID de área debe ser único dentro del AS Cuando los sistemas autónomos son grandes por si mismos y nada sencillos de administrar. OSPF les permite dividirlos en áreas numeradas donde un área es una red o un conjunto de redes inmediatas. Un área es una generalización de una subred. Fuera de un área, su topología y detalle no son visibles. Área de Backbone Esta área es sumamente especial ya que todas las otras áreas deben conectarse a ella. El ID de área 0 (0.0.0.0) está reservada para el área de backbone. Todo el tráfico inter-area (entre áreas) debe pasar por el área de backbone, lo que implica que los routers del backbone deben tener la base de datos topológica completa de la red. Academy Xperts 28 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF • ASBR= Autonomous System Border Router • ASBR es un router que está conectado a más de un AS o Un ASBR es usado para distribuir en todo su propio sistema autónomo las rutas recibidas desde otros AS. • ABR= Area Border Router • ABR es un router que está conectado a más de un área OSPF o Un ABR mantiene múltiples copias en memoria de la base link-state, una para cada área • IR= Internal Router • IR es un router que está conectado solamente a un área Router de Backbone Un router con una interfaz en el área 0 se lo conoce como un router de backbone. Un router de backbone también puede tener interfaces en otras áreas. Los routers R1, R2, R3, R4 y R5 en la Figura 3.3 son routers troncales. Los routers de backbone tienen una base de datos topológica que describe el estado de todos los enlaces troncales, enlaces que describen las redes IP en las áreas area1, area2, y area3, y enlaces externos que describen la red IP en la red RIP (según el ejemplo de la Figura 3.3). Área o Área Regular Un área regular tiene un identificador de área único en el rango entre 1 (0.0.0.1) y 4.294.967.295 (255.255.255.255). En la figura previa, un router en el area1 mantendrá una información topológica del estado de todos los enlaces del area1, así como también un resumen de los enlaces que describen las redes IP en las area0, area2 y area3, y de los enlaces externos que describen las redes IP en esas redes. Academy Xperts 29 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Router Interno Un router interno tiene interfaces únicamente en una sola Área. En el ejemplo del gráfico previo los routers R6, R7 y R8 son routers internos en el area1. Router de Borde de Área (ABR: Area Border Router) Un router ABR tiene interfaces en más de un área. En la Figura 3.3, los routers R3, R4 y R5 son ABRs. Un ABR tiene información topológica de múltiples áreas. Por ejemplo el router R3 es un ABR que contiene las bases de datos topológicas de area0 y area1. El router R4 contiene las bases de datos topológica de las area0, area2 y area3. El router R5 contiene las bases de datos topológicas de area0 y area3. Un ABR puede resumir la base de datos topológica de una de sus áreas. El router R3 puede resumir la base de datos topológica de area1 dentro del area0. Este resumen o “sumarización” es clave para reducir la complejidad computacional de los procesos OSPF. Router de Límite de Sistema Autónomo (ASBR: Autonomous System Boundary Router) Un ASBR importa la información de ruteo de otro Sistema Autónomo (AS) en OSPF. Las rutas importadas en OSPF de otro AS se conocen como rutas externas. En la Figura 3.3 router R9 es un ASBR. El router R9 importa al OSPF las rutas RIP de otra red externa. Un ASBR puede configurarse para que “sumarice” las rutas externas al OSPF. Stub Area Si un área no tiene conexiones directas a ninguna red externa, entonces sería innecesario importar registros externos a esta área, ya que todo el tráfico hacia las redes externas debe ser ruteado a los ABRs. Este tipo de área puede usar una ruta por default (en lugar de rutas externas) para enviar todo el tráfico IP externo a sus ABRs. Configurar un área como un Stub Area, hace que este tipo de área bloquee los anuncios de los registros de IP externos en los ABRs, y en cambio hace que los ABRs generen rutas por default dentro del Stub Area. Los routers en un Stub Area mantienen una base de datos topológica que describe el estado de todos los enlaces locales, sumariza los enlaces describiendo las redes IP en otras áreas, pero no de redes externas. Esta reducción en el tamaño de la base de datos topológica ahorra recursos de procesador y memoria. Un Stub Area puede usar routers con menor poder de memoria/CPU, o utilizar los recursos de memoria/CPU libres para construir una gran Stub Area. Sin embargo existe una desventaja potencial al configurar un área como Stub Area. Por ejemplo, si en la Figura 3.3 el area3 se configura como un Stub Area, cada uno de los routers R4 y R5 anunciarán una ruta por default en el Stub Area. Una ruta externa puede estar más cerca de R4, pero los routers en el Stub Area perderán esa información y enrutarán todo el tráfico externo a R4 y R5, dependiendo de cuál está más cerca. Los Stub Area no puden soportar conexiones externas ya que los routers Stub no llevan LSAs externos. Los Stub Area no pueden soportar enlaces virtuales por razones similares. Totally Stub Area Un TSA (Totally Stub Area) lleva el concepto de un Stub Area más allá, bloqueando los registros de sumarización de las redes IP en otras áreas de los ABRs. Todo el tráfico inter-area y externo se hace coincidir con la ruta por default anunciada por el/los ABR(s). En términos de tipos de LSA (Link State Advertisement), los routes en TSA mantienen una base de datos topológica que describe el estado de todos enlaces locales únicamente. Al igual que en el Stub Area, un TSA no puede soportar conexiones a redes externas. Academy Xperts 30 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Not So Stubby Area (NSSA) Los NSSA son Stub Areas con una restricción menos: Los NSSAs pueden soportar conexiones externas. En todos los demás aspectos, los NSSAs son como los Stub Areas, es decir que los routers en un NSSA no llevan LSAs externos, ni tampoco soportan enlaces virtuales. Cualquier área puede ser configurada como como un Stub Area, pero necesita soportar una red externa que pueda ser cambiada a un NSSA. Base de Datos Topológica OSPF Esta base de datos está compuesta de LSAs (Link State Advertisements). Los routers OSPF originan los LSAs describiendo una parte de la topología de la red. Estos LSAs se inundan a otros routers que entonces componen una base de datos de LSAs. Existen muchos tipos de LSAs, cada uno se origina en un router diferente y describe un componente diferente de la topología de red. Los diferentes tipos de LSA son los siguientes: Router LSA (type 1 – tipo 1) Un LSA de router describe los enlaces (o interfaces) de un router. Todos los routers originan los LSAs del router. Un LSA del router se inunda a todos los routers intra-area. Network LSA (type 2 – tipo 2) Un LSA de Red (Network LSA) describe una Red Broadcast (por ejemplo un segmento ethernet) o una red NMBA (non- broadcast multi-access) como por ejemplo una red Frame Relay. Todos los routers conectados a la red Broadcast/NBMA se describen en el LSA. Un LSA de Red se inunda a todos los routers intra-area. Summary LSA (type 3 – tipo 3) Un LSA Resumen (Sumarizado) describe las redes IP en otra área. El LSA Sumarizado se origina en un ABR y se inunda fuera del área. Los LSA Sumarizados se inundan a los routers en todas las áreas OSPF, excepto en los TSA (Totally Stubby Area). ASBR summary LSA (type 4 – tipo 4) El LSA Sumarizado ASBR describe la ruta a un ASBR. La máscara asociada con estos LSAs es de 32 bits de longitud ya que el router al que ellos anuncian es un host, es decir, la dirección IP del ASBR. Los ASBR summary LSA se originan en los ASBRs, y son inundados a los routers en todas las áreas OSPF, excepto en las Stub Areas. External LSA (type 5 – tipo 5) Los LSAs Externos describen las rutas externas al proceso OSPF (es decir que están en otro sistema autónomo). Una ruta externa puede ser una ruta por default. Los LSAs Externos se originan en el ASBR, y son inundados a través de las red OSPF, excepto a los Stub Areas. NSSA external LSA (type 7 – tipo 7) Los LSAs externo NSSA describen las rutas a redes externas (es decir que están en otro sistema autónomo) conectadas al NSSA. A diferencia de los LSAs Externos Tipo 5, los LSAs externos NSSA se inundan únicamente dentro del NSSA. Opcionalmente, los LSAs Tipo 7 pueden ser traducidos a LSAs Tipo 5 en el ABR e inundados como LSAs Tipo 5. Tipos de Rutas OSPF Cada router en OSPF usa su base de datos topológica local como entrada al algoritmo SPF. El algoritmo SPF proporciona el camino más corto a cada destino conocido, que luego se utiliza para llenar la tabla de enrutamiento IP como uno de los cuatro tipos de rutas: Ruta inter-area Describe la ruta a un destino dentro del área Ruta inter-area Describe la ruta a un destino en otra área. La ruta hacia el destino comprende una ruta intra-area, una ruta a través del área de backbone y una ruta intra-area en el área de red de destino. Una ruta inter-area algunas veces se la conoce como una ruta sumarizada. Ruta Externa (type 1 – tipo 1) Una ruta externa describe la ruta a un destino fuera del AS (sistema autónomo). El costo de una Ruta Externa Tipo 1 es la suma de los costos para alcanzar el destino en la red externa y los costos de alcanzar el ASBR que anuncia la ruta. Ruta Externa (type 2 – tipo 2) Una ruta externa describe la ruta a un destino fuera del AS (sistema autónomo). El costo de una Ruta Externa Tipo 2 es el costo de alcanzar el destino únicamente en la red externa. No incluye el costo de alcanzar el ASBR que anuncia la ruta. Cuando se rutea un paquete, la tabla de ruteo se escanea por la coincidencia más específica. Por ejemplo, si la dirección IP destino es 10.1.1.254 y la tabla de ruta contiene las entradas 10.1.1.0/24 y 10.1.1.0/26, la coincidencia más específica será a la red 10.1.1.0/26. Academy Xperts 31 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Pero, qué sucedería si la red 10.1.1.0/26 ya fue conocida como una ruta intra-area y una ruta inter-area? El OSPF prefiere rutear en el siguiente orden: 1. Rutas intra-area (más preferida) 2. Rutas inter-area 3. Rutas Externas Tipo 1 4. Rutas Externas Tipo 2 (menos preferida) Es importante el orden en que se han aplicado las reglas: • Primero se identifica la ruta con la coincidencia más específica, y • Entonces se aplican las preferencias OSPF. De esta forma, cuando se rutea el paquete con la dirección destino 10.1.1.254, si la tabla de ruteo tiene 10.1.1.0/24 como una ruta intra-area y 10.1.1.192/26 como una ruta externa Tipo 2, ganará la coincidencia más específica, es decir 10.1.1.192/26 Si OSPF tiene múltiples rutas de igual-costo (equal-cost) a un destino, entonces balanceará el tráfico a través de esas rutas. Cómo trabaja OSPF Los routers OSPF primero deben descubrirse unos a otros antes de que puedan intercambiar sus bases de datos topológicas. Una vez que cada router tiene la base de datos topológica completa, puede utilizar el algoritmo SPF (Shortest Path First) para calcular el camino más corto a cada red. • Los paquetes OSPF se encapsulan directamente en IP con el campo de protocolo configurado como 89. • La dirección IP destino en OSPF depende del tipo de red. • OSPF utiliza dos direcciones IP multicast, en broadcast y en redes punto-a-punto: o 225.0.0.5 para todos los routers OSPF o 224.0.0.6 para todos los routers DR/BDR (Designated Router/Backup Designated Router) • El uso de direcciones IP multicast es más eficiente que usar direcciones broadcast • Si se utilizan direcciones broadcast, todos los dispositivos conectados deben 1. Recibir le paquete broadcast 2. Desarmar el paquete, y luego 3. Descartar el contenido del paquete si no está corriendo OSPF • Las redes NBMA y los enlaces virtuales usan direcciones unicast ya que no soportan direcciones multicast La cabecera OSPF La cabecera OSPF es común para todos los tipos de paquetes OSPF, y su estructura se muestra a continuación: IP Packet Header Data Link Protocol OSPF OSPF Header Frame Header Number Message OSPF=89 Octet 0 1 2 3 Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 Version No. Packet Type Packet Length 4 32 Router ID 8 64 Area ID 12 96 Checksum AU Type 16 128 Authentication 20 160 Authentication OSPF Common Header La siguiente lista define el formato de la cabecera OSPF y los cinco tipos de paquetes OSPF: Version No – La versión OSPF que se está usando. Actualmente versión 2 para IPv4 (versión 3 para IPv6) Packet Type (Tipo de Paquete) – Existen 5 tipos de paquetes OSPF: • Type 1 – Paquetes Hello • Type 2 – Paquetes de descripción de la base de datos (database description packets) • Type 3 – Requerimientos de estado del enlace (link state requests) • Type 4 – Actualizaciones del estado del enlace (link state updates) • Type 5 – Reconocimientos del estado del enlace (link state acknowledgments) Packet Length – Longitud en bytes del paquete OSPF incluyendo la cabecera (header) Router ID – El ID del router que origina el paquete OSPF. Academy Xperts 32 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Cuando el protocolo OSPF inicia el proceso en un router (por ejemplo cuando el router se enciende) intenta establecer un router ID. Este router ID es el nombre o la etiqueta que será añadida al nodo que representa el router en la topología SPF (Shortest Path First). Si el OSPF no puede establecer un router ID, el OSPF aborta el proceso. Para que un router elija su router ID existen dos situaciones que se deben considerar: 1. Si un router tiene una o más interfaces loopback, entonces elige la dirección IP más alta del pool de interfaces loopback como su router ID. Las interfaces loopback están siempre activas. 2. Si un router tiene interfaces no-loopback, entonces elige la dirección IP más alta de cualquiera de sus interfaces activas como su router ID. Si un router tiene interfaces no-activas con una dirección IP, entonces no iniciará el proceso OSPF. El router ID se elige cuando el proceso OSPF inicia. La adición o eliminación de interfaces o direcciones en un router después de que se ha seleccionado el router ID, no cambia el router ID. Un nuevo router ID se elige únicamente cuando el router se reinicia, o cuando se reinicia el proceso OSPF. Area ID – El ID del área de la red en el cual el paquete está siendo enviado Checksum – El Checksum del paquete entero, incluyendo la cabecera AU Type – El tipo de esquema de autenticación que se está usando. Los posibles valores para este campo son los siguientes: • 0 – Sin autenticación • 1 – Autenticación clear-text password • 2 – Checksum MD5 Authentication (Autenticación) – Data de autenticación Neighbor Discovery: Protocolo Hello (OSPF Packet Type 1) • Cada router genera paquetes hello OSPF en cada interface en que está habilitado el protocolo OSPF. • Los paquetes hello se envían cada 10 segundos en un ambiente broadcast, y cada 30 segundos en un ambiente no-broadcast. • Los routers descubren a sus vecinos escuchando los paquetes hello. • El comando /routing ospf neighbor print mostrará los vecinos que han sido descubiertos Cada paquete hello contiene los campos que se describen según el formato a continuación: IP Packet Header Data Link Frame Protocol OSPF Header Header Number OSPF=89 0 1 2 3 OSPF Common Header 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Version No. Packet Type Packet Length Router ID Area ID Checksum AU Type Authentication Authentication Offsets Octet 0 1 2 3 Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 Network Mask 4 32 Hello Interval Options Router Priority 8 64 Router Dead Interval 12 96 Designated Router 16 128 Backup Designated Router 20 160 Neighbor # 1 ….. Neighbor # N Academy Xperts 33 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Hello Interval Este campo especifica la duración entre paquetes hello. El valor por default en la mayoría de interfaces es de 10 segundos. El hello-interval se puede modificar Options OSPF define varias capacidades opcionales que un router puede o no puede soportar. Este campo es de un octeto de largo. El formato de este campo es el siguiente: • Los routers que soportan circuitos de demanda, configuran el bit DC. • El soporte de NSSA se activa usando el bit N • El bit E significa que el router acepta LSAs externos. • Los stub routers apagan este bit E • El bit T significa que se soporta múltiples tipos de servicio Router Priority El router que tiene la prioridad más alta tiene la prioridad en la elección del algoritmo DR (Designated Router). Cuando priority=0 (cero) significa que el router no es elegible para la elección DR/BDR. El valor por default de este campo es 1 Router dead-interval Si no se reciben paquetes hello mientras dura el dead-interval, se declara “muerto” al vecino (neighbor) Academy Xperts 34 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Designated Router (DR) Router Designado para redes multi-access. Este campo está configurado como 0.0.0.0 si no se ha elegido un DR en la red. Backup Designated Router (BDR) Especifica la dirección IP de la interface del router designado como backup en esta red. Este campo se configura como 0.0.0.0 si no se ha elegido un BDR en la red. Neighbor list (lista de router ID de los vecinos) Este parámetro contiene la lista de los routers vecinos, desde los cuales éste router ha recibido paquetes hello dentro de los últimos segundos dead-interval. Antes de que un router muestre sus vecinos en su paquete hello, los dos routers deben estar de acuerdo en lo siguiente: • Area ID • Mecanismo de Autenticación • Network Mask • Hello-interval • Router dead-interval • Campo “options” Si estos valores coinciden, los ruters se convierten en vecinos y comienzan a escucharse uno a otro en sus paquetes hello. Los principales estados de relación con los vecinos (neighbor) son los siguientes: • Full – Implica que los vecinos han intercambiado las bases de datos LS (Link State) para ser adyacentes. En condiciones normales, o condiciones estables, el estado de cada vecino (neighbor) debería ser 2-way o Full. • 2-way – Implica que los vecinos han visto los paquetes hello de cada uno, pero que aún no han intercambiado los LSAs. • Exstart, Exchange, Loading – Durante el proceso de maduración de una relación Full, el estado de los vecinos puede variar y tomar estos estatus. Indican que los vecinos pueden ver los paquetes hello de cada uno y que están intentando intercambiar sus bases de datos LS. Son estados transitorios. • Down – Indica que que no se ha recibido un paquete hello desde el vecino en el último dead-interval del router. • Attempt – Se aplica a las redes NBMA e indica que un paquete hello aún no se ha recibido desde el vecino. • Init – Implica que un paquete hello se recibió desde el vecino, pero que la lista de router ID de su vecino no incluye al router ID de éste router. Elección DR/BDR Supongamos que tenemos n routers en una red broadcast (por ejemplo una red Ethernet). Si un router intercambia su base de datos topológica con cada router en la red, se deberían formar n*(n-1)/2 adyacencias en dicho segmento. Esto podría crear mucho overhead de tráfico OSPF. Este problema de overhead es resuelto por OSPF eligiendo un Router Designado (DR, Designated Router) y Backup de Router Designado (BDR, Backup Designated Router) en cada red broadcast. Cada router, en una red broadcast, establece una adyacencia únicamente con el DR y el BDR. Estos routers (DR y BDR) inundan esta información topológica a todos los otros routers en el segmento. • El proceso de elección DR/BDR ocurre en cada red multi-access (no ocurre en cada router) • Un mismo router puede ser el Router Designado (DR) en una de sus interfaces, pero no en otra. Academy Xperts 35 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF El siguiente escenario asume que un router R se ha iniciado en una red multi-access 1. Cuando un router R se activa en una red multi-access, el proceso OSPF en dicho router comienza recibiendo los paquetes hello de sus vecinos en su interface a la red multi-access. Si los paquetes hello indican que ya existen un DR y un BDR, se termina el proceso de elección DR/BDR. Este proceso se termina incluso si la prioridad OSPF de R es más alta que la prioridad actual DR/BDR. 2. Si los paquetes hello de los vecinos indican que no hay un BDR activo en la red, el router con la más alta prioridad se elige como BDR. Si la prioridad más alta es compartida por más de un router, ganará el router con el router ID más alto. 3. Si no hay un DR activo en la red, el BDR se promueve a DR. Es necesario mencionar los siguientes corolarios sobre las reglas anteriores: 1. Si un DR y un BDR ya se han elegido, presentar un nuevo router (incluso con la prioridad más alta) no alterará las identidades del DR/BDR. 2. Si existe únicamente un router que puede ser elegido como DR en una red multi-access, ese router se convertirá en el Router Designado (DR). 3. Si existen únicamente dos routers que pueden ser elegidos como DR en una red multi-access, uno de ellos será elegido como DR y el otro como BDR. Un router con la prioridad más alta tiene precedencia durante la elección del DR. Un valor de prioridad 0 (cero) indica que el router nunca podrá participar en una elección de DR. El valor de prioridad por default es 1. Los routers que tienen poca memoria y pocos recursos de CPU deben ser configurados para que nunca participen en una elección DR. Estado de la Interface (Interface State) El estado de la interface puede tener uno de los siguientes valores: • Down – Similar a los protocolos de bajo nivel. Aún no se ha enviado o recibido tráfico OSPF • Loopback – La interface se conecta en bucle (looped) y será anunciada en los LSAs como una ruta de host • Point-to-point – La interface está activa (up) y es reconocida como una interface serial o un enlace virtual. Después de ingresar el estado point-to-point, los vecinos intentarán establecer la adyacencia. • Waiting – Este estado se aplica únicamente a redes broadcast/NBMA en el cual el router está intentando identificar el DR/BDR. • DR – Este router es el DR en la red a la cual está conectado. • Backup – Este router es el BDR en la red a la cual está conectado. • DRother – Este router no es ni el DR ni el BDR en la red a la cual está conectado. El router formará adyacencias con el DR y el BDR (si ellos existen) Relación de vecino (Neighbor Relationship) No todos los vecinos establecen adyacencia. Los vecinos pueden estar en una relación 2-way o entrar en una relación Full, dependiendo del tipo de red, como por ejemplo los siguientes tipos de redes: • point-to-point – Los routers en redes point-to-point (punto a punto) siempre establecen adyacencia • broadcast – Los routers en redes broadcast establecen adyacencia únicamente con el DR y el BDR, manteniendo una relación 2-way con los otros routers en la red • non-broadcast multi-access (NBMA) – Los routers en las redes NBMA establecen adyacencia únicamente con el DR y el BDR • virtual links (enlaces virtuales) – Los routers en enlaces virtuales siempre establecen adyacencia Intercambio de Base de Datos (Database Exchange) El paquete DD (Database Description Packet – paquete de descripción de la base de datos) se utiliza para describir los contenidos de la base de datos LS a un router OSPF. Únicamente las cabeceras (headers) LSA se envían en los paquetes DD, el otro router responde enviando sus propias cabeceras LSA en paquetes DD. Academy Xperts 36 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Formato del paquete DD (Database Description Packet, OSPF Packet Type 2) Octet 0 1 2 3 Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 OSPF Header 0 0 Interface MTU Options 0 0 0 0 0I M MS 4 32 DD Sequence Number Un LSA Header Otros LSA Headers ….. • Interface MTU – Contiene el valor MTU de la interface saliente. Para enlaces virtuales, este valor se configura como 0x0000 (2 bytes) • Options – Similar al campo options en un paquete hello (1 byte) • I – Bit Inicial. Indica que éste es el primero en las series de paquetes DD (1 bit) • M – Más bits. Indica si el paquete DD es el útimo en la serie de paquetes. El último paquete tiene un valor de 0, mientras que todos los paquetes previos tienen un valor de 1 (1 bit) • MS – Master/Slave bit. Master=1, Slave=0 (1 bit) • DD Sequence Number – Se utiliza para secuenciar la colección de paquetes DD. El valor inicial debe ser único. Luego el número de secuencia incrementa en 1 hasta que el DD completo haya sido enviado (4 bytes) • LSA Header – Este campo contiene las cabeceras LSA que describen la base de datos del router local (longitud variable) Formato de la cabecera LSA (Link State Advertisement header) Offsets Octet 0 1 2 3 Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 Link State Age Options Link State Type 4 32 Link State ID 8 64 Advertising Router 12 96 Link State Sequence Number 16 128 Checksum Length 20 160 24 192 28 224 Dependiendo del LS Type, variará el detalle 32 256 de este contenido 36 288 ….. La cabecera LSA únicamente identifica una pieza de la topología de la red OSPF. Los campos claves en la cabecera LSA son: • Advertising router – Es el router ID del originador del LSA • LS type – Identifica el tipo de LSA que sigue • Link State ID – Depende del LS type Tabla del LS Type LSA Function Code LS Type Description Link State ID 1 0x2001 Router-LSA Router ID del originador del LSA Dirección IP de la interface del 2 0x2002 Network-LSA DR a la red multi-access Inter-Area-Prefix-LSA 3 0x2003 Dirección IP de la red de destino También se conoce como Summary-LSA en OSPFv2. Inter-Area-Router-LSA 4 0x2004 También se conoce como ASBR-Summary-LSA en Router ID del ASBR OSPFv2. AS-External-LSA 5 0x4005 También se conoce como External-LSA o AS-External- Dirección IP de la red de destino LSA en OSPFv2. MOSPF-LSA obsoleto en OSPFv3 (puede ser 6 0x2006 reasignado) Se conocía como Multicast-OSPF-LSA en OSPFv2. NSSA-LSA 7 0x2007 También se conoce como NSSA-LSA en OSPFv2. 8 0x0008 Link-LSA 9 0x2009 Intra-Area-Prefix-LSA Academy Xperts 37 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Varias copias de un LSA pueden estar circulando en una red. El número de secuencia LS (LS Sequence Number) es un entero de 32-bit, y ayuda a identificar el LSA más reciente. La primera instancia de un registro LSA contiene un campo de número de secuencia 0x80000001. Cada nueva instancia de un LSA contiene un número de secuencia que es uno más alto. El máximo número de secuencia es 0x7fffffff, después del cual los números de secuencia se reciclan. El número de secuencia ayuda a identificar la instancia más reciente de un LSA. Después de recibir las cabeceras LSA en los paquetes DD, ambos routers revisan si esta pieza de la topología OSPF ya está contenida en sus bases de datos LS. En este proceso, los campos advertising router, LS type, y link state ID (de la cabecera LSA) se comparan contra la base de datos LS del router. Si se encuentran registros que no concuerdan, o si se encuentra un registro que concuerda con un número de secuencia más bajo, se solicita el LSA completo usando el paquete link state request. El paquete LS request contiene la cabecera LSA para ayudar a identificar el registro que está siendo buscado. En respuesta a un link state request, un router emite una actualización del estado del enlace (link state update) conteniendo el LSA. El LSA completamente describe la pieza de la topología OSPF en cuestión. Las actualizaciones LS se emiten: a) En respuesta a un LS request b) Debido a un cambio en el estado del enlace c) Cada 30 minutos, con un nuevo número de secuencia y con el campo age=0 Todas las actualizaciones LS (LS updates) son reconocidas en los paquetes link state acknowledgment Existen 6 tipos de registros LSA, cada uno de los cuales representa una parte diferente de la topología de red. Basados en la Figura 3.4 daremos un vistazo a los varios tipos de LSA. • R4 es un ABR con un enlace en Area 1 al router R5 • R5 es un ASBR que redistribuye las rutas RIP de una red legacy al OSPF • Las subredes 10.0.0.0 (10.0.1.0, 10.0.2.0 y 10.0.3.0) son conocidas para ambos procesos OSPF y RIP en el router R5. • La tabla de ruteo de R3 aprende la red 10.0.3.0 como una red externa, mientras que las redes 10.0.1.0 y 10.0.2.0 son aprendidas como rutas inter-area. Esto se debe a que las rutas inter-area son preferidas sobre las rutas externas. • El orden OSPF de la preferencia de rutas, desde la más preferida a la menos preferida, es: intra-area, inter- area, type 1 external, type 2 external. Router LSA (type 1) Un router LSA describe los anuncios de los enlaces conectados directamente al router. Academy Xperts 38 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Los routers R1, R2, R3, y R4 anuncian las LSAs del router que se inundan a través del Area 0. La base de datos LS de R3 mantiene los LSAs del router desde todos estos routers. El número de enlaces descrito en el LSA es 1. Aunque R4 tiene dos enlaces conectados directamente (un segmento a través de ether1 y otro enlace a través de ether2), únicamente el enlace ether1 es el que se describe en el LSA a R3. Esto se debe a que el enlace ether2 está en Area 1 y los LSAs del router no cruzan los límites del área OSPF. El enlace descrito es una red de tránsito, lo cual implica que hay múltiples routers en el enlace. Otros tipos de enlace son point-to-point (para enlaces seriales), stub network (para una red con un solo router), y virtual link (para enlaces virtuales OSPF). El valor del campo Link ID depende del tipo de enlace (Link Type) que está siendo descrito, según se muestra en la siguiente tabla: Tipo de Enlace (Link Type) Link ID Point-to-point ID del router vecino (neighbor) Transit Network (red de tránsito) Dirección IP del Router Designado (DR) en la red Stub Network Número de red IP o número de subnet Virtual Link (enlace virtual) ID del router vecino (neighbor) En el ejemplo de la Figura 3.4, el DR (router designado) es R3, por lo que el Link ID contiene la dirección IP de R3. El contenido del campo de dato de enlace también depende del tipo de enlace, como se muestra en la siguiente tabla: Tipo de Enlace (Link Type) Link data (dato de enlace) Point-to-point Dirección IP de la interface de red Transit Network (red de tránsito) Dirección IP de la interface de red Stub Network Número de red IP o número de subnet Virtual Link (enlace virtual) MIB II ifIndex de la interace del router En el ejemplo, el campo de dato de enlace especifica la dirección IP de R4 Network LSA (type 2) Un network LSA describe las redes broadcast/NBMA. La red LSA es originada por el DR (router designado) y describe todas los routers conectados. El LSA en el siguiente ejemplo se origina por sí mismo, como se ve en el campo de anuncio del router, el cual muestra el propio router ID de R3. La red LSA describe la máscara en la red multi-access y la dirección IP de los routers en la red multi-access. Summary LSA (type 3) Un Summary LSA es anunciado por un ABR (router de borde de área) y describe las rutas inter-area. En el siguiente ejemplo los Summary LSAs son originados por R4 (192.168.1.4) y describe las rutas a 10.0.1.0 y 10.0.2.0 respectivamente. El ID del estado de enlace (link state ID) describe el número de summary network. Nótese que cada LSA describe únicamente un número de summary network. ASBR Summary LSA (type 4) Un ASBR Summary LSA describe la ruta al ASBR. La máscara asociada con un LSA Type 4 es de 32 bits de longitud porque la ruta anunciada es a un host, que es el host que está siendo el ASBR. Los ASBR Summary LSAs son originados por los ABRs. En el siguiente ejemplo, el link state ID describe el router ID de R5, el cuál es el ASBR redistribuyendo RIP dentro de OSPF. El router anunciante es el ABR, es decir R4. External LSA (type 5) El External LSA se origina en los ASBRs y describe las rutas externas al proceso OSPF. Los External LSAs son inundados a través de la red OSPF, con excepción de las áreas stub (stub areas). La red 10.0.1.0 es aprendida vía RIP desde R4, el cual inunda un External LSA con un Link state ID de 10.0.1.0 10.0.1.0 es también conocido como una ruta inter-area. El router R4 prefiere la ruta IA (inter-area) pero mantendrá el external LSA en su base de datos topológica. El router de anuncio es R5, el ASBR, el cual redistribuye RIP en OSPF. La dirección de reenvío (forwarding) es 0.0.0.0, indicando que el destino para 10.0.1.0 es el ASBR. El LSA especifica una etiqueta (tag) de ruta externa de 0 (cero), lo cual indica una ruta externa type 1; un valor de 1 indicaría una ruta externa type 2. Academy Xperts 39 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Note que la base de datos externa de R3 contiene otros dos LSAs, con el Link State ID de 10.0.2.0 y 10.0.3.0 (que no se muestran aquí). NSSA External LSA (type 7) El NSSA External LSA describe las rutas externas al proceso OSPF. Sin embargo, a diferencia de los external LSAs type 5, los NSSA external LSAs son inundados únicamente dentro del NSSA. No hay LSAs type 7 en esta red. De hecho, no hay incluso ningún NSSA en esta red. El formato del NSSA external LSA es idéntico al del AS external LSA, excepto para el campo de dirección de reenvío (forwarding). El campo de dirección de reenvío en un NSSA external LSA siempre indica la dirección a la cual el tráfico debe ser reenviado. Inundación (Flooding) de LSAs Los LSAs se generan cada 30 minutos, o antes si es que ocurre un cambio en el estado de un enlace. Los LSAs se intercambian entre routers que han establecido adyacencia (como se describió anteriormente). Las reglas para la inundación de LSAs son gobernadas por la estructura jerárquica del OSPF, según se muestra en la siguiente tabla: LSA Type Router Originador Area en el cual es inundado Router LSA /type 1) Cada router Area local del router Network LSA (type 2) DR Area local del router Summary LSA (type 3) ASBR Nonlocal área ASBR summary LSA (type 4) ASBR Todas las áreas excepto: stub area, totally stubby area, o NSSA External LSA (type 5) ASBR Todas las áreas excepto: stub area, totally stubby area, o NSSA NSSA external LSA (type 7) ASBR Area local del router. El NSSA external LSA puede ser reenviado por un ABR como un LSA type 5 Sumarización de Rutas RIP-1 e IGRP sumarizan automáticamente las subredes. OSPF en cambio no sumariza automáticamente las rutas. La sumarización de ruta en OSPF debe ser configurada manualmente en el ABR o en el ASBR. Además, OSPF permite la sumarización de rutas en cualquier límite de bit, a diferencia de RIP e IGRP que únicamente sumarizan números de redes classful (con clase). La sumarización de rutas mantiene las tablas de rutas más pequeñas y mucho más fáciles para hacer troubleshooting. En todo caso, la sumarización de rutas en OSPF no es solo algo interesante de hacer, sino que debe ser considerado necesario para reducir el tamaño de la base de datos topológica de OSPF, especialmente cuando la red es grande. La base de datos de una topología grande requiere una gran cantidad de memoria del router, lo cual reduce o pone lento a los demás procesos, incluyendo a los cálculos de SPF (Shortest Path First). Para permitir la sumarización en los ABRs y ASBRs, la dirección IP debe ser asignada cuidadosamente. Primero, se deben ubicar suficientes direcciones a cada área de tal forma que permita la expansión posterior. Luego se debe configurar un límite de bit en el cual se sumarizarán las rutas. Esta última actividad debe ser realizada con cautela ya que generalmente se trabaja sobre una red que ya trae consigo problemas de direccionamiento y se requieren cambios. Rutas por Default (Default Routes) Una ruta por default se puede utilizar para conectar a Internet representando todas las rutas que existen en Internet. Por ejemplo, si la red de la Figura 3.4 establece una conexión desde R4, ether3 a un ISP (proveedor de servicio de Internet). Se instala una ruta estática en R4, apuntando al ISP. R4 se configura para originar la ruta por default. La palabra always implica que la ruta por default debe ser originada ya sea que la ruta por default esté activa o no. El parámetro metric-value es la métrica asociada que puede ser configurado como 1 o 2 para especificar si la ruta por default es external type 1 o external type 2. Puesto que se especificó el parámetro always, la ruta por default no desaparecerá de la tabla de ruteo OSPF si ether3 está caído. Si la red de la Figura 3.4 tiene dos o más routers conectando a ISPs y cada router anuncia una ruta por default en OSPF, entonces no se debe usar el parámetro always. Si se pierde la conexión de un ISP, el tráfico encontrará su camino a la otra conexión ISP. Para asegurar de que la ruta por default siempre se anuncie, incluso si ether3 se cae, entonces se usa la opción always. Una ruta por default de Type 1 incluye el costo interno de alcanzar el ASBR. Si la red de la Figura 3.4 tiene múltiples conexiones a Internet, el anunciar una ruta por default desde cada uno con una métrica Type 1 podría tener la desventaja de que cualquier router en la red podría encontrar el ASBR más cercano. Academy Xperts 40 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Virtual Links (Enlaces Virtuales) • Son usados para conectar áreas remotas al backbone area a través de un área non-backbone • También son usados para conectar dos partes de un área de backbone particionado a través de un área non- backbone. Asumamos que la red de la Figura 3.4 planea establecer una nueva oficina en R5 con areaID=2. El primer router en area2 se lo llamará R6. Se necesita establecer un circuito directo desde R4 (ABR) hacia R6, ya que todas las áreas OSPF se deben conectar directamente al área de backbone (area 0). Ya existe una ruta física disponible a area2 a través de area1, que se puede usar para activar el area2 sin necesidad de que exista un camino físico de R4 a R6. Para esto OSPF define lo que se conoce como Enlaces Virtuales (VL=Virtual Link) los cuales pueden extender el área de backbone. El area2 se conectará directamente al área de backbone vía el Virtual Link (VL). Un Enlace Virtual se puede ver como un enlace punto-a-punto que pertenece al area 0. Los puntos finales (extremos) de un Enlace Virtual deben ser los ABRs. En el ejemplo de la Figura 3.5 se define un VL desde R4 a R6 a través de area1. Los VLs (Enlaces Virtuales) pueden atravesar los Stub Areas (o los Totally Stubby Areas o los NSSAs). Esto se debe a que los VLs pertenecen al area0, y para que el area0 rutee correctamente debe tener la base de datos topológica completa. Las Stub Areas no contienen la base de datos topológica completa. Los VLs se pueden usar para reparar la red cuando un área pierde su enlace al backbone. Por ejemplo en la Figura 3.3, la pérdida del enlace R1 a R4 aislaría el area2 del resto de la red. Hasta que ese enlace R1 a R4 se repare, se puede definir un VL entre R4 y R5 para unir el area2 con el backbone. Academy Xperts 41 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Stub Area, Totally Stubby Area, y Not So Stubby Area Los LSAs externos se inundan a través del backbone OSPF como también a través de todas las áreas regulares. Basado en la Figura 3.4 se probará esto. Se define una ruta estática para 192.168.3.0 en R1 y se redistribuye en la red OSPF. El router R1 anuncia una LSA externo con un Link State ID = 192.168.3.0 El LSA se inunda a todos los routers en la red. La ruta 192.168.3.0 tambien aparece en la tabla de ruteo: La inundación de LSAs externos a través de la red OSPF puede representar un desperdicio de recursos. Por este motivo los Stub Area pueden bloquear la inundación de de LSAs Externos. Stub Area Basado en la Figura 3.1, el router en area2 que conecta a la red RIP fluye los LSAs externos en la red. Parece que no se gana nada importando los LSAs Externos en las area1 y area3, con lo cual puede apuntar todas las rutas externas a sus ABRs usando rutas por default. La representación de cada LSA externo en las area1 y area3 podría ser un desperdicio de recursos. Academy Xperts 42 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Con esto en mente, es que OSPF define los Stub Areas. Cuando un área se define como un Stub Area, todos los LSAs externos se bloquean en los ABRs, y en su lugar, el ABR origina una simple ruta por default en el Stub Area. Todos los routers en el Stub Area deben ser configurados como Stub Routers. Los Stub routers forman adyacencias únicamente con otros routers Stub y no propagan los LSAs externos. La manera en que un router sabe si su vecino es un Stub router es a través del bit E en el paquete hello, el mismo que se cambia a 0 (cero) si el router es un Stub router. • Un Stub Area es un área que no recibe rutas externas AS • Típicamente todas las rutas a redes AS externas pueden ser reemplazadas por una Default Route. Esta ruta será creada automáticamente y distribuida por el ABR • La opción <<Inject Summary LSA>> permite recolectar backbone separados u otros LSA (Link State Advertisement) de router de área e inyectarlo al Stub Area • Habilite la opción <<Inject Summary LSA>> solo en el ABR • <<Inject Summary LSA>> no es una agregación de ruta • El costo de <<Inject Summary LSA>> es especificado por la opción <<Default Area Cost>> El area1 en la red de la Figura 3.4 puede convertirse en Stubby a través de cambios en la configuración de R4 La tabla de ruteo para R5 ahora muestra una ruta por default apuntando al ABR (R4) pero no muestra la ruta externa a 192.168.3.0 (originada por R1): Sin embargo, después de este cambio se encontrará que la red ha perdido conectividad a 10.0.3.0, la cual representa la red externa RIP conectada a R5. La razón es porque los Stub Areas no propagan los LSAs externos. En otras palabras, un ASBR no puede pertenecer a un Stub Area. Otra restricción con los Stub Areas es que ellas no pueden soportar enlaces virtuales (VL), ya que no tienen la tabla de ruteo completa. Un área que necesita soportar un VL no puede ser un Stub Area. Cualquier área que no contiene un ASBR (por ejmplo, no soporta una conexión a una red externa) y no es candidato para soportar un VL debería convertirse en un Stub Area. Existe una desventaja en configurar un Area en un Stub Area. Cuando múltiples ABRs originan una ruta por default, los routers en el Stub Area pueden fallar en reconocer el camino más corto (Shortest path) a la red destino. Esto puede ayudar a determinar si se elige implementar un Area como un Area regular o como un Stub Area. Academy Xperts 43 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Totally Stubby Area Los TSA pueden llevar el concepto de Stub Areas más allá, bloqueando todos los resúmenes de los LSAs en adición a los LSAs externos. En la configuración previa, donde R5 se configura como un Stub Area, la base de datos LS de R5 no mostrará los LSAs externos pero mostrará todos los resúmenes de los LSAs, por lo tanto la tabla de ruteo de R5 mostrará la ruta sumarizada inter-area a 172.16.0.0/16. Si R4 no sumariza las subredes 172.16.0.0, R5 podría mostrar todas las 6 subredes 172.16.0.0: 172.16.1.0/24, 172.16.50.0/24, 172.16.100.0/24, 172.16.250.0/24, 172.16.251.0/24, y 172.16.252.0/24. Los TSAs, a diferencia de los Stub Areas, reemplazarán todas las rutas inter-area (en adición a las rutas externas) con una ruta por default. area1 se puede configurar como un TSA modificando la configuración de R4 de la siguiente manera. No se requieren cambios en el router R5: La tabla de ruta de R5 no contiene ninguna ruta IA, más que la ruta por default originada por R4: Los TSA tienen las mismas restricciones que los Stub Area, es decir que no permite ASBRs (no LSA externos) ni enlaces virtuales (VL). También, al igual que los Stub Areas, los TSAs ven todos los ABRs como equidistantes a todos los destinos que coinciden con la ruta por default. Cuando múltiples ABRs originan una ruta por default, los routers en el TSA podrían no reconocer el camino más corto a la red destino. NSSAs Es posible que un Stub Area necesite aprender las rutas de otro protocolo de ruteo. Por ejemplo, R5 (area1) puede necesitar aprender algunas rutas RIP de una red legacy. Los NSSAs permiten que las rutas externas sean importadas en un área sin perder el carácter de Stub Area. Por ejemplo, sin importar ninguna ruta externa del área de backbone. Los NSSAs importan las rutas externas a través de un ASBR en LSA Type 7. Los LSAs Type 7 son inundados dentro del NSSA. También pueden ser inundados por el ABR dentro del dominio entero OSPF como un LSA Type 5, o también pueden ser bloqueados en el ABR. Al igual que con cualquier Stub Area, los NSSAs no importan LSAs Type 5 desde el ABR. La opción de traducir o no un LSA Type 7 en un LSA Type 5 en el NSSA ABR, se especifica en el bit P (en el campo de opciones) del LSA Type 7. Si este bit se configura como 1, el LSA se traduce por el ABR en un LSA Type 5 para que sea inundado a través del dominio OSPF. Si el bit se configura como 0, el LSA no será anunciado fuera del área NSSA. • NSSA es un tipo de Stub Area que está habilitado para inyectar transparentemente rutas externas AS al backbone • <<Translator Role>> Esta opción permite controlar cual ABR del área NSSA actuará como relay del ASBR al área de backbone OSPF AS Todos los routers en el NSSA deben ser configurados con el parámetro NNSA: Academy Xperts 44 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Cuando está configurado en el NSSA ABR, el parámetro default-information-originate ocasiona que el ABR origine una ruta por default en el NSSA. El parámetro no-redistribution es útil en los NSSA ABRs que también son ASBRs. Este parámetro detiene la redistribución de LSAs Externos (desde otro AS) dentro del NSSA. El parámetro no-summary hace del NSSA un Totally Stubby NSSA, es decir que ningún LSA Type 3 o Type 4 se enviará al área. Los NSSAs son una variante de los Stub Area con una restricción menos, y es que las conexiones externas son permitidas. En todos los otros aspectos, los NSSA son un Stub Area. Redes NBMA Cuando se elige un Router Designado (DR), este proceso va de la mano con la capacidad broadcast o multicast de la red. Las redes NBMA como Frame Relay o X.25 no poseen una capacidad inherente de broadcast o multicast, pero pueden simular una red broadcast si está completamente mallada. Una red completamente mallada con N nodos, requiere Nx(N-1)/2 circuitos virtuales. El costo de Nx(N-1)/2 circuitos virtuales puede ser indeseable, y además, la falla de un simple circuito virtual podría interrumpir el mallado total. Una opción que existe alrededor de una red completamente mallada es configurar estáticamente el DR (Router Designado) para la red. El DR anunciará la red NBMA como una red multi-access usando una simple subred IP en una red LSA. Otra opción es configurar la red como un conjunto de redes punto-a-punto. Esto es más simple de configurar, administrar y entender. Sin embargo cada red point-to-point gasta/utiliza una subred IP. Ante esto se podría utilizar VLSM en OSPF, con una subred de 2 bits para cada red point-to-point. Pero, el costo es la sobrecarga de procesamiento de un LSA para red point-to-point. En el siguiente ejemplo RA se configura con una interface serial para soportar PVCs Frame Relay para las oficinas en RB y RC: El comando ip ospf network broadcast hace que el OSPF crea que la red conectada es multi-access, como un segmento Ethernet. Sin embargo, ya que la red no tiene una verdadera capacidad broadcast, las prioridades en RA, RB, y RC se deben especificar para forzar a que RA sea el DR en la red NBMA. • En redes non-broadcast es necesario especificar manualmente los vecinos • La prioridad determina la oportunidad de que tiene el vecino de ser elegido como Designated Router (DR) RA utiliza la prioridad por default de 1. RB y RC se configuran con una prioridad 0 (cero), lo cual hace que no puedan ser elegidos para ser DR. La red NBMA se puede modelar como una colección de redes punto-a-punto. Se configura los routers de la misma manera, pero se configura las interfaces como point-to-multipoint en vez de broadcast y no se especifica la prioridad OSPF, puesto que una red point-to-multipoint no elige un DR (el protocolo hello se utiliza para encontrar los vecinos). Academy Xperts 45 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF La red point-to-multipoint conusme únicamente una subred IP, pero crea múltiples rutas de host. Se pueden utilizar subinterfaces para modelar la red NBMA como una colección de redes point-to-point. Los routers al final de la subinterface point-to-point siempre forman adyacencia, al igual que los routers el final de la interfaces serial. No se ejerce una elección de DR. Puesto que OSPF soporta VLSM, no se malgastaría espacio de direcciones IP. Sin embargo, el uso de subinterfaces point-to-point en lugar de redes broadcast, genera LSAs por cada subinterface, lo cual agrega sobrecarga al procesamiento. Diseño de una red OSPF Jerarquía OSPF Diseñar una red OSPF grande, sin una estructura adecuad, es sinónimo de desastre. El diseño de la red OSPF debe estar claramente definido. Todos los cambios en el entorno OSPF deben ser acordes a la arquitectura OSPF. Por ejemplo, cuando se agrega un nuevo router, del ingeniero de red debe tener en cuenta los siguientes puntos: • Será ese router un router de área, un stub router,o un ABR? • Si el router es un ABR o un ASBR, qué rutas debería sumarizar el router? • Qué impacto tendría la falla de ese router en el ruteo OSPF? • Será este router un DR/BDR? • Cómo afectará este router el desempeño de otros routers OSPF? Direccionamiento IP Las direcciones IP deben ser colocadas en bloques que permitan la sumarización de rutas en los ABRs. Los bloques de direcciones debe tomar en cuenta el número de usuarios en el área, y dejar espacio para crecimiento. Se recomienda utilizar VLSM para la planeación de la asignación del direccionamiento IP. Router ID Se debe usar las direcciones loopback para asignar los router ID. Se debe elegir el router ID cuidadosamente, ya que éste impactará en la elección del DR/BDR en todas las redes multi-access conectadas. Se debe tener a mano una lista de los router IDs y de los nombres de los routers, para hacer mucho más fácil el proceso de troubleshooting de la red. DR/BDR Los routers que no deberían ser considerados para ser elegidos como DR son los que tienen bajos recursos de: • Procesador • Memoria • Ancho de banda Un router que se convierte en DR/BDR en múltiples redes, puede tener alto consumo de recursos de memoria y/o CPU. Area de Backbone Puesto que todo el tráfico inter-area atravesará el backbone, se debe asegurar de que existe el adecuado ancho de banda en los enlaces del backbone. El área de backbone estará compuesta típicamente de enlaces de gran ancho de banda en la red, con múltiples rutas/caminos entre los routers. El backbone debe tener múltiples caminos entre cualquier par de áreas que no son backbone. Un backbone particionado interrumpirá el tráfico inter-area, por lo que se debe asegurar que existe una adecuada redundancia en el backbone. Se debe usar el backbone únicamente para el tráfico inter-area, y no ubicar usuarios o servidores en el backbone. Número de routers en un Area El máximo número de routers en un área depende de varios factores: • Número de redes • CPU del router • Memoria del router, etc. Algunos autores sugieren que entre 40 y 50 es un número razonable, aunque no es extraño encontrar redes con 100 o 200 routers en un área, aunque los problemas de enlaces podrían sobrecargar el CPU de los routers en el área. Número de vecinos Si el número de routers en una red multi-access excede a 12 o 15, y el DR/BDR está teniendo problemas de desempeño, se debe pensar en un router más potente como DR/BDR. Es importante notar que tener hasta 50 routers en una red broadcast no es muy común. Se recomienda que el número de vecinos en todas las redes no debería exceder los 50. Sumarización de rutas Al sumarizar las rutas se debe tener en cuenta los siguientes puntos: Academy Xperts 46 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF • Ubicar bloques de direcciones para cada área, basado en los límites de bit. Puesto que las áreas crecen, se debe tener en mente el área puede necesitar ser dividido en dos. De ser posible, se debe ubicar las direcciones dentro de un área en bloques contiguos para permitir la sumarización al momento que se ejecuta la división. • Sumarizar en el backbone en el ABR, en lugar de sumarizar en el área que no es backbone (nonbackbone área). Esto reduce el tamaño de la base de datos LS en el área de backbone y las bases de datos LS en las áreas nonbackbone. • La sumarización de ruta tiene la ventaja de que una ruta-flap en una subred (que ha sido sumarizada) no dispara un LSA para que sea inundado, reduciendo la sobrecarga del procesamiento OSPF. • Si un área tiene múltiples ABRs y un ABR anuncia rutas más específicas, todo el tráfico fluirá a ese router. Esto es bueno si este es el efecto que se desea. De lo contrario, si lo que se quiere es usar todos los ABRs igualmente, entonces todos los ABRs deben tener idénticas sentencias de summary. • Sumarizar las rutas externas en el ASBR • Como regla sin discusión: sumarizar siempre. VLSM Los registros OSPF LSA llevan máscaras de subnet. Se fomenta el uso de VLSM para conservar el espacio de direcciones IP disponible. Stub Areas Un área con solo un ABR es el candidato ideal para un Stub Area. Cambiar el área en un Stub Area reducirá el tamaño de la base de datos LS sin la pérdida de cualquier información de ruteo útil. Debe recordarse que los Stub Areas no pueden soportar VLs o LSAs Type 5. Enlaces Virtuales (Virtual Links) Se debe diseñar la red de tal forma que no se requieran VLs. Los VLs deben ser usados únicamente como correcciones de emergencia, y no como parte del diseño. Timers OSPF Los Timers OSPF (hello-interval, dead-interval, etc) pueden ser dejados con sus valores por default. Sin embargo, en un ambiente multi-vendor, el ingeniero de red podría tener la necesidad de ajustar los timers para asegurarse de que coincidan. Haciendo Troubleshooting de OSPF OSPF es un esquema complejo y por lo tanto puede resultar difícil hacer troubleshooting, sin embargo, el ingeniero de red debe estar bien familiarizado con el funcionamiento interno. Los siguientes puntos describen algunos de los problemas más comunes de OSPF. ID del Area OSPF Cuando se usan múltiples sentencias de áreas de red en la configuración OSPF, el orden de las sentencias es crítico. Se debe chequear que las redes tienen asignado el Area ID deseado. OSPF no inicia El proceso OSPF puede no iniciar en un router si no se puede establecer el Router ID. Se debe chequear si se ha establecido un router ID Si no se ha establecido un Router ID, se debe verificar si el router tiene una interface activa (preferiblemente una interface loopback) con una dirección IP Verificar las relaciones del vecino Luego de que un router está habilitado para iniciar OSPF, se establecerá una estructura de datos de interface para cada interface configurada para que corra OSPF. Se debe verificar que el OSPF está activo en las interfaces requeridas Si el OSPF está activo, se deben chequear los parámetros respectivos. Muchos problemas en OSPF se deben a una incorrecta configuración de la interface. Dos routers no forman parte de una relación de vecino a menos que coincidan los parámetros especificados en el protocolo hello. Si dos routers no pueden establecer una relación de vecino, y ambos están activos en la red multi-access (es decir que se pueden hacer ping uno al otro), es porque sus parámetros hello no coinciden. Sumarización de Ruta Si un área tiene múltiples ABRs y un ABR anuncia rutas más específicas que otros ABR, entonces todo el tráfico fluirá a ese router. Pero, si lo que se desea es que todos los ABRs se usen igualmente, entonces todos los ABRs deben tener idénticos summary statements. Academy Xperts 47 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Routers Sobrecargados Debe recordarse que los ABRs hacen más trabajo que los routers internos, y que los DR/BDR trabajan más que los otros routers. Un router que se convierte en DR/DBR en múltiples redes, incluso hace mucho más trabajo. Los routers en Stub Areas y NSSA Area realizan menos trabajo. Exceso de SPF (Shortest Path First) Un cambio frecuente de interfaces puede ocasionar que se ejecute frecuentemente el algoritmo SPF, ocasionando que el CPU desatienda otros procesos críticos del router. En el ejemplo anterior, el algoritmo SPF se ha ejecutado 24 veces desde la última vez que el router hizo un reboot. Según el ejemplo, el SPF está programado para tener un retardo de 5 segundos en su ejecución después de que se recibe la actualización de un LSA y el tiempo mínimo entre ejecuciones SPF se configura a 10 segundos. Esto hace que el SPF se abstenga de usar todos los recursos de procesador en el caso de que todas las interfaces empiecen a cambiar. Usando la Base de Datos LS La base de datos LS es el punto de entrada del algoritmo SPF, y por lo tanto se la puede analizar para hacer troubleshooting cuando se pierden rutas. El análisis de la base de datos LS puede ser muy útil cuando se está trabajando con Stub Areas, TSAs, o NSSAs, ya que estas áreas bloquean ciertos LSAs. Bitácora/registros (Logs) de Red El comando log presenta los datos históricos y es muy útil para analizar las interrupciones en la red. Laboratorio de OSPF • Habilite la redistribución tipo 1 para todas las rutas conectadas • Revise la tabla de ruteo • Habilite la redistribución tipo 1 para todas las rutas estáticas • Revise la tabla de ruteo Academy Xperts 48 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Laboratorio Costos OSPF • Elegir el correcto tipo de red para todas las interfaces OSPF • Asignar los costos (próximo slide) para asegurar el tráfico de una vía en el área • Chequear la tabla de ruteo para observar las rutas ECMP • Asignar los costos necesarios para que el enlace de backup sea usado solamente cuando los otros enlaces fallan • Chequear la redundancia de la red OSPF • Asegúrese que el ABR esté en el DR de su área, pero no en el área de backbone Laboratorio Costos OSPF + Nueva Ruta Academy Xperts 49 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 3: OSPF Laboratorio de Area OSPF • Cree su propia área o Area name “Area<Z>” o Area-id= 0.0.0.Z • Asignar redes a las áreas • Chequear sus vecinos OSPF y las tablas de ruteo • El propietario del ABR también debería configurar el área de backbone y las redes • El AP principal debería estar en la lista de vecinos OSPF del ABR. Academy Xperts 50 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 4: Ruteo e Interface Point-to-Point Capítulo 4: Ruteo e Interface Point-to-point Vlan, EoIP, direccionamiento punto-a-punto Virtual LAN (802.1Q) • Virtual LAN permite a los dispositivos de red ser agrupados en subgrupos independientes incluso si están ubicados en segmentos de Lan diferentes • Para que los routers se comuniquen el VLAN ID debe ser el mismo para las intefaces VLAN • Los puertos en el router soportan múltiples (hasta 250 4095) VLANs en una interfaz ethernet • Una VLAN puede ser configurada sobre otra interfaz VLAN “Q-in-Q” (802.1Q) Creando una interfaz VLAN VLAN en Switch • Los puertos de switch compatibles con VLAN pueden ser asignados a uno o varios grupos basados en VLAN tag • Los puertos de switch en cada grupo pueden ser configurados como: o Tagged mode: permite añadir VLAN tag de grupos en transmisión y permite recibir frames con este tag o Untagged mode: permite remover VLAN tag de grupos en transmisión, y permite recibir solo paquetes unttaged o <Undefined>: el puerto no tiene relación a este grupo • Trunk port: es un puerto taggeado para varios grupos VLAN Laboratorio VLAN • Crear grupos de 4 participantes • Conectar los equipos usando wireless o 1 AP o 3 clientes • Crear un enlace VLAN para cada participante • Asignar redes /30 a los enlaces VLAN y verificarsu funcionalidad IPIP • IPIP (IPv4) permite crear un túnel encapsulando paquetes IP en paquetes IP para enviarlos a otro router • IPIP es un túnel en capa 3. No puede ser “bridged” (L2) Academy Xperts 51 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 4: Ruteo e Interface Point-to-Point • RouterOS implementa túneles IPIP acorde al RFC 2003, por lo tanto es compatible con las implementaciones IPIP de otros vendedores • Para crear un túnel se debe especificar la dirección del router local y del router remoto en ambos lados del túnel Creando una interface IPIP Laboratorio IPIP • Reemplace todas las VLANs (del laboratorio anterior) con túneles IPIP • Verifique que puede hacer “ping” a la dirección remota antes de crear el túnel • Asigne direcciones /30 (del laboratorio anterior) a las intefaces IPIP y cheque el funcionamiento de los túneles Direccionamiento /30 Direccionamiento point-to-point • El direccionamiento point-to-point utilzia solo dos Ips por enalce mientras /30 utiliza cuatro Ips • No hay dirección de broadcast, sino que la dirección de red debe ser configurada manualmente a la dirección IP opuesta. Ejemplo: o Router 1: address=1.1.1.1/32, network=2.2.2.2 o Router 2: address=2.2.2.2/32, network=1.1.1.1 • Pueden haber direcciones /32 idénticas en el router. Cada dirección tendrá una diferente ruta conectada Direccionamiento point-to-point Academy Xperts 52 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 4: Ruteo e Interface Point-to-Point Laboratorio de direccionamiento point-to-point • Reemplace todas las direcciones /30 en las interfaces IPIP (del laboratorio anterior) con direcciones point-to-point /32 • Asegúrese de que cada participante puede hacer “ping” a su dirección IP XY.XY.XY.XY a través de todos los túneles IPIP • Analice cuántas direcciones IP fueron utilizadas en total en túneles IPIP para todo el grupo Tunel Ethernet Over IP (EoIP) • (IP protocol 47/GRE) Tunneling EoIP crea un tunel Ethernet (encapsula frames Ethernet en paquetes IP) entre 2 routers en una conexión IP • Tunneling EoIP es un protocolo propetario de Mikrotik RouterOS • EoIP es un tunel de L2. Puede ser “bridged” • Para crear un tunel se debe especificar la dirección del router remoto y elegir un único Tunnel ID • Se debe chequear que la interfaz EOIP tenga una diferente MAC-address que el lado opuesto Beneficios de Túnel EoIP • Extender LANs sobre Internet • Extender LANs sobre túneles encriptados • Extender LANs sobre redes wireless “ad-hoc” Creación de un Tunel EOIP EOIP y Bridging Laboratorio EOIP • Reemplace las VLANs con túneles EOIP • Verificar que es posible hacer “ping” las direcciones remotas antes de crear un túnel hacia el remoto • Asignar direcciones /30 a las interfaces EOIP y chequear todos los túneles • Hacer bridge de todas las interfaces EOIP con la interfaz local • Revisar en el winbox loader la opción “Discovery” Academy Xperts 53 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 5: VRRP Capítulo 5: VRRP Virtual Router Redundancy Protocol VRRP • La implementación de VRRP en MikroTik RouterOS es compatible con RFC2338 • VRRP es un protocolo usado para asegurar el acceso constante a ciertos recursos. • 2 o más routers (referidos como routers VRRP) crean un cluster de Alta Disponibilidad (también referidos como Routers Virtuales) con fail-over dinámico • Cada router puede participar en hasta 255 routers virtuales por interfaz • VRRP • Una o más direcciones IP se pueden asignar a un router virtual • Un nodo de un router virtual puede tener uno de los siguientes estados: o Master o Backup VRRP Master/Backup VRRP Master • El router adquiere este estado cuando el nodo responde todos los requerimientos a la dirección IP • Puede haber solo un nodo MASTER en un router virtual. Este nodo envía paquetes de aviso a todos los routers BACKUP (usando dirección multicast) cada cierto tiempo (este tiempo se configura en la opción interval) VRRP Backup • No responde ningún requerimiento a las direcciones IP de la instancia. • Si el MASTER se vuelve no-disponible (si al menos 3 paquetes secuenciales VRRP se pierden) se genera un proceso de elección y se proclama un nuevo MASTER basado en su prioridad. Notas VRRP • VRRP no trabaja en interfaces VLAN ya que es imposible asegurar que la MAC-address de una VLAN sea diferente de la MAC-address del router virtual • El máximo número de clusters en una red es 255 teniendo cada uno un único Virtual Router ID (VRID) • Cada router que participa en un cluster VRRP debe tener asignada una prioridad VRRP: Implementación Básica R1 /system identity set name=R1 /ip address add address=192.168.1.1/24 interface=ether1 /interface vrrp add interface=ether1 vrid=49 priority=254 /ip address add address=192.168.1.254/32 interface=vrrp1 R1 R2 R2 (eth1) 192.168.1.1/24 (eth1) 192.168.1.2/24 /system identity set name=R2 Master vrrp1 Backup /ip address add address=192.168.1.2/24 interface=ether1 192.168.1.254 /interface vrrp add interface=ether1 vrid=49 /ip address add address=192.168.1.254/32 interface=vrrp1 /interface vrrp print 192.168.1.0/24 (cliente) ping 192.168.1.254 arp -a * observar MAC address de 192.168.1.1 192.168.1.2 192.168.1.254 Academy Xperts 54 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 5: VRRP VRRP + Internet (router) Apoyo usando ECMP Internet ECMP Router (eth1) (eth2) (bridge1) 172.19.1.254/24 - Asignar IP a eth3 de R1 y R2 - Router: eth1+eth2 = bridge1 - Asignar IP a bridge1 (eth3) 172.19.1.1/24 (eth3) 172.19.1.2/24 Aplicar ECMP en Router [admin@Router] > ip route add dst-address=192.168.1.0/24 gateway=172.19.1.1, 172.19.1.2 R1 R2 check-gateway=ping (eth1) 192.168.1.1/24 (eth1) 192.168.1.2/24 Master vrrp1 Backup Existen inconvenientes en esta implementación? 192.168.1.254 192.168.1.0/24 VRRP + Internet (router) Apoyo usando ECMP – Identificando problemas Internet Internet ECMP ECMP Router Router (eth1) (eth2) (bridge1) 172.19.1.254/24 (eth1) (eth2) (bridge1) 172.19.1.254/24 (eth3) 172.19.1.1/24 (eth3) 172.19.1.2/24 (eth3) 172.19.1.1/24 (eth3) 172.19.1.2/24 R1 R2 R1 R2 (eth1) 192.168.1.1/24 (eth1) 192.168.1.2/24 (eth1) 192.168.1.1/24 (eth1) 192.168.1.2/24 Master vrrp1 Backup Master vrrp1 Backup 192.168.1.254 192.168.1.254 192.168.1.0/24 192.168.1.0/24 ping 172.19.1.254 ping 172.19.1.254 Academy Xperts 55 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 5: VRRP VRRP + Internet (router) Apoyo usando ECMP + Bridge + STP Internet Router (bridge1) 172.19.1.254/24 Solución: ECMP + Bridge + STP Router (bridgeR1R2) 172.19.1.1/24 (bridgeR2R1) 172.19.1.2/24 [admin@Router] > interface bridge set bridge1 protocol-mode=stp (eth2) R1 R1 (eth2) R2 [admin@R1] > interface bridge add name=bridgeR1R2 protocol-mode=stp [admin@R1] > interface bridge port add interface=ether2 bridge=bridgeR1R2 (eth1) 192.168.1.1/24 (eth1) 192.168.1.2/24 [admin@R1] > interface bridge port add interface=ether3 bridge=bridgeR1R2 Master vrrp1 Backup * la IP (172.19.1.1) se asigna ahora a bridgeR1R2 192.168.1.254 R2 [admin@R2] > interface bridge add name=bridgeR2R1 protocol-mode=stp 192.168.1.0/24 [admin@R2] > interface bridge port add interface=ether2 bridge=bridgeR2R1 [admin@R2] > interface bridge port add interface=ether3 bridge=bridgeR2R1 * la IP (172.19.1.2) se asigna ahora a bridgeR2R1 VRRP + Internet (router) Apoyo usando VRRP en 172.19.1.0 Internet Router (bridge1) 172.19.1.254/24 Router [admin@Router] > interface bridge set bridge1 protocol-mode=stp [admin@Router] > ip route add dst-address=192.168.1.0/24 gateway=172.19.1.253 Backup VRRProuter Master 172.19.1.253 (eth3) 172.19.1.1/24 (eth3) 172.19.1.2/24 R1 [admin@R1] > interface vrrp add name=VRRProuter interface=ether3 vrid=2 priority=100 [admin@R1] > ip address add address=172.19.1.253/24 interface=VRRProuter R1 R2 (eth1) 192.168.1.1/24 (eth1) 192.168.1.2/24 R2 [admin@R2] > interface vrrp add name=VRRProuter interface=ether3 vrid=2 priority=200 Master vrrp1 Backup [admin@R2] > ip address add address=172.19.1.253/24 interface=VRRProuter 192.168.1.254 192.168.1.0/24 Academy Xperts 56 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 5: VRRP VRRP + Internet (router) Requerimiento de 2 Gateways en LAN Internet Router R1 R1 R2 /ip address add address=192.168.1.1/24 interface=ether1 /interface vrrp add name=VR1 interface=ether1 vrid=49 priority=254 /interface vrrp add name=VR2 interface=ether1 vrid=77 (eth1) 192.168.1.1/24 (eth1) 192.168.1.2/24 /ip address add address=192.168.1.253 interface=VR1 /ip address add address=192.168.1.254 interface=VR2 Master VR1 Backup 192.168.1.253 R2 Backup VR2 Master /ip address add address=192.168.1.2/24 interface=ether1 192.168.1.254 /interface vrrp add name=VR1 interface=ether1 vrid=49 /interface vrrp add name=VR2 interface=ether1 vrid=77 priority=254 /ip address add address=192.168.1.253 interface=VR1 192.168.1.0/24 /ip address add address=192.168.1.254 interface=VR2 GW: 192.168.1.253 GW: 192.168.1.254 Academy Xperts 57 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 6: Túneles Capítulo 6: Túneles Introducción Los túneles son una forma de ampliar una red privada a través de una red pública, como Internet. A los Túneles también se les conoce como VPNs (redes privadas virtuales). • El concepto de seguridad se asocia con VPN. Es recomendable ya que no se desea que el tráfico de los usuarios vaya a través de redes que no son seguras Se conoce como túnel o tunneling a la técnica que consiste en encapsular un protocolo de red sobre otro (protocolo de red encapsulador) creando un túnel de información dentro de una red de computadoras. El uso de esta técnica persigue diferentes objetivos, dependiendo del problema que se esté tratando, como por ejemplo la comunicación de islas en escenarios multicast, la redirección de tráfico, etc. La técnica de tunelizar se suele utilizar para trasportar un protocolo determinado a través de una red que, en condiciones normales, no lo aceptaría. Otro uso de la tunelización de protocolos es la creación de diversos tipos de redes privadas virtuales. El establecimiento de dicho túnel se implementa incluyendo una PDU (unidad de datos de protocolo) determinada dentro de otra PDU con el objetivo de transmitirla desde un extremo al otro del túnel sin que sea necesaria una interpretación intermedia de la PDU encapsulada. De esta manera se encaminan los paquetes de datos sobre nodos intermedios que son incapaces de ver en claro el contenido de dichos paquetes. El túnel queda definido por los puntos extremos y el protocolo de comunicación empleado, que entre otros, podría ser SSH. Así, el protocolo A es encapsulado dentro del protocolo B, de forma que el primero considera al segundo como si estuviera en el nivel de enlace de datos. Ejemplos de protocolos tunelizados • L2TP (Layer 2 Tunneling Protocol) • MPLS (Multiprotocol Label Switching) • PPTP (Point-to-Point Tunneling Protocol) • PPPoE (point-to-point protocol over Ethernet) • PPPoA (point-to-point protocol over ATM) • IPSec (Internet Protocol security) • IEEE 802.1Q (Ethernet VLANs) • 6to4 (IPv6 over IPv4 as protocol 41) RouterOS y Túneles MikroTik RouterOS provee funcionalidad escalable de Autenticación, Autorización y Contabilización • AAA = Authentication Authorization Accounting (Contabilización) La autenticación local se logra usando una Base de Datos de Usuario y una Base de Datos de Perfil (profile). La configuración del usuario está compuesta por el registro del respectivo usuario (tomado de la Base de Datos de Usuario), el ítem asociado de la Base de Datos de Perfil (profile) y el ítem en la base de datos de Perfil en cual está configurado como default para un servicio dado al que el usuario está autenticando. Las configuraciones del Perfil por default de la base de Datos del Perfil, tienen la prioridad más baja, mientras que las configuraciones de los registros de acceso de usuario de la Base de Datos de Usuario tiene la más alta prioridad con la única excepción de que siendo una dirección IP particular toma precedencia sobre los Pools de direcciones IP en las configuraciones local-address y remote-address. El soporte para la autenticación RADIUS le proporciona al ISP o al administrador de red la habilidad para manejar el acceso y la contabilidad de usuarios PPP desde un solo servidor a través de una gran red. MikroTik RouterOS tiene un Cliente RADIUS que puede autenticar conexiones PPP, PPPoE, PPTP, L2TP e ISDN. Los atributos recibidos del servidor RADIUS invalidan las configuraciones del Perfil (profile) por default, pero si algunos parámetros no son recibidos, entonces son tomados del Perfil por default respectivo /ppp profile (perfiles de usuario) Los perfiles PPP se utilizan para definir los valores por default de los registros de usuario que se almacenan en el submenu /ppp secret. Las configuraciones /ppp secret de la Base de Datos de Usuario invalidan las configuraciones /ppp profile correspondientes, excepto que las direcciones IP simples siempre tienen precedencia sobre los Pool de direcciones IP cuando se especifican como parámetros en local-addres o remote-address. Los PPP profiles representan los parámetros de configuración para ser utilizado por los clientes PPP, pero no limitados a: • Dirección IP o Pool de direcciones (remotas o locales) • Compresión • Cifrado /ppp profile (example from a client) add change-tcp-mss=yes name=Profile-external\ use-compression=yes use-encryption=yes use-vj-compression=no /ppp profile (example from a server) add change-tcp-mss=yes local-address=192.168.222.1\ name=Profile-external remote-address=192.168.222.2 use-compression=yes\ use-encryption=yes use-vj-compression=no add change-tcp-mss=no dns-server=192.168.5.1 local-address=192.168.5.1 name=Profile-internal\ remote-address=Pool-VPN use-compression=yes use-encryption=yes use-vj-compression=no Academy Xperts 58 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 6: Túneles Parámetros • address-list (string; Default: ) .- Especifica el nombre del address-list a donde se agregarán las direcciones asignadas PPP • bridge (string; Default: ) .- Nombre de la interface bridge a la que se agregará la interface ppp como un puerto esclavo. Ambos puntos finales del tunel (server y cliente) deben estar en un bridge para que esto funcione. • change-tcp-mss (yes | no | default; Default: default) .- Permite cambiar la configuración de la conexión MSS o yes : ajusta el valor de la conexión MSS o no : no ajusta el valor de la conexión MSS o default : obtiene este valor del perfil por default de la interface • comment (string; Default: ) .- Campo para escribir un comentario • dhcpv6-pd-pool (string; Default: ) .- Nombre del Pool Ipv6 que se usará para el servidor DHCPv6-PD creado dinámicamente cuando los clientes se conectan. • dns-server (IP; Default: ) .- Dirección IP del server DNS que se suministra a los clientes PPP • idle-timeout (time; Default: ) .- Especifica la cantidad de tiempo luego del cual el enlace se terminará si es que no hay actividad presente. • incoming-filter (string; Default: ) .- Nombre del chain de firewall para paquetes entrantes. El chain especificado obtiene el control para cada paquete que viene del cliente. El chain PPP debería ser agregado manualmente, y también deberían agregarse las reglas con action=jump jump-target=ppp a otros chains relevantes para que esta característica funcione. • local-address (IP address | pool; Default: ) .- Especifica la dirección del túnel o el nombre del Pool del cual se asigna la dirección a la interface PPP local • name (string; Default: ) .- Nombre del Perfil PPP • only-one (yes | no | default; Default: default) .- Define si es que un usuario está permitido tener más de una conexión a la vez. o yes – Un usuario NO está permitido tener más de una conexión al mismo tiempo o no – El usuario está permitido a tener más de una conexión a la vez o default – Obtiene este valor del Perfil por default de la Interface • outgoing-filter (string; Default: ) .- Nombre del chain de firewall para paquetes salientes. El chain especificado obtiene el control para cada paquete que va hacia el cliente. El chain PPP debería ser agregado manualmente, y también deberían agregarse las reglas con action=jump jump-target=ppp a otros chains relevantes para que esta característica funcione. • rate-limit (string; Default: ) .- La limitación de velocidad desde el punto de vista del router se presenta en la siguiente forma (rx es el tráfico de subida del cliente, y tx es el tráfico de bajada del cliente): o rx-rate[/tx-rate] [rx-burst-rate[/tx-burst-rate] [rx-burst-threshold[/tx- burst-threshold] [rx-burst-time[/tx-burst-time] [priority] [rx-rate-min[/tx- rate-min]]]] o Todas las velocidades están medidas en bits-por-segundo (bps), a menos que le siga el sufijo k (kilobits por segundo) o el sufijo M (megabits por segundo) o Si no se especifica el tx-rate, entonces el rx-rate sirve también como tx-rate o Lo mismo aplica para tx-burst-rate, tx-burst-threshold y tx-burst-time. Si rx-burst- threshold y tx-burst-threshold no se especifican (but burst-rate está especificado), rx-rate y tx-rate se utilizan como burst thresholds. o Si rx-burst-time y tx-burst-time no se especifican, se utiliza 1s como default. La prioridad toma los valores 1..8, donde 1 representa a la prioridad más alta, y 8 la prioridad más baja. o Si rx-rate-min y tx-rate-min no se especifican, entonces se utilizan los valores rx-rate y tx-rate o Los valores de rx-rate-min y tx-rate-min no pueden exceder a los valores rx-rate y tx-rate. • remote-address (IP; Default: ) .- Especifica la dirección del túnel o el nombre del Pool del cual se asigna la dirección a la interface PPP remota • remote-ipv6-prefix-pool (string | none; Default: none) .- Asigna el prefijo del Pool IPv6 al cliente e instala la correspondiente ruta IPv6. • session-timeout (time; Default: ) .- Especifica el máximo tiempo de conexión que se puede establecer. Por default no se configura límite de tiempo. • use-compression (yes | no | default; Default: default) .- Especifica si se usa compresión o no. Esta configuración no afecta los túneles OVPN o yes – Habilita la compresión de datos o no – Deshabilita la compresión de datos o default – Obtiene este valor del Perfil por default de la Interface • use-encryption (yes | no | default | require; Default: default) .- Especifica si se usa encriptación o no. Esta configuración no afecta los túneles OVPN o yes – Habilita la encriptación de datos o no – Deshabilita la encriptación de datos o default – Obtiene este valor del Perfil por default de la Interface Academy Xperts 59 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 6: Túneles • use-ipv6 (yes | no | default | require; Default: default) .- Especifica si se permite IPv6. Por default se habilita si es que el paquete IPv6 está instalado. o yes – Habilita el soporte IPv6 o no – Deshabilita el soporte IPv6 o default – Obtiene este valor del Perfil por default de la Interface o require – Requiere explícitamente soporte IPv6 • use-mpls (yes | no | default | require; Default: default) .- Especifica si es que se permite MPLS sobre PPP o yes – Habilita el soporte MPLS o no – Deshabilita el soporte MPLS o default – Obtiene este valor del Perfil por default de la Interface o require – Requiere explícitamente soporte MPLS • use-vj-compression (yes | no | default; Default: default) .- Especifica si es que se usa el algoritmo de compresión de cabecera Van Jacobson o yes – Habilita la compresión de cabecera Van Jacobson o no – Deshabilita la compresión de cabecera Van Jacobson o default – Obtiene este valor del Perfil por default de la Interface • wins-server (IP address; Default: ) .- Permite especificar la dirección IP del servidor WINs para suministrar a los clientes Notas Importantes • Existen dos Perfiles por Default que no pueden ser removidos: /ppp profile print Flags: * - default 0 * name="default" use-compression=no use-vj-compression=no use-encryption=no only-one=no change-tcp-mss=yes 1 * name="default-encryption" use-compression=default use-vj-compression=default use-encryption=yes only-one=default change-tcp-mss=default • Se debe usar el algoritmo de compresión Van Jacobson únicamente si es necesario, ya que se reducen las comunicaciones en canales malos o congestionados. • Los argumentos incoming-filter y outgoing-filter agregan reglas de jump dinámicas al chain PPP, donde el argumento jump-target será igual al argumento incoming-filter o outgoing-filter en /ppp profile. Por lo tanto, el chain PPP debe ser agregado manualmente antes de que se cambien estos argumentos. • El parámetro only-one se ignora si se usa la autenticación RADIUS • Si hay más de 10 conexiones PPP simultáneas, se recomienda apagar (off) la propiedad change-mss, y usar una regla general de cambio MSS en la tabla de mangle, para reducir la utilización del CPU. /ppp secret (base de datos de usuario) La Base de Datos de Usuario PPP almacena los registros de acceso de usuario PPP con el perfil de usuario PPP asignado a cada usuario. Los PPP secrets se encuentran en PPP servers y también podemos especificar los parámetros básicos y necesarios para autenticar a un cliente, tales como: • Nombre: Identificación del usuario • Contraseña: contraseña del usuario • Servicio: el protocolo que está dando servicio (si de dejan en “any” el PPP secret autenticara al usuario a través de algunos de estos servicios (PPPoE, L2TP, PPTP, etc.)) • Perfil: el subconjunto de configuración que utilizara este usuario. Los perfiles permiten parámetros a ser utilizados por muchos usuarios sin tener que volver a escribir todo cada vez. Los clientes no utilizan PPP secrets como credenciales de autenticación. Se especifican en la interfaz del cliente PPP bajo los parámetros de “Usuario” y “Contraseña” /ppp secret add name=Pod4-external password=pod4-123 profile=Profile-external routes=192.168.4.0/24 add name=alain password=alain!! profile=Profile-internal Parámetros • caller-id (string; Default: ) .- Para PPTP y L2TP, este parámetro es la dirección IP desde la cual un cliente debe conectarse. Para PPPoE es la dirección MAC (escrito en letras mayúsculas) desde la cual un cliente debe conectarse. Para ISDN es el número del caller (que puede o no puede ser provisto por el operador) desde el cual el cliente debe llamar. • comment (string; Default: ) .- Una corta descrición del usuario • disabled (yes | no; Default: no) .- Permite especificar si se usará un secret • limit-bytes-in (integer; Default: 0) .- Especifica la máxima cantidad de bytes que un cliente puede subir (upload) en una sesión • limit-bytes-out (integer; Default: 0) .- Especifica la máxima cantidad de bytes que un cliente puede descargar (download) Academy Xperts 60 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 6: Túneles • local-address (IP address; Default: ) .- Dirección IP que será configurada localmente en la interface PPP • name (string; Default: ) .- Nombre usado para la autenticación • password (string; Default: ) .- Contraseña (password) usada para la autenticación • profile (string; Default: default) .- Especifica qué perfil se utilizará • remote-address (IP; Default: ) .- Especifica la dirección IP que se asignará a la interface PPP remota • remote-ipv6-prefix (IPv6 prefix; Default: ) .- Prefijo IPv6 asignado al cliente PPP. El prefijo se agrega a la lista de prefijo ND que permite la configuración automática de direcciones sin estado en una interface PPP. Esta opción está disponible desde la v5.0 • routes (string; Default: ) .- Especifica las rutas que aparecen en el server cuando el cliente se conecta. El formato de la ruta es dst-address gateway metric (por ejemplo 10.1.0.0/24 10.0.0.1 1). Se peude especificar varias rutas separando con comas. Este parámetro será ignorado por OpenVPN • service (any | async | isdn | l2tp | pppoe | pptp | ovpn | sstp; Default: any) .- Especifica el tipo de servicio que un usuario específico podrá utilizar. /ppp active (usuarios activos) Este submenú permite minitorear los usuarios activos o usuarios conectados. Representa el estado actual de las conexiones. Útil para depurar y verificar el funcionamiento correcto de sus túneles. • /ppp active print mostrará todos los usuarios conectados actualmente • /ppp active print stats mostrará los bytes y paquetes recibidos /ppp active print detail Flags: R - radius 0 name=”alain” service=pppoe caller-id=”28:D2:44:2C:06:EE”\ address=192.168.5.100 uptime=3m56s encoding=”MPPE128 statefull” session-id=0x81B00044\ limit-bytes-in=0 limit-bytes-out=0 1 name=”Pod4-external” service=pppoe caller-id=”D4:CA:6D:8E:1ª:97”\ address=192.168.222.2 uptime=37s encoding=”MPPE128 stateless” session-id=0x81B00045\ limit-bytes-in=0 limit-bytes-out=0 /ppp active print Flags: R – radius # NAME SERVICE CALLER-ID ADDRESS UPTIME ENCODING 0 alainpppoe 28:D2:44:2C:06:EE 192.168.5.100 4m12s MPPE128 statefull 1 Pod4-exte... pppoe D4:CA:6D:8E:1ª:97 192.168.222.2 53s MPPE128 stateless Parámetros • address (IP address) .- La dfirección IP que el cliente obtiene del server • bytes (integer) .- Cantidad de bytes transferidos a través de esta conexión. La primera representa la cantidad de tráfico transmitido desde el punto de vista del router, mientras que la segunda muestra la cantidad de tráfico recibido. • caller-id (string) .- Para PPTP y L2TP es la dirección IP desde la que el cliente está conectado. Para PPPoE es la dirección MAC desde la que el cliente está conectado. • encoding (string) .- Muestra la encriptación y codificación (separado con “/” si es asimétrico) que está siendo usado en esta conexión. • limit-bytes-in (integer) .- Máxima cantidad de bytes que el usuario está permitido enviar al router • limit-bytes-out (integer) .- Máxima cantidad de bytes que el usuario está permitido enviar al cliente • name (string) .- Nombre de usuario proporcionado en la fase de autenticación • packets (integer/integer) .- Cantidad de paquetes transferidos a través de esta conexión. La primera representa la cantidad de tráfico transmitido desde el punto de vista del router, mientras que la segunda muestra la cantidad de tráfico recibido. • service (async | isdn | l2tp | pppoe | pptp | ovpn | sstp) .- Tipo de servicio que el usuario está usando • session-id (string) .- Muestra el identificador de cliente único • uptime (time) .- Tiempo de actividad del usuario /ppp aaa (AAA remoto) Las configuraciones en este menú permiten sonfigurar la contabilización (accounting) y autenticación (authentication) RADIUS. La base de datos de usuario RADIUS se consulta únicamente si el nombre usuario (username) requerido no se encuentra en la base de datos de usuario local Parámetros • accounting (yes | no; Default: yes) .- Habilita la contabilización (accounting) RADIUS • interim-update (time; Default: 0s) .- Intervalo de tiempo de actualización interino • use-radius (yes | no; Default: no) .- Habilita la autenticación de usuario vía RADIUS. Si no se encuentra le entrada en la base de datos Secret Local, entonces el cliente será autenticado vía RADIUS. /ppp client (cliente PPP) Parámetros Academy Xperts 61 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 6: Túneles • add-default-route (yes | no; Default: no) .- Especifica si se agrega la ruta por default para encaminar todo el tráfico sobre el túnel. • allow (pap | chap | mschap1 | mschap2; Default: pap,chap,mschap1,mschap2) .- Especifica los protocolos permitidos a usar para la autenticación • apn (string; Default: ) .- Nombre del Access Point (APN = Access Point Name) del Proveedor de Servicio • comment (string; Default: ) .- Nombre que describe el item • data-channel (integer; Default: 0) .- Especifica cuál de los canales de puertos es usado para transferir datos. • default-route-distance (integer; Default: 1) .- A partir de la v6.2, configura el valor distancia aplicado para la ruta por default creada automáticamente, si es que también se ha seleccionado add-default-route • dial-command (string; Default: "ATDT") .- Comando dial que se va a usar. Por default se configura el modo del tono de marcado • dial-on-demand (yes | no; Default: no) .- Habilita/deshabilita dial on demand • disabled (yes | no; Default: yes) .- Especifica si es que la interface esta deshabilitada o no. Por default está deshabilitada • info-channel (integer; Default: 0) .- Especifica cuál de los canales de puerto (por channels) se utiliza para info • keepalive-timeout (integer [0..4294967295]; Default: 30s) .- Keepalive timeout PPP en segundos • max-mru (integer; Default: 1500) .- Unidad de Recepción Máxima (MRU = Maximum Receive Unit). Tamaño máximo del paquete que la interface PPP estará habilitada para recibir sin fragmentación de paquetes • max-mtu (integer; Default: 1500) .- Unidad de Tránsmisión Máxima (MTU = Maximum Transmission Unit). Tamaño máximo del paquete que la interface PPP estará habilitada para enviar sin fragmentación de paquetes • modem-init (string; Default: "") .- String de inicialización del modem • mrru (disabled | integer; Default: disabled) .- Máximo tamaño del paquete que puede ser recibido en el enlace. Si un paquete es más grande que el tunel MTU, será dividido en múltiples paquetes, permitiendo que el tamaño total de los paquetes IP o Ethernet sean enviados sobre el túnel. • name (string; Default: ) .- Nombre descriptivo de la interface • null-modem (yes | no; Default: no) .- Habilita/deshabilita el modo null-modem (cuando está habilitado, no se envían cadenas de inicialización al modem) • password (string; Default: "") .- Contraseña (password) usada para autenticación • phone (string; Default: "") .- Número de teléfono para marcar (dial-out) • pin (string; Default: "") .- Código de Pin de las Tarjetas SIM • port (string; Default: "") .- Nombre del puerto Serial o USB donde está conectado el modem • profile (name; Default: default) .- Perfil PPP que se utiliza • remote-address (IP Address; Default: ) .- Dirección IP remota • use-peer-dns (yes | no; Default: yes) .- Usa las configuraciones DNS server del servidor remoto • user (string; Default: ) .- Nombre de usuario usado para autenticación /ip pool El Pool IP define un rango de direcciones IP que es utlizado por el Server DHCP y también por los Servers Point-to-Point. Es decir que no sólo es utilizado para DHCP, sino que también se puede utilizar para los clientes PPP y Hotspot. Útil cuando una interfaz puede dar servicio a muchos clientes. Las direcciones se asignan a partir del Pool de forma automática. Rangos de IPs son listas de direcciones IP que no se repiten entre si y que se pueden asignar a los clientes a través de servicios (DHCP, PPP, Hotspot). Parámetros • name (name) .- El nombre del Pool • next-pool (name) .- Cuando la dirección se adquiere de un pool que no tiene direcciones libres, y la propiedad next-pool está configurada a otro pool, entonces la siguiente dirección se obtendrá del next-pool • ranges (IP address) .- La lista de dirección IP de los rangos de dirección IP en la forma: desde1-hasta1, desde2-hasta2, …, desdeN-hastaN. Por ejemplo, 10.0.0.1-10.0.0.27,10.0.0.32-10.0.0.47 Vamos a demostrar con un ejemplo. Usted tiene 50 ordenadores de la LAN corporativa y 50 que vienen desde VPN. /ip pool add name=Pool-PC ranges=192.168.5.50-192.168.5.99 add name=Pool-VPN ranges=192.168.5.100-192.168.5.149 Supongamos ahora que usted necesita agregar 50 equipos en el Pool de la LAN /ip pool print # NAME RANGES 0 Pool-PC 192.168.5.50-192.168.5.99 1 Pool-VPN 192.168.5.100-192.168.5.149 /ip pool set 0 ranges=192.168.5.50-192.168.5.99,192.168.5.150-192.168.5.199 /ip pool> print # NAME RANGES 0 Pool-PC 192.168.5.50-192.168.5.99 Academy Xperts 62 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 6: Túneles 192.168.5.150-192.168.5.199 1 Pool-VPN 192.168.5.100-192.168.5.149 Asignaciones para un servicio • Un Pool puede ser asignado para diferentes servicios tales como DHCP, PPP y Hotspot. • Veremos la sintaxis más adelante Ejercicio: Cómo comunicamos las redes A y B? PPPoE El protocolo PPPoE (Point to Point Protocolo ver Ethernet) proporciona una amplia administración de usuario, administración de red y beneficios de contabilización (accounting) a los ISPs y administradores de red. En muchos sitios el PPPoE se utiliza principalmente en los ISPs para controlar las conexiones de clientes por xDSL y Cable Modem, así como también por redes Ethernet planas (plain networks). PPPoE es una extensión del estándar PPP. La diferencia entre ambos esta en el medio de transporte, ya que PPPoE utiliza Ethernet en lugar de conexiones de modem serial. Generalmente PPPoE se utiliza para manejar las direcciones IP a clientes basados en autenticación por nombre de usuario (incluso si se requiere también por estación de trabajo) en lugar de la autenticación únicamente por estación de trabajo donde se utiliza direccionamiento estático o DHCP. Se recomienda no utilizar direccionamiento estático o DHCP en las mismas interfaces como PPPoE por razones de seguridad. El cliente y server PPPoE trabajan sobre: • Cualquier interface Ethernet Capa 2 • Wireless 802.11 (Aironet, Cisco, WaveLan, Prism, Atheros) • Ethernet 10/100/1000 Mbit/s • RadioLan • EoIP (túnel Ethernet sobre IP) Características principales de PPPoE • Soporte para cliente y server PPPoE • Multilink PPP (MLPPP) • MLPPP sobre un enlace simple (habilidad para transmitir frames de tamaño completo) • Soporte para BCP (Bridge Control Protocol). Permite el envío de frames Ethernet sobre enlaces PPP • Encriptación MPPE 40bits • Encriptación MPPE 128 RSA • Autenticación pap, chap, mschap v1, mschap v2 • Soporte RADIUS para autenticación y contabilización de clientes Academy Xperts 63 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 6: Túneles Nótese que cuando el servidor RADIUS está autenticando un usuario con CHAP, MS-CAHPv1 o MS-CHAPv2, el protocolo RADIUS no usa una clave compartida (shared secret), ya que esta calve compartida se utiliza únicamente en la respuesta a la autenticación. Esto significa que si se tiene una clave compartida errónea, el servidor RADIUS aceptará el requerimiento. Se puede entonces utilizar el comando /radius monitor para visualizar el parámetro bad-replies. Este valor debería incrementar cada vez que un cliente intenta conectarse. Conexiones soportadas • El Cliente PPPoE MikroTik RouterOS se puede conectar con cualquier servidor PPPoE (concentrador de acceso) • El Servidor PPPoE MikroTik RouterOS (concentrador de acceso) se puede conectar con múltiples clientes PPPoE (los clientes pueden provenir de casi todos los sistemas operativos y la mayoría de routers) Operación PPPoE Estados PPPoE tiene 2 estados 1) Descubrimiento (Discovery) .- Un cliente descubre todos los concentradores de acceso disponible, y selecciona uno de ellos para establecer la sesión PPPoE. Este estado tiene cuatro pasos: a. Inicialización (initialization) b. Oferta (offer) c. Request (requerimiento) d. Confirmación de sesión (sesión confirmation) • PPPoE Discovery utiliza frames Ethernet especiales con su propio tipo de frame Ethernet (0x8863) • Para iniciar el descubrimiento, el cliente PPPoE envía un frame PADI a la dirección Ethernet broadcast FF:FF:FF:FF:FF:FF, y opcionalmente puede especificar un nombre de servicio (service name) • Cuando el server recibe el frame PADI, el server responde con un frame PADO a la dirección Ethernet unicast del Cliente. Puede haber más de un servidor en el rango broadcast del cliente. En tal caso el Cliente colecciona los frames PADO y elige uno para iniciar la sesión. En la mayoría de los casos elige el servidor que responde primero. • El Cliente envía un frame PADR a la dirección Ethernet unicast del Server que elige. Si el Server está de acuerdo en configurar una sesión con este Cliente, entonces asigna recursos para configurar una sesión PPP y asigna un número de Identificación de Sesión (Session ID). Este número se envía de retorno al Cliente en un frame PADS. Cuando el Cliente recibe el frame PADS, conoce la dirección MAC de los servidores y el Session ID, asigna los recursos y la sesión puede comenzar. 2) Sesión (Session) .- Cuando se completa el estado Discovery, ambas partes conocen el PPPoE Session ID y la dirección MAC Ethernet de cada uno, con lo cual juntos definen la sesión PPPoE. Los frames PPPoE son encapsulados en frames de sesión PPPoE, los mismos que tienen un tipo de frame Ethernet 0x8864 Cuando el Server envía la confirmación y el Cliente la recibe, se inicia el estado de Sesión PPP que consiste de los siguientes pasos: a. Negociación LCP b. Autenticación c. Negociación IPCP, donde se le asigna una dirección IP al Cliente El Server PPPoE envía paquetes Echo-Request al Cliente para determinar el estado de la sesión, de otra forma el Server no podrá determinar que la sesión está terminada en los casos en que el Cliente termina la sesión sin enviar el paquete Terminate-Request Tipos de paquetes utilizados PADI – PPPoE Active Discovery Initialization Academy Xperts 64 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 6: Túneles El Cliente PPPoE envía un paquete PADI a la dirección broadcast. Este paquete también puede poblar el campo service-name si un nombre de servicio ha sido ingresado en las propiedades de networking dial-up del cliente PPPoE. Si no se ha ingresado un service-name, este campo nos será poblado PADO – PPPoE Active Discovery Offer El Server PPPoE (Concentrador de Acceso) debe responder al PADI con un PADO si el Concentrador de Acceso está habilitado para servir el campo service-name que ha sido listada en el paquete PADI. Si ningún campo service-name ha sido listado, el Concentrador de Acceso responderá con un paquete PADO que tiene el campo service-name poblado con los nombres de servicio que el Concentrador de Acceso puede servir. El paquete PADO se envía a la dirección unicast del cliente PPPoE PADR – PPPoE Active Discovery Request Cuando se recibe un paquete PADO, el Cliente PPPoE responde con un paquete PADR. Este paquete se envía a la dirección unicast del Concentrador de Acceso. El cliente puede recibir múltiples paquetes PADO, pero el cliente responde al primer PADO válido que el cliente recibió. Si el paquete inicial PADI tiene un campo service-name en blanco, el cliente puebla el campo service-name del paquete PADR con el nombre del primer servicio que retorna en el paquete PADO. PADS – PPPoE Active Discovery Session confirmation Cuando se recibe el PADR, el Concentrador de Acceso genera una identificación de sesión única (ID) para la sesión PPP y regresa este ID al Cliente PPPoE en el paquete PADS. Este paquete es enviado a la dirección unicast del Cliente. PADT – PPPoE Active Discovery Terminate Puede ser enviado en cualquier momento después de que se establece una sesión para indicar una sesión PPPoE terminada. Puede ser enviada por el Server como por el Cliente. MTU Típicamente el frame Ethernet más grande que se puede transmitir sin fragmentación es 1500 bytes. El protocolo PPPoE agrega 6 bytes de overhead y el campo PPP agrega 2 bytes más, dejando 1492 bytes para el datagrama IP. Por lo tanto los valores máximos de MTU y MRU para PPPoE no deben ser mayores a 1492. Las pilas TCP tratan de evitar la fragmentación, por lo que usan un MSS (Maximum Segment Size). Por default el MSS es elegido como el MTU de la interface saliente menos el tamaño usual de las cabeceras IP y TCP (40 bytes), lo cual resulta en 1460 bytes para una interface Ethernet. Desafortunadamente puede haber enlaces intermedios con un MTU más bajo el cual puede ocasionar fragmentación. En tal caso, la pila TCP ejecuta un path MTU discovery. Los routers que no pueden pasar el datagrama sin fragmentación se supone que abandonarán/rechazarán (drop) el paquete y enviarán un mensaje ICMP-Fragmentation-Required al host origen. Cuando el host recibe este paquete ICMP, intenta disminuir el MTU. Esto debería funcionar en un esquema ideal, sin embargo en el mundo real muchos routers no generan los datagramas fragmentation-requiered, y también muchos firewalls abandonan/rechazan (drop) todos los datagramas ICMP. La solución para este problema es ajustar el MSS si es que es demasiado grande. Por default el RouterOS agrega reglas de mangle para interceptar los paquetes TCP SYN y silenciosamente ajusta cualquier opción MSS anunciando la que será apropiada para el enlace PPPoE. pppoe client (Cliente PPPoE) Propiedades • ac-name (string; Default: "") .- Nombre del Concentrador de Acceso. Este campo puede ser dejado en blanco y el cliente se conectará a cualquier Concentrador de Acceso en el dominio de broadcast. • add-default-route (yes|no; Default: no) .- Habilita/Deshabilita si es que se agregará automáticamente la ruta por default. • allow (mschap2 | mschap1 | chap | pap; Default: mschap2, mschap1, chap, pap) .- Especifica los métodos de autenticación permitidos. Por default todos los métodos están permitidos. • default-route-distance (byte [0..255]; Default: 1) .- Configura el valor de distancia aplicado para la ruta por default creada automáticamete, si es que también se ha seleccionado add-default-route • dial-on-demand (yes | no; Default: no) .- Se conecta al Concentrador de Acceso únicamente cuando se genera tráfico de salida. Si esta opción está seleccionada, entonces la ruta con la dirección del gateway desde la red 10.112.112.0/24 será agregada mientras la conexión no está establecida • interface (string; Default: ) .- Nombre de la interface en la cual correrá el cliente • keepalive-timeout (integer; Default: 60) .- Configura el keepalive timeout en segundos • max-mru (integer; Default: 1460) .- Unidad de Recepción Máxima (MRU = Maximum Receive Unit). • max-mtu (integer; Default: 1460) .- Unidad de Tránsmisión Máxima (MTU = Maximum Transmission Unit • mrru (disabled | integer 512..65535; Default: disabled) .- Máximo tamaño del paquete que puede ser recibido en el enlace. Si un paquete es más grande que el tunel MTU, será dividido en múltiples paquetes, permitiendo que el tamaño total de los paquetes IP o Ethernet sean enviados sobre el túnel • name (string; Default: ) .- Nombre de la interface PPPoE. Se genera automáticamente por el RouterOS si es que no se especifica. Academy Xperts 65 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 6: Túneles • password (string; Default: "") .- Contraseña (password) usado para la autenticación • profile (name; Default: default-encryption) .- Especifica el perfil por default para la conexión definida en /ppp profiles • service-name (string; Default: "") .- Especifica el nombre de servicio configurado en el Concentrador de Acceso. Puede ser dejado en blanco para conectarse a cualquier Server PPPoE • use-peer-dns (yes|no; Default: no) .- Habilita/Deshabilita la obtención de las configuraciones DNS desde su peer • user (string; Default: ) .- Nombre de usuario (user name) usado para la autenticación PPPoE service-name • El service-name puede ser visto como el SSID de 802.11, lo que significa que es el nombre de red que el cliente este buscando. • A diferencia del SSID, si el cliente no especifica uno, el concentrador de acceso (servidor PPPoE) enviara todos los service-names que administre. El cliente responderá al primero que llegue. Status El comando /inteface pppoe-client monitor mostrará el estatus PPPoE actual Propiedades • ac-mac (MAC address) .- La dirección MAC del Concentrador de Acceso al que el Cliente está conectado • ac-name (string) .- Nombre del Concentrador de Acceso • active-links (integer) .- Número de las conexiones MLPPP unidas (‘1’ si no se está usando MLPPP) • encoding (string) .- Encriptación y codificación (si es asimétrico, separado con ‘/’) que está siendo usado en esta conexión. • local-address (IP Address) .- Dirección IP asignada al cliente • remote-address (IP Address) .- Dirección IP remota asignada al Server (por ejemplo la dirección del Gateway) • mru (integer) .- MRU efectivo del enlace • mtu (integer) .- MTU efectivo del enlace • service-name (string) .- Nombre del servicio utilizado • status (string) .- Estatus actual del enlace. Los valores disponibles son: • dialing (marcando) • verifying password... (verificando contraseña) • connected (conectado) • disconnected (desconectado) • uptime (time) .- Tiempo de conexión mostrado en días, horas, minutos y segundos. Scanner A partir de la v3.21 RouterOS agregó la herramienta PPPoE Scanner. Esta herramienta permite escanear todos los servidores PPPoE activos en el dominio de broadcast. /interface pppoe-client scan <interface> Propiedades • service (string) .- Nombre del servicio configurado en el Server • mac-address (MAC) .- Dirección MAC del Server detectado • ac-name (string) .- Nombre del Concentrador de Acceso Notas importantes En Windows, algunas instrucciones de conexión pueden usar la forma donde el phone number, por ejemplo MikroTik_AC\mt1, se especifica para indicar que MikroTik_AC es el nombre del Concentrador de Acceso (AC), y mt1 es el nombre del servicio. La especificación del MRRU significa que se habilita MP (Multilink PPP) sobre un enlace simple. Este protocolo se utiliza para dividir los paquetes grandes en paquetes más pequeños. En Windows esto se puede habilitar en la pestaña Networking, botón Configuración, opción “Negociar multi-link para conexiones de enlace simple”. El MRRU en Windows está codificado en 1614. Esta configuración es útil para resolver fallas de PathMTU Discovery. La configuración MP debe estar habilitada en ambas partes. Configuración del Server PPPoE (Concentrador de Acceso) /interface pppoe-server server El Server PPPoE (Concentrador de Acceso) soporta múltiples servers para cada interface, con diferentes nombres de servicio (service-name). El Throughput del Server PPPoE ha sido probado a 160 Mbps en un CPU Celeron 600. El uso de CPUs de mayor velocidad debería incrementar proporcionalmente el Throughput. El nombre del Concentrador de Acceso y el nombre del servicio PPPoE son usados por los clientes para identificar el concentrador de acceso al cual se quieren registrar. El nombre del concentrador de acceso es el mismo que la identidad del router que se muestra antes del command prompt. La identidad se puede configurar en /system identity Academy Xperts 66 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 6: Túneles Es importante recordar que si no se especifica un nombre de servicio en Windows XP, únicamente usará un servicio sin nombre. Por lo tanto si se desea atender clientes Windows XP, se debe dejar el nombre de servicio vacío. Propiedades • authentication ( mschap2 | mschap1 | chap | pap; Default: "mschap2, mschap1, chap, pap") .- Algoritmo de autenticación. • default-profile (string; Default: "default") .- Perfil de usuario por default que se va a utilizar • interface (string; Default: "") .- Interface a la que los clientes se conectan • keepalive-timeout (time; Default: "10") .- Define el período de tiempo (en segundos) después del cual el router inicia el envío de paquetes keepalive cada segundo. Si es que no existe tráfico y no arriban respuestas keepalive en ese período de tiempo (por ejemplo, 2*keepallive-timeout), el cliente que no responde se proclama como desconectado. • max-mru (integer; Default: "1480") .- Maximum Receive Unit. El valor óptimo es el MTU de la interface en la que el túnel está trabajando, disminuido en 20. Por ejemplo, para un enlace Ethernet de 1500-bytes, se debe configurar el MTU en 1480 para evitar la fragmentación de paquetes. • max-mtu (integer; Default: "1480") .- Maximum Transmission Unit. El valor óptimo es el MTU de la interface en la que el túnel está trabajando, disminuido en 20. Por ejemplo, para un enlace Ethernet de 1500-bytes, se debe configurar el MTU en 1480 para evitar la fragmentación de paquetes. • max-sessions (integer; Default: "0") .- Número máximo de clientes que el Concentrador de Acceso puede atender. 0 (cero) significa que no hay limitantes. • mrru (integer: 512..65535 | disabled; Default: "disabled") .- Tamaño máximo del paquete que puede ser recibido en el enlace. Si un paquete es más grande que el túnel MTU, será divido en múltiples paquetes, permitiendo el tamaño completo de los paquetes IP o Ethernet que serán enviados a través del túnel. • one-session-per-host (yes | no; Default: "no") .- Se permite únicamente una sesión por host (determinado por la dirección MAC). Si un host intenta establecer una nueva sesión, la anterior será cerrada. • service-name (string; Default: "") .- El nombre de servicio PPPoE. El servidor aceptará clientes a los cuales envía el mensaje PADI con service-names que concuerden con esta configuración o si el campo de service-name en el mensaje PADI no está configurado. Notas importantes El valor por default de 10 segundos del parámetro keepalive-timeout es adecuado en la mayoría de los casos. Si se configura este parámetro como 0 (cero), el router no desconectará a los clientes hasta que ellos explícitamente hagan log- out o hasta que el router reinicie. Para resolver este problema, se puede utilizar la propiedad one-session-per-host. Como punto importante de seguridad recuerde que no debe asignar una dirección IP a la interface en la cual se recibirán los requerimientos PPPoE. La especificación del MRRU significa que se habilita MP (Multilink PPP) sobre un enlace simple. Este protocolo se utiliza para dividir los paquetes grandes en paquetes más pequeños. En Windows esto se puede habilitar en la pestaña Networking, botón Configuración, opción “Negociar multi-link para conexiones de enlace simple”. El MRRU en Windows está codificado en 1614. Esta configuración es útil para resolver fallas de PathMTU Discovery. La configuración MP debe estar habilitada en ambas partes. PPPoE Server (Servidor PPPoE) /interface pppoe-server Una interface se crea por cada túnel establecido al servidor dado. Las interfaces estáticas se agregan administrativamente si es que existe la necesidad de referenciar el nombre de la interface en particular (en reglas en firewall u otro lugar) creada para el usuario en particular. Se crea una interface por cada túnel establecido al servidor. Existen dos tipos de interfaces en la configuración PPTP Server • Las interfaces estáticas se agregan administrativamente si es que existe una necesidad para referenciar el nombre de interface en particular (por ejemplo en las reglas de firewall o en algún otro lugar) creada para un usuario en particular. • Las interfaces dinámicas son agregadas a esta lista automáticamente si es que un usuario está conectado y su nombre de usuario (username) no coincide con cualquier entrada estática existente (o en caso de que la entrada ya está activa, ya que no puede haber dos interfaces de túnel separadas referenciadas por el mismo nombre. Si existe problema se debe configurar el valor one-session-per-host. Las interfaces dinámicas aparecen cuando un usuario se conecta y desaparece una vez que el usuario se desconecta, por lo que es imposible hacer referencia al túnel creado con ese fin en la configuración del router (por ejemplo, en firewall), así que si se necesitan reglas persistentes para ese usuario, se debe crear una entrada estática para ese usuario. De lo contrario es seguro usar la configuración dinámica. Es importante notar que en ambos casos los usuarios PPP deben ser configurados apropiadamente. Las entradas estáticas no reemplazan la configuración PPP. Propiedades • encoding (read-only: text) .- Encriptación y codificación (si es asimétrico, separado con ‘/’) que está siendo usado en esta conexión. • mru (integer) .- MRU del cliente Academy Xperts 67 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 6: Túneles • mtu (integer) .- MTU del cliente • name (name) .- Nombre de la interface • remote-address (read only: MAC address) .- Dirección MAC del cliente conectado • service (string) .- Nombre del servicio al que el usuario está conectado • uptime (time) .- Tiempo que el cliente ha estado conectado • user (name) .- Nombre del usuario conectado (debe estar presente en la base de datos de usuario) Creando un PPPoE server • Un PPPoE server es el dispositivo que ofrece el servicio de tunelización • Permite a los clientes obtener un servicio de VPN seguro a la capa 3 a través de la infraestructura de la capa 2. • Usted no puede llegar a un servidor PPPoE a través de routers. Ya que es un protocolo de capa 2, el servidor solo se puede llegar a través del mismo dominio de difusión Ethernet a la que los clientes pertenecen. • Antes de crear el servidor, creamos los parámetros de configuración que usted requiere tales como: o IP Pool o PPP profiles • PPP secrets Crear la interfaz de servidor de la interfaz física frente a los clientes Ejemplo: /ip pool add name=Pool-PC ranges=192.168.5.50-192.168.5.99, 192.168.5.150-192.168.5.199 add name=Pool-VPN ranges=192.168.5.100-192.168.5.149 /ppp profile add change-tcp-mss=yes local-address=192.168.222.1 name=Profile-external \ remote-address=192.168.222.2 use-compression=yes use-encryption=yes \ use-vj-compression=no add change-tcp-mss=no dns-server=192.168.5.1 local-address=192.168.5.1\ name=Profile-internal remote-address=Pool-VPN use-compression=yes\ use-encryption=yes use-vj-compression=no /ppp secret add name=Pod4-external password=pod4-123 profile=Profile-external routes=192.168.4.0/24 add name=alain password=alain!! profile=Profile-internal /interface pppoe-server server add authentication=mschap2 default-profile=Profile-external disabled=no \ interface=ether1 mrru=1600 service-name=PPPoE-external add authentication=mschap2 default-profile=Profile-internal disabled=no \ interface=ether5 mrru=1600 service-name=PPPoE-internal Tip: Usted puede dejar un puerto Ethernet sin un puerto maestro, un bridge o una dirección IP y el cliente que está conectado a este puerto pueden conseguir todavía el acceso a Internet si el servidor PPPoE (y el cliente PPPoE) está configurado correctamente. Direcciones Point-to-Point • Direcciones desde /ppp secret tienen prioridad sobre /ppp profile, y ellos tienen prioridad sobre /ip pool. • Tanto las direcciones locales y remotas pueden ser únicas o de un Pool • Direcciones estáticas o direcciones por medio de DHCP no se deben utilizar en interfaces de clientes PPPoE. Creando Clientes PPPoE en un RouterOS • Si desea utilizar un perfil diferente que el de por defecto, crearlo primero. • Crear la interfaz de cliente en la interfaz de cara al ISP • Ya está! Ejemplo /ppp profile add change-tcp-mss=yes name=Profile-external use-compression=yes \ use-encryption=yes use-vj-compression=no /interface pppoe-client add ac-name=" " add-default-route=yes allow=mschap2 default-route-distance=1\ dial-on-demand=no disabled=no interface=ether1 keepalive-timeout=60 max-mru=1480 max-mtu=1480 mrru=disabled name=Client-PPPoE password=pod4-123 profile=Profile-external service-name=" " use- peer-dns=no user=Pod4-external Habilite la interfaz del cliente. Tip El router no tendría que ser configurado con un cliente DHCP en la interfaz WAN y esto aún funcionará si el servidor PPPoE está en la misma infraestructura de capa 2 como puerto WAN. PPTP PPTP es un túnel seguro para transportar tráfico IP usando PPP. PPTP encapsula PPP en líneas virtuales que corren sobre IP. PPTP incorpora PPP y MPPE (Microsoft Point to Point Encryption) para crear enlaces encriptados. Academy Xperts 68 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 6: Túneles El propósito de este protocolo es crear conexiones seguras entre routers y también entre routers y clientes PPTP. Los clientes PPTP están disponibles en casi todos los sistemas operativos, incluso en Windows. RouterOS soporta Multilink PPP (también conocido como MP, MLPPP, MPPP, MLP, o Multilink) con lo cual se provee un método para esparcir el tráfico a través de múltiples conexiones PPP distintas. En una simple línea PPP los frames no pueden arribar fuera de orden, pero esto se puede solucionar si los frames se los divide entre múltiples conexiones PPP. Por este motivo el MP debe numerar los fragmentos para que puedan ser reordenados cuando lleguen al destino. MP es un ejemplo de tecnología de agregación de enlace. MP (Multilink PPP) provee MRRU y capacidad de Bridging a través de enlaces PPP. • MRRU consiste en la habilidad de transmitir paquetes de tamaño 1500 y de mayor tamaño. o MRRU = Maximum Received Reconstructed Unit o El MRRU es similar al MTU (Maximum Transmission Unit), pero solo se aplica a los paquetes Multilink. o El MRRU es el máximo tamaño de paquete que una interface Multilink puede procesar. o Por default el MRRU es 1500 bytes, pero se puede configurar un diferente de MRRU si el equipo con el que va a conversar permite/acepta ese nuevo valor. • La capacidad de hacer Bridging se obtiene del uso de BCP (Bridge Control Protocol) que es el que permite enviar frames Ethernet a través de enlaces PPP. De esta forma es posible configurar un Bridge (usando PPTP) en lugar de utilizar EoIP. Para esto se necesita que el Bridge tenga una dirección MAC o una interface tipo Ethernet, ya que los enlaces PPP no tienen direcciones MAC. PPTP incluye contabilización (accounting) y autenticación (authentication) PPP para cada conexión PPTP. La autenticación y contabilización de cada conexión puede ser hecha a través de un cliente RADIUS o de forma local RouterOS soporta los tipos de encriptación • MPPE 40bit RC4 • MPPE 128bit RC4 El tráfico PPTP utiliza • TCP puerto 1723 • IP protocol GRE o GRE = Generic Routing Encapsulation o GRE = IP protocol ID 47 PPTP puede ser usado con la mayoría de firewalls y routers habilitando TCP 1723 y GRE (protocolo 47). De esta manera el tráfico puede ser ruteado a través del firewall o router. Las conexiones PPTP pueden resultar muy limitadas o incluso a veces hasta imposibles cuando se configura através de una conexión enmascarada (NATeada). PPTP es un protocolo de túnel que utiliza la información y direccionamiento del enrutamiento IP, para ligar a los clientes a los servidores PPTP. • La definición del servidor PPTP es casi lo mismo que para PPPoE, excepto que ninguna interfaz tiene que ser especificada. • El cliente se define casi de la misma manera como un cliente PPPoE, excepto que una dirección IP tiene que ser especificada para el servidor. Consejo: Se debe desbloquear el puerto 1723 en el firewall del router (el servidor PPTP) para que pueda llegar con su tunel. Es un túnel seguro para el transporte de trafico IP mediante PPP. La encapsulación de PPTP en líneas virtuales que corren sobre IP. PPTP incorpora PPP y MPPE (Microsoft Point-to-Point Encryption) para hacer enlaces cifrados. El objetivo de este protocolo es hacer conexiones seguras bien administradas entre los routers, así como entre los router clientes PPTP. Clientes están disponibles para y/o incluido en casi todos los sistemas operativos incluyendo Windows). Se crea una interfaz para cada túnel establecido con el servidor dado. Hay dos tipos de interfaces en la configuración de PPTP. • Las interfaces estáticas se añaden administrativamente si hay una necesidad de hacer referencia al nombre de la interfaz en particular (en las reglas de firewall) creados por el usuario en particular. • Las interfaces dinámicas se añaden a esta lista de forma automática cada vez que se conecta un usuario y su nombre de usuario no coincide con ninguna entrada estática existente. Interfaces dinámicas aparecen cuando un usuario se conecta y desaparecen una vez que el usuario se desconecta, por lo que es imposible hacer referencia al túnel creado con ese fin en la configuración del router (por ejemplo, en el servidor de seguridad), así que si necesitas reglas persistentes para ese usuario, crear una entrada estática para el usuario, de lo contrario es seguro usar configuración dinámica. El siguiente ejemplo muestra como conectar un ordenar a un red de oficina remota a través de una túnel PPTP encriptado, dando ese equipo una dirección IP de la misma red que la oficina remota tiene (sin necesidad de tender un bridge sobre túneles EoIP) Academy Xperts 69 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 6: Túneles El router de la oficina está conectado a internet a través de ether1. Las estaciones de trabajo están conectados a ether2. Las portátiles están conectadas a internet, y puede alcanzar IP publica del router de la oficina (en nuestro ejemplo es 192.168.80.1) Primer paso es crear un usuario /ppp secret add name=Laptop service=pptp password=123 local-address=10.1.101.1\ remote-address=10.1.101.100 /ppp secret print detail Flags: X – disabled 0 name=”Laptop” service=pptp caller-id=” ” password=”123” profile=default local-address=10.1.101.1 remote-address=10.1.101.100 routes==” “ Observe que la dirección local PPTP es la misma que la dirección del router en la interfaz local y la dirección remota es del mismo rango que la red local (10.1.101.0/24). El siguiente paso es habilitar el servidor PPTP y el cliente PPTP en la computadora portátil. /interface pptp-server server set enabled=yes /interface pptp-server server print Enabled: yes max-mtu: 1460 max-mru: 1460 mrru: disabled authentication: mschap2 keepalive-timeout: 30 default-profiles: default El cliente PPTP de la computadora portátil debe conectarse a routers IP publica que en nuestro ejemplo es 192.168.80.1 (consulte el manual respectivo sobre como configurar un cliente PPTP con el software del sistema operativo que esté utilizando). En este punto (cuando el cliente PPTP está conectado con éxito) si intenta hacer ping a cualquier estación de trabajo que forma parte de la red del ordenador portátil, el ping será el tiempo de espera debido a que el ordenador portátil está en condiciones de obtener aplicaciones de estaciones de trabajo. La solución es la creación de proxy arp en la interfaz local. /interface ethernet set Office arp=proxy-arp /interface ethernet print Flags: X – disabled, R – running # Name MTU MAC-ADDRESS ARP 0 R ether1 1500 00:30:4F:0B:7B:C1 enabled 1 R ether2 1500 00:30:4F:06:62:12 proxy-arp Luego que el proxy-arp este activado, el cliente remoto puede alcanzar con éxito todas las estaciones de trabajo en la red local detrás del router. PPTP Client (cliente pptp) • add-default-route (yes | no; Default: no) .- Especifica si es que se agrega una dirección remota PPTP como una ruta por default • allow (mschap2 | mschap1 | chap | pap; Default: mschap2, mschap1, chap, pap) .- Especifica los métodos de autenticación permitidos • connect-to (IP; Default: ) .- Dirección remota del servidor PPTP • default-route-distance (byte [0..255]; Default: 1) .- Configura el valor de distancia aplicado para la ruta por default creada automáticamete, si es que también se ha seleccionado add-default-route • dial-on-demand (yes | no; Default: no) .- Se conecta al servidor PPTP únicamente cuando se genera tráfico de salida. Si esta opción está seleccionada, entonces la ruta con la dirección del gateway desde la red 10.112.112.0/24 será agregada mientras la conexión no está establecida Academy Xperts 70 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 6: Túneles • disabled (yes | no; Default: yes) .- Especifica si la interface está deshabilitada o no. Por default está deshabilitada. • keepalive-timeout (integer; Default: 60) .- Configura el keepalive timeout en segundos • max-mru (integer; Default: 1460) .- Unidad de Recepción Máxima (MRU = Maximum Receive Unit). Tamaño máximo del paquete que la interface PPTP estará habilitada para recibir sin fragmentación de paquetes • max-mtu (integer; Default: 1460) .- Unidad de Tránsmisión Máxima (MTU = Maximum Transmission Unit). Tamaño máximo del paquete que la interface PPTP estará habilitada para enviar sin fragmentación de paquetes • mrru (disabled | integer; Default: disabled) .- Máximo tamaño del paquete que puede ser recibido en el enlace. Si un paquete es más grande que el tunel MTU, será dividido en múltiples paquetes, permitiendo que el tamaño total de los paquetes IP o Ethernet sean enviados sobre el túnel • name (string; Default: ) .- Nombre descriptivo de la interface • password (string; Default: "") .- Contraseña (password) usado para la autenticación • profile (name; Default: default-encryption) .- Especifica el perfil PPP que se usa • user (string; Default: ) .- Nombre de usuario (user name) usado para la autenticación PPTP Server (servidor pptp) Se crea una interface por cada túnel establecido al servidor. Existen dos tipos de interfaces en la configuración PPTP Server • Las interfaces estáticas son administrativamente agregadas si es que existe una necesidad para referenciar el nombre de interface en particular (por ejemplo en las reglas de firewall o en algún otro lugar) creada para un usuario en particular. • Las interfaces dinámicas son agregadas a esta lista automáticamente si es que un usuario está conectado y su nombre de usuario (username) no coincide con cualquier entrada estática existente (o en caso de que la entrada ya está activa, ya que no puede haber dos interfaces de túnel separadas referenciadas por el mismo nombre) Las interfaces dinámicas aparecen cuando un usuario se conecta y desaparece una vez que el usuario se desconecta, por lo que es imposible hacer referencia al túnel creado con ese fin en la configuración del router (por ejemplo, en firewall), así que si se necesitan reglas persistentes para ese usuario, se debe crear una entrada estática para ese usuario. De lo contrario es seguro usar la configuración dinámica. Nota Importante En ambos casos los usuarios PPP deben ser configurados apropiadamente, las entradas estáticas no reemplazan la configuración PPP Parámetros • authentication (pap | chap | mschap1 | mschap2; Default: mschap1,mschap2) .- Especifica los métodos de autenticación que el servidor aceptará • default-profile (name; Default: default-encryption) .- Perfil PPP por default que se usará • enabled (yes | no; Default: no) .- Define si es que el servidor PPTP está habilitado o no • keepalive-timeout (time; Default: 30) .- Si el servidor durante el período keepalive no recibe ningún paquete, se enviará paquetes keepalive cada segundo por cinco veces. Si el server no recibe respuesta del cliente, entonces se desconecta después de 5 segundos. La bitácora de eventos (LOG) mostrará 5 veces los mensajes “LCP missed echo reply” y luego se desconectará. • max-mru (integer; Default: 1460) .- Unidad de Recepción Máxima (MRU = Maximum Receive Unit). Tamaño máximo del paquete que la interface PPTP estará habilitada para recibir sin fragmentación de paquetes • max-mtu (integer; Default: 1460) .- Unidad de Tránsmisión Máxima (MTU = Maximum Transmission Unit). Tamaño máximo del paquete que la interface PPTP estará habilitada para enviar sin fragmentación de paquetes • mrru (disabled | integer; Default: disabled) .- Máximo tamaño del paquete que puede ser recibido en el enlace. Si un paquete es más grande que el tunel MTU, será dividido en múltiples paquetes, permitiendo que el tamaño total de los paquetes IP o Ethernet sean enviados sobre el túnel L2TP L2TP es un protocolo de túnel seguro para transportar tráfico IP usando PPP. L2TP encapsula PPP en líneas virtuales que corren sobre IP, frame Relay y otros protocolos (que no son soportados actualmente por MikroTik RouterOS) L2TP incorpora PPP y MPPE (Microsoft Point to Point Encryption) para crear enlaces encriptados. El propósito de este protocolo es permitir que los extremos PPP y Capa 2 residan en diferentes dispositivos interconectados por una red conmutada de paquetes (packet-switched network) Con L2TP, un usuario tiene una conexión en Capa 2 a un concentrador de acceso – LAC (ejemplo: manco de módems, ADSL DSLAM, etc.), y el concentrador entonces hace túneles de frames PPP individuales al Servidor de Acceso de Red (NAS = Network Access Server). Esto permite que el procesamiento real de paquetes PPP sea separado de la terminación del circuito de Capa 2. Desde la perspectiva del usuario, no existe diferencia funcional entre tener que el circuito en Capa 2 termine en un NAS directamente o usando L2TP. Puede ser útil usar L2TP únicamente como cualquier otro protocolo de túnel con o sin encriptación. El estándar L2TP establece que la forma más segura de encriptar datos es usar L2TP sobre IPsec (este es el modo por default para cliente Academy Xperts 71 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 6: Túneles Microsoft L2TP) ya que todos los paquetes de control y datos de L2TP de un túnel aparecen como paquetes de datos UDP/IP homogéneos para el sistema IPsec. Se soporta Multilink PPP (MP) para poder proveer MRRU (la habilidad para transmitir paquetes de 1500 y más grandes) y Bridging sobre enlaces PPP (usando BCP=Bridge Control Protocol, el cual permite enviar frames Ethernet sobre enlaces PPP). De esta forma es posible configurar Bridging sin EoIP. El bridge debería tener ya sea una dirección MAC administrativa o una interface tipo Ethernet, ya que los enlaces PPP no tienen direcciones MAC. L2TP incluye autenticación (authentication) y contabilización (accounting) PPP para cada conexión L2TP. Una completa autenticación y contabilización de cada conexión puede ser realizada a través de un cliente RADIUS o localmente. Métodos de encriptación soportados • MPPE 40bit RC4 • MPPE 128bit RC4 El protocolo L2TP utiliza el protocolo UDP para los paquetes de control y de datos. El puerto UDP 1701 se utiliza únicamente para establecer el enlace, el tráfico adicional puede utilizar cualquier puerto UDP (que puede o no ser el 1701). Esto significa que L2TP puede ser usado con la mayoría de firewalls y routers (incluso con NAT) tan solo habilitando que el tráfico UDP sea ruteado a través del firewall o del router. L2TP Client (cliente l2tp) • add-default-route (yes | no; Default: no) .- Especifica si es que se agrega una dirección remota L2TP como una ruta por default • allow (mschap2 | mschap1 | chap | pap; Default: mschap2, mschap1, chap, pap) .- Especifica los métodos de autenticación permitidos • connect-to (IP; Default: ) .- Dirección remota del servidor L2TP • coment (string; Default: ) .- Breve descripción del túnel • default-route-distance (byte; Default:) .- Desde la v6.2 se configura el valor de distancia aplicado para la ruta por default creada automáticamete, si es que también se ha seleccionado add-default-route • dial-on-demand (yes | no; Default: no) .- Se conecta únicamente cuando se genera tráfico de salida. Si esta opción está seleccionada, entonces la ruta con la dirección del gateway desde la red 10.112.112.0/24 será agregada mientras la conexión no está establecida • disabled (yes | no; Default: yes) .- Especifica si la interface está deshabilitada o no. Por default está deshabilitada. • keepalive-timeout (integer [1..4294967295]; Default: 60s) .- Desde l av6.0rc13, el keepalive timeout en segundos • max-mru (integer; Default: 1460) .- Unidad de Recepción Máxima (MRU = Maximum Receive Unit). Tamaño máximo del paquete que la interface L2TP estará habilitada para recibir sin fragmentación de paquetes • max-mtu (integer; Default: 1460) .- Unidad de Tránsmisión Máxima (MTU = Maximum Transmission Unit). Tamaño máximo del paquete que la interface L2TP estará habilitada para enviar sin fragmentación de paquetes • mrru (disabled | integer; Default: disabled) .- Máximo tamaño del paquete que puede ser recibido en el enlace. Si un paquete es más grande que el tunel MTU, será dividido en múltiples paquetes, permitiendo que el tamaño total de los paquetes IP o Ethernet sean enviados sobre el túnel • name (string; Default: ) .- Nombre descriptivo de la interface • password (string; Default: "") .- Contraseña (password) usado para la autenticación • profile (name; Default: default-encryption) .- Especifica el perfil PPP que se usa • user (string; Default: ) .- Nombre de usuario (user name) usado para la autenticación L2TP Server (servidor l2tp) Se crea una interface por cada túnel establecido al servidor. Existen dos tipos de interfaces en la configuración L2TP Server • Las interfaces estáticas son agregadas administrativamente si es que existe una necesidad para referenciar el nombre de interface en particular (por ejemplo en las reglas de firewall o en algún otro lugar) creada para un usuario en particular. • Las interfaces dinámicas son agregadas a esta lista automáticamente si es que un usuario está conectado y su nombre de usuario (username) no coincide con cualquier entrada estática existente (o en caso de que la entrada ya está activa, ya que no puede haber dos interfaces de túnel separadas referenciadas por el mismo nombre) Las interfaces dinámicas aparecen cuando un usuario se conecta y desaparece una vez que el usuario se desconecta, por lo que es imposible hacer referencia al túnel creado con ese fin en la configuración del router (por ejemplo, en firewall), así que si se necesitan reglas persistentes para ese usuario, se debe crear una entrada estática para ese usuario. De lo contrario es seguro usar la configuración dinámica. Nota Importante En ambos casos los usuarios PPP deben ser configurados apropiadamente, las entradas estáticas no reemplazan la configuración PPP Parámetros • authentication (pap | chap | mschap1 | mschap2; Default: mschap1,mschap2) .- Especifica los métodos de autenticación que el servidor aceptará Academy Xperts 72 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 6: Túneles • default-profile (name; Default: default-encryption) .- Perfil PPP por default que se usará • enabled (yes | no; Default: no) .- Define si es que el servidor L2TP está habilitado o no • keepalive-timeout (time; Default: 30) .- Si el servidor durante el período keepalive-timeout no recibe ningún paquete, se enviará paquetes keepalive cada segundo, por cinco veces. Si el server no recibe respuesta del cliente, entonces se desconecta después de 5 segundos. La bitácora de eventos (LOG) mostrará 5 veces los mensajes “LCP missed echo reply” y luego se desconectará. Este parámetro está disponible a partir de las versiones v5.22 y v6rc3 • max-mru (integer; Default: 1460) .- Unidad de Recepción Máxima (MRU = Maximum Receive Unit). Tamaño máximo del paquete que la interface L2TP estará habilitada para recibir sin fragmentación de paquetes • max-mtu (integer; Default: 1460) .- Unidad de Tránsmisión Máxima (MTU = Maximum Transmission Unit). Tamaño máximo del paquete que la interface L2TP estará habilitada para enviar sin fragmentación de paquetes • mrru (disabled | integer; Default: disabled) .- Máximo tamaño del paquete que puede ser recibido en el enlace. Si un paquete es más grande que el tunel MTU, será dividido en múltiples paquetes, permitiendo que el tamaño total de los paquetes IP o Ethernet sean enviados sobre el túnel Clientes y servidores SSTP VPN SSTP es un tipo de VPN de acceso remoto que permite una conexión VPN por SSL de HTTPS, o lo que es lo mismo encapsula trafico PPP sobre un canal SSL. Esto le permite atravesar Firewalls donde las conexiones VPN por PPTP o L2TP estén prohibidas. SSTP utilizara el puerto 443 para atravesar los firewalls y a través de SSL tenemos cifrado, autenticación y negociación de claves. • Definición del servidor SSTP es casi lo mismo que para PPTP, salvo que se especifique un puerto TCP para conectarse (443 por defecto). • Se usa con certificados digitales para crear Túneles sobre internet. • El cliente se define casi la misma forma que un cliente PPTP, salvo que se especifique un puerto TCP a utilizar para establecer una conexión (443 por defecto). • Consejo: Debe permitir el puerto 443 para que su túnel pueda llegar sin problemas. Además, dejar el puerto en 443 para asegurarlo con SSL y poderlo utilizar para sus comunicaciones. Configuración en línea de comando: /interface sstp-server server set authentication=mschap2 enabled=yes /interface sstp-client add add-default-route=no authentication=mschap2 certificate=none connect-to=\ 192.168.0.5:443 dial-on-demand=no disabled=no http-proxy=0.0.0.0:443 \ keepalive-timeout=60 max-mru=1500 max-mtu=1500 mrru=1600 name=Client-SSTP \ password=pod4-123 profile=Profile-external user=Pod4-external \ verify-server-address-from-certificate=no verify-server-certificate=n Clientes y Servidores OpenVPN Es una solución de conectividad basada en software libre: SSL (Secure Sockets Layer) VPN Virtual Private Network (red virtual privada), OpenVPN ofrece conectividad punto-a-punto con validación jerárquica de usuarios y host conectados remotamente. • Sigue el mismo patrón de configuraciones anteriores, similar a SSTP. • Con la única diferencia, que con esta herramienta (OPVN) nos permites crear nuestros propios certificados digitales públicos, para poder usarlos, sin tener que pagar por ellos. • Una muy buena herramienta a la hora de pensar en el factor COSTO. Academy Xperts 73 RouterOS v6.36.0.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 6: Túneles Configuración de Rutas entre redes Es necesaria la configuración de rutas estáticas para que exista comunicación, tomar en cuenta: • Una vez que el túnel está configurado y operativo, usted necesita rutas para mover los paquetes de un lado a otro. • La primera forma, es usar la ruta que se crea automáticamente en el router del cliente para ese túnel. /ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADS 0.0.0.0/0 192.168.0.254 0 1 ADC 192.168.0.0/24 192.168.0.5 ether1 0 2 ADC 192.168.5.0/24 192.168.5.1 Bridge-PC 0 3 ADC 192.168.5.101/32 192.168.5.1 <pptp-ejemplo> 0 • La segunda opción es especificar una o múltiples rutas con PPP secret para cada cliente: /ppp secret export add name=Pod4-external password=pod4-123 profile=Profile-external \ routes=192.168.4.0/24 add name=alain password=alain!! profile=Profile-internal /ppp secret print Flags: X - disabled # NAME SERVICE CALLER-ID PASSWORD PROFILE REMOTE-ADDRESS 0 Pod4-external any pod4-123 Profile-external 1 alain any alain!! Profile-internal /ppp secret set 0 routes=192.168.4.0/24,10.10.2.0/24 /ppp secret export add name=Pod4-external password=pod4-123 profile=Profile-external \ routes=192.168.4.0/24,10.10.2.0/24 add name=alain password=alain!! profile=Profile-internal • La tercera forma es agregar rutas estáticas a una o varias redes a través de un túnel. • Este método es útil si ambos routers tienen su propia ruta por defecto, pero implica más mantenimiento y parámetros. /ip route add comment="TO OFFICE LOOPBACKS" distance=1 dst-address=10.10.2.0/24 \ gateway=192.168.254.10 add comment="TO OFFICE NETWORKS" distance=1 dst-address=172.16.8.0/21 \ gateway=192.168.254.10 Preguntas de repaso del Módulo 6 1. Qué protocolos pueden ser tunelizados? 2. Qué es el SECRET y qué es el PROFILE? 3. Cuál es la principal característica del túnel PPPoE? 4. Cuál es el puerto y el protocolo que se debe tener en cuenta para habilitar una regla en Firewall para permitir túneles PPTP? Academy Xperts 74 RouterOS v6.35.2.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 7: Laboratorio Detallado de Túneles 7 – Repaso Laboratorios Detallados Túneles Objetivos y Conceptos previos a túneles IPIP Objetivos: • Entender cuál es el objetivo de los túneles y cómo configurarlos. • En este ejercicio se realizará un túnel IP-IP que es uno de lo túneles más básicos. Bases Conceptuales: Es importante entender por qué realizamos un túnel y los elementos que formarán parte de esta importante herramienta que permitirá interconectar a dos redes remotas separadas por la nube de Internet. Si se desea tener comunicación entre las redes A y B (Figura 8.1.1) que están separadas por la nube de Internet, la opción de ruteo no es viable ya que las IPs privadas 172.16.1.0/24 y 192.168.1.0/24 no son direcciones IP públicamente ruteables. Esto significa que los routers públicos en Internet no pueden usar las IPs privadas como una red de destino (a menos que sea para uso exclusivo & privado de cada ISP). Por esta razón, si se desea que las redes A y B se comuniquen, se debe crear una VPN • VPN = Virtual Private Network • En Español = Red Privada Virtual • También se la conoce como = Túnel Esto se realiza creando una Interface Virtual en cada router remoto. Una vez creada esta interface, dependiendo de la naturaleza de la misma, se podrán establecer conexiones en Capa 2 (L2) o en Capa 3 (L3). Recuerde que las siguientes redes son Redes Privadas y NO son Públicamente Ruteables • 10.0.0.0 /8 • 172.16.0.0 /12 • 192.168.0.0 /16 Existen diferentes tipos de túneles que se usan para diferentes aplicaciones. RouterOS de MikroTik permite trabajar con túneles • IPIP • EoIP • GRE • PPP (PPP, L2TP, PPTP, EoIP, OVPN SSTP) • IPsec Academy Xperts 75 RouterOS v6.35.2.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 7: Laboratorio Detallado de Túneles Para efectos de nuestros laboratorios debe quedar muy claro que cuando levantamos un túnel a través de Internet nos encontramos ante una nube de la cual prácticamente desconocemos todo lo que ocurre dentro (Figura 8.1.2). Los ejercicios que desarrollaremos serán una simulación del escenario en la red pública para lo cual trabajaremos con el router del Trainer como medio de acceso a la nube (Figura 8.1.3) En este escenario cada estudiante trabajará con las IPs privadas (192.168.n.0/24) y las IP externas (10.1.1.m/30) asignadas al inicio del curso Academy Xperts 76 RouterOS v6.35.2.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 7: Laboratorio Detallado de Túneles Nota Importante: Recordar que cuando se va a crear un túnel, la única información que posee cada localidad es la IP externa de los routers de borde de cada destino remoto (Figura 8.1.4) Proceso Túnel IPIP Como denota el nombre de este túnel (IPIP), se creará un túnel Capa 3 (IP) sobre una conexión Capa 3 (IP). Este tipo de túnel es muy básico y no posee autenticación ni encriptación. Para el ejemplo en este texto usaremos las siguientes interfaces y direcciones IP (Figura 8.1.5) R1 (Router 1) 192.168.a.0/24 ID de red de LAN en Red A 192.168.a.1 IP de la Laptop en Red A 192.168.a.254 IP de interface LAN en R1 (ether2 en este LAB) 10.1.1.w/30 IP de interface WAN en R1 (wlan1 en este LAB) 10.1.1.x/30 IP de interface WAN en R-trainer (wlan1 en este LAB) R2 (Router 2) 192.168.b.0/24 ID de red de LAN en Red B 192.168.b.1 IP de la Laptop en Red B 192.168.b.254 IP de interface LAN en R2 (ether2 en este LAB) 10.1.1.z/30 IP de interface WAN en R2 (wlan1 en este LAB) 10.1.1.y/30 IP de interface WAN en R-trainer (wlan1 en este LAB) Nota Importante: Para las configuraciones en este laboratorio asumiremos los siguientes valores para a, b, w, x, y & z. Estos valores fueron asignados previamente por el instructor al inicio del curso. Si tiene dudas por favor consulte su entrenador. • a=1 (192.168.1.0/24) • b=2 (192.168.2.0/24) • w=2 (10.1.1.2/30) • x=1 (10.1.1.1/30) • y=5 (10.1.1.5/30) • z=6 (10.1.1.6/30) Academy Xperts 77 RouterOS v6.35.2.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 7: Laboratorio Detallado de Túneles Laboratorio 7.1 – Túnel IP-IP Los pasos a seguir en este ejercicio son los siguientes: Paso 1 R1 (Router 1) debe configurar las direcciones IP local (externa) y remota (externa) para armar el túnel. Recuerde que: • local-address se refiere la IP externa local (R1) • remote-address se refiere a la IP externa remota (R2) /interface ipip add name=ipip-tunnel1 local-address=10.1.1.2 remote-address=10.1.1.6 R2 (Router 2) debe configurar las direcciones IP local (externa) y remota (externa) para armar el túnel. Recuerde que: • local-address se refiere la IP externa local (R2) • remote-address se refiere a la IP externa remota (R1) /interface ipip add name=ipip-tunnel1 local-address=10.1.1.6 remote-address=10.1.1.2 Paso 2 R1 (Router 1) debe asignar una dirección IP a la interface ipip-tunnel1 recién generada /ip address add address=10.20.30.1/30 interface=ipip-tunnel1 R2 (Router 2) debe asignar una dirección IP a la interface ipip-tunnel1 recién generada /ip address add address=10.20.30.2/30 interface=ipip-tunnel1 Paso 3 R1 (Router 1) debe verificar que llega a la IP del tunel remoto ejecutando un ping /ping 10.20.30.2 SEQ HOST SIZE TTL TIME STATUS 0 10.20.30.2 56 64 3ms 1 10.20.30.2 56 64 3ms 2 10.20.30.2 56 64 0ms 3 10.20.30.2 56 64 14ms R2 (Router 2) debe verificar que llega a la IP del tunel remoto ejecutando un ping / ping 10.20.30.1 SEQ HOST SIZE TTL TIME STATUS 0 10.20.30.1 56 64 3ms 1 10.20.30.1 56 64 1ms 2 10.20.30.1 56 64 1ms 3 10.20.30.1 56 64 1ms Academy Xperts 78 RouterOS v6.35.2.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 7: Laboratorio Detallado de Túneles Paso 4 R1 (Router 1) debe crear una entrada en la tabla de rutas para llegar a la red remota (192.168.2.0/24) especificando como Gateway la dirección IP de la inteface del túnel IPIP remota /ip route add dst-address=192.168.2.0/24 gateway=10.20.30.2 R2 (Router 2) debe crear una entrada en la tabla de rutas para llegar a la red remota (192.168.1.0/24) especificando como Gateway la dirección IP de la inteface del túnel IPIP remota /ip route add dst-address=192.168.1.0/24 gateway=10.20.30.1 Paso 5 R1 (Router 1) debe verificar que llega a la IP de la interface LAN remota ejecutando un ping /ping 192.168.2.254 R2 (Router 2) debe verificar que llega a la IP de la interface LAN remota ejecutando un ping /ping 192.168.1.254 Finalmente la interconexión entre las Redes remotas A & B queda según la Figura 8.1.6 Academy Xperts 79 RouterOS v6.35.2.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 7: Laboratorio Detallado de Túneles Laboratorio 7.2 – Túnel EoIP Objetivos: • Crear un túnel EoIP y verificar que las redes remotas se encuentran en el mismo dominio de broadcast Bases Conceptuales: El túnel Ethernet Sobre IP (Ether Over IP) es un túnel de Capa 2 (Ethernet) sobre una conexión en Capa 3 (IP). Esto significa que genera una dirección MAC en la interface del túnel. Al final de este laboratorio se comprobará que efectivamente se genera un túnel de Capa 2 (Ethernet) porque se podrá agregar la interface EoIP en un Bridge. De esta manera las redes remostas A y B estarán en el mismo dominio de broadcast, y puesto que formarán parte del mismo Bridge también estarán dentro del mismo dominio de Colisión. Esta última característica (formar parte del mismo dominio de Colisión) es la razón por la cual los Bridges o las redes Bridge deben ser evitadas al máximo. Una de las formas de constatar que ambas redes están trabajando en el mismo dominio de Broadcast es que las direcciones IP de las laptops estén en la misma subred. Otra forma de verificar es que a pesar de que ambas laptops tengan direcciones IP de distintas subredes, al ejecutar el Winbox podrán ver las direcciones MAC de los routers remotos. Esto no podría ser posible si es que ambas redes no compartieran el mismo dominio de Broadcast. El diagrama inicial de configuración es el que se presenta en la Figura 8.2.1 Los pasos a seguir en este ejercicio son los siguientes: Paso 1 R1 (Router 1) debe remover la ruta creada en el Laboratorio 8.1 (dst-address=192.168.2.0/24 gateway=10.20.30.2) R2 (Router 2) debe remover la ruta creada en el Laboratorio 8.1 (dst-address=192.168.1.0/24 gateway=10.20.30.1) • Este paso es necesario para que no haya inconvenientes con el direccionamiento de las redes • No es necesario que los Routers desactiven/eliminen los túneles IPIP Paso 2 R1 (Router 1) debe configurar la dirección IP remota (externa) para armar el túnel. Para este tipo de túnel (EoIP) no es obligatorio configurar la dirección IP local (externa). Sin embargo se debe configurar el tunnel-id que debe ser el mismo en los routers que arman el túnel. Recuerde que: • local-address se refiere la IP externa local (R1) • remote-address se refiere a la IP externa remota (R2) /interface eoip add name=eoip-tunnel1 remote-address=10.1.1.2 tunnel-id=10 Academy Xperts 80 RouterOS v6.35.2.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 7: Laboratorio Detallado de Túneles R2 (Router 2) debe configurar la dirección IP remota (externa) para armar el túnel. Recuerde que: • local-address se refiere la IP externa local (R2) • remote-address se refiere a la IP externa remota (R1) /interface eoip add name=eoip-tunnel1 remote-address=10.1.1.1 tunnel-id=10 Paso 3 R1 (Router 1) debe crear un Bridge, y en este bridge agregar las interfaces ether2 y eoip-tunnel1 /interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether2 /interface bridge port add bridge=bridge1 interface=eoip-tunnel1 R2 (Router 2) debe crear un Bridge, y en este bridge agregar las interfaces ether2 y eoip-tunnel1 /interface bridge add name=bridge1 /interface bridge port add bridge=bridge1 interface=ether2 /interface bridge port add bridge=bridge1 interface=eoip-tunnel1 Paso 4 Las laptops de las Redes A y B deben configurar una IP de la misma subred. Por ejemplo: Laptop Red A: 192.168.1.1/24 Laptop Red B: 192.168.1.2/24 Con esta configuración ambas laptops debe poder hacer PING entre ellos. Figura 8.2.2 Note que la Laptop de la Red B (192.168.1.2) no podrá hacer PING a R2 (Router 2) ya que están en una subred diferente. Academy Xperts 81 RouterOS v6.35.2.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 7: Laboratorio Detallado de Túneles Academy Xperts 82 RouterOS v6.35.2.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 7: Laboratorio Detallado de Túneles Objetivos y Conceptos previos a túneles PPTP Objetivos: • Crear un túnel PPTP, para lo cual se requerirá que R1 actúe como PPTP-Server y R2 actúe como PPTP-Client Bases Conceptuales: • PPTP es un túnel seguro para transportar tráfico IP usando PPP. • PPTP encapsula el PPP en líneas virtuales que corren sobre IP. • PPTP incorpora PPP y MPPE (Microsoft Point to Point Encryption) para crear enlaces encriptados. El propósito de este protocolo es crear conexiones seguras entre routers y también entre routers y clientes PPTP. Los clientes PPTP están disponibles en casi todos los sistemas operativos, incluso en Windows. RouterOS soporta Multilink PPP (también conocido como MP, MLPPP, MPPP, MLP, o Multilink) con lo cual se provee un método para esparcir el tráfico a través de múltiples conexiones PPP distintas. En una simple línea PPP los frames no pueden arrivar fuera de orden, pero esto se puede solucionar si los frames se los divide entre múltiples conexiones PPP. Por este motivo el MP debe numerar los fragmentos para que puedan ser reordenados cuando lleguen al destino. MP es un ejemplo de tecnología de agregación de enlace. MP (Multilink PPP) provee MRRU y capacidad de Bridging a través de enlaces PPP. • MRRU consiste en la habilidad de transmitir paquetes de tamaño 1500 y de mayor tamaño. o MRRU = Maximum Received Reconstructed Unit o El MRRU es similar al MTU (Maximum Transmission Unit), pero solo se aplica a los paquetes Multilink. o El MRRU es el máximo tamaño de paquete que una interface Multilink puede procesar. o Por default el MRRU es 1500 bytes, pero se puede configurar un diferente de MRRU si el equipo con el que va a conversar permite/acepta ese nuevo valor. • La capacidad de hacer Bridging se obtiene del uso de BCP (Bridge Control Protocol) que es el que permite enviar frames Ethernet a través de enlaces PPP. De esta forma es posible configurar un Bridge (usando PPTP) en lugar de utilizar EoIP. Para esto se necesita que el Bridge tenga una dirección MAC o una interface tipo Ethernet, ya que los enlaces PPP no tienen direcciones MAC. PPTP incluye contabilización y autenticación PPP para cada conexión PPTP. La autenticación y contabilización de cada conexión puede ser hecha a través de un cliente RADIUS o de forma local RouterOS soporta los tipos de encriptación • MPPE 40bit RC4 • MPPE 128bit RC4 El tráfico PPTP utiliza • TCP puerto 1723 • IP protocol GRE o GRE = Generic Routing Encapsulation o GRE = IP protocol ID 47 PPTP puede ser usado con la mayoría de firewalls y routers habiitando TCP 1723 y GRE (protocolo 47). De esta manera el tráfico puede ser ruteado a través del firewall o router. Las conexiones PPTP pueden resultar muy limitadas o incluso a veces hasta imposibles cuando se configura através de una conexión enmascarada (NATeada). Academy Xperts 83 RouterOS v6.35.2.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 7: Laboratorio Detallado de Túneles Laboratorio 7.3 – Túnel PPTP (R1 Server – R2 Client) El diagrama inicial de configuración es el que se presenta en la Figura 8.3.1 Los pasos a seguir en este ejercicio son los siguientes: Paso 1 R1 (Router 1) debe remover los puertos (ether2 y eoip-tunnel1) agregados a Bridge1, y también debe eliminar el Bridge1 creados en el Laboratorio 8.2 R2 (Router 2) debe remover los puertos (ether2 y eoip-tunnel1) agregados a Bridge1, y también debe eliminar el Bridge1 creados en el Laboratorio 8.2 • Este paso es necesario para que no haya inconvenientes con el direccionamiento de las redes • No es necesario que los Routers desactiven/eliminen los túneles EoIP ni IPIP Paso 2 R1 (Router 1) tendrá el rol de Server PPTP por lo que debe crear la siguiente configuración: 1. Crear el PPP SECRET. El perfil/profile que se utilizará es DEFAULT (sin encriptación) /ppp secret add name=prueba password=prueba service=pptp local-address=10.2.2.2 \ remote-address=10.3.3.3 2. Habilitar el servicio PPTP SERVER /interface pptp-server server set enabled=yes default-profile=default Academy Xperts 84 RouterOS v6.35.2.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 7: Laboratorio Detallado de Túneles Paso 3 R2 (Router 2) tendrá el rol de Cliente PPTP por lo que debe crear la siguiente configuración: /interface pptp-client add name=pptp-out1 connect-to=10.1.1.2 \ user=prueba password=prueba profile=default disabled=no Paso 4 1. R1 (Router 1) debe verificar que se ha generado una interface pptp y que se encuentra corriendo (R). Esta interface se ha generado dinámicamente (D) /interface pptp-server print Flags: X - disabled, D - dynamic, R - running # NAME USER MTU CLIENT-ADDRESS UPTIME ENCODING 0 DR <pptp-prueba> prueba 1450 10.1.1.6 2m31s 2. R1 debe verificar el estatus de la conexión (connected) /interface pptp-server monitor <pptp-prueba> status: connected uptime: 7m1s user: prueba caller-id: 10.1.1.6 encoding: mtu: 1450 mru: 1450 local-address: 10.2.2.2 remote-address: 10.3.3.3 -- [Q quit|D dump|C-z pause] Nota: El pptp-server asignó las direcciones local (local-address) y remota (remote-address) a ambas interfaces del túnel Paso 5 1. R2 (Router 2) debe verificar que la interface pptp-client se encuentra corriendo (R). /interface pptp-client print Flags: X - disabled, R - running 0 R name="pptp-out1" max-mtu=1450 max-mru=1450 mrru=disabled connect-to=10.1.1.2 user="prueba" password="prueba" profile=default keepalive-timeout=60 add-default-route=no dial-on-demand=no allow=pap,chap,mschap1,mschap2 2. R2 debe verificar el estatus de la conexión (connected) /interface pptp-client monitor pptp-out1 do file interval numbers [admin@R2] > interface pptp-client monitor pptp-out1 status: connected uptime: 12m22s encoding: mtu: 1450 mru: 1450 local-address: 10.3.3.3 remote-address: 10.2.2.2 -- [Q quit|D dump|C-z pause] Academy Xperts 85 RouterOS v6.35.2.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 7: Laboratorio Detallado de Túneles Paso 6 R1 (Router 1) debe crear una entrada en la tabla de rutas para llegar a la red remota (192.168.2.0/24) especificando como Gateway la dirección IP de la interface del túnel PPTP remota /ip route add dst-address=192.168.2.0/24 gateway=10.3.3.3 R2 (Router 2) debe crear una entrada en la tabla de rutas para llegar a la red remota (192.168.1.0/24) especificando como Gateway la dirección IP de la interface del túnel PPTP remota /ip route add dst-address=192.168.1.0/24 gateway=10.2.2.2 Paso 7 R1 (Router 1) debe verificar que llega a la IP de la interface LAN remota ejecutando un ping /ping 192.168.2.254 R2 (Router 2) debe verificar que llega a la IP de la interface LAN remota ejecutando un ping /ping 192.168.1.254 Academy Xperts 86 RouterOS v6.35.2.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 7: Laboratorio Detallado de Túneles Laboratorio 7.4 – Túnel PPTP (R1 Client – R2 Server) El diagrama inicial de configuración es el que se presenta en la Figura 8.4.1 Los pasos a seguir en este ejercicio son los siguientes: Paso 1 R1 (Router 1) debe remover la ruta creada en el Laboratorio 8.3 (dst-address=192.168.2.0/24 gateway=10.3.3.3) R2 (Router 2) debe remover la ruta creada en el Laboratorio 8.3 (dst-address=192.168.1.0/24 gateway=10.2.2.2) • Este paso es necesario para que no haya inconvenientes con el direccionamiento de las redes • No es necesario que los Routers desactiven/eliminen los túneles EoIP ni IPIP • Es IMPORTANTE que se mantenga el túnel PPTP creado en el Laboratorio 8.3 para demostrar que un mismo router puede actuar como Cliente y Server a la vez. Paso 2 R2 (Router 2) tendrá el rol de Server PPTP por lo que debe crear la siguiente configuración: 1. Crear el PPP SECRET. El perfil/profile que se utilizará es DEFAULT (sin encriptación) /ppp secret add name=prueba password=prueba service=pptp local-address=10.4.4.4 \ remote-address=10.5.5.5 2. Habilitar el servicio PPTP SERVER /interface pptp-server server set enabled=yes default-profile=default Paso 3 R1 (Router 1) tendrá el rol de Cliente PPTP por lo que debe crear la siguiente configuración: /interface pptp-client add name=pptp-out1 connect-to=10.1.1.6 \ user=prueba password=prueba profile=default disabled=no Paso 4 1. R2 (Router 2) debe verificar que se ha generado una interface pptp y que se encuentra corriendo (R). Esta interface se ha generado dinámicamente (D) /interface pptp-server print Flags: X - disabled, D - dynamic, R - running # NAME USER MTU CLIENT-ADDRESS UPTIME ENCODING 0 DR <pptp-prueba> prueba 1450 10.1.1.2 1m16s 2. R2 debe verificar el estatus de la conexión (connected) interface pptp-server monitor <pptp-prueba> status: connected uptime: 4m23s user: prueba caller-id: 10.1.1.2 encoding: mtu: 1450 mru: 1450 local-address: 10.4.4.4 remote-address: 10.5.5.5 -- [Q quit|D dump|C-z pause] Nota: El pptp-server asignó las direcciones local (local-address) y remota (remote-address) a ambas interfaces del túnel Academy Xperts 87 RouterOS v6.35.2.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 7: Laboratorio Detallado de Túneles Paso 5 1. R1 (Router 1) debe verificar que la interface pptp-client se encuentra corriendo (R). /interface pptp-client print Flags: X - disabled, R - running 0 R name="pptp-out1" max-mtu=1450 max-mru=1450 mrru=disabled connect-to=10.1.1.2 user="prueba" password="prueba" profile=default keepalive-timeout=60 add-default-route=no dial-on-demand=no allow=pap,chap,mschap1,mschap2 2. R1 debe verificar el estatus de la conexión (connected) /interface pptp-client monitor pptp-out1 do file interval numbers [admin@R2] > interface pptp-client monitor pptp-out1 status: connected uptime: 12m22s encoding: mtu: 1450 mru: 1450 local-address: 10.5.5.5 remote-address: 10.4.4.4 -- [Q quit|D dump|C-z pause] Paso 6 R1 (Router 1) debe crear una entrada en la tabla de rutas para llegar a la red remota (192.168.2.0/24) especificando como Gateway la dirección IP de la interface del túnel PPTP remota /ip route add dst-address=192.168.2.0/24 gateway=10.4.4.4 R2 (Router 2) debe crear una entrada en la tabla de rutas para llegar a la red remota (192.168.1.0/24) especificando como Gateway la dirección IP de la interface del túnel PPTP remota /ip route add dst-address=192.168.1.0/24 gateway=10.5.5.5 Paso 7 R1 (Router 1) debe verificar que llega a la IP de la interface LAN remota ejecutando un ping /ping 192.168.2.254 R2 (Router 2) debe verificar que llega a la IP de la interface LAN remota ejecutando un ping /ping 192.168.1.254 Nota: Al final de este ejercicio puede constatar que un mismo router puede actuar como Cliente y como Server al mismo tiempo cuando se configuran túneles. Academy Xperts 88 RouterOS v6.35.2.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 7: Laboratorio Detallado de Túneles Laboratorio 7.5 – Bridge a través de un túnel PPTP usando BCP Objetivos: • Interconectar 2 redes remotas (Red A y Red B) y formar una sola red Ethernet (un mismo dominio de broadcast) • Se requiere usar encriptación para proteger la integridad de los datos. • Esta actividad se realizará con túnel PPTP y protocolo BCP Bases Conceptuales: • RouterOS soporta BCP (Bridge Control Protocol) para las interfaces PPP, PPTP, L2TP y PPPoE. • BCP permite que los paquetes pasen en Bridge a través de un enlace PPP. • Para hacer Bridging, BCP puede utilizarse en lugar de EoIP + Túnel VPN • Para hacer Bridging, BCP puede utilizarse en lugar de un enlace WDS en una red inalámbrica Cuando se establece el BCP, éste constituye una parte independiente del túnel PPP. No está relacionado a ninguna dirección IP de la interface PPP, razón por la cual el Bridging y el Routing se pueden realizar al mismo tiempo de forma independiente. Requerimientos: • BCP debe ser habilitado en ambos lados (PPP server y PPP cliente) para poder funcionar. • RouterOS puede trabajar con otros dispositivos que soporte BCP de acuerdo al estándar siempre y cuando el BCP esté habilitado. El diagrama de configuración al que se desea llegar es el que se presenta en la Figura 8.5.1 Paso 1 1. R1 (Router 1) debe remover la ruta creada en el Laboratorio 8.4 (dst-address=192.168.2.0/24 gateway=10.5.5.5) 2. R1 (Router 1) debe eliminar la IP asignada a la interface ether2 (192.168.1.254/24) 3. R2 (Router 2) debe remover la ruta creada en el Laboratorio 8.4 (dst-address=192.168.1.0/24 gateway=10.4.4.4) 4. R2 (Router 2) debe eliminar la IP asignada a la interface ether2 (192.168.2.254/24) 5. Después de eliminar las direcciones IP de las interfaces ether2, los estudiantes deberán ingesar por MAC Winbox a los respectivos dispositivos. Notas importantes: • Este paso es necesario para que no haya inconvenientes con el direccionamiento de las redes • No es necesario que los Routers desactiven/eliminen los túneles EoIP ni IPIP • No es necesario que los Routers desactiven/eliminen los túneles PPTP creados en los Laboratorios 8.3 y 8.4 Paso 2 (configuración en R1 <Router 1> en la RED A) 1. Primero se debe crear una interface Bridge, y se debe segurar que el Bridge tiene una dirección MAC. El motivo es porque los puertos PPP no tienen dirección MAC. /interface bridge add name=bridge_local protocol-mode=rstp /interface bridge port add bridge=bridge_local interface=ether2 2. Debemos asegurarnos que el Bridge posee una dirección MAC. Para esto asignamos la MAC de la interface ether2 al bridge com MAC de Administración. D4:CA:6D:E5:7F:DF es la dirección MAC de ether2 en el router del laboratorio ejemplo. Usted debe obtener la dirección MAC de su equipo. /interface bridge set bridge_local admin-mac=D4:CA:6D:E5:7F:DF Academy Xperts 89 RouterOS v6.35.2.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 7: Laboratorio Detallado de Túneles 3. Asignamos las IP a la interface bridge_local. Se asume que la interface wlan ya tiene asignada su IP desde los laboratorios anteriores. /ip address add address=192.168.1.254/24 interface=bridge_local 4. En este laboratorio vamos a utilizar el túnel PPP únicamente para hacer Bridge, por lo que la configuración del Profile PPP es sencilla y no requiere que se asignen direcciones IP a las interfaces de túnel local y remoto. Por lo tanto solo se va a user/password, y muy importante especificar la opción bridge en el Profile. /ppp profile add name=ppp_bridge bridge=bridge_local use-encryption=yes /ppp secret add profile=ppp_bridge name=pruebabridge password=pruebabridge 5. Cuando se hace Bridge, el túnel PPP necesita pasar los paquetes con la cabecera de Capa 2 incluida, por lo que el valor MTU de la interface no es suficiente. Para el caso de túneles PPTP el MTU es de 1460. Para asegurar una operación apropiada se sugiere modificar el valor del MRRU en el router que hace de Server, po lo que se debe especificar un valor de MRRU mayor. Recuerde que MRRU permite habilitar soporte multi-link sobre un enlace único, y lo hace dividiendo el paquete hacia múltiples canales y por consiguiente incrementando el valor de MTU y MRRU. /interface pptp-server server set enabled=yes mrru=1600 Paso 3 (configuración en R2 <Router 2> en la RED B) 1. Primero se debe crear una interface Bridge, y se debe asegurar que el Bridge tiene una dirección MAC. El motivo es porque los puertos PPP no tienen dirección MAC. /interface bridge add name=bridge_local protocol-mode=rstp /interface bridge port add bridge=bridge_local interface=ether2 2. Debemos asegurarnos que el Bridge posee una dirección MAC. Para esto asignamos la MAC de la interface ether2 al bridge con MAC de Administración. D4:CA:6D:B4:31:19 es la dirección MAC de ether2 en el router del laboratorio ejemplo. Usted debe obtener la dirección MAC de su equipo. /interface bridge set bridge_local admin-mac=D4:CA:6D:B4:31:19 3. Asignamos las IP a la interface bridge_local. Se asume que la interface wlan ya tiene asignada su IP desde los laboratorios anteriores. /ip address add address=192.168.1.253/24 interface=bridge_local 4. En este laboratorio vamos a utilizar el túnel PPP únicamente para hacer Bridge, por lo que la configuración del Profile PPP es sencilla. Por lo tanto es muy importante especificar la opción bridge en el Profile. Recuerde que R2 actuará como Cliente PPTP por lo que NO necesita configurar SECRET. /ppp profile add name=ppp_bridge bridge=bridge_local use-encryption=yes Academy Xperts 90 RouterOS v6.35.2.01 – Ruteo Avanzado y Alta Disponibilidad, Capítulo 7: Laboratorio Detallado de Túneles 5. Se debe crear la interface pptp-client. Recuerde que se debe especificar el valor de MRRU del mismo valor al que se especificó en el pptp-server. De esta forma se asegura que los paquetes pasen adecuadamente por el túnel PPP. /interface pptp-client add profile=ppp_bridge mrru=1600 connect-to=10.1.1.2 user=pruebabridge password=pruebabridge disabled=no Paso 4 Las laptops de las Redes A y B deben configurar una IP de la misma subred. Por ejemplo: Laptop Red A: 192.168.1.1/24 Laptop Red B: 192.168.1.2/24 Con esta configuración ambas laptops debe poder hacer PING entre ellos. Academy Xperts 91 Ruteo Avanzado y Alta Disponibilidad con MikroTik RouterOS por Mauro Escalante