BGP анонсы префикса

[Kabraksis]

Добрый день.

 

Имеется арендуемый блок адресов /24, на данный момент префикс анонсирует в рамках своей AS вышестоящий оператор связи.

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

 

Т.к. данный блок адресов активно используется (NAT/SAT и т.д. Компания занимается ритейлом, не оператор связи), большой простой связи делать нельзя, as maintainer предложил прописать дополнительный route-объект, чтобы в момент когда мы

сами начнем анонсировать наш префикс, переключение произошло быстро.

 

Собственно тут я не совсем понимаю след.вещи (увы, опыта в данном направлении нет):

1. Что произойдет, когда я начну анонсировать наш префикс не предупредив об этом оператора связи который на данный момент его анонсирует?

2. Если AS maintainer уберет route-объект у нашего префикса с AS вышестоящего оператора (наша приобретенная AS само собой будет прописана), как быстро наш префикс станет доступен?

3. Может быть есть какой-то еще вариант быстрой миграции нашего префикса с AS вышестоящего оператора на нашу собственную?

 

Спасибо.

[s.lobanov]

1. будет конкуренция между вашим и чужим анонсом (если ваш анонс примет оператор и если он распространится дальше)

2,3. у одного префикса может быть несколько route object в БД RIPE. делайтей 2 route object, предупреждайте аплинков которым будете анонсировать (если фильтры не автоматические в вашу сторону) и анонсируйте на следующий день префикс уже от своей AS

[Kabraksis]

On 10/19/2020 at 5:45 PM, s.lobanov said:

1. будет конкуренция между вашим и чужим анонсом (если ваш анонс примет оператор и если он распространится дальше)

2,3. у одного префикса может быть несколько route object в БД RIPE. делайтей 2 route object, предупреждайте аплинков которым будете анонсировать (если фильтры не автоматические в вашу сторону) и анонсируйте на следующий день префикс уже от своей AS

Добрый день.

А почему на следующий день?

Допустим, as maintainer сделает сейчас второй route object. Я уже настроил стык с обоими аплинками. Далее говорю опаретору, который сейчас анонсит наш префикс, типа "прекращай, мы его начинаем анонсить". Он прекращает, я настраиваю анонс нашего префикса. 

В такой схеме сразу заведется анонс?

[passer]

Если договоришься, да. Тут слишком многое от отношения технарей этих аплинков зависит.

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

Edited October 21, 2020 by passer

[s.lobanov]

В 21.10.2020 в 13:33, Kabraksis сказал:

Добрый день.

А почему на следующий день?

Допустим, as maintainer сделает сейчас второй route object. Я уже настроил стык с обоими аплинками. Далее говорю опаретору, который сейчас анонсит наш префикс, типа "прекращай, мы его начинаем анонсить". Он прекращает, я настраиваю анонс нашего префикса. 

В такой схеме сразу заведется анонс?

почему на следующий день ответили выше.

 

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

[Kabraksis]

10 hours ago, s.lobanov said:

почему на следующий день ответили выше.

 

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

1. Ну т.е. для минимизации простоя лучше делать это ближе к полуночи, чтобы после 12 все у всех обновилось?

 

2. Вопрос немного не по сабжу, но тоже в этом направлении:

У нас на другой площадке уже анонсится префикс еще 1, и все бы хорошо, только есть 1 проблема

У нас 2 аплинка (один 300 мбит, второй 20 мбит - резервный), и через второй аплинк as-path всегда ниже. Как следствие входящий трафик идет через него.

 

Пытался разрулить это при помощи as-path prepend, но почему-то при применеии этой политики на резервном аплинке перестает вообще трафик идти (причем bgp стык поднимается, маршруты я получаю)

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

Полагаю ктото вышестоящий фильтрует этот атрибут? И если это так, то какие могут быть альтернативы?

Не хотелось бы прибегать к IPSla и тупо гасить нейбора пока жив основной аплинк.

[MrNv]

@Kabraksis а резервный оператор кто? возможно они принимают анонс только с длиной as-path = 1

[passer]

2 часа назад, Kabraksis сказал:

мы чтото не так делаем

Если bgp на сервере, то проверьте, не забыли ли rp_filter выключить.

 

И хорошо бы посмотреть анонсы резервному аплинку у него и у вас.

Edited October 23, 2020 by passer

[Pinkbyte]

11 hours ago, Kabraksis said:

на резервном аплинке перестает вообще трафик идти (причем bgp стык поднимается, маршруты я получаю)

Как определили? Если направить трафик на непосредственно сети самого аплинка - куда пойдут ответы? А то может вы столько prepend-ов насовали, что резервный аплинк посчитал что "дешевле" отправить трафик вам через своих аплинков, нежели непосредственно стык с вами.

 

Для решения этой проблемы можно воспользовать conditional advertising, ну это если у вас железо умеет. Если бы блок был больше /24 - то можно было бы поплясать с more specific в комбинации с no-export/no-advertise - но тут явно не ваш случай, с одним блоком /24 такие пляски невозможны.

 

Если резервный аплинк поддерживает community - крутите их. Если нет - тогда технических вариантов у вас по факту нет. Ну или договориться чтобы  маршруты от вашей AS на непосредственном стыке с вами принимали с большим localpref