LINUX.ORG.RU
ФорумAdmin

Не работает multicast в point to multipoint GRE тоннеле

 , , ,


1

2

Приветствую. Что имеем
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 forever
ip 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 уже недостаточно нам ведь надо отправлять мультикаст во все туннели. На данный момент я даже не представляю как это реализуется, но это тема отдельного вопроса.

гм. multicast over gre ? А оно вообще когда-нибудь работало в линуксе ?

то правила вроде ip route add 224.0.0.0/4 dev gre1 уже недостаточно нам ведь надо отправлять мультикаст во все туннели. На данный момент я даже не представляю как это реализуется

. Ну тут немного проще - mrouted/pimd/....

vel ★★★★★
()
Ответ на: комментарий от vel

гм. multicast over gre ? А оно вообще когда-нибудь работало в линуксе ?

Ну с явным указанием конечных точек работает. В процессе изучения вопрос наткнулся на данную запись, из которой можно сделать вывод что потенциально оно может работать. Но там обсуждается достаточно старое ядро, не факт что патчи наложатся на более новые ядра. И главное, совершенно не хочется поддерживать все это для продакшен систем.

Hatifnatt
() автор топика
Ответ на: комментарий от Hatifnatt

То, что оно работало на каком-то ядре - возможно, но в каком состоянии оно сейчас - большой вопрос.

А «echo 0 > /proc/sys/net/ipv4/neigh/gre1/mcast_solicit» и «echo 0 > /proc/sys/net/ipv4/conf/gre1/rp_filter» не помогает ?

vel ★★★★★
()
Ответ на: комментарий от vel

А «echo 0 > /proc/sys/net/ipv4/neigh/gre1/mcast_solicit» и «echo 0 > /proc/sys/net/ipv4/conf/gre1/rp_filter» не помогает ?

Нет, оба варианта не помогают. Вместе тоже.

Hatifnatt
() автор топика
Ответ на: комментарий от Pinkbyte
ip tunnel
gre0: gre/ip  remote any  local any  ttl inherit  nopmtudisc
gre1: gre/ip  remote any  local any  ttl 64  tos inherit key 1001

Почему же шляпа то? Хотелось бы подробностей.

А касательно проблемы с несколькими обычными p2p тоннелями, появилась мысль использовать gretap тоннели и объеденить их в бридж затем. Правда оверхед выше, инкапсулируется Ethernet пакет целиком.

Hatifnatt
() автор топика
Ответ на: комментарий от Hatifnatt

remote any local any

Аааа... Тут я умываю руки, я такое ни разу не настраивал

Pinkbyte ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.