Capítulo 34. Redes Avanzadas

Para ver la tabla de enrutamiento de un sistema FreeBSD, usa netstat(1):

Las entradas en este ejemplo son como sigue:

Se pueden ver varios atributos para cada ruta en la columna Flags. Flags Habituales de la Tabla de Enrutado resume algunos de estos flags y sus significados:

En un sistema FreeBSD, la ruta por defecto se puede configurar en /etc/rc.conf especificando la dirección IP del gateway por defecto:

También es posible añadir la ruta de forma manual usando route:

Date cuenta de que las rutas añadidas manualmente no persisten entre reinicios. Para más información sobre la manipulación manual de tablas de enrutamiento de red, consulta route(8).

Un sistema FreeBSD se puede configurar como el gateway por defecto, o router, para una red si es un sistema "dual-homed". Un sistema "dual-homed" es una máquina que está en al menos dos redes diferentes. Típicamente cada red se conecta a un interfaz de red separada, aunque se puede usar IP aliasing para enlazar múltiples direcciones, cada una en una subred diferente, a una única interfaz física.

Para que el sistema pueda reenviar paquetes entre interfaces, FreeBSD debe ser configurado como un router. Los estándares de Internet y las buenas prácticas de ingeniería evitan que el Proyecto FreeBSD active esta característica por defecto, pero se puede configurar en el arranque añadiendo esta línea a /etc/rc.conf:

Para habilitar el enrutado, establece la variable sysctl(8) net.inet.ip.forwarding a 1. Para parar el enrutado, restablece esta variable a 0.

La tabla de enrutamiento de un router necesita rutas adicionales para saber cómo llegar a otras redes. Las rutas se puede añadir manualmente utilizando rutas estáticas o se pueden aprender automáticamente usando un protocolo de enrutamiento. Las rutas estáticas son apropiadas para redes pequeñas y esta sección describe cómo añadir una ruta estática para una red pequeña.

Considera la siguiente red:

En este escenario, RouterA es una máquina FreeBSD que está actuando como un router para el resto de Internet. Tiene una ruta por defecto establecida a 10.0.0.1 que le permite conectarse con el mundo exterior. RouterB ya está configurado para utilizar 192.168.1.1 como su gateway por defecto.

Antes de añadir ninguna ruta estática, la tabla de enrutamiento de RouterA tiene este aspecto:

Con la tabla de enrutamiento actual, RouterA no tiene una ruta a la red 192.168.2.0/24. El siguiente comando añade la red Internal Net 2 a la tabla de enrutamiento de RouterA usando 192.168.1.2 para el siguiente salto:

Ahora, RouterA puede alcanzar cualquier host en la red 192.168.2.0/24. Sin embargo, la información de enrutamiento no persistirá si el sistema FreeBSD se reinicia. Si una ruta estática necesita ser persistente, añádela a /etc/rc.conf:

La variable de configuración static_routes es una lista de cadenas separadas por un espacio, donde cada cadena referencia el nombre de una ruta. La variable route_internalnet2 contiene la ruta estática para el nombre de esa ruta.

Usar más de una cadena en static_routes crea múltiples rutas estáticas. Lo siguiente muestra un ejemplo de cómo añadir rutas estáticas para las redes 192.168.0.0/24 y 192.168.1.0/24:

Cuando se asigna un espacio de direcciones a una red, el proveedor de servicio configura sus propias tablas de enrutamiento de forma que todo el tráfico para la red se enviará a través del enlace para el sitio. Pero ¿cómo saben los sitios externos que tienen que enviar sus paquetes al ISP de la red?

Hay un sistema que lleva el control de todos los espacios de direcciones asignados y define sus puntos de conexión a la red principal de Internet, o las líneas troncales que llevan el tráfico por todo el país y alrededor del mundo. Cada máquina troncal tiene una copia de un conjunto maestro de tablas, las cuales dirigen el tráfico para una red particular hacia un portador troncal específico, y de ahí bajando por la cadena de proveedores de servicio hasta que alcanza una red particular.

Es tarea del proveedor de servicio avisar a los sitios troncales de que son el punto de conexión, y por tanto el camino de entrada, para un sitio. Esto se conoce como propagación de ruta.

A veces, hay algún problema con la propagación de ruta y algunos sitios son incapaces de conectar. Quizás el comando más útil para intentar averiguar dónde se rompe la ruta es traceroute. Es útil cuando ping falla.

Cuando uses traceroute, incluye la dirección del host remoto al que conectar. La salida mostrará el gateway junto con el camino que sigue el intento, eventualmente alcanzando el destino, o terminando debido a la falta de conexión. Para más información, consulta traceroute(8).

FreeBSD soporta de forma nativa tanto aplicaciones multicast como enrutamiento multicast. Las aplicaciones multicast no necesitan ninguna configuración especial para ejecutarse en FreeBSD. El soporte para enrutamiento multicast requiere que la siguiente opción esté incluida en un kernel personalizado:

El demonio de enrutamiento multicast, mrouted se puede instalar usando el paquete o port net/mrouted. Este demonio implementa el protocolo de enrutamiento multicast DVMRP y se configura editando el fichero /usr/local/etc/mrouted.conf para configurar los túneles y DVMRP. La instalación de mrouted también instala map-mbone y mrinfo, así como sus páginas de manual. Consúltalas para ver ejemplos de configuración.

La segunda forma de utilizar WPA es con un servidor de autenticación 802.1X. En este caso, WPA se llama WPA Enterprise para diferenciarlo del WPA Personal menos seguro. La autenticación en WPA Enterprise se basa en el Extensible Authentication Protocol (EAP).

EAP no viene con un método de encriptación. En su lugar, EAP se introduce dentro de un túnel encriptado. Hay muchos métodos de autenticación EAP, pero EAP-TLS, EAP-TTLS, y EAP-PEAP son los más comunes.

EAP con Transport Layer Security (EAP-TLS) es un protocolo de autenticación inalámbrica bien soportado ya que fue el primer método EAP certificado por la Wi-Fi Alliance. EAP-TLS requiere tres certificados para funcionar: el certificado de Certificate Authority (CA) instalado en todas las máquinas, el certificado de servidor para el servidor de autenticación, y un cliente de certificado para cliente inalámbrico. En este método EAP, tanto el servidor de autenticación como el cliente inalámbrico se autentican entre sí presentando sus respectivos certificados, y luego verificando que estos certificados están firmados por la CA de la organización.

Como antes, la configuración se hace mediante /etc/wpa_supplicant.conf:

Después, añade las siguientes líneas a /etc/rc.conf:

El siguiente paso es levantar la interfaz:

También es posible levantar la interfaz manualmente utilizando wpa_supplicant(8) y ifconfig(8).

Con EAP-TLS, tanto la autenticación de servidor como la de cliente necesitan un certificado. Con EAP-TTLS, el certificado de cliente es opcional. Este método es similar a un servidor web que crea un tunel SSL seguro incluso cuando los visitantes no tienen certificados de cliente. EAP-TTLS utiliza un túnel encriptado con TLS para el transporte seguro de los datos de autenticación.

La configuración necesaria se puede añadir a /etc/wpa_supplicant.conf:

Después, añade las siguientes líneas a /etc/rc.conf:

El siguiente paso es levantar la interfaz:

Protected EAP (PEAP) se diseñó como una alternativa a EAP-TTLS y es el segundo estándar EAP más usado por detrás de EAP-TLS. En una red con sistemas operativos variados, PEAP debería ser el estándar más soportado por detrás de EAP-TLS.

PEAP es similar a EAP-TTLS ya que utiliza un certificado de servidor para autenticar clientes mediante la creación de un túnel TLS encriptado entre el cliente y el servidor de autenticación, el cual protege el subsiguiente intercambio de información de autenticación. La autenticación PEAP es diferente de EAP-TTLS ya que emite el usuario sin encriptar y sólo la contraseña se envía por el túnel TLS encriptado. EAP-TTLS utilizará el túnel TLS tanto para el nombre de usuario como para la contraseña.

Añade las siguientes líneas a /etc/wpa_supplicant.conf para configurar los parámetros relacionados con EAP-PEAP:

Añade lo siguiente a /etc/rc.conf:

Después, levanta la interfaz:

FreeBSD puede actuar como un Punto de Acceso (AP) lo que elimina la necesidad de comparar un hardware AP o montar una red ad-hoc. Esto puede ser particularmente útil cuando una máquina FreeBSD está actuando como gateway a otra red como Internet.

La pila Bluetooth en FreeBSD está implementada utilizando el framework netgraph(4). Una gran variedad de conectores USB Bluetooth se soporta con ng_ubt(4). Los dispositivos Bluetooth basados en Broadcom BCM2033 se soportan mediante los controladores ubtbcmfw(4) y ng_ubt(4). La tarjeta 3Com Bluetooth PC Card 3CRWB60-A está soportada por el controlador ng_bt3c(4). Los dispositivos serie y UART Bluetooth están soportados por sio(4), ng_h4(4), y hcseriald(8).

Antes de conectar un dispositivo, determina cuál de los controladores anteriores utiliza, después carga el controlador. Por ejemplo, si el dispositivo utiliza el controlador ng_ubt(4):

Si el dispositivo Bluetooth se va a conectar al sistema durante el arranque, éste se puede configurar para cargar el módulo durante el arranque añadiendo el controlador a /boot/loader.conf:

Una vez que el controlador está cargado, conecta el dispositivo USB. Si el controlador se cargó de forma correcta, en la consola y en /var/log/messages debería aparecer una salida similar a la siguiente:

Para iniciar y parar la pila Bluetooth, utiliza su script de arranque. Es una buena idea parar la pila después de desconectar el dispositivo. Arrancar la pila bluetooth podría necesitar que se arranque hcsecd(8). Cuando se arranca la pila, la salida debería ser similar a la siguiente:

El Host Controller Interface (HCI) proporciona un método uniforme para acceder a las capacidades de la banda base de Bluetooth. En FreeBSD, se crea un nodo HCI de netgraph para cada dispositivo Bluetooth. Para más detalles, consulta ng_hci(4).

Una de las tareas más comunes es el descubrimiento de dispositivos Bluetooth dentro del rango de proximidad de RF. Esta operación se llama inquiry (pregunta). Inquiry y otras operaciones HCI relacionadas se ejecutan con hccontrol(8). El ejemplo de abajo muestra cómo encontrar dispositivos Bluetooth que están dentro de rango. La lista de dispositivos debería mostrarse en unos pocos segundos. Ten en cuenta que un dispositivo remoto sólo contestará a la pregunta si está en modo descubrible.

BD_ADDR es la dirección única de un dispositivo Bluetooth, similar a la dirección MAC de una tarjeta de red. Esta dirección es necesaria para la comunicación posterior con el dispositivo y es posible asignarle un valor que se amigable de leer. Hay información acerca de los hosts Bluetooth conocidos en /etc/bluetooth/hosts. El siguiente ejemplo muestra cómo obtener un nombre legible por las personas que ha sido asignado a un dispositivo remoto:

Si se realiza una pregunta a un dispositivo Bluetooth remoto, encontrará tu ordenador como "your.host.name (ubt0)". El nombre asignado al dispositivo local se puede cambiar en cualquier momento.

Se puede asignar alias a los dispositivos remotos en /etc/bluetooth/hosts. Se puede encontrar más información acerca de /etc/bluetooth/hosts en bluetooth.hosts(5).

El sistema Bluetooth proporciona conexión punto a punto entre dos unidades Bluetooth, o punto a multipunto que se comparte entre varios dispositivos Bluetooth. El siguiente ejemplo muestra cómo crear una conexión con un dispositivo remoto:

create_connection acepta BT_ADDR así como los alias encontrados en /etc/bluetooth/hosts.

El siguiente ejemplo muestra cómo obtener la lista de conexiones activas en la banda base para el dispositivo local:

Un manejador de conexión es útil cuando se requiere la terminación de una conexión de la banda base, aunque normalmente no es necesario hacer esto a mano. La pila terminará automáticamente las conexiones de banda base inactivas.

Teclea hccontrol help para obtener un listado completo de los comandos HCI disponibles. La mayoría de los comandos HCI no requieren privilegios de súper usuario.

Por defecto, la comunicación Bluetooth no está autenticada, y cualquier dispositivo puede hablar con cualquier otro. Un dispositivo Bluetooth, como un teléfono móvil, podría decidir requerir autenticación para proporcionar un servicio particular. La autenticación Bluetooth se hacer normalmente con un código PIN, una cadena ASCII de hasta 16 caracteres. Se requiere que el usuario introduzca el mismo código PIN en ambos dispositivos. Una vez que el usuario ha introducido el código PIN, ambos dispositivos generarán una clave de enlace. Después de eso, la clave de enlace se puede almacenar en los dispositivos o en almacenamiento persistente. La siguiente vez, ambos dispositivos utilizarán las claves de enlace generadas previamente. Este procedimiento se llama emparejamiento. Ten en cuenta que si alguno de los dispositivos pierde la clave de enlace, se tiene que repetir el emparejamiento.

El demonio hcsecd(8) es el responsable de manejar las peticiones de autenticación Bluetooth. El fichero de configuración por defecto es /etc/bluetooth/hcsecd.conf. A continuación se muestra un ejemplo de sección para un teléfono móvil con el PIN establecido a 1234:

La única limitación de los códigos PIN es la longitud. Algunos dispositivos, como los auriculares Bluetooth, podrían tener un código PIN fijo de fábrica. La opción -d fuerza a hcsecd(8) a permanecer en primer plano, de forma que es fácil ver lo que está pasando. Establece el dispositivo remoto para que reciba emparejamientos e inicia la conexión Bluetooth con el dispositivo remoto. El dispositivo remoto debería indicar que el emparejamiento ha sido aceptado y solicitar el código PIN. Introduce el mismo código PIN listado en hcsecd.conf. Ahora el ordenador y el dispositivo remoto están emparejados. De forma alternativa, el emparejamiento puede ser iniciado por el dispositivo remoto.

Se puede añadir la siguiente línea a /etc/rc.conf para configurar que hcsecd(8) arranque automáticamente cuando se inicia el sistema:

Lo siguiente es una muestra de la salida del demonio hcsecd(8):

Es posible utilizar un perfil DUN (Dial-Up Networking) para configurar un teléfono móvil como un módem inalámbrico para conectarse a un servidor de acceso a Internet. También se puede utilizar para configurar un ordenador para recibir llamadas de datos desde un teléfono móvil.

Se puede usar el acceso a la red mediante un perfil PPP para proporcionar acceso LAN para uno o varios dispositivos Bluetooth. También puede proporcionar conexión PC a PC usando PPP sobre emulación de cable serie.

En FreeBSD, estos perfiles se implementan con ppp(8) y el adaptador rfcomm_pppd(8) que convierte la conexión Bluetooth en algo que PPP puede usar. Antes de que se pueda usar el perfile, se debe crear una nueva etiqueta PPP en /etc/ppp/ppp.conf. Consulta rfcomm_pppd(8) para ver ejemplos.

En este ejemplo, se usa rfcomm_pppd(8) para abrir una conexión con un dispositivo remoto con un BD_ADDR de 00:80:37:29:19:a4 en un canal DUNRFCOMM:

El número de canal real se obtendrá del dispositivo remoto usando el protocolo SDP. Es posible especificar el canal RFCOMM a mano, y en este caso rfcomm_pppd(8) no realizará la consulta SDP. Usa sdpcontrol(8) para averiguar el canal RFCOMM en el dispositivo remoto.

Para proporcionar acceso a la red con el servicio PPPLAN, se debe estar ejecutando sdpd(8) y se tienen que crear una nueva entrada para clientes LAN en /etc/ppp/ppp.conf. Consulta rfcomm_pppd(8) para ver ejemplos. Finalmente, arrancar el servidor RFCOMMPPP en un número de canal RFCOMM válido. El servidor RFCOMMPPP registrará automáticamente el servicio LAN Bluetooth con el demonio SDP local. El ejemplo de abajo muestra cómo arrancar el servidor RFCOMMPPP.

Esta sección proporciona un resumen de varios protocolos Bluetooth, sus funciones, y sus utilidades asociadas.

Por defecto, cuando FreeBSD está aceptando una nueva conexión, intenta realizar un cambio de roles y convertirse en maestro. Algunos dispositivos Bluetooth más antiguos que no soportan el cambio de roles no serán capaces de conectar. Puesto que el cambio de roles se realiza cuando se establece una nueva conexión, no es posible preguntar al dispositivo remoto si soporta el cambio de roles. Sin embargo, hay una opción HCI para deshabilitar el intercambio de roles en el lado local:

Para mostrar paquetes Bluetooht, usa el paquete de terceros hcidump, que se puede instalar mediante el paquete o port comms/hcidump. Esta utilidad es similar a tcpdump(1) y se puede usar para mostrar el contenido de los paquetes Bluetooth en el terminal y para volcarlos a un fichero.

En FreeBSD, if_bridge(4) es un módulo del kernel que se carga automáticamente cuando ifconfig(8) crea un interfaz bridge. También es posible compilar soporte para bridge en un kernel personalizado añadiendo device if_bridge al fichero de configuración del kernel personalizado.

El bridge se crea clonando una interfaz. Para crear la interfaz bridge:

Cuando se crea una interfaz bridge, se le asigna automáticamente una dirección Ethernet generada de forma aleatoria. Los parámetros maxaddr y timeout controlan cuántas direcciones MAC puede mantener el bridge en su tabla de reenvío y cuántos segundos deben pasar para eliminarla desde la última vez que han sido vistas. Los otros parámetros controlan cómo opera STP.

Después, especifica qué interfaces de red añadir como miembros del bridge. Para que el bridge sea capaz de reenviar paquetes, todas las interfaces y el bridge necesitan estar levantadas:

El puente ahora puede reenviar tramas Ethernet entre fxp0 y fxp1. Añade las siguientes líneas a /etc/rc.conf de forma que el bridge se cree al arrancar:

Si la máquina bridge necesita una dirección IP, establécela en la interfaz del bridge, no en las interfaces que son miembro. La dirección puede establecerse estáticamente o vía DHCP. Este ejemplo establece una dirección IP estática:

También es posible establecer una dirección IPv6 al interfaz del bridge. Para hacer los cambios permanentes, añade la información de la dirección a /etc/rc.conf.

Para que una red Ethernet funcione adecuadamente, sólo debe existir un camino activo entre dos dispositivos. El protocolo STP detecta bucles y pone enlaces redundantes en un estado bloqueado. Si uno de los enlaces activos fallara, STP calcula un árbol diferente y activa uno de los caminos bloqueados para restaurar la conectividad a todos los puntos de la red.

El protocolo Rapid Spanning Tree (RSTP o 802.1w) proporciona compatibilidad hacia atrás con el STP antiguo. RSTP proporciona una convergencia más rápida e intercambia información con switches vecinos para transicionar rápidamente a modo reenvío sin crear bycles. FreeBSD soporta como modos de operación RSTP y STP, siendo RSTP el modo por defecto.

Se puede activar STP en las interfaces miembro usando ifconfig(8). Para un bridge con fxp0 y fxp1 como interfaces actuales, activa STP con:

Este bridge tiene un spanning tree con un ID de 00:01:02:4b:d4:50 y una prioridad de 32768. Como el root id es el mismo, eso indica que es el bridge raíz del árbol.

Otro bridge en la red tiene STP activado:

La línea root id 00:01:02:4b:d4:50 priority 32768 ifcost 400000 port 4 muestra que el bridge raíz es 00:01:02:4b:d4:50 y que tiene un camino con coste 400000 desde este bridge. La ruta al brige raíz es vía port 4 que es fxp0.

Varios parámetros de ifconfig son únicos de las interfaces del bridge. Esta sección resume algunos casos comunes para estos parámetros. ifconfig(8) describe la lista completa de parámetros disponibles.

Las interfaces del bridge también soportan modo monitor, donde los paquetes son descartados después de haber sido procesados por bpf(4) y no se procesan más ni se reenvían. Esto se puede usar para multiplexar la entrada de dos o más interfaces en un único flujo bpf(4). Esto es útil para reconstruir el tráfico de redes que transmiten las señales RX/TX hacia fuera usando dos interfaces separadas. Por ejemplo, para leer la entrada desde cuatro interfaces de red como un único flujo:

El interfaz bridge y los parámetros STP se pueden monitorizar con bsnmpd(1) que se incluye con el sistema base FreeBSD. Las MIBs del bridge exportadas siguen el estándar IETF de forma que se puede usar cualquier cliente SNMP o paquete de monitorización para recuperar los datos.

Para habilitar la monitorización en el bridge, descomenta esta línea en /etc/snmpd.config eliminando el símbolo # al comienzo:

Podría ser necesario modificar en este fichero otros valores de configuración, como los nombres de la comunidad y listas de acceso. Consulta bsnmpd(1) y snmp_bridge(3). Una vez guardados los cambios, añade esta línea a /etc/rc.conf:

Después, arranca bsnmpd(1):

Los siguientes ejemplos usan el software Net-SNMP (net-mgmt/net-snmp) para consultar un bridge desde un sistema cliente. También se puede usar el port net-mgmt/bsnmptools. Desde el cliente SNMP que está ejecutando Net-SNMP, añade las siguientes líneas a $HOME/.snmp/snmp.conf para importar las definiciones MIB del bridge:

Para monitorizar un sólo bridge usando IETF BRIDGE-MIB (RFC4188):

El valor dot1dStpTopChanges.0 es dos, lo que indica que la topología STP ha cambiado dos veces. Un cambio de topología significa que uno o más enlaces en la red han cambiado o fallado y se ha tenido que calcular un nuevo árbol. El valor dot1dStpTimeSinceTopologyChange.0 mostrará cuándo sucede esto.

Para monitorizar múltiples interfaces del bridge, se puede usar el BEGEMOT-BRIDGE-MIB privado:

Para cambiar la interfaz del bridge que está siendo monitorizada mediante el subárbol mib-2.dot1dBridge:

Esta sección muestra cómo configurar un switch Cisco® y un sistema FreeBSD para hacer balanceado de carga LACP. Después muestra cómo configurar dos interfaces Ethernet en modo failover así como cómo configurar el modo failover entre una interfaz Ethernet y otra inalámbrica.

Las pasos que se muestran en esta sección configuran los servidores NFS y TFTP incluidos. La siguiente sección muestra cómo instalar y configurar el servidor DHCP. En este ejemplo, el dirección que contendrá los ficheros usados por los usuarios PXE es /b/tftpboot/FreeBSD/install. Es importante que este directorio exista y que el nombre del directorio esté configurado tanto en /etc/inetd.conf como en /usr/local/etc/dhcpd.conf.

Cuando se arranca desde un volumen raíz NFS, /etc/rc detecta el arranque NFS y ejecuta /etc/rc.initdiskless. En este caso se necesita que /etc y /var estén cargados den memoria de forma que estos directorios sean escribibles pero el directorio raíz NFS sea de sólo escritura:

Cuando el sistema arranca, los sistemas de fichero en memoria para /etc y /var se crearán y montarán y el contenido de los ficheros cpio.gz se copiará dentro de ellos. Por defecto, estos sistemas de ficheros tienen una capacidad máxima de 5 megabytes. Si tus archivos no caben, que es habitualmente el caso para /var cuando se han instalado paquetes binarios, solicita más tamaño poniendo el número de sectores de 512 bytes necesarios (por ejemplo, 5 megabytes es 10240 sectores) en ${NFSROOTDIR}/conf/base/etc/md_size y ${NFSROOTDIR}/conf/base/var/md_size para los sistemas de ficheros /etc y /var respectivamente.

El servidor DHCP no necesita estar en la misma máquina que los servidores de TFTP y NFS, pero necesita estar accesible en la red.

DHCP no es parte del sistema base de FreeBSD pero se puede instalar usando el port o paquete net/isc-dhcp44-server.

Una vez instalado, edita el fichero de configuración, /usr/local/etc/dhcpd.conf. Configura las opciones next-server, filename, y root-path como se ve en este ejemplo:

La directiva next-server se usa para especificar la dirección IP del servidor TFTP.

La directiva filename define la ruta a /boot/pxeboot. Se usa un nombre de fichero relativo, lo que significa que /b/tftpboot no está incluido en la ruta.

La opción root-path define la ruta al sistema de ficheros raíz NFS.

Una vez salvados los cambios, activa DHCP durante el arranque añadiendo la siguiente línea a /etc/rc.conf:

Después inicia el servicio DHCP:

Una vez que todos los servicios están configurados y arrancados, los clientes PXE deberían ser capaces de cargar automáticamente FreeBSD a través de la red. Si un cliente particular no es capaz de conectar, cuando ese cliente arranque, entra en el menú de configuración de la BIO y confirma que está configurado para arrancar desde la red.

Esta sección describe algunos consejos para resolución de problemas para aislar la fuente del problema de configuración si los clientes no fueran capaces de arrancar mediante PXE.

Activa el soporte de CARP en el arranque añadiendo una entrada para el módulo del kernel carp.ko en /boot/loader.conf:

Para cargar el módulo ahora sin reiniciar:

Para los usuarios que prefieren usar un kernel personalizado, incluye la siguiente línea en el fichero de configuración del kernel personalizado y compila como se describe en Configurando el Kernel de FreeBSD:

El nombre de host, dirección IP de gestión y su máscara de subred, la dirección IP compartida, y el VHID se configuran añadiendo entradas en /etc/rc.conf. Este ejemplo es para hosta.example.org:

El siguiente conjunto de entradas es para hostb.example.org. Puesto que representa un segundo maestro, utiliza una dirección IP compartida y VHID diferentes. Sin embargo, la contraseña especificada con pass debe ser idéntica ya que CARP sólo escuchará y aceptará notificaciones de las máquinas que tengan la contraseña correcta.

La tercer máquina, hostc.example.org, está configurada para manejar el failover de cualquiera de los maestros. Esta máquina está configurada con dos CARPVHIDS, uno para manejar cada dirección IP virtual de cada host maestro. El desvío de notificaciones CARP, advskew, está configurado para asegurar que el host de respaldo notifica más tarde que el maestro, puesto que advskew controla el orden de precedencia cuando hay varios servidores de reemplazo.

Tener dos CARPVHIDs configurados significa que hostc.example.org se dará cuenta si alguno de los maestros no se encuentra disponible. Si un maestro no es capaz de notificar antes que el servidor de reemplazo, el servidor de reemplazo usará la dirección IP compartida hasta que el maestro esté disponible de nuevo.

Una vez completada la configuración, reinicia la red o reinicia cada sistema. Ahora la alta disponibilidad está habilitada.

La funcionalidad CARP se puede controlar mediante varias variables de sysctl(8) que están documentadas en las páginas de manual carp(4). Se pueden disparar otras acciones a partir de eventos CARP usando devd(8).

La configuración para estas versiones de FreeBSD es similar a la descrita en la sección previa, excepto que se tiene que crear primero un dispositivo CARP y hacer referencia a él en la configuración.

Activa el soporte de CARP al arrancar cargando el módulo del kernel if_carp.ko en /boot/loader.conf:

Para cargar el módulo ahora sin reiniciar:

Para los usuarios que prefieren usar un kernel personalizado, incluye la siguiente línea en el fichero de configuración del kernel personalizado y compila como se describe en Configurando el Kernel de FreeBSD:

Después, en cada host, crea un dispositivo CARP:

Establece el nombre de host, dirección IP de gestión, dirección IP compartida, y VHID añadiendo las líneas necesarias a /etc/rc.conf. Puesto que se usa un dispositivo CARP virtual en lugar de un alias, se usa la máscara de subred /24 en lugar de /32. Aquí están las entradas para hosta.example.org:

En hostb.example.org:

La tercera máquina, hostc.example.org, se configura para manejar el failover de cualquiera de los hosts maestros:

Una vez completada la configuración, reinicia la red o reinicia cada sistema. Ahora la alta disponibilidad está habilitada.