Всем доброго времени суток. Есть такая ситуация:
организация примерно 70 человек, 2 канала в интернет, основной 10мбит/c и резервный 1 Мбит/c. Есть несколько опубликованных сервисов, которые видны снаружи, например OWA. На основном канале адресация x.x.x.x /30, на резервном - y.y.y.y /30. Вопрос заключается в том, чтобы обеспечить каким-то образом прозрачную отказоустойчивость опубликованных сервисов, ну и выхода в интернет заодно (хотя это уже задача второстепенной важности). То есть другими словами, если основной канал падает, надо чтобы незаметно для пользователей происходило автоматическое переключение на резервный канал и все сервисы, вытащенные наружу, оставались видны с теми же параметрами (ip-адрес, порт). Как я понимаю, таким функционалом обладает протокол BGP, я позвонил нашему провайдеру и они подтвердили что у них можно купить сервис BGP, поставить на нашей площадке циску, в которую воткнуть оба канала и LAN, настроить BGP и якобы все в шоколаде. У нас есть Cisco 1841 с 3-мя маршрутизируемыми интерфейсами. Вот не подскажет ли мне кто-нибудь, а верно ли я вообще все это себе представляю? Будет такая схема работать? Если да, то приведите, пожалуйста, пример конфига в моем случае, или дайте ссылки, где можно толково почитать про основы BGP и его использование для решения задач отказоустойчивости с прозрачным переносом сервисов. В дополнение, привожу 3 вопроса от технарей нашего провайдера, это, как мне сказали, необходимо им для настройки BGP со своей стороны. Я в этом протоколе пока не смог разобраться в достаточной степени, чтобы понять даже значение некоторых терминов, просьба знающих людей объяснить, чтоимеется ввиду и посоветовать что-то почитать. Вопросы:
1. Номер Вашей AS. (Это понятно, что такое и зачем нужно, только не ясно, надо ли нам эту AS Где-то регистрировать или нет? Я имею ввиду по типу выделения блока реальных ip-адресов, там ведь надо заявку писать специальную и т.д., а здесь есть какая-то такая процедура?
2. Что Вы будете нам посылать? (что будете транслировать, если что-то кроме своей AS, то просьба указать AS macro),
3. Что Вы хотите получать от нас:
- всю таблицу маршрутизации,
- AS sovam,
- ничего,
- все+default.Заранее огромное спасибо за помощь, самому разобраться в сжатые сроки в BGP, не имея возможности тестировать что-либо в боевых условиях, не представляется возможным, выручайте :))
делаете 2 дефолтных маршрута с разной метрикой и всё.
> 2. Что Вы будете нам посылать? (что будете транслировать, если что-то кроме
> своей AS, то просьба указать AS macro),они запрашивают номер вашей AS или as-set, чтобы можно было по нему строить фильтр префиксов, например тем же bgpq
> 3. Что Вы хотите получать от нас:
> - всю таблицу маршрутизации,или full-view, есле вы не транзитер , то оно вам скорее не надо.
> - AS sovam,я так понял предлагают сети голдена.
> - ничего,тут добавить нечего
> - все+default.маршрут по умолчанию 0.0.0.0/0
В вашем случае нужно будет установить два пиринга с вашими провайдерами. Обеим анонсировать свой блок PI. От провайдеров получать default.
В простейшем случаее препендами (prepend) сделат канал 1M/s бекапным (в этот канала анонсить например с 3 препендами свой префикс).
> Заранее огромное спасибо за помощь, самому разобраться в сжатые сроки в BGP,
> не имея возможности тестировать что-либо в боевых условиях, не представляется возможным,
> выручайте :))
>[оверквотинг удален]
> тут добавить нечего
>> - все+default.
> маршрут по умолчанию 0.0.0.0/0
> В вашем случае нужно будет установить два пиринга с вашими провайдерами. Обеим
> анонсировать свой блок PI. От провайдеров получать default.
> В простейшем случаее препендами (prepend) сделат канал 1M/s бекапным (в этот канала
> анонсить например с 3 препендами свой префикс).
>> Заранее огромное спасибо за помощь, самому разобраться в сжатые сроки в BGP,
>> не имея возможности тестировать что-либо в боевых условиях, не представляется возможным,
>> выручайте :))благодарю за ответ, правда сильно яснее пока не стало :)
Провайдер один - Совинтел, оба канала идут от него, но имеют абсолютно разные блоки реальных адресов и, судя по всему, маршрутизируются через разные МЕН-узлы, так как при падении основного канала (авария у Совинтела), радиоканал продолжает работать (проверяли несколько раз), именно это и дает надежду его использовать для отказоустойчивости.
Из Ваших разъяснений я так понял, что нам не нужно ни full-view, ни sovam, только default. Все ли верно я понял: устанавливаются neighbor-отношения со шлюзами на каждом из каналов, затем prepend-ами (я не знаю пока, что это такое) указывается, что 1Мбит/с - резервный (большая метрика у маршрута??), 10Мбит/c - основной. Каким-то образом анонсируется блок адресов основного канала, на которм опубликованы внешние сервисы (вот здесь тоже не понятно, как это все выглядит). Далее, если основной канал падает, наш блок адресов основного канала остается доступен через резервный, так как автоматически меняется таблица маршрутизации. Я все верно понимаю? Не приведете пример необходимого блока команд, хотя бы без полного синтаксиса, просто каркас, чтобы я на циске смог посмотреть и поискать информацию в интернете?? Спасибо Вам огромное за помощь!!
У вас на вашей циске уже настроен какой нить протокол маршрутизации ???
Либо статикой настройте
ip route 0.0.0.0 0.0.0.0 x.x.x.x 1
ip route 0.0.0.0 0.0.0.0 y.y.y.y 10
при падении одного линка, будет работать другой линк.
но такая настройка может порождать некоторые проблемы.
> У вас на вашей циске уже настроен какой нить протокол маршрутизации ???
> Либо статикой настройте
> ip route 0.0.0.0 0.0.0.0 x.x.x.x 1
> ip route 0.0.0.0 0.0.0.0 y.y.y.y 10
> при падении одного линка, будет работать другой линк.
> но такая настройка может порождать некоторые проблемы.Мне кажется (поправьте, если ошибаюсь), что такая схема позволяет зарезервировать только интернет канал, что для нас является второстепенной задачей. Намного более важно для нас иметь отказоустойчивость по опубликованным в интернет сервисам. То есть чтобы при падении основного канала связи, доступные извне сервисы оставались доступными по тому же ip-адресу и порту. Насколько я понимаю, это требует более сложной настройки, чем просто 2 дефолтных маршрута с разной метрикой.
>[оверквотинг удален]
> со шлюзами на каждом из каналов, затем prepend-ами (я не знаю
> пока, что это такое) указывается, что 1Мбит/с - резервный (большая метрика
> у маршрута??), 10Мбит/c - основной. Каким-то образом анонсируется блок адресов основного
> канала, на которм опубликованы внешние сервисы (вот здесь тоже не понятно,
> как это все выглядит). Далее, если основной канал падает, наш блок
> адресов основного канала остается доступен через резервный, так как автоматически меняется
> таблица маршрутизации. Я все верно понимаю? Не приведете пример необходимого блока
> команд, хотя бы без полного синтаксиса, просто каркас, чтобы я на
> циске смог посмотреть и поискать информацию в интернете?? Спасибо Вам огромное
> за помощь!!уже много раз писали на этом форуме про ip sla и track на маршрутизаторах. Мне кажется, без этого ни одна откзоустойчивая схема при маршрутизации не обойдется. По поводу номер AS - ее действительно надо регистрировать, так как приватная AS не будет транслироваться в интернете.
>[оверквотинг удален]
>> как это все выглядит). Далее, если основной канал падает, наш блок
>> адресов основного канала остается доступен через резервный, так как автоматически меняется
>> таблица маршрутизации. Я все верно понимаю? Не приведете пример необходимого блока
>> команд, хотя бы без полного синтаксиса, просто каркас, чтобы я на
>> циске смог посмотреть и поискать информацию в интернете?? Спасибо Вам огромное
>> за помощь!!
> уже много раз писали на этом форуме про ip sla и track
> на маршрутизаторах. Мне кажется, без этого ни одна откзоустойчивая схема при
> маршрутизации не обойдется. По поводу номер AS - ее действительно надо
> регистрировать, так как приватная AS не будет транслироваться в интернете.ip sla это конечно хорошо, но опять же, насколько я знаю, не позволяет резервировать опубликованные сервисы прозрачно.
>[оверквотинг удален]
>>> таблица маршрутизации. Я все верно понимаю? Не приведете пример необходимого блока
>>> команд, хотя бы без полного синтаксиса, просто каркас, чтобы я на
>>> циске смог посмотреть и поискать информацию в интернете?? Спасибо Вам огромное
>>> за помощь!!
>> уже много раз писали на этом форуме про ip sla и track
>> на маршрутизаторах. Мне кажется, без этого ни одна откзоустойчивая схема при
>> маршрутизации не обойдется. По поводу номер AS - ее действительно надо
>> регистрировать, так как приватная AS не будет транслироваться в интернете.
> ip sla это конечно хорошо, но опять же, насколько я знаю, не
> позволяет резервировать опубликованные сервисы прозрачно.не будет работать не ip sla и track
не разные метрики на маршрутах по-умолчанию.
два адресного пространства, каждое адресное пространство жестко закреплено за своим каналом на стороне совинтел.
например, "падает" основной канал, весь трафик от обоих адресных пространств будет исходить с "резервного" канала, но ответы со стороны провайдера вернутся только на адресное пространство, закрепленное за "резервным" каналом.
если динмически изменится нат для внутренних адресов в адреса "резервного" канала, то резервирование пройдет.
а вот сервисы, висящие на внешних адресах основного канала ждет ситуация, описанная выше.попробовать договориться с голдентелекомом, настраивать в качестве AS с фейковым номером, но не помню чтобы они на такое пошли.
>[оверквотинг удален]
> на стороне совинтел.
> например, "падает" основной канал, весь трафик от обоих адресных пространств будет исходить
> с "резервного" канала, но ответы со стороны провайдера вернутся только на
> адресное пространство, закрепленное за "резервным" каналом.
> если динмически изменится нат для внутренних адресов в адреса "резервного" канала, то
> резервирование пройдет.
> а вот сервисы, висящие на внешних адресах основного канала ждет ситуация, описанная
> выше.
> попробовать договориться с голдентелекомом, настраивать в качестве AS с фейковым номером,
> но не помню чтобы они на такое пошли.Если оба канала из-под одной AS-ки - то можно пообщаться с провайдером.
>[оверквотинг удален]
>> с "резервного" канала, но ответы со стороны провайдера вернутся только на
>> адресное пространство, закрепленное за "резервным" каналом.
>> если динмически изменится нат для внутренних адресов в адреса "резервного" канала, то
>> резервирование пройдет.
>> а вот сервисы, висящие на внешних адресах основного канала ждет ситуация, описанная
>> выше.
>> попробовать договориться с голдентелекомом, настраивать в качестве AS с фейковым номером,
>> но не помню чтобы они на такое пошли.
> Если оба канала из-под одной AS-ки - то можно пообщаться с
> провайдером.Оба канала от одного провайдера, хотя адресные пространства абсолютно разные, как я писал выше. Что конкретно мне необходимо обсудить с провадером, чтобы точно понять - будет ли BGP работать так, как нам надо, или нет?
>[оверквотинг удален]
> на стороне совинтел.
> например, "падает" основной канал, весь трафик от обоих адресных пространств будет исходить
> с "резервного" канала, но ответы со стороны провайдера вернутся только на
> адресное пространство, закрепленное за "резервным" каналом.
> если динмически изменится нат для внутренних адресов в адреса "резервного" канала, то
> резервирование пройдет.
> а вот сервисы, висящие на внешних адресах основного канала ждет ситуация, описанная
> выше.
> попробовать договориться с голдентелекомом, настраивать в качестве AS с фейковым номером,
> но не помню чтобы они на такое пошли.То есть правильно ли я вас понял, что тут все зависит от Совинтела? Я с ними разговаривал и описывал им детально задачу, делал акцент на то, что нам нужно именно опубликованные сервисы в первую очередб резервировать, они сказали, что все реально через BGP сделать? Не подскажете чуть более детально, что нужно с их стороны настроить и с нашей, чтобы это работало?
>[оверквотинг удален]
>> а вот сервисы, висящие на внешних адресах основного канала ждет ситуация, описанная
>> выше.
>> попробовать договориться с голдентелекомом, настраивать в качестве AS с фейковым номером,
>> но не помню чтобы они на такое пошли.
> То есть правильно ли я вас понял, что тут все зависит от
> Совинтела? Я с ними разговаривал и описывал им детально задачу, делал
> акцент на то, что нам нужно именно опубликованные сервисы в первую
> очередб резервировать, они сказали, что все реально через BGP сделать? Не
> подскажете чуть более детально, что нужно с их стороны настроить и
> с нашей, чтобы это работало?А Вы говорили им, что у Вас нет автономной системы?
>[оверквотинг удален]
>>> выше.
>>> попробовать договориться с голдентелекомом, настраивать в качестве AS с фейковым номером,
>>> но не помню чтобы они на такое пошли.
>> То есть правильно ли я вас понял, что тут все зависит от
>> Совинтела? Я с ними разговаривал и описывал им детально задачу, делал
>> акцент на то, что нам нужно именно опубликованные сервисы в первую
>> очередб резервировать, они сказали, что все реально через BGP сделать? Не
>> подскажете чуть более детально, что нужно с их стороны настроить и
>> с нашей, чтобы это работало?
> А Вы говорили им, что у Вас нет автономной системы?Нет, но мы с ними давно работаем уже, они предоставляют нам кучу сервисов еще помимо интернета и их менеджеры знают, как организована наша сеть, что у нас нет и не было никогда зарегистрированной AS... А это существенно? Советуете переспросить у них, поможет ли нам BGP, явно указав при этом на отсутствие у нас зарегистрированной AS?
>[оверквотинг удален]
>>> акцент на то, что нам нужно именно опубликованные сервисы в первую
>>> очередб резервировать, они сказали, что все реально через BGP сделать? Не
>>> подскажете чуть более детально, что нужно с их стороны настроить и
>>> с нашей, чтобы это работало?
>> А Вы говорили им, что у Вас нет автономной системы?
> Нет, но мы с ними давно работаем уже, они предоставляют нам кучу
> сервисов еще помимо интернета и их менеджеры знают, как организована наша
> сеть, что у нас нет и не было никогда зарегистрированной AS...
> А это существенно? Советуете переспросить у них, поможет ли нам BGP,
> явно указав при этом на отсутствие у нас зарегистрированной AS?Переспросите.
>[оверквотинг удален]
>>>> очередб резервировать, они сказали, что все реально через BGP сделать? Не
>>>> подскажете чуть более детально, что нужно с их стороны настроить и
>>>> с нашей, чтобы это работало?
>>> А Вы говорили им, что у Вас нет автономной системы?
>> Нет, но мы с ними давно работаем уже, они предоставляют нам кучу
>> сервисов еще помимо интернета и их менеджеры знают, как организована наша
>> сеть, что у нас нет и не было никогда зарегистрированной AS...
>> А это существенно? Советуете переспросить у них, поможет ли нам BGP,
>> явно указав при этом на отсутствие у нас зарегистрированной AS?
> Переспросите.у нас очень похожая ситуация
> у нас очень похожая ситуацияпопросите сделать вам мультихом подключение. например по bgp с private AS.
1. Имеем две интерфейсные пары /30
2. Строим пиринг с remote AS111
3. анонсим свой префикс на которых работают ваши сервисы 22.22.22.0/26
4. Принимаем маршрут по умолчанию с 10mbit канала и вешаем на него local_pref 200
на втором будет дефотлтное значение 100Со своей стороны провайдер вешает community no-advertise, чтобы не нарушать свою внутренню полиси маршрутизации.
5. Убираем статику на маршрутизаторе
итого имеем резервирование на L3 уровне.
>[оверквотинг удален]
> 1. Имеем две интерфейсные пары /30
> 2. Строим пиринг с remote AS111
> 3. анонсим свой префикс на которых работают ваши сервисы 22.22.22.0/26
> 4. Принимаем маршрут по умолчанию с 10mbit канала и вешаем на него
> local_pref 200
> на втором будет дефотлтное значение 100
> Со своей стороны провайдер вешает community no-advertise, чтобы не нарушать свою внутренню
> полиси маршрутизации.
> 5. Убираем статику на маршрутизаторе
> итого имеем резервирование на L3 уровне.в том и вопрос будет ли провайдер работать с private AS
>[оверквотинг удален]
> 1. Имеем две интерфейсные пары /30
> 2. Строим пиринг с remote AS111
> 3. анонсим свой префикс на которых работают ваши сервисы 22.22.22.0/26
> 4. Принимаем маршрут по умолчанию с 10mbit канала и вешаем на него
> local_pref 200
> на втором будет дефотлтное значение 100
> Со своей стороны провайдер вешает community no-advertise, чтобы не нарушать свою внутренню
> полиси маршрутизации.
> 5. Убираем статику на маршрутизаторе
> итого имеем резервирование на L3 уровне.Вот, теперь стало более менее ясно. По крайней мере, есть алгоритм действий :) Буду стараться связаться с нашим менеджером у провайдера, чтобы уточнить, будут ли они работать с private as. Всем огромное спасибо за помощь, вернусь в тему, когда получу подтверждение провайдера.
>[оверквотинг удален]
>> local_pref 200
>> на втором будет дефотлтное значение 100
>> Со своей стороны провайдер вешает community no-advertise, чтобы не нарушать свою внутренню
>> полиси маршрутизации.
>> 5. Убираем статику на маршрутизаторе
>> итого имеем резервирование на L3 уровне.
> Вот, теперь стало более менее ясно. По крайней мере, есть алгоритм действий
> :) Буду стараться связаться с нашим менеджером у провайдера, чтобы уточнить,
> будут ли они работать с private as. Всем огромное спасибо за
> помощь, вернусь в тему, когда получу подтверждение провайдера.Да да, вернись, есть подобные вопросы.
>[оверквотинг удален]
> 1. Имеем две интерфейсные пары /30
> 2. Строим пиринг с remote AS111
> 3. анонсим свой префикс на которых работают ваши сервисы 22.22.22.0/26
> 4. Принимаем маршрут по умолчанию с 10mbit канала и вешаем на него
> local_pref 200
> на втором будет дефотлтное значение 100
> Со своей стороны провайдер вешает community no-advertise, чтобы не нарушать свою внутренню
> полиси маршрутизации.
> 5. Убираем статику на маршрутизаторе
> итого имеем резервирование на L3 уровне.Den
А если немного изменить за дачу.
Два канала на одного провайдера.
Сейчас за каждым каналом закреплены свои подсети. Если хочется, чтобы подсеть стала доступна с другого канала пишем заявку на смену маршуртизации провайдеру.
Как сделать так чтобы настроив у себя BGP, это делалось автоматически.
Как бы "сказать" при помощи BGP провайдеру, что такая-то подсеть доступна теперь через такой-то канал, а в случае падения канала, доступна через другой канал.
>[оверквотинг удален]
>> итого имеем резервирование на L3 уровне.
> Den
> А если немного изменить за дачу.
> Два канала на одного провайдера.
> Сейчас за каждым каналом закреплены свои подсети. Если хочется, чтобы подсеть стала
> доступна с другого канала пишем заявку на смену маршуртизации провайдеру.
> Как сделать так чтобы настроив у себя BGP, это делалось автоматически.
> Как бы "сказать" при помощи BGP провайдеру, что такая-то подсеть доступна теперь
> через такой-то канал, а в случае падения канала, доступна через другой
> канал.Вы вообще с BGP знакомы?
У BGP есть иерархия параметров при принятии решения о выборе того или иного пути, одними параметрами вы можете управлять, другими - нет.
Кроме того есть равила ip маршрутизации.
>[оверквотинг удален]
>> Сейчас за каждым каналом закреплены свои подсети. Если хочется, чтобы подсеть стала
>> доступна с другого канала пишем заявку на смену маршуртизации провайдеру.
>> Как сделать так чтобы настроив у себя BGP, это делалось автоматически.
>> Как бы "сказать" при помощи BGP провайдеру, что такая-то подсеть доступна теперь
>> через такой-то канал, а в случае падения канала, доступна через другой
>> канал.
> Вы вообще с BGP знакомы?
> У BGP есть иерархия параметров при принятии решения о выборе того или
> иного пути, одними параметрами вы можете управлять, другими - нет.
> Кроме того есть равила ip маршрутизации.то есть задача не решабельна?
>[оверквотинг удален]
>>> доступна с другого канала пишем заявку на смену маршуртизации провайдеру.
>>> Как сделать так чтобы настроив у себя BGP, это делалось автоматически.
>>> Как бы "сказать" при помощи BGP провайдеру, что такая-то подсеть доступна теперь
>>> через такой-то канал, а в случае падения канала, доступна через другой
>>> канал.
>> Вы вообще с BGP знакомы?
>> У BGP есть иерархия параметров при принятии решения о выборе того или
>> иного пути, одними параметрами вы можете управлять, другими - нет.
>> Кроме того есть равила ip маршрутизации.
> то есть задача не решабельна?У вас уже настроено взаимодействие по BGP с провайдером?
Если нет - то не решабельна, т.к. нет собственно задачи.
Если да - то вы хотя бы обзорно настройку BGP разбирали????
>[оверквотинг удален]
>>>> через такой-то канал, а в случае падения канала, доступна через другой
>>>> канал.
>>> Вы вообще с BGP знакомы?
>>> У BGP есть иерархия параметров при принятии решения о выборе того или
>>> иного пути, одними параметрами вы можете управлять, другими - нет.
>>> Кроме того есть равила ip маршрутизации.
>> то есть задача не решабельна?
> У вас уже настроено взаимодействие по BGP с провайдером?
> Если нет - то не решабельна, т.к. нет собственно задачи.
> Если да - то вы хотя бы обзорно настройку BGP разбирали????Нет не настроено.
А чем вышеописанное не задача?
>[оверквотинг удален]
>>>> Вы вообще с BGP знакомы?
>>>> У BGP есть иерархия параметров при принятии решения о выборе того или
>>>> иного пути, одними параметрами вы можете управлять, другими - нет.
>>>> Кроме того есть равила ip маршрутизации.
>>> то есть задача не решабельна?
>> У вас уже настроено взаимодействие по BGP с провайдером?
>> Если нет - то не решабельна, т.к. нет собственно задачи.
>> Если да - то вы хотя бы обзорно настройку BGP разбирали????
> Нет не настроено.
> А чем вышеописанное не задача?Слишком абстрактно...
Допустим все настроили и работает, сеть А при нормальных условиях "ходит" через канал 1, теперь вы решили, что основным каналом будет канал 2.
При определенной политике со строны провайдера вы НИКАКИМИ средствами это не реализуете БЕЗ согласования с провайдером, хотя если линк по каналу 1 пропадет - все побежит через канал 2."Как бы "сказать" при помощи BGP провайдеру, что такая-то подсеть доступна теперь через такой-то канал, а в случае падения канала, доступна через другой... "
вопрос вообще непонятно зачем заданый, задача протоколов динамической маршрутизации (а BGP-один из таковых) именно в этом и состоит.
>[оверквотинг удален]
>> А чем вышеописанное не задача?
> Слишком абстрактно...
> Допустим все настроили и работает, сеть А при нормальных условиях "ходит" через
> канал 1, теперь вы решили, что основным каналом будет канал 2.
> При определенной политике со строны провайдера вы НИКАКИМИ средствами это не реализуете
> БЕЗ согласования с провайдером, хотя если линк по каналу 1
> пропадет - все побежит через канал 2.
> "Как бы "сказать" при помощи BGP провайдеру, что такая-то подсеть доступна теперь
> через такой-то канал, а в случае падения канала, доступна через другой...
> "Это было разъяснение, что хотим получить.
> вопрос вообще непонятно зачем заданый, задача протоколов динамической маршрутизации (а
> BGP-один из таковых) именно в этом и состоит.Может BGP такого не может сделать.
>> "Как бы "сказать" при помощи BGP провайдеру, что такая-то подсеть доступна теперь
>> через такой-то канал, а в случае падения канала, доступна через другой..."Технически задача решаемая, но врядли апстрим будет под вас править bgp policy. Но если вы VIP клиент....
Способов вижу 2, все требуют поддержки провайдера
1. С помощью MED
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note...
2. С помощью коммунити. Выставляя определенный коммунити на анонсируемый префикс на стороне провайдера будет повышаться local_pref, тем самымВ обеих случаях анонсить ваши две сети с сервисами.
>>> "Как бы "сказать" при помощи BGP провайдеру, что такая-то подсеть доступна теперь
>>> через такой-то канал, а в случае падения канала, доступна через другой..."
> Технически задача решаемая, но врядли апстрим будет под вас править bgp policy.
> Но если вы VIP клиент....
> Способов вижу 2, все требуют поддержки провайдера
> 1. С помощью MED
> http://www.cisco.com/en/US/tech/tk365/technologies_tech_note...
> 2. С помощью коммунити. Выставляя определенный коммунити на анонсируемый префикс на стороне
> провайдера будет повышаться local_pref, тем самым
> В обеих случаях анонсить ваши две сети с сервисами.3. если сети суммируются - в один канал сумму + 1 подсеть в каждый канал.
4. если договориться с провом - на один канал больший локал-преф
5. AS-пафом....
>[оверквотинг удален]
>> Способов вижу 2, все требуют поддержки провайдера
>> 1. С помощью MED
>> http://www.cisco.com/en/US/tech/tk365/technologies_tech_note...
>> 2. С помощью коммунити. Выставляя определенный коммунити на анонсируемый префикс на стороне
>> провайдера будет повышаться local_pref, тем самым
>> В обеих случаях анонсить ваши две сети с сервисами.
> 3. если сети суммируются - в один канал сумму + 1 подсеть
> в каждый канал.
> 4. если договориться с провом - на один канал больший локал-преф
> 5. AS-пафом....Ага, а еще можно сделать через DNS. У них на фирме example.com = IP22.22.22.22 стоит apache-бокс, который периодически отваливается, ибо ломается связь до прова. А нужно чтобы веб-любители всегда смогли достичь эту апаче-коробку. По IP адресу явно не достигнут, ибо фирме нужна своя AS, собственный CIDR-блок==префикс + BGP-based external(exterior?) gateway(s). Но ведь есть же DNS! И все нормальные люди ею пользуются. Вбив на один ресурс www.example.com сразу несколько IP, получим балансировку понимаешь. В обычном случае траф на апачебокс траф будет идти сразу с двух направлений. При отваливании одного из них, ну что ж, только на 1. ХитрО, а?