Soru Linux Çekirdeği çok noktaya yayın UDP paketlerinden geçmiyor


Son zamanlarda yeni bir Ubuntu Server 10.04 kurdum ve UDP sunucumun artık mümkün olmadığını fark ettim Çok noktaya yayın grubunu birleştirdikten sonra bile, arayüze gönderilen çok noktaya yayın verilerini görmek için. Aynı diğer iki Ubuntu 8.04.4 LTS makinede de aynı ayarları yaptım ve aynı çok noktaya yayın grubuyla birleştirildikten sonra veri almada sorun yok.

Ethernet kartı bir Broadcom netXtreme II BCM5709 ve kullanılan sürücü:

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

Çok noktaya yayın kayıtlarımı yönetmek için smcroute kullanıyorum.

b$ smcroute -d
b$ smcroute -j eth1 233.37.54.71

Gruba katıldıktan sonra ip maddr yeni eklenen kaydı gösterir.

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

Şimdiye kadar çok iyi, bu çok noktaya yayın grubu için veri aldığımı görebiliyorum.

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
...

Arabirimin mcast paketlerini aldığını da doğrularım.

b $ ethtool -S eth1 | grep mcast_pack
rx_mcast_packets: 103998
tx_mcast_packets: 33

Şimdi sorun burada. Basit bir yakut UDP sunucusu kullanarak trafiği yakalamaya çalıştığımda sıfır veri alırım! 15572 numaralı bağlantı noktasında veri gönderimini okuyan ve yazdırılan basit bir sunucudur. ilk iki karakter. Bu, iki 8.04.4 Ubuntu Sunucusunda çalışır, ancak 10.04 sunucusunda değil.

require 'socket'
s = UDPSocket.new
s.bind("", 15572)
5.times do
  text, sender = s.recvfrom(2)
  puts text
end

Yerel birime rubyede hazırlanmış bir UDP paketi göndersem, sunucu bunu alır ve ilk iki karakteri yazdırır. Bu yüzden yukarıdaki sunucunun düzgün çalıştığını biliyorum.

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)

Protokol istatistiklerini kontrol ettiğimde InMcastPkts'ın artmadığını görüyorum. Açıkken Aynı ağdaki diğer 8.04 sunucuları 10 saniyeliğine birkaç binlerce paket aldı.

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

Eğer arayüzü promisc moduna zorlamaya çalışırsam hiçbir şey değişmez.

Bu noktada sıkıştım. Çekirdek yapılandırmasının çok noktaya yayın etkin olduğunu doğruladım. Belki kontrol etmem gereken başka yapılandırma seçenekleri var mı?

b $ grep CONFIG_IP_MULTICAST /boot/config-2.6.32-23-server
CONFIG_IP_MULTICAST=y

Buradan nereye gideceğiniz hakkında bir fikrin var mı?


33
2017-07-23 01:00


Menşei


Git rakamı. Yeni bir soruya girmeye gidiyorum, ilgili algoritma bana bu sorunun var olduğunu mutlu bir şekilde gösteriyor, ama anlamlı bir cevabı yok. Boo :(. - VxJasonxV
Ödülünü tam olarak ne kadar ödeyeceğimi bilmiyorum. Bir iş arkadaşı sorunu buldu ve ben bunun nasıl olduğunu anladım. Ödülün nasıl verileceğine dair önerileri eğlendirmekten daha fazlasıyım. - VxJasonxV
hala etrafta mısın? sana bazı sorularım var. - VxJasonxV
Benim de bu problemim var. Sevgili buecking, çözdün mü?
Bu sorunu yaşayan diğer kişilere - bu sorudaki tüm cevapları okuyunuz, çünkü düzeltilmesi gereken 2-3 O / S ayarı vardır. Bu sorunu değiştirerek çözdük rp_filter ve /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts ve sonra çalışmaya başladı. - Sam Goldberg


Cevaplar:


Bizim örneğimizde, problemimiz Maciej'den farklı bir sysctl parametreleriyle çözüldü.

OP (buecking) için konuşmamaya dikkat edin, problemin temel ayrıntısı ile ilgili sorun nedeniyle bu yazıya girdim (userland'de çok noktaya yayın trafiği yok).

Dört adet çok noktaya yayın adreslerine gönderilen verileri ve çok noktaya yayın adresi için benzersiz bir bağlantı noktasını (genellikle) doğrudan alıcı sunucudaki bir arabirime bağlı olan bir aygıttan okuyan bir uygulamamız vardır.

Bilinmeyen bir nedenden ötürü gizemli bir şekilde başarısız olduğunda, bu yazılımı bir müşteri sitesinde dağıtmaya çalışıyorduk. Bu yazılımı hata ayıklama girişimleri, her sistem çağrısını incelemekle sonuçlandı, sonuçta hepimiz aynı şeyi söylediler:

Yazılımımız veri ister ve OS hiçbir zaman herhangi bir şey sağlamaz.

Çok noktaya yayın paket sayacı arttığında, tcpdump, trafiğin kutuyu / belirli bir ara yüze ulaştığını gösterdi, ancak bununla hiçbir şey yapamadık. SELinux devre dışı bırakıldı, iptables çalışıyordu ancak hiçbir tabloda hiçbir kural yoktu.

Stumped, öyleydik.

Rastgele etrafta dolaşırken, sysctl'nin kullandığı çekirdek parametrelerini düşünmeye başladık, ancak belgelenen özelliklerin hiçbiri ya özellikle alakalı değildi ya da çok noktaya yayın trafiğiyle ilgiliyse bunlar etkinleştirildi. Oh ve ifconfig, özellik satırında "MULTICAST" (yukarı, yayın, koşma, çoklu yayın) listelemesini yaptı. Merak ettiğimiz meraktan /etc/sysctl.conf. 'Bakın ve bu müşterinin temel görüntüsünün altta ona eklenmiş birkaç satır daha vardı.

Bizim durumumuzda müşteri belirledi net.ipv4.all.rp_filter = 1. rp_filter (anladığım kadarıyla) bu kutuya erişememiş olabilecek tüm trafiği reddeden Rota Yolu filtresidir. Ağ alt ağ atlamalı, düşünce kaynak IP'nin sahte olduğu.

Eh, bu sunucu 192.168.1 / 24 bir alt ağdaydı ve cihazın çok noktaya yayın trafiği için kaynak IP adresi 10. * ağında bir yerdeydi. Böylece, filtre sunucunun trafikte anlamlı bir şey yapmasını engelliyordu.

Müşteri tarafından onaylanmış bir çift tweaks; net.ipv4.eth0.rp_filter = 1 ve net.ipv4.eth1.rp_filter = 0 ve mutlu bir şekilde koşuyorduk.


32
2017-12-27 22:50



Bu işe yaradı! rp_filter 10 Gb ağ arayüzümüz için tüm UDP multicast paketlerimizi boşaltıyordu. Filtrenin kapatılması, her şeyin akmasına izin verir. - chrisaycock
Bir Ubuntu alıcısı üzerindeki tun cihazında AMT multicast üzerinden akış oluştururken sorun yaşıyorduk ve paketlerin tcpdump yoluyla cihaza teslim edildiğini görebiliyorduk, ancak uygulama sadece akış yapmak istemiyor. Bu gönderi bizi kurtardı! - software engineer


TL / DR Ayrıca multicast'inizin bir vlan'dan gelmediğinden emin olun. tcpdump -e yaptıklarını belirlemeye yardımcı olur.

Tüm hakkaniyete göre, birilerinin çok noktaya yayınların kullanıcı alanına ulaşmasını engelleyebilecek şeylerin kontrol listesiyle bir sayfa oluşturması gerekir. Birkaç gün boyunca bununla uğraşıyordum ve doğal olarak web'de bulabileceğim hiçbir şey yardım etmedi.

Paketleri sadece tcpdumpDiğer üreticiler için başka bir çok noktaya yayın paketini gerçekten farklı bir arabirimde alabiliyordum. Çok noktaya yayın alıp alamayacağımı test etmek için kullandığım komut şuydu:

$ GRP=224.x.x.x # set me to the group
$ PORT=yyyy # set me to the receiving port
$ IFACE=mmmm # set me to the name or IP address of the interface
$ strace -f socat -  UDP4-DATAGRAM:$GRP:$PORT,ip-add-membership=$GRP:$IFACE,bind=0.0.0.0:$PORT,multicast-loop=0

Nedeni strace işte aslında yapamadım socat paketleri stdout'a yazdırmak, ancak strace çıktı açıkça görebilirsiniz eğer socat bağlanan soketten gerçek veri alıyor (birkaç başlangıçtan sonra tersi olacaktır) select aramaları)

  • rp_filter sysctl - geçerli değil, sistemler aynı IP ağında. 0 hepsi aynı, öyle görünüyor ki 1 şimdi en azından Ubuntu için varsayılan bir ayardır).
  • güvenlik duvarı / etc - alıcı sistem güvenlik duvarı içermez (eğer paketler güvenlik duvarı oluşturulmuşsa tcpdump'ta görünmez, ama sanırım güvenlik duvarı komikse)
  • IP / Çok noktaya yayın yönlendirmesi ve çoklu arabirimler - Doğru arabirimde gruba açıkça katıldım
  • Wacky ağ donanımı - bu benim son çare oldu, ama Intel NUC bir dizüstü bilgisayar değiştirmek yardımcı olmadı. Bu, dirseklerimi çiğnemeye başladığım ve bunu SE'ye yollamayı sürdürdüğüm yer.
  • Benim durumumdaki sorun, bu çok noktaya yayın paketlerini üreten özel donanım tarafından VLAN'ların kullanılmasıydı. Sorununuzun bu olup olmadığını görmek için şunları eklediğinizden emin olun. -e bayrağı tcpdumpve vlan etiketlerini kontrol edin. Userland'ın bu paketleri alabilmesi için doğru vlanın bir arayüzünü yapılandırması gerekecektir. Benim için hediye, aslında çok noktaya yayın yapımcılarının ping yapmamasıydı, ancak ARP yanıtını bile göremediğim halde ARP önbelleğine bile girmeyeceklerdi.

VLAN ile koşturmak için bu bağlantı çok noktaya yayın yönlendirmesini yapılandırmaya yardımcı olabilir. (Maalesef bu konuda yeniyim, İtibar bir cevap eklememe izin vermiyor. Bu yüzden bu düzenleme.)

İşte ben yaptım (gerekirse sudo kullanın):

ip link add link eth0 name eth0_100 type vlan id 100
ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth0_100
ip link set dev eth0_100 up
ip maddr add 01:00:5e:01:01:01 dev eth0_100
route -n add -net 224.0.0.0 netmask 240.0.0.0 dev eth0_100

Bu şekilde vlan kimliği 100 ile vlan trafiği için oluşturulmuşsa ek bir arayüz. Vlan ip gereksiz olabilir. Sonra yeni arabirim için bir çok noktaya yayın adresi yapılandırılır (01: 00: 5e: 01: 01: 01 239.1.1.1 için bağlantı katmanı adresidir) ve tüm gelen çok noktaya yayın trafiği eth0_100'e bağlanır. Ayrıca yukarıdaki cevaplarda tüm olası adımları yaptım (iptables, rp_filter vb).


3
2017-07-08 08:10



@ Gero: Çok noktaya yayın yolu ekleniyor dışına dönük çok noktaya yayın, gelen çok noktaya yayın. Bir şey yaparken, çok noktaya yayın IP adreslerini doğrudan arayüzlere bağlamanız gerekmez, normalde uygulamanın işi. - Pawel Veselov


Bu ayarları denemek ve bakmak isteyebilirsiniz:

proc

echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

sysctl.conf

sed -i -e 's|^net.ipv4.icmp_echo_ignore_broadcasts =.*|net.ipv4.icmp_echo_ignore_broadcasts = 0|g' /etc/sysctl.conf

Bunlar RHEL'de çoklu yayınlamayı sağlamak için kullanılmıştır.

Güvenlik duvarınızın mutlicast trafiğe izin verdiğinden emin olmak isteyebilirsiniz; RHEL ile tekrar aşağıdakileri etkinleştirdim:

# allow anything in on multicast addresses
-A INPUT -s 224.0.0.0/4 -j ACCEPT
-A INPUT -p igmp -d 224.0.0.0/4 -j ACCEPT
# needed for multicast ping responses
-A INPUT -p icmp --icmp-type 0 -j ACCEPT

2
2017-12-21 00:27



"broadcast" seçenekleri de "multicast" için geçerlidir? - Raedwald


Yönetilen bir anahtar kullanıyor musunuz? Bazılarının 'yayın fırtınalarını' veya diğer çok noktaya yayın sorunlarını önleme seçenekleri vardır, bu da belirli paket türlerini engellemelerine neden olur. Anahtar belgelerinize bir göz atmanızı öneriyorum.


0
2017-12-21 02:54





s.bind("", 15572)

"" Hakkında emin misin? Neden çok noktaya yayın IP adresini kullanmıyorsunuz?


0
2018-01-31 18:19



Boş ana bilgisayar adresleri yaygın olarak "tüm arayüzler" anlamına gelir. - VxJasonxV