Теперь рассмотрим простой пример. У нас есть некий шлюз, на него приходят пакеты с IP 192.168.1.20. Пакеты с этого IP нужно отправлять на шлюз 10.1.0.1...
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, — только вред.
Гигабиты бывают разные, железо бывает разное. В разных случаях — разные оптимальные параметры. Поэтому лучше всегда подкручивать «на месте».
А Ваши рекомендации прочитал внимательно, не через строку :)
Из статьи:
# ip ruleRTNETLINK answers: Operation not supported
Dump terminated
Если есть /proc/config.gz, то
zcat /proc/config.gz | grep CONFIG_IP_ADVANCED_ROUTERиzcat /proc/config.gz | grep CONFIG_IP_MULTIPLE_TABLES.На 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, — только вред.
А Ваши рекомендации прочитал внимательно, не через строку :)