Este capítulo es una lista de proyectos que tienen que ver con el encaminamiento y el control de tráfico avanzados en Linux. Algunos de estos enlaces merecerían capítulos completos por sí solos, mientras que otros están muy bien documentados por sí mismos, y no necesitan más Cómos.
Las VLAN son una manera muy guay de separar sus redes de una manera más virtual que física. Puede encontrar buena información sobre las VLAN aquí. Con esta implementación, puede hacer que su máquina Linux hable VLAN con máquinas como Cisco Catalyst, 3Com: {Corebuilder, Netbuilder II, SuperStack II switch 630}, Extreme Ntwks Summit 48, Foundry: {ServerIronXL, FastIron}.
Aquí puede encontrar un gran Cómo sobre VLAN.
Actualización: incluido en el núcleo desde 2.4.14 (quizá 13).
Implementación alternativa de VLAN para Linux. Este proyecto empezó por un desacuerdo con la arquitectura y el estilo de programación del proyecto "establecido" de VLAN, lo que ha resultado en un diseño general más limpio.
Esta gente es brillante. El Linux Virtual Server es un servidor de alta escalabilidad y disponibilidad construido sobre un clúster de servidores reales, con el equilibrador de carga ejecutándose en el sistema operativo Linux. La arquitectura del clúster es transparente al usuario final. Este sólo verá un único servidor virtual.
En breve, siempre que necesite equilibrio de carga, a cualquier nivel de tráfico, LVS es el camino a seguir. ¡Algunas de sus técnicas son verdaderamente malvadas! Por ejemplo, permiten que varias máquinas tengan la misma dirección IP en el mismo segmento, pero desactivándoles ARP. Sólo la máquina LVS hace ARP, y decide cual de las máquinas posteriores deberá gestionar un paquete entrante, enviándoselo directamente a la dirección MAC correcta. El tráfico saliente se envía directamente al router, y no a través de la máquina LVS, que por tanto no necesita ver sus 5Gbit de contenido saliendo hacia el mundo, y por tanto no será un cuello de botella.
El LVS se implementa como un parche para el núcleo en Linux 2.0 y 2.2, y como módulo para Netfilter en 2.4/2.5, ¡de manera que no necesitará parches! El soporte para 2.4 aún se encuentra en principio de desarrollo, de manera que pruébelo y proporcione realimentación o parches.
Configurar CBQ puede ser un poco intimidante, especialmente si todo lo que desea es ajustar el tráfico de algunos computadores hacia un router. CBQ.init puede ayudarle a configurar Linux con una sintaxis simplificada.
Por ejemplo, si desea que todos los computadores de su subred 192.168.1.0/24 (en una eth1 10mbit) tengan limitada la velocidad de descarga a 28kbit/s, ponga esto en el fichero de configuración de CBQ.init:
DEVICE=eth1,10Mbit,1Mbit RATE=28Kbit WEIGHT=2Kbit PRIO=5 RULE=192.168.1.0/24
Use este programa siempre que no le interese el "cómo y por qué". Estamos usando CBQ.init en producción y funciona muy bien. La documentación está inscrita en el script, lo cual explica por qué no encontrará un README.
Stephan Mueller (smueller@chronox.de) wrote two useful scripts, 'limit.conn' and 'shaper'. The first one allows you to easily throttle a single download session, like this:
# limit.conn -s SERVERIP -p SERVERPORT -l LIMIT
It works on Linux 2.2 and 2.4/2.5.
The second script is more complicated, and can be used to make lots of different queues based on iptables rules, which are used to mark packets which are then shaped.
This is purely for redundancy. Two machines with their own IP address and MAC Address together create a third IP Address and MAC Address, which is virtual. Originally intended purely for routers, which need constant MAC addresses, it also works for other servers.
The beauty of this approach is the incredibly easy configuration. No kernel compiling or patching required, all userspace.
Just run this on all machines participating in a service:
# vrrpd -i eth0 -v 50 10.0.0.22
And you are in business! 10.0.0.22 is now carried by one of your servers, probably the first one to run the vrrp daemon. Now disconnect that computer from the network and very rapidly one of the other computers will assume the 10.0.0.22 address, as well as the MAC address.
I tried this over here and had it up and running in 1 minute. For some strange reason it decided to drop my default gateway, but the -n flag prevented that.
This is a 'live' fail over:
64 bytes from 10.0.0.22: icmp_seq=3 ttl=255 time=0.2 ms 64 bytes from 10.0.0.22: icmp_seq=4 ttl=255 time=0.2 ms 64 bytes from 10.0.0.22: icmp_seq=5 ttl=255 time=16.8 ms 64 bytes from 10.0.0.22: icmp_seq=6 ttl=255 time=1.8 ms 64 bytes from 10.0.0.22: icmp_seq=7 ttl=255 time=1.7 ms
Not *one* ping packet was lost! Just after packet 4, I disconnected my P200 from the network, and my 486 took over, which you can see from the higher latency.