Приветствую.
Имеется следующий конфиг: несколько серверов, объединенных в «локальную сеть» путем соединения каждого с каждым используя GRE туннели (vpntapX), зашифрованные с помощью IPSec, на каждом сервере туннели объединены в мост (vpnbr0), таким образом все сервера как будто включены в один коммутатор.
Если у кого-то есть лучший вариант реализации full-mesh сети поверх интернет - с радостью выслушаю, но текущее решение работало прилично до настоящего момент когда понадобилось добавить 4-й сервер.
Каждый сервер отвечает за свою подсеть в которой «живут» виртуалки, для маршрутизации используется Quagga (OSPF, Zebra) 3 старых сервера на Debian 7 работают нормально, OSPF корректно ходит по туннелям, а вот с новым на Debian 8 проблема, мультикаст нормально проходит через туннели, а OSPF Hello - нет.
Версии ОС и ПО
Старые сервера
- Debian 7 (Proxmox 3)
Linux pve01 2.6.32-30-pve #1 SMP Wed Jun 25 05:54:15 CEST 2014 x86_64 GNU/Linux
quagga 0.99.22.4-1+wheezy1
Новый сервер
- Debian 8 (Proxmox 4)
Linux pve03 4.4.35-2-pve #1 SMP Mon Jan 9 10:21:44 CET 2017 x86_64 GNU/Linux
quagga 0.99.23.1-1+deb8u3
Настройка сети
Хорошие IP - где все работает
- 172.20.128.1
- 172.20.128.2
- 172.20.128.254
Проблемный IP - где не работает OSPF
- 172.20.128.3
VPN туннель:
ip address show vpntap1
8: vpntap1@NONE: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast master vpnbr0 state UNKNOWN group default qlen 1000
link/ether 4a:6c:b9:b6:47:06 brd ff:ff:ff:ff:ff:ff
brctl show vpnbr0
bridge name bridge id STP enabled interfaces
vpnbr0 8000.fa8d12bcc999 no vpntap1
vpntap2
vpntap3
ip address show vpnbr0
131: vpnbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN
link/ether fa:8d:12:bc:c9:99 brd ff:ff:ff:ff:ff:ff
inet 172.20.128.1/24 brd 172.20.128.255 scope global vpnbr0
inet6 fe80::f88d:12ff:febc:c999/64 scope link
valid_lft forever preferred_lft forever
auto vpntap1
iface vpntap1 inet manual
pre-up ip link add $IFACE type gretap local A.B.C.D remote X.Z.Y.F key 123456
post-up ip link set $IFACE mtu 1400 || true
post-down ip link delete $IFACE
auto vpntap2
iface vpntap2 inet manual
pre-up ip link add $IFACE type gretap local A.B.C.D remote Q.W.E.R key 123456
post-up ip link set $IFACE mtu 1400 || true
post-down ip link delete $IFACE
auto vpntap3
iface vpntap3 inet manual
pre-up ip link add $IFACE type gretap local A.B.C.D remote A.B.Z.Y key 123456
post-up ip link set $IFACE mtu 1400 || true
post-down ip link delete $IFACE
auto vpnbr0
iface vpnbr0 inet static
address 172.20.128.1
netmask 255.255.255.0
bridge_ports regex vpntap[1-9].*
# We don't want disabled links so STP off
bridge_stp off
bridge_fd 2
bridge_maxwait 5
# Do not forward packets over "ports" we don't want broascast storms
pre-up ebtables -A FORWARD --logical-in $IFACE --j DROP
post-down ebtables -D FORWARD --logical-in $IFACE --j DROP
# Route all multicast to this interface
post-up ip route add 224.0.0.0/4 dev $IFACE
pre-down ip route del 224.0.0.0/4 dev $IFACE
# Clamp MSS to PMTU
post-up iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu -m comment --comment "$IFACE"
pre-down iptables -t mangle -D POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o $IFACE -j TCPMSS --clamp-mss-to-pmtu -m comment --comment "$IFACE"
# Disable multicast snooping
post-up echo 0 > /sys/devices/virtual/net/vpnbr0/bridge/multicast_snooping
Маршруты
На 172.20.128.1
видим сети добавленные Quagga.
ip ro
172.20.252.2 via 172.20.128.2 dev vpnbr0 proto zebra metric 20
172.20.252.254 via 172.20.128.254 dev vpnbr0 proto zebra metric 20
A.B.C.F/27 dev vmbr0 proto kernel scope link src A.B.C.D
172.20.128.0/24 dev vpnbr0 proto kernel scope link src 172.20.128.1
172.21.254.0/24 via 172.20.128.254 dev vpnbr0 proto zebra metric 20
10.17.1.0/24 dev tun0 proto kernel scope link src 10.17.1.1
172.21.2.0/24 via 172.20.128.2 dev vpnbr0 proto zebra metric 20
172.21.1.0/24 dev vmbr1 proto kernel scope link src 172.21.1.1
224.0.0.0/4 dev vpnbr0 scope link
default via A.B.C.Z dev vmbr0
На 172.20.128.3
только локальные маршруты.
ip ro
default via Q.W.E.F dev vmbr0
Q.W.E.Z/26 dev vmbr0 proto kernel scope link src Q.W.E.D
172.20.128.0/24 dev vpnbr0 proto kernel scope link src 172.20.128.3
172.21.3.0/24 dev vmbr1 proto kernel scope link src 172.21.3.1
224.0.0.0/4 dev vpnbr0 scope link
Диагностическая информация, ospf, tcpdump
Как видно рабочие сервера вообще не видят новый сервер, потому что OSPF Hello не доходит до них.
show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL
172.20.252.2 1 Full/DR 36.509s 172.20.128.2 vpnbr0:172.20.128.1 0 0 0
172.20.252.254 1 Full/Backup 35.370s 172.20.128.254 vpnbr0:172.20.128.1 0 0 0
На 172.20.128.1
видны OSPF Hello всех серверов кроме нового.
tcpdump -ni vpnbr0 proto ospf
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vpnbr0, link-type EN10MB (Ethernet), capture size 65535 bytes
18:45:42.335682 IP 172.20.128.254 > 224.0.0.5: OSPFv2, Hello, length 52
18:45:43.468166 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
18:45:43.469742 IP 172.20.128.2 > 224.0.0.5: OSPFv2, Hello, length 52
18:45:52.336008 IP 172.20.128.254 > 224.0.0.5: OSPFv2, Hello, length 52
18:45:53.468557 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
18:45:53.470197 IP 172.20.128.2 > 224.0.0.5: OSPFv2, Hello, length 52
Новый сервер видит всех соседей, но висит в Init, видимо потому, что его никто не видит.
Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL
172.20.252.1 1 Init/DROther 31.781s 172.20.128.1 vpnbr0:172.20.128.3 0 0 0
172.20.252.2 1 Init/DROther 31.782s 172.20.128.2 vpnbr0:172.20.128.3 0 0 0
172.20.252.254 1 Init/DROther 30.647s 172.20.128.254 vpnbr0:172.20.128.3 0 0 0
На проблемный 172.20.128.3
доходят все OSPF Hello
tcpdump -ni vpnbr0 proto ospf
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vpnbr0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:48:02.342019 IP 172.20.128.254 > 224.0.0.5: OSPFv2, Hello, length 52
18:48:03.473027 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
18:48:03.473527 IP 172.20.128.2 > 224.0.0.5: OSPFv2, Hello, length 52
18:48:05.589296 IP 172.20.128.3 > 224.0.0.5: OSPFv2, Hello, length 56
18:48:12.342449 IP 172.20.128.254 > 224.0.0.5: OSPFv2, Hello, length 52
18:48:13.473298 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
18:48:13.473852 IP 172.20.128.2 > 224.0.0.5: OSPFv2, Hello, length 52
18:48:15.589541 IP 172.20.128.3 > 224.0.0.5: OSPFv2, Hello, length 56
Погрузимся глубже, изучим туннель между 172.20.128.3
и 172.20.128.1
Смотрим на 172.20.128.1
, наблюдаем отсутствие OSPF Hello от 172.20.128.3
tcpdump -ni vpntap3 proto ospf
tcpdump: WARNING: vpntap3: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vpntap3, link-type EN10MB (Ethernet), capture size 65535 bytes
19:09:23.511620 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
19:09:33.512082 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
19:09:43.512206 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
19:09:53.512758 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
Смотрим на 172.20.128.3
, наблюдаем OSPF Hello от 172.20.128.1
и 172.20.128.3
tcpdump -ni vpntap3 proto ospf
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vpntap3, link-type EN10MB (Ethernet), capture size 262144 bytes
19:09:33.512349 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
19:09:35.675136 IP 172.20.128.3 > 224.0.0.5: OSPFv2, Hello, length 56
19:09:43.512495 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
19:09:45.675931 IP 172.20.128.3 > 224.0.0.5: OSPFv2, Hello, length 56
19:09:53.513071 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
19:09:55.676709 IP 172.20.128.3 > 224.0.0.5: OSPFv2, Hello, length 56
19:10:03.513473 IP 172.20.128.1 > 224.0.0.5: OSPFv2, Hello, length 52
19:10:05.677474 IP 172.20.128.3 > 224.0.0.5: OSPFv2, Hello, length 56
Таким образом, OSPF Hello проходит через туннель только в одну сторону о.О и понять почему это происходит я никак не могу.
Просто мультикаст ходит через туннель нормально
На 172.20.128.1
ssmpingd
received request from 172.20.128.3
received request from 172.20.128.3
...
# ssmping 172.20.128.1
ssmping joined (S,G) = (172.20.128.1,232.43.211.234)
pinging S from 172.20.128.3
multicast from 172.20.128.1, seq=1 dist=0 time=1.049 ms
unicast from 172.20.128.1, seq=1 dist=0 time=2.733 ms
unicast from 172.20.128.1, seq=2 dist=0 time=1.208 ms
multicast from 172.20.128.1, seq=2 dist=0 time=1.217 ms
...
На 172.20.128.1
omping 172.20.128.1 172.20.128.3
172.20.128.3 : waiting for response msg
172.20.128.3 : waiting for response msg
172.20.128.3 : waiting for response msg
172.20.128.3 : waiting for response msg
172.20.128.3 : joined (S,G) = (*, 232.43.211.234), pinging
172.20.128.3 : unicast, seq=1, size=69 bytes, dist=0, time=0.744ms
172.20.128.3 : multicast, seq=1, size=69 bytes, dist=0, time=0.749ms
172.20.128.3 : unicast, seq=2, size=69 bytes, dist=0, time=0.586ms
172.20.128.3 : multicast, seq=2, size=69 bytes, dist=0, time=0.593ms
172.20.128.3 : unicast, seq=3, size=69 bytes, dist=0, time=0.564ms
172.20.128.3 : multicast, seq=3, size=69 bytes, dist=0, time=0.570ms
172.20.128.3 : unicast, seq=4, size=69 bytes, dist=0, time=1.097ms
172.20.128.3 : multicast, seq=4, size=69 bytes, dist=0, time=1.115ms
172.20.128.3 : unicast, seq=5, size=69 bytes, dist=0, time=0.980ms
172.20.128.3 : multicast, seq=5, size=69 bytes, dist=0, time=0.984ms
172.20.128.3 : waiting for response msg
172.20.128.3 : server told us to stop
172.20.128.3 : unicast, xmt/rcv/%loss = 5/5/0%, min/avg/max/std-dev = 0.564/0.794/1.097/0.237
172.20.128.3 : multicast, xmt/rcv/%loss = 5/5/0%, min/avg/max/std-dev = 0.570/0.802/1.115/0.241
На 172.20.128.3
omping 172.20.128.1 172.20.128.3
172.20.128.1 : waiting for response msg
172.20.128.1 : joined (S,G) = (*, 232.43.211.234), pinging
172.20.128.1 : unicast, seq=1, size=69 bytes, dist=0, time=0.656ms
172.20.128.1 : multicast, seq=1, size=69 bytes, dist=0, time=0.658ms
172.20.128.1 : unicast, seq=2, size=69 bytes, dist=0, time=0.695ms
172.20.128.1 : multicast, seq=2, size=69 bytes, dist=0, time=0.704ms
172.20.128.1 : unicast, seq=3, size=69 bytes, dist=0, time=0.817ms
172.20.128.1 : multicast, seq=3, size=69 bytes, dist=0, time=0.827ms
172.20.128.1 : unicast, seq=4, size=69 bytes, dist=0, time=1.127ms
172.20.128.1 : multicast, seq=4, size=69 bytes, dist=0, time=1.136ms
172.20.128.1 : unicast, seq=5, size=69 bytes, dist=0, time=0.962ms
172.20.128.1 : multicast, seq=5, size=69 bytes, dist=0, time=0.968ms
172.20.128.1 : unicast, seq=6, size=69 bytes, dist=0, time=1.074ms
172.20.128.1 : multicast, seq=6, size=69 bytes, dist=0, time=1.083ms
^C
172.20.128.1 : unicast, xmt/rcv/%loss = 6/6/0%, min/avg/max/std-dev = 0.656/0.888/1.127/0.197
172.20.128.1 : multicast, xmt/rcv/%loss = 6/6/0%, min/avg/max/std-dev = 0.658/0.896/1.136/0.198