В случае с маршрутизатором хороший эффект дает группировка rx-прерывания одного интерфейса с tx-прерыванием другого интерфейса на одном ядре. Это обсуждалось в статье, которую автор упомянул в начале.
А вот от постоянных прыганий прерываний по процессорам, которые делает irqbalance, — только вред.
Гигабиты бывают разные, железо бывает разное. В разных случаях — разные оптимальные параметры. Поэтому лучше всегда подкручивать «на месте».
А Ваши рекомендации прочитал внимательно, не через строку :)
Еще.
Если увеличиваете параметр txqueuelen, то наверное имеет смысл rxqueuelen тоже увеличивать?
А также, наверное, не стоит эти параметры резко увеличивать до конкретных значений. Ведь у Вас гигабиты и Вам эти значения подходят, однако для меньших потоков эти значения лучше взять поменьше, иначе железо будет простаивать, а пинги упадут. Стоит их увеличивать до тех пор, пока нагрузка в часы пик не станет в пределах нормы. Это же касается и MTU.
В первоначальной статье есть фраза «если сервер работает только маршрутизатором, то тюнинг TCP стека особого значения не имеет». Это утверждение в корне неверно.
Однако настройка MTU не имеет отношения к тюнингу TCP-стека, а NAT это уже не «только маршрутизатор».
Ну это не проблема технологии, это проблема провайдера.
Я тоже думаю, что глупо блокировать возможность пользователей обмениваться трафиком, это лишь приведет к возрастанию нагрузки на внешние каналы.
Авторизация через RADIUS для DHCP-запросов? Вы поставляете клиентам модифицированные DHCP-клиенты, которые поддерживают авторизацию?
Или Вы имеете в виду патч www.netpatch.ru/dhcp2radius.html, в котором RADIUS играет лишь роль прослойки между DHCP и SQL-базой. А нужно это исключительно для удобства задания настроек DHCP.
1) Я подобных взломов не делал, так что могу только дать ссылку: www.nestor.minsk.by/sr/2007/03/sr70314.html.
2) И на Ethernet и на ADSL. Коммутируемые линии, к счастью, уже стали забытым кошмаром.
А про PAP Вы наверное не поверите…
Волгателеком — крупнейший провайдер всего Поволжья использует PPPoE с PAP :) Думаю, что обстановка по всей стране примерно такая.
MS-CHAP v2 лишь добавляет взаимность в процесс аутентификации.
Выяснение самого пароля в случае MS-CHAP и MS-CHAPv2 возможно очень долгим подбором. Однако сам пароль нам и не нужен. Получив хэши, мы уже сможем прозрачно вклиниться между клиентом и сервером.
На недоверенных каналах связи более-менее надежен лишь PEAP.
Теперь понял. Вклиниваемся в кабель клиента, его трафик роутим через себя, а сами при этом также пользуемся его каналом. Но, при использовании туннелей, хоть PPTP, хоть PPPoE, не намного сложнее провести аналлогичную атаку. Аутентификация PAP тупо перехватывается, CHAP немного сложнее, но тоже особых проблем не будет.
В случае использования IPoE, как врезавшийся в кабель клиента злоумышленник сможет сосать трафик без ведома самого клиента? На порту VLAN, на VLAN роутится один единственный IP. Два хоста с одинаковым IP в одной сети, работать будет только один. Или тут есть что-то, чего я не учитываю? Если еще и MAC себе поставить клиентский, то опять же одновременно корректно работать они не смогут.
Не могу рассказывать, что и как у меня на текущем месте работы, но вообще приходилось работать и с ~4000 интерфейсов в продакшене и с ~10000 с Q-in-Q в тесте.
Ну это зависит от количества пользователей. Сотня пользователей в одном бродкаст-домене (L2) — ничего особо страшного. Тысяча — катастрофа, одним бродкаст-пингом можно положить всю сеть. Конечно, активное сетевое оборудование может бороться с штормами, но не стоит делать большие бродкаст-домены, полагаясь только на эту защиту.
Смотря что считать извращением :)
Если Client-VLAN, то для того, чтобы не использовать привязки по MAC.
Если DHCP Option82, то для того, чтобы автоматически выдавать настройки абонентам.
А вот от постоянных прыганий прерываний по процессорам, которые делает irqbalance, — только вред.
А Ваши рекомендации прочитал внимательно, не через строку :)
Если увеличиваете параметр txqueuelen, то наверное имеет смысл rxqueuelen тоже увеличивать?
А также, наверное, не стоит эти параметры резко увеличивать до конкретных значений. Ведь у Вас гигабиты и Вам эти значения подходят, однако для меньших потоков эти значения лучше взять поменьше, иначе железо будет простаивать, а пинги упадут. Стоит их увеличивать до тех пор, пока нагрузка в часы пик не станет в пределах нормы. Это же касается и MTU.
Однако настройка MTU не имеет отношения к тюнингу TCP-стека, а NAT это уже не «только маршрутизатор».
Я тоже думаю, что глупо блокировать возможность пользователей обмениваться трафиком, это лишь приведет к возрастанию нагрузки на внешние каналы.
Или Вы имеете в виду патч www.netpatch.ru/dhcp2radius.html, в котором RADIUS играет лишь роль прослойки между DHCP и SQL-базой. А нужно это исключительно для удобства задания настроек DHCP.
2) И на Ethernet и на ADSL. Коммутируемые линии, к счастью, уже стали забытым кошмаром.
Волгателеком — крупнейший провайдер всего Поволжья использует PPPoE с PAP :) Думаю, что обстановка по всей стране примерно такая.
Выяснение самого пароля в случае MS-CHAP и MS-CHAPv2 возможно очень долгим подбором. Однако сам пароль нам и не нужен. Получив хэши, мы уже сможем прозрачно вклиниться между клиентом и сервером.
На недоверенных каналах связи более-менее надежен лишь PEAP.
dev lo, конечно же.Если Client-VLAN, то для того, чтобы не использовать привязки по MAC.
Если DHCP Option82, то для того, чтобы автоматически выдавать настройки абонентам.