smart85 Posted September 3, 2019 Коллеги, приветствую! Есть CCR1036-12G-4S, в него включены два сервера с Windows server 2016. На микроте созданы два бонда, в каждом бонде по паре 1G меди, Mode 802.3ad THP: Layer 2 and 3 (пробовали и просто L2). На винде соответственно собран тиминг адаптеров, и в целом все хорошо, траф бегает, но не более 1Гб/секю Для примера, с сервера №1 льем файло на сервер №2, все упирается в гигабит, но при этом трафик от сервера №1 размазан по линкам 50/50, а вот уже после микрота на сервер №2 трафик идет только по одному линку. Это же получается фишка LACP + по одному хосту на каждом бонде? Это как-то можно обойти? Спасибо за внимание! Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
alexmern Posted September 3, 2019 mode=balance-rr Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ShyLion Posted September 3, 2019 19 minutes ago, mse.rus77 said: Для примера, с сервера №1 льем файло на сервер №2, все упирается в гигабит, но при этом трафик от сервера №1 размазан по линкам 50/50, а вот уже после микрота на сервер №2 трафик идет только по одному линку. Очень хочется поиметь гемор, когда в сеансе часть пакетов прилетает раньше чем пришли предыдущие? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
VolanD666 Posted September 3, 2019 Может хэш поменять? Кстати, я еще читал где-то, что у микрота LACP при двух линках использует только один из них. Но это не точно. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
jffulcrum Posted September 3, 2019 Одно "соединение" - один физический линк, LACP - это балансировка многих-к-одному. Для ускорения один-к-одному нужна статическая агрегация, но у микротика с этим могут быть проблемы, хотя попробуйте режим balance-alb Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
VolanD666 Posted September 3, 2019 Можно балансировать манглом путем задания вероятности срабатывания правила Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
smart85 Posted September 3, 2019 1 час назад, ShyLion сказал: Очень хочется поиметь гемор, когда в сеансе часть пакетов прилетает раньше чем пришли предыдущие? Вот есть ощущение, что мы его и поимели. Рандомно начинают лагать RDP сессии до серваков, просто фризит картинку, иногда отваливает соединение. Такое вписывается в этот кейс? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
VolanD666 Posted September 3, 2019 1 час назад, ShyLion сказал: Очень хочется поиметь гемор, когда в сеансе часть пакетов прилетает раньше чем пришли предыдущие? Ну мне кажется это должно влиять на скорость передачи, целостность данных не должна пострадать. Т.к. по сути приложение должно просто перезапросить потерянный пакет. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
smart85 Posted September 3, 2019 5 минут назад, VolanD666 сказал: Ну мне кажется это должно влиять на скорость передачи, целостность данных не должна пострадать. Т.к. по сути приложение должно просто перезапросить потерянный пакет. У нас сейчас проблема с лагом RDP сессий, при этом пинги не теряются, rtt тоже. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
jffulcrum Posted September 3, 2019 Если у вас на этот микрот по 10Г вливается клиентский траф, то даже с двумя 1Г сосками к серверам неизбежна буферизация на коммутаторе, берсты = фризы. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
smart85 Posted September 3, 2019 1 час назад, jffulcrum сказал: Если у вас на этот микрот по 10Г вливается клиентский траф, то даже с двумя 1Г сосками к серверам неизбежна буферизация на коммутаторе, берсты = фризы. Нет, 10Г там и подавно нет. Юзеры вообще на 100М аплинке к микроту с мира идут. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
jffulcrum Posted September 3, 2019 RDP в дефолте работает через UDP. Попробуйте в GPO настроить на TCP, может помочь (уж от reordering - точно). Правда, если у вас Remote FX фичи в ходу - могут отвалиться. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
smart85 Posted September 3, 2019 Сейчас разобрали LACP, оставили по обычному 1Gbps линку на каждый сервер, будем смотреть. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ShyLion Posted September 4, 2019 16 hours ago, mse.rus77 said: Вот есть ощущение, что мы его и поимели. Рандомно начинают лагать RDP сессии до серваков, просто фризит картинку, иногда отваливает соединение. Такое вписывается в этот кейс? Вполне. Агрегация нормально работает когда отдельные потоки идут фиксированым путем по одному линку. Да, между двумя конечными хостами, по одному потоку скорость будет равна скорости одного линка, но когда хостов много или потоков много (зависит от типа хеша), то данные статистически размазываются по нескольким линкам и суммарно получается, что общая скорость равна сумме отдельных. Как именно размазывать потоки решает каждая сторона отдельно. Также еще многое зависит от типа траффика. Если скажем по LACP соединены два роутера, то хеширование по макам неприемлимо, так как их всего по одному с каждой стороны и траффик размазыватсья не будет, нужно чтобы дивайс заглядывал глубже. Если там еще и туннель, то вообще труба - и маки постоянны и IP адреса постоянны. Round-robin - очень специфичное применение, сильно зависит от приложения и в целом слабо применимо. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
