[killonik]

Всем доброго дня.

Имеем подключение к нескольким IX и нескольким FV. Сейчас все они подключены к одному бордеру, который в данный момент и собираемся резервировать. Этот бордер отдаёт дефолт нескольким НАТ на LINUX и одному Extreme x670, через который бегают абоненты с внешними IP.

 

Очевидно, что для полноценного резервирования, аплинков надо поделить между существующим бордером и новым так, чтобы к каждому были подключены и IX и FV. В идеале получить от каждого провайдера адрес для резервного BGP. Чтобы схема выглядела так:

 

 

Но до этого момента ещё далеко и провайдеры если и выдадут дополнительный адрес, то не все и не сразу. Поэтому пока думаем поделить провайдеров между бордерами как было сказано выше, но сразу видим проблемку: НАТы легко получат FV от обоих бордеров, а вот Extreme не потянет даже один FV. Получается что надо отдавать ему два дефолта с разным приоритетом и соединять бордеры между собой для того, чтобы трафик с Extreme мог дойти до IX подключенного к другому бордеру, а не в FV. Схема получается такая:

 

 

По-хорошему наверно надо с каждого бордера на Extreme отдать маршруты до IX(должны поместиться) c максимальным приоритетом, и два дефолта с разным приоритетом. Тогда не весь трафик от внешников будет ходить через один дефолтный BGP.

 

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

[myst]

Если отдаете только дефолт, настройте с бордеров 2 дефолта с разной метрикой, и докучи IP SLA.

Есть контакт - отдаем default-originate, нет - убираем.

 

Если хочется разного, можно вниз отдавать FV с одного бордера, а со второго отфильтровать, скажем по /20.

[killonik]

..можно вниз отдавать FV с одного бордера..

 

В том-то и проблема, что нельзя - Extreme не сможет принять FV, памяти не хватит.

Вот и думаем как лучше сделать:

 

• сливать маршруты до IX на Extreme + два дефолта
  
• просто два дефолта, а на бордерах друг с друга маршруты до IX
  

Склоняемся к второму варианту. В этом случае Extreme будет тихонечко гонять трафик по основному дефолту пока тот будет доступен, а управлять трафиком придётся только на бордерах.

[twh.mega]

Второй вариант, на мой взгляд, лучше. Меньше заморочек, удобней управлять.

[g3fox]

Может вообще на экстриме сделать статику через виртуальный адрес, а на бордерах сделать vrrp ?

Между бордерами также сделать и ibgp и рулить пирами/аплинками исключительно на бордерах.

[killonik]

Может вообще на экстриме сделать статику через виртуальный адрес, а на бордерах сделать vrrp ?

 

Интересное предложение. Сначала были сомнения потому, что Extreme должен получать по BGP ещё некоторые маршруты от неуказанного на схеме сервера.

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

[myst]

Может вообще на экстриме сделать статику через виртуальный адрес, а на бордерах сделать vrrp ?

 

Интересное предложение. Сначала были сомнения потому, что Extreme должен получать по BGP ещё некоторые маршруты от неуказанного на схеме сервера.

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

Зачем тут метрики есть статика дефолт?

Некоторые маршруты это явно более специфичные префиксы, так что метрики и прочие параметры тут уже рояля не играют.

[alexchip]

Собрали тестовый стенд где бордеры объединены по IBGP, а на NAT'ы и Extrime сливается DefaultGW с каждого бордера.

В итоге так как:

• Предпочтение отдается путям eBGP, а не путям iBGP.
  
• Только лучший путь помещается в таблицу маршрутизации и анонсируется BGP-соседям.
  

получается что трафик до одного и того же хоста будет уходить через разных аплинков (в зависимости от какого бордера NAT или Extreme выберет default).

 

Использовать "сервые" AS для соединения бордеров по EBGP тоже не катит: будет увеличиваться путь.

 

Как синхронизировать маршруты 2-х BGP серверов одной AS?

Или как отменить удлинение маршрутов между серыми AS если AS565333 разделить на две AS?

 

[g3fox]

На префиксы, которые получаете от IX ставьте localpref выше. localpref является транзитивным атрибутом, и будет передан на все ibgp-пиры.

Да и что-то вы с default намудрили. Что за куча сетей у вас отрисована? Вы как там собрались использовать VRRP?

[alexchip]

Да и что-то вы с default намудрили. Что за куча сетей у вас отрисована? Вы как там собрались использовать VRRP?

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

 

 

На префиксы, которые получаете от IX ставьте localpref выше. localpref является транзитивным атрибутом, и будет передан на все ibgp-пиры.

localpref нам не подходит так как перебивает AS Path length, а вот MED наверное решит нашу проблему, будем тестировать.

Спасибо.

[g3fox]

А "сливать дефолты" вы как хотите?

Так для вас важнее AS-Path или отдавать трафик через IX?

[alexchip]

А "сливать дефолты" вы как хотите?

По протоколу BGP опцией default-originate с каждого бордера на каждый NAT.

 

Так для вас важнее AS-Path или отдавать трафик через IX?

Стараемся как можно больше влить в IX и при этом не потерять в качестве. (т.е. если путь через FV идет через 5 AS, а путь через IX идет через 30 AS, то конечно лучше FV)

[alexchip]

Собрали тестовый стенд:

 

На нате с каждого бордера по bgp приняли дефолтный GW, лучшим стал от того бордера у которого был меньший router-id.

В случае падения бордера на который ведет приоритетный default gw умирает bgp-сессия с этим бордером и весь трафик уходит на резервный бордер.

Но так как параметр Hold был 180 секунд, то сессия умирала очень долго, а соответственно в течении примерно 3 минут не было интернета.

Решили уменьшить на NAT Hold и соответственно Keepalive для соседей в виде бордеров, получилось так:

• Hold — 15 секунд
  
• Keepalive — 5 секунд
  

Переход на резерв осуществляется в течении 15 секунд, что не может не радовать, но вот мучают вопросы:

• не слишком ли маленькое время было выбрано?
  
• можно ли сделать его ещё меньше?
  
• и какие проблемы в связи с этим могут возникнуть?
  

[myst]

1) Не маленькое, это обычный тюнинг bgp.

2) Я бы всетаки приоритет выбора GW сделал на основании метрики а не RID.

[g3fox]

Я, честно говоря, так и не увидел плюсов в вашей схеме перед схемой с VRRP.

А на маршруты, получаемые от IX я бы, всё же, ставил Localpref выше, возможно, комбинировал с AS-PATH листами.

[alexchip]

Я, честно говоря, так и не увидел плюсов в вашей схеме перед схемой с VRRP.

Дело в том что у нас 4 NAT сервера + 1 Extrime, поэтому скорее всего может потребоваться распределить нагрузку между двумя бордерами, а VRRP на сколько я понял позволяет гонять трафик только через один GW.

 

2) Я бы всетаки приоритет выбора GW сделал на основании метрики а не RID.

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

 

 

Благодарю за замечания.

[g3fox]

да, gw будет один

но ничего не мешает сделать несколько gw

 

... сам прочитал, понял, что написал херню. исправляюсь:

для пары интерфейсов виртуальный gw в один момент времени будет только один.

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

то есть для части устройств будет один gw, а для другой части - другой gw.

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

Изменено 20 августа, 2014 пользователем g3fox