LINUX.ORG.RU
решено ФорумAdmin

grelan-интерфейс в бридже

 , , ,


0

2

Захотел поднять сеть между парой нод проксмокса. Раньше всегда делал на tinc, а сейчас решил попробовать grelan, мол, прямо в ядре, минимум нагрузки. У обеих нод белые айпишники, туннель поднялся без проблем, скорость в самом деле выдал замечательную, под гигабит. Воткнул я его во внутренний бридж, чтобы контейнеры могли между нодами общаться напрямую, присвоил им адреса из одной подсети - замечательно, контейнеры с одной ноды пингуют на другой. Но вот незадача:

root@db1:~# iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 10.10.0.101, port 53276
[  5] local 10.10.0.102 port 5201 connected to 10.10.0.101 port 53278
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  5]   0.00-1.00   sec   384 KBytes  3.15 Mbits/sec    5   1.41 KBytes       
[  5]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes       
[  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
[  5]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes       
[  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
[  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  5]   0.00-5.00   sec   384 KBytes   629 Kbits/sec    7             sender
[  5]   0.00-5.00   sec  0.00 Bytes  0.00 bits/sec                  receiver
iperf3: the client has terminated
То есть трафик толком не ходит. Выкинул grelan из бриджа - всё стало нормально. В чём может быть дело? Маки везде разные. Конфиг сети:
# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp2s0f0
iface enp2s0f0 inet manual

auto vmbr0 # в этот бридж втыкаются виртуалки/контейнеры с белыми адресами
iface vmbr0 inet static 
	address x.x.x.x/29
	gateway x.x.x.y
	bridge_ports enp2s0f0
	bridge_stp off
	bridge_fd 0
	post-up ifup tun0 #и тут же поднимается тоннель до второй ноды
	pre-down ifdown tun0

iface tun0 inet manual
	up ip link add tun0 type gretap local x.x.x.x remote y.y.y.y
	up ip link set tun0 up
	up ip link set tun0 multicast on
	down ip link set tun0 down

auto vmbr1 #внутренний бридж
iface vmbr1 inet static
	address 10.10.0.1/24
	bridge_ports none #вот здесь был tun0
	bridge_stp off
	bridge_fd 0
	post-up echo 1 > /proc/sys/net/ipv4/ip_forward
	post-up   iptables -t nat -A POSTROUTING -s '10.10.0.0/24' -o vmbr0 -j MASQUERADE
	post-down iptables -t nat -D POSTROUTING -s '10.10.0.0/24' -o vmbr0 -j MASQUERADE

Выглядит как проблемы с MTU, но я не уверен. К тому же, почему тогда во внутренней сети были проблемы, а не только с коннектом к другой ноде?

9: tun0@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1462 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 9a:e9:f0:57:69:92 brd ff:ff:ff:ff:ff:ff
24: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether fe:71:56:36:22:bd brd ff:ff:ff:ff:ff:ff
    inet 10.10.0.1/24 brd 10.10.0.255 scope global vmbr1
       valid_lft forever preferred_lft forever

★★★

Последнее исправление: lizard (всего исправлений: 2)

К тому же, почему тогда во внутренней сети были проблемы, а не только с коннектом к другой ноде?

Если MTU выставился большим(1500 вместо 1462) на мосту, то GRE-пакеты у тебя наружу пошли фрагментированные и это может быть проблемой - в локалке это обычно не проблема(хотя тоже зависит от локалки), но если ты их через интернет пускаешь, то пересборка пакетов может быть проблемой

У меня в кластере используется vxlan - всё несколько по-другому:

а) все ноды стоят физически рядом; б) MTU интерфейса равно 8950 (Jumbo frame, 9000 на физических интерфейсах, 50 - накладные расходы самого vxlan);

Соответственно стандартные(1500 байт) пакеты пролезают на ура и фрагментации нет(vxlan в Linux хреново фрагментируется, по крайней мере раньше это было проблемой).

В общем я отвлекся - если подозреваешь проблемы с MTU/фрагментацией - снимай pcap-дамп и смотри wireshark-ом

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

Да, с mtu были проблемы. После добавления tun0 в бридж на нем устанавливался такой же mtu 1462, а на интерфейсах виртуалок оставался 1500. Меня сбило с толку то, что в пределах одной ноды между виртуалками, подключенными к этому бриджу, трафик фрагментировался, а вот при подключении к ноде через опенвпн, который маршрутизировал в подсеть виртуалок через этот же бридж, все было нормально. И с самой ноды проблем с доступом к виртуалкам по сети не было.

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