Pull to refresh

Comments 18

Есть еще один очень простой, но очень действенный способ борьбы с localpref:
В оба аплинка анонсится агрегированный префикс, в качестве резерва, и в каждый аплинк дополнительно — соответствующий аплинку more-specific префикс. Таким образом, трафик практически всегда будет литься на more-specific анонс, а в случае падения — на оставшийся агрегированный.
Заодно исчезают игры с ивентами и прочими лишними сервисами, работает даже на самом простом софте/железе.
Единственное, что надо иметь более чем /24
Это не «еще один» способ. Я бы сказал, что это ОСНОВНОЙ способ и я упомянул его в статье, но наверное надо было описать его подробней. Вот только он, действительно, не работает при неудачной конфигурации подсетей, когда их нельзя сагрегировать.
Это да. Распишите, пожалуйста, подробнее. Статьи на хабре часто используются как готовый мануал на все случаи жизни :)
С другой стороны, основной способ из статьи, проверяющий состояние bgp neigbor, я считаю далеко не самым надежным в ситуации, когда у аплинка сессия с вами есть, а вот выше — уже проблемы. Хотя, конечно, последняя миля обычно более подвержена проблемам, чем ядро оператора.
С цисками я практически не работал, но, кажется, у них есть возможность проверять наличие/отсутствие во входящих анонсах конкретного префикса, и в зависимости от этого что-то делать? Такой вариант намного надежнее. Правда, работает только при получении FW (или хотя бы локальный ix + дефолт — распространенная схема для приземления bgp на L3 коммутатор с нерезиновой forwarding table).
Метод проверки наличия определённых префиксов и анонс маршрутов на основе наличия/отсутствия оных на Cisco есть — BGP Conditional Advertisement. Поэтому EEM не требуется.

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

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

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

Community — в идеальном мире идеальных провайдеров. В реальности все весьма печально и гибкостью политика многих операторов не отличается.
Почему сделано так
 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 !"


Есть какие то ньюансы работы с переменными или просто для красоты?
Для красоты. Из регулярного выражения _state может быть и «Down» и «reset». Приводим в сообщении к «DOWN». Унифицированное сообщение в syslog, что бы упростить жизнь дежурной смене, например.
Возможно, я невнимательно прочитал, но ведь в таком решении при падении пирингового линка между ISP, пропадет связность части подсетей с ресурсами, доступными только через одного ISP?
Как правило, провайдеры имеют несколько стыков между собой или с пиринговыми площадками. На схеме, поэтому, сделан пир межу ними. Так что связанность не пропадает.
Я имел ввиду конкретно ваш пример. При использовании решения с 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…
К сожалению, не знаком с ЕЕМ, поэтому не в курсе его возможностей. Но тема интересная, спасибо.
На EEM такое наверное можно сделать, но сложно. Для этого есть BGP Conditional Advertisment, который, конечно, надо описать в заметке (и на что мне уже указали выше). Там как раз можно написать route-map с анализом префиксов, next-hop для них и as-path, в зависимости от результата которого будут меняться анонсы. Конечно, для этого надо иметь от провайдера контрольный префикс. Т.е. вариант «берем только default» не прокатит. Возможно даже нужен full view.
Думаю, Default route вполне достаточен для реализации BGP Conditional Advertisment во многих инсталляциях. Конечно, предварительно стоит попробовать прояснить, кто в сети провайдера его инжектирует, чтобы понять его «качество».
default-route имеет смысл только на PE, если есть несколько full-view. В ядре оно не нужно: все, что есть в FW — пророутится куда надо, остальное — unreachable.
На цисках/кваггах даже есть neighbor xxx default-originate, такой дефолт в принципе существует только в виде абстрактоного BGP-анонса.
Хотя, наверное, технически правильнее организовать aggregate 0/0 с правильной политикой и именно его редистрибьютить (нет фул-вью — нет дефолта), но я не сталкивался с таким, обычно не заморачиваются и с раздают default-originate или static 0/0.
Как правило, провайдеры имеют несколько стыков между собой или с пиринговыми площадками. На схеме, поэтому, сделан пир межу ними. Так что связанность не пропадает.
Можно переделать сценарий EEM и выполнять переконфигурацию не по событию «появления записи в логе», а по событию «трэк определенного хоста (или набора хостов) в интернете». Это немного упрощает сценарий, и к тому же страхует от ситуации, когда проблема возникает на сети провайдера, а последняя миля в порядке.
Можно. Но в этом случае нужно брать от провайдеров не только default, но и какие-то «контрольные» префиксы. А вот их адекватный выбор (что бы по ним можно было увидеть проблему у провайдера) задачка не типовая и сильно завязана на топологию провайдера.
Sign up to leave a comment.

Articles