1. Этого будет достаточно для заруливания всех IP-пакетов, приходящих на eth1, причем в Ethernet-фрейме, содержащем этот IP-пакет в качестве MAC-адреса получателя должен стоять MAC-адрес нашего eth1. Почему только эти пакеты? Потому что только эти пакеты роутятся по определению. Почему будут роутиться? Потому что прописаны такие правила, и они как ни странно работают. Можно поставить эксперимент:
На C3 делаем ip route add default via 192.168.12.1.
На C2 делаем ip route add default via 192.168.11.1 table 123 proto static и ip rule add iif eth0 table 123 (синтаксис не принципиален, работает также как и ip rule add iif eth0 lookup 123).
Генерируем трафик с C3 на любые адреса, кроме 192.168.12.0/24. Запускаем tcpdump на C1 и наблюдаем эти пакеты.
Новый день — новый хостинг — новое убежище. Контент сайта представляет намного меньше интереса, чем игра в догонялки с США. Ждем новых серий сериала «Приключения Wikileaks» :)
Это не дословный перевод, я постарался более понятно изложить описание опций. Также, к большинству опций приведено дополнительное описание, рекомендованные значения и на что ориентироваться при выборе значений, этого в документации нет.
А типовых случаев не бывает, как я считаю. В каждом случае нужно подбирать свои опции, поэтому готовых примеров не привожу.
Предложите более адекватное название статьи.
Группировка RX и TX на одном процессоре в основном дает оптимизицию использования кэша процессора. Более подробно вопрос не изучал, когда ставил эксперименты — группировка действительно дала некоторое снижение нагрузки. Если руки дойдут, то попробую эксперименты повторить и привести конкретные числа.
Еще могу посоветовать почитать вот этот документ: vger.kernel.org/netconf2009_slides/LinuxCon2009_JesperDangaardBrouer_final.pdf
А keepalive-пакеты? По умолчанию net.ipv4.tcp_keepalive_intvl = 75, так что если у провайдера >75, то проблем быть не должно. Если же у провайдера проведен подобный тюнинг, то уменьшите это значение со своей стороны и опять же проблем быть не должно.
Прочитайте Большие потоки трафика и управление прерываниями в Linux. Предполагается, что сетевые интерфейсы имеют несколько очередей. Иначе обработка больших потоков трафика скорее всего не получится.
В Вашем конкретном случае нужно проверить на практике, в каком случае нагрузка будет меньше — eth0 на одном процессоре, eth1 на другом или оба на одном.
В фразе подразумевался смысл «тюнинг TCP стека особого значения не имеет, однако имеет значение тюнинг ARP кэша». Пожалуй фразу мне следовало построить по-другому. В любом случае, спасибо за замечание :)
В случае с маршрутизатором хороший эффект дает группировка rx-прерывания одного интерфейса с tx-прерыванием другого интерфейса на одном ядре. Это обсуждалось в статье, которую автор упомянул в начале.
А вот от постоянных прыганий прерываний по процессорам, которые делает irqbalance, — только вред.
Гигабиты бывают разные, железо бывает разное. В разных случаях — разные оптимальные параметры. Поэтому лучше всегда подкручивать «на месте».
А Ваши рекомендации прочитал внимательно, не через строку :)
Еще.
Если увеличиваете параметр txqueuelen, то наверное имеет смысл rxqueuelen тоже увеличивать?
А также, наверное, не стоит эти параметры резко увеличивать до конкретных значений. Ведь у Вас гигабиты и Вам эти значения подходят, однако для меньших потоков эти значения лучше взять поменьше, иначе железо будет простаивать, а пинги упадут. Стоит их увеличивать до тех пор, пока нагрузка в часы пик не станет в пределах нормы. Это же касается и MTU.
В первоначальной статье есть фраза «если сервер работает только маршрутизатором, то тюнинг TCP стека особого значения не имеет». Это утверждение в корне неверно.
Однако настройка MTU не имеет отношения к тюнингу TCP-стека, а NAT это уже не «только маршрутизатор».
Ну это не проблема технологии, это проблема провайдера.
Я тоже думаю, что глупо блокировать возможность пользователей обмениваться трафиком, это лишь приведет к возрастанию нагрузки на внешние каналы.
Авторизация через RADIUS для DHCP-запросов? Вы поставляете клиентам модифицированные DHCP-клиенты, которые поддерживают авторизацию?
Или Вы имеете в виду патч www.netpatch.ru/dhcp2radius.html, в котором RADIUS играет лишь роль прослойки между DHCP и SQL-базой. А нужно это исключительно для удобства задания настроек DHCP.
На C3 делаем
ip route add default via 192.168.12.1.На C2 делаем
ip route add default via 192.168.11.1 table 123 proto staticиip rule add iif eth0 table 123(синтаксис не принципиален, работает также как иip rule add iif eth0 lookup 123).Генерируем трафик с C3 на любые адреса, кроме 192.168.12.0/24. Запускаем tcpdump на C1 и наблюдаем эти пакеты.
А типовых случаев не бывает, как я считаю. В каждом случае нужно подбирать свои опции, поэтому готовых примеров не привожу.
Предложите более адекватное название статьи.
фейри не попробовалне нашел на хабре вот эти статьи:habrahabr.ru/blogs/sysadm/88624/
habrahabr.ru/blogs/sysadm/89002/
Еще могу посоветовать почитать вот этот документ: vger.kernel.org/netconf2009_slides/LinuxCon2009_JesperDangaardBrouer_final.pdf
В Вашем конкретном случае нужно проверить на практике, в каком случае нагрузка будет меньше — eth0 на одном процессоре, eth1 на другом или оба на одном.
А вот от постоянных прыганий прерываний по процессорам, которые делает irqbalance, — только вред.
А Ваши рекомендации прочитал внимательно, не через строку :)
Если увеличиваете параметр txqueuelen, то наверное имеет смысл rxqueuelen тоже увеличивать?
А также, наверное, не стоит эти параметры резко увеличивать до конкретных значений. Ведь у Вас гигабиты и Вам эти значения подходят, однако для меньших потоков эти значения лучше взять поменьше, иначе железо будет простаивать, а пинги упадут. Стоит их увеличивать до тех пор, пока нагрузка в часы пик не станет в пределах нормы. Это же касается и MTU.
Однако настройка MTU не имеет отношения к тюнингу TCP-стека, а NAT это уже не «только маршрутизатор».
Я тоже думаю, что глупо блокировать возможность пользователей обмениваться трафиком, это лишь приведет к возрастанию нагрузки на внешние каналы.
Или Вы имеете в виду патч www.netpatch.ru/dhcp2radius.html, в котором RADIUS играет лишь роль прослойки между DHCP и SQL-базой. А нужно это исключительно для удобства задания настроек DHCP.