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

ISP - переход со статики на динамику Требуется перевести ядро ISP с статической маршрутизации на динамику

Доброго времени суток всем наговцам.

Требуются советы по реорганизации сети.

Текущая схема сети

158035656.jpg

Описание - абоны попадают на "Шейпер", после чего на следующем серваке натятся и уходят в инет через bgp роутер.

В сети все работает по статическим роутам, кроме bgp роутера на внешку .

 

Требования к сети:

1. Гибкость

2. Расширяемость

3. Резервирование

4. Надежность.

5. Балансировка нагрузки по роутерам.

 

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

Предполагаемая схема сети...

158035658.jpg

 

Возникшие вопросы...

1. Должно быть несколько роутеров bgp. Как организовать балансировку и резервирование ?

Я вижу только два - отдавать разные подсети с разных роутеров , либо развесить роутеры по направлениям. Для балансировки поднимается с каждым нейбором по связи и идет настройка приоритетов (для бекапирования роутеров)

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

3. Можно ли построить схему в которой не будет бегать мультикаста и броадксата OSPF. Т.е. Шейпер отдает DR и BDR какие он сети обслуживает, а остальные роуетры получают инфу, какие подсети и за каким ротутером находятся

4. Как сделать эту схему более оптимальной, каким образом минимализировать нагрузку на сервера от динамических протоколов.

 

P.S. Все планируется поднимать на PC+quagga.

 

Буду благодарен за любые ссылки и комментарии и рекомендации по теме.

Edited by HEDG

Share this post


Link to post
Share on other sites

Какая-то у Вас нездоровая тяга к избыточности. :) Наверное Вам некуда большое количество РС утилизировать?

Я бы сделал каждому шейперу по своему НАТ-у (собственно говоря на одном РС делать шейпер+НАТ). Скажете - сильно напряжные нагрузки? Ну так сделать больше таких РС, раскинув акцесс-сеть по ним более мелкими сегментами. Далее, ставим на каждый внешний аплинк по своему бордеру + Л3-свич для пиров и "различных IX" (хотя, если таблица последнего не влезет в память свича, то тоже ставить РС).

Между бордерами и НАТ-ами пускаем OSPF. Не нужны никакие отдельные DR/BDR/LocalRouter. Чем меньше железяк - проще обслуживание, меньше бардака, меньше жрут/шумят, меньше точек отказа.

Фсё.

Share this post


Link to post
Share on other sites
Какая-то у Вас нездоровая тяга к избыточности. :)

Чем меньше железяк - проще обслуживание, меньше бардака, меньше жрут/шумят

боюсь у него не избыточность а нехватка средств на пару нормальных машин

и времени чтобы всё это по уму настроить

 

а так - согласен.

 

 

пы.сы. локально в одной комнате и RIP пойдет.

Share this post


Link to post
Share on other sites
Какая-то у Вас нездоровая тяга к избыточности. :) Наверное Вам некуда большое количество РС утилизировать?

Я бы сделал каждому шейперу по своему НАТ-у (собственно говоря на одном РС делать шейпер+НАТ). Скажете - сильно напряжные нагрузки? Ну так сделать больше таких РС, раскинув акцесс-сеть по ним более мелкими сегментами. Далее, ставим на каждый внешний аплинк по своему бордеру + Л3-свич для пиров и "различных IX" (хотя, если таблица последнего не влезет в память свича, то тоже ставить РС).

Между бордерами и НАТ-ами пускаем OSPF. Не нужны никакие отдельные DR/BDR/LocalRouter. Чем меньше железяк - проще обслуживание, меньше бардака, меньше жрут/шумят, меньше точек отказа.

Фсё.

На самом деле, схема проекта - это схема к которой должна прийти сеть через год, максимум полтора.

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

Загрузка канала в 350Мб/с, но к концу года планируется минимум удвоить трафик, а может и утроить..

Поэтому и выдвигались требования - 1. Гибкость 2. Расширяемость. , чтоб потом не получилось - "Вот и приплыли....Полный п.."

 

В будущем так и планируется - Каждому Шейперу свой нат.

 

Так много роутеров для того чтоб, например любой роутер c NAT или BGP я мог погасить в любой момент на обслуживание.

LocalRouter - имелось ввиду различные сервисы (прошу прощения за неточность формулировки). А DR/BDR - планировалось сделать пару незагруженных LocalRouter .

 

Схема, которую Вы предлагаете интересна, но меня смущают пару моментов

1. Как будут распространятся LRA между роутерами? Мультипоинт? Мультикаст?

сеть очень динамичная, постоянно переносятся подсети, добавляются новые.. Хочется иметь возможность изменив данные на одном роутере, получить устоявшееся состояние сети максимум через 30-60 сек.

2. В сети работает торрент трекер, поэтому нагрузка на каждый из шейперов 150-200Мб. Схема с разделенным нат и шейпером, конечно с минусами, но позволяет пропускать через NAT только внешний трафик(соответственно снижая на него нагрузку). С количеством глючных узлов согласен, но и проблему в таком случае гораздо проще отследить. У нас политика четкого разделения внешнего и локального трафика.

 

P.S. Схема резервирования N+1 имеет свои недостатки, но в нашем случае она более предпочтительна. Можно конечно размышлять, что лучше одна тачка на Core i7 или несколько попроще, но лучше подскажите как максимально приблизиться к выдвинутым требованиям...

Share this post


Link to post
Share on other sites
боюсь у него не избыточность а нехватка средств на пару нормальных машин

и времени чтобы всё это по уму настроить

 

а так - согласен.

 

 

пы.сы. локально в одной комнате и RIP пойдет.

Возможности ограничены конечно. Парк PC обновляется по необходимости.

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

 

Насчет RIP. Насколько я читал OSPF под мои задачи будет поинтереснее, поэтому использовать устаревший(по сравнению с OSPF) протокол в проектировании новой сети думаю не совсем правильно.

Share this post


Link to post
Share on other sites

Ядро добавьте еще в свою сеть, сразу все станет проще и наглядней. Какой нибудь каталист с ospf.

Share this post


Link to post
Share on other sites
1. Как будут распространятся LRA между роутерами? Мультипоинт? Мультикаст?

сеть очень динамичная, постоянно переносятся подсети, добавляются новые.. Хочется иметь возможность изменив данные на одном роутере, получить устоявшееся состояние сети максимум через 30-60 сек.

:) Вы, судя по всему, понятия не имеете о работе протоколов динамической маршрутизации. Не парьтесь, этот велосипед изобретен давно, и он очень хорош. "устоявшееся состояние сети" в Вашем случае будет достигнуто за пару милисекунд при мизере служебного трафика (да, это мультикаст). :) В инете много учебного материала по OSPF, в том числе и на русском языке. Не поленитесь погуглить.

 

2. В сети работает торрент трекер, поэтому нагрузка на каждый из шейперов 150-200Мб. Схема с разделенным нат и шейпером, конечно с минусами, но позволяет пропускать через NAT только внешний трафик(соответственно снижая на него нагрузку). С количеством глючных узлов согласен, но и проблему в таком случае гораздо проще отследить. У нас политика четкого разделения внешнего и локального трафика.
Мда... Совсем все запущено... А зачем же Вы гоните внутренний трафик через шейперы? Или этот трафик у Вас в сети платный? Обычно делается все не так.

1. Все акцесс-сегменты заводим и терминируем на один Л3-свич (чтобы дефолт-роутером для каждого сегмента были SVI этого свича). В него же повтыкать все локальные серверы. Таким образом, весь локальный трафик замкнется на этом свиче и не пойдет наружу.

2. В этот же свич втыкаем нужное количество РС шейпер+НАТ (ИМХО для Ваших объемов абсолютно достаточно 2-х РС). Между ними запускаем OSPF в тупиковой арии. Тут необходимо продумать способ балансировки трафика между НАТ (например PBR на Л3-свиче).

3. Все дальнейшее описано в моем первом посте.

 

Данная схема позволит Вам отключать/добавлять сервера НАТ на ходу абсолютно прозрачно для абонентов и обеспечить необходимое резервирование. Отвалился один НАТ => весь трафик по OSPF автоматом перекинулся в оставшиеся. То же самое и с бордерами: вышел из строя один бордер => отсох его аплинк => весь внешний трафик автоматом сливается через оставшиеся бордеры. Динамическая маршрутизация рулит.

 

Share this post


Link to post
Share on other sites

Меня всегда радуют люди, которые пишут "BGP или OSPF". Запомните дети, BGP _И_ OSPF. Других вариантов у вас нет. IS-IS для писюков не бывает.

Share this post


Link to post
Share on other sites
:) Вы, судя по всему, понятия не имеете о работе протоколов динамической маршрутизации. Не парьтесь, этот велосипед изобретен давно, и он очень хорош. "устоявшееся состояние сети" в Вашем случае будет достигнуто за пару милисекунд при мизере служебного трафика (да, это мультикаст). :) В инете много учебного материала по OSPF, в том числе и на русском языке. Не поленитесь погуглить.
C BGP работал. По OSPF только постепенно просвещаюсь (Источник - Структура и реализация сетей на основе протокола OSPF, 2-е изд.).

Из прочитанного, мне больше нравится схема мультипоинта. (Хочется иметь возможность контролировать обновления на одном роутере).

Насколько я читал при мультипоинте "устоявшееся состояние сети" будет через 6-46сек.

 

Мда... Совсем все запущено... А зачем же Вы гоните внутренний трафик через шейперы? Или этот трафик у Вас в сети платный? Обычно делается все не так.

1. Все акцесс-сегменты заводим и терминируем на один Л3-свич (чтобы дефолт-роутером для каждого сегмента были SVI этого свича). В него же повтыкать все локальные серверы. Таким образом, весь локальный трафик замкнется на этом свиче и не пойдет наружу.

2. В этот же свич втыкаем нужное количество РС шейпер+НАТ (ИМХО для Ваших объемов абсолютно достаточно 2-х РС). Между ними запускаем OSPF в тупиковой арии. Тут необходимо продумать способ балансировки трафика между НАТ (например PBR на Л3-свиче).

3. Все дальнейшее описано в моем первом посте.

 

Данная схема позволит Вам отключать/добавлять сервера НАТ на ходу абсолютно прозрачно для абонентов и обеспечить необходимое резервирование. Отвалился один НАТ => весь трафик по OSPF автоматом перекинулся в оставшиеся. То же самое и с бордерами: вышел из строя один бордер => отсох его аплинк => весь внешний трафик автоматом сливается через оставшиеся бордеры. Динамическая маршрутизация рулит.

Локальный трафик у нас не тарифицируется. Раньше на разных пакетах была разная скорость. А как обычно это делается ? (Спасибо за пищу к размышлению по оптимизации).

SVI есть в свичах кроме CISCO и Juniper ? (к сожалению у нас пока построено все на смарт свичах L2, в том числе и ядро сети).

 

Даже если реализовать данную схему остается вопрос связи BGP роутеров и роутеров NAT. Я так понимаю либо на BGP роутерах должен подниматься OSPF, либо На серверах NAT поднимать сессии c BGP роутерами

 

 

 

Share this post


Link to post
Share on other sites

ospf пожалуй проще будет чем тот же bgp, да и если есть опыт работы с bgp, то ospf как семечки щелкать будете.

между роутерами и nat никакого bgp не надо - ересь это все. bgp на то и называется border gateway protocol, чтоб его использовать только на бордерах. если так хочется динамикой развести - все что находится за бордером разводите по ospf.

p.s. SVI - это удел всех L3 коммутаторов. в том числе и cisco и juniper и dlink и т.д.

 

Share this post


Link to post
Share on other sites
никакого bgp не надо - ересь это все. bgp на то и называется border gateway protocol, чтоб его использовать только на бордерах

Зачем Вы пишете о том, в чем не разбираетесь?

 

Share this post


Link to post
Share on other sites
Зачем Вы пишете о том, в чем не разбираетесь?
Что за хамство? Где конструктивная критика ?

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

 

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

 

The Border Gateway Protocol (BGP) is an interautonomous system routing protocol. An autonomous system is a network or group of networks under a common administration and with common routing policies. BGP is used to exchange routing information for the Internet and is the protocol used between Internet service providers (ISP). Customer networks, such as universities and corporations, usually employ an Interior Gateway Protocol (IGP) such as RIP or OSPF for the exchange of routing information within their networks. Customers connect to ISPs, and ISPs use BGP to exchange customer and ISP routes.
(с) Cisco Systems.

 

Share this post


Link to post
Share on other sites
IS-IS для писюков не бывает.
Почему не бывает, в последней версии quagga есть is-is. Вопрос только в его работоспособности, я не пробывал так что точно утверждать не могу :).
bgp на то и называется border gateway protocol, чтоб его использовать только на бордерах
Ересь :) а ibgp где использовать? :)

Share this post


Link to post
Share on other sites
Ересь :) а ibgp где использовать? :)
на мой взгляд, ibgp хорош для использования в случае если сеть переросла в состояние enteprise масштабов. например для связывания нескольких городов, областей, или даже регионов.

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

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

 

просто к слову добавлю - споры про ospf vs bgp vs isis и т.д., одно из самых излюбленных направлений среди сисадминов. уж сколько тем было. на certification.ru они чуть ли не через одну шли, да и до сих пор идут..

Edited by darkagent

Share this post


Link to post
Share on other sites
на мой взгляд, ibgp хорош для использования в случае если сеть переросла в состояние enteprise масштабов. например для связывания нескольких городов, областей, или даже регионов.

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

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

Вы таки удивитесь, но в некоторых случаях даже в пределах одной сети вполне может использоваться еBGP. С приватными номерами АС например.

А уж применение iBGP в сетях с MPLS - так вообще типовой дизайн (и такая сеть вполне может существовать и в пределах одного города).

Share this post


Link to post
Share on other sites
Вы таки удивитесь, но в некоторых случаях даже в пределах одной сети вполне может использоваться еBGP. С приватными номерами АС например.

А уж применение iBGP в сетях с MPLS - так вообще типовой дизайн (и такая сеть вполне может существовать и в пределах одного города).

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

 

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

Edited by darkagent

Share this post


Link to post
Share on other sites

Насколько я читал при мультипоинте "устоявшееся состояние сети" будет через 6-46сек.

Наверное то что Вы читали о мультипоинте, написано про синхронные/асинхронные линки конца прошлого века. :) У Вас же в сети будет всего несколько роутеров в полносвязной схеме с гиговыми линками. Какие секунды? Время, требуемое на сходимость сети тут будет равно времени передачи пары мультикаст-пакетов между роутерами. :) Когда все соберете - увидите сами.

Share this post


Link to post
Share on other sites
Ересь :) а ibgp где использовать? :)
на мой взгляд, ibgp хорош для использования в случае если сеть переросла в состояние enteprise масштабов. например для связывания нескольких городов, областей, или даже регионов.

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

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

 

просто к слову добавлю - споры про ospf vs bgp vs isis и т.д., одно из самых излюбленных направлений среди сисадминов. уж сколько тем было. на certification.ru они чуть ли не через одну шли, да и до сих пор идут..

Мой вам совет, потом спасибо скажите:

igp (rip/ospf/eigrp...) используйте для своего оборудования.

а egp (i/eBGP) для клиентских сетей.

 

Почему? с опытом поймете, щас вряд ли вы готовы слЫшать аргументы (мне так показалось).

Share this post


Link to post
Share on other sites
Почему? с опытом поймете, щас вряд ли вы готовы слЫшать аргументы (мне так показалось).

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

Share this post


Link to post
Share on other sites

Дайте угадаю? Число префиксов /32 (абонентов) переносимое между брасами?

Share this post


Link to post
Share on other sites

Прочитав все вышеперечисленное, сделал следующие выводы(все выводы касаются моей сети):

1. BGP использую для связи с вышестоящими, IX, паритетами и т.д

2. Все остальные роутеры обмениваются инфой по OSPF

 

Возникающие вопросы:

Аплинков может быть несколько (мы получаем full view от каждого) + ix + паритеты

1. Можно ли реализовать такую схему, чтоб с нескольких аплинков на роутеры NAT отсылать только default route, причем чтоб была балансировка между каналами... Насколько это реально?

 

Share this post


Link to post
Share on other sites

а схему с отражателем маршрутов (route reflector) никто не использует? по моим представлениям они как раз для подобных схем выдуманы

Share this post


Link to post
Share on other sites

Дайте угадаю? Число префиксов /32 (абонентов) переносимое между брасами?

Не совсем угадали... Подсети разбиты по /24 и довольно часто переносятся между брасами, в зависимости от изменений на районах.

Share this post


Link to post
Share on other sites

Так /24 имхо можно и по igp гонять :)

Или на перспективу?

 

а схему с отражателем маршрутов (route reflector) никто не использует? по моим представлениям они как раз для подобных схем выдуманы
RR , насколько я помню, выдуманы чтобы не плодить фулл-меш связность из ibgp сессий внутри автономки...

Share this post


Link to post
Share on other sites
Так /24 имхо можно и по igp гонять :)

Или на перспективу?

Нужна не просто схема, работающая как-то.

Нужна наиболее оптимальная схема, в которой будет заложен большой потенциал на будущее.

Хочется один раз настроить сеть, а потом просто менять железо на более новое или добавлять...

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