¿Qué es el MTU?
Básicamente, el MTU (Maximum Transmission Unit) define el tamaño máximo que pueden tener los datos en capa 2 para un protocolo cualquiera. Lo que esto significa es que si por ejemplo una trama de datos excede el MTU, dicha trama deberá ser dividida en porciones más pequeñas para que pueda ser enviada por la red utilizando el protocolo subyacente. Dependiendo del protocolo, el MTU puede estar prefijado o definirse al momento de la conexión. Por ejemplo, el MTU para Ethernet es de 1500 bytes.
Ahora bien, la pregunta que surge muchas veces es si conviene un MTU grande o uno pequeño y la respuesta está asociada en general al tipo de medio con el que se cuente, aunque es importante primero entender las ventajas y desventajas en casa caso. Un MTU grande suele ser más eficiente debido a que puede llevar gran cantidad de datos de usuario, haciendo que el porcentaje de overhead (dado por los diferentes encabezados) sea menor. A su vez, para igual cantidad de datos, un MTU mayor implica menos tramas lo que también redunda en eficiencia, debido a que los dispositivos intermedios deben interactuar con menos paquetes. Por otro lado, existen dos desventajas principales asociadas a MTU muy grandes; una de ellas es que si en una de las tramas se detecta un error se descarta toda la trama, siendo entonces mayor el tiempo y el ancho de banda que se desperdician; la otra es que el enlace que transmite tramas grandes puede verse ocupado durante bastante tiempo, lo que implicaría retrasar otros datos de usuario, deteriorando la calidad del servicio.
Entonces y básicamente, el tamaño del MTU suele derivarse de la velocidad del enlace y la confiabilidad del mismo, dado que por ejemplo en un enlace con mucha tendencia a errores es poco eficiente un MTU grande, mientras que resulta ideal en enlaces confiables y rápidos.
Tim Berners Lee llama a continuar con la neutralidad de la web
El inventor de la World Wide Web, Tim Berners Lee, ha escrito un muy interesante artículo para la publicación Scientific American donde explica la importancia de mantener la neutralidad y los estándares abiertos en la web.
En sus reflexiones, Tim Berners Lee indica que la web tal como él la pensó suponía un espacio de intercambio de información en la que cualquier persona pudiera participar aportando contenido propio, de manera sencilla, sin tener que pagar ningún canon por ello ni pedir autorización para hacerlo. Marca que cada nuevo contenido la enriquece y destaca que son fundamentales en la web los enlaces entre diferentes sitios y contenidos, dado que forman una gran red de información, interconectada y disponible para cualquiera.
Especifica que al utilizar estándares abiertos se logra una compatibilidad absoluta entre todos los navegadores, garantizando precisamente el acceso universal a la información, a la vez que se hace posible la utilización de todos los recursos sin necesidad de pagar ningún costo adicional. Contrapone a esta situación el uso de patentes y Web Services propietarios, que limitan la innovación y el desarrollo.
Finalmente, en lo que respecta a neutralidad, es fundamental, según palabras del científico, que no exista por parte de los proveedores ni de los gobiernos ninguna restricción en el tráfico ni que se influencie el mismo, priorizando por ejemplo determinados sitios mientras que se dificulta el acceso a otros. A su vez, el tráfico de un cliente no debería ser inspeccionado bajo ningún punto de vista, ya que no sólo se atenta con ello contra la privacidad sino que también se influencia al cliente y se le limita la libertad.
Dentro de los ejemplos que cita Tim Berners Lee aparecen Facebook y otras redes sociales, que precisamente van en contra del acceso universal a la información por no poder compartir el contenido que se genera con otros portales. De esta manera, Facebook termina convirtiéndose en un monopolio que atrapa cada vez más a sus usuarios debido a que mucha de su producción se encuentra dentro de un lugar del que no es posible exportarla. Esto acrecienta un gran riesgo que es el de fragmentar la red de manera que se formen como islas de contenido separadas, lo que no se condice con los fundamentos principales de la web.
Hasta aquí un resumen del artículo, que es bastante extenso pero su lectura es recomendada por ser una interesante reflexión y porque quien lo escribe tiene la suficiente autoridad para que su opinión sea considerada.
Ruteo dinámico
En un post anterior se describieron las características del ruteo estático y dinámico, explicando ventajas y desventajas de cada uno. En este caso, se explicarán los diferentes tipos de ruteo dinámico y las características de cada uno. Existen fundamentalmente dos tipos de protocolos de enrutamiento dinámico: los de vector distancia y los de estado de enlace. Ambos se tratan a continuación.
Protocolos de vector distancia.
En una red donde se utiliza un protocolo de vector distancia cada dispositivo envía actualizaciones periódicas indicando una por una las redes que puede alcanzar y la métrica para llegar a ellas (es decir, cuánto le cuesta llegar a esa red). De esta manera, cada router conoce sólo a sus vecinos, las redes que puede alcanzar por medio de ellos y el costo de ir por cada vecino (en caso de existir múltiples caminos para un mismo destino). Para su funcionamiento se basan en el algoritmo de Bellman-Ford.
Por su naturaleza, los protocolos de vector distancia no tienen un conocimiento global de la topología entera de la red, lo cuál puede traer asociadas algunas dificultades como la posibilidad de bucles de ruteo. Adicionalmente, en una red de dimensiones considerables, el intercambio de información propia de estos protocolos puede generar un gran tráfico en la red. No obstante, cuentan con dos ventajas importantes: son simples en su funcionamiento lo cuál implica facilidad de configuración y detección de errores y la ejecución de su algoritmo consume pocos recursos en los routers.
Protocolos de estado de enlace.
Los protocolos de estado de enlace, por su parte, se basan para funcionar en dos bases fundamentales:
- Un conocimiento global de la red, con nodos, enlaces y los costos de los mismos.
- Un algoritmo capaz de encontrar los caminos mínimos desde un punto a cada destino.
Las ventajas de los protocolos de enrutamiento de estado de enlace es que al tener un conocimiento global de la red siempre eligen los caminos óptimos y no corren riesgos de sufrir bucles de ruteo. Además convergen de manera rápida y reaccionan de una forma mucho más veloz al detectar algún problema en la red. Otra gran ventaja es que son escalables lo que permite que sean utilizados en redes medianas y grandes, dado que algunos de ellos soportan un diseño de red jerárquico. Además suelen consumir pocos recursos de la red una vez que está funcionando y si la misma se mantiene estable.
Las mayores desventajas de estos protocolos son, por un lado, su complejidad de funcionamiento, lo que requiere que el administrador tenga un conocimiento profundo para que funcionen de forma óptima y poder resolver eventuales problemas. Los mismos utilizan el algoritmo de Dijsktra para desempeñar su función. Otra desventaja es que son bastante más demandantes en capacidad de procesamiento en comparación con los de vector distancia.
Clasificación de los protocolos más conocidos.
| Protocolo | Tipo |
| RIP | Vector distancia. |
| OSPF | Estado de enlace. |
| IS-IS | Estado de enlace. |
| EIGRP | Vector distancia (aunque se podría decir que es un híbrido, dado que tiene características de los protocolos de estado de enlace). |
| BGP | Vector de ruta. |
Bloques IPv4 libres
El pasado 12 de noviembre la IANA asignó la red 105.0.0.0/8 a AfriNIC dejando un total de sólo 11 bloques IPv4 libres en reserva de IANA. Actualmente, los mismos son:
5.0.0.0/8 23.0.0.0/8 37.0.0.0/8 39.0.0.0/8 100.0.0.0/8 102.0.0.0/8 103.0.0.0/8 104.0.0.0/8 106.0.0.0/8 179.0.0.0/8 185.0.0.0/8
Se prevee también que ARIN solicite dos bloques más durante este mes y que AfriNIC requiera otro bloque a principios del año que viene, con lo cuál el momento en que las tradicionales IPv4 se agoten parece estar muy cerca.
Bonding con Linux
Introducción
En este post se verá cómo configurar bonding en Linux para utilizar más de una placa a la vez con el objetivo de lograr agregación de enlaces y alta disponibilidad. Existen varios modos de funcionamiento de bonding que se listan debajo:
- Modo 0 (balance-rr): en este modo se utiliza una política de round-robin.
- Modo 1 (active-backup): sólo una placa funciona a la vez, el resto actúan como backup si la que está funcionando deja de hacerlo.
- Modo 2 (balance-xor): modo que soporta agregación de enlaces y tolerancia a fallos. Utiliza una política de transmisión basada en un hsh. Dicha política puede modificarse cambiando el valor del atributo xmit_hash_policy.
- Modo 3 (broadcast): envía la misma información por cada placa.
- Modo 4 (802.3ad): estándar que ajusta el bondig de forma dinámica. Requiere soporte del switch y que el mismo sea configurado.
- Modo 5 (balance-tlb): realiza balanceo de carga entre las placas sólo para la transmisión de datos.
- Modo 6 (balance-alb): realiza balanceo de carga entre las placas tanto para transmisión como para recepción de datos.
Información del módulo
Se puede consultar toda la información del módulo con el comando modinfo. Con la salida del comando puede verse el detalle de los modos en los que puede funcionar y los demás parámetros que se le pueden configurar.
root@test:~# modinfo bonding filename: /lib/modules/2.6.32-21-server/kernel/drivers/net/bonding/bonding.ko author: Thomas Davis, tadavis@lbl.gov and many others description: Ethernet Channel Bonding Driver, v3.5.0 version: 3.5.0 license: GPL srcversion: 0D992F3F7BA86233AA29838 depends: vermagic: 2.6.32-21-server SMP mod_unload modversions parm: max_bonds:Max number of bonded devices (int) parm: num_grat_arp:Number of gratuitous ARP packets to send on failover event (int) parm: num_unsol_na:Number of unsolicited IPv6 Neighbor Advertisements packets to send on failover event (int) parm: miimon:Link check interval in milliseconds (int) parm: updelay:Delay before considering link up, in milliseconds (int) parm: downdelay:Delay before considering link down, in milliseconds (int) parm: use_carrier:Use netif_carrier_ok (vs MII ioctls) in miimon; 0 for off, 1 for on (default) (int) parm: mode:Mode of operation : 0 for balance-rr, 1 for active-backup, 2 for balance-xor, 3 for broadcast, 4 for 802.3ad, 5 for balance-tlb, 6 for balance-alb (charp) parm: primary:Primary network device to use (charp) parm: lacp_rate:LACPDU tx rate to request from 802.3ad partner (slow/fast) (charp) parm: ad_select:803.ad aggregation selection logic: stable (0, default), bandwidth (1), count (2) (charp) parm: xmit_hash_policy:XOR hashing method: 0 for layer 2 (default), 1 for layer 3+4 (charp) parm: arp_interval:arp interval in milliseconds (int) parm: arp_ip_target:arp targets in n.n.n.n form (array of charp) parm: arp_validate:validate src/dst of ARP probes: none (default), active, backup or all (charp) parm: fail_over_mac:For active-backup, do not set all slaves to the same MAC. none (default), active or follow (charp)
Configuración en Debian
Ahora bien, después de haber explicado de forma básica la parte teórica y conocer el módulo de bonding, sólo restar configurarlo y ponerlo a funcionar. En Debian esta tarea es absolutamente trivial y se lleva a cabo editando el archivo /etc/network/interfaces, agregando la configuración que se ve a continuación (modificando los parámetros según las necesidades particulares). Las interfaces que intervienen en el bonding no deberían tener una configuración en el archivo mencionado.
auto bond0
iface bond0 inet static
address 192.168.10.2
netmask 255.255.255.0
network 192.168.10.0
gateway 192.168.10.1
slaves eth0 eth1
bond_mode balance-alb
bond_miimon 100
bond_downdelay 200
bond_updelay 200
Conclusión
Como se puede ver, configurar en bonding en Linux es extremadamente sencillo y puede traer grandes ventajas cuando se lo utiliza en un servidor que reciba mucho tráfico o bien que se necesite tenga una alta disponibilidad. Y los requisitos necesarios son muy fáciles de cumplir: a no ser que se quiera utilizar el modo 4, sólo basta con tener al menos dos placas en el servidor y dos puertos libres en uno o más switches.
