LINUX.ORG.RU
Форум — Admin  

GRE Потери пакетов, странное поведение сети

 


0

1

Уважаемые форумчане, подскажите кто и что знает. Есть сервер, условно «А» - основной(source), от которого идут все IP на другие сервера, а так же 15 других(destination ip) условно «1,2,3,4» и тд.

Появилась очень странная проблема, которая не поддаётся никакой логике. Появились потери пакетов, именно на IP которые идут в туннель. Например 155.44.33.22 - находится на сервере «А», по GRE идёт в сервер «1» При пинге 155.44.33.22, есть потери примерно 20%. Между серверами «А» и «1», при прямой проверке связи, вообще всё отлично. Но, при проверке пинга внутри туннеля, по локальному адресу например 192.168.0.50, есть потери, от чего потери идут уже и на внешнем адресе.

Что очень интересно, то если проблема появляется, то только в таком виде:

64 bytes from 155.44.33.22: icmp_seq=215 ttl=51 time=61.221 ms
64 bytes from 155.44.33.22: icmp_seq=216 ttl=51 time=54.311 ms
64 bytes from 155.44.33.22: icmp_seq=217 ttl=51 time=49.040 ms
64 bytes from 155.44.33.22: icmp_seq=218 ttl=51 time=51.325 ms
Request timeout for icmp_seq 219
64 bytes from 155.44.33.22: icmp_seq=220 ttl=51 time=49.756 ms
64 bytes from 155.44.33.22: icmp_seq=221 ttl=51 time=53.280 ms
64 bytes from 155.44.33.22: icmp_seq=222 ttl=51 time=52.730 ms
64 bytes from 155.44.33.22: icmp_seq=223 ttl=51 time=52.830 ms
Request timeout for icmp_seq 224
64 bytes from 155.44.33.22: icmp_seq=225 ttl=51 time=54.453 ms
64 bytes from 155.44.33.22: icmp_seq=226 ttl=51 time=51.656 ms
64 bytes from 155.44.33.22: icmp_seq=227 ttl=51 time=53.333 ms
64 bytes from 155.44.33.22: icmp_seq=228 ttl=51 time=52.741 ms
Request timeout for icmp_seq 229
64 bytes from 155.44.33.22: icmp_seq=230 ttl=51 time=51.533 ms
64 bytes from 155.44.33.22: icmp_seq=231 ttl=51 time=59.256 ms
64 bytes from 155.44.33.22: icmp_seq=232 ttl=51 time=50.136 ms
64 bytes from 155.44.33.22: icmp_seq=233 ttl=51 time=53.572 ms
Request timeout for icmp_seq 234
64 bytes from 155.44.33.22: icmp_seq=235 ttl=51 time=51.787 ms
64 bytes from 155.44.33.22: icmp_seq=236 ttl=51 time=51.866 ms
64 bytes from 155.44.33.22: icmp_seq=237 ttl=51 time=51.229 ms
64 bytes from 155.44.33.22: icmp_seq=238 ttl=51 time=50.872 ms
Request timeout for icmp_seq 239

Видно закономерность потери пинга. Тоже самое по локальному IP, между серверами на которых туннель.

64 bytes from 192.168.0.50: icmp_seq=85 ttl=64 time=7.79 ms
64 bytes from 192.168.0.50: icmp_seq=86 ttl=64 time=7.75 ms
64 bytes from 192.168.0.50: icmp_seq=87 ttl=64 time=7.77 ms
64 bytes from 192.168.0.50: icmp_seq=88 ttl=64 time=7.75 ms
64 bytes from 192.168.0.50: icmp_seq=90 ttl=64 time=7.74 ms
64 bytes from 192.168.0.50: icmp_seq=91 ttl=64 time=7.73 ms
64 bytes from 192.168.0.50: icmp_seq=92 ttl=64 time=7.76 ms
64 bytes from 192.168.0.50: icmp_seq=93 ttl=64 time=7.73 ms
64 bytes from 192.168.0.50: icmp_seq=95 ttl=64 time=7.95 ms
64 bytes from 192.168.0.50: icmp_seq=96 ttl=64 time=7.73 ms
64 bytes from 192.168.0.50: icmp_seq=97 ttl=64 time=7.73 ms
64 bytes from 192.168.0.50: icmp_seq=98 ttl=64 time=7.88 ms
64 bytes from 192.168.0.50: icmp_seq=100 ttl=64 time=7.77 ms
64 bytes from 192.168.0.50: icmp_seq=101 ttl=64 time=7.74 ms
64 bytes from 192.168.0.50: icmp_seq=102 ttl=64 time=7.74 ms
64 bytes from 192.168.0.50: icmp_seq=103 ttl=64 time=7.76 ms
64 bytes from 192.168.0.50: icmp_seq=105 ttl=64 time=7.73 ms
64 bytes from 192.168.0.50: icmp_seq=106 ttl=64 time=7.75 ms
64 bytes from 192.168.0.50: icmp_seq=107 ttl=64 time=7.76 ms

Каждый 5 пакет, потеря. Буфер сетевой карты увеличил до максимальных значений, в dmesg никаких проблем нет от слова совсем. Правила iptables кристально чисты. Что это может быть и что делать?

При этом, проблема частичная, она может не затрагивать часть туннелей, пинг по ним будет без потерь, а потом опять так же их затронуть, начнутся потери на какой-то период, а другие при этом начнут работать без потерь, и так по кругу.

irqbalance стоит, руками в прерывания не лазил, нагрузка 40-50к pps всего, до 100мб\c, обычно 50. Нагрузка на канал, в моменты потери пинга, падает до 20мб\c, из 40-50, т.е грубо говоря в половину, но не полностью.

забыл уточнить, еще есть bridge интерфейс, на сервере крутится несколько виртуалок через proxmox, а так как основной настроен как «inet manual», то и туннель работает через интерфейс vmbr0 Возможна ли проблема здесь?



Последнее исправление: frealy121212 (всего исправлений: 3)
← Как установить и пользоваться distrobuilder?
Thunar зависает. →

Пакеты внутри локалки ходят или это вы про проблемы загруженых каналов у провайдера, где приоритет отдан icmp/tcp, а не GRE?

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

пакеты ходят внутри gre туннеля, между разными ДЦ в принципе. Но так как проблема на всех серверах и по очереди, то логично что виноват только «А», но пока не понятно, это проблема в конфиге либо еще в чём-то. Ваше предположение, что проблемы у самого провайдера, сервера «А» ?

frealy121212
() автор топика

rate-limit icmp какой нить на пингуемом IP. не?[br] с двух сторон или на разных сетевых интерфейсах tcpdump ом пакеты снифать и смотреть где теряются

Vlad-76 ★★★★
()
Ответ на: комментарий от Vlad-76 
[No response seen]
    [Expert Info (Warning/Sequence): No response seen to ICMP request]
        [No response seen to ICMP request]
        [Severity level: Warning]
        [Group: Sequence]
Timestamp from icmp data: Mar 14, 2020 12:56:28.000000000 CET
[Timestamp from icmp data (relative): 0.532578000 seconds]
Data (48 bytes)

как-то так 2 запроса, на один подобная инфа, ответа на него нет.

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

вот скрин как это выглядит со стороны EKRANA-2020-03-14-V-13.15.09.png

т.е 2 разных ип, 2 разных туннеля, но источних у них один, сервер «А», потом эта ситуация или уравняется, или поменяется местами. никаких лимитов на icmp запросы нет, я просто в недоумении.

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

1350 изначально стояло на всех туннелях ставил 1200, разницы никакой, mss менял и указывал так же на 40 меньше чем mtu

frealy121212
() автор топика
Ответ на: комментарий от frealy121212 
tc qdisc
qdisc noqueue 0: dev lo root refcnt 2 
qdisc mq 0: dev enp1s0 root 
qdisc pfifo_fast 0: dev enp1s0 parent :4 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev enp1s0 parent :3 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev enp1s0 parent :2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev enp1s0 parent :1 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc noqueue 0: dev vmbr0 root refcnt 2 
qdisc noqueue 0: dev tun0 root refcnt 2 
qdisc noqueue 0: dev tun1 root refcnt 2 
qdisc noqueue 0: dev tun2 root refcnt 2 
qdisc noqueue 0: dev tun4 root refcnt 2 
qdisc noqueue 0: dev tun13 root refcnt 2 
qdisc noqueue 0: dev tun15 root refcnt 2 
qdisc noqueue 0: dev tun16 root refcnt 2 
qdisc noqueue 0: dev tun17 root refcnt 2 
qdisc noqueue 0: dev tun18 root refcnt 2 
qdisc noqueue 0: dev veth102i0 root refcnt 2 
qdisc noqueue 0: dev fwbr102i0 root refcnt 2 
qdisc noqueue 0: dev fwpr102p0 root refcnt 2 
qdisc noqueue 0: dev fwln102i0 root refcnt 2 
qdisc htb 1: dev veth103i0 root refcnt 2 r2q 10 default 0x1 direct_packets_stat 0 direct_qlen 1000
qdisc ingress ffff: dev veth103i0 parent ffff:fff1 ---------------- 
qdisc noqueue 0: dev fwbr103i0 root refcnt 2 
qdisc noqueue 0: dev fwpr103p0 root refcnt 2 
qdisc noqueue 0: dev fwln103i0 root refcnt 2 
qdisc htb 1: dev veth100i0 root refcnt 2 r2q 10 default 0x1 direct_packets_stat 0 direct_qlen 1000
qdisc ingress ffff: dev veth100i0 parent ffff:fff1 ---------------- 
qdisc noqueue 0: dev fwbr100i0 root refcnt 2 
qdisc noqueue 0: dev fwpr100p0 root refcnt 2 
qdisc noqueue 0: dev fwln103i0 root refcnt 2 
qdisc htb 1: dev veth100i0 root refcnt 2 r2q 10 default 0x1 direct_packets_stat 0 direct_qlen 1000
qdisc ingress ffff: dev veth100i0 parent ffff:fff1 ---------------- 
qdisc noqueue 0: dev fwbr100i0 root refcnt 2 
qdisc noqueue 0: dev fwpr100p0 root refcnt 2 
qdisc noqueue 0: dev fwln100i0 root refcnt 2 
qdisc noqueue 0: dev veth101i0 root refcnt 2 
qdisc noqueue 0: dev fwbr101i0 root refcnt 2 
qdisc noqueue 0: dev fwpr101p0 root refcnt 2 
qdisc noqueue 0: dev fwln101i0 root refcnt 2 
qdisc htb 1: dev veth104i0 root refcnt 2 r2q 10 default 0x1 direct_packets_stat 0 direct_qlen 1000
qdisc ingress ffff: dev veth104i0 parent ffff:fff1 ---------------- 
qdisc noqueue 0: dev fwbr104i0 root refcnt 2 
qdisc noqueue 0: dev fwpr104p0 root refcnt 2 
qdisc noqueue 0: dev fwln104i0 root refcnt 2 
qdisc noqueue 0: dev tun5 root refcnt 2 
qdisc noqueue 0: dev tun7 root refcnt 2 
qdisc noqueue 0: dev tun3 root refcnt 2

может быть проблемой?

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

Всякое GRO, LRO на enp1s0 случаем не включено?

а смысл? На мелких пакетах оно не проявляется.

vel ★★★★★
()

Не пробовали запускать пинг не раз в секунду, а хотя бы 100 раз/сек ping -i 0.01 -c 1000 -q ...?

Если есть icmp rate-limit, то потери возрастут многократно.

ping/icmp не лучший показатель потерь в современном мире c dpi.

iperf3 в udp режиме не пробовали запускать?

Может там появление потерь будет более явно наблюдаться?

Хорошо бы убедиться, что пакеты посылаются в сеть. Тогда это будет говорить о проблемах по пути.

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

я на всё это, решил проверить по другому. запустил просто udp игровой сервер КС 1.6, посидел на нём, заметил дикие рывки, те же самые каждые 4-5 секунд и потери до 30-40% в эту секунду. Для уверенности сделал ребут сервера с туннелями, создал еще один тунель вообще в другой дата-центр, ситуация идентичная.

Самое смешное, что сервера не видят dropped пакетов, они везде по 0

Сделал пинг по ping -i 0.01 -c 1000 -q 1000 packets transmitted, 968 received, 3.2% packet loss, time 180ms rtt min/avg/max/mdev = 7.730/7.777/7.965/0.121 ms

Ну как бы потери есть, но они явно не 10-20% как это на обычном тесте проявляется, они просто не успели столько раз вылезти за короткий промежуток времени.

c -s qdisc | grep dropped
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 94439363695 bytes 605529250 pkt (dropped 0, overlimits 0 requeues 723) 
 Sent 21619298748 bytes 130375022 pkt (dropped 0, overlimits 0 requeues 189) 
 Sent 26880363133 bytes 172614480 pkt (dropped 0, overlimits 0 requeues 179) 
 Sent 26562985261 bytes 180740888 pkt (dropped 0, overlimits 0 requeues 196) 
 Sent 19376716553 bytes 121798860 pkt (dropped 0, overlimits 0 requeues 159) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 573112544 bytes 9235752 pkt (dropped 0, overlimits 1271 requeues 0) 
 Sent 866362240 bytes 712679 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 1263676407 bytes 11826292 pkt (dropped 0, overlimits 73866 requeues 0) 
 Sent 703154558 bytes 3047400 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 623332939 bytes 9421181 pkt (dropped 0, overlimits 2459 requeues 0) 
 Sent 102237098 bytes 520171 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

Везде по нулям так же. overlimits не совсем понятно

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

iperf3 вещает потерю скорости в моменты падения пинга.

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  7.83 MBytes  65.7 Mbits/sec    0    133 KBytes       
[  5]   1.00-2.00   sec  7.60 MBytes  63.8 Mbits/sec    0    133 KBytes       
[  5]   2.00-3.00   sec  7.76 MBytes  65.1 Mbits/sec    0    133 KBytes       
[  5]   3.00-4.00   sec  3.68 MBytes  30.8 Mbits/sec    2   1.12 KBytes       
[  5]   4.00-5.00   sec  6.47 MBytes  54.3 Mbits/sec    1    133 KBytes       
[  5]   5.00-6.00   sec  7.57 MBytes  63.5 Mbits/sec    0    133 KBytes       
[  5]   6.00-7.00   sec  7.73 MBytes  64.8 Mbits/sec    0    133 KBytes       
[  5]   7.00-8.00   sec  7.57 MBytes  63.5 Mbits/sec    0    133 KBytes       
[  5]   8.00-9.00   sec  3.31 MBytes  27.8 Mbits/sec    2   1.12 KBytes       
[  5]   9.00-10.00  sec  6.84 MBytes  57.4 Mbits/sec    1    133 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  66.3 MBytes  55.7 Mbits/sec    6             sender
[  5]   0.00-10.01  sec  65.9 MBytes  55.3 Mbits/sec                  receiver
frealy121212
() автор топика
Ответ на: комментарий от frealy121212

А при проверке напрямую, не через GRE, всё ок.

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  8.19 MBytes  68.7 Mbits/sec    0    137 KBytes       
[  5]   1.00-2.00   sec  7.72 MBytes  64.7 Mbits/sec    0    137 KBytes       
[  5]   2.00-3.00   sec  7.41 MBytes  62.2 Mbits/sec    0    137 KBytes       
[  5]   3.00-4.00   sec  7.69 MBytes  64.5 Mbits/sec    0    137 KBytes       
[  5]   4.00-5.00   sec  7.66 MBytes  64.2 Mbits/sec    0    137 KBytes       
[  5]   5.00-6.00   sec  7.75 MBytes  65.0 Mbits/sec    0    137 KBytes       
[  5]   6.00-7.00   sec  7.41 MBytes  62.2 Mbits/sec    0    137 KBytes       
[  5]   7.00-8.00   sec  7.66 MBytes  64.2 Mbits/sec    0    137 KBytes       
[  5]   8.00-9.00   sec  7.66 MBytes  64.2 Mbits/sec    0    137 KBytes       
[  5]   9.00-10.00  sec  7.66 MBytes  64.2 Mbits/sec    0    137 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  76.8 MBytes  64.4 Mbits/sec    0             sender
[  5]   0.00-10.01  sec  76.3 MBytes  63.9 Mbits/sec                  receiver
frealy121212
() автор топика
Ответ на: комментарий от frealy121212

выбором точки съема информации для tcpdump
ping запускаете - и в разных местах (с интерфейсов) снимаете
gre тунель в системе - это какой то интерфейс?
цепочку интерфейсов (маршрут пакета)нарисуйте до удаленного icmp linux box и снимайте. Может быть пакет теряется на участке до удаленного linux, может в обратную сторону.

Вы писали что у Вас vmbr0 в системе есть. Это элемент цепочки, с которого можно снять информацию tcpdump.

Vlad-76 ★★★★
()
Последнее исправление: Vlad-76 (всего исправлений: 3)
Ответ на: комментарий от frealy121212

overlimits - фактически это дроп. На сколько я помню, это удаление пакета из очереди, который превысил свое время ожидания отправки.

А на каких интерфейсах этот оверлимит растет?

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

Посмотри, не упирается ли в это время все в производительность процессора (mpstat). Возможно softirq в какие-то моменты под 100%

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

еще есть сетевухи которые внутри себя умеют разбирать пакет и применять к нему правила (по типу iptables). могут ли они таким образом icmp rate limit внутри gre - ХЗ.

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

ну немного увидел ситуацию.

получается так.

пакет идёт на основной сервер «А», оттуда уходит в туннель, сервер за туннелем, пусть будет «B» отвечает на пинг, возвращает ответ назад, сервер «А» его не принимает. Именно этот момент потеря пинга.

т.е сервер «B» который идёт туннель, пишет такое

14:19:44.496496 IP 89.99.99.99 > 196.7.7.7: ICMP echo request, id 46666, seq 209, length 64
14:19:44.496519 IP 196.7.7.7 > 89.99.99.99: ICMP echo reply, id 46666, seq 209, length 64

А сервер с которого этот туннель идёт «А», видит такое.

11:20:39.647212 IP 196.7.7.7 > 89.99.99.99: ICMP echo reply, id 46666, seq 264, length 64
11:20:40.649480 IP 89.99.99.99 > 196.7.7.7: ICMP echo request, id 46666, seq 265, length 64
11:20:41.651908 IP 89.99.99.99 > 196.7.7.7: ICMP echo request, id 46666, seq 266, length 64
11:20:41.659634 IP 196.7.7.7 > 89.99.99.99: ICMP echo reply, id 46666, seq 266, length 64

Получается, если сервер «В» ответ даёт и отправляет, но он не доходит до сервера «А», и так с любыми разными серверами, виноват только «А», то где искать дальше

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

если поменять ip tunnel mode gre на mode ipip то сервер «А» вообще не принимает никакие пакеты, но при этом отправляет, а сервер «В» и принимает и отправляет. Сервер «А», в ОВХ, видимо, что-то они накрутили на туннельные пакеты.

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

GRE пакеты, в которых icmp ответы от В к А, на физическом сетевом интерфейсе сервера А вы видите?

а gre при помощи чего настраивали? это модуль ядра? в системе есть какой нить tun (tap) интерфейс для туннеля? на нем tcpdump что показывает?
дебаг gre пакетов есть какой нить?
может в вашем ядре + модуле для gre туннелей что нить сломали. попробуйте ядро (+ модуль) поменять

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

не приходят ответы до сервера А от В момент потери.

gre там нормально настроен, обычный модуль стандартный, modprobe ip_gre и поехали.

создан tun интерфейс, со всеми настройками ip адресов и тунеля ip tunnel add mod gre и тд

ядро и модуль, не трогались совершенно, так как работали более месяца, до четверга 12.03.2020, отлично и без всяких потерь, потом резко началось, это точно исключено

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

«не приходят ответы до сервера А от В момент потери.»
ну если так, учитывая что вы точно (точно?) диагностировали что B отправил с физического интерфейса в сторону А GRE (с инкапсулированным icmp ответом)пакет, то проблема на стороне провайдера.

PS Вы точно на физ интерфейсах видели на B и не видели на А пакеты ?

Vlad-76 ★★★★
()
Последнее исправление: Vlad-76 (всего исправлений: 1)
Ответ на: комментарий от Vlad-76

в смысле) 2 сервера. один в ОВХ, другой в Хетзнере, что я пущу через телефон, мой пинг? Я же говорю, запустил с двух сторон tcpdump и сидел пинговал, затык происходит на сервере ОВХ, он пакет обратно не принимает, что бы дать ответ об успешном пинге.

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

tcpdump в данном случае лучше запускать интерфейсе через который идет gre 

tcpdump -ni XXX  -v proto gre and host YYYY
если там напряженный трафик, то записать это в файл, а потом смортеть

Если у тебя именно локальные дропы, то будет видно получение пакета gre, а icmp ответ не всегда будеп приходить.

Если gre не приходит, значит проблема где-то по пути.

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

не совсем понял что за каналы у тебя, это каналы между дата центрами ? В смысле в них вообще можно сомневаться ?

Если канал проседает по скорости что видно в айперфе то зачем ты мучаешься ? обратись к провайдеру. Или этот iperf в гре тунеле сделан ?

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

в том и проблема, что напрямую проблем нет, только через GRE трафик она появляется. сейчас, относительно утро, нагрузка на канал 25мб/с туда/обратно, это половина от вечерней, никаких проблем вообще нет, всё работает идеально, то я предполагаю, что где-то висяк у самого дата-центра, перегружены каналы и GRE по приоритизации, не пролазит.

frealy121212
() автор топика
Ответ на: комментарий от Vlad-76

могу сказать с уверенностью, что проблема была на стороне OVH. после долгих писанин и звонка в поддержку, проблема сама по себе решилась, без шаманства на сервере, всем спасибо, возможно кому-то тема поможет, но овх по прежнему пишет шаблонные ответы в виде «сделайте тест mtr» и тд.

frealy121212
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Как установить и пользоваться distrobuilder?
Admin
Thunar зависает. →