Как стать автором
Обновить

Комментарии 28

А еще можно сделать гит рерозиторий, и править в проекте файл с данными на одной машине, а остальные допустим по крону раз в минуту делают git pull и всё. Имхо, менее геморойно.
Да, вариант вполне жизнеспособен, однако я работал в условиях, когда серверную часть желательно было оставить как есть (кое-кто придерживается старого правила «работает — не трогай»). Поэтому я и выбрал вариант, в котором инициализация работы происходит со сторонней машины.
Если изменять серверную часть, то, наверное, лучше было бы сразу посмотреть в сторону динамической маршрутизации (тот же bird).
Зачем же так сложно, неудобно и некрасиво? Все прогрессивное человечество вот уже 30 лет пользуется протоколами динамической маршрутизации.
Присоединяюсь к вопросу. На юниксах есть пакет zebra, который позволяет настроить и RIP и OSPF. Раз настроили и забыли.
Иногда динамика невозможна. Скажем, пакет Quagga не умеет работать с «виртуальным» ip-адресом carp-интерфейсов, упорно подсовывая в анонсах «реальный» ip-адрес, что во многих случаях неудобно. Авторы Quagga в рассылке заявили, что и не будут это исправлять, типа это фича.

В остальном соглашусь. И скрипты что-то очень уж… гм… монстроидальны. Центральный репозиторий svn/git был бы куда изящней.
Я вообще не фанат маршрутизации на Linux, все-таки, роутинг при помощи CPU — это уже не модно.

Для малого офиса, конечно, сойдет, пока поток через роутер не превышает 2-3 Мб/с, а количество сетей — 3-4 штук. Но дальше уже надо бы на специализированное оборудование переходить, желательно с Cisco Express Forwarding, чтобы маршрутизацией занимались исключительно ASIC, а процессор освободить для управления этой и другими функциями.
Гм, вы видимо в провайдерских сетях не работали ;) Маршрутизация на CPU это очень даже модно. Гигабит, причём с NAT'ом, маршрутизировать на серверах и под Linux — милое дело, стоит на порядок дешевле цисковских (и не только) NAT-железок. А уж чистый роутинг на этих скоростях вытянет любой современный офисный тазик с нормальной сетевушкой.
Работал :-) Я, кагбэ, исключительно с провайдерами и работаю. Правда, не нашими. К примеру, сейчас работаю с Sprint, одним из 12 Tier 1 операторов.

Чистый роутинг на 1 Гб/с между 10 разными сетями — не вытянет, готов поспорить :-) То есть, итоговая скорость не будет 1 Гб/с из-за задержек на обработку пакетов. А уж цепочка таких роутеров сделает задержку совсем неприличной.
Ну давайте поспорим, не вопрос :) С многоядерными процессорами и интеловскими картами с поддержкой нескольких очередей MSI-X влёгкую.
:-)

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

Поставьте эксперимет, если Вам интересно: подключите каскадом несколько компов на Linux с настроенным роутингом и рядом — несколько роутеров с поддержкой Cisco Express Forwarding, и просто попингуйте сеть на одном конце цепочки с другого ее конца. И посмотрите на delay.

Для того, чтобы ускорить маршрутизацию пакетов при помощи центрального процессора, когда-то придумали MPLS. Cisco Express Forwarding позволяет маршрутизировать обычные пакеты с той же скоростью, с которой это делают P роутеры в MPLS сети по меткам. Никогда процессором вы не добьетесь этой скорости.
Ну да, бессмысленный спор за отсутствием реального приложения. Но говорить, что нужна циска при потоках, превышающих 2-3 Мбайт/сек, является уж явным и абсолютным преувеличением.
Добро пожаловать на Хабр.
Спасибо!
Обалдеть.

Я конечно что-то не понимаю наверное, но это очень кривые костыли, которые просто из неправильной архитектуры сети вытекают.

Поднимите или демоны динамической маршрутизации (типа quagga или zebra) на машинках или dhcp rfc смотрите:

tools.ietf.org/html/rfc2132

5.8. Static Route Option

This option specifies a list of static routes that the client should
install in its routing cache. If multiple routes to the same
destination are specified, they are listed in descending order of
priority.
Вариант с DHCP может не подойти, ибо изменения очень инертны получаются. а вот включить тупой RIP
командной router_enable="YES", действительно не сложно
Безусловно, динамика лучше.

Но если уж гоняют скрипты — то попросить dhcpcd проапдейтить руты (одна команда вместо тонны ненужных скриптов — дефакто нужно дать только SIGHUP сигнал демону) — все равно сильно лучше и проще предложенного решения.
Согласен, что «неправильная» (устаревшая) архитектура сети — ключ ко всему. Я работал с тем, что есть, о чём писал в комментарии выше. Топик — это описание реализации конкретного решения конкретной задачи, плюс небольшое описание некоторых особенностей shell-скриптов (работа с опциями скрипта, передача команды в качестве параметра функции), кому-то может пригодиться. И я не уверен, что запуск dhclient'a на серверах будет одобрен свыше. Но за наводку спасибо, об этом я, признаться, не подумал.
ребята, давайте я вам конфиги для OSPF напишу, а? Забесплатно :)
Спасибо, особенно за бескорыстие — это в наше время довольно редкое явление =) Но, если дадут добро на OSPF, мы и сами как-нибудь справимся =)
Извините, а зачем написана эта статья? Я восхищаюсь Вашим трудолюбием и понимаю, что в Вашем случае внедрение OSPF может быть и невозможно («я работал в условиях, когда серверную часть желательно было оставить как есть»), но зачем описывать это здесь? Вряд ли кто-нибудь пойдёт удалять свою кваггу или bird и адаптировать под себя выложенные скрипты.
Прошу прощения, что повторяюсь в комментариях, но отвечу и здесь. Топик — это описание реализации конкретного решения конкретной задачи, плюс небольшое описание некоторых особенностей shell-скриптов (работа с опциями скрипта, передача команды в качестве параметра функции), я посчитал, что кому-то может пригодиться (раз схема со статическими маршрутами работает у нас, то она вполне может встретиться и где-то ещё). Я ни в коем случае не призываю отказываться от динамической маршрутизации или от своих наработанных схем. =)
что люди только не делают чтобы не использовать какой-либо igp, хотя бы тот же rip и коробочного routed O_o
А я всегда настраивал рип или оспф, думаю тут это тоже уместно.
Free-BSDшники шальные люди.

Титанический труд автора безусловно заслуживает уважение за исключением одной мелочи — постановка такой задачи полный идиотизм! Несколько десятков лет огромное количество людей разрабатывают протоколы маршртизации для того чтобы вот ЭТО НЕ ДЕЛАТЬ вручную.
«я не переписываю телнетд! мне лень его исходники качать!!» (c баша, не смог удержаться =) )
Мы не шальные, это автор… гм… тот ещё выдумщик. :)
автор зверь, перелопатил на С свою статическую маршрутизацию сети. есть еще умельцы!
долой динамические протоколы циски и прочую ересь! даешь С! шучу )
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории