два провайдера (freebsd, quagga)

[multya]

приветствую всех…

 

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

 

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

 

имеется сервер с тремя сетевыми. eth0 – внутрь сети (5.5.5.5 сеть /24), eth1 – первый провайдер (1.1.1.1 маска /30), eth2 – второй провайдер (2.2.2.2 маска /30).

 

оборудование:

программный маршрутизатор на основе freebsd & quagga/zebra

 

необходимо:

1. постоянно активных два линка от разных провайдеров (т.е. нет резервного канала, никто не простаивает, оба постоянно пыхтят);

2. возможность распределения нагрузки… т.е. хотим 1:1, хотим 5:1 (это все очень приблизительно, но главное смысл думаю понятен);

3. падает один линк - весь трафик идет через другого, восстанавливается линк – восстанавливаются правила описанные в п.2.;

4. возможность статического задания маршрута (т.е. в сети первого провайдера ходим через eth1, второго соответственно через - eth2).

 

не хотелось бы услышать что-то типа (уже мого подобного читал на форумах):

- напиши скрипт который пингует провов и меняет основной шлюз в зависимости от живности провайдера, и запускай по крону – не подходит – см п.1. и п.2.

- направь часть пользователей (сервисов) через один шлюз, часть через другой – не подходит см. п.1. и п.2

- регистрируй as & pi настраивай bgp и будет тебе щастье – этот вопрос разрабатывается – возможно так и будет, ну а пока что «що маємо то маємо»

 

мысли:

необходима динамическая маршрутизация. для этих целей использовать маршрутизаторы cisco systems & подобные ему. конечно же не понижая достоинства возможностей cisco ios с теми же задачами практически в полном объеме может справиться quagga/zebra (или Я ошибаюсь?). посему на нем и остановимся. а необходимый нам протокол ospf v2 (или то же самое можно сделать с помощью bgp, rip, etc?)

настраиваем необходимые конфиги (zebra.conf & ospfd.conf) и договариваемся с провайдерами чтобы они … и вот здесь загвоздка (во всяком случае для меня)… появляются кучи вопросов:

 

что должны анонсировать провайдеры на мой маршрутизатор?

свои сети, свои маршруты?

или просто достаточно получать от его ближайшего роутера какие-то данные, тогда какие?

что именно?

вопрос назревший, сам большого опыта не имею – но имею большое желание научиться/разобраться, посему прошу по существу

заранее благодарен!

[Kirya]

Всё-таки, возьми себе PI IP,AS, настрой BGP и не мучайся.

[Nailer]

приветствую всех…  

 

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

 

А не приходило в голову, что раз не было готового простого решения в других постах, то не будет и сейчас? :-)

 

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

 

имеется сервер с тремя сетевыми. eth0 – внутрь сети (5.5.5.5 сеть /24), eth1 – первый провайдер (1.1.1.1 маска /30), eth2 – второй провайдер (2.2.2.2 маска /30).  

 

оборудование:

программный маршрутизатор на основе freebsd & quagga/zebra  

 

необходимо:

1. постоянно активных два линка от разных провайдеров (т.е. нет резервного канала, никто не простаивает, оба постоянно пыхтят);  

 

Замечательное требование. Разумное.

Но! Объясните, по какому признаку маршрутизатор должен разбрасывать сессии?

 

Если вы не хотите брать PI-адреса, то это значит, что придется изнутри использовать нат. Соответственно, реальные адреса раздавать внутрь вы сможете, но через второй канал они будут ходить кривовато (через нат, а это не есть гут).

 

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

 

Возвращаясь к нашим пирогам. По какому признаку маршуртизатор может принимать решение о направлении траффика в один из каналов?

 

Вариант 1. Единственно разумный - по адресу получателя, соответственно тому, как и должен работать роутер. А для того, чтобы знать, где какой адрес ближе, он должен знать обо всех маршрутах. Fullview принимать, другими словами. А провайдеры должны его отдвать. Оба.. И еще нужны PI-адреса.

Протокол, естественно, BGP.

 

Вариант 2. Два дефлота, решаем от балды, куда что полетит. Соответственно балда может ориетироваться на внутрение адреса, может на внешние, а может round-robin-ом раскидывать. Вот тут, кстати, может быть разница между софтовым роутером и циской - нельзя разбрасывать в разные каналы пакеты одной сессии, можно одного получателся, иначе пакеты могут менять порядк следования. Циска точно умеет, а вот как тут дела у фри - вопросец.

Дефлот, соответственно, можно принимать по статике, ОСПФ-у, EIGRP, RIP, BGP - как заблогорассудится. Но наружу свои адреса анонсить удобнее по BGP, если они у вас будут. Если не будет - то можно использовать для ната провайдеские, а анонсить будут их провайдеры.

 

2. возможность распределения нагрузки… т.е. хотим 1:1, хотим 5:1 (это все очень приблизительно, но главное смысл думаю понятен);  

 

А тут вы многого хотите. Даже с fullview BGP балансировка - дело тяжелое, и чтобы добится хотя бы 1:1 между каналами, надо хорошо постараться.

 

 

 

не хотелось бы услышать что-то типа (уже мого подобного читал на форумах):  

- напиши скрипт который пингует провов и меняет основной шлюз в зависимости от живности провайдера, и запускай по крону – не подходит – см п.1. и п.2.  

- направь часть пользователей (сервисов) через один шлюз, часть через другой – не подходит см. п.1. и п.2  

- регистрируй as & pi настраивай bgp и будет тебе щастье – этот вопрос разрабатывается – возможно так и будет, ну а пока что «що маємо то маємо»  

 

Как это ни банально, но от вас ничего не утаили :-)

[f13]

свои PI и AS это кончено хорошо, но однако дорого :(

для решения такой задачи вполне хватит упросить провов сливать свои fullview в твою приватную AS

а если еще уговорить прова аннонсировать твои сети другова прова, то это вообще блеск, ну и наоборот

зы. и почему про приватные AS все забываю? :(

[Kirya]

для решения такой задачи вполне хватит упросить провов сливать свои fullview в твою приватную AS

 

Всё-равно для этого свои PI нужны.

 

а если еще уговорить прова аннонсировать твои сети другова прова, то

 

Ну попробуй уговори. :)

[f13]

для решения такой задачи вполне хватит упросить провов сливать свои fullview в твою приватную AS

Всё-равно для этого свои PI нужны.

зачем?

про свои ресуры в инете в вопросе ничего не было

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

а если еще уговорить прова аннонсировать твои сети другова прова, то

Ну попробуй уговори. :)

можно