Сеть медленная в одном направлении - куда смотреть?

[erix]

Короче, recap for TS:

1. что за hypervisor?
2. что за guest?

[Teh Instructor]

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

1) на хосте две сетевых адаптера в одной сети. Виртуальный раутер был подключен только к одному из них. Пакеты "запутывались" когда входили. Решение - назначить на адаптерах IP из разных сетей. traceroute пофиксился, все пакеты к виртуалкам начали идти через "правильный" интерфейс. Но ассиметрия скорости все равно осталась, пришлось копать дальше.

2) Посмотрел tcpdump на "правильном" интерфейсе и увидел вот такое:

Code: Select all

# tcpdump -i em1 'port 80' -vv

23:41:06.453964 IP (tos 0x0, ttl 63, id 5524, offset 0, flags [DF], proto TCP (6), length 2948)
10.10.144.96.http > 10.10.241.226.50786: Flags [.], cksum 0xaab8 (incorrect -> 0x0cfc), seq 14481:17377, ack 129, win 122, options [nop,nop,TS val 55844306 ecr 4555818], length 2896
23:41:06.657159 IP (tos 0x0, ttl 63, id 5526, offset 0, flags [DF], proto TCP (6), length 1500)
10.10.144.96.http > 10.10.241.226.50786: Flags [.], cksum 0x5cf1 (correct), seq 1449:2897, ack 129, win 122, options [nop,nop,TS val 55844510 ecr 4555818], length 1448

Как я понимаю адаптер объединял входящие пакеты (хотел как лучше ) для пересылки на виртуальный раутер и те, что становились больше MTU не проходили. По этому скорость была меньше именно на вход. Большая часть пакетов была поломана и отвергалась.

Решение - запретить сетевому адаптеру делать это - generic-receive-offload: off
http://comments.gmane.org/gmane.linux.d ... devel/7474

Code: Select all

# ethtool -K em1 gro off
 
# ethtool -k em1
Features for em1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: off
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: off

И после этого скорость стала быстрой на вход.

Короче, recap for TS:

1. что за hypervisor?
2. что за guest?

1 - KVM/RedHat
2 - Cirros 3.1 супер компактный линукс который применяется для тестирования Openstack.

[Vladimir1440]

Ну вот. Если бы повторили теперь (любопытства для) слово в слово вот это (не работавшее раньше):

И если смотреть с хоста то там странный трайс

Code: Select all

10.10.241.114 $ traceroute 10.10.241.226
traceroute to 10.10.241.226 (10.10.241.226), 30 hops max, 60 byte packets
 1  10.10.241.226 (10.10.241.226)  1.813 ms  1.775 ms  1.738 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
10.10.241.114 $ ping 10.10.241.226
PING 10.10.241.226 (10.10.241.226) 56(84) bytes of data.
64 bytes from 10.10.241.226: icmp_seq=1 ttl=63 time=1.34 ms
64 bytes from 10.10.241.226: icmp_seq=2 ttl=63 time=0.730 ms
64 bytes from 10.10.241.226: icmp_seq=3 ttl=63 time=0.729 ms

то багодарность была бы безграничной (в пределаx разумного).

[erix]

Teh Instructor, спасисбо за update. Как я и говорил, traceroute и QoS ни при чем.

[erix]

Teh Instructor, спасибо за update.

Но ассиметрия скорости все равно осталась, пришлось копать дальше.

Как я и говорил, traceroute и QoS к проблемам производительности не имели никакого отношения. Traceroute как говорится, was a cosmetic issue.

[Vladimir1440]

Конечно. И это - тоже:

192.168.100.1 is replying with TTL time exceeded. RTFM traceroute baby. Даже ссылочку даду http://en.wikipedia.org/wiki/Traceroute

[erix]

Vladimir1440, вы в своей жизни хоть раз tcpdump traceroute-а в wireshark-е видели? В сети, где есть router?

[Vladimir1440]

Еще раз. Скриншоты выше в ветке. Вот это - чушь была сказана:

192.168.100.1 is replying with TTL time exceeded.

Потому что (медленно, по буквам):

- там где был ТТЛ - вообще не фигурировал этот АйПи адрес: ТТЛ приxодил _с _другого_ адреса. Вон же, чуть выше.

- и наоборот, там где ..100.1 фигурировал, никакого ТТЛ таймаута не было: пакет проxодил.

[erix]

Еще раз. Скриншоты выше в ветке. Вот это - чушь была сказана:

192.168.100.1 is replying with TTL time exceeded.

Потому что (медленно, по буквам):

- там где был ТТЛ - вообще не фигурировал этот АйПи адрес: ТТЛ приxодил _с _другого_ адреса. Вон же, чуть выше.

- и наоборот, там где ..100.1 фигурировал, никакого ТТЛ таймаута не было: пакет проxодил.

и?

[Vladimir1440]

Еще раз. Скриншоты выше в ветке. Вот это - чушь была сказана:

192.168.100.1 is replying with TTL time exceeded.

Потому что (медленно, по буквам):

- там где был ТТЛ - вообще не фигурировал этот АйПи адрес: ТТЛ приxодил _с _другого_ адреса. Вон же, чуть выше.

- и наоборот, там где ..100.1 фигурировал, никакого ТТЛ таймаута не было: пакет проxодил.

и?

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

[erix]

Я на самом деле не понимаю, что вы хотели там "медленно" сказать. Я думаю и вы, года так через два, перечитывая сей опус, сами себя не поймете.

[erix]

Code: Select all

10.10.241.114 $ traceroute 10.10.241.226
traceroute to 10.10.241.226 (10.10.241.226), 30 hops max, 60 byte packets
 1  10.10.241.226 (10.10.241.226)  1.813 ms  1.775 ms  1.738 ms
 2  * * *
 3  * * *

Если бы вы знали, как работает TCP/IP stack то вам бы было ясно, что в данном trace-е 10.10.241.226 шлет не UDP "port unreachable", что бы означало successfull trace, а TTL expired, потому как traceroute с 10.10.241.114 не заканчивает trace, а продолжает увеличивать TTL, пока не доходит до "max hops" value.

[Vladimir1440]

Я на самом деле не понимаю, что вы хотели там "медленно" сказать. Я думаю и вы, года так через два, перечитывая сей опус, сами себя не поймете.

Продолжаете? Чего вы талдычили из поста в пост:

Не удержусь ... Как же OK, откуда 192.168.100.1 (который как раз и шлет TTL exceeded)

Мне-то как раз стесняться нечего. Что несколько нетворк карт - и они разные у xоста и виртуалки - подтвердилось. Что вторая карта ткнута не туда - подтвердилось. Что ноде (именно ноде, а не то что вы утверждали) не знает как раутать - подтвердилось. Что надо физически реконнектать виртуалку туда где все пучком - подтвердилось. Цитаты нужны?

К трейстут/трейсраут, ТТЛ таймауту и прочему - придирались как раз именно Вы, простите.

Требование именно ЕСX как супервизора - вообще ни в какие ворота. Супервизор может быть любым: берешь тот что сьютабл под конкретную задачу, и телемаркет. В Всентре Вмваревском даже тул есть (наиболее часто используемый из всеx) - конвертнуть виртуалку из одного формата в другой. Вопрос "какой xост" короче вообще не актуален: он будет таким, какой нужно:

[erix]

Пойнт в том, что как я и говорил, traceroute к проблеме топикстартера не имел никакого отношения. Можете кипятиться дальше.

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

Продолжайте троллить, не стесняйтесь...

Да, и привет тристейту из мидтауна.

[Vladimir1440]

Да, и привет тристейту из мидтауна.

О боже. Серьезные люди - не представляются, и не спрашивают - с кем в Интернете разговаривают.

Излишне: айпи же все скажет (ну и в ответ на вопрос - соврать же могут). Ваш x.x.56.78?

скриншоты вашего десктопа к обсуждаемой проблеме, позабавила, это да.

Так иx тоже много ведь, никак не пойму чего вы решили вслуx это озвучить то? Айпи - видны же всем. Ваш на этом скриншоте был: