# rm-rf.es | Administración de sistemas

Bitácora personal de un SysAdmin Gnu/Linux, Windows, BSD...

Bonding/Teaming/Trunking en RHEL y CentOS

bonding linux

El Bonding (también conocido como teaming, y en switching como trunking) es, básicamente, la unión de varias interfaces de red para que trabajen como una única interfaz lógica. Esta configuración permite establecer configuraciones de activo-pasivo, balanceo de carga o crear un agregado de interfaces con un ancho de banda que supone la suma del de todas las interfaces asignadas.

Antes de comenzar la configuración, nos aseguramos de tener cargado el módulo bonding:

# lsmod | grep bonding
bonding               109558  0
ipv6                  264641  29 bonding,ip6t_REJECT,nf_conntrack_ipv6,nf_defrag_ipv6,cnic

En caso de no estar lo cargamos:

# modprobe bonding

Tenemos que configurar unos parámetros de kernel para añadir esta nueva interfaz/funcionalidad:

# vi /etc/modprobe.conf
alias bond0 bonding
options bond0 mode=6 miimon=100

El valor mode, especificado en 6 indica que el tipo de bonding va a ser de balanceo de carga. Los posibles valores son de 0 a 6:

  • 0: round robin policy, defecto
  • 1: active backup policy
  • 2: XOR
  • 3: brodcast
  • 4: 802.3ad
  • 5:  balance-tlb
  • 6:  balance-alb

El valor miimon indica con un valor entero la frecuencia de monitorización del link. Para conocer todos estos parámetros en condiciones os recomiendo revisar la documentación del kernel sobre bonding

Ahora vamos a crear el fichero de configuración para la interfaz Bond0, que será la que en nuestro caso creará el bonding de eth0 y eth1. El fichero de configuración se crea en la misma ruta que el resto /etc/sysconfig/network-scripts/ifcfg-XXX. Este fichero es el que contendrá la configuración IP, NETMASK, etc.

# vim /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
ONBOOT=yes
IPADDR=192.168.1.190
NETMASK=255.255.255.0
BROADCAST=192.168.1.255
NETWORK=192.168.1.0
USERCTL=no
BOOTPROTO=none

Ahora configuramos eth0 y eth1, en ellas no establecemos ninguna configuración IP, sino que especificamos que es una interfaz esclavo (slave) y que su master es bond0:

vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
USERCTL=no
BOOTPROTO=none
MASTER=bond0
SLAVE=yes
vi /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
ONBOOT=yes
USERCTL=no
BOOTPROTO=none
MASTER=bond0
SLAVE=yes

Una vez configurado, reiniciamos el servicio de red:

# /etc/init.d/network restart

Si todo ha ido bien ya veremos la interfaz bond0 en ifconfig:

# ifconfig
bond0     Link encap:Ethernet  HWaddr 08:00:27:00:C8:7A
          inet addr:192.168.1.190  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe00:c87a/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:1029 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1198 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:101972 (99.5 KiB)  TX bytes:182347 (178.0 KiB)

eth0      Link encap:Ethernet  HWaddr 08:00:27:00:C8:7A
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:946 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1144 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:90003 (87.8 KiB)  TX bytes:175136 (171.0 KiB)
          Interrupt:11 Base address:0xc020 

eth1      Link encap:Ethernet  HWaddr 08:00:27:00:C8:7A
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:94 errors:0 dropped:0 overruns:0 frame:0
          TX packets:59 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:12695 (12.3 KiB)  TX bytes:8325 (8.1 KiB)
          Interrupt:10 Base address:0xc060 

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1241 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1241 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:170253 (166.2 KiB)  TX bytes:170253 (166.2 KiB)

Podemos monitorizar el estado del bonding desde /proc/net/bonding/bond0:

# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)

Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth0
MII Status: up
Speed: 100 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:00:c8:7a
Slave queue ID: 0

Slave Interface: eth1
MII Status: up
Speed: 100 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:fd:48:08
Slave queue ID: 0

Múltiples VLAN por interfaz en Windows Server

broadcom advanced control suiteDe forma nativa (que yo sepa) Windows Server no ofrece la posibilidad de configurar múltiples VLAN por interfaz de red. Esto nos obliga a recurrir a las utilidades que el fabricante del dispositivo de red nos facilite.

Broadcom por ejemplo nos ofrece la utilidad “Broadcom Advanced Control Suite” que nos permite, además de crear VLANs virtuales, hacer balanceo de carga o Ethernet bonding. Podéis leer la guía de utilización en este enlace y descargar la suite desde el sitio web de Broadcom. Por supuesto se presupone que la configuración de red en los switches para las VLAN (trunk, etc) es la correcta. En el caso de esta utilidad, todo se puede configurar a través de los asistentes de forma gráfica y/o en modo experto así que no tiene demasiada complejidad.

Básicamente, primero se crea un Team, se le asignan las intefaces de red que queramos y a partir de ahí se configuran las VLAN virtuales, el balanceo de carga o lo que necesitemos. Una vez finalizado el asistente, si hemos creado VLAN virtuales, los nuevos dispositivos virtuales aparecerán en el centro de redes de Windows, donde podremos asignarle la IP correspondiente como si un dispositivo estándar se tratara.

Si necesitáis este tipo de configuraciones no perdáis el tiempo e id a buscar directamente las utilidades del proveedor de las tarjetas de red.

Configurar una VLAN en Linux con vconfig

La forma más conocida de configurar una VLAN en Linux es la de copiar el fichero de configuración de la interfaz y añadir/cambiar ciertos parámetros, ejemplo en RHEL asumiendo el ID 80 para la VLAN:

# cp -p /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0.80
# vim /etc/sysconfig/network-scripts/ifcfg-eth0.80
    # Añadimos:
    VLAN=yes
    # Cambiamos el dispositivo:
    DEVICE=eth0.80
# /etc/init.d/network restart

El comando vconfig nos simplifica un poco la tarea de gestionar una o varias VLAN. Para el ejemplo anterior, sería tan sencillo como:

# vconfig add eth0 80
Added VLAN with VID == 80 to IF -:eth0:-

Ya tenemos la interfaz creada:

# ifconfig eth0.80
eth0.80   Link encap:Ethernet  HWaddr 08:00:27:E7:48:CC
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Podemos ver información detallada sobre ella en /proc/net/vlan/:

# cat /proc/net/vlan/eth0.80
eth0.80  VID: 80	 REORDER_HDR: 1  dev->priv_flags: 1
         total frames received            0
          total bytes received            0
      Broadcast/Multicast Rcvd            0

      total frames transmitted            0
       total bytes transmitted            0
            total headroom inc            0
           total encap on xmit            0
Device: eth0
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings:

Podríamos asignarle la IP con el comando ifconfig:

# ifconfig eth0.80 192.168.1.222 netmask 255.255.255.0

Y si quisiéramos eliminar la interfaz:

# ifconfig eth0.80 down && vconfig rem eth0.80

Recordad que tiene que estar cargado en el kernel el módulo 8021q:

# lsmod | grep 8021q
8021q                  19491  0
garp                    5901  1 8021q

En fin, ¡para gustos los colores!

Routing Tables: ‘netstat -rn’ y ‘route -n’

Algo importante en los sistemas Linux (o Unix) y todo lo relacionado con networking es conocer el estado y configuración de las tablas de rutas IP (routing tables), que nos indican cómo y a través de donde se envía un paquete en las distintas redes.

Para visualizar la tabla de rutas tenemos dos posibilidades, utilizar el comando netstat -rn o route -n, ambos nos ofrecen la misma salida:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth0

Las tres primeras columnas nos indican, por un lado las redes de destino (Destination), la puerta de enlace que utilizan (Gateway) y la máscara de red (Genmask). En las Flags vemos “U”, que significa que la interfaz de red está levantada y G que indica que esa ruta utiliza la puerta de enlace. 0.0.0.0 es tratado como un wildcard (también se suele representar con un *) y especifica el destino a cualquier red no especificada.

Explicando la salida del comando route anterior, vemos en primer lugar que todo paquete dirigido a las redes 192.168.1.0/255.255.255.0 y 169.254.0.0/255.255.0.0 serán enviados a través de redes LAN (vemos que no hay flag de gateway) por lo que no harán uso de puerta de enlace. En cambio todo paquete con destino 0.0.0.0, es decir, el resto de redes sí que pasará por nuestra puerta de enlace 192.168.1.1. Todas estas rutas trabajan bajo la interfaz de red eth0, si tuviéramos más interfaces levantadas aparecerían marcadas como ethX en la columna Iface.

GNS3: simulador gráfico de redes

Para todos aquellos que necesitéis crear entornos de redes virtuales, topologías de red complejas y además tener la posibilidad de integrarlos con simuladores de IOS (Dynamips/Dynagen) y entornos de virtualización (Quemu, emulador de PIX.GNS3), GNS3 os puede ser de gran utilidad.

La instalación en Debian/Ubuntu y otras distro Linux es sencilla, la hacéis por gestor de paquetes:

$ sudo apt-get install gns3

Una vez arrancada la aplicación tenéis un asistente que os permite subir las imágenes IOS que dispongáis (podéis encontrarlas buscando por Google) y comenzar a trabajar. Simplemente se trata de crear la topología de red arrastrando elementos al cuadro central y configurarlos. Posteriormente se pueden arrancar/parar, acceder por consola, etc.

Si estás en proceso de pasar un CCNA, CCNP, CCIE o similar, o simplemente quieres tener la posibilidad de crear entornos de red sin necesidad de adquirir hardware costoso, esta es tu oportunidad.

GNS3

Consola IOS GNS3

Encapsular tráfico a través de un tunel cifrado con SSH

Hoy vamos a ver como conseguir establecer conexiones cifradas mediante SSH (Openssh) a protocolos/servicios que no están sirviendo su tráfico encriptado. La mayoría de vosotros sabréis que es sencillo “esnifar” el tráfico dentro de una misma red, gracias a este encapsulamiento de tráfico (que es muy sencillo) podemos cifrar el tráfico entre dos equipos independientemente de que el servicio lo ofrezca sin ningún tipo de cifrado. Eso sí, hay que tener conexión vía ssh al servidor destino.

Vamos a verlo con ejemplos ya que resulta más sencilla la explicación de este modo. Pongamos el caso de que queremos conectar de forma segura al sitio web http://test.com. Este sitio web no sirve el contenido por protocolo seguro así que todo el tráfico se podrá visualizar sin problemas desde cualquier equipo de esta red local, por ejemplo con el programa Wireshark (analizador de protocolos de red) lo podemos verificar.

Primero accedemos directamente desde el navegador desde http://test.com, el analizador de tráfico muestra todos los paquetes de información sin cifrar:

whireshark

Ahora, lo que vamos a hacer es crear un tunel de cifrado entre las dos máquinas. Utilizaremos el puerto local 9999 para servir el contenido que previamente encapsulamos por conexión segura desde el servidor que sirve todos los datos (test.com). Para ello creamos una conexión SSH al servidor destino y creamos un tunel entre nuestro puerto 9999 local y el puerto remoto 80 (http):

# ssh alex@test.com -L 9999:pruebas.com:80 -N

Nota: si queréis que el proceso quede en segundo plano y no aparezca la shell ssh en la consola debéis usar el parámetro

-f

.

-N

hace que no se puedan ejecutar comandos SSH en el servidor remoto.

Ahora, podemos acceder al mismo sitio web (http://test.com) desde nuestro equipo, de forma local a través del puerto 9999. Simplemente ponemos en el navegador:

http://localhost:9999

Vemos que efectivamente, al acceder de este modo estamos sirviendo el mismo contenido pero esta vez completamente cifrado:

whireshark cifrado

Una vez conocida la sintaxis del tunneling (

man ssh

) podemos aplicar este mismo recurso a cualquier otro servicio (http, ftp, smtp, pop).

Como información extra os dejo una excelente explicación de Tunel SSH poor parte de la Wikipedia:

El protocolo SSH (secure shell) se utiliza con frecuencia para tunelizar tráfico confidencial sobre Internet de una manera segura. Por ejemplo, un servidor de ficheros puede compartir archivos usando el protocolo SMB (Server Message Block), cuyos datos no viajan cifrados. Esto permitiría que una tercera parte, que tuviera acceso a la conexión (algo posible si las comunicaciones se realizan en Internet) pudiera examinar a conciencia el contenido de cada fichero trasmitido.
Para poder montar el sistema de archivo de forma segura, se establece una conexión mediante un túnel SSH que encamina todo el tráfico SMB al servidor de archivos dentro de una conexión cifrada SSH. Aunque el protocolo SMB sigue siendo inseguro, al viajar dentro de una conexión cifrada se impide el acceso al mismo.
Por ejemplo, para conectar con un servidor web de forma segura, utilizando SSH, haríamos que el cliente web, en vez de conectarse al servidor directamente, se conecte a un cliente SSH. El cliente SSH se conectaría con el servidor tunelizado, el cual a su vez se conectaría con el servidor web final. Lo atractivo de este sistema es que hemos añadido una capa de cifrado sin necesidad de alterar ni el cliente ni el servidor web.

Redirigir tráfico entre puertos TCP con tcptunnel

Tcptunnel permite redirigir tráfico desde un puerto TCP a otro, escuchando en el puerto local y redirigiendo todo el tráfico hacia el puerto remoto que le indiquemos.

Tcptunnel puede ser utilizado con protocolos basados en TCP como HTTP, SMTP, POP, IRC, etc. y ha sido probado en GNU/Linux, FreeBSD, Solaris, HP-UX, Windows XP y Windows Server 2008.

Personalmente lo he probado entre dos máquinas CentOS y por el momento ha funcionado de forma correcta. En breve lo usaré en “producción” así que esperaremos a ver que tal. Os dejo unos ejemplos de utilización y su instalación.

Instalación

# wget http://www.vakuumverpackt.de/tcptunnel/tcptunnel-0.2.tar.gz
# tar -xzvf tcptunnel-0.2.tar.gz
# cd tcptunnel-0.2
# ./configure --install-dir=/usr/local/bin
# make
# make install

Ejemplos de uso

En este ejemplo queremos redirigir todo el tráfico SMTP local contra el puerto SMTP de la máquina remota 192.168.0.100:

# tcptunnel --local-port=25 --remote-port=25 --remote-host=192.168.0.100 --stay-alive

En este ejemplo redirigimos el tráfico POP local (puerto 110) contra el puerto 111 del equipo remoto 192.168.0.100:

# tcptunnel --local-port=110 --remote-port=111 --remote-host=192.168.0.100 --stay-alive

En este ejemplo redirigimos el tráfico HTTP local (puerto 80) contra el puerto 80 del equipo remoto 192.168.0.100:

# tcptunnel --local-port=80 --remote-port=80 --remote-host=192.168.0.100 --stay-alive

Modo de uso:

# tcptunnel --help
Usage: tcptunnel [options]

Options:
  --version
  --help               this help

  --local-port=PORT    port to redirect
  --remote-port=PORT   target port
  --remote-host=HOST   target host

  --stay-alive
  --log-to-stdout

Si alguien conoce una forma más óptima de hacerlo, ¡soy todo oídos!

Cómo montar un servidor DHCP

Esta es una forma sencilla de instalar y configurar un servidor DHCP en una máquina Linux (Red-Hat, CentOS, Fedora). Voy a mostraros los pasos para hacerlo y una configuración básica para hacer funcionar el equipo como servidor DHCP.

DHCP (sigla en inglés de Dynamic Host Configuration Protocol – Protocolo Configuración Dinámica de Servidor) es un protocolo de red que permite a los nodos de una red IP obtener sus parámetros de configuración automáticamente. Se trata de un protocolo de tipo cliente/servidor en el que generalmente un servidor posee una lista de direcciones IP dinámicas y las va asignando a los clientes conforme éstas van estando libres, sabiendo en todo momento quién ha estado en posesión de esa IP, cuánto tiempo la ha tenido y a quién se la ha asignado después. (Wikipedia)

En primera instancia, instalamos el paquete necesario vía yum:

yum install dhcp.i586

Una vez instalado, podemos utilizar como base para el fichero de configuración el que nos ofrecen con la instalación. Incorpora comentarios sobre cada una de las opciones y configuraciones para hacer más sencilla la puesta en marcha del servicio:

cp /usr/share/doc/dhcp-4.1.0p1/dhcpd.conf.sample /etc/dhcp/dhcp.conf

El fichero de ejemplo es el siguiente:

# dhcpd.conf
#
# Sample configuration file for ISC dhcpd
#

# option definitions common to all supported networks...
option domain-name "example.org";
option domain-name-servers ns1.example.org, ns2.example.org;

default-lease-time 600;
max-lease-time 7200;

# Use this to enble / disable dynamic dns updates globally.
#ddns-update-style none;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
#authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.

subnet 10.152.187.0 netmask 255.255.255.0 {
}

# This is a very basic subnet declaration.

subnet 10.254.239.0 netmask 255.255.255.224 {
 range 10.254.239.10 10.254.239.20;
 option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
}

# This declaration allows BOOTP clients to get dynamic addresses,
# which we don't really recommend.

subnet 10.254.239.32 netmask 255.255.255.224 {
 range dynamic-bootp 10.254.239.40 10.254.239.60;
 option broadcast-address 10.254.239.31;
 option routers rtr-239-32-1.example.org;
}

# A slightly different configuration for an internal subnet.
subnet 10.5.5.0 netmask 255.255.255.224 {
 range 10.5.5.26 10.5.5.30;
 option domain-name-servers ns1.internal.example.org;
 option domain-name "internal.example.org";
 option routers 10.5.5.1;
 option broadcast-address 10.5.5.31;
 default-lease-time 600;
 max-lease-time 7200;
}

# Hosts which require special configuration options can be listed in
# host statements.   If no address is specified, the address will be
# allocated dynamically (if possible), but the host-specific information
# will still come from the host declaration.

host passacaglia {
 hardware ethernet 0:0:c0:5d:bd:95;
 filename "vmunix.passacaglia";
 server-name "toccata.fugue.com";
}

# Fixed IP addresses can also be specified for hosts.   These addresses
# should not also be listed as being available for dynamic assignment.
# Hosts for which fixed IP addresses have been specified can boot using
# BOOTP or DHCP.   Hosts for which no fixed address is specified can only
# be booted with DHCP, unless there is an address range on the subnet
# to which a BOOTP client is connected which has the dynamic-bootp flag
# set.
host fantasia {
 hardware ethernet 08:00:07:26:c0:a5;
 fixed-address fantasia.fugue.com;
}

# You can declare a class of clients and then do address allocation
# based on that.   The example below shows a case where all clients
# in a certain class get addresses on the 10.17.224/24 subnet, and all
# other clients get addresses on the 10.0.29/24 subnet.

class "foo" {
 match if substring (option vendor-class-identifier, 0, 4) = "SUNW";
}

shared-network 224-29 {
 subnet 10.17.224.0 netmask 255.255.255.0 {
   option routers rtr-224.example.org;
 }
 subnet 10.0.29.0 netmask 255.255.255.0 {
   option routers rtr-29.example.org;
 }
 pool {
   allow members of "foo";
   range 10.17.224.10 10.17.224.250;
 }
 pool {
   deny members of "foo";
   range 10.0.29.10 10.0.29.230;
 }
}

Veréis que es un fichero con muchísimas opciones, os dejo un ejemplo más sencillo. En el siguiente dhcp.conf utilizamos la interfaz de red eth0 para las tareas de DHCP, esta interfaz tiene configurada la red 192.168.0.0/24 (subnet), sobre la cual vamos a reservar las IPs desde la 192.168.0.200 a la 192.168.0.220 para las asignaciones DHCP (range).

Esto es lo más básico, respecto a las distintas opciones añadidas en el fichero sample de configuración véis especificado lo que es cada cosa:

ddns-update-style none;
ddns-updates off;
deny client-updates;
one-lease-per-client false;
allow bootp;
option T150 code 150 = string;

subnet 192.168.0.0 netmask 255.255.255.0 {
  interface eth0;
   range 192.168.0.200 192.168.0.220;
       option subnet-mask 255.255.255.0;
       default-lease-time 6000;
       max-lease-time 7200;
       option time-offset -3600;
}

Finalmente, arrancamos el servicio:

/etc/init.d/dhcp start

Y el log (en mi caso vuelca a messages):

Oct 23 19:35:37 sylv1006 dhcpd: Internet Systems Consortium DHCP Server 4.1.0p1
Oct 23 19:35:37 sylv1006 dhcpd: Copyright 2004-2009 Internet Systems Consortium.
Oct 23 19:35:37 sylv1006 dhcpd: All rights reserved.
Oct 23 19:35:37 sylv1006 dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
Oct 23 19:35:37 sylv1006 dhcpd: Not searching LDAP since ldap-server, ldap-port and ldap-base-dn were not specified in the config file
Oct 23 19:35:47 sylv1006 dhcpd: Internet Systems Consortium DHCP Server 4.1.0p1
Oct 23 19:35:47 sylv1006 dhcpd: Copyright 2004-2009 Internet Systems Consortium.
Oct 23 19:35:47 sylv1006 dhcpd: All rights reserved.
Oct 23 19:35:47 sylv1006 dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
Oct 23 19:35:47 sylv1006 dhcpd: Not searching LDAP since ldap-server, ldap-port and ldap-base-dn were not specified in the config file
Oct 23 19:35:47 sylv1006 dhcpd: Wrote 0 leases to leases file.
Oct 23 19:35:47 sylv1006 dhcpd: Listening on LPF/eth0/00:16:3e:1d:36:42/192.168.0.0/24
Oct 23 19:35:47 sylv1006 dhcpd: Sending on   LPF/eth0/00:16:3e:1d:36:42/192.168.0./24
Oct 23 19:35:47 sylv1006 dhcpd: Sending on   Socket/fallback/fallback-net

Ahora que todo funciona correctamente, podemos configurar DHCP para que arranque automáticamente:

chkconfig dhcpd on