Comments 18
Есть еще один очень простой, но очень действенный способ борьбы с localpref:
В оба аплинка анонсится агрегированный префикс, в качестве резерва, и в каждый аплинк дополнительно — соответствующий аплинку more-specific префикс. Таким образом, трафик практически всегда будет литься на more-specific анонс, а в случае падения — на оставшийся агрегированный.
Заодно исчезают игры с ивентами и прочими лишними сервисами, работает даже на самом простом софте/железе.
Единственное, что надо иметь более чем /24
В оба аплинка анонсится агрегированный префикс, в качестве резерва, и в каждый аплинк дополнительно — соответствующий аплинку more-specific префикс. Таким образом, трафик практически всегда будет литься на more-specific анонс, а в случае падения — на оставшийся агрегированный.
Заодно исчезают игры с ивентами и прочими лишними сервисами, работает даже на самом простом софте/железе.
Единственное, что надо иметь более чем /24
0
Это не «еще один» способ. Я бы сказал, что это ОСНОВНОЙ способ и я упомянул его в статье, но наверное надо было описать его подробней. Вот только он, действительно, не работает при неудачной конфигурации подсетей, когда их нельзя сагрегировать.
0
Это да. Распишите, пожалуйста, подробнее. Статьи на хабре часто используются как готовый мануал на все случаи жизни :)
С другой стороны, основной способ из статьи, проверяющий состояние bgp neigbor, я считаю далеко не самым надежным в ситуации, когда у аплинка сессия с вами есть, а вот выше — уже проблемы. Хотя, конечно, последняя миля обычно более подвержена проблемам, чем ядро оператора.
С цисками я практически не работал, но, кажется, у них есть возможность проверять наличие/отсутствие во входящих анонсах конкретного префикса, и в зависимости от этого что-то делать? Такой вариант намного надежнее. Правда, работает только при получении FW (или хотя бы локальный ix + дефолт — распространенная схема для приземления bgp на L3 коммутатор с нерезиновой forwarding table).
С другой стороны, основной способ из статьи, проверяющий состояние bgp neigbor, я считаю далеко не самым надежным в ситуации, когда у аплинка сессия с вами есть, а вот выше — уже проблемы. Хотя, конечно, последняя миля обычно более подвержена проблемам, чем ядро оператора.
С цисками я практически не работал, но, кажется, у них есть возможность проверять наличие/отсутствие во входящих анонсах конкретного префикса, и в зависимости от этого что-то делать? Такой вариант намного надежнее. Правда, работает только при получении FW (или хотя бы локальный ix + дефолт — распространенная схема для приземления bgp на L3 коммутатор с нерезиновой forwarding table).
0
Метод проверки наличия определённых префиксов и анонс маршрутов на основе наличия/отсутствия оных на Cisco есть — BGP Conditional Advertisement. Поэтому EEM не требуется.
Ещё один вариант влияния на маршрутизацию у вышестоящих провайдеров — BGP community.
Ещё один вариант влияния на маршрутизацию у вышестоящих провайдеров — BGP community.
+1
В отличии от conditional/more-specific/eem, комьюнити, все-таки, совсем не универсальный метод т.к. опирается на возможности конкретного оператора. Хотя и, пожалуй, самый гибкий и многофункциональный. Он, скорее, идет в дополнение к остальным методам.
Далеко не у всех есть даже backup community с выставлением минимального localpref, обычно ограничиваются препендами на различные направления.
Далеко не у всех есть даже backup community с выставлением минимального localpref, обычно ограничиваются препендами на различные направления.
0
Conditional Advertisment — однозначно да. Надо описать. То что про него с заметке ни слова — косяк.
Community — в идеальном мире идеальных провайдеров. В реальности все весьма печально и гибкостью политика многих операторов не отличается.
Community — в идеальном мире идеальных провайдеров. В реальности все весьма печально и гибкостью политика многих операторов не отличается.
0
Использование BGP при наличии двух каналов в Интернет для выборочного анонсирования
https://habrahabr.ru/post/150969/
https://habrahabr.ru/post/150969/
0
Почему сделано так
А не так:
Есть какие то ньюансы работы с переменными или просто для красоты?
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 !"
Есть какие то ньюансы работы с переменными или просто для красоты?
0
Возможно, я невнимательно прочитал, но ведь в таком решении при падении пирингового линка между ISP, пропадет связность части подсетей с ресурсами, доступными только через одного ISP?
0
Как правило, провайдеры имеют несколько стыков между собой или с пиринговыми площадками. На схеме, поэтому, сделан пир межу ними. Так что связанность не пропадает.
0
Я имел ввиду конкретно ваш пример. При использовании решения с 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…
К сожалению, не знаком с ЕЕМ, поэтому не в курсе его возможностей. Но тема интересная, спасибо.
Вы правы, в большинстве случаев есть несколько стыков, но было бы интересно почитать про реализацию апплета, который бы предусматривал возможность возникновения таких ситуаций. Например, каким-то образом фиксировать пропадание анонсов с NH R1 и предпоследней AS 65002 в AS-PATH (для ISP1) и NH на R3 и предпоследняя AS 65001 для ISP2…
К сожалению, не знаком с ЕЕМ, поэтому не в курсе его возможностей. Но тема интересная, спасибо.
0
На EEM такое наверное можно сделать, но сложно. Для этого есть BGP Conditional Advertisment, который, конечно, надо описать в заметке (и на что мне уже указали выше). Там как раз можно написать route-map с анализом префиксов, next-hop для них и as-path, в зависимости от результата которого будут меняться анонсы. Конечно, для этого надо иметь от провайдера контрольный префикс. Т.е. вариант «берем только default» не прокатит. Возможно даже нужен full view.
0
Думаю, Default route вполне достаточен для реализации BGP Conditional Advertisment во многих инсталляциях. Конечно, предварительно стоит попробовать прояснить, кто в сети провайдера его инжектирует, чтобы понять его «качество».
0
default-route имеет смысл только на PE, если есть несколько full-view. В ядре оно не нужно: все, что есть в FW — пророутится куда надо, остальное — unreachable.
На цисках/кваггах даже есть neighbor xxx default-originate, такой дефолт в принципе существует только в виде абстрактоного BGP-анонса.
Хотя, наверное, технически правильнее организовать aggregate 0/0 с правильной политикой и именно его редистрибьютить (нет фул-вью — нет дефолта), но я не сталкивался с таким, обычно не заморачиваются и с раздают default-originate или static 0/0.
На цисках/кваггах даже есть neighbor xxx default-originate, такой дефолт в принципе существует только в виде абстрактоного BGP-анонса.
Хотя, наверное, технически правильнее организовать aggregate 0/0 с правильной политикой и именно его редистрибьютить (нет фул-вью — нет дефолта), но я не сталкивался с таким, обычно не заморачиваются и с раздают default-originate или static 0/0.
0
Как правило, провайдеры имеют несколько стыков между собой или с пиринговыми площадками. На схеме, поэтому, сделан пир межу ними. Так что связанность не пропадает.
0
Можно переделать сценарий EEM и выполнять переконфигурацию не по событию «появления записи в логе», а по событию «трэк определенного хоста (или набора хостов) в интернете». Это немного упрощает сценарий, и к тому же страхует от ситуации, когда проблема возникает на сети провайдера, а последняя миля в порядке.
+1
Sign up to leave a comment.
Балансировка двух провайдеров на основе BGP и EEM