Servidor no responde con Spike en paquetes de multidifusión recibidos

Tengo un servidor de UbiquityServers hace una semana, he instalado un servidor Apache simple y sólo sirve imágenes. El servidor está bajo muy poca carga porque simplemente es un servidor de origen detrás de CloudFront de Amazon, pero ayer de repente se volvió insensible a SSH hasta el punto de que tenía el poder de encendido / a SSH de nuevo pulg Estoy tratando de encontrar lo que causó esto Y agradecería cualquier aportación de la comunidad.

Aquí hay algunos hallazgos.

Me di cuenta de que había un pico en paquetes recibidos multicast derecho en todo el tiempo, aquí es un registro:

sar -n DEV -f sa29 | less 08:30:01 PM eth1 66.96 63.34 19.54 62.51 0.00 0.00 0.05 08:40:01 PM lo 0.07 0.07 0.01 0.01 0.00 0.00 0.00 08:40:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 08:40:01 PM eth1 65.05 70.51 5.63 84.70 0.00 0.00 0.02 08:50:01 PM lo 0.04 0.04 0.00 0.00 0.00 0.00 0.00 08:50:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 08:50:01 PM eth1 57.84 59.48 6.71 67.85 0.00 0.00 0.04 09:00:01 PM lo 0.03 0.03 0.00 0.00 0.00 0.00 0.00 09:00:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:00:01 PM eth1 48.55 47.35 4.30 53.78 0.00 0.00 0.03 09:10:01 PM lo 0.01 0.01 0.00 0.00 0.00 0.00 0.00 09:10:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:10:01 PM eth1 53.16 51.88 5.61 58.48 0.00 0.00 0.02 09:20:01 PM lo 0.04 0.04 0.00 0.00 0.00 0.00 0.00 09:20:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:20:01 PM eth1 61.80 63.91 7.75 73.46 0.00 0.00 0.05 09:30:01 PM lo 0.03 0.03 0.00 0.00 0.00 0.00 0.00 09:30:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:30:01 PM eth1 54.74 55.70 5.79 63.43 0.00 0.00 0.02 09:40:01 PM lo 0.01 0.01 0.00 0.00 0.00 0.00 0.00 09:40:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:40:01 PM eth1 27.83 28.57 3.17 32.59 0.00 0.00 1058754721.47 09:50:01 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:50:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:50:01 PM eth1 0.00 0.00 0.00 0.00 0.00 0.00 2142789576.69 10:00:01 PM lo 0.05 0.05 0.01 0.01 0.00 0.00 0.00 10:00:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 10:00:01 PM eth1 0.00 0.00 0.00 0.00 0.00 0.00 2152346090.50 10:10:01 PM lo 0.01 0.01 0.00 0.00 0.00 0.00 0.00 10:10:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 10:10:01 PM eth1 0.00 0.00 0.00 0.00 0.00 0.00 2142038999.87 10:20:01 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 10:20:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 10:20:01 PM eth1 0.00 0.00 0.00 0.00 0.00 0.00 2153457524.69 10:30:01 PM lo 0.01 0.01 0.00 0.00 0.00 0.00 0.00 10:30:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 10:30:01 PM eth1 0.00 0.00 0.00 0.00 0.00 0.00 2142646569.12 Average: lo 0.03 0.03 0.00 0.00 0.00 0.00 0.00 Average: eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: eth1 91.61 90.43 21.05 59.33 0.00 0.00 87333330.59 10:42:20 PM LINUX RESTART 10:50:01 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s 11:00:01 PM lo 0.03 0.03 0.00 0.00 0.00 0.00 0.00 11:00:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:00:01 PM eth1 31.57 28.14 2.54 30.25 0.00 0.00 0.05 11:10:01 PM lo 0.11 0.11 0.01 0.01 0.00 0.00 0.00 11:10:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 

El servidor está utilizando CentOS 6. No estoy muy seguro de qué más debo comprobar.

One Solution collect form web for “Servidor no responde con Spike en paquetes de multidifusión recibidos”

Sólo quería contribuir a esto, ya que tenía el mismo problema, utilizando la misma empresa de alojamiento como el OP. Nuestro servidor no respondería durante mucho tiempo (a veces horas) y que siempre coincidió con una cantidad loca de paquetes multicast entrantes.

Lo que descubrí fue que nuestro servidor no estaba en una VLAN privada y estaba siendo expuesto a "multicast público" y el tráfico de difusión, específicamente el tráfico probablemente dirigido a los propietarios anteriores de nuestra dirección IP (web de acogida reciclar los). Nuestra dirección IP fue utilizada una vez por una comunidad de juegos en línea, así que ve a la figura.

Conseguir que los chicos de Ubiquity nos coloquen en una VLAN privada resolvió de inmediato este problema, y ​​fue $ 80 total (tarifa única). Probablemente me habrían advertido acerca de eso cuando compré mi servidor dedicado acerca de esta vulnerabilidad, pero no lo hicieron.

No tengo nada más que decir cosas buenas para Ubiquity Hosting, así que quería asegurarse de que el registro era claro que sólo se reducía al hecho de que mi IP era vulnerable al tráfico UDP, y mi caja no podía manejar un billón + erróneo UDP en una ráfaga tan corta.

Espero que esto ayude a alguien!

  • Manual de reenvío de multidifusión con enrutador Linux
  • ¿Cómo manejan los switches gestionados Broadcast Multicast y Unicast?
  • ¿Por qué mis packages de multidifusión que no escuchan afectan al performance de Wifi?
  • Cómo compartir el tráfico de multidifusión en muchos vlans
  • ¿Cómo puedo probar la conectividad UDP de multidifusión entre dos serveres?
  • Cómo deshabilitar IGMP en Raspbian
  • ¿La comunicación IP global de uno a muchos es práctica hoy?
  • hay una manera de "multicast" una request con haproxy?
  • ¿Cuál es la diferencia entre las direcciones bind, network (interfaz) y multicast?
  • VMware ESX 5.0 locking DHCPv6 solicitaciones en vSwitches?
  • de routing multicast - CentOS 5
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.