[Butch3r]

Поясните пожалуйста что в вашем понимании нормальный роутер?

Я бы посмотрел на какую-нибудь БУ циску

[tonny_bennet]

На такие объёмы трафика - тазик с *nix. Дёшево, сердито, из серии поставил, настроил, слил настроенный образ в бекап и забыл.

 

Спасибо. От тазиков в таких задачах я решил отказываться.

 

Зато GRE туннель требует указания 2-х пар IP адресов, и в случае изменения со стороны дальнего устройства, перенастройку. Шифровать никакие пакеты не следует.

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

 

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

 

У меня сейчас четыре филиала, и у некоторых уже по несколько внешних каналов. Соответсвенно между двумя филиалами у меня четыре тунеля: isp1 - isp1, isp2 - isp2, isp1 - isp2, isp2 - isp1. При падении любого из интерфейсов у любого из провайдеров OSPF перестраивается быстро и ничего не отваливается т.к. все соединения уже есть. Я не параноик но в IpSec можно тончайшими нитями настраивать шифрование, хотя по-моему L2TP тоже профили IpSec использует.

 

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

 

 

 

Я просто думаю, если МТ может утилизировать 2 Гбит/с трафика через 2 порта средствами всего лишь маршрутизации (+/- тегирование VLAN), то может я как-нибудь просто выключу все правила. Выключу IpSec и прочее и просто проверю. Он по идее должен разогнаться? Или всё-таки не в этом дело?

[sexst]

Вы только учитывайте еще что порты 1-5 и 6-10 это фактически два свитча с гиговыми линками до процессора. Со всеми вытекающими.

[tonny_bennet]

2 ТС - а микрика этого прикол с портами )) не советую делать бондинг. Посмотрите на потери по портам - это нормальный режим для него.. там есть только один или два порта нормально работающих при трафике в 100+ мегабит

 

Посмотрел на порты, кторые в агрегации - вроде всё нормально. Потерь или ошибок на интерфейсе нет. Я где-то встречал что у RB есть разные порты, но там не так страшно что один отдаёт гигабит, а другой делает вид что отдаёт гигабит а сам отдаёт только 300 мбит/с.

[tonny_bennet]

Вы только учитывайте еще что порты 1-5 и 6-10 это фактически два свитча с гиговыми линками до процессора. Со всеми вытекающими.

 

Спасибо за уточнение. В этом видимо и кроется прична моей проблемы. В итоге тонкое место между свитчем и процессором. Посмотрел на диаграмму и прозрел.

 

Скажите пожалуйста, 11 и 12 порты указаны как bypass group. С отдельным каналом до процессора в 1Gbit/s. В сети нет чёткого определения что это такое и для чего нужно. Может у форумчан будут догадки?

[Saab95]

Я просто думаю, если МТ может утилизировать 2 Гбит/с трафика через 2 порта средствами всего лишь маршрутизации (+/- тегирование VLAN), то может я как-нибудь просто выключу все правила. Выключу IpSec и прочее и просто проверю. Он по идее должен разогнаться? Или всё-таки не в этом дело?

 

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

 

У меня сейчас четыре филиала, и у некоторых уже по несколько внешних каналов. Соответсвенно между двумя филиалами у меня четыре тунеля: isp1 - isp1, isp2 - isp2, isp1 - isp2, isp2 - isp1. При падении любого из интерфейсов у любого из провайдеров OSPF перестраивается быстро и ничего не отваливается т.к. все соединения уже есть. Я не параноик но в IpSec можно тончайшими нитями настраивать шифрование, хотя по-моему L2TP тоже профили IpSec использует.

 

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

[zhenya`]

Дмвпн с двумя хабами.

[sexst]

Bypass значит что есть тумблер, который их физически соединяет. Там натурально реле стоит. Гигабиты там честные, насколько оно к микротику применимо вообще.

Но лучше для тупого локального роутинга L3 коммутатор использовать и забыть про подобные проблемы как класс. Ну или хотя бы бюджетно какой-нибудь edgerouter от ubnt. Там хоть какой-то hw offload есть и такие вещи тоже на скорости порта работают.

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

[Saab95]

Но лучше для тупого локального роутинга L3 коммутатор использовать и забыть про подобные проблемы как класс. Ну или хотя бы бюджетно какой-нибудь edgerouter от ubnt. Там хоть какой-то hw offload есть и такие вещи тоже на скорости порта работают.

 

То есть вы хотите сказать что микротик RB1100 в чистом роутинге с включенным Fast Path не в состоянии прокачать 2 гигабита трафика? А какой-то роутер от убнт за 100 баксов это сделать в состоянии?

Я всегда пишу - делайте правильную схему сети, если у вас есть НАТ, его следует делать на отдельном микротике, нужен шейпер - тоже на отдельном, далее идет центральный маршрутизатор, в который подключаете агрегацию от абонентов или PPPoE терминаторы. В таком случае внутрисетевой трафик пойдет на скорости порта до основного, загруженного работой оборудования. Когда же пытаются решить все действия на одном микротике, включив НАТ, шейпер и т.п., то его производительность уменьшается как минимум в 2 раза, а при некоторых настройках и в 10 раз.

[sexst]

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

И покупать роутер чтобы включить на нем fastpath и получить недоl3 свитч это просто конгениально.

Зы: Ну вот и опять "нужно просто больше микротиков". Хотя купить l3 свитч по факту дешевле и практичнее.

[alibek]

А какой-то роутер от убнт за 100 баксов это сделать в состоянии?

Действительно, как же так.

 

Хотя купить l3 свитч по факту дешевле и практичнее.

Для продавца это минус. А "продать больше микротиков" — плюс.

[tonny_bennet]

Нужно выделить одну точку в качестве центральной и уже к ней подключать все офисы,

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

 

в каждом офисе при появлении дополнительного канала требуется ставить дополнительный микротик.

А почему нельзя в один маршрутизатор подключит сразу несколько каналов? Вопрос только в отказоустойчивости роутера?

 

Дмвпн с двумя хабами.

DMVPN (англ. Dynamic Multipoint Virtual Private Network — динамическая многоточечная виртуальная частная сеть) — технология для создания виртуальных частных сетей, разработанная Cisco Systems.

 

Bypass значит что есть тумблер, который их физически соединяет. Там натурально реле стоит. Гигабиты там честные, насколько оно к микротику применимо вообще.

Хм... не могу представить ситуации, в которой это может понадобиться.

 

Я всегда пишу - делайте правильную схему сети, если у вас есть НАТ, его следует делать на отдельном микротике, нужен шейпер - тоже на отдельном, далее идет центральный маршрутизатор, в который подключаете агрегацию от абонентов или PPPoE терминаторы. В таком случае внутрисетевой трафик пойдет на скорости порта до основного, загруженного работой оборудования. Когда же пытаются решить все действия на одном микротике, включив НАТ, шейпер и т.п., то его производительность уменьшается как минимум в 2 раза, а при некоторых настройках и в 10 раз.

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

[Saab95]

Зы: Ну вот и опять "нужно просто больше микротиков". Хотя купить l3 свитч по факту дешевле и практичнее.

 

А что, L3 свичи теперь научились нормально работать с OSPF?

[alibek]

А что, L3 свичи теперь научились нормально работать с OSPF?

Для простых случаев (OSPF между филиалами) — давно.

[Saab95]

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

 

Так и должно быть - можно все контролировать из центра. Когда у вас будет 100 офисов, вы сделаете 10000 туннелей между ними?

 

А почему нельзя в один маршрутизатор подключит сразу несколько каналов? Вопрос только в отказоустойчивости роутера?

 

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

 

Хм... не могу представить ситуации, в которой это может понадобиться.

 

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

 

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

 

Вообще межабонентский трафик, если он есть, должен оставаться на транспортной сети, а не попадать в центр.

[tonny_bennet]

Так и должно быть - можно все контролировать из центра. Когда у вас будет 100 офисов, вы сделаете 10000 туннелей между ними?

 

Тут вопрос уже расходования ресурсов. Если будет 100 офисов я наверное перееду на Cisco и DMVPN или подобные Full Mesh VPN-решения.

А так если мы гоним трафик в 10 мбит/с из офиса1 в офис2 через центральный офис, то получается что канал центрального офиса загружен на 20 мбит/с (10 туда и 10 обратно). А при наличии канала между офисом1 офисом2 мы экономим пропускную способность внешнего канала центального офиса. Дешевле поднять один туннель нежели увеличить расходы на канал в центральном офисе.

 

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

У меня в нескольких офисах по два канала. Это два лишних правила в таблице маршрутизации. Два правила в правилах маршрутизации. Шесть правил в таблице mangle. - это всё настраивается 1 раз.

Если хочу кого-то выпустить в сеть через определённый канал +1 правило в mangle.

 

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

 

P.S.

на одном узле

межабонентский трафик

подключаете агрегацию от абонентов

 

Вы работаете у провайдера?

[sexst]

Зы: Ну вот и опять "нужно просто больше микротиков". Хотя купить l3 свитч по факту дешевле и практичнее.

 

А что, L3 свичи теперь научились нормально работать с OSPF?

Я большего количества факапов с OSPF чем у микротика ни с одним вендором больше не хватал.

И не забывайте что нормальный L3 свитч помимо быстрого перекладывания пакетов обычно умеет еще и ACL, QoS, storm control, отделение data plane от control plane и прочий ненужный и странный хлам.

[sexst]

Хм... не могу представить ситуации, в которой это может понадобиться.

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

В любом случае для роутера вещь странная, я еще понимаю когда DPI так может.

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

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

[s.lobanov]

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

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

 

Лет 7 назад - да, сейчас же локального трафика в ISP настолько мало, что проще его молотить тем же сервером, что и всё остальное.

[alibek]

ТС, насколько я понял, не ISP, а энтерпрайз.

А там внутреннего трафика в разы больше, чем внешнего.

[sexst]

Лет 7 назад - да, сейчас же локального трафика в ISP настолько мало, что проще его молотить тем же сервером, что и всё остальное.

Я что-то написал про ISP? Да и даже в ISP нередко еще имеет смысл.

[SyJet]

ТС, насколько я понял, не ISP, а энтерпрайз.

А там внутреннего трафика в разы больше, чем внешнего.

Подверждаю. Был гиг, потом ласп, дам 10ку и её утилизировуют. Хотя внешку и 50мбит не берут.

[Sonne]

Топик стартеру.

 

RB1100AHx2 примерно 350 Мбит и тянет с типичным набором фич.

 

Разделите бордер ( NAT, shaper, низко скоростные аплинки) и локальный свичинг. Последнее лучше всё же делать на коммутатора, тем более он у вас уже есть.

 

Если религия не позволяет, то поставьте Cloud Core и даже в вашей довольно странной конфигурации будете иметь гиг локального трафика.

[Saab95]

Тут вопрос уже расходования ресурсов. Если будет 100 офисов я наверное перееду на Cisco и DMVPN или подобные Full Mesh VPN-решения.

А так если мы гоним трафик в 10 мбит/с из офиса1 в офис2 через центральный офис, то получается что канал центрального офиса загружен на 20 мбит/с (10 туда и 10 обратно). А при наличии канала между офисом1 офисом2 мы экономим пропускную способность внешнего канала центального офиса. Дешевле поднять один туннель нежели увеличить расходы на канал в центральном офисе.

 

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

 

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

 

У меня в нескольких офисах по два канала. Это два лишних правила в таблице маршрутизации. Два правила в правилах маршрутизации. Шесть правил в таблице mangle. - это всё настраивается 1 раз.

Если хочу кого-то выпустить в сеть через определённый канал +1 правило в mangle.

 

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

 

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

 

То есть ваш бюджет не позволяет купить еще одну железку за 100 баксов?

 

Вы работаете у провайдера?

 

Я сам провайдер.

 

ТС, насколько я понял, не ISP, а энтерпрайз.

А там внутреннего трафика в разы больше, чем внешнего.

 

У нас были заказы от энтерпрайзов на такие сети, обычно первым пунктом идет ограничение доступа между офисами, поэтому внутреннего трафика, как такового, нет, все идет в центр и из центра.

 

Я большего количества факапов с OSPF чем у микротика ни с одним вендором больше не хватал.

 

Не видел проблем с OSPF у микротика. Все проблемы от не верной настройки.

 

И не забывайте что нормальный L3 свитч помимо быстрого перекладывания пакетов обычно умеет еще и ACL, QoS, storm control, отделение data plane от control plane и прочий ненужный и странный хлам.

 

Вы написали такие функции, которые, обычно, никому не требуются. Это как говорить что вон используйте коммутаторы они на скорости порта коммутируют. А если нужна скорость всего мегабит 200-300 с 24 абонентов, можно же и CRS поставить, сделав L3 доступ. Хотя он играючи и с 1-2 гига трафика справляется.

[sexst]

И не забывайте что нормальный L3 свитч помимо быстрого перекладывания пакетов обычно умеет еще и ACL, QoS, storm control, отделение data plane от control plane и прочий ненужный и странный хлам.

 

Вы написали такие функции, которые, обычно, никому не требуются. Это как говорить что вон используйте коммутаторы они на скорости порта коммутируют. А если нужна скорость всего мегабит 200-300 с 24 абонентов, можно же и CRS поставить, сделав L3 доступ. Хотя он играючи и с 1-2 гига трафика справляется.

 

 

Странный и ненужный, написал же. И вланы в топку.

 

Не видел проблем с OSPF у микротика. Все проблемы от не верной настройки.

 

Да, согласен. Все от неверной настройки. В жепу драфты по ospf. Heil Mikrotik!!!

 

RB1100AHx2 примерно 350 Мбит и тянет с типичным набором фич.

 

Sonne дело написал. И Cloud Router реально тянет достаточно много. Правда стоит с нынешним курсом прилично + наш микротикоадмин за последний год ловил четыре факапа с итогом в виде замены на рабочий и восстановлением сдохшего. Ну и стоит помнить что один поток походу упирается в одно ядро,а ядра, увы, не фонтан и берут числом.