Subnets.ru

Всем здравствуйте!
в продолжении этой темы
успешно закончили все преобразования (правда от идеи резервирования серверов доступа по dns отказались)
и теперь стоит следующая задача: сделать всю схему в ядре отказоустойчивой и сбалансированной, при этом желательно не сложно масштабируемой.
сейчас все выглядит так:
хочется добавить для начала еще один сервер доступа + еще один бордер, причем так, чтобы они работали параллельно (пресловутая балансировка) и в случае отказа заменяли друг друга. т.к nat не используется понятно, что без собственной AS и полного перехода на PI адреса не получится реализовать задуманное.
немного отвлекусь, интересно ваше мнение, стоит ли сейчас заморачиваться и получать статус LIR, или в этом нет необходимости, если мы пока будем тупиковой AS?
Допустим, у нас уже есть и адреса, и AS.. Следующий шаг - это поднятие и настройка bgp (по этому поводу я думаю у меня возникнет много вопросов:)). Правильно ли я понимаю, что лучше брать full-view от обоих uplink'ов? анонсировать свои адреса полностью обоим uplink'ам? между бордерами настраивать iBGP?
резервирование в случае падении канала тогда будет само собой, а вот балансировку как сделать?
Далее, как сделать так, чтоб при падении одного бордера сервера доступа переключались на работающий, но если работают оба, то и нагружаться они должны примерно поровну? И тоже самое с серверами доступа? на всех серверах freebsd. смотрю в сторону carp, но не уверен, смогу ли я с помощью него все реализовать.
Заранее спасибо , сорри, что так много вопросов в одной теме.

вопрос не простой и вот так на раз два на форуме его не объяснить, попробую накидать "тезисы"

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

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

YaEvgen писал(а):стоит ли сейчас заморачиваться и получать статус LIR, или в этом нет необходимости, если мы пока будем тупиковой AS?

LIR и AS никак не взаимосвязаны. Статус LIR нужен для того, что бы ты мог самостоятельно выделять подсети (из выданного тебе блока) под своих абонентов и регистрировать их в БД RIPE, а так же LIR может выбивать и регистрировать PI адреса и ASки для своих клиентов.

YaEvgen писал(а):Правильно ли я понимаю, что лучше брать full-view от обоих uplink'ов?

да, т.к. без full-view не будет оптимальных маршрутов, да и с балансировкой исходящего трафика туго придется.

YaEvgen писал(а):анонсировать свои адреса полностью обоим uplink'ам?

ессно, нет анонсов - нет трафика

YaEvgen писал(а):между бордерами настраивать iBGP?

если ты хочешь получить оптимальные маршруты то да

YaEvgen писал(а):Далее, как сделать так, чтоб при падении одного бордера сервера доступа переключались на работающий, но если работают оба, то и нагружаться они должны примерно поровну?

в любом случае ровно поровну точно не будет никогда, хороший результат, очень хороший это 60/40.

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

а вот тут ты все же должен определиться со схемой, т.к. ты уже по сути сказал о двух вариантах:
1. CARP
Лично я не поднимал схем на CARP, потому не могу сказать ничего о стабильности работы данного метода.
В CARP есть возможность балансировки на основе MAC-адреса клиента, в случае балансировки "внизу" для BGP эти "клиенты" VPN-сервера (сервера доступа), а вот с "верхом" это уже не прокатит.
2. Динамическая маршрутизации между всеми серверами. Между BGP ходит iBGP, между BGP и VPN ходит OSPF.
В теории VPN серверам по OSPF анонсировать default gateway с одинаковой метрикой, в случае с cisco это как раз и вызовет балансировку, но тут фря и всплывет засада с 2мя default gateway в табле роутинга, а точнее что двух не будет, будет тока один.
Я как то давно, на тестовом стенде, сталкивался с этой проблемой и с "лёту" я её не решил, как обстоят с этим дела во фре 8.Х я честно не знаю, нуна читать. Т.е. по quagga ты будешь видеть что оба дефолта приехали, но по netstat -rn будешь видеть только один.
Есть пара механизмов как это вручную мона обойти, без динамики:
а) setfib
б) PBR (pf или ipfw с fwd и probe)

Далее, не надо забывать, что балансировать тебе придется ДВА типа трафика:
а) входящий трафик
б) исходящий трафик
т.к. обычно люди говорят "балансировка", но забывают о двух типах, да, в обоих случаях это трафик , но балансировать придется по разному, механизмы разные.

YaEvgen писал(а):резервирование в случае падении канала тогда будет само собой, а вот балансировку как сделать?

поверь мне и моему опыту, "само собой" оно будет не так как задумываешь ты, а так как получится
а вот что бы было как хочешь ты - придется попотеть и почитать доки
например в BGP с исходящим трафиком ты король и Бог, волен делать все что захочешь, все полностью в твоих руках, балансируй на основе route-map и приоритетов (loc-pref, weight)
а вот со входящим в твою AS трафиком не все так просто, вот несколько механизмов:
а) препенды своей AS
б) community для руления трафиком (если они есть у твоих апстримов)
в) дробление своей подсети на более мелкие части и разные анонсы своим апстримам (называется more specific, но это не желательный вариант, не всем провам это может понравится)

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

Мой совет:
Раздели свою задачу на две части:
1. "верх" - это BGP-сервера и апстримы
2. "низ" - это BGP-сервера и сервера доступа
и занимайся ими по отдельности, а не все сразу и начинай с "верха"