Выдача MTU через туннели GRE - PullRequest
Новая
       84

Выдача MTU через туннели GRE

0 голосов
/ 23 октября 2019

У меня проблема с туннелями GRE и MTU. Это моя топология: https://user -images.githubusercontent.com / 40271438 / 67222183-171d1b80-f42d-11e9-8ffa-f032a84b6280.png

Прежде всего, я объяснюмоя топология.

У меня 3 сайта с 2 маршрутизаторами на сайт (на самом деле у нас 9 сайтов, но в данном случае для понимания моей проблемы требуется только 3 сайта).

  • OrangeМаршрутизатор является основным для каждого сайта (шлюз по умолчанию для сервера), а серый - резервным маршрутизатором (по протоколу VRRP)
  • На рисунке все зеленые ссылки - это IPSEC VPN-туннели, смонтированные с StrongSwan.
  • В этих туннелях имеется интерфейс GRE, который монтирует туннель GRE между узлами на каждой стороне VPN IPSEC (туннели и GRE IP выделены черным цветом на рисунке).
  • Каждый узел имеет адрес обратной связи (IP всинее на рисунке).
  • Конечно, каждый узел имеет IP-адрес локальной сети (IP на нем зеленым цветом).
  • Каждый узел также имеет конфигурацию BGP для объявления сетей с маршрутизаторами.
  • Каждый роутер на Linux Ubuntu 18.04.3

У меня странная проблема с MTU, когда 2 сервера должны взаимодействовать через эту инфраструктуру. Когда я проверяю связь с сервером 10.55.0.69 из 172.16.97.2 (черные серверы на рисунке), все работает правильно, и я могу видеть трафик, входящий и выходящий из маршрутизаторов. 

ping 10.55.0.69
PING 10.55.0.69 (10.55.0.69) 56(84) bytes of data.
64 bytes from 10.55.0.69: icmp_seq=1 ttl=60 time=13.6 ms
64 bytes from 10.55.0.69: icmp_seq=2 ttl=60 time=13.9 ms
64 bytes from 10.55.0.69: icmp_seq=3 ttl=60 time=13.9 ms
64 bytes from 10.55.0.69: icmp_seq=4 ttl=60 time=14.1 ms
^C
--- 10.55.0.69 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 13.675/13.947/14.169/0.228 ms

На оранжевом маршрутизаторе включенсайт 8 (ближайший к целевому серверу) я сделал этот захват (все в порядке): 

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens160, link-type EN10MB (Ethernet), capture size 262144 bytes
08:25:48.562284 IP 172.16.97.2 > 10.55.0.69: ICMP echo request, id 37119, seq 1, length 64
08:25:48.562389 IP 10.55.0.69 > 172.16.97.2: ICMP echo reply, id 37119, seq 1, length 64
08:25:49.563329 IP 172.16.97.2 > 10.55.0.69: ICMP echo request, id 37119, seq 2, length 64
08:25:49.563449 IP 10.55.0.69 > 172.16.97.2: ICMP echo reply, id 37119, seq 2, length 64
08:25:50.564448 IP 172.16.97.2 > 10.55.0.69: ICMP echo request, id 37119, seq 3, length 64
08:25:50.564593 IP 10.55.0.69 > 172.16.97.2: ICMP echo reply, id 37119, seq 3, length 64
08:25:51.565591 IP 172.16.97.2 > 10.55.0.69: ICMP echo request, id 37119, seq 4, length 64
08:25:51.565736 IP 10.55.0.69 > 172.16.97.2: ICMP echo reply, id 37119, seq 4, length 64
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel

Теперь я отправляю тот же пинг, без инструкции фрагмента и 1300 байт с сервера 172.16.97.2 

ping 10.55.0.69 -s 1300 -M do
PING 10.55.0.69 (10.55.0.69) 1300(1328) bytes of data.
From 10.255.0.73 icmp_seq=1 Frag needed and DF set (mtu = 894)
ping: local error: Message too long, mtu=894
ping: local error: Message too long, mtu=894
ping: local error: Message too long, mtu=894
ping: local error: Message too long, mtu=894
ping: local error: Message too long, mtu=894
ping: local error: Message too long, mtu=894
ping: local error: Message too long, mtu=894
^C
--- 10.55.0.69 ping statistics ---
8 packets transmitted, 0 received, +8 errors, 100% packet loss, time 7040ms

Сетевой захват на оранжевом маршрутизаторе на сайте 7 

tcpdump -ni any host 172.16.97.2 and icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
08:32:27.586718 IP 172.16.97.2 > 10.55.0.69: ICMP echo request, id 37658, seq 1, length 1308
08:32:27.586751 IP 172.16.97.2 > 10.55.0.69: ICMP echo request, id 37658, seq 1, length 1308
08:32:27.598692 IP 10.255.0.73 > 172.16.97.2: ICMP 10.55.0.69 unreachable - need to frag (mtu 894), length 556
08:32:27.598705 IP 10.255.0.73 > 172.16.97.2: ICMP 10.55.0.69 unreachable - need to frag (mtu 894), length 556
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

Сетевой захват на оранжевом маршрутизаторе на сайте 2 

tcpdump -ni any host 172.16.97.2 and icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
08:32:27.596503 IP 172.16.97.2 > 10.55.0.69: ICMP echo request, id 37658, seq 1, length 1308
08:32:27.596527 IP 172.16.97.2 > 10.55.0.69: ICMP echo request, id 37658, seq 1, length 1308
08:32:27.596548 IP 10.255.0.73 > 172.16.97.2: ICMP 10.55.0.69 unreachable - need to frag (mtu 894), length 556
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel

Получить маршрут и MTU на оранжевом маршрутизаторе наСайт 7 

ip route get to 10.55.0.69
10.55.0.69 via 10.255.0.73 dev tunnel18 src 10.255.0.74 uid 0
cache expires 309sec mtu 1398

Получение маршрута и MTU на оранжевом маршрутизаторе на сайте 2 

ip route get to 10.55.0.69
10.55.0.69 via 10.255.0.97 dev tunnel24 src 10.255.0.98 uid 0
cache expires 329sec mtu 894

Попробуем уменьшить размер пинга до 800 байт (из-за истечения срока действия кэша 329сек. предыдущая команда) 

ping 10.55.0.69 -s 800 -M do
PING 10.55.0.69 (10.55.0.69) 800(828) bytes of data.
From 10.255.0.73 icmp_seq=1 Frag needed and DF set (mtu = 606)
ping: local error: Message too long, mtu=606
ping: local error: Message too long, mtu=606
ping: local error: Message too long, mtu=606
ping: local error: Message too long, mtu=606
^C
--- 10.55.0.69 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4024ms

Сетевой захват на оранжевом маршрутизаторе на сайте 7 

tcpdump -ni any host 172.16.97.2 and icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
08:39:42.735130 IP 172.16.97.2 > 10.55.0.69: ICMP echo request, id 38450, seq 1, length 808
08:39:42.735143 IP 172.16.97.2 > 10.55.0.69: ICMP echo request, id 38450, seq 1, length 808
08:39:42.746899 IP 10.255.0.73 > 172.16.97.2: ICMP 10.55.0.69 unreachable - need to frag (mtu 606), length 556
08:39:42.746911 IP 10.255.0.73 > 172.16.97.2: ICMP 10.55.0.69 unreachable - need to frag (mtu 606), length 556
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

ip route get to 10.55.0.69
10.55.0.69 via 10.255.0.73 dev tunnel18 src 10.255.0.74 uid 0
cache expires 582sec mtu 1398

Сетевой захват на оранжевом маршрутизаторе на сайте 2 

tcpdump -ni any host 172.16.97.2 and icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
08:39:42.745058 IP 172.16.97.2 > 10.55.0.69: ICMP echo request, id 38450, seq 1, length 808
08:39:42.745126 IP 172.16.97.2 > 10.55.0.69: ICMP echo request, id 38450, seq 1, length 808
08:39:42.745160 IP 10.255.0.73 > 172.16.97.2: ICMP 10.55.0.69 unreachable - need to frag (mtu 606), length 556
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel

ip route get to 10.55.0.69
10.55.0.69 via 10.255.0.97 dev tunnel24 src 10.255.0.98 uid 0
cache expires 582sec mtu 606

Странно, MTU уменьшился с 894 до 606 байтов

AlИтак, во время другого теста у меня была странная вещь (кажется, что MTU динамически обновлялся ...): 

ping 10.55.0.69 -s 1010 -M do
PING 10.55.0.69 (10.55.0.69) 1010(1038) bytes of data.
1018 bytes from 10.55.0.69: icmp_seq=1 ttl=60 time=13.7 ms
1018 bytes from 10.55.0.69: icmp_seq=2 ttl=60 time=13.8 ms
1018 bytes from 10.55.0.69: icmp_seq=3 ttl=60 time=14.1 ms
1018 bytes from 10.55.0.69: icmp_seq=4 ttl=60 time=14.2 ms
1018 bytes from 10.55.0.69: icmp_seq=5 ttl=60 time=13.9 ms
From 10.255.0.73 icmp_seq=6 Frag needed and DF set (mtu = 966)
ping: local error: Message too long, mtu=966
ping: local error: Message too long, mtu=966
ping: local error: Message too long, mtu=966
ping: local error: Message too long, mtu=966
ping: local error: Message too long, mtu=966
^C
--- 10.55.0.69 ping statistics ---
11 packets transmitted, 5 received, +6 errors, 54% packet loss, time 10040ms
rtt min/avg/max/mdev = 13.759/14.000/14.297/0.226 ms

Мой вопрос: почему MTU динамически уменьшается таким образом? Я знаю, что есть инкапсуляция GRE, но это не объясняет, почему она так сильно уменьшилась. Я надеюсь, что предоставил достаточно информации для решения моей проблемы:)

Спасибо

...