$ route -n
Tabla de rutas IP del núcleo
Destino         Pasarela        Genmask         Indic Métric Ref    Uso Interfaz
192.168.1.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0

Bien, hay que saber que se trata de la característica Automatic Private IP Address (APIPA), y es la asignación automática por parte del sistema operativo de una IP en ese rango (máscara de red 255.255.0.0) cuando no consigue contactar con el servidor DHCP que tiene que asignarnos una IP. En un hipotético caso de una red privada en la que fallara el servidor DHCP, esto permitiría que las máquinas conectadas a esa red tuvieran asignada una IP dentro del mismo rango y se pudieran comunicar, no así con el exterior ya que no se configura gateway.

Si queremos prescindir de esta funcionalidad en sistemas RHEL, CentOS, Scientific Linux, etc. Debemos añadir la directiva “NOZEROCONF=yes” al fichero “/etc/sysconfig/network”.

NOZEROCONF=yes

Después reiniciamos la red:

# /etc/init.d/network restart

También te puede interesar:

• Enrutar en Linux (route add/del)
• Routing Tables: ‘netstat -rn’ y ‘route -n’
• Bucle de password expirado en ldap nativo RHEL contra Sun LDAP
• nf_conntrack: table full, dropping packet en kernel 2.6.32

# dmesg
...
...
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
nf_conntrack: table full, dropping packet.
...
...

El problema puede residir tanto en un ataque puntual o que realmente el tráfico legítimo que recibe la máquina es muy grande. Tanto en un caso como en otro la solución rápida es modificar este parámetro del kernel y aumentar su valor. Os recomiendo revisar este otro artículo sysctl y /proc/sys – modificar parámetros de kernel para ampliar la información.

Lo primero que debemos ver es, por un lado el valor máximo actual y el valor en uso:

$ cat /proc/sys/net/netfilter/nf_conntrack_count
62686
$ cat /proc/sys/net/netfilter/nf_conntrack_max
65536

La primera orden nos dice el número de entradas en la tabla y el segundo el máximo. Como vemos estamos a punto de llegar al límite. Cuando esto suceda se comenzarán a descartar paquetes. Podemos entonces ampliar temporalmente (no sobrevive a renicios) el nº de entradas máximas en la tabla (ponemos el doble):

# sysctl -w net.netfilter.nf_conntrack_max=131072
net.netfilter.nf_conntrack_max = 131072

Si quisieramos hacerlo persistente a reinicios, lo modificaríamos en el fichero /etc/sysctl.conf añadiendo:

net.netfilter.nf_conntrack_max=131072

También te puede interesar:

• ¿Qué es APIPA/zeroconf y cómo deshabilitarlo en CentOS/RHEL (169.254.x.y)?
• Subnetting y cálculo de netmask desde línea de comandos
• Red Hat Cluster: “generic error” al crear un IP Resource
• Introducción a iptables

Para instalarlos utilizamos los gestores de paquetes correspondientes, apt, yum…

$ sudo apt-get install ipcalc

$ sudo yum install ipcalc

Nota: en RHEL y CentOS hay que activar el repositorio rpmforge.

La utilización es bien sencilla, podemos pasar como parámetro la subred en formato CIDR y nos devuelve toda la información de la misma, máscara, red, nº de hosts, etc:

$ ipcalc 10.0.0.0/24
Address:   10.0.0.0             00001010.00000000.00000000. 00000000
Netmask:   255.255.255.0 = 24   11111111.11111111.11111111. 00000000
Wildcard:  0.0.0.255            00000000.00000000.00000000. 11111111
=>
Network:   10.0.0.0/24          00001010.00000000.00000000. 00000000
HostMin:   10.0.0.1             00001010.00000000.00000000. 00000001
HostMax:   10.0.0.254           00001010.00000000.00000000. 11111110
Broadcast: 10.0.0.255           00001010.00000000.00000000. 11111111
Hosts/Net: 254                   Class A, Private Internet

IPV6 con sipcalc:

$ sipcalc 2001:DB8::/24
-[ipv6 : 2001:DB8::/24] - 0

[IPV6 INFO]
Expanded Address	- 2001:0db8:0000:0000:0000:0000:0000:0000
Compressed address	- 2001:db8::
Subnet prefix (masked)	- 2001:d00:0:0:0:0:0:0/24
Address ID (masked)	- 0:b8:0:0:0:0:0:0/24
Prefix address		- ffff:ff00:0:0:0:0:0:0
Prefix length		- 24
Address type		- Aggregatable Global Unicast Addresses
Network range		- 2001:0d00:0000:0000:0000:0000:0000:0000 -
			  2001:0dff:ffff:ffff:ffff:ffff:ffff:ffff

Otra característica interesante es la posibilidad de sipcalc de especificar una red y hacer subneting con ella, si por ejemplo queremos dividir un /21 en redes /22 o /24:

$ sipcalc -s24 10.0.0.0/21
-[ipv4 : 10.0.0.0/21] - 0

[Split network]
Network			- 10.0.0.0        - 10.0.0.255
Network			- 10.0.1.0        - 10.0.1.255
Network			- 10.0.2.0        - 10.0.2.255
Network			- 10.0.3.0        - 10.0.3.255
Network			- 10.0.4.0        - 10.0.4.255
Network			- 10.0.5.0        - 10.0.5.255
Network			- 10.0.6.0        - 10.0.6.255
Network			- 10.0.7.0        - 10.0.7.255

-
$ sipcalc -s22 10.0.0.0/21
-[ipv4 : 10.0.0.0/21] - 0

[Split network]
Network			- 10.0.0.0        - 10.0.3.255
Network			- 10.0.4.0        - 10.0.7.255

Si revisáis la ayuda del comando encontraréis otras posibilidades de interés.

También te puede interesar:

• Escanear rango de Ips
• ¿Qué es APIPA/zeroconf y cómo deshabilitarlo en CentOS/RHEL (169.254.x.y)?
• nf_conntrack: table full, dropping packet en kernel 2.6.32
• Red Hat Cluster: “generic error” al crear un IP Resource

Uno de los primeros problemas que me encontré es de lo más simple. La idea es crear un recurso IP, que levanta una IP virtual en uno de los nodos del cluster. Esa IP la podemos utilizar posteriormente como recurso para un servicio HTTP ó MySQL por ejemplo, IP que en caso de fallo del nodo activo se traspasará junto con el resto de servicio a otro nodo del cluster.

Lo único que hay que tener claro es que la subred de esa IP debe estar configurada en alguna de las interfaces de red de los nodos, sino el rgmanager no sabrá donde levantarla. La máscara es opcional, pero por ahí venían todos mis problemas. Recibía el siguiente error al levantar el servicio:

Dec 28 21:41:53 nodo1 rgmanager[3563]: Initializing service:IP
Dec 28 21:42:32 nodo1 rgmanager[3563]: Recovering failed service service:IP
Dec 28 21:42:32 nodo1 rgmanager[3563]: start on ip "192.168.1.200/255.255.255.0" returned 1 (generic error)
Dec 28 21:42:33 nodo1 rgmanager[3563]: #68: Failed to start service:IP; return value: 1
Dec 28 21:42:33 nodo1 rgmanager[3563]: Stopping service service:IP
Dec 28 21:42:35 nodo1 rgmanager[3563]: Service service:IP is recovering

Y la configuración del recurso/servicio:

<service autostart="0" domain="IP_FAILOVER" name="IP" recovery="relocate">
<ip address="192.168.1.200/255.255.255.0" monitor_link="1" sleeptime="10"/>
</service>

El problema, tras darle unas cuantas vueltas era tan simple como que la máscara se especifica como bits de máscara de red, es decir, en lugar de 255.255.255.0, 24:

<service autostart="0" domain="IP_FAILOVER" name="IP" recovery="relocate">
<ip address="192.168.1.200/24" monitor_link="1" sleeptime="10"/>
</service>

Tratamos de arrancar el servicio y ya levanta la IP virtual correctamente. Puede parecer una tontería pero es útil tenerlo en cuenta por si os pasa.

Dec 28 21:47:31 nodo1 rgmanager[3331]: Starting stopped service service:IP
Dec 28 21:47:37 nodo1 rgmanager[8561]: [ip] Adding IPv4 address 192.168.1.200/24 to eth0
Dec 28 21:47:44 nodo1 rgmanager[3331]: Service service:IP started

También te puede interesar:

• FAQ de RHCS (Red Hat Cluster Suite)
• Cluster HTTP en alta disponibilidad con CentOS + Heartbeat
• Cómo añadir IP virtual en Linux
• ¿Qué es APIPA/zeroconf y cómo deshabilitarlo en CentOS/RHEL (169.254.x.y)?

Main.cf por defecto:

smtp_bind_address =

Esto hará que Postfix sea quien elija la IP de salida. En mi caso concreto, tenía una interfaz con salida a Internet y además otra interfaz virtual (eth0 192.168.0.13 y eth0:1 192.168.0.14). En este caso Postfix usaba eth0 para la salida de correos.

Si queremos elegir nosotros la interfaz eth0:1 (192.168.0.14) para el outbound SMTP, simplemente le decimos cual debe usar:

smtp_bind_address = 192.168.0.14

Reiniciamos Postfix y todo correo que salga desde nuestro servidor lo hará por esta IP (192.168.0.14).

También te puede interesar:

• Creación de cuenta no-reply en Postfix
• Verificar funcionamiento correo SMTP vía TELNET
• Deshabilitar VRFY en Postfix
• ¿Qué es APIPA/zeroconf y cómo deshabilitarlo en CentOS/RHEL (169.254.x.y)?

Bien, buscando por Internet he encontrado diversas soluciones, pero la más sencilla y eficaz es la de añadir la siguiente directiva en el fichero de configuración snmpd.conf (normalmente en /etc/snmpd/snmpd.conf), donde xx.xx.xx.xx es la IP en la que queréis que escuche:

agentaddress xx.xx.xx.xx

Posteriormente recargáis el servicio:

service snmpd reload

Después, verificad que escucha por la IP que habéis configurado:

# netstat -nau
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             State
udp        0      0 0.0.0.0:161                 0.0.0.0:*                               

Si queréis, en Cybercity tenéis información ampliada sobre las distintas posibilidades.

También te puede interesar:

• ¿Qué es APIPA/zeroconf y cómo deshabilitarlo en CentOS/RHEL (169.254.x.y)?
• nf_conntrack: table full, dropping packet en kernel 2.6.32
• Subnetting y cálculo de netmask desde línea de comandos
• Red Hat Cluster: “generic error” al crear un IP Resource

En la ruta /etc/sysconfig/network-scripts encontraréis los ficheros de arranque de cada una de las interfaces de red del sistema:

# ls -l /etc/sysconfig/network-scripts/ifcfg-*
-rw-r--r-- 3 root root 201 Jul  7 16:01 /etc/sysconfig/network-scripts/ifcfg-eth0
-rw-rw-rw- 3 root root 178 Jul  7 16:00 /etc/sysconfig/network-scripts/ifcfg-eth1
-rw-r--r-- 1 root root 254 Sep 24  2008 /etc/sysconfig/network-scripts/ifcfg-lo

En este caso, queremos que la interfaz de red eth0 contenga una IP virtual además de la IP principal de la misma, simplemente tendríamos que crear un nuevo fichero de configuración, llamado ifcfg-eth0:0 (sucesivas IPs virtuales serían ifcfg-eth0:1, ifcfg-eth0:2,….). El contenido del fichero será el mismo que el de ifcfg-eth0 pero con las siguientes modificaciones:

ifcfg-eth0

DEVICE=eth0
BOOTPROTO=static
HWADDR=00:22:7e:3c:3b:12
IPADDR=192.168.0.110
NETMASK=255.255.255.0
ONBOOT=yes
GATEWAY=192.168.0.1
TYPE=Ethernet

ifcfg-eth0:0

Veréis que cambiamos la IP por la IP virtual y DEVICE por el nuevo identificador ( eth0:0 ), por lo demás, tanto la dirección MAC de la tarjeta de red sigue siendo la misma, protocolo de arranque, etc:

DEVICE=eth0:0
BOOTPROTO=static
HWADDR=00:22:7e:3c:3b:12
IPADDR=192.168.0.111
NETMASK=255.255.255.0
ONBOOT=yes
GATEWAY=192.168.0.1
TYPE=Ethernet

Una vez completado el proceso, reiniciamos la red o levantamos la nueva IP virtual:

service network restart

ifup eth0:0

La nueva IP ya debería responder a ping.

También te puede interesar:

• Red Hat Cluster: “generic error” al crear un IP Resource
• ACL (Access Control List) en sistemas de ficheros GNU/Linux
• Cómo crear un RAID 1 por software en RHEL y CentOS
• 6 trucos útiles del gestor de paquetes yum

for IP in 192.168.1.{1..10}; do if ping $IP -c 1 > /dev/null; then echo $IP alive; else echo $IP dead; fi; done

Y la salida (escaneo desde la 192.168.1.1 a 192.168.1.10

~$ for IP in 192.168.1.{1..10}; do if ping $IP -c 1 > /dev/null; then echo $IP alive; else echo $IP dead; fi; done
192.168.1.1 alive
192.168.1.2 dead
192.168.1.3 dead
192.168.1.4 dead
192.168.1.5 dead
192.168.1.6 dead
192.168.1.7 dead
192.168.1.8 dead
192.168.1.9 dead
192.168.1.10 dead

También te puede interesar:

• Subnetting y cálculo de netmask desde línea de comandos
• ¿Qué es APIPA/zeroconf y cómo deshabilitarlo en CentOS/RHEL (169.254.x.y)?
• Nmap Online para tu IP o Clase C
• nf_conntrack: table full, dropping packet en kernel 2.6.32

Ejemplo:

Conexiones a apache:

# netstat -plan|grep :80 | awk {'print $5'} | cut -d: -f 1 | sort | uniq -c | sort -n
1 XX.XX.XXX.XXX
1 XX.XX.XXX.XXX
1 XX.XX.XXX.XXX
51 XX.XX.XXX.XXX
64 XX.XX.XXX.XXX

Por explicar un poco el comando, NETSTAT muestra un listado de las conexiones activas del servidor, con GREP filtramos solo las conexiones al puerto 80, con AWK filtramos para que muestre solamente el contenido de la columna 5 (en este caso la IP) de la salida por pantalla, con CUT quitamos el “:”, con SORT ordenamos, con UNIQ sacamos valores únicos, y con SORT ordenamos de nuevo por nº de conexiones.

También te puede interesar:

• ¿Qué es APIPA/zeroconf y cómo deshabilitarlo en CentOS/RHEL (169.254.x.y)?
• nf_conntrack: table full, dropping packet en kernel 2.6.32
• Subnetting y cálculo de netmask desde línea de comandos
• Red Hat Cluster: “generic error” al crear un IP Resource