Jump to content
Калькуляторы

mikrotik собрать несколько сетей

Приветствую, коллеги.

 

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

Имеется 7 роутеров ( удаленных микротиков), на которых сейчас происходит разруливание абонентов в интернет (DHCP, NAT, Firewall). Каждый из них подключен к своему каналу в интернет. Идея в том, что бы поставить еще один центральный микротик, на который будет заходить широкий канал от аплинка и туда пригнать все остальные сети. При этом присоединяющий оператор дает подсеть серых адресов /23 и предполагается на центральном микротике натить 1:1, что бы можно было видеть всех клиентов на СОРМе присоединяющего. Как мне свести в центр всех удаленных абонентов: какой лучше построить туннель, как завернуть туда абонов. Полагаю, что на удаленных микротиках ничего, кроме маршрутизации юзать больше будет не надо - все будет обеспечивать центральная железка? В этом случае можно ли будет оставить часть функций (DHCP например) на удаленных роутерах? Пока смутно вырисовывается схема в голове как это все будет выглядеть и как управляться.

Share this post


Link to post
Share on other sites

IPIP туннель поверх Ipsec.

 

Если честно строил туннели только для управления. Как себя в них чувствует клиентский трафик?

Для каждой подсети кторую прокидываем нужно будет свой туннель поднимать?

Если прокидываем 192.168.0.0/24 и 172.16.0.0/24 - надо будет два туннеля или один?

Edited by kinord

Share this post


Link to post
Share on other sites

IPIP туннель поверх Ipsec.

 

Если честно строил туннели только для управления. Как себя в них чувствует клиентский трафик?

Для каждой подсети кторую прокидываем нужно будет свой туннель поднимать?

Если прокидываем 192.168.0.0/24 и 172.16.0.0/24 - надо будет два туннеля или один?

 

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

Share this post


Link to post
Share on other sites

 

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

 

Почуму не EoIP при белых адресах?

Edited by kinord

Share this post


Link to post
Share on other sites

IPSec устаревшая технология вместе с устаревшим же IPIP туннелем.

Халва, халва...

Share this post


Link to post
Share on other sites

Я бы стал использовать то, что жрёт меньше всего ресурсов и даёт наименьший оверхед. Какой-либо ipip, gre.

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

Share this post


Link to post
Share on other sites

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

 

Почуму не EoIP при белых адресах?

 

EoIP разбивает большой пакет 1500 байт на 2 - размером 1500 + довесок. Если очередность пакетов будет нарушена - пойдут потери данных и канал начнет постоянно отваливаться. При необходимости использования таких туннелей, их поверх L2TP запускают. Так же EoIP требуется указание IP адресов и номера туннеля с обоих сторон линка.

 

Я бы стал использовать то, что жрёт меньше всего ресурсов и даёт наименьший оверхед. Какой-либо ipip, gre.

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

 

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

 

Со всякими там IP-IP и прочими туннелями, которые требуют указания обоих адресов, требуется намного больше времени на администрирование, а во время проблем с МТУ со стороны операторов, не сможете оперативно вернуть работоспособность. С L2TP можно в центре МТУ уменьшить и все заработает. Аналогично и с пингами 1500 байт без фрагментации. У L2TP есть параметр MRRU, а у всяких других IPIP, GRE и т.п., потребуется вручную создавать правила=)

Share this post


Link to post
Share on other sites

у L2TP оверхед несколько больше, так как это транспортный уровень. Есть и плюсы - лёгкое преодоление NAT.

Но это никак не относится к вопросам ТС.

Share this post


Link to post
Share on other sites

а какой применрный процеент оверхеда у разных подходов? у 100М полосы сколько отрежется на служебный?

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

Share this post


Link to post
Share on other sites

а какой применрный процеент оверхеда у разных подходов? у 100М полосы сколько отрежется на служебный?

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

В случае с IPIP и GRE к пакету добавляется непосредственно заголовок тоннельного протокола + новый заголовок IP. В случае L2TP плюсом добавляется ещё и заголовок транспортного уровня.

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

Но от этого никуда не деться.

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

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

Я совсем недавно решал подобную задачу. Вот ссылка на параллельную ветку.

Share this post


Link to post
Share on other sites

а какой применрный процеент оверхеда у разных подходов? у 100М полосы сколько отрежется на служебный?

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

В случае с IPIP и GRE к пакету добавляется непосредственно заголовок тоннельного протокола + новый заголовок IP. В случае L2TP плюсом добавляется ещё и заголовок транспортного уровня.

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

Но от этого никуда не деться.

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

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

Я совсем недавно решал подобную задачу. Вот ссылка на параллельную ветку.

 

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

Share this post


Link to post
Share on other sites

а какой применрный процеент оверхеда у разных подходов? у 100М полосы сколько отрежется на служебный?

В случае с IPIP и GRE к пакету добавляется непосредственно заголовок тоннельного протокола + новый заголовок IP. В случае L2TP плюсом добавляется ещё и заголовок транспортного уровня.

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

 

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

 

Для примера можете провести тест на самом микротике - запустите тест скорости по UDP пакетами 1500 байт, увидите, что количество пакетов к туннеле удваивается, а от 100 мегабит канала теряется около 15-20 процентов, то есть остается около 80 чистыми. Стоит уменьшить размер пакета до 1400, как количество пакетов идет без увеличения, канал загружается без потерь на все 100 мегабит.

Share this post


Link to post
Share on other sites

Никакого оверхеда нет

 

Схрена-ли?! Дополнительные заголовки - это уже оверхеад.

В случае с мелкими пакетами оверхед не происходит фрагментация.

Вам нужно передать 5ГБ данных через тоннель, который проходит через канал канал шириной в 100 мбит и MTU 1500.

Так вот оверхед накладываемый тоннелем добавит к вашим 5ГБ данных ещё какой-то объём по вашей теории 15-20%.

Разумеется, что 5ГБ+15-20% будет передаваться дольше через канал в 100мбит, чем 5ГБ.

Как-то так...

Share this post


Link to post
Share on other sites

Схрена-ли?! Дополнительные заголовки - это уже оверхеад.

В случае с мелкими пакетами оверхед не происходит фрагментация.

Вам нужно передать 5ГБ данных через тоннель, который проходит через канал канал шириной в 100 мбит и MTU 1500.

Так вот оверхед накладываемый тоннелем добавит к вашим 5ГБ данных ещё какой-то объём по вашей теории 15-20%.

Разумеется, что 5ГБ+15-20% будет передаваться дольше через канал в 100мбит, чем 5ГБ.

Как-то так...

 

Служебной информации там мизер, смотрите картинку - передача полезная 10 мбит (пакеты 1400 байт), в туннеле 10.4, перегрузка всего 4 процента. Следовательно в канале 100 мегабит пропадет 4 мегабита, в гигабитном - 40. Естественно передача 1500 байт потеряет больше.

 

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

 

l2tp-mikrotik.png

Share this post


Link to post
Share on other sites

Про 15-20% не я же сказл :)

Но в любом случае, даже 4% тоже трафик. И это как раз тот самый оверхед, которого "нету".

Share this post


Link to post
Share on other sites

Атас. Сааб везде рекламирует технологию без какого-либо вменяемого подверждения её приемущества.

 

Если прокидываем 192.168.0.0/24 и 172.16.0.0/24 - надо будет два туннеля или один?

Да хоть 1000 сетей прокидывайте. Протоколу без особой разницы что передавать.

Share this post


Link to post
Share on other sites

Атас. Сааб везде рекламирует технологию без какого-либо вменяемого подверждения её приемущества.

И иногда противоречит себе-же.

Share this post


Link to post
Share on other sites

в общем поднял туннель между двумя микротиками. Как теперь статическим маршрутом завернуть в него трафик? Допустим на интерфейсе есть подсеть 172.16.0.0/24 и 192.168.0.0/24.

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

Share this post


Link to post
Share on other sites

Через тоннель трафик точно начал ходить?

Создаёте дефолтный маршрут и указываете:

в "gateway" ваш тоннельный интерфейс

в "routing mark", например, "via_tun"

Далее в маршрутах переходите на вкладку rules, и там создаёте правило:

src address "172.16.0.0/24" и lookup "via_tun"

Share this post


Link to post
Share on other sites

Через тоннель трафик точно начал ходить?

Создаёте дефолтный маршрут и указываете:

в "gateway" ваш тоннельный интерфейс

в "routing mark", например, "via_tun"

Далее в маршрутах переходите на вкладку rules, и там создаёте правило:

src address "172.16.0.0/24" и lookup "via_tun"

 

Вот, спасибо!!! Получилось!!!

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

Трафик бегает теперь через туннель. Начало положено - теперь буду читать OSPF

Edited by kinord

Share this post


Link to post
Share on other sites

Трафик бегает теперь через туннель. Начало положено - теперь буду читать OSPF

 

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

Share this post


Link to post
Share on other sites

С точки зрения саабжа - все верно, при таком подходе "Саабы" всегда будут нужны.

Edited by pppoetest

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this