организация роутера

[leave]

Llama, проблема-то в другом: попробуй найди через пару лет замену встроенному контроллеру. Внешний "такой же" найти много лечге.

[tes+or]

leave: встроенные в ядро линукса?

Llama: говорят софтварные это медленно, это правда? просто в моем случае это вопервых категорически неважно, а во вторых - нет с чем сравнить.

UPD: под софтварными я понимаю совсем софтварные. т.е. не контроллеры, а рэйд на любых блочных устройствах средствами ОС. я всегда юзал такие и проблем не замечал. я что-то делаю не так или проблем и не должно быть?

[leave]

рэйд на любых блочных устройствах средствами ОС

Ааа, тогда понятно. Сорри, недопонял тебя.

[tes+or]

так я к чему это. какие минусы у этого решения? зачем люди платят много денег за железку? мне вобщем-то кажется, что железный рэйд нужен только в том случае, если используется ОС не имеющая своего драйвера для вирутального рэйда.

[Llama]

tes+or, производительность аппаратного RAID все-таки как ни крути намного выше хотя бы за счет кеширования записи и разгрузки процессора от массы вычислений, даже элементарного чтения с чередованием в RAID1 пока что ни говнорейды ни md не умеют.

[tes+or]

гм.. ну в прицнипе да, резон есть, но не в моем случае.

[tes+or]

ну, отчитаюсь, может кому инетересно будет.

комп взяли с интеловской материнкой, какой точно я даже незнаю, но что-то позиционирующееся как недорогое решение для офисного рабочего места.

проц таков: Intel Core2 Duo CPU E7200 @ 2.53GHz GenuineIntel
памяти гиг.
винты - два макстора по 160
блок - FSP 450

на шине висит следующее:
corerouter ~ # lspci
00:00.0 Host bridge: Intel Corporation Device 2e20 (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Device 2e22 (rev 03)
00:02.1 Display controller: Intel Corporation Device 2e23 (rev 03)
00:03.0 Communication controller: Intel Corporation Device 2e24 (rev 03)
00:19.0 Ethernet controller: Intel Corporation Device 10ce
00:1a.0 USB Controller: Intel Corporation Device 3a37
00:1a.1 USB Controller: Intel Corporation Device 3a38
00:1a.2 USB Controller: Intel Corporation Device 3a39
00:1a.7 USB Controller: Intel Corporation Device 3a3c
00:1c.0 PCI bridge: Intel Corporation Device 3a40
00:1c.3 PCI bridge: Intel Corporation Device 3a46
00:1d.0 USB Controller: Intel Corporation Device 3a34
00:1d.1 USB Controller: Intel Corporation Device 3a35
00:1d.2 USB Controller: Intel Corporation Device 3a36
00:1d.7 USB Controller: Intel Corporation Device 3a3a
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 90)
00:1f.0 ISA bridge: Intel Corporation Device 3a18
00:1f.2 SATA controller: Intel Corporation Device 3a22
00:1f.3 SMBus: Intel Corporation Device 3a30
02:00.0 IDE interface: JMicron Technologies, Inc. JMB368 IDE controller
03:00.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
03:02.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
03:04.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]

вобщем-то большая часть мне мне мало о чем говорит, факт только в том, что DMA для дисков не включилось, да и не больно то надо было. вобщем все это работает хорошо. могу отметить что южный мост(который снизу, правильно?) с пассивным охлаждением игольчатым радиатором мне показался черезмерно горячим для южного моста, северный же куда как холоднее, но на нем радиатор больше в 3 раза и сказывается близость кулера проца. посмотрел я на это и решил добавить кулеров на всякий случай, потому как вреда от них еще никогда небыло. в комплектации в которой он мне пришел был один кулер на корпусе, причем его обороты были по всей вероятности завязаны на какой-то термодатчик на плате, потому как крутился он слишком медленно. я добавил еще два, на крышку и рядом с корзиной с дисками и включил их прямо на +12. шума стало много, но для серверной это не важно.

в качестве ос поставил gentoo, аккуратно собрал минималистичное монолитное ядро, поставил тулзы, все как обычно.

грузился посредством grub'a прямо с RAID1 организованного средствами ядра при помощи mdadm. раздел один единственный корневой, FS - ext3.

поставил iptables и iproute2. роутинг организовал возможно довольно нестандартно. фактически LAN и DMZ у меня в одном эзернет сегменте. т.е. на ланпорту прописано два айпишника, один из внешнего диапазона и один из внутреннего, серваки имеют на своих интерфейсах внешние айпишники, обычные компы - внутренние, а дефолт гейтвеем у тех и у других прописаны соотвествующие айпишники с ланпорта. это все отлично работает, за исключением того, что если что-то из локалки SNATится на роутере, то внутренние серваки для этого чего-то почему-то становятся недоступны. решено это было очень просто - првила были исправлены так, что если адресом назначения был один из внутренних серверов - оно просто не передавалось на SNAT.

шейпинг я делал посредством tc и htb с использованием классификатора u32 и sfq в качестве краевой дисциплины. надеюсь выразился корректно, потому как в вопросе еще плаваю. честно говоря я думал там все попроще будет, но оказалось что там борода побольше чем в айпитэйблс, однако было найдено множество полезных и интересных вещей с которыми я собираюсь поэксперементировать, о результатах чего расскажу по факту.

в качестве инструмента стастистики был установлен ntop, как я уже писал в другом трэде. думаю обсуждение этого аспекта целесообразнее будет продолжить там.

а так - работает, аптайм чуть больше суток, мелкие недочеты устранены, если произойдет что-то интересное - расскажу.

[tes+or]

включились вот еще в пирринг, для маршрутизации теперь используем bgp. в качестве реализации bgp - quagga. это вполне работает. но вскрылась одна проблема - юзер сидящий за двухсторонним натом one-to-one не может получить доступ к одному из внешних серверов. советовались с одним чеовеком - он говорит что проблема в том, что у того провайдера, к которому подключен этот сервак, маршрутизация настроена таким образом, что исходящие от нас к нему пакеты идут через один канал(наш пиринг), а ответы возвращаются к нам через наш основной интернет канал. есть мнение что в таком случае нат не может корректно произвести трэкинг соединений, хотя вроде как он у меня нигде к интерфейсу не привязан.

правило трансляции по смыслу таково:

iptables -t nat -A POSTROUTING -s $LAN_IP -d ! $WAN_SUBNET/24 -j SNAT --to-source $WAN_IP
iptables -t nat -A PREROUTING -d $WAN_IP -j DNAT --to-destination $LAN_IP

где $LAN_IP внутренний айпишник юзера, $WAN_IP айпишник нашего пула через который он работает с инетом, а $WAN_SUBNET - подсеть пула соотвественно.

такая проблема в самом деле существует? и как она реашется если решается? пока я вижу только одно очевидное решение - для данного конкретного провайдера прописать роуты так, чтобы они от нас шли через основной канал, однако тогда мы теряем преимущества пиринга, а не хотелось бы. есть идеи?

[Hermit]

RP Filtering может уничтожать пакеты при ассиметричной маршрутизации.

Код: Выделить всё

sysctl net.ipv4.conf.ethX.rp_filter

[tes+or]

спасибо, кажется работает!

вот линк дающий немного более развернутое пояснение, если кто пойдет по моим граблям:
http://www.opennet.ru/base/net/rp_filte ... e.txt.html

[tes+or]

внедряем дальше. на этот раз установил роутер дома, делим анлим на троих. и все бы хорошо, но у нас на роутере стоит большой винт и оттуда торренты раздаются. и скачиваются они тоже, причем постоянно. естественно решаем вопрос шейпинга. с шейпингом на сеть все в порядке, стандартно настроили htb с sfq в качестве краевой дисциплины и все было хорошо, пока собственно торренты небыли запущены, потому как будучи запущеными они решительно забивают канал всем остальным, потому что sqf на них не распространяется, по той очевидной причине что процесс локальный для роутера и через интерфейс на котором у нас поднят шейпинг, траффик просто не идет. есть три варианта решения проблемы.

1.ingress policer. плохой вариант, потому что негибкий. для нас было бы идеально, если бы торренты забивали весь канал когда никто не пользуется, но немедленно отдавали его если кто-то из сети пользует инет.

2.встроенный в rtorrent шейпер. этот вариант испольуем как временный. просто крутим его руками. когда кому-то что-то надо, подрубаемся к скрин сессии и выставляем приемлимое значение. когда заканчиваем работу в сети - делаем как было. пробелма в том, что лень делать это руками во первых, и не все в состоянии это сделать во вторых.

3.http://www.linuxfoundation.org/en/Net:IFB . смысл в том, что весь трафик пришедший на инетовский интерфейс заворачивается на вирутальный интерфейс, который уже, в свою очередь, его всем _раздает_, в том числе и локальным для роутера процессам. решение идеальное, да только не работает. проблема тут:

Код: Выделить всё

ifconfig ifb0 up
tc qdisc add dev ppp0 ingress
# redirect all IP packets arriving in eth0 to ifb0 
# use mark 1 --> puts them onto class 1:1
tc filter add dev ppp0 parent ffff: protocol ip prio 10 u32 \
  match u32 0 0 flowid 1:1 \
  action ipt -j MARK --set-mark 1 \
  action mirred egress redirect dev ifb0

собственно эти комманды создают виртуальный интерфейс, поднимают на нем ингресс полисер и весь найденный на нем траффик передают на вируальный. я так понял. с документацией тут туго, но смысл угадывается. и всебы хорошо, да только вот:

Код: Выделить всё

/usr/lib/iptables: cannot open shared object file: No such file or directory
 failed to find target MARK

bad action parsing
parse_action: bad value (11:ipt)!

вот тут народ тоже обсуждал: http://lists.altlinux.org/pipermail/sis ... 06538.html

я 10 раз перепроверил, в ядре все нужное у меня стопудово есть. по крайней мере поддержка цели MARK железно вкомпилена в само ядро. может проблема в том, что оно продразумевается модулем? ведь фактически там где оно его ищет, его в самом деле нет. даже диры нет. может создать диру просто?=) или в самом деле скомпилить модулем?

[phaoost]

tes+or, modprobe xt_MARK ?

upd: нет, вроде проблема в самом tc:

Код: Выделить всё

warp:~# tc filter add dev ppp0 parent ffff: protocol ip prio 10 u32 \
>   match u32 0 0 flowid 1:1 \
>   action ipt -j MARK --set-mark 1 \
>   action mirred egress redirect dev ifb0
/lib/iptables/libipt_mark.so: cannot open shared object file: No such file or directory
 failed to find target MARK
warp:~# find /lib -name "*mark.so"
/lib/ebtables/libebt_mark.so
/lib/xtables/libxt_connmark.so
/lib/xtables/libxt_mark.so
warp:~# iptables -V
iptables v1.4.1.1
warp:~# tc -V
tc utility, iproute2-ss080725

upd2: http://lists.openwall.net/netdev/2007/12/24/14

[tes+or]

вобщем выяснилось следующее:

1.цель MARK, тем более вызываемая из селектора нам была попросту ненужна.

2.IFB нам тоже неужен потому как не годится. вот диаграмма http://l7-filter.sourceforge.net/PacketFlow.png так вот IFB не реализует эту диаграмму, т.е. он реализует исключительно ее блоки с красными заголовками, все остальное как мы поняли там отсутствует. вообще это нормально, но в случае с NAT это делает классификацию невозможной, потому что сперва мы делаем классификацию и приоритезацию, а потом трафф попадает на интерфейс где его NATит. а перед натом мы не можем классифицировать траффик, потому что там еще айпишники не растранслированы обратно.

3.решилось все использованием IMQ. это по сути два патча, на ядро и на айпитаблицы. сами авторы утверждают что решение более чем надежное, хотя вроде как хак, причем кривой, по причине чего IFB и пишется сейчас. однако, как мы можем видеть, не все еще там реализовано. а IMQ в свою очередь поднялось и без проблем заработало, чему я очень рад.

пока вроде все.

[tes+or]

а вы знаете, толи я что-то не так делаю, толи пакету можно присваивать несколько меток одновременно, по крайней мере две, хотя об этом вроде не написано нигде. т.е. ситуация:

ставлю на пакет метку - на него срабатывает селектор для tc. при некоторых условиях поверху ставится еще одна метка, на которую должен срабатывать другой селектор на другом интерфейсе, но тот селектор который срабатывает на старую метку продолжает на нее срабатывать. это нормально?

чесговоря знал бы раньше - все бы проблемы куда как проще решались у меня, потому что это в самом деле дофига удобно, ставить на один пакет несколько меток.

[Kornelius]

а не целесообразнее было бы взять просто линукс (только ядро), прикрутить только то, что необходимо для функционирования роутера + все необходимое для поддержки разнообразного железа, и запихнуть это все на LiveCD или LiveUSB. А не брать за основу какие либо дистрибутивы, там ведь много ненужного.
И тогда бы не так важно бы было железо: сдохло одно, берем другое и просто грузимся с флешки.
Правда лучше бы это делать на BSD, а не на Linux.