Балансировка двух провайдеров на основе BGP и EEM

[@Mystray]

Есть еще один очень простой, но очень действенный способ борьбы с localpref:
В оба аплинка анонсится агрегированный префикс, в качестве резерва, и в каждый аплинк дополнительно — соответствующий аплинку more-specific префикс. Таким образом, трафик практически всегда будет литься на more-specific анонс, а в случае падения — на оставшийся агрегированный.
Заодно исчезают игры с ивентами и прочими лишними сервисами, работает даже на самом простом софте/железе.
Единственное, что надо иметь более чем /24

[@kvinogradov]

Это не «еще один» способ. Я бы сказал, что это ОСНОВНОЙ способ и я упомянул его в статье, но наверное надо было описать его подробней. Вот только он, действительно, не работает при неудачной конфигурации подсетей, когда их нельзя сагрегировать.

[@Mystray]

Это да. Распишите, пожалуйста, подробнее. Статьи на хабре часто используются как готовый мануал на все случаи жизни :)
С другой стороны, основной способ из статьи, проверяющий состояние bgp neigbor, я считаю далеко не самым надежным в ситуации, когда у аплинка сессия с вами есть, а вот выше — уже проблемы. Хотя, конечно, последняя миля обычно более подвержена проблемам, чем ядро оператора.
С цисками я практически не работал, но, кажется, у них есть возможность проверять наличие/отсутствие во входящих анонсах конкретного префикса, и в зависимости от этого что-то делать? Такой вариант намного надежнее. Правда, работает только при получении FW (или хотя бы локальный ix + дефолт — распространенная схема для приземления bgp на L3 коммутатор с нерезиновой forwarding table).

[@ksg222]

Метод проверки наличия определённых префиксов и анонс маршрутов на основе наличия/отсутствия оных на Cisco есть — BGP Conditional Advertisement. Поэтому EEM не требуется.

Ещё один вариант влияния на маршрутизацию у вышестоящих провайдеров — BGP community.

[@Mystray]

В отличии от conditional/more-specific/eem, комьюнити, все-таки, совсем не универсальный метод т.к. опирается на возможности конкретного оператора. Хотя и, пожалуй, самый гибкий и многофункциональный. Он, скорее, идет в дополнение к остальным методам.

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

[@kvinogradov]

Conditional Advertisment — однозначно да. Надо описать. То что про него с заметке ни слова — косяк.

Community — в идеальном мире идеальных провайдеров. В реальности все весьма печально и гибкостью политика многих операторов не отличается.

[@Ovsiannikov]

Использование BGP при наличии двух каналов в Интернет для выборочного анонсирования
https://habrahabr.ru/post/150969/

[@DeeZ]

Почему сделано так

 action 14.0 if $_state eq "Up"
 action 15.0  set _status "UP"
 action 16.0 else
 action 17.0  set _status "DOWN"
 action 18.0  set _list "full-list"
 action 19.0 end
 action 20.0 syslog priority warnings msg "$_name now is $_status !"

А не так:

 action 14.0 if $_state eq "DOWN"
 action 18.0  set _list "full-list"
 action 19.0 end
 action 20.0 syslog priority warnings msg "$_name now is $_state !"

Есть какие то ньюансы работы с переменными или просто для красоты?

[@kvinogradov]

Для красоты. Из регулярного выражения _state может быть и «Down» и «reset». Приводим в сообщении к «DOWN». Унифицированное сообщение в syslog, что бы упростить жизнь дежурной смене, например.

[@MicCheck]

Возможно, я невнимательно прочитал, но ведь в таком решении при падении пирингового линка между ISP, пропадет связность части подсетей с ресурсами, доступными только через одного ISP?

[@kvinogradov]

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

[@MicCheck]

Я имел ввиду конкретно ваш пример. При использовании решения с EEM, которое вы описали, при пропадании линка между ISP апплет не сработает, т.к. оба пира для AS65000 будут живы, но при этом у ISP1 не будет информации о сети 172.16.9/24, а у ISP2 о двух других сетях. Соответсвенно 9-я подсеть не достучится до AS65100, а 7 и 8 до AS65110…
Вы правы, в большинстве случаев есть несколько стыков, но было бы интересно почитать про реализацию апплета, который бы предусматривал возможность возникновения таких ситуаций. Например, каким-то образом фиксировать пропадание анонсов с NH R1 и предпоследней AS 65002 в AS-PATH (для ISP1) и NH на R3 и предпоследняя AS 65001 для ISP2…
К сожалению, не знаком с ЕЕМ, поэтому не в курсе его возможностей. Но тема интересная, спасибо.

[@kvinogradov]

На EEM такое наверное можно сделать, но сложно. Для этого есть BGP Conditional Advertisment, который, конечно, надо описать в заметке (и на что мне уже указали выше). Там как раз можно написать route-map с анализом префиксов, next-hop для них и as-path, в зависимости от результата которого будут меняться анонсы. Конечно, для этого надо иметь от провайдера контрольный префикс. Т.е. вариант «берем только default» не прокатит. Возможно даже нужен full view.

[@ksg222]

Думаю, Default route вполне достаточен для реализации BGP Conditional Advertisment во многих инсталляциях. Конечно, предварительно стоит попробовать прояснить, кто в сети провайдера его инжектирует, чтобы понять его «качество».

[@Mystray]

default-route имеет смысл только на PE, если есть несколько full-view. В ядре оно не нужно: все, что есть в FW — пророутится куда надо, остальное — unreachable.
На цисках/кваггах даже есть neighbor xxx default-originate, такой дефолт в принципе существует только в виде абстрактоного BGP-анонса.
Хотя, наверное, технически правильнее организовать aggregate 0/0 с правильной политикой и именно его редистрибьютить (нет фул-вью — нет дефолта), но я не сталкивался с таким, обычно не заморачиваются и с раздают default-originate или static 0/0.

[@kvinogradov]

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

[@Kiseloff]

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

[@kvinogradov]

Можно. Но в этом случае нужно брать от провайдеров не только default, но и какие-то «контрольные» префиксы. А вот их адекватный выбор (что бы по ним можно было увидеть проблему у провайдера) задачка не типовая и сильно завязана на топологию провайдера.