[chukcha]

Коллеги, у меня такая ситуация, что покупать канал с BGP выходит в 3-4 раза дороже, чем просто со статическим IP аплинка. Родилась идея - поставить в датацентре в Москве оборудование, и протащить от него до меня туннель, и уже в этом туннеле поднимать BGP сессию с московскими операторами, или брать трафик с того же MSK-IX.

 

Для тестирования такой возможности я поставил в датацентре Mikrotik AH1100 (Микротик ДЦ), датацентр дал мне один порт, канал 100 Мегабит, и 5 IP адресов (/29 сеть).

На своем узле связи я поставил точно такой же Mikrotik AH1100 (Микротик УС).

 

Решил начать тестирование, и чет забуксовал.

 

Что я хочу получить в итоге:

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

 

Для простоты думал просто поднять EoIP туннель между железкой у себя и железкой в датацентре. Это без проблем получилось.

Следующим шагом я решил создать бридж, поместить в него порт Микротика ДЦ который смотрит на коммутатор датацентра и EoIP туннель. Подобную настройку я сделал и на Микротике на своем узле связи. Но вылезла некрасивая ситуация, когда шлюз датацентра стал виден не на физическом интерфейсе Микротика ДЦ. В итоге туннель нормально не работает, и кроме того, постоянно ловит петлю, и соответственно отключается.

 

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

Заранее спасибо!

[vlad11]

Микротик закопать и забыть.

Полезная емкость канала уменьшится в 2 раза.

Используйте NAT.

[MMM]

Топикстартеру: маршруты между микротиками должны идти "мимо туннеля". Вам вообще можно не EoIP, а GRE. А так, 100 мбит даже на мыльницах TPLink люди прокачивали (на openwrt). Для верности, навесьте еще на трафик, который будет идти внутрь туннеля, mssfix где-то на 1300 байт, чтобы не было лишней фрагментации.

[SUrov_IBM]

Заранее спасибо!

 

Уважаемый Chukcha, доброго времени суток.

 

Mikrotik, я не использую, на это есть ряд причин.

 

Была бы у Вас самая вшивая кошка, помог бы с конфигурацией.

Но оборудование сути вопроса не меняет.

 

Что бы поти самым простым путём, примерная схема:

 

1. В «дата центре» маршрутизатор «А» выходит в Интернет и строит GRE

туннельное соединение с маршрутизатором «Б» (который тоже выходит в Интернет)

на вашей базе.

 

2. Между маршрутизаторами «А» и «Б» поднимется iBGP (внимание на «i»).

 

3. Со стороны маршрутизатора «Б» на маршрутизатор «А» начинается анонс вашей сети.

 

4. Маршрутизатор «А» строит eBGP сессию с операторам в «дата центре» и анонсирует

Вашу сеть только при получении её от маршрутизатора «Б».

 

5. По такой же схеме отдаём сети «дата центра» (например 0.0.0.0/0) в обратную сторону.

 

6. Если плохо понимаете маршрутизацию, с обеих сторон используйте Next hop Self,

для прямой связности по BGP, но лучше об этом почитать.

 

Проблемы MTU, с которыми вы можете столкнутся, отдельная тематика,

к BGP она не имеет прямого отношения.

[Saab95]

Для тестирования такой возможности я поставил в датацентре Mikrotik AH1100 (Микротик ДЦ), датацентр дал мне один порт, канал 100 Мегабит, и 5 IP адресов (/29 сеть).

На своем узле связи я поставил точно такой же Mikrotik AH1100 (Микротик УС).

 

Устанавливаете один IP из этой сети на роутере и включаете proxy-ARP на порту.

Настраиваете L2TP сервер, создаете учетную запись для второго микротика, указав 3 адрес из выданной вами сети для выдачи ему (remote address) а 2 адрес укажите в local address.

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

 

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

 

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

По выданным адресам поднимаете сессию BGP.

 

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

 

То, что я написал, будет работать, однако у вас в канале будет МТУ меньше 1500 байт, что для работы BGP не очень хорошо. Именно по этой причине лучше всего BGP настраивать в датацентре, а далее через OSPF анонсировать маршруты на него.

Что бы в L2TP туннеле проходили пакеты размером 1500 байт без фрагментации, нужно указать в параметрам MRRU размер пакета 1500 байт, тогда фрагментировать пакеты будет сам туннель, и пинг с флагом без фрагментации пройдет без потерь.

 

Топикстартеру: маршруты между микротиками должны идти "мимо туннеля". Вам вообще можно не EoIP, а GRE. А так, 100 мбит даже на мыльницах TPLink люди прокачивали (на openwrt). Для верности, навесьте еще на трафик, который будет идти внутрь туннеля, mssfix где-то на 1300 байт, чтобы не было лишней фрагментации.

 

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

 

Микротик закопать и забыть.

Полезная емкость канала уменьшится в 2 раза.

 

Это почему в 2 раза?

Если вы запускаете тест на пакетах 1460 байт и у вас канал 100 мегабит, то прокачаете 100 мегабит.

Если запустите тест на пакетах 1500 байт, то на канале 100 мегабит прокачаете около 80-85, потери на фрагментацию.

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

 

Mikrotik, я не использую, на это есть ряд причин.

 

По каким?

 

1. В «дата центре» маршрутизатор «А» выходит в Интернет и строит GRE

туннельное соединение с маршрутизатором «Б» (который тоже выходит в Интернет)

на вашей базе.

 

2. Между маршрутизаторами «А» и «Б» поднимется iBGP (внимание на «i»).

 

3. Со стороны маршрутизатора «Б» на маршрутизатор «А» начинается анонс вашей сети.

 

4. Маршрутизатор «А» строит eBGP сессию с операторам в «дата центре» и анонсирует

Вашу сеть только при получении её от маршрутизатора «Б».

 

5. По такой же схеме отдаём сети «дата центра» (например 0.0.0.0/0) в обратную сторону.

 

6. Если плохо понимаете маршрутизацию, с обеих сторон используйте Next hop Self,

для прямой связности по BGP, но лучше об этом почитать.

 

Аааа, теперь понятно почему=) Вы цисковские вещи пытаетесь перенести на микротик, хотя на нем достаточно OSPF включить и больше ничего не делать.

[vlad11]

Запасся попкорном.

Жду когда клиент, используя OSPF положит роутер ДЦ :)

[SUrov_IBM]

 

Аааа, теперь понятно почему=) Вы цисковские вещи пытаетесь перенести на микротик, хотя на нем достаточно OSPF включить и больше ничего не делать.

 

Уважаемый Saab95, доброго времени суток.

 

Я не умиляю достоинства Ваших чудо коробочек Mikrotik.

Под определённые задачи, скорей всего прекрасная коробочка.

 

Заметьте, я не пытаюсь развернуть баталии на тему «Cisco vs Mikrotik».

 

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

Что «кошка», что Mikrotik – маршрутизаторы, главное это понимание маршрутизации и протокола,

за счет которого она строится.

 

Я не переношу «кошкины» вещи на Mikrotik, последний тоже умеет BGP,

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

 

OSPF в конкретном случае не пришей кобыле хвост, пожалуйста не сбивайте с толку человечка.

OSPF может потребоваться в будущем для отказоустойчивости каналов.

 

Я понимаю, Вы продаёте Mikrotik’и и Вам хочется их разрекламировать,

но тогда делайте это грамотно. В данном случае не советуйте OSPF,

а объясните нуждающемуся в помощи человечку как на Mikrotik настроить схему iBGP.

 

Лично я не использую Mikrotik только по одной причине - почти всё что может Mikrotik,

я могу сделать руками на компактном сервере с FreeBSD.

Опять же не подумайте что я как-то умиляю достоинства Mikrotik!

 

У меня так же как у автора темы, построен канал связи в «дата центр»,

правда на софт маршрутизаторах FreeBSD и Linux.

 

Да я не умею настраивать Mikrotik, только принцип маршрутизации от типа оборудования не меняется!

 

Спасибо Vlad11’у за напоминание о том, что скорость полезного трафика

при одно портовом включении (самый распространённый случай) в «дата центре»

уменьшится (грубо) на 50%. Поскольку проходит «петлёй» через маршрутизатор.

 

P.S. Плюс через «публичный» Интернет, скорость трафика в тоннеле может скачкообразно меняться!

[Saab95]

OSPF в конкретном случае не пришей кобыле хвост, пожалуйста не сбивайте с толку человечка.

OSPF может потребоваться в будущем для отказоустойчивости каналов.

 

 

Для чего нужен вообще BGP? Что бы анонсировать в интернет свои IP адреса.

Для чего нужен OSPF? Что бы динамически обмениваться маршрутами.

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

[SUrov_IBM]

OSPF в конкретном случае не пришей кобыле хвост, пожалуйста не сбивайте с толку человечка.

OSPF может потребоваться в будущем для отказоустойчивости каналов.

 

 

Для чего нужен вообще BGP? Что бы анонсировать в интернет свои IP адреса.

Для чего нужен OSPF? Что бы динамически обмениваться маршрутами.

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

 

 

Уважаемый Saab95, доброго времени суток.

 

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

 

У каждого протокола, своя особенность. OSPF нужен (грубо), для отказоустойчивости и балансировки

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

 

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

его «ядром системы» и «дата центром», на основе протокола BGP.

 

Не существует возможности дистрибутировать специфические метрики протокола BGP на узле «А» в OSPF,

а на узле «Б» вывернуть их обратно. Фарш невозможно провернуть назад и мясо из котлет не восстановишь!

 

С учётом того, что между узлами «А» и «Б» у человека один канал, на основе туннеля

(пока не подразумевается резервирование) использование OSPF равносильно поездке на машине «Белаз» в магазин за пивом.

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

 

А вот для передачи специфической сигнальной информации протокола BGP поверх построено канала, как раз потребуется iBGP.

 

Можно конечно использовать eBGP multihop поверх построенного туннельного канала, но это отдельная песня.

[s.lobanov]

Для чего нужен вообще BGP? Что бы анонсировать в интернет свои IP адреса.

 

 

BGP условно делят на 2 части - ebgp и ibgp. ebgp как раз нужен для того, чтобы "анонсировать в интернет свои IP адреса" (с точки зрения тупиковой AS) продавцы SOHO-шлюзов вряд ли знают что-то про транзитные AS

 

Относительно ospf, то в ISP он нужен лишь для обмена информации о лупбэках, для обмена же информации об остальных сетях внутри AS - ibgp. Дело в том, что bgp на порядок проще и понятнее с точки зрения фильтров и вообще механизма работы (чем ospf, is-is и т.п.) и практически неограниченно масштабируется

[SyJet]

Вот даже не смешно уже..

[s.lobanov]

SyJet

если вы считаете, что ospf это протокол, для того, чтобы анонсить connected/static сети между роутерами внутри AS, то значит, что вы просто ничего не понимаете в дизайне и проблемах масштабирования

[vlad11]

/me запасся поп-корном

[SyJet]

SyJet

если вы считаете........

Я не о вас. А о письменах Сааб-а

Изменено 12 июля, 2015 пользователем SyJet

[s.lobanov]

SyJet

если вы считаете........

Я не о вас. А о письменах Сааб-а

 

ок. vlad11 можете убирать поп-корн

[Saab95]

BGP условно делят на 2 части - ebgp и ibgp. ebgp как раз нужен для того, чтобы "анонсировать в интернет свои IP адреса" (с точки зрения тупиковой AS) продавцы SOHO-шлюзов вряд ли знают что-то про транзитные AS

 

Относительно ospf, то в ISP он нужен лишь для обмена информации о лупбэках, для обмена же информации об остальных сетях внутри AS - ibgp. Дело в том, что bgp на порядок проще и понятнее с точки зрения фильтров и вообще механизма работы (чем ospf, is-is и т.п.) и практически неограниченно масштабируется

 

То есть, если у меня в датацентре стоит оборудование и принимает BGP, а после есть несколько каналов, через которые работает OSPF, то тут что-то не правильно?

 

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

его «ядром системы» и «дата центром», на основе протокола BGP.

 

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

 

При этом OSPF как раз нужен.

 

Например дает вышестоящий блок адресов /29, на один из этих адресов устанавливается туннель извне. Однако, бывает так, что связанность до этого адреса может пропасть, поэтому выгодно на своем же BGP сервере повесить один адрес из своей адресации, тогда можно будет и на него установить туннель извне. Получается уже 2 туннеля, и тут без OSPF не обойтись.

[tehmeh]

SyJet

если вы считаете, что ospf это протокол, для того, чтобы анонсить connected/static сети между роутерами внутри AS, то значит, что вы просто ничего не понимаете в дизайне и проблемах масштабирования

Как же тогда ospf будет обмениваться информацией о лупбеках, если он не анонсит connected (про static молчу)? : )

[SUrov_IBM]

BGP условно делят на 2 части - ebgp и ibgp. ebgp как раз нужен для того, чтобы "анонсировать в интернет свои IP адреса" (с точки зрения тупиковой AS) продавцы SOHO-шлюзов вряд ли знают что-то про транзитные AS

 

Относительно ospf, то в ISP он нужен лишь для обмена информации о лупбэках, для обмена же информации об остальных сетях внутри AS - ibgp. Дело в том, что bgp на порядок проще и понятнее с точки зрения фильтров и вообще механизма работы (чем ospf, is-is и т.п.) и практически неограниченно масштабируется

 

То есть, если у меня в датацентре стоит оборудование и принимает BGP, а после есть несколько каналов, через которые работает OSPF, то тут что-то не правильно?

 

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

его «ядром системы» и «дата центром», на основе протокола BGP.

 

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

 

При этом OSPF как раз нужен.

 

Например дает вышестоящий блок адресов /29, на один из этих адресов устанавливается туннель извне. Однако, бывает так, что связанность до этого адреса может пропасть, поэтому выгодно на своем же BGP сервере повесить один адрес из своей адресации, тогда можно будет и на него установить туннель извне. Получается уже 2 туннеля, и тут без OSPF не обойтись.

 

Уважаемый Saab95, доброго времени суток.

 

Я уже как девушка хотел сказать фразу – «Ой, всё!», но все же выскажу пару мыслей.

 

>>То есть, если у меня в датацентре стоит оборудование и принимает BGP, а после есть

>>несколько каналов, через которые работает OSPF, то тут что-то не правильно?

 

Если Вы используете более одного канала «IP связи», проложенных между точкой «А»

через космическое пространство и точкой «Б», то да использование OSPF поможет

в быстром переключении (резервировании) при отказе одного из каналов.

 

Если у Вас один канала «IP связи», то OSPF в принципе не нужен,

требуется только статическая маршрутизация.

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

 

У человечка в описании один канала «IP связи».

 

Это первое, почему OSPF в данной задачи не нужен.

Пока каналов не станет два или более (неважно физических или логических).

 

 

 

>>Так у человека не правильная задача - нет никакого смысла тащить BGP из датацентра,

>>выгодно его оставить там же, а вне тащить уже просто роутеры со связностью через OSPF.

 

Второе:

 

C чего вы решили, что человеку выгоднее оставлять табличку BGP маршрутов

на его оборудовании в «дата центре»? Вы полагаете, что у него «дата центр»

это единственный канал в «Мир», там принимается единственный Default Route

(0.0.0.0/0) который можно дистрибутировать в OSPF и передать в «ядро системы»?

 

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

не единственным, а как минимум вторым. И на этих каналах может быть полноценное FullView,

сумируемое на маршрутизаторе в «ядре системы».

 

Или вы предлагаете дистрибутировать полученную в «дата центре» BGP FullView в OSPF?

 

Знате, что тогда произойдёт, помимо «обрезания» специфической маршрутной информации BGP?

 

Маршрутизатор скажет фразу – «Ой, всё!».

Изменено 13 июля, 2015 пользователем SUrov_IBM

[myst]

Маршрутизатор скажет фразу – «Ой, всё!».

Ну предположем может и не сказать, но сама по себе идея дурная ага =)

[Saab95]

Или вы предлагаете дистрибутировать полученную в «дата центре» BGP FullView в OSPF?

 

Можно поднять несколько сессий BGP и анонсить с них свои адреса, а управлять кто куда пойдет метриками.

[SUrov_IBM]

Или вы предлагаете дистрибутировать полученную в «дата центре» BGP FullView в OSPF?

 

Можно поднять несколько сессий BGP и анонсить с них свои адреса, а управлять кто куда пойдет метриками.

 

Уважаемый Saab95, доброго времени суток.

 

Извиняюсь за грубость, по-моему, Вы до конца не понимаете работу протокола BGP.

 

Вы смотрите на картину, как будто есть всего пара BGP маршрутизаторов,

разбросанных один в «дата центр», другой в пыльной стойке местного провайдера.

При этом есть кучка мелкого оборудования умеющего «статик/RIP/OSPF».

 

Вы пытаетесь объединить это оборудование хоть какой-то связанностью

и скомкав (агрегировав) «выплюнуть» на BGP маршрутизаторы, что бы они

объединив это в одну сеть /24 (может больше) «отплюнули» её дальше в «Мир».

 

Входящий из «Мра» маршруты, поломаем до "0.0.0.0/0" на BGP маршрутизаторах

и «пропихнём» на мелкое оборудование (см. выше) через дистрибъюцию в OSPF/статик.

Может быть ещё пару «костылей» по дороге поставим.

 

Самое забавное, эта «каша» даже будет работать!

 

Да только не всем нужна концепция такой «помятой», тупиковой AS!

 

Представьте, что в «ядре системы» может стоять головной маршрутизатор

или «микро кластер» из маршрутизаторов, строящий связность с «Мир»’ом

на основе информации таблички BGP. Для этого решения необходимо иметь

FullView (по возможности), от всех каналов из «Мир»’а.

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

 

Именно «полную» , а не дистрибъюцию «огрызка» через промежуточный протокол.

 

S.lobanov, уже расписал на пальцах концепцию eBGP и iBGP, спасибо ему за это,

я слишком громоздко описываю…

 

Поэтому, что через VPN, что через реальные каналы

связанность должна сохранять свою специфику до головного узла.

[chukcha]

Ребята, спасибо за такое количество советов и ответов.

По пунктам:

Полезная емкость канала уменьшится в 2 раза.

У меня несколько аплинков, и в этот канал я не буду пускать исходящий трафик совсем. Т.е. сколько в порт пришло, столько и уйдет.

 

Используйте NAT.

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

 

 

SUrov_IBM, спасибо за совет. Но я не хочу поднимать BGP на Микротике, были инциденты не приятные.

 

достаточно OSPF включить и больше ничего не делать.

Я тоже не понимаю, зачем на нем OSPF.

 

Друзья, я понимаю, что лучше всего на железке в ДЦ включить iBGP и не мучиться. Но протащить до своего центрального рутера L2 канал от ДЦ совсем плохая идея?

[vlad11]

Полезная емкость канала уменьшится в 2 раза.

У меня несколько аплинков, и в этот канал я не буду пускать исходящий трафик совсем. Т.е. сколько в порт пришло, столько и уйдет.

 

В начальных условиях такого не было.

 

Используйте NAT.

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

 

Натить БГП-сессию, а не весь траффик.

[SUrov_IBM]

Chukcha, доброго времени суток.

 

Я посоветовал использовать iBGP, так как мне это видится

самым простым вариантом в описанной Вами схеме.

Единственное, я не знаю, как оборудование Mikrotik ведёт себя с BGP.

Нет практических примеров.

 

Вы хотите пробросить в «дата центр» именно L2 канал?

 

Просто я не сторонник проброса L2 трафика упакованного в туннель

через «публичный Интернет» без особой необходимости.

 

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

на не подконтрольном Вами участке IP сети.

 

Под особой необходимостью L2 проброса я подразумеваю управление специфическим оборудованием

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

 

В некоторых случаях L2 туннель может помочь разрешить проблему MTU, но опять же,

я не уверен в адекватности такого канала через «публичный Интернет».

 

Если при прохождении трафика через «публичный Интернет», существует проблема MTU,

лучше постараться разрешить её на маршрутизируемых L3 каналах, средствами своих оконечных

маршрутизаторов.

 

Опять же использование iBGP проще, но только если в Ваша схема используется для связи между

«дата центром» и маршрутизатором в ядре AS. Если в ядре AS уже используется iBGP между нескольких

маршрутизаторов, то данная схема скорее вызовет «головную боль».

 

Тогда понятно, почему вы хотите поднять именно L2, что бы используя «режим моста» пробросить

один из IP адресов «дата центра» в ядро AS и опираясь на этот IP настроить полноценную eBGP сессию

с «дата центром».

 

В таком случае, я бы всё равно не стал строить L2 канал через «публичный Интернет».

 

Можно использовать eBGP Multihop, оставив Вашему оборудованию в «дата центре» роль

канало-образующего (L3 VPN тоннель), не завязывая BGP на него в принципе.

Правда с «дата центром» придётся обговорить некоторые моменты статической маршрутизации

и собственно самого eBGP Multihop.

Изменено 14 июля, 2015 пользователем SUrov_IBM