Архив рубрики: BGP

BGP redistribute static

R1 выступает в качестве CE, R2 — PE, R3 удаленный (iBGP) PE, между R2 и R3 должен быть iBGP, а сам клиент в проде живет в VRF, но сейчас и так сойдет:

CE подключен к PE по eBGP, и анонсирует 0/0 в сторону PE. Анонсируем default от клиента через redistribute static:

Статика анонсируется в BGP:

R2 и R3 видят 0/0:

Далее клиент говорит, что он хочет чтобы наша PE (R2) анонсировала 0/0  в случае если его CE1 перестанет отдавать нам 0/0 , повторяем настройки сделанные на проде:

Настраиваем backup маршрут через R1, на случай если мы потеряем маршрут от BGP пира, AD=250, чтобы выигрывал у [ie]BGP (AD=20,200):

Никаких изменений в BGP таблице, т.к коробке нечего редистрибутить, статики нет в GRT:

Все работает ОК, далее клиент по какой-то причине перестает анонсировать 0/0  через BGP:

Ушел BGP маршрут, в GRT установился static, далее он появился в BGP ( weight 32768) а анонсируется другим пирам:

Со стороны R3 поменялся AS_PATH (« Local «):

Далее клиент снова начинает анонсировать 0/0 :

На данном этапе от него пришла заявка, что на удаленном сайте он не видит 0/0 от CE.

На R3 без изменений:

R2 не анонсирует eBGP маршрут полученный от R1 т.к он не является best, происходит это потому-что Weight у локально генерируемых маршрутов = 32768 и он выигрывает у [ie]BGP маршрутов (« Weight = 0 «).
Если попробовать уровнять Weight (установить отрицательный мы не можем), далее будет проверятся LP (он у нас будет одинаковый) и потом будут выигрывать локально генерируемые маршруты.

Попробуем в добавок сбросить LP:

Маршрут выбрался от R1:

Проверяем еще раз:

Генерируем 0/0 от R2:

Возвращаем:

Также можно на PE в сторону CE выставить максимальный Weight, чтобы всегда был приоритет у eBGP маршрута, но тем самым мы поломаем возможность клиенту самостоятельно управлять трафиком BGP атрибутами.

BGP UPDATE change

Проблема:

PE получала 0/0 от удаленного МР, в один неподходящий момент, данный маршрут пропал, тем самым полностью изолировав PE от сервиса, т.к. трафик замыкается в пределах локального МР, было принято решение безусловно анонсировать 0/0 пиру, тем самым трафик в пределах локального МР не зависит от наличия 0/0 из вне.

Изначально у меня была картина мира с «перерывом сервиса»:

  1. Настраиваем анонс 0/0 на нейбора
  2. Коробка отправляет BGP WITHDRAWN со «старым» NLRI
  3. Генерирует новый UPDATE с новыми атрибутами
  4. Пинго!

Но т.к. у нас NLRI не меняется, а меняются только атрибуты, то мы можем это сделать неявно, используя UPDATE просто с новыми атрибутами вариант (b)

RFC 4271

There are three methods by which a given BGP speaker can indicate that a route has been withdrawn from service:

a) the IP prefix that expresses the destination for a previously advertised route can be advertised in the WITHDRAWN ROUTES field in the UPDATE message, thus marking the associated route as being no longer available for use,
b) a replacement route with the same NLRI can be advertised, or
c) the BGP speaker connection can be closed, which implicitly removes all routes the pair of speakers had advertised to each other from service.

Changing the attribute(s) of a route is accomplished by advertising a replacement route. The replacement route carries new (changed) attributes and has the same address prefix as the original route.

В действительности коробки так и делают:

Генерируем 0/0 от удаленного МР (R1):

Смотрим исх обновления в сторону R3:

0/0 получен от R1:

Теперь на R2 также безусловно генерирует 0/0 в сторону R3, чтобы не зависеть от маршрута из AS65001 (R1).

R2 отправляет только UPDATE.