Balanceo de Carga con
MikroTik RouterOS
v6.38.0.01
Ejemplos de Balanceo
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.
Tabla de Contenido
Introducción ... ii
Audiencia ... iii
Convenciones usadas en este libro ... iii
Comentarios y preguntas ... iii
Partners de Academy Xperts en Latinoamérica ... iv
Empresas Asociadas ... iv
Universidades e Institutos Superiores ... iv
Deseas convertirte en Academia o ser Partner de Academy Xperts? ... iv
Un poco de Historia (Costa Rica) ... v
Cubriendo un País con MikroTik. ... v
Detalle de cambios en las dos últimas versiones de RouterOS ... vi
6.38 (2017-Diciembre-30 11:33): ... vi
6.37.3 (28-Noviembre-2016, 11:11) ... xi
Balanceo de Carga ... 14
Balanceo de Carga Usando PCC (Per Connection Classifier) ... 14
Balanceo de Carga Usando ECMP (Equal Cost Multi-Path) ... 18
Introducción
MikroTik es una empresa que nace en Latvia (Letonia) en 1996 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
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.
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:
libro@abcxperts.com
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
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 libro@abcxperts.com 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 mescalante@academyxperts.com para proporcionarte los detalles.
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.
Detalle de cambios en las dos últimas versiones de RouterOS
Para una revisión 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
6.38 (2017-Diciembre-30 11:33):
IMPORTANTE
• Para evitar problemas de compatibilidad STP/RSTP con versiones anteriores de RouterOS, se recomienda actualizar RouterOS en todos los routers en las redes Capa 2 que tengas configuraciones de VLAN y STP/RSTP
IMPORTANTE ipsec
• Se agregó la autenticación de usuario IKEv1 xauth con RADIUS "/ip ipsec user settings set xauth-use-radius=yes"
• Se agregó soporte IKEv2
• Se agregó autenticación IKEv2 EAP RADIUS passthrough para el contestador (responder) • Se agregó soporte para generación única de políticas
• Se removió el soporte IKEv1 ah+esp IMPORTANTE snmp
• Se agregaron las funcionalidades básicas get y walk "/tool snmp-[get|walk]" IMPORTANTE switch
• Se agregó la funcionalidad STP de hardware para dispositivos CRS y pequeños switch con chip Atheros
• (http://wiki.mikrotik.com/wiki/Manual:CRS_examples#Spanning_Tree_Protocol);
IMPORTANTE tr069-client
• Implementación inicial de TR069-cliente (como un paquete separado) (únicamente el cliente); IMPORTANTE winbox
• Winbox 3.7 es la mínima versión que se puede conectar a RouterOS arp
• Se agregó la funcionalidad "local-proxy-arp" bonding
• Se agregó la opción "forced-mac-address"
• Se corrigió un problema en "tx-drop" en VLAN sobre bonding en plataformas x86; bridge
• Se corrigió un raro problema cuando se removía un puerto de un bridge
• Se corrigió un problema en VLAN BPDU rx y tx cuando se conectaba a un dispositivo no RouterOS con funcionalidad STP
• Se requiere que se especifique el admin-mac si el auto-mac está deshabilitado • Se muestra el bridge port name en el monitor de puertos
capsman
• Se agregó el parámetro "group-key-update"
• Se agregó la posibilidad de cambiar los valores arp, mtu, l2mtu en la configuración datapath • Se corrigió el ugrade CAP cuando se utilizaban diferentes paquetes wireless (se introdujo en v6.37)
• Se usa el correcto source address (dirección origen) en respuesta a los requerimientos unicast discovery ccr
• Se agregó el driver AHCI driver para Samsung XP941 128GB AHCI M.2; certificates
• Se agregó soporte para el export PKCS#12
• Se corrigió un problema de caída cuando el crl es removido mientras está siendo “fetched”
• Se corrigió un problema de confianza en la actualización del chain en la revocación del certificado local en programas que utilizan ssl
• Si no se provee el nombre, el nombre del certificado se creará automáticamente de los campos del certificado console
• Se corrigió un problema con un valor de multi argumento no configurado crs
• Se agregó la habilidad de poner comentario en más menús de switch
• Se corrigió una rara falla de kernel en el reset del switch (por ejemplo, reboot) dhcp
• Se corrigió un problema en la asignación del DNS server al cliente cuando el servidor dinámico ya existe y es de otra familia de direcciones IP
• Se corrigió un problema cuando el dhcp-client era todavía posible en las interfaces que tenían la etiqueta “slave” y utilizaban la MAC address de la interface esclava (slave)
• Se muestra el dhcp server como inválido y se envía a la bitácora (log) el error cuando la interface se convierte en esclava (slave)
dhcp-server
• Se corrigió un problema en que el asistente (wizard) no estaba habilitado para crear el pool dhcp_pool99 discovery
• Se agregó soporte LLDP
• Se removieron los túneles 6to4 de "/ip neighbor discovery menu" dns
• Se agregaron las configuraciones "max-concurrent-queries" y "max-concurrent-tcp-sessions" dude
• Los cambios se discuten en el siguiente link:
http://forum.mikrotik.com/viewtopic.php?f=8&t=112599)
ethernet
• Se agregó la unidad de soporte "k" y "M" para la configuración de Ethernet Bandwidth
• Se corrigió un problema en "tx-fcs-error" en las interfaces SFP cuando el loop-protect está habilitado export
• No se muestra el comentario en la interface en el menú "/ip neighbor discovery" • Se actualizan los valores por default para limpiar el export compact
fastpath
• Se corrigió un raro problema de caída
• Se corrigió un problema en el estatus de x86 bridge fast-path en que lo mostraba como activo incluso si manualmente estaba deshabilitado
file
• Se corrigió un problema de caída del file manager cuando se cancelaba la transferencia de archivos firewall
• Se agregó “creation-time” a las entradas del address-list
• Se agregó soporte sctp/dccp/udp-lite para las opciones de firewall "src-port", "dst-port", "port" y "to-ports"
• No se defragmentan los paquetes cuando están marcados con "notrack" en raw firewall
• Se corrigió un problema en la opción “time” reconociendo el día de la semana apropiadamente (se introdujo en la v6.37.2)
• Se corrigió un problema en el comportamiento de una regla raw dinámica (dynamic raw rule)
• Se corrigió un problema en la activación de una regla si la opción “time” es utilizada y no hay otras reglas activas presentes
• Se incrementó el máximo tamaño de conexiones (max size) en la tabla del connection tracking a 1048576 • Se hizo una implementación más rápida de la opción “connection-limit”
• Se mejoró significativamente el desempeño cuando se importan grandes reglas de firewall graphing
• Se corrigió un problema en los gráficos de colas (simples) que aparecía en la interface web si el tamaño del nombre agregado era mayor a 57840 símbolos
health
• Se muestra el consumo de potencia en los dispositivos que tienen monitor voltaje y corriente hotspot
• Se corrigió un problema en la configuración en las reglas de NAT en “chain=hs-unauth-to” cambiándolo de “dst-port” a “src-“dst-port” en las reglas “return” en Walled Garden IP
interface
• Se cambió el MTU de la interface loopback a 1500
• No se tratan los múltiples ceros como un simple cero en la comparación de nombre • Se muestran las estadísticas del enlace en "/interface print stats-detail" ipsec
• Se agregó la capacidad de especificar la Dirección IP estática en la opción “send-dns” • Se agregó la contabilización ph2 para cada política "/ip ipsec policy ph2-count" • Se permite especificar la dirección de dns de división explícita
• Se cambió el tópico de logging de error a debug cuando se reciben mensajes pfkey vacíos • No se auto negocian más SAs de los que se necesitan
• Se asegura de que la política generada se refiere a una propuesta (proposal) válida • Se corrigió un problema en la carga del módulo del algoritmo criptográfico camelia • Se corrigió el prefijo remote IPv6
• Se corrigió una falla de Kernel en los equipos tile con sha256 cuando no se utiliza la encriptación por hardware • Se corrigió un problema en la configuración “my-id IPv4 address endianness”
• Se corrigió un problema de auton egociación chequeando las políticas en orden correcto • Se carga los módulos relacionados a IPv6 únicamente cuando el paquete IPv6 está habilitado • Se hace que las políticas generadas sean siempre únicas
• Los pares no pasivos siempre establecerán los SAs de las políticas sin esperar por el primer paquete • Se optimizó el loggin en el tópico ipsec
• Se muestra la etiqueta/bandera activa cuando la política tiene un SA activo • Se muestra el SA "enc-key-size"
• Se dividen los argumentos "mode-config" y "send-dns" ipv6
• Se agregó la configuración “no-dad” a las direcciones IPv6
• Se corrigió un problema con el comportamiento "accept-router-advertisements" • Se movió el mensaje de error del pool IPv6 vacío a ser ahora un tópico de error lcd
• Se mejoró el desempeño, lo que ocasiona ahora menos carga del CPU led
• Se corrigió un problema en el modo oscuro (dark mode) del cAP 2nD
(http://wiki.mikrotik.com/wiki/Manual:System/LEDS#Leds_Setting);
log
• Se corrigió un problema con el mensaje "System rebooted because of kernel failure" que se mostraba después del primer reboot
lte
• Se agregó soporte para más modems Vodafone K4201-Z, Novatel USB620L, PANTECH UML295 y ZTE MF90 • Se permite ejecutar los comandos de información actuales
• Se corrigió un problema en el soporte a dwm-222, Pantech UML296
• Se corrigió un problema de retardo de inicio después de que se hacía un reset • Se incrementó el retardo cuando se configuraba el modo sms send
• Se retorna los datos de información cuando se llenan todos los campos metarouter
• Se corrigió un problema durante el proceso de inicio (se introdujo en la v6.37.2) mmips
• Se corrigió un problema de contabilización de tráfico en el menú "/interface" ospf
• Se corrigió un problema de caída de ruta ocasionado por un fallo en la memoria cuando había múltiples interfaces activas
ppp
• Se corrigió un problema en el cálculo del tamaño del paquete cuando se configuraba el MRRU (cuando era 2 bytes más grande que lo que permitía el MTU)
• Se mejoró significativamente la velocidad de apagado (shutdown) en los servidores con múltiples túneles activos • Se mejoró significativamente el proceso de terminación de túnel en servidores con múltiples túneles activos profile
• Se agregaron los procesos "bfd" y "remote-access"
• Se agregó la capacidad de monitorear el uso del CPU por núcleo (per core) • Se hace que el profile trabaje en dispositivos mmips
• Se clasifican apropiadamente los procesos “wireless” queue
• Se corrigió un problema en la opción “time” reconociendo apropiadamente los días de la semana (se introdujo en la v6.37.2)
radius
• Se agregó el servicio IPSec (únicamente en el cliente) rb750Gr3
• Se corrigió un problema en IPsec con 3des+md5 rb850Gx2
• Se corrigió un problema de monitoreo de temperatura PCB si la temperatura era superior a 60C resolver
• Se ingnoran las entradas de cahé si se utiliza el servidor especificado routerboot
• Se muestra el mensaje de log si el CPU/RAM del router está sobrecargado script
• Se incrementa el valor de contador de ejecución cuando el script se ejecuta desde SNMP snmp
• Siempre se reporta la velocidad del bonding como la velocidad del primer esclavo (slave) del bonding • Se corrige un raro problema de caída cuando se recibía un paquete formateado incorrectamente • Se prove sinr en la tabla lte
ssh
• Se agrega la configuración routing-table (únicamente en el cliente)
• Se corrige un problema en la configuración perdida "/ip ssh" cuando se hacía un upgrade desde una versión más vieja que la v5.15
system
• Se hace un reboot al dispositivo en la caída de un programa crítico tile
• Se corrige un problema de falla de Kernel cuando el paquete IPv6 ICMP se enviaba a través de la interface PPP time
• Se actualizaron las zonas de tiempo (time zones) traceroute
• Se corrigió un problema de fuga de memoria traffic-flow
• Se corrigió un problema en el contador y en la longitud de la secuencia del flujo trafficgen
• Se corrigió un problema en el export compacto (compact export) cuando el "header-stack" incluía TCP • Se corrigió un problema de caída cuando se procesaba tráfico IPv6
• Se corrigió un problema de caída potencial cuando se generaba un frame muy grande • Se mejoró el soporte para fastpath
tunnel
• Se corrigió un problema en que ocasionalmente los paquetes transmitidos no pasaban a través del fastpath • Se exporta apropiadamente el valor keepalive
usb
• Se corrigió un problema de fallo de Kernel cuando se removía el dispositivo Nexus 6P users
• Se agregó un conjunto de permisos mínimos requeridos para el grupo de usuarios “full” • Se agregó la política TikApp
vlan
• Se permite agregar multiples VLANs cuyo nombre inicia con el mismo número y tiene la misma longitud vrrp
watchdog
• No se envía el archivo supout si el parámetro "auto-send-supout" está deshabilitado webfig
• Se agrega una protección extra contra exploits XSS • Se muestra correctamente las direcciones IPv6
• Se muestra apropiadamente los tiempos last-link-up/down de la interface winbox
• Se agregó la bandera/etiqueta “complete” a la tabla ARP
• Se agregó la opción “untracked” a la configuración de firewall “connection-state”
• Se agregó el ícono Dude al menú Dude
• Se permite habilitar/deshabilitar (enable/disable) los destinos (targets) de flujo de tráfico • Se permite ejecutar el profile desde el menú "/system resources"
• Se permite especificar la interface para los leds con el trigger "interface-speed" • No se permite configurar "loop-protect-send-interval" con ceros (0)
• No se muestra el profile del user hotspot de los filtros y marcas entrantes y salientes si no hay un valor especificado
• Se corrigió un problema de caída cuando se utilizaba una versión legacy de Winbox
• Se corrigieron los valores por default para las interfaces "loop-protect-disable-time" y "loop-protect-send-interval"
• Se corrigió un problema en que se perdía el menú "IPv6/Settings" • Se corrigió un problema de tipografía en la configuración "propagate-ttl" • Se hace que el firmado de certificado incluye el ca-crl-host proporcionado • Se movió el ipsec peer "exchange-mode" a la pestaña General
• Se muestra apropiadamente las tasas básicas y soportadas VHT en CAPsMAN • Se remueve los valores de repuesto del menú loop-protect
• Se muestran todas las configuraciones relacionadas en la pestaña HT en el modo 2GHz-g/n
• Se muestran como 0.0.0.0 las direcciones NTP primaria y secundaria, si es que no se han configurado • Se muestra el timeout de conexión IPv6 apropiado
wireless
• Se agregó el comando API para reportar el country-list (/interface/wireless/info/country-list) • Se agregó el chequeo CRL para eap-tls
• Se corrigió un problema en la acción del manejo de frame en nodos WDS • Se corrigió la apariencia del canal extension-channel en consola
• Se corrigió completamente la impresión de la cabecera "spectral-history" en los modos AP
• Se corrigió una rara falla de Kernel cuando se conectaba a un AP NV2 con una tasa legacy seleccionada
• Se corrigió un problema cuando se hacía upgrade desde viejos paquetes Wireless cuando la interface AP tenía el SSID vacío
• Se toma en cuenta el ancho del canal cuando se retornan los canales soportados • Se utiliza el VLAN ID 0 en el mensaje RADIUS para deshabilitar el VLAN tagging
6.37.3 (28-Noviembre-2016, 11:11)
bgp
• No se verifica coincidencia a todos los prefijos taggeados con community 0:0 en los filtros de ruteo bridge
• Se corrigió un problema en la opción filter ingress priority (problema se presentó en v6.36rc8)
chr
• Se corrigió un problema de caída en “/interface print” (problema se presentó en v6.34.4) • Se corrigió un problema en "/system reboot" y "/system shutdown";
crs226
• Se corrigió un problema de renegociación de enlace en sfp-sfpplus1 (problema se presentó en v6.37rc28/v6.37.1) disk
• Se corrigió un problema cuando el disco se cambiaba de nombre después de hacer reboot en dispositivos con flash disks
dns
• No resuelve las direcciones incorrectas después de que se han hecho los cambios en las entradas de DNS estático • Se mejoran las entradas de DNS estático agregando velocidad cuando se utiliza regexp
dude
• Los cambios se discuten en el link: http://forum.mikrotik.com/viewtopic.php?f=8&t=112598
firewall
• Se corrigió un problema en las reglas de filtrado en el parámetro limit, haciéndolo visible nuevamente
• Se corrigió un problema en el reconocimiento del estado de la interface slave (problema se presentó en v6.37.2) • Se corrigió un problema en la opción timeout en address lists con el nombre de dominio
log
• Se ignora el tópico email si action=email
mipsbe
• Se mejoró la asignación de memoria en dispositivos con NAND cuando se están procesando las transferencias de archivo y el tráfico TCP
route
• Se corrigió un problema de memoria cuando se deshabilitaba el route cache tile
• Se corrigió un raro problema de Kernel cuando se recibía un paquete IPv6 neighbor discovery packet traceroute
• Se corrigió un problema de caída cuando demasiadas sesiones estaban activas tunnel
• Se permite forzar el valor del MTU cuando el actual-mtu ya es el mismo winbox
• Se reconoce correctamente TCP en traffic-generator packet-template header type
Balanceo de Carga
El balanceo de carga es un método que ayuda a distribuir el tráfico a través de múltiples enlaces para obtener una mejor utilización.
El balanceo de carga ayuda a optimizar la utilización de recursos, maximizar el throughput, minimizar los tiempos de respuesta, y evitar la sobrecarga de un único recurso. De esta forma se logra confiabilidad y disponibilidad a través de redundancia.
Es importante mencionar que existe una diferencia entre balanceo de carga y unión de canales (channel bonding): • Balanceo de carga – Divide el tráfico entre interfaces de red (Capa 4 del modelo OSI)
• Unión de canales (channel bonding) – Implica una división de tráfico entre interfaces física en un nivel más bajo, ya sea por paquete (Capa 3) o por enlace de datos (Capa 2, utilizando el protocolo 802.1aq – SPB, Shortest Path Bridging)
El balanceo de carga es sumamente útil donde existen enlaces de comunicación redundantes, ya que todos los enlaces se pueden utilizar al mismo tiempo. Al utilizar múltiples enlaces de forma simultánea, se incrementa la disponibilidad del ancho de banda. De esta forma se evita la congestión o saturación de la red en un solo enlace.
En RouterOS el balanceo de carga puede ser realizado basado en paquete packet) o basado en conexión (per-connection). Los más comunes son PCC, ECMP y Nth
Método per-connection per-packet
Marcado de firewall SI SI
ECMP (Equal Cost Multi-Path) SI NO
PCC (per Connection Classifier) SI NO Nth (eNésimo Paquete - Nth Packet) SI SI
Bonding NO SI
OSPF SI NO
BGP SI NO
Balanceo de Carga Usando PCC (Per Connection Classifier)
PCC toma los campos seleccionados de la cabecera IP, y con la ayuda de un algoritmo de hashing convierte los campos seleccionados en un valor de 32-bits.
Este valor se divide por un Denominador especificado y el resto se compara con un Restante especificado; si es igual entonces se captura el paquete.
Se puede elegir de los siguientes campos de las cabeceras IP y TCP para utilizarlos en esta operación: • src-address (cabecera IP)
• dst-address (cabecera IP) • src-port (cabecera TCP) • dst-port (cabecera TCP)
Cabecera IP
Con estos campos se pueden armar las siguientes combinaciones: • both-addresses • both-ports • dst-address-and-port • src-address • src-port • both-addresses-and-ports • dst-address • dst-port • src-address-and-port
Si queremos revisar la sintaxis completa a través de CLI (línea de comandos) utilizamos el signo “?” al final del comando: /ip firewall mangle add chain=prerouting per-connection-classifier=?
per-connection-classifier=
PerConnectionClassifier ::= [!]ValuesToHash:Denominator/Remainder Remainder ::= 0..4294967295 (integer number)
Denominator ::= 1..4294967295 (integer number)
ValuesToHash ::= both-addresses|both-ports|dst-address-and-port|
src-address|src-port|both-addresses-and-ports|dst-address|dst-port|src-address-and-port
Denominadores y Restos son partes de operaciones de módulos.
Una operación de módulo produce un valor entero que sobra cuando se divide dos números y solo uno acepta la porción del número completo del resultado. Se representa con un signo %
Ejemplos de esta operación:
• 3 % 3 = 0, porque 3 se divide limpiamente para 3
• 4 % 3 = 1, porque el siguiente número más pequeño al que 4 se divide limpiamente por 3 es 3, y 4 – 3 = 1 • 5 % 3 = 2, porque el siguiente número más pequeño al que 5 se divide limpiamente por 3 es 3, y 5 – 3 = 2 • 6 % 3 = 0, porque 6 se divide limpiamente para 3
Hash es una función que se alimenta de una entrada y produce una salida. Las funciones de hash tienen muchas
propiedades interesantes, pero para el uso de PCC la única que importa es la función determinística. Esto significa que, si se alimenta una función hash con una entrada que lee “hola” y produce la salida “1”, entonces se puede confiar en el hecho de que si se alienta nuevamente la entrada con “hola” producirá nuevamente la salida “1”, es decir, que cuando se alimenta una función de hash con la misma entrada, entonces producirá la misma salida.
Para el caso de PCC, cuando se alimenta las direcciones IP y puertos, solo se agrega los octetos de las direcciones IP como números decimales al igual que los puertos, y luego se toma el último dígito y lo produce como la salida.
Por ejemplo, la función hash se alimenta con:
• 1.1.1.1 como la dirección IP origen, 10000 como el puerto origen TCP • 2.2.2.2 como la dirección IP destino, 80 como el puerto destino TCP
• La salida será 1+1+1+1+10000+2+2+2+2+80 = 10092, el último dígito de ese nuevo número es 2, por lo que la salida de la función hash será 2.
• Por lo tanto, se producirá la salida 2 cada vez que se produzca la misma combinación de direcciones IP y puertos Es importante notar que, aunque PCC es muy utilizado para balancear carga entre circuitos de red, sin embargo, PCC por sí mismo no tiene nada que ver con el enrutamiento, con los routing-mark, con la distribución de la carga. PCC es
simplemente una forma para hacer coincidir (match) a los paquetes, y no está relacionado directamente con la acción de marcar los paquetes que coinciden, aunque ese sea su propósito principal.
Las siguientes son líneas que comúnmente se utilizan en PCC:
1) /ip firewall mangle add chain=prerouting action=mark-connection \
new-connection-mark=1st_conn per-connection-classifier=src-address-and-port:3/0 2) /ip firewall mangle add chain=prerouting action=mark-connection \
new-connection-mark=2nd_conn per-connection-classifier=src-address-and-port:3/1 3) /ip firewall mangle add chain=prerouting action=mark-connection \
new-connection-mark=3rd_conn per-connection-classifier=src-address-and-port:3/2
La primera línea significa: Producir la salida de la función hash dada la dirección IP y puerto origen del paquete, dividirlo por 3, y si el resto es 0, realizar la acción de marcar la conexión como 1st_conn
La segunda línea significa: Producir la salida de la función hash dada la dirección IP y puerto origen del paquete, dividirlo por 3, y si el resto es 1, realizar la acción de marcar la conexión como 2nd_conn
La tercera línea significa: Producir la salida de la función hash dada la dirección IP y puerto origen del paquete, dividirlo por 3, y si el resto es 2, realizar la acción de marcar la conexión como 3rd_conn
A continuación, se presenta el significado de las diferentes opciones de campo para el marcado de paquetes. Estos constituyen los campos que serán alimentados en el algoritmo de hashing, y para el propósito de distribuir la carga a través de los enlaces, decidir por qué enlace se enviará un paquete. Es importante recordar que una función de hash siempre producirá la misma entrada cuando se alimenta la misma salida:
• src-address: La dirección origen de un cliente siempre será la misma, por lo que todo el tráfico de un cliente en particular siempre coincidirá con el mismo matcher PCC, y siempre será puesto en el mismo enlace.
• dst-address: La dirección destino de un servidor específico siempre será la misma, por lo que todo el tráfico hacia ese server (por ejemplo www.mikrotik.com) siempre coincidirá con el mismo matcher PCC, y siempre será puesto en el mismo enlace.
• both-addresses: El par de IP origen y destino entre el mismo cliente y el mismo server siempre será el mismo, por lo que todo el tráfico entre un cliente específico y un servidor específico (por ejemplo, entre su laptop y
www.mikrotik.com) siempre coincidirá con el mismo matcher PCC, y siempre será puesto en el mismo enlace.
• src-port: Los puertos origen de los clientes son generalmente elegidos aleatoriamente cuando se crea la conexión, por lo que a través de muchas conexiones diferentes puertos origen serán alimentados en la función hash, y diferentes matchers PCC coincidirán y el tráfico irá a través de diferentes enlaces. Sin embargo, algunos protocolos cliente siempre eligen el mismo puerto origen, y los servidores atrás del router en su mayoría probablemente siempre utilicen el mismo puerto de servicio para enviar el tráfico de retorno a sus clientes. Un servidor web detrás del router enviaría la mayoría del tráfico desde sus puertos HTTP (80) y HTTPS (443), y ese tráfico siempre coincidiría con el mismo matcher PCC y se enviaría en el mismo enlace.
• dst-port: Los puertos destino de los clientes suelen ser puertos de servicio bien definidos. Todo el tráfico HTTP (80) entre clientes y servidores en Internet siempre coincidirá con el mismo matcher PCC, y se enviaría en el mismo enlace. Sin embargo, los mismos clientes que realicen tráfico HTTPS (443) podrían coincidir con un matcher PCC diferente y buscarían un enlace diferente.
• both-ports: Dado que el puerto del cliente es generalmente elegido en forma aleatoria, la combinación de los dos puertos es generalmente aleatoria y propagará la carga a través de los enlaces
• src-address-and-port: Igual que src-port. • dst-address-and-port: Igual que dst-port.
• both-addresses-and-ports: Esta es la forma más aleatoria de propagar el tráfico a través de los enlaces, ya que tiene el mayor número de variables.
Direcciones IP
/ip address
add address=192.168.0.1/24 interface=eth3 add address=10.1.1.2/30 interface=eth1 add address=10.20.1.2/30 interface=eth2
Políticas de ruteo
El objetivo de las políticas de ruteo es forzar el tráfico hacia un gateway específico, incluso si estuviera destinado a otro gateway. Las siguientes 2 reglas permiten el uso de las tablas de ruteo por default para el tráfico que está conectado a dichas redes (10.1.0/30 y 10.20.1.0/30) siempre y cuando el tráfico provenga de la LAN (ether3, 192.168.0.1/24)
/ip firewall mangle
add chain=prerouting dst-address=10.1.1.0/30 action=accept in-interface=eth3 add chain=prerouting dst-address=10.20.1.0/30 action=accept in-interface=eth3
En las siguientes 2 reglas se manejarán las conexiones iniciadas en el exterior (en la WAN), ya que las respuestas deben salir por la misma interface (desde la misma IP pública) por donde vino el requerimiento. Se marcarán únicamente las nuevas conexiones entrantes.
add chain=prerouting in-interface=eth1 connection-mark=no-mark action=mark-connection \ new-connection-mark=ISP1_conn
add chain=prerouting in-interface=eth2 connection-mark=no-mark action=mark-connection \ new-connection-mark=ISP2_conn
En las siguientes 2 reglas se utiliza PCC para dividir el tráfico LAN (ether3, 192.168.0.1/24) en dos grupos (en este ejemplo solo hay 2 interfaces WAN/Internet) para lo cual se utiliza both-addresses (basado en direcciones origen y destino). Puesto que el tráfico filtrado por chain=prerouting captura todo el tráfico que va hacia el mismo router, y se necesita filtrar el tráfico cuyo destino NO ES la red local (LAN, ether3), entonces se utiliza dst-address-type=!local
add chain=prerouting in-interface=eth3 connection-mark=no-mark dst-address-type=!local \
per-connection-classifier=both-addresses:2/0 action=mark-connection new-connection-mark=ISP1_conn add chain=prerouting in-interface=eth3 connection-mark=no-mark dst-address-type=!local \
per-connection-classifier=both-addresses:2/1 action=mark-connection new-connection-mark=ISP2_conn Cuando se trabaja con mark-routing debemos recordar que únicamente se puede utilizar chain=output y chain=prerouting. Por este motivo el tráfico de conexión LAN (ether3) se filtra con prerouting, y el tráfico de conexión WAN/Internet se filtra y marca (mark-routing) con chain=output.
add chain=prerouting connection-mark=ISP1_conn in-interface=eth3 action=mark-routing \ new-routing-mark=to_ISP1 passthrough=no
add chain=prerouting connection-mark=ISP2_conn in-interface=eth3 action=mark-routing \ new-routing-mark=to_ISP2 passthrough=no
add chain=output connection-mark=ISP1_conn action=mark-routing new-routing-mark=to_ISP1 passthrough=no add chain=output connection-mark=ISP2_conn action=mark-routing new-routing-mark=to_ISP2 passthrough=no En las siguientes 2 reglas se crean las rutas para cada routing-mark
/ip route
add dst-address=0.0.0.0/0 gateway=10.1.1.1 routing-mark=to_ISP1 check-gateway=ping add dst-address=0.0.0.0/0 gateway=10.20.1.1 routing-mark=to_ISP2 check-gateway=ping
Las siguientes 2 reglas habilitan el failover cuando uno de los Gateway falla. Para esto es necesario que esté activada la opción check-gateway
add dst-address=0.0.0.0/0 gateway=10.1.1.1 distance=1 check-gateway=ping add dst-address=0.0.0.0/0 gateway=10.20.1.1 distance=2 check-gateway=ping
NAT
Finalmente, puesto que las decisiones de ruteo ya fueron realizadas en las reglas anteriores, tan solo se necesita enmascarar (NATear) los paquetes que saldrán por cada interface WAN/Internet
/ip firewall nat
add chain=srcnat out-interface=eth1 action=masquerade add chain=srcnat out-interface=eth2 action=masquerade
Balanceo de Carga Usando ECMP (Equal Cost Multi-Path)
Direcciones IP
/ip address
add address=192.168.0.1/24 interface=eth3 add address=10.1.1.2/30 interface=eth1 add address=10.20.1.2/30 interface=eth2
NAT
/ip firewall nat
add chain=srcnat out-interface=eth1 action=masquerade add chain=srcnat out-interface=eth2 action=masquerade
Routing
/ip route
add dst-address=0.0.0.0/0 gateway=10.1.1.1,10.20.1.1 check-gateway=ping /ip route
add dst-address=0.0.0.0/0 gateway=10.1.1.1,10.20.1.1,10.20.1.1,10.20.1.1,10.20.1.1,10.20.1.1 \ check-gateway=ping
Conexiones usadas por propio router
/ip firewall mangle
add chain=input in-interface=eth1 action=mark-connection new-connection-mark=ISP1_conn add chain=input in-interface=eth2 action=mark-connection new-connection-mark=ISP1_conn
add chain=output connection-mark=ISP1_conn action=mark-routing new-routing-mark=to_ISP1 passthrough=no add chain=output connection-mark=ISP2_conn action=mark-routing new-routing-mark=to_ISP2 passthrough=no /ip route
add dst-address=0.0.0.0/0 gateway=10.1.1.1 routing-mark=to_ISP1 add dst-address=0.0.0.0/0 gateway=10.20.1.1 routing-mark=to_ISP2
Balanceo de Carga usando eNésimo Paquete (Nth Packet)
En el balanceo de carga usando el eNésimo paquete, cada regla tiene su propio contador. Cuando la regla recibe un paquete, el contador de la regla actual se incrementa en uno. Si el contador coincide con el valor de cada paquete será emparejado (match) y el contador se pondrá a cero
Si el passthrough no se configura, entonces los paquetes se marcarán de la siguiente manera:
• Primera regla nth=2,1 – En esta regla se emparejará cada primer paquete de 2, por lo tanto, el 50% del tráfico es emparejado por la regla
• Segunda regla si el passthrough=no – Emparejará únicamente el 25% del tráfico
Ejemplos:
Es posible emparejar (hacer match) el 50% de todo el tráfico solo con una regla: /ip firewall mangle
add action=mark-packet chain=prerouting new-packet-mark=AAA nth=2,1
Si se necesita más de una regla, entonces existen 2 formas de hacer coincidir los paquetes:
1. La primera regla ve todos los paquetes y hace coincidir (match) el 1/3 de todos. La segunda regla ve los 2/3 restantes de todos los paquetes y hace coincidir 1/2 de los mismos. La tercera regla ve y hace coincidir todos los paquetes que pasaron a través de as 2 reglas anteriores, es decir, el 1/3 de todos los paquetes (los que sobran).
/ip firewall mangle
add action=mark-packet chain=prerouting new-packet-mark=AAA nth=3,1 passthrough=no add action=mark-packet chain=prerouting new-packet-mark=BBB nth=2,1 passthrough=no add action=mark-packet chain=prerouting new-packet-mark=CCC
2. Todas las reglas pueden ver todos los paquetes y cada regla hace coincidir (match) cada tercer paquete /ip firewall mangle
add action=mark-packet chain=prerouting new-packet-mark=AAA nth=3,1 passthrough=yes; add action=mark-packet chain=prerouting new-packet-mark=BBB nth=3,2 passthrough=yes; add action=mark-packet chain=prerouting new-packet-mark=CCC nth=3,3 passthrough=yes;
IP Addresses
En el este ejercicio (Fig. 14-1), el router tiene 2 interfaces WAN con direcciones eth1=10.1.1.2/30 y eth2=10.20.1.2/30. La interface LAN (ether3) tiene la dirección ether3=192.168.0.1/24
/ip address
add address=192.168.0.1/24 interface=eth3 add address=10.1.1.2/30 interface=eth1 add address=10.20.1.2/30 interface=eth2
Mangle
Todo el tráfico de los clientes cuya Dirección IP coincide con el address-list=impar se marca con las marcas de conexión y marcas de ruteo “impar". Después, el tráfico se excluye del procesamiento de sucesivas reglas de mangle en
chain=prerouting /ip firewall mangle
add chain=prerouting src-address-list=impar in-interface=eth3 action=mark-connection \ new-connection-mark=impar passthrough=yes
add chain=prerouting src-address-list=impar in-interface=eth3 action=mark-routing \ new-routing-mark=impar passthrough=no
Lo mismo sucede con los clientes cuya dirección IP coincide con el address-list=par. /ip firewall mangle
add chain=prerouting src-address-list=par in-interface=eth3 action=mark-connection \ new-connection-mark=par passthrough=yes
add chain=prerouting src-address-list=par in-interface=eth3 action=mark-routing \ new-routing-mark=par passthrough=no
A continuación, lo que se hará es tomar cada segundo paquete que establece una nueva conexión (connection-state=new), y se lo marcará como “impar”. Consecuentemente todos los paquetes sucesivos que pertenezcan a la misma sesión llevarán la marca de conexión “impar”.
Nótese que:
• Se pasarán estos paquetes a la segunda y tercera regla (passthrough=yes)
• La segunda regla añade la dirección IP del cliente al address-list para habilitarlo para todas las sucesivas sesiones que pasan a través del mismo Gateway.
• La tercera regla establece el routing-mark=impar en todos los paquetes que pertenecen a la conexión “impar” y detiene el procesamiento de todas las otras reglas de mangle en chain=prerouting
/ip firewall mangle
add chain=prerouting in-interface=eth3 connection-state=new nth=2,1 \ action=mark-connection new-connection-mark=impar passthrough=yes add chain=prerouting in-interface=eth3 action=add-src-to-address-list \
address-list=impar address-list-timeout=1d connection-mark=impar passthrough=yes add chain=prerouting in-interface=eth3 connection-mark=impar action=mark-routing \
new-routing-mark=impar passthrough=no
Las siguientes reglas hacen lo mismo que el grupo anterior para la mitad restante del tráfico.
El código significa que cada nueva conexión que se inicia a través del router desde la red local será marcada como “impar” o “par” con ambas reglas de marcado de conexión y de ruteo.
/ip firewall mangle
add chain=prerouting in-interface=eth3 connection-state=new nth=2,2 \ action=mark-connection new-connection-mark=par passthrough=yes add chain=prerouting in-interface=eth3 action=add-src-to-address-list \
address-list=par address-list-timeout=1d connection-mark=par passthrough=yes add chain=prerouting in-interface=eth3 connection-mark=par action=mark-routing \
new-routing-mark=par passthrough=no
Las reglas funcionan bien, sin embargo, hay algunas situaciones en que la misma dirección IP está listada en ambos address-list (par e impar). Este comportamiento ocasiona problemas cuando las aplicaciones requieren conexiones persistentes. Para solucionar este inconveniente se debe agregar la siguiente regla a las reglas de mangle. Esto asegurará que las nuevas conexiones no sean parte del src-address-list=impar. Se tendrá que hacer lo mismo para las reglas de mangle “impar” y de esta forma excluir las direcciones IP que ya son parte del src-address-list=par.
add chain=prerouting in-interface=eth3 connection-state=new nth=2,2 \
src-address-list=!impar action=mark-connection new-connection-mark=par \ passthrough=yes
NAT
Se realiza el NATeo por las interfaces de salida correspondientes /ip firewall nat
add chain=srcnat out-interface=eth1 action=masquerade add chain=srcnat out-interface=eth2 action=masquerade
Routing
Todo el tráfico marcado como “impar” saldrá por el Gateway 10.1.1.1, y todo el tráfico marcado como “par” saldrá por el Gateway 10.20.1.1
/ip route
add dst-address=0.0.0.0/0 gateway=10.1.1.1 scope=255 target-scope=10 routing-mark=impar add dst-address=0.0.0.0/0 gateway=10.20.1.1 scope=255 target-scope=10 routing-mark=par
Finalmente, se agrega una entrada adicional especificando que el tráfico del propio router (tráfico que no tiene routing mark) deberá salir por el Gateway 10.20.1.1
/ip route
