forum.lissyara.su

Мое почтение, коллегам.
Нашел одну заковыку.
Шлюз, он же сервер №1. Одна сетевая карта в мир, вторая в локалку.
На шлюзе используется ipfw, ядерный nat.
Сервер №2 находится в локалке.
Настроен проброс rdp порта во вне.
С внешнего компа стучимся на проброшенный порт и шагаем на rdp.

И все это тихо мирно годы работало. Настраивал сам, в смысле это не по наследству переходило и я представляю, как это настроено.

Нагрузка возросла, решил перевести локальные сервера на 10G. Поставил на сервер №2 новую карту, SFP+ модуля, заработало.
Поставил такую же карту на сервер №1, изменил правила ipfw и прочее. И тоже заработало.

Но нашелся таки один косяк.
Коннект с внешнего порта на проброшенный порт на rdp на сервер №2. Окно терминального подключения открывается как-то с неохотой. Дергается мальца. Доходит до пароля. Дальше может уйти в черный экран. А может открыться окно рабочего стола. Даже дойти до нажатия на кнопку пуск и замереть.

С сервера №2 открываю внешний компьютер (тот же самый). Все зашибись бегает.
Значит все-таки проблема в nat?
Вертаю на сервер №2 на старый интерфейс - проблема не уходит.
Вертаю на сервере №1 обратно на старый интерфейс - все бегает как было.
Возвращаю на сервере №1 новый интерфейс - снова затык на rdp.

Продолжаю раскачивать ситуацию.
С внешнего компьютера соединяюсь не на сервер №2, а на другой компьютер (только виндой отличаются), то же на проброшенный порт.
Все хорошо
Проблема именно в коннекте на сервер №2.
Зашел не на проброшенный порт, а через vpn. Сервер №2 по rdp тоже открывается с проблемами. Зашел на другой компьютер, тоже через vpn - все в порядке.

Взял tcpdump. А там посыпались chksum incorrect. Ну я за голову, неужто патчкорд на оптике завалил
Потом вычитал, что это особенность tcpdump

В чем может быть проблема?

Сегодня планирую продолжить эксперимент.
На повестке дня:
1. Коннект на другой сервер с такой же виндой через проброшенный порт.
2. Сменить на сервере №2 ip адрес и попробовать на него.

На проблемы с правилами не похоже. Коннекта бы не было, как я думаю.
На проблемы с драйвером новой карты тоже не похоже. Тогда бы была проблема на разные компы. А тут именно один сервер №2.

В качестве бреда:
1. Согласование скоростей
2. Размеры пакетов
3. Дропнутые есть?

Alvares, как это проверить?
1. Согласование скоростей.
Это не прямой соединение, это через коммутатор.
На коммутаторе скорости определяются как 10G.
Пробовал отключать и включать управление потоком.

2. Размеры пакетов. Как проверить?
На шлюзе JUMBO_MTU включено. Но по больше размер пакета еще не указал. Начал пробовать, но тут проблема с rdp вмешалась.

3. Как проверить дропнутые?

Полученный файл разбирать в wireshark'е

lazhu, точно, забыл совсем о wireshark

Дамп снял. Буду пытаться разобрать.

Глянул краем глаза оба дампа - и в рабочем окружении и не рабочем.
На мое удивление, трассы разные
Прям даже в замешательстве. Казалось бы, исправил только название интерфейса
По мере разбирательства, сообщу общественности детали.

als писал(а): ↑

2019-08-02 7:37:18

На мое удивление, трассы разные
Прям даже в замешательстве. Казалось бы, исправил только название интерфейса

проверять arp на соответствие правильных маков правильным ip

lazhu писал(а): ↑

2019-08-02 8:55:16

проверять arp на соответствие правильных маков правильным ip

Кстати да.
Тут еще такая штука. Сетевая двухпортовая. Драйвер под Freebsd выводит ... 8 интерфейсов по этой сетевой.
Первому порту соответствуют четные интерфейсы, второму нечетные.
Зачем он это делает, пока не разбирался.
Само собой, каждый интерфейс имеет свой мак.

С разными трассами это я дятел.
Новая сетевка она внутренняя. Трассу снял с нее.
Переключился на рабочий вариант.
И ... снял трассу с внешней сетевки
Будем снова снимать.

Пока готовился к снятию трассы, добавил MTU.
На карте, что под виндой дает предопределенный выбор MTU:
4088
9014
9614

Под Freebsd можно самому указать. Ну я решил, что бы было одинаково, поставил везде (на обоих сетевых, на коммутаторе) 9014.

Проверил rdp с телефона, с LTE. Медленно, но открывается.
Я обрадовался.
Решил проверить с внешнего стационарного компа.
Все как обычно - еше протягивает и постепенно умирает.

Попутно сделал тест iperf. С локальной машинке до обоих карт и между картами.
Так вот результат между картами меня поразил
[ 5] 0.0-18.9 sec 24.0 Bytes 10.2 bits/sec
Я такого еще не видел.

Снял дампы и в этой ситуации, буду смотреть.

Итак, насмотрел.
В ходе экспериментов выяснено.
1. Эти восемь эзернет карт порождаются самой картой. При этому, драйвер под Freebsd позволяет их использовать, как отдельные карты. А вот под винду он их не видит. Только по одной карте на порт (карта физически двух портовая).
Сделал по карте на порт. Мне пока столько не надо

2. Коннект через rdp оптическую карту на сервере с другой оптической картой, как и писал ранее встает колом.
Коннект через оптическую карту на сервере на локальный комп колом не встает, но заметно тормозит.

Снял трассы при коннекте через прежнюю карту и через оптическую.
Трасса через прежнюю карту без претензий. Чистая с точки зрения wiresharkа.
Трасса через оптическую карту имеет косяк.

Идут пакеты с внешнего адреса. Они natируются и уходят на внутренний.
Идут пакеты с внутренного, natираются и уходят на внешний.
Но иногда, а судя по диаграмме wireshark то и часто, происходит ситуация.
Пакет с внутреннего адреса уходит с указанием внешнего адреса. Судя по анализу, длина этого пакета 1706. Info application data
И тут сервер отвечает ICMP пакетом с info Destination unreachable (Fragmentation need)

Следующим пакетом локальный адрес шлет пакет в адрес внешнего компа, Info application data
Следующий пакет от внешнего адреса в адрес локального компа. С пометкой TCP previous segment not captured

Исследую дальше

У оптической карты в опция ifconfig написано
options=527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO>
Вот бы как-нибудь JUMBO_MTU отключить.
Пробовал через -mediaopt, не выходит.
Поискал в драйвере man bxe, то же ничего нет.
Как бы отключить?

Сравнил пакеты в нормальной среде и в оптической.

В нормальное среде локальный комп отправляет пакет в адрес внешнего.
Длина пакета 1514.
Стоит флаг Don't fragment
Пакет собирается со вторым пакетом с длиной 246.
Итого локальный комп отправляет в адрес внешнего 1760. Думаю, если вычесть заголовки это как раз тот пакет, который вызывает проблемы в оптической среде.

В оптической среде локальный комп отправляет пакет (похоже этот же) в адрес внешнего.
Длина пакет 1706.
Стоит флаг Don't fragment
И он не "пролазит"
Шлюз пытается его фрагментировать, а не удается. Это вызывает ICMP сообщение.
Но что толкает локальный комп отправлять большой пакет?
Отключил с оптической карты протокол DCB (ну мало ли ). Реакции нет.

Попробую собрать еще трассу с локального компа.

вы бы хоть ifconfig показали, раз разговор о сетях идёт

Alex.Keda, это запросто.
Текущий ifconfig. Оптика (карты bxe) заглушена

bxe0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO>
ether 6c:b3:11:4e:d5:98
media: Ethernet autoselect (none)
status: no carrier
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
bxe1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO>
ether 6c:b3:11:4e:d5:99
media: Ethernet autoselect (none)
status: no carrier
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=81249a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER>
ether 00:15:17:60:f7:ec
inet6 fe80::215:17ff:fe60:f7ec%em0 prefixlen 64 scopeid 0x3
inet XX.XX.X.XX netmask 0xfffffff0 broadcast XX.XX.XX.XX
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=81249b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER>
ether 00:15:17:60:f7:ed
inet 192.168.0.101 netmask 0xffffff00 broadcast 192.168.0.255
inet 192.168.1.100 netmask 0xffffff00 broadcast 192.168.1.255
inet 192.168.0.15 netmask 0xffffff00 broadcast 192.168.0.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

rxcsum и txcsum тоже попытайтесь отключить

snorlov писал(а): ↑

2019-08-06 12:48:05

rxcsum и txcsum тоже попытайтесь отключить

Попробую, чего ж нет.

snorlov писал(а): ↑

2019-08-06 12:48:05

rxcsum и txcsum тоже попытайтесь отключить

не сработало.

Снял трассу при коннекте через оптическую карту на внутреннюю оптическую карту.
Напомню, что в этом случае коннект еще хуже. Пытается открыться окно подключения и черный экран.

Смотрю трассу.
Вот начинается приветствие. Здравствуй внутренний сервер, давай слать пакеты с MSS = 1460.
TCP Option - Maximum segment size: 1460 bytes.
Давай, отвечает внутренний сервер.
И через некоторое время отправляет в адрес внешнего пакет длиной 2420 байт. А как же договоренности??
Шлюз на такой пакет отвечает ICMP Destination unreachable.
Внутренний сервер урезает пакет и шлет снова.
Не факт, что это является причиной замедления. Но вроде как зачем он так делает?

Так что пока не ясно, что и попробовать.

Разгадал я тайну.

Пошел по пути "выключим все неизведанное, вернемся к дедовским настройкам"
И как заработает!
Начал копать по опциям.
В качестве теста использовал iperf для замера скорости и коннект к rdp по проброшенному порту.

Скорость по iperf становится выше и rdp коннект начинается, если на оптической карте на сервере, на bxe0 выключить lro.
TCP Large Receive Offload

Остальные опции проверил, реакции такой значительной нет

Почему включенный lro коннекте по проброшенному порту между двумя оптическими картами дает такой эффект, сказать не могу

Я помню, была такая беда с броадкомовскими сетевухами. Обычными ethernet, не оптикой. Надо было все оффлоады вырубать у них.

lazhu писал(а): ↑

2019-08-07 17:08:03

Я помню, была такая беда с броадкомовскими сетевухами

Вообщем это теперь у них в и оптику перешло

lazhu писал(а): ↑

2019-08-07 17:08:03

Я помню, была такая беда с броадкомовскими сетевухами. Обычными ethernet, не оптикой. Надо было все оффлоады вырубать у них.

А у меня что-то не работало, пока не вырубил rxcsum/txcsum