Приветствую.
Что имеем
3 машины для тестирования, на них следующий конфиг сети, последний октет меняется от 1 до 3:
auto eth1
iface eth1 inet static
address 192.168.100.1
netmask 255.255.255.0
auto gre1
iface gre1 inet static
pre-up ip tunnel add $IFACE mode gre ttl 64 tos inherit key 1001 || true
address 10.42.43.1
netmask 255.255.255.0
post-up ip link set $IFACE multicast on || true
post-up ip link set $IFACE mtu 1420 || true
post-down ip tunnel del $IFACE || true
post-up ip neigh add 10.42.43.2 lladdr 192.168.100.2 dev gre1
post-up ip neigh add 10.42.43.3 lladdr 192.168.100.3 dev gre1
post-up ip route add 224.0.0.0/4 dev $IFACE
pre-down ip route del 224.0.0.0/4 dev $IFACE
Но проще это представить в виде команд ip
ip tunnel add gre1 mode gre ttl 64 tos inherit key 1001
ip link set dev gre1 up
ip link set dev gre1 multicast on
ip link set dev gre1 mtu 1420
ip addr add 10.42.43.1/24 broadcast 10.42.43.255 dev gre1
ip neigh add 10.42.43.2 lladdr 192.168.100.2 dev gre1
ip neigh add 10.42.43.3 lladdr 192.168.100.3 dev gre1
ip a s gre1
7: gre1@NONE: <MULTICAST,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default
link/gre 0.0.0.0 brd 0.0.0.0
inet 10.42.43.1/24 brd 10.42.43.255 scope global gre1
valid_lft forever preferred_lft foreverip neigh show dev gre1
10.42.43.3 lladdr 192.168.100.3 PERMANENT
10.42.43.2 lladdr 192.168.100.2 PERMANENTПроверим что пакеты ходят в принципе
ping 10.42.43.2
PING 10.42.43.2 (10.42.43.2) 56(84) bytes of data.
64 bytes from 10.42.43.2: icmp_seq=1 ttl=64 time=0.818 ms
ping 10.42.43.3
PING 10.42.43.3 (10.42.43.3) 56(84) bytes of data.
64 bytes from 10.42.43.3: icmp_seq=1 ttl=64 time=0.361 msПроверяем мультикаст с помощь ssmping, на 10.42.43.2-3 запускаем ssmpingd, c 10.42.43.1 пингуем:
ssmping 10.42.43.2
ssmping joined (S,G) = (10.42.43.2,232.43.211.234)
pinging S from 10.42.43.1
unicast from 10.42.43.2, seq=1 dist=0 time=1.289 ms
unicast from 10.42.43.2, seq=2 dist=0 time=1.017 ms
ssmping 10.42.43.3
ssmping joined (S,G) = (10.42.43.3,232.43.211.234)
pinging S from 10.42.43.1
unicast from 10.42.43.3, seq=1 dist=0 time=0.680 ms
unicast from 10.42.43.3, seq=2 dist=0 time=0.763 msДля пробы делаем так ip route replace 224.0.0.0/4 dev eth1 на каждом хосте. Запускаем ssmpingd, проверям:
ssmping 192.168.100.2 -c 1
ssmping joined (S,G) = (192.168.100.2,232.43.211.234)
pinging S from 192.168.100.1
unicast from 192.168.100.2, seq=1 dist=0 time=0.548 ms
multicast from 192.168.100.2, seq=1 dist=0 time=0.556 ms
ssmping 192.168.100.3 -c 1
ssmping joined (S,G) = (192.168.100.3,232.43.211.234)
pinging S from 192.168.100.1
unicast from 192.168.100.3, seq=1 dist=0 time=0.549 ms
multicast from 192.168.100.3, seq=1 dist=0 time=0.557 msПроблема
Суть отражена в заголовке. Если настроить обычные p2p GRE тоннели с явным указанием конечных точек подключения - то мультикаст отлично в таком тоннеле ходит. Минус обычных тоннелей в тоннах конфигов на каждой машине, и кроме того если соединить хотя бы 3 машины в сеть «каждый с каждым», то правила вроде ip route add 224.0.0.0/4 dev gre1 уже недостаточно нам ведь надо отправлять мультикаст во все туннели. На данный момент я даже не представляю как это реализуется, но это тема отдельного вопроса.
