kinord Опубликовано 17 февраля, 2014 · Жалоба Приветствую, коллеги. Подскажите каким образом лучше всего собрать несколько разных сетей. Имеется 7 роутеров ( удаленных микротиков), на которых сейчас происходит разруливание абонентов в интернет (DHCP, NAT, Firewall). Каждый из них подключен к своему каналу в интернет. Идея в том, что бы поставить еще один центральный микротик, на который будет заходить широкий канал от аплинка и туда пригнать все остальные сети. При этом присоединяющий оператор дает подсеть серых адресов /23 и предполагается на центральном микротике натить 1:1, что бы можно было видеть всех клиентов на СОРМе присоединяющего. Как мне свести в центр всех удаленных абонентов: какой лучше построить туннель, как завернуть туда абонов. Полагаю, что на удаленных микротиках ничего, кроме маршрутизации юзать больше будет не надо - все будет обеспечивать центральная железка? В этом случае можно ли будет оставить часть функций (DHCP например) на удаленных роутерах? Пока смутно вырисовывается схема в голове как это все будет выглядеть и как управляться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 17 февраля, 2014 · Жалоба IPIP туннель поверх Ipsec. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kinord Опубликовано 17 февраля, 2014 (изменено) · Жалоба IPIP туннель поверх Ipsec. Если честно строил туннели только для управления. Как себя в них чувствует клиентский трафик? Для каждой подсети кторую прокидываем нужно будет свой туннель поднимать? Если прокидываем 192.168.0.0/24 и 172.16.0.0/24 - надо будет два туннеля или один? Изменено 17 февраля, 2014 пользователем kinord Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 17 февраля, 2014 · Жалоба IPIP туннель поверх Ipsec. Если честно строил туннели только для управления. Как себя в них чувствует клиентский трафик? Для каждой подсети кторую прокидываем нужно будет свой туннель поднимать? Если прокидываем 192.168.0.0/24 и 172.16.0.0/24 - надо будет два туннеля или один? IPSec устаревшая технология вместе с устаревшим же IPIP туннелем. Настраивайте в центре L2TP сервер, удаленные подключаться, по OSPF разрулите маршруты и завернете весь трафик с нужных адресов в сторону вашего центрального провайдера, даже нат включать не понадобиться, если он вам кучу серых подсетей выделит, которых под всех абонентов хватит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kinord Опубликовано 18 февраля, 2014 (изменено) · Жалоба IPSec устаревшая технология вместе с устаревшим же IPIP туннелем. Настраивайте в центре L2TP сервер, удаленные подключаться, по OSPF разрулите маршруты и завернете весь трафик с нужных адресов в сторону вашего центрального провайдера, даже нат включать не понадобиться, если он вам кучу серых подсетей выделит, которых под всех абонентов хватит. Почуму не EoIP при белых адресах? Изменено 18 февраля, 2014 пользователем kinord Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Night_Snake Опубликовано 18 февраля, 2014 · Жалоба IPSec устаревшая технология вместе с устаревшим же IPIP туннелем. Халва, халва... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
g3fox Опубликовано 18 февраля, 2014 · Жалоба Я бы стал использовать то, что жрёт меньше всего ресурсов и даёт наименьший оверхед. Какой-либо ipip, gre. С L2TP удобнее выделять адреса для клиентов. На удалённых микротиках можете оставить всё тоже самое, что и сейчас. Только вместо текущих аплинков на на оператора у вас будет аплинк на самого себя. NAT, разумеется, нужно будет отключить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 18 февраля, 2014 · Жалоба 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 и т.п., потребуется вручную создавать правила=) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
g3fox Опубликовано 18 февраля, 2014 · Жалоба у L2TP оверхед несколько больше, так как это транспортный уровень. Есть и плюсы - лёгкое преодоление NAT. Но это никак не относится к вопросам ТС. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kinord Опубликовано 18 февраля, 2014 · Жалоба а какой применрный процеент оверхеда у разных подходов? у 100М полосы сколько отрежется на служебный? при организации ipip и им подобных получится оставить все хозяство с сетями убрав только нат и указав маршрут на головной микротик, где будет все натиться? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
g3fox Опубликовано 18 февраля, 2014 · Жалоба а какой применрный процеент оверхеда у разных подходов? у 100М полосы сколько отрежется на служебный? при организации ipip и им подобных получится оставить все хозяство с сетями убрав только нат и указав маршрут на головной микротик, где будет все натиться? В случае с IPIP и GRE к пакету добавляется непосредственно заголовок тоннельного протокола + новый заголовок IP. В случае L2TP плюсом добавляется ещё и заголовок транспортного уровня. В процентном соотношении от полосы сказать сложно. Такую статистику мало кто ведёт. Чем меньше размер пакетов, которые вы будете гонять через тоннель - тем больше будет оверхед. Если пакет после упаковки будет больше, чем MTU канала - произойдёт фрагментация, что тоже внесёт свой оверхед. Но от этого никуда не деться. Вообще можете не париться по поводу оверхедов и фрагментации. При использовании тоннелей, а как следствии каналов с разным MTU этого не избежать :) Так что оптимальным, наверное, будет L2TP. А чтобы не париться с маршрутами можно использовать какой-нибудь динамический протокол маршрутизации, например, OSPF. Я совсем недавно решал подобную задачу. Вот ссылка на параллельную ветку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kinord Опубликовано 18 февраля, 2014 · Жалоба а какой применрный процеент оверхеда у разных подходов? у 100М полосы сколько отрежется на служебный? при организации ipip и им подобных получится оставить все хозяство с сетями убрав только нат и указав маршрут на головной микротик, где будет все натиться? В случае с IPIP и GRE к пакету добавляется непосредственно заголовок тоннельного протокола + новый заголовок IP. В случае L2TP плюсом добавляется ещё и заголовок транспортного уровня. В процентном соотношении от полосы сказать сложно. Такую статистику мало кто ведёт. Чем меньше размер пакетов, которые вы будете гонять через тоннель - тем больше будет оверхед. Если пакет после упаковки будет больше, чем MTU канала - произойдёт фрагментация, что тоже внесёт свой оверхед. Но от этого никуда не деться. Вообще можете не париться по поводу оверхедов и фрагментации. При использовании тоннелей, а как следствии каналов с разным MTU этого не избежать :) Так что оптимальным, наверное, будет L2TP. А чтобы не париться с маршрутами можно использовать какой-нибудь динамический протокол маршрутизации, например, OSPF. Я совсем недавно решал подобную задачу. Вот ссылка на параллельную ветку. спасибо - обязательно почитаю, хотя динамическая маршрутизация в любом виде - темный лес для меня ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 18 февраля, 2014 · Жалоба а какой применрный процеент оверхеда у разных подходов? у 100М полосы сколько отрежется на служебный? В случае с IPIP и GRE к пакету добавляется непосредственно заголовок тоннельного протокола + новый заголовок IP. В случае L2TP плюсом добавляется ещё и заголовок транспортного уровня. В процентном соотношении от полосы сказать сложно. Такую статистику мало кто ведёт. Чем меньше размер пакетов, которые вы будете гонять через тоннель - тем больше будет оверхед. Если пакет после упаковки будет больше, чем MTU канала - произойдёт фрагментация, что тоже внесёт свой оверхед. Никакого оверхеда нет, пока размер пакета не превышает определенный предел, например 1460 байт, как только протокол начинает фрагментировать пакеты - он появляется. Следовательно, если часть данных передается маленькими пакетами, например телефония, то никакой разницы нет, в чистом виде она идет, или в туннеле. Тут только загрузка процессора увеличивается по сравнению с прямым подключением без всяких туннелей. Для примера можете провести тест на самом микротике - запустите тест скорости по UDP пакетами 1500 байт, увидите, что количество пакетов к туннеле удваивается, а от 100 мегабит канала теряется около 15-20 процентов, то есть остается около 80 чистыми. Стоит уменьшить размер пакета до 1400, как количество пакетов идет без увеличения, канал загружается без потерь на все 100 мегабит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
g3fox Опубликовано 19 февраля, 2014 · Жалоба Никакого оверхеда нет Схрена-ли?! Дополнительные заголовки - это уже оверхеад. В случае с мелкими пакетами оверхед не происходит фрагментация. Вам нужно передать 5ГБ данных через тоннель, который проходит через канал канал шириной в 100 мбит и MTU 1500. Так вот оверхед накладываемый тоннелем добавит к вашим 5ГБ данных ещё какой-то объём по вашей теории 15-20%. Разумеется, что 5ГБ+15-20% будет передаваться дольше через канал в 100мбит, чем 5ГБ. Как-то так... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 19 февраля, 2014 · Жалоба Схрена-ли?! Дополнительные заголовки - это уже оверхеад. В случае с мелкими пакетами оверхед не происходит фрагментация. Вам нужно передать 5ГБ данных через тоннель, который проходит через канал канал шириной в 100 мбит и MTU 1500. Так вот оверхед накладываемый тоннелем добавит к вашим 5ГБ данных ещё какой-то объём по вашей теории 15-20%. Разумеется, что 5ГБ+15-20% будет передаваться дольше через канал в 100мбит, чем 5ГБ. Как-то так... Служебной информации там мизер, смотрите картинку - передача полезная 10 мбит (пакеты 1400 байт), в туннеле 10.4, перегрузка всего 4 процента. Следовательно в канале 100 мегабит пропадет 4 мегабита, в гигабитном - 40. Естественно передача 1500 байт потеряет больше. На скрине так же видна работа OSPF, по каждому каналу передаются данные в одном направлении. Когда абоненты передают данные на разные адреса, то до них идут по разным тоннелям, что позволяет утилизировать оба канала. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
g3fox Опубликовано 19 февраля, 2014 · Жалоба Про 15-20% не я же сказл :) Но в любом случае, даже 4% тоже трафик. И это как раз тот самый оверхед, которого "нету". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 19 февраля, 2014 · Жалоба Атас. Сааб везде рекламирует технологию без какого-либо вменяемого подверждения её приемущества. Если прокидываем 192.168.0.0/24 и 172.16.0.0/24 - надо будет два туннеля или один? Да хоть 1000 сетей прокидывайте. Протоколу без особой разницы что передавать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
g3fox Опубликовано 19 февраля, 2014 · Жалоба Атас. Сааб везде рекламирует технологию без какого-либо вменяемого подверждения её приемущества. И иногда противоречит себе-же. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kinord Опубликовано 22 февраля, 2014 · Жалоба в общем поднял туннель между двумя микротиками. Как теперь статическим маршрутом завернуть в него трафик? Допустим на интерфейсе есть подсеть 172.16.0.0/24 и 192.168.0.0/24. Сейчас обе натятся и ходят в инет. Надо, что бы подсеть 172.16.0.0 ходила в инет через удаленный микротик Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
g3fox Опубликовано 22 февраля, 2014 · Жалоба Через тоннель трафик точно начал ходить? Создаёте дефолтный маршрут и указываете: в "gateway" ваш тоннельный интерфейс в "routing mark", например, "via_tun" Далее в маршрутах переходите на вкладку rules, и там создаёте правило: src address "172.16.0.0/24" и lookup "via_tun" Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kinord Опубликовано 22 февраля, 2014 (изменено) · Жалоба Через тоннель трафик точно начал ходить? Создаёте дефолтный маршрут и указываете: в "gateway" ваш тоннельный интерфейс в "routing mark", например, "via_tun" Далее в маршрутах переходите на вкладку rules, и там создаёте правило: src address "172.16.0.0/24" и lookup "via_tun" Вот, спасибо!!! Получилось!!! Помимо всего прочего на дальнем микротике еще не было маршрута на ближний микротик. Трафик бегает теперь через туннель. Начало положено - теперь буду читать OSPF Изменено 22 февраля, 2014 пользователем kinord Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 23 февраля, 2014 · Жалоба Трафик бегает теперь через туннель. Начало положено - теперь буду читать OSPF Читать про него не нужно, достаточно включить и забыть про проблемы с маршрутизацией. Для работы достаточно только прописать на устройствах (на портах, которыми соединены) адреса из одной подсети, устройства сразу установят связь по ним. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myst Опубликовано 24 февраля, 2014 · Жалоба Читать про него не нужно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
g3fox Опубликовано 24 февраля, 2014 · Жалоба Согласен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 24 февраля, 2014 (изменено) · Жалоба С точки зрения саабжа - все верно, при таком подходе "Саабы" всегда будут нужны. Изменено 24 февраля, 2014 пользователем pppoetest Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
