[Saab95]

Я разговор вел про то, что биллинг полностью отключится (все резервные сервера биллинга тоже перестанут быть доступными). При этом никаким образом адреса уже не будут перераспределятся и вся сеть будет функционировать самостоятельно на локальных базах каждого сервера. В самом крайнем случае, когда например BGP полностью отключится и не будет связи по белым адресам, все переключается на НАТ через каналы вышестоящих операторов. У них нужно обязательно заказывать хотя бы один белый адрес для этих целей.

Если биллинг полностью отключился - с какой радости микротик должен пускать абонов? Откуда ему знать, что абон Вася, не оплативший 100500 лет назад инет, теперь его оплатил и пользуется? А может - и не оплатил, но решил подключиться проверить- вдруг инет есть? И почему это биллинг будет недоступен, а сервера с БГП - доступными?

Вклчение ната при падении бгп - если сервер работает с нагрузкой проца более 50% без ната, как думаете, к чему приведет включение ната? ;)

 

И опять же, нарисуйте, как будет работать ваша вундервафля с десятком каналов к аплинкам при необходимости использовать 4 разных апстрима, и растянуть поверх этого одну-единственную подсеть /24 (ну или любую другую) в случае потери связи с центром? Чо, трафик побежит на бордюр, а потом с него - через канал апстрима чудом смаршрутизируется на брасы? Или EoIP городить еще? И чем это лучше резервного л2 транспорта в ядро через аплинк с STP?

 

Ну вот схема:

 

Допустим есть 3 сервера доступа, например в разных городах или районах одного города. Все они объединены между собой своими каналами (или арендованными, тут не важно), на примере указано звездой, но ничего не мешает и подключать несколько друг за дружкой. Обычно это оптоволокно или РРЛ.

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

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

Каждый сервер доступа кроме всего подключен через 3-го оператора напрямую к интернету, через него можно поднять туннели до своего BGP сервера.

 

Все устройства общаются между собой по OSPF, что само собой подразумевает возможность раскидывания подсети /24 куда угодно без ограничений.

 

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

 

Если полностью отключится BGP сервер, то естественно под реальниками клиенты работать не смогут, тут вся сеть переводится в режим NAT и клиенты сливаются через каналы 3-го оператора (и с серыми и с белыми адресами, только белые тут превращаются в серые). Если отключится BGP и например часть своих каналов, то через OSPF по оставшимся все получат маршрут в интернет и смогут передавать туда данные.

 

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

 

Далее по поводу не оплативших. Во время работы биллинг отправляет учетки на каждый PPPoE терминатор, где они и хранятся на случай проблем. Если клиент не оплатил, то его адрес добавляется в список должников и доступа в сеть у него нет, работает переадресация на страницу с информацией. Поэтому потеряв связь с биллингом никакой халявы не будет. Все продолжит работать в штатном режиме, только естественно с ограниченным функционалом.

 

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

[NiTr0]

По схеме: нарисован всего 1 апстрим. + 3 типа резервных канала через "домашний интернет" другого прова, как я понял. Ибо держать в данной схеме по несколько сот мбит на брас "гуляющих" - расточительство, при цене гарантированных каналов... А они - именно гуляющие, и именно домашние (т.к. в противном случае был бы полноценный транспорт в ядро, а не пляски с натом).

 

Далее, упал биллинг. Выдало десяткам абонов одинаковые ип адреса. Никто толком не работает... Биллинг поднялся/связь с брасом восстановилась - и если сессии продолжают работать локально, не уведомляя радиус о своем существовании, в сети случается жопа. Если уведомляют, а биллинг не умеет их дропать - случается жопа.

 

Если полностью отключится BGP сервер, то естественно под реальниками клиенты работать не смогут, тут вся сеть переводится в режим NAT и клиенты сливаются через каналы 3-го оператора (и с серыми и с белыми адресами, только белые тут превращаются в серые). Если отключится BGP и например часть своих каналов, то через OSPF по оставшимся все получат маршрут в интернет и смогут передавать туда данные.

Если БГП сервер потеряет сессию/упадет демон - случится жопа. Поясняю: в OSPF есть понятие default gateway. Т.е. пока сервер физически жив, и на нем оспф крутится - маршрут на него не пропадет, и весь трафик будет бежать на него.

 

А в целом - все то же самое прекрасно реализовывается и на линуксе. Причем - еще проще. Поднимается локальный радиус, выдающий ип из серого пула; для авторизации - прописывается 2 радиус-сервера, первый - биллинга, второй - локальный. Ну и указанные "типа резервные" каналы через домашние пакеты третьего оператора, если хочется. Аккаунтинг пакеты шлются на биллинг, который потом "серые" сессии дропает. При желании - можно и докрутить списки авторизации вместо разрешения всех подряд. Но на практике - я такого не встречал, и навряд встречу.

[Saab95]

По схеме: нарисован всего 1 апстрим. + 3 типа резервных канала через "домашний интернет" другого прова, как я понял. Ибо держать в данной схеме по несколько сот мбит на брас "гуляющих" - расточительство, при цене гарантированных каналов... А они - именно гуляющие, и именно домашние (т.к. в противном случае был бы полноценный транспорт в ядро, а не пляски с натом).

 

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

 

Далее, упал биллинг. Выдало десяткам абонов одинаковые ип адреса. Никто толком не работает... Биллинг поднялся/связь с брасом восстановилась - и если сессии продолжают работать локально, не уведомляя радиус о своем существовании, в сети случается жопа. Если уведомляют, а биллинг не умеет их дропать - случается жопа.

 

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

 

Если полностью отключится BGP сервер, то естественно под реальниками клиенты работать не смогут, тут вся сеть переводится в режим NAT и клиенты сливаются через каналы 3-го оператора (и с серыми и с белыми адресами, только белые тут превращаются в серые). Если отключится BGP и например часть своих каналов, то через OSPF по оставшимся все получат маршрут в интернет и смогут передавать туда данные.

Если БГП сервер потеряет сессию/упадет демон - случится жопа. Поясняю: в OSPF есть понятие default gateway. Т.е. пока сервер физически жив, и на нем оспф крутится - маршрут на него не пропадет, и весь трафик будет бежать на него.

 

В микротике можно прописать дефолтный маршрут сам на себя, в случае BGP сервера. При падении канала скриптом он отключается и трафик уже бежит на другие узлы. Почему то как в линуксах и прочих системах писать скрипты это ничего зазорного, а на микротике про них и не упоминается=)

 

А в целом - все то же самое прекрасно реализовывается и на линуксе. Причем - еще проще. Поднимается локальный радиус, выдающий ип из серого пула; для авторизации - прописывается 2 радиус-сервера, первый - биллинга, второй - локальный. Ну и указанные "типа резервные" каналы через домашние пакеты третьего оператора, если хочется. Аккаунтинг пакеты шлются на биллинг, который потом "серые" сессии дропает. При желании - можно и докрутить списки авторизации вместо разрешения всех подряд. Но на практике - я такого не встречал, и навряд встречу.

 

Вот надо докручивать, а на микротике и без кручения все работает.

[Ivan_83]

В микротике можно прописать дефолтный маршрут сам на себя, в случае BGP сервера. При падении канала скриптом он отключается и трафик уже бежит на другие узлы. Почему то как в линуксах и прочих системах писать скрипты это ничего зазорного, а на микротике про них и не упоминается=)

У микротика виндовый конфигуратор для чайников чуть ли не единственное преимущество, если пытаться использовать его как фрю/линух то он сливает во всём.

Мелкое дешманское железо и вайфаи это отдельная тема.

[NiTr0]

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

Если покупать как юрлицо - то покупать транспорт в ядро и все.

 

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

Да ну? И как потом билилнг будет учитывать эти сессии, с непонятно откуда взятыми адресами?

А если адреса выдаются совпадающие с последним выданным биллингом - горе будет...

 

В микротике можно прописать дефолтный маршрут сам на себя, в случае BGP сервера. При падении канала скриптом он отключается и трафик уже бежит на другие узлы. Почему то как в линуксах и прочих системах писать скрипты это ничего зазорного, а на микротике про них и не упоминается=)

 

И нафига такое извращение? Скриптовый костыль прикручивать? Кто-то там что-то о "искаропки" говорил?

И нафига дефолтный маршрут сам на себя??? Или микротик не поддерживает маршрут в null?

 

Вот надо докручивать, а на микротике и без кручения все работает.

 

Само по себе силой мысли? :)

[Saab95]

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

Если покупать как юрлицо - то покупать транспорт в ядро и все.

 

Не каждый провайдер может продавать транспорт, либо он такой, что проще взять у него интернет и самому поднять в нем нужные туннели. Многие вообще друг у друга каналы перекупают и накручивают, особенно в аренде каналов L2.

 

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

Да ну? И как потом билилнг будет учитывать эти сессии, с непонятно откуда взятыми адресами?

А если адреса выдаются совпадающие с последним выданным биллингом - горе будет...

 

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

 

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

 

 

В микротике можно прописать дефолтный маршрут сам на себя, в случае BGP сервера. При падении канала скриптом он отключается и трафик уже бежит на другие узлы. Почему то как в линуксах и прочих системах писать скрипты это ничего зазорного, а на микротике про них и не упоминается=)

И нафига такое извращение? Скриптовый костыль прикручивать? Кто-то там что-то о "искаропки" говорил?

И нафига дефолтный маршрут сам на себя??? Или микротик не поддерживает маршрут в null?

 

Там костыль из 10 строк, при этом достаточно написать команды в планировщик и он все сделает как надо. На микротике маршрут сам на себя аналогичен null на линуксах. Обычно бридж создают и его используют в качестве интерфейса назначения для этого маршрута.

 

Вот надо докручивать, а на микротике и без кручения все работает.

 

Само по себе силой мысли? :)

 

Да.

[NiTr0]

Не каждый провайдер может продавать транспорт, либо он такой, что проще взять у него интернет и самому поднять в нем нужные туннели. Многие вообще друг у друга каналы перекупают и накручивают, особенно в аренде каналов L2.

Любой провайдер с сетью не на мыльницах вполне себе предоставит как минимум один влан. Как максимум - полноценный транспорт, завернутый у него в qinq.

 

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

 

А ип из нетфлоу кто будет к пользователям привязывать? Пушкин?

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

 

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

Причем тут бекап, если достаточно отсутствия связи на момент поднятия сессии? Или у вас для абонов статически выдаются белые адреса???

 

Там костыль из 10 строк, при этом достаточно написать команды в планировщик и он все сделает как надо.

А для этого команды еще надо найти и изучить, и надо придумать логику...

 

На микротике маршрут сам на себя аналогичен null на линуксах.

Не аналогичен. Пакет при маршруте через себя будет крутится в роутере пока не истечет TTL. Т.е. PPS увеличится в ~60-120 раз. Некисло так, да?

 

Да.

Угу, и костыль напишется силой мысли... Еще и в планировщик сам по себе поместится...

[Saab95]

Не каждый провайдер может продавать транспорт, либо он такой, что проще взять у него интернет и самому поднять в нем нужные туннели. Многие вообще друг у друга каналы перекупают и накручивают, особенно в аренде каналов L2.

Любой провайдер с сетью не на мыльницах вполне себе предоставит как минимум один влан. Как максимум - полноценный транспорт, завернутый у него в qinq.

 

Это какой? Большинство провайдеров, предоставляя канал L2, устанавливают ограничение по макам, а при аренде Q-in-Q порой бывают такие глюки, что как я и говорил выше, проще самому туннель поднять.

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

 

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

А ип из нетфлоу кто будет к пользователям привязывать? Пушкин?

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

 

Если выдавать серые адреса статикой, как многие и делают, то проблем нет. Останутся только у белых, но им можно и реконнект сделать.

 

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

Причем тут бекап, если достаточно отсутствия связи на момент поднятия сессии? Или у вас для абонов статически выдаются белые адреса???

 

Если просто пропала связь с биллингом, то после ее восстановления никаких проблем нет, т.к. какие адреса были выданы под такими клиенты и работают, следовательно нетфлоу будет все верно обсчитывать.

 

Там костыль из 10 строк, при этом достаточно написать команды в планировщик и он все сделает как надо.

А для этого команды еще надо найти и изучить, и надо придумать логику...

 

Можно сказать для других систем в комплекте идет книга со всеми возможными разъяснениями для чайников? =)

 

На микротике маршрут сам на себя аналогичен null на линуксах.

Не аналогичен. Пакет при маршруте через себя будет крутится в роутере пока не истечет TTL. Т.е. PPS увеличится в ~60-120 раз. Некисло так, да?

 

Этот маршрут только для того, что бы отправить его через OSPF. Что бы показать другим узлам что все пакеты в интернет отправлять на него. Когда пакет попадет на маршрутизатор, то он знает куда его отправить, т.к. у него есть все маршруты на интернет через BGP.

[NiTr0]

Большинство провайдеров, предоставляя канал L2, устанавливают ограничение по макам

С какой такой радости? Никогда такого не встречал. Не говоря о том, что там будет десяток-другой маков от силы...

 

а при аренде Q-in-Q порой бывают такие глюки, что как я и говорил выше, проще самому туннель поднять.

Какие такие глюки? Поподробнее с этого момента...

 

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

Какая разница-то? Оптику до аплинка не судьба протянуть???

 

Если выдавать серые адреса статикой, как многие и делают, то проблем нет. Останутся только у белых, но им можно и реконнект сделать.

Кто эти многие? Я таковых не знаю. Ну кроме пионеров без своей AS...

 

Если просто пропала связь с биллингом, то после ее восстановления никаких проблем нет, т.к. какие адреса были выданы под такими клиенты и работают, следовательно нетфлоу будет все верно обсчитывать.

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

 

Можно сказать для других систем в комплекте идет книга со всеми возможными разъяснениями для чайников? =)

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

 

Этот маршрут только для того, что бы отправить его через OSPF. Что бы показать другим узлам что все пакеты в интернет отправлять на него. Когда пакет попадет на маршрутизатор, то он знает куда его отправить, т.к. у него есть все маршруты на интернет через BGP.

 

Ух какой костылище знатный-то...

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

А что будет с вашим микротиком, когда внезапно бгп сессия отпадет - я уже описал... Будет он гонять пакеты сам через себя до истечения их TTL, и хорошо если не скукожится под резко возросшей нагрузкой (что вполне может быть, учитывая глюкавость).

[Saab95]

Большинство провайдеров, предоставляя канал L2, устанавливают ограничение по макам

С какой такой радости? Никогда такого не встречал. Не говоря о том, что там будет десяток-другой маков от силы...

 

Насколько я понял по подписи вы с Украины. Не знаю как там, а в РФ операторы очень любят либо экономить, либо продавать то, что не могут реализовать. В большинстве каналов есть различного рода ограничения, так же бывает в них залетает чужой трафик при перегрузах оборудования.

 

а при аренде Q-in-Q порой бывают такие глюки, что как я и говорил выше, проще самому туннель поднять.

Какие такие глюки? Поподробнее с этого момента...

 

Да обычные - часть номеров вланов работает, а часть нет. Или проблемы с прохождением трафика или MTU. Если взять тот же микротик и поднять EoIP то получится такой канал, который пропускает все подряд, хоть QinQinQinQinQinQinQ и еще много Q, т.к. программно запаковывает пакеты, передает через интернет и распаковывает назад. Что вошло то и вышло. А любители цисок и иного оборудования любят гонять прозрачный L2 напрямую или через MPLS, и при не соответствии своих возможностей с проданными услугами начинаются косяки. Кто сталкивался с арендой каналов по всей стране знает, как много на рынке обманок в этой сфере.

 

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

Какая разница-то? Оптику до аплинка не судьба протянуть???

 

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

 

Если выдавать серые адреса статикой, как многие и делают, то проблем нет. Останутся только у белых, но им можно и реконнект сделать.

Кто эти многие? Я таковых не знаю. Ну кроме пионеров без своей AS...

 

А я знаю. Обычно кто выдает серые привязывает адрес к конкретному клиенту. Их же не нужно экономить.

 

Если просто пропала связь с биллингом, то после ее восстановления никаких проблем нет, т.к. какие адреса были выданы под такими клиенты и работают, следовательно нетфлоу будет все верно обсчитывать.

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

 

Ну на крайний случай потеряется часть статистики. Что это разве большая проблема?

 

Можно сказать для других систем в комплекте идет книга со всеми возможными разъяснениями для чайников? =)

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

 

На микротике все намного проще, и в большинстве случаев не нужно ничего дописывать.

 

Этот маршрут только для того, что бы отправить его через OSPF. Что бы показать другим узлам что все пакеты в интернет отправлять на него. Когда пакет попадет на маршрутизатор, то он знает куда его отправить, т.к. у него есть все маршруты на интернет через BGP.

Ух какой костылище знатный-то...

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

А что будет с вашим микротиком, когда внезапно бгп сессия отпадет - я уже описал... Будет он гонять пакеты сам через себя до истечения их TTL, и хорошо если не скукожится под резко возросшей нагрузкой (что вполне может быть, учитывая глюкавость).

 

Не будет он гонять пакеты сам через себя. Сразу вернет что получатель недостижим.

[Ivan_83]

Уверены что пока ттл не станет = 0 оно не будет гонять пакет по кругу внутри?

[Saab95]

Уверены что пока ттл не станет = 0 оно не будет гонять пакет по кругу внутри?

 

Он его что сам себе что ли отправлять будет? Скинет на бридж, на котором IP адреса нет и сразу получатель недостижим.

[NiTr0]

Насколько я понял по подписи вы с Украины. Не знаю как там, а в РФ операторы очень любят либо экономить, либо продавать то, что не могут реализовать. В большинстве каналов есть различного рода ограничения, так же бывает в них залетает чужой трафик при перегрузах оборудования.

 

qinq туннель какбы проблем не составит. На любом оборудовании. Чужой трафик - маловероятно, но даже если и попадет - ну и фиг с ним. Хотя в вашей схеме и qinq не надо, одного растегированного влана достаточно.

 

Да обычные - часть номеров вланов работает, а часть нет. Или проблемы с прохождением трафика или MTU.

С какой такой радости?

 

Если взять тот же микротик и поднять EoIP то получится такой канал, который пропускает все подряд, хоть QinQinQinQinQinQinQ и еще много Q, т.к. программно запаковывает пакеты, передает через интернет и распаковывает назад. Что вошло то и вышло.

Угу, и поиметь проблемы с MTU в полный рост...

О производительности этого решения - помолчу; покажите мне железку, способную прокачать гиг симметричного трафика через EoIP...

 

Кто сталкивался с арендой каналов по всей стране знает, как много на рынке обманок в этой сфере.

 

Несоответствие - на первый раз жалоба в саппорт, не помогло - смена оператора. Делов-то...

 

А я знаю. Обычно кто выдает серые привязывает адрес к конкретному клиенту. Их же не нужно экономить.

Обычно серые выдают те, у кого либо нет своей AS, либо нет конкурентов, предоставляющих за те же деньги белый адрес. Ибо на белом адресе и скайп лучше работает, и торренты лучше качают, и на гугле не банят нат-адрес по подозрению в ботнете, и файлопомойки не ругаются "с вашего ип уже качают", и т.д. Не, для сети на 50 абонов конечно пофиг, а вот для сколь-либо крупного прова это будет печально...

Не говоря о том, что с определенного момента дешевле докупать AS, чем вкладываться в железки для ната.

 

Ну на крайний случай потеряется часть статистики. Что это разве большая проблема?

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

 

На микротике все намного проще, и в большинстве случаев не нужно ничего дописывать.

Описанное нагромождение костылей с самописным скриптом - проще? Не заметил что-то...

[dr.Livci]

Что, вы, ребята, демонизируете этот микротик ОС.

Не нужно забывать - что "под капотом" там - GNU/Linux - c "жёстко натянутой непривычной мордой".

 

Нужно четко понимать нишы, а не холиварить: "железные вундервафли против линупса"

или

"свой кошерный линупс против готовой закрытой некошерной сборки".

 

Вы ж таки умные ребята.

Всему своя ниша.

 

Все просто:

1. Есть деньги, и объемы трафика и к-во клиентов выше N - юзай специализированные железки, нанимай кошерных специалистов.

2. Небольшой бизнес? Малые объемы трафика? Малое к-во клиентов? Денежные потоки или "политические мотивы" не позволяют железки заиметь? - юзай софт решения - оно тоже работает.

Никто тебе, анонимус, не запретит юзать линупс, солярку или бсд или , не дай бох - виндавс 2008 server.

Можешь даже соврать друзьям и клиентам - что у тебя сиськи или жуниперы стоят - никто разницы не заметит )))

 

2A. Умеешь сам тонко тюнить линукс/бсд ? - имеешь большой опыт и скил? (с 90-х намучил людей в пионер сети или на заводе)? ты сам себе начальник и просрал все полимеры на шлюх? Или начальник жалеет денег на редбэк? Тогда готовь сам свой линупс.

2B. Не имеешь опыта в готовке линупса или редбэка? Сельский программист по заправке принтера? Возьми готовую сборку дистрибутива линукс аля MikroTik Router OS.

 

 

И что тут спорить - что готовая закрытая сборка имеет свои минусы - закрытость и ограничинность тюнинга не дает выжать максимальную производительнось по сравнению с открыой системой, которую можно оттюнить по самое небалуй. Иногда разница действительно может быть в разы. ! Но дешивизна лицензии на микротик и железа общего назначения (PC x86) - легко компенсирует танцы с тюнингом драйверов, прерываний и ядра )

Но есть и плюс готовой сборки - это очень быстро и легко позволит развернуть сетевые службы в любом поселке за Уралом:

ВПН, шейперы, днс, дхцп, бгп, вланы, роутинг, нетфлоу, радиус и отличная (лучшая) морда для iptables и шейпер и многое другое - все быстро и лекго и удобно настраивается с помощью мышки ))))) как в винде )

Ведь иногда нужно очень быстро в ***ковичах настроить сеть - а чёта опытные спецы из Москвы не хотят ехать за 5 копек в ***ковичи.

 

Да - можно потроллить админов, которые юзают Микротики - что они ниасилили БСД или линупс или цыски. На здоровье.

 

И еще - не надо ставить в продакшн бета версии и релиз кандидаты))) (либо на свой страх и риск).

Это я про троллинг новых поделий микротиковцев и Release Candidate 6x

(старые проверенные железки + 5 версия ROS отлично молотят в ***ковичах по всему миру (особенно этот ваш вай фай))

 

 

Теперь по пунктам разбиваем мифы специалистов от линупсов и цысок, которые по слухам что-то пишут хуиту про Микротик:

 

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

А какая разница с линупсами?

Настройте правильно роутинг в сети - маршруты "заглушки" в таблице маршрутизации никто не отменял- типа blackhole или unreachable - чтобы "занулить" трафик.

 

Что за херню и проблемы вы придумали с изменением скорости на Тике?

На серве с Микротиком и 2 000 юзеров - например - ночное увеличение скорости- делается за доли секунды - всего две команды на каждый тариф - для up и down трафика.

Если юзеру нужен личный форсаж - пжлста - он нажимает "турбо кнопку" в личном кабинете в биллинге - и за доли секунды попадает в другую ветку шейпера.

Ессно - все это без обрыва сессий!!!

Ничем не отличается от линупсов )))

 

 

По поводу накладки адресов у юзерских сессий - тоже чушь - нет таких проблем - тут хоть сто раз биллинг ребутай.

Тут тоже микротик ничем не отличается от линупсов.

Тут только его величество RADIUS - аутентификация, авторизация, аккаунтинг.

Тут все зависит от биллинга!!!

И микротик тут или БСД или линупс - пофиг - НЕ ОНИ рулят адресами. А биллинг!

Не слышал проблем ни разу с накладкой адресов от тех, кто юзает микротик + всем известные в СНГ биллинги из первой десятки.

Ничем не отличается от линупсов ))) (радиус просто радиус, господа)

 

Далее по поводу логов и ментов - чем тут Тик отличается от других линупсов?

Ничем.

Если раздаешь белые ипы (и это правильно) собирай себе логи радиус на удаленный сислог сервер и сливай нетфлоу.

Если юзаешь NAT - тоже никаких отличий от линупс - теже сложности - как собирать инфу для ментов в таких случаях уже не раз писано в Сети.

 

Ну и так далее.

Изменено 14 мая, 2013 пользователем dr.Livci

[dr.Livci]

а теперь ответ на вопрос афтора темы

какое железо выбрать для MikroTik v6.0rc14

1. Не надо юзать релиз кандидат - он сырой и глючный. Юзай 5. Потом запилят 6-ку - подождать еще.. год ))) и обновишься.

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

3. Сетевухи должны быть кошерные - но это и так понятно. Список кошерных типа "серверных" сетевух можно найти на этом форуме.

На сайте микротика можно найти список отзывов про разное железо и чипсеты...

4. Память 2 гига - больше ось не видит - но ей столько и не надо - на 2 000 L2TP - 300 метров кушает всего.

5. Не будет хватать производительности - поставишь рядом такой же (сразу ставь рядом такой же для балансировки/отказоустойчивости).Благо у тебя PPPOE - вообще ничего не нужно специально для этого настравиать - юзеры рандомно будут цепляться на твои серваки приблизительно равномерно (+/- 0,3%)

 

Вообще - производительность зависит от к-ва пакетиков в секунду и к-во правил фаера и шейпера.

PPPoE - это хорошо - оно на Тике работает в ядре, в отличии от PPTP/L2TP - которые в юзерспейсе.

Далее - не юзай simple queue - которые создаются автоматом, если передавать рейты через радиус атрибуты - юзай дерево очередей (Queue Tree) - это во много раз улучшит запас производительности. (Это самый важный пункт моего совета!!!!)

NAT - это конешно херово, но все таки проц грузит не особо - но нужно чуть подтюнить conntrack

Не юзай разные хернюшки типа построение графиков (graphing), не юзай L7 filtering, не перемудри с к-вом правил фаера - оптимально настрой минимально нужно к-во правил - с оптимальным порядком следования.

Ёжику ясно - что не юзай шифрование юзерских pppoe тунелей )

 

Проц бери intel 6 ядер - побольше мегагерц.

 

В общем ты понел - не бери брендовый сервак - Тик может с большой веротностью на нем не взлететь и Тик нормально работает на "обычном" железе (если оно изначально не глючное).

Изменено 14 мая, 2013 пользователем dr.Livci

[NiTr0]

Не нужно забывать - что "под капотом" там - GNU/Linux - c "жёстко натянутой непривычной мордой".

...и жестко изуродованный вендорскими костылями. Еще и базовая версия ядра, на которую они напиливались, ископаемая...

 

И еще - не надо ставить в продакшн бета версии и релиз кандидаты))) (либо на свой страх и риск).

Это я про троллинг новых поделий микротиковцев и Release Candidate 6x

Висы/краши в 5.х при коннекте по ssh, обсуждаемые в соседней ветке, которые за год никто так и не сподвигся пофиксить, какбы намекают на качество софта в целом и отношение к его потребителям в частности.

 

Что за херню и проблемы вы придумали с изменением скорости на Тике?

На серве с Микротиком и 2 000 юзеров - например - ночное увеличение скорости- делается за доли секунды - всего две команды на каждый тариф - для up и down трафика.

По ssh, как предложил тута дистрибьютор тика, по принципу "одна команда - один коннект"? Не верю.

 

И микротик тут или БСД или линупс - пофиг - НЕ ОНИ рулят адресами. А биллинг!

Читайте внимательнее. Предлагается таки выдача адресов самим микротиком. Типа "для резервирования" биллинга. Только горя от этого больше, чем толку будет.

 

Проц бери intel 6 ядер - побольше мегагерц.

Это как, на 10 гбит трафика? Или это так плохо с производительностью ROS?

[Saab95]

Да обычные - часть номеров вланов работает, а часть нет. Или проблемы с прохождением трафика или MTU.

С какой такой радости?

 

Я откуда знаю, это все по опыту. Даже крупные операторы этим страдают, потом оказывается что часть вланов на каких-то коммутаторах куда-то там заворачиваются или фильтруются. Приходится 100 раз обращаться в поддержку что бы эту проблему решили.

 

Если взять тот же микротик и поднять EoIP то получится такой канал, который пропускает все подряд, хоть QinQinQinQinQinQinQ и еще много Q, т.к. программно запаковывает пакеты, передает через интернет и распаковывает назад. Что вошло то и вышло.

Угу, и поиметь проблемы с MTU в полный рост...

О производительности этого решения - помолчу; покажите мне железку, способную прокачать гиг симметричного трафика через EoIP...

 

Проблем с MTU на микротике с EoIP нет. У него 65535 байт, на новых железках на сетевых портах под 4000, так что запас очень и очень большой. Гиг по EoIP прокачает CCR с 36 ядрами. А RB1100AHx2 может под 400 мегов прогнать.

 

Кто сталкивался с арендой каналов по всей стране знает, как много на рынке обманок в этой сфере.

Несоответствие - на первый раз жалоба в саппорт, не помогло - смена оператора. Делов-то...

 

Ну да, если выбор есть. А если его нет нужно наслаждаться тем что есть. Ругань тут не помогает, только отношения испортит.

 

А я знаю. Обычно кто выдает серые привязывает адрес к конкретному клиенту. Их же не нужно экономить.

Обычно серые выдают те, у кого либо нет своей AS, либо нет конкурентов, предоставляющих за те же деньги белый адрес. Ибо на белом адресе и скайп лучше работает, и торренты лучше качают, и на гугле не банят нат-адрес по подозрению в ботнете, и файлопомойки не ругаются "с вашего ип уже качают", и т.д. Не, для сети на 50 абонов конечно пофиг, а вот для сколь-либо крупного прова это будет печально...

Не говоря о том, что с определенного момента дешевле докупать AS, чем вкладываться в железки для ната.

 

Купите свою AS и адреса IPv4 за 3000 евро=) если найдете где они еще остались. Многие операторы держат статические серые IP еще со старых времен, когда была локалка и все держали FTP и игровые сервера у себя. У кого есть белые естественно их и выдают. У многих белых в нужном количестве нет, они выдают серые. Более того, есть такие, которые заставляют руками их вписывать, и что-то оттока клиентов у них нет, держат по 10000 и более, хотя есть конкуренты с PPPoE и DHCP.

 

Ну на крайний случай потеряется часть статистики. Что это разве большая проблема?

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

 

Тарифы же безлимитные. Ничего страшного.

 

На микротике все намного проще, и в большинстве случаев не нужно ничего дописывать.

Описанное нагромождение костылей с самописным скриптом - проще? Не заметил что-то...

 

На микротике проще.

[Saab95]

Не нужно забывать - что "под капотом" там - GNU/Linux - c "жёстко натянутой непривычной мордой".

...и жестко изуродованный вендорскими костылями. Еще и базовая версия ядра, на которую они напиливались, ископаемая...

 

Зато установка из коробки и все работает. Не нужно ставить драйвера и т.п. Ставится за 5 минут. Вы сможете линукс за столь малое время установить?

 

И еще - не надо ставить в продакшн бета версии и релиз кандидаты))) (либо на свой страх и риск).

Это я про троллинг новых поделий микротиковцев и Release Candidate 6x

Висы/краши в 5.х при коннекте по ssh, обсуждаемые в соседней ветке, которые за год никто так и не сподвигся пофиксить, какбы намекают на качество софта в целом и отношение к его потребителям в частности.

 

Никаких крашей по SSH нет. При правильной настройке разумеется. Обычно же как - настроили что-то криво, вылезла проблема - виноват микротик нужно лезть на форум и ругаться.

 

Что за херню и проблемы вы придумали с изменением скорости на Тике?

На серве с Микротиком и 2 000 юзеров - например - ночное увеличение скорости- делается за доли секунды - всего две команды на каждый тариф - для up и down трафика.

По ssh, как предложил тута дистрибьютор тика, по принципу "одна команда - один коннект"? Не верю.

 

Есть 3 схемы работы:

 

1.Локальная база на микротике, биллинг только ей управляет (включает и выключает клиентов).

2.Локальная база на микротике, биллинг авторизует по радиусу, а так же приводит в соответствие локальную базу микротика со своей.

3.Авторизация по радиусу.

 

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

 

Далее резать скорости можно 2 способами:

 

1.Через встроенные шейперы PPP.

2.Через деревья шейперов.

 

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

 

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

 

И микротик тут или БСД или линупс - пофиг - НЕ ОНИ рулят адресами. А биллинг!

Читайте внимательнее. Предлагается таки выдача адресов самим микротиком. Типа "для резервирования" биллинга. Только горя от этого больше, чем толку будет.

 

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

 

Проц бери intel 6 ядер - побольше мегагерц.

Это как, на 10 гбит трафика? Или это так плохо с производительностью ROS?

 

Хватит и 2-4 ядер. Это так для запаса.

[Ivan_83]

Зато установка из коробки и все работает. Не нужно ставить драйвера и т.п. Ставится за 5 минут. Вы сможете линукс за столь малое время установить?

dd образа с флешки на винт и вся установка.

[snark]

dd образа с флешки на винт и вся установка

 

Понимаете, тут все сильно зависит от версии USB и скорости флешки, интерфейса, частоты оборотов и скорости винта ... )))

[^rage^]

Этот маршрут только для того, что бы отправить его через OSPF. Что бы показать другим узлам что все пакеты в интернет отправлять на него. Когда пакет попадет на маршрутизатор, то он знает куда его отправить, т.к. у него есть все маршруты на интернет через BGP.

 

Ух какой костылище знатный-то...

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

А что будет с вашим микротиком, когда внезапно бгп сессия отпадет - я уже описал... Будет он гонять пакеты сам через себя до истечения их TTL, и хорошо если не скукожится под резко возросшей нагрузкой (что вполне может быть, учитывая глюкавость).

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

собственно, CCR поддерживается только новой версией routeros из-за того, что в мейнлайн добавили поддержку tilera в 2.6.36, а бэкпортить и потом еще саппортить - сложно.

да и о чем вообще говорить, если у них до сих пор есть разделение smp/non-smp версий ядра.

 

Зато установка из коробки и все работает. Не нужно ставить драйвера и т.п. Ставится за 5 минут. Вы сможете линукс за столь малое время установить?

вам рассказать, за какое время ставится vyatta?

вот nitr0 может рассказать про время инсталляции LEAF ))

[NiTr0]

Гиг по EoIP прокачает CCR с 36 ядрами.

С профилактическим ребутом каждые сутки? :)

 

Купите свою AS и адреса IPv4 за 3000 евро=) если найдете где они еще остались.

Уже есть 2 АС /22. Надо будет - еще докупим.

 

Более того, есть такие, которые заставляют руками их вписывать, и что-то оттока клиентов у них нет, держат по 10000 и более, хотя есть конкуренты с PPPoE и DHCP.

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

 

Тарифы же безлимитные. Ничего страшного.

Ничего страшного не считая того, что в сети несколько клиентов с одинаковыми адресами...

 

На микротике проще.

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

 

Зато установка из коробки и все работает. Не нужно ставить драйвера и т.п. Ставится за 5 минут. Вы сможете линукс за столь малое время установить?

LEAF разворачивается за минуту. Дебиан в минимальном инсталле - где-то минут 5 от силы (я у себя на флэш развернул за 2 минуты через debootstrap).

И да, не стоит о драйверах, в микротике если не работает i82599 - то не работает, сливай воду и выкидывай железку. В отличие от линя, где для свежей карты, о которой ядро еще не знает, при желании можно драйвер и собрать. Или ядро обновить. И свежие дрова в линь закидываются обычно из расчета получить прирост производительности/реализацию новой фичи.

И, что характерно, для МТ нет никакой инфы о том, поддерживается или не поддерживается карта. Вообще. Не считая полузаброшенной странички в вики, которую ведут...сами владельцы микротиков.

 

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

С тем же успехом биллинг может управлять чем угодно, хоть SOHO мыльницами через веб-интерфейс. Одна проблема - его под это надо затачивать очень шершавым напильником. Особенно это актуально для самописного биллинга (к которому рано или поздно оператор таки приходит).

RFC3576 - стандарт, которым управляется любое железо, от тазика до цисок. Микротиковский шелл для смены скорости - нестандартное, проприетарное, ни с чем не совместимое решение. Т.е. - костыль.

 

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

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

[snark]

Микротиковский шелл для смены скорости - нестандартное, проприетарное, ни с чем не совместимое решение.

 

nuclearcat как-то говорил о том, что API постоянно меняется, т.е. получается так что если что-то работало вчера - не факт что заработает завтра.

[Saab95]

Гиг по EoIP прокачает CCR с 36 ядрами.

С профилактическим ребутом каждые сутки? :)

 

Без ребута.

 

Купите свою AS и адреса IPv4 за 3000 евро=) если найдете где они еще остались.

Уже есть 2 АС /22. Надо будет - еще докупим.

 

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

 

Более того, есть такие, которые заставляют руками их вписывать, и что-то оттока клиентов у них нет, держат по 10000 и более, хотя есть конкуренты с PPPoE и DHCP.

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

 

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

 

Тарифы же безлимитные. Ничего страшного.

Ничего страшного не считая того, что в сети несколько клиентов с одинаковыми адресами...

 

Никаких одинаковых адресов нет и не будет.

 

На микротике проще.

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

 

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

 

Зато установка из коробки и все работает. Не нужно ставить драйвера и т.п. Ставится за 5 минут. Вы сможете линукс за столь малое время установить?

LEAF разворачивается за минуту. Дебиан в минимальном инсталле - где-то минут 5 от силы (я у себя на флэш развернул за 2 минуты через debootstrap).

И да, не стоит о драйверах, в микротике если не работает i82599 - то не работает, сливай воду и выкидывай железку. В отличие от линя, где для свежей карты, о которой ядро еще не знает, при желании можно драйвер и собрать. Или ядро обновить. И свежие дрова в линь закидываются обычно из расчета получить прирост производительности/реализацию новой фичи.

И, что характерно, для МТ нет никакой инфы о том, поддерживается или не поддерживается карта. Вообще. Не считая полузаброшенной странички в вики, которую ведут...сами владельцы микротиков.

 

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

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

С тем же успехом биллинг может управлять чем угодно, хоть SOHO мыльницами через веб-интерфейс. Одна проблема - его под это надо затачивать очень шершавым напильником. Особенно это актуально для самописного биллинга (к которому рано или поздно оператор таки приходит).

RFC3576 - стандарт, которым управляется любое железо, от тазика до цисок. Микротиковский шелл для смены скорости - нестандартное, проприетарное, ни с чем не совместимое решение. Т.е. - костыль.

 

А вы знаете софтроутеры которые полностью соответствуют RFC во всем?

 

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

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

 

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

[dr.Livci]

По ssh, как предложил тута дистрибьютор тика, по принципу "одна команда - один коннект"? Не верю.

Не по ссш - а по телнет. Телнет в разы быстрее по понятным причинам.

Если нужен безопасный конект между биллингом и МикроТиком - подымается постоянный шифрованный тунель любого типа - на постоянку один раз при старте системы.

Но обычно не нужно - серверы рядом напрямую подключены.

 

 

 

 

Или это так плохо с производительностью ROS?

 

Да - плохо.

Капитан очевидность повторяет - Тик проигрывает во многих случаях другим софтовым роутерам. И чо?

Но всем пофиг - свою нишу и дальше будет занимать - все не кинутся ща на LEAF Или Vyatta или не станут пилить свой дистр.

Разнообразие видов сохраняется.

 

Всем пока, продолжайте холиварить.....