Ключевые слова:pool, device, ethernet, freebsd, kernel, tune, route, ipfw, traffic, (найти похожие документы)
Date: Sat, 28 Feb 2004 04:35:51 +0500
From: Alexander Sheiko <adsh@i.com.ua>
Newsgroups: ftn.ru.unix.bsd
Subject: DEVICE_POLLING и заметка по рутерам на базе FreeBSD
SA> я предполагаю, что при малой интенсивности трафика пакеты будут
SA> обрабатываться с несколько большей задержкой, а при слишком большой
SA> интенсивости - потери пакетов.
Х.З. По крайней мере - визуально я ничего плохого не заметил.
Кстати, на http://www.nag.ru, по поводу сабжа была заметка. Думаю - всем
будет интересно:
=========Beginning of the citation==============
Софтроутер
Материал прислал Фдуч.
Hесколько наблюдений по поводу уже 6-ти летнего использования софтовых
рутеров на FreeBSD.
Если надо рутить (только рутить) 3-5 сегмента 10мбпс, то с этим нормально
справляется любой пентиум с любыми pci сетевухами.
Если появилось 100Мб, то карточки realtek и им подобные сразу на свалку. О
том, какое это "чудо" в плане дизайна чипа читайте в комментариях драйвера
if_rl. Мы используем intel. 3com тоже можно, однако его дрова не
поддерживают очень важную функцию, о которой ниже.
Основная проблема при пропускании сквозь себя 100Мб - это затыкание рутера
по прерываниям. Дело не в 100 мегабитах, а в количестве пакетов и
соответственно прерываний. Top и systat -v 1 вам поможет понять, что рутер
затыкается. 8000 прерываний в секунду и ваш p3-700 уже труп. Однако во
FreeBSD есть полезная фича - DEVICE_POLLING. Обязательно включаем ее на
рутере. Карточки работают не по прерываниям, а принудительно опрашиваются
ядром. В итоге к примеру 4*100Мб, как говорится, на full wire speed идет
легко. Подробнее смотреть на странице разработчика ipfw, dummynet и прочих
вкусных штук во FreeBSD Луиджи Риззо.
Hужно считать трафик. Мы это делаем ipacctd. Вещь классная, удобная,
безглючная. Однако у нее есть одна проблема - подсчет идет через divert и на
каждый пакет идет переключение контекста. От чего он существенно занимает
процессорное время. Замечено, что если ipacctd в топе висит с 30% - срочно
пора менять камень. Есть еще ng_ipacctd, который сделан в виде ядерного
модуля и не щелкает контексты. Однако он менее гибок в использовании - может
считать только весь трафик на интерфейсе, а нам это не всегда надо.
Фаервол. ipfw - штатный от фри рулит. Hовая его генерация ipfw2 (в фре 4.8
надо включать руками - man ipfw, в 5.х штатный) еще более производителен.
Вобщем, по фаерволу никогда не замечал затыков.
Squid. В идеале конечно нужно ставить на отдельную машинку, памяти поболее,
и винт пошустрее. К примеру, даже в небольшой конторе на p1 32M запрос через
сквид идет заметно медленней, чем напрямую.
Итак, что мы имеем на сегодняшний день на примере 2х конкретных рутеров:
p1-166 16M. 1*100 3*10. Только рутинг. ~1Т в месяц
p4-1800 512M. 4*100. Hесколько vlanов. Фаервол ~3000 записей, подсчет
входящего трафика на 1-ом интерфейсе (~600Гб в месяц). Суммарно
проручмвается ~4Тб в месяц. Тут же висит squid.
Следуя традиции данного выпуска, приведу и тут перефразированную поговорку
про джипы. "Чего только не придумают русские, что бы не покупать Cisco"
(чего только не придумают русские что бы не строить нормальные дороги).
http://info.iet.unipi.it/~luigi/polling/
=========The end of the citation================
--
Саша.
