Recientemente configuré un nuevo Ubuntu Server 10.04 y noté que mi servidor UDP ya no puede ver los datos de multidifusión enviados a la interfaz, incluso después de unirse al grupo de multidifusión. Tengo exactamente la misma configuración en otras dos máquinas Ubuntu 8.04.4 LTS y no hay ningún problema para recibir datos después de unirme al mismo grupo de multidifusión.
La tarjeta ethernet es una Broadcom netXtreme II BCM5709 y el controlador utilizado es:
b $ ethtool -i eth1
driver: bnx2
version: 2.0.2
firmware-version: 5.0.11 NCSI 2.0.5
bus-info: 0000:01:00.1
Estoy usando smcroute para administrar mis registros de multidifusión.
b$ smcroute -d
b$ smcroute -j eth1 233.37.54.71
Después de unirse al grupo, ip maddr muestra el registro recién agregado.
b$ ip maddr
1: lo
inet 224.0.0.1
inet6 ff02::1
2: eth0
link 33:33:ff:40:c6:ad
link 01:00:5e:00:00:01
link 33:33:00:00:00:01
inet 224.0.0.1
inet6 ff02::1:ff40:c6ad
inet6 ff02::1
3: eth1
link 01:00:5e:25:36:47
link 01:00:5e:25:36:3e
link 01:00:5e:25:36:3d
link 33:33:ff:40:c6:af
link 01:00:5e:00:00:01
link 33:33:00:00:00:01
inet 233.37.54.71 <------- McastGroup.
inet 224.0.0.1
inet6 ff02::1:ff40:c6af
inet6 ff02::1
Hasta ahora todo bien, puedo ver que estoy recibiendo datos para este grupo de multidifusión.
b$ sudo tcpdump -i eth1 -s 65534 host 233.37.54.71
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65534 bytes
09:30:09.924337 IP 192.164.1.120.58848 > 233.37.54.71.15572: UDP, length 212
09:30:09.947547 IP 192.164.1.120.58848 > 233.37.54.71.15572: UDP, length 212
09:30:10.108378 IP 192.164.1.120.58866 > 233.37.54.71.15574: UDP, length 268
09:30:10.196841 IP 192.164.1.120.58848 > 233.37.54.71.15572: UDP, length 212
...
También puedo confirmar que la interfaz está recibiendo paquetes mcast.
b $ ethtool -S eth1 | grep mcast_pack
rx_mcast_packets: 103998
tx_mcast_packets: 33
Ahora aquí está el problema. ¡Cuando trato de capturar el tráfico usando un simple servidor ruby UDP, recibo cero datos! Aquí hay un servidor simple que lee el envío de datos en el puerto 15572 e imprime los dos primeros caracteres. Esto funciona en los dos servidores Ubuntu 8.04.4, pero no en el servidor 10.04.
require 'socket'
s = UDPSocket.new
s.bind("", 15572)
5.times do
text, sender = s.recvfrom(2)
puts text
end
Si envío un paquete UDP creado en rubí a localhost, el servidor lo recibe e imprime los dos primeros caracteres. Entonces sé que el servidor anterior funciona correctamente.
irb(main):001:0> require 'socket'
=> true
irb(main):002:0> s = UDPSocket.new
=> #<UDPSocket:0x7f3ccd6615f0>
irb(main):003:0> s.send("I2 XXX", 0, 'localhost', 15572)
Cuando reviso las estadísticas del protocolo, veo que InMcastPkts no está aumentando. Mientras que en los otros servidores 8.04, en la misma red, recibió unos pocos miles de paquetes en 10 segundos.
b $ netstat -sgu ; sleep 10 ; netstat -sgu
IcmpMsg:
InType3: 11
OutType3: 11
Udp:
446 packets received
4 packets to unknown port received.
0 packet receive errors
461 packets sent
UdpLite:
IpExt:
InMcastPkts: 4654 <--------- Same as below
OutMcastPkts: 3426
InBcastPkts: 9854
InOctets: -1691733021
OutOctets: 51187936
InMcastOctets: 145207
OutMcastOctets: 109680
InBcastOctets: 1246341
IcmpMsg:
InType3: 11
OutType3: 11
Udp:
446 packets received
4 packets to unknown port received.
0 packet receive errors
461 packets sent
UdpLite:
IpExt:
InMcastPkts: 4656 <-------------- Same as above
OutMcastPkts: 3427
InBcastPkts: 9854
InOctets: -1690886265
OutOctets: 51188788
InMcastOctets: 145267
OutMcastOctets: 109712
InBcastOctets: 1246341
Si trato de forzar la interfaz a modo promisc, nada cambia.
En este punto estoy atascado. He confirmado que la configuración del núcleo tiene habilitada la multidifusión. ¿Quizás hay otras opciones de configuración que debería verificar?
b $ grep CONFIG_IP_MULTICAST /boot/config-2.6.32-23-server
CONFIG_IP_MULTICAST=y
¿Alguna idea sobre a dónde ir desde aquí?
rp_filtery/proc/sys/net/ipv4/icmp_echo_ignore_broadcastsy luego empezamos a trabajar.Respuestas:
En nuestro caso, nuestro problema se resolvió mediante parámetros sysctl, uno diferente de Maciej.
Tenga en cuenta que no hablo por el OP (buecking), llegué a esta publicación debido a que el problema está relacionado con los detalles básicos (no hay tráfico de multidifusión en el país de usuario).
Tenemos una aplicación que lee los datos enviados a cuatro direcciones de multidifusión, y un puerto único por dirección de multidifusión, desde un dispositivo que (generalmente) está conectado directamente a una interfaz en el servidor receptor.
Intentábamos implementar este software en el sitio de un cliente cuando falló misteriosamente sin razón conocida. Los intentos de depurar este software resultaron en la inspección de cada llamada al sistema, en última instancia, todos nos dijeron lo mismo:
Nuestro software solicita datos y el sistema operativo nunca proporciona ninguno.
El contador de paquetes de multidifusión aumentó, tcpdump mostró que el tráfico llegaba a la interfaz box / específica, pero no pudimos hacer nada con él. SELinux estaba deshabilitado, iptables se estaba ejecutando pero no tenía reglas en ninguna de las tablas.
Perplejos, estábamos.
Al hurgar aleatoriamente, comenzamos a pensar en los parámetros del núcleo que maneja sysctl, pero ninguna de las características documentadas era particularmente relevante, o si tenían que ver con el tráfico de multidifusión, estaban habilitadas. Ah, y ifconfig enumeró "MULTICAST" en la línea característica (arriba, transmisión, ejecución, multidifusión). Por curiosidad miramos
/etc/sysctl.conf. Bueno, he aquí, la imagen base de este cliente tenía un par de líneas adicionales agregadas en la parte inferior.En nuestro caso, el cliente había establecido
net.ipv4.all.rp_filter = 1. rp_filter es el filtro Ruta de ruta, que (según tengo entendido) rechaza todo el tráfico que posiblemente no podría haber llegado a este cuadro. Salto de subred de red, la idea es que la IP de origen se está falsificando.Bueno, este servidor estaba en una subred 192.168.1 / 24 y la dirección IP de origen del dispositivo para el tráfico de multidifusión estaba en algún lugar de la red 10. *. Por lo tanto, el filtro impedía que el servidor hiciera algo significativo con el tráfico.
Un par de ajustes aprobados por el cliente;
net.ipv4.eth0.rp_filter = 1ynet.ipv4.eth1.rp_filter = 0y estábamos corriendo felices.fuente
rp_filterde nuestra interfaz de red de 10 Gb estaba volcando todos nuestros paquetes de multidifusión UDP. Al apagar el filtro, todo fluye.net.ipv4.all.rp_filter = 0. Específicamente, con los datos de multidifusión llegando a eth2, tuve que configurar ambosnet.ipv4.eth2.rp_filter = 0ynet.ipv4.all.rp_filter = 0.TL / DR También asegúrese de que su multidifusión no provenga de un vlan.
tcpdump -eayudaría a determinar si lo hacen.Para ser justos, alguien debería construir una página con una lista de verificación de las cosas que pueden evitar que la multidifusión llegue al país de los usuarios. He estado luchando con eso durante un par de días, y naturalmente nada de lo que pude encontrar en la web me ayudó.
No solo podía ver los paquetes en el
tcpdump, sino que también podía recibir otros paquetes de multidifusión, para otros productores, solo en una interfaz diferente. El comando que terminé usando para probar si puedo recibir multidifusión fue:La razón de
straceesto es que en realidad no pudesocatimprimir los paquetes en lastracesalida estándar, pero en la salida puede ver claramente sisocatestá recibiendo datos reales del socket enlazado (de lo contrario, se silenciará después de un par deselectllamadas iniciales )rp_filtersysctl: no se aplica, los sistemas están en la misma red IP (los configuré de0todos modos, parece que ahora1es una configuración predeterminada, al menos para Ubuntu).-eflag totcpdumpy verifica las etiquetas de vlan. Será necesario configurar una interfaz en el vlan correcto antes de que userland pueda obtener esos paquetes. El regalo para mí en realidad fue que los productores de multidifusión no harán ping, pero ni siquiera entrarán en el caché ARP, aunque pude ver claramente las respuestas ARP.Para que funcione con VLAN, este enlace puede ser útil para configurar el enrutamiento de multidifusión. (Lamentablemente, soy nuevo en esto, por lo que Reputation no me permite agregar una respuesta. De ahí esta edición).
Esto es lo que hice (use sudo si es necesario):
De esta manera, si se crea una interfaz adicional para el tráfico vlan con vlan id 100. La ip vlan podría ser innecesaria. Luego, se configura una dirección de multidifusión para la nueva interfaz (01: 00: 5e: 01: 01: 01 es la dirección de la capa de enlace para 239.1.1.1) y todo el tráfico de multidifusión entrante está vinculado a eth0_100. También hice todos los pasos posibles en las respuestas anteriores (consulte iptables, rp_filter, etc.).
fuente
Es posible que desee probar y ver estas configuraciones:
proc
sysctl.conf
Estos se han utilizado para habilitar la multidifusión en RHEL.
Es posible que desee asegurarse de que su firewall esté permitiendo el tráfico de multidifusión; De nuevo con RHEL he habilitado lo siguiente:
fuente
¿Estás utilizando un conmutador administrado? Algunos tienen opciones para evitar 'tormentas de difusión' u otros problemas de multidifusión, que podrían hacer que eviten ciertos tipos de paquetes. Sugeriría echar un vistazo a la documentación de su interruptor.
fuente
Seguro acerca de ""? ¿Por qué no usar la dirección IP de multidifusión para enlazar?
fuente