Подскажите, как красиво настроить маршрутизацию

[grifin.ru]

Есть микротик роутер, подключен к "интернету" по PPPOE. Шлюз по умолчанию смотрит сюда.

потом поднял L2TP туннель на серых IP с удаленным маршрутизатором

В этом туннеле установлена BGP сессия, при помощи которой микротик анонсит всоою подсеть в мир

 

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

отключить дефолтный маршрут на PPPOE - нельзя, т.к. тогда L2TP не поднимется (не найдет сервер).

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

Наверное как-то анализировать SOURCE И на основе него решать куда роутить (если SOURCE Из анонсируемой по BGP сети, то слать в туннель, если нет, то слать мимо.

Но я, во-первых не нашел где это сделать, а во-вторых мне это решение тоже не очень нравится.

Наверняка есть красивое решение, прошу подсказать.

[GrandPr1de]

ну насколько я понимаю можно только через PBR в таком раскладе

а PBR как все мы знаем ровно противоположно слову "красиво"

поэтому статик роут /32 маской в сторону PPPoE шлюза до L2TP сервера и дефолт в ваш L2TP тунель

поидее так должно быть

 

вообще у вас тут "красиво" априори не будет

вы принимаете интернет по PPPoE, суете анонсы BGP в L2TP тунель... даже звучит так себе))

хз как вас жизнь на такое натолкнула

Edited November 20, 2016 by GrandPr1de

[sol]

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

А не надо убирать дефолт. Надо его не трогать и прописать дополнительно маршрут к серверу. Он будет более специфичным, чем дефолт. И выцепит из общей массы трафик для сервера.

 

В этом туннеле установлена BGP сессия, при помощи которой микротик анонсит всоою подсеть в мир

Что микротик анонсит свою сеть, это понятно. Вопрос в другом: для чего он это делает? Что такое "мир" и что "мир" отдаёт микроту?

[SUrov_IBM]

Grifin.ru, доброго Вам времени суток.

 

Как мне ведется, Вы уже сами сделали максимально красивый вариант - «Можно, конечно,

убрать дефолт и прописать руками маршрут до L2TP сервера».

 

Можно придумать несколько вариантов:

 

1. Если Mikrotik поддерживает VRF (Virtual Routing and Forwarding в терминологии CISCO,

с Mikrotik я просто не знаком, к сожалению), то перенести BGP процесс внутрь отдельной VRF таблицы.

Оставив NAT, PPPoE и L2TP клиенты в «основной» таблице. Но при этом, придётся настроить несколько

дополнительных статических маршрутов между «основной» и «виртуальной» (VRF) таблицами и если используется

eBGP,то скорей всего потребуется multihop при связи с сервером (из-за увеличения количества переходов через

статические маршруты).

 

2. Поставить два маршрутизатора Mikrotik друг за другом. На первом оставить PPPoE клиента и NAT, на втором

L2TP клиента и BGP. Но этот вариант какой-то уж слишком "Saab’овский" (кто в теме форума, тот поймёт). :)

 

3. Использовать вместо Mikrotik - CISCO с VRF, убедившись, что её производительности хватит под Ваши задачи

(у меня, например Cisco 881 справляется с 50 Мб/Сек., при похожей схеме, описанной в п.1.).

 

4. Использовать вместо Mikrotik - сервер с ОС FreeBSD или Linux, позволяющий сделать аналог VRF за счёт

виртуализации (например FreeBSD Jail).

[grifin.ru]

вы принимаете интернет по PPPoE, суете анонсы BGP в L2TP тунель... даже звучит так себе))

хз как вас жизнь на такое натолкнула

Вот примерно такая-же ситуация:

http://forum.nag.ru/forum/index.php?showtopic=106141&st=0

 

только у меня будет 2 "ЦОДа" с BGP сессиями и два линка в инетрнет из "ядра системы". И необходимо обеспечить отказоустойчивость проброса реальных IP в "ядро системы".

Задача усложняется еще и тем, что часть из получаемых по BGP адресов нужно оставить в ЦОДе, и только /27 передать в "ядро".

[grifin.ru]

А не надо убирать дефолт. Надо его не трогать и прописать дополнительно маршрут к серверу. Он будет более специфичным, чем дефолт. И выцепит из общей массы трафик для сервера.

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

Я вот думаю может мне там использовать какой-то OSPF или еще какой умный протокольчик нужно. Но вообще заменит BGP на OSPF не получается. Ситуация такая:

Есть ЦОД1 и ЦОД2 с возможностями BGP, есть своя /23, есть точка "TARGET" куда нужно прокинуть немножко реальничков. В этой точке есть два "интернета", но нет возможности BGP.

 

В каждом ЦОДе анонсится своя /24 (половина от /23).

Была идея сделать IBGP (через туннели) между ЦОД1, ЦОД2 и Target. Сделать так,чтоб:

В TARGET было две /27 (от каждой из /24)

Про пропадании связанности любого из ЦОДов с внешним миром (Упал аплинк)

или при падение любого из ребер треугольника

обе /27 на таргете все-равно присутсвовали-бы.

Вот.

[sol]

Дефолт убирать надо, т.к. он пуляет все пакеты на улицу

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

От этого и был мой вопрос: Что микротик анонсит свою сеть, это понятно. Вопрос в другом: для чего он это делает? Что такое "мир" и что "мир" отдаёт микроту?

 

В каждом ЦОДе анонсится своя /24 (половина от /23).

Была идея сделать IBGP (через туннели) между ЦОД1, ЦОД2 и Target. Сделать так,чтоб:

В TARGET было две /27 (от каждой из /24)

Про пропадании связанности любого из ЦОДов с внешним миром (Упал аплинк)

или при падение любого из ребер треугольника

обе /27 на таргете все-равно присутсвовали-бы.

 

Своего сына?!? Какое извращение! (цэ) кинофильм Догма.

 

1. Анонсить в обоих ЦОДах (разным аплинкам, я надеюсь?) надо всю /23. Делить её на две половинки смысла нет.

2. Между этими роутерами в датацентрах обязательно нужен iBGP линк. Причина: Миръ ничего не знает о вашей внутренней структуре и будет присылать пакеты тому бордеру, которому удобно слать в текущей ситуации. Это, с вероятностью 1/2 будет не тот бордер, какой надо. И этот бордер должен ДОСЛАТЬ пакетики нужному. Такая же ситуация и с исходящим трафиком. Внутренность вашей сети ничего не знает о структуре Мира. Там нет FW. И, соответственно, будет слать пакеты тому бордеру, которому удобнее слать в текущей ситуации, а не тому, с которого пункт назначения ближе. С вероятностью 1/2 это окажется не тот бордер. И бордер должен будет ДОСЛАТЬ пакет своему соседу. Для этого нужен или прямой канал между бордерами (почему бы не попросить у кого нибудь VLAN?) или тоннель. Поднять тоннель желательно способом Сааба. Т.е. на отдельных микротах, просто сбриджевав EoIP с физическим интерфейсом. Причина - резкое упрощение конфигурации и сужение поля для ошибок. Но, можно и на этих же бордерах. Причин не взлететь я не вижу.

3. Итак, мы имеем отказоустойчивый анонс нашей АС в Миръ. Что бы не упало, анонс в Миръ уйдёт. Правда, возможны чЮдеса из за нестабильной работы тоннеля, но, это издержки. Не хотите - стройте VLAN. Или два, через разных операторов.

4. Далее непонятно. Если вы хотите на target пригнать ваш интернет, то default там не нужен. Там нужны два статических маршрута до серверов тоннелей и любой протокол динамической маршрутизации. Хоть BGP, хоть OSPF. Нужен для анонса в сеть маршрутов к прогоняемым IP и получения двух дефолтов от обоих тоннелей. При этом, при одиночном падении чего угодно связность остаётся. Если вы хотите пригнать на target И ваши IP И оставить там локальный интернет, то опять послушайте совета Сааба и поставте ДВА микротика. На одном тоннели, на другом вся маршрутизация.

[grifin.ru]

1. Анонсить в обоих ЦОДах (разным аплинкам, я надеюсь?) надо всю /23. Делить её на две половинки смысла нет.

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

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

Между этими роутерами в датацентрах обязательно нужен iBGP линк.

Ясен пень.

С вероятностью 1/2 это окажется не тот бордер. И бордер должен будет ДОСЛАТЬ пакет своему соседу. Для этого нужен или прямой канал между бордерами (почему бы не попросить у кого нибудь VLAN?) или тоннель.

См. пункт 1. Именно поэтому не /23 а два раза по /24

Поднять тоннель желательно способом Сааба. Т.е. на отдельных микротах, просто сбриджевав EoIP с физическим интерфейсом.

Ну вот еще, оверхеда L2 мне тут только нехватало )

 

Если вы хотите пригнать на target И ваши IP И оставить там локальный интернет,

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

Идея двух микротиков мне примерно понятна. Ноя не верю что это нельзя все сделать красиво на одном. )

 

разным аплинкам, я надеюсь?

В одном ЦОДе 2 апилика, в другом один. Естественно они разные все. ЦОДы географически разнесены.

 

Кстати, еще вопрос. А как мне зарезервировать сами микротики ? Сейчас получается что узким местом является микротик (либо один либо два) если с одним из них что-то случается, то все умирает моментально.

[sol]

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

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

 

Т.е. вы хотите анонсировать more specific и не анонсировать сам маршрут?!? Хм, ну, удачи в этом начинании....

 

Ну вот еще, оверхеда L2 мне тут только нехватало )

Эээ, о чём это вы?

 

Нет смысла гонять этот трафик через туннели.

Почему?

 

А как мне зарезервировать сами микротики ? Сейчас получается что узким местом является микротик (либо один либо два) если с одним из них что-то случается, то все умирает моментально.

 

Мда. Строить сеть из говна, палок и тоннелей и думать о резервировании микротика... Настройте основной, потом склонируйте настройки в запасной. Наклейте на запасной инструкцию по замене и положите его на объекте не полочку. И назначте ответственного.

[grifin.ru]

Т.е. вы хотите анонсировать more specific и не анонсировать сам маршрут?!? Хм, ну, удачи в этом начинании....

По-русски можно ? )

Цитата

Ну вот еще, оверхеда L2 мне тут только нехватало )

Эээ, о чём это вы?

О том, что делать L2 Туннель без острой на то необходимости - дурной тон.

Цитата

Нет смысла гонять этот трафик через туннели.

Почему?

 

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

 

Мда. Строить сеть из говна, палок и тоннелей и думать о резервировании микротика... Настройте основной, потом склонируйте настройки в запасной. Наклейте на запасной инструкцию по замене и положите его на объекте не полочку. И назначте ответственного.

Речь идет о создании HA решения. Не думаю что одна кошка будет наденее двух микротиков. Вопрос как их зарезервировать. Естественно речь идет о горячем резерве, а не о ЗИПе.

Я что-то про кластер микротиков слышал.

[grifin.ru]

В общем давайте упростим вопрос.

Как сделать на одном микротике, чтоб на части портов у него был "интернет через PPPOE" (Ну через НАТ например, на фейковых IP

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

Сейчас вопрос не про настройку портов, а про настройку маршрутизации. Мне видится решение в виде использования разных таблиц маршрутизации для пакетов от разных источников. Те пакеты, у которых SOURCE равен адресу полученному по PPPOE должны маршрутизироваться в PPPOE интерфейс (в локальный интернет).

Те же, где SOURC Из моей прокинутой по BGP подсети - должны идти в L2TP туннель (на iBGP соседа)

Как организовать такое на одном устройстве ?

[SUrov_IBM]

 

Если вы хотите пригнать на target И ваши IP И оставить там локальный интернет,

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

Grifin.ru,

 

В функционале CISCO например имеется интересный механизм - Policy-based Routing (PBR), позволяющий

принудительно перенаправить IP пакеты (основываясь на адрес «источника» (source)) по заданному маршруту,

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

запустить iBGP процесс внутри отдельной таблицы VRF (в ней будет выполняться BGP маршрутизация), а средствами

PBR перенаправить IP пакеты сети /27 во «внутрь» этой VRF. Т.е. «белые» IP адреса из Вашей сети, будут уходить

в сторону iBGP (минуя маршрут 0.0.0.0/0 в главной таблице), а далее в ЦОД, весь остальной трафик, на Default Rout

провайдера.

 

P.S. Но к сожалению не знаю, как реализовать данную схему средствами Mikrotik, поскольку работал только с CISCO и "тазиками".

[grifin.ru]

SUrov_IBM

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

[nkusnetsov]

Есть микротик роутер, подключен к "интернету" по PPPOE. Шлюз по умолчанию смотрит сюда.

потом поднял L2TP туннель на серых IP с удаленным маршрутизатором

В этом туннеле установлена BGP сессия, при помощи которой микротик анонсит всоою подсеть в мир

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

У вас с провайдером, к которому подключены по PPPoE eBGP поднят? Он про вашу подсеть за PPPoE-клиентом знает или исходящее на PPPoE тупо NATится?

Если у вас белая /23 или /24 за микротиком - ответы идущие с белых IP не важно по какому пути должны пропускаться прозрачно в мир. Но, если провайдер PPPoE не знает, что за клиентским подключением есть валидная "белая" сеть - он может резать трафик как спуф.

 

Сейчас вопрос не про настройку портов, а про настройку маршрутизации. Мне видится решение в виде использования разных таблиц маршрутизации для пакетов от разных источников. Те пакеты, у которых SOURCE равен адресу полученному по PPPOE должны маршрутизироваться в PPPOE интерфейс (в локальный интернет).

Те же, где SOURC Из моей прокинутой по BGP подсети - должны идти в L2TP туннель (на iBGP соседа)

Как организовать такое на одном устройстве ?

...

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

Если включен connection-tracker, то лучше сначала маркировать соединение, а затем пакеты принадлежащие к этому соединению.

Маркировка производится в двух местах. "Mangle prerouting" для входящих и возможного транзита. "Mangle output" для соединений и пакетов порожденных самим роутером.

Далее, две таблицы маршрутизации в зависимости от маркировки.

 

P.S. Может это NAT на PPPoE портит всё?

Edited November 20, 2016 by nkusnetsov

[grifin.ru]

У вас с провайдером, к которому подключены по PPPoE eBGP поднят?

Конечно нет, иначе смысл городить туннели ?

Он про вашу подсеть за PPPoE-клиентом знает или исходящее на PPPoE тупо NATится?

Не знает, но и НАТ не настроен. По крайней мере на данном этапе.

--------

Кстати, насчет "красиво":

1. Не стал писать руками маршруты, а выбрал в инстансе альтернативную таблицу маршрутизации.

2. Вместо манглов написал правила во вкладке "rules" Раздела "Routes".

Это я правильно сделал ?

[nkusnetsov]

grifin.ru, правильно ли я понимаю, что у вас на белые адреса запрос приходит через туннель, а ответ пытается уходить через PPPoE?

Лучше нарисуйте схему, хотя бы с "левыми" IP и подсетями и покажите направления запрос-ответ реальные и желаемые.

[Serejka]

нормального vrf раньше 7ой ветки говорят не будет. Так что лучше этот функционал заведомо на микротиках не трогать.

[grifin.ru]

grifin.ru, правильно ли я понимаю, что у вас на белые адреса запрос приходит через туннель, а ответ пытается уходить через PPPoE?

Лучше нарисуйте схему, хотя бы с "левыми" IP и подсетями и покажите направления запрос-ответ реальные и желаемые.

Да, так и было. Но я это разрулил уже (см. последнее сообщение). Теперь все работает. (По крайней мере с одним аплинком). Буду дальше настраивать.

[Saab95]

Нужно на каждом BGP соединении поднять полную сеть /23.

Нужно оба этих BGP сервера соединить туннелем.

В фильтрах динамического роутинга создать маршрут в сторону BGP и промаркировать его.

Манглами промаркировать все маршруты внутреннего трафика в сторону имени созданного фильтра.

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

[grifin.ru]

Нужно на каждом BGP соединении поднять полную сеть /23.

Нужно оба этих BGP сервера соединить туннелем.

Читайте вше, я писал почему не хочу это делать.

Не забываем, что кроме таргета, еще и в самих ЦОДах стоят сервера, именно поэтому отдается лишь /27 из каждой /24.

В описанном Вами случае через туннель будет летать, в том числе трафик, предназначенный для серверов находящихся в противоположном ЦОДе.

 

В фильтрах динамического роутинга создать маршрут в сторону BGP и промаркировать его.

Манглами промаркировать все маршруты внутреннего трафика в сторону имени созданного фильтра.

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

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

Только при этом эти два микротика будут иметь разные IP адреса, на какой из них настраивать интерфейсы клиентов ? До вашего варианта я и сам догадался. Интересует как сделать так, чтоб при выход из строя одного микротоика - второй бы поднялся с его IP адресами.

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

И создал-бы еще одну точку отказа, причем незарезервированную. Смысл ?