Написал небольшую статью, но её похоже не приняли, отпишусь здесь, т.к материал на самом деле полезный, и в конце у меня есть вопрос (нужны примеры vrf-lite для второго варианта), если кто поможет - буду благодарен :) Использование BGP при наличии двух каналов в Интернет для выборочного анонсирования
Вводные данные
При наличии двух собственных подсетей /24, столкнулся с необходимостью стандартной работы BGP, и погуглив, обнаружил минимальное количество информации по этой теме. На просторах рунета, в основном рассматриваются случаи, когда имеется одна сетка /24, и 2 провайдера, один из которых используется, как резервный. Да даже и этот случай рассмотрен некорректно, либо разрознено, нормально встретил описания только на англоязычных ресурсах.
Сразу же оговорюсь - рассматриваемые фичи CiscoOS: EXIST-MAP и NON-EXIST-MAP не поддерживаются UNIX-аналогами (типа Quagga)
В данной статье я рассмотрю два примера конфигов, исходя из следующих данных.
*У нас есть два канала: основной рабочий и резервный. Оба провайдера анонсируют нам дефолт. Использование обоих каналов для нас нежелательно. Мы, в свою очередь, будем анонсировать им свои подсети, но если жив основной канал - анонс наших префиксов в резервный канал мы принудительно запретим, и будем анонсировать, только в случае падения рабочего канала
*У нас есть два рабочих канала. И нам необходимо, чтобы через первый канал ВСЕГДА работала (анонсировалась) наша первая подсеть, а через второй канал - наша вторая подсеть. Оба провайдера при этом анонсируют нам дефолты. В случае, если падает один из каналов - мы переносим анонс с этого канала, на оставшийся в живых. При возобновлении работы упавшего канала - возвращаем анонсы в начальный вид - по одной подсети через каждого провайдера
Теория:
"The BGP conditional advertisement feature uses the non-exist-map and the advertise-map keywords of the neighbor advertise-map command in order to track routes by the route prefix. If a route prefix is not present in output of the non-exist-map command, then the route specified by the advertise-map command is announced. This feature is useful for multihomed networks, in which some prefixes are advertised to one of the providers only if information from the other provider is not present (this indicates a failure in the peering session or partial reachability)."
Т.е в если в кратце: фичи EXIST-MAP и NON-EXIST-MAP - это условия проверки наличия в таблице маршрутов, описанного в роут-мапах префикса. Это триггер, срабатывающий, когда какой-то маршрут исчезает из таблицы (NON-EXIST-MAP) или наоборот появляется (EXIST-MAP)
Итак, у Вас есть:
* своя AS;
* две своих подсети класса "С" (префиксы менее /24 - не принимаются провайдерами к анонсу);
* два провайдера, с которым договорились о bgp-сессии;
* cisco с версией операционки не ниже 12.4 (в версиях ниже 12.4 отсутствует нужная нам фича EXIST-MAP, NON-EXIST-MAP);
* оба провайдера отдают Вам дефолтный маршрут и какой-нибудь любой свой префикс (далее объясню зачем этот префикс)
Случай №1: все сети отдаются одному провайдеру (основной канал), анонсирование в резервный канал начинается только в случае падения основного канала
Данный случай является самым простым, разнообразные его решения Вы можете найти где угодно, но почти всегда через [вырезано цензурой], т.е через увеличение path-prepend.
Стандартно, как для Cisco, так и для решений на UNIX-системах (при использовании Quagga), является одновременный анонс в оба канала. Просто в резервный канал идёт анонс с более длинным path prepend, но на мой взгляд это не самое удачное решение. Некоторые провайдеры препенды обрезают (так у меня было, например с ростелекомом) и вместо резервного канала - получаем балансировку между двумя каналами.
Следующее решение является более гибким, но есть два ньюанса:
1. Его нельзя реализовать на Quagga - она не умеет работать с EXIST-MAP
2. Необходимо, чтобы один из провайдеров помимо дефолта отдавал ещё какой-нибудь (любой) свой префикс, по которму будет отрабатывать EXIST-MAP, NON-EXIST-MAP. Для этого, о дополнительном префиксе легко договорится с провайдером - просто скажите NOC'у, что доп.префикс от него необходим, т.к Вы будете использовать EXIST-MAP, и свой доп. префикс провайдер добавит для Вас в анонс, без проблем.
Схема: http://img13.imageshost.ru/img/2012/08/15/image_502bd13f31b7...
Здесь - ComStar (vlan 100) - основной канал, QWERTY (vlan 200) - резервный канал, а Cisco - собственно, наш девайс.
Из логических данных:
* FastEthernet0/0.100 смотрит в основной канал ComStar;
* FastEthernet0/0.200 смотрит в резервный канал QWERTY;
* 88.88.10.0/23 - две наши подсети С-класса (88.88.10.0/24, 88.88.11.0./24), которые будем анонсировать;
* AS11111 - наша автономка;
* 10.10.10.0/24 - дополнительный префикс, который нам анонсирует провайдер основного канала, помимо дефолтного маршрута
Конфиг циски:
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
! Влан №100, который смотрит на ComStar
!
interface FastEthernet0/0.100
encapsulation dot1Q 100
ip address 10.192.0.10 255.255.255.0
!
! Влан №200 - смотрит на QWERTY
!
interface FastEthernet0/0.200
encapsulation dot1Q 200
ip address 192.168.1.10 255.255.255.0
!
!
ip forward-protocol nd
!
! Указываем наш префикс в нуль-интерфейс (если больше на циске эти подсети нигде не описаны),
! иначе BGP не будет делать анонс. Префикс сетей, которые будут анонсироваться - должен быть
! прописан в локальном роутинге.
!
ip route 88.88.10.0 255.255.254.0 Null0
!
! Настройки BGP
!
router bgp 11111
no synchronization
! router-id в принципе может быть какой угодно
bgp router-id 10.192.0.10
no bgp enforce-first-as
bgp log-neighbor-changes
! Сеть, которая пойдёт в анонс
network 88.88.10.0 mask 255.255.254.0
! Первый бгп-линк - комстар
neighbor 10.192.0.200 remote-as 8359
neighbor 10.192.0.200 description ComStar
neighbor 10.192.0.200 next-hop-self
neighbor 10.192.0.200 soft-reconfiguration inbound
! Установим вес для основного (приоритетного) канала
neighbor 10.192.0.200 weight 500
! Фильтруем префиксы, которые мы получаем
neighbor 10.192.0.200 route-map comstar in
! Фильтруем префиксы, которые мы отдаём
neighbor 10.192.0.200 route-map ournets out
! Второй линк - кверти
neighbor 192.168.1.200 remote-as 8615
neighbor 192.168.1.200 description QWERTY
neighbor 192.168.1.200 next-hop-self
neighbor 192.168.1.200 soft-reconfiguration inbound
! Установим вес для резервного (не приоритетного) канала
neighbor 192.168.1.200 weight 100
neighbor 192.168.1.200 route-map qwerty in
! Фильтруем префиксы которые мы отдаём
! Если мы не укажем эту строку, то мы проанонсируем провайдеру всё что есть у нас и всё
! что нам анонсировано другими линками, за исключениемнашей 88.88.10.0/23 (пока
! не сработает срабатывает триггер non-exist-map
neighbor 192.168.1.200 route-map ournets out
! Указываем префиксы, которые мы проанонсируем, если префикс 10.10.10.0/24
! исчезнет из таблицы роутинга, т.е пропадёт связь на основном канале
neighbor 192.168.1.200 advertise-map ournets non-exist-map NONEXIST_MAP
no auto-summary
!
! Опишем префикс, который нам отдаёт дополнительно наш основной провайдер
ip prefix-list NONEXIST seq 5 permit 10.10.10.0/24
!
! Опишем "левые" сети, которые мы точно не будем принимать
! если вдруг провайдер по ошибке начнёт нам их анонсировать
ip prefix-list bogons description Bad-nets
ip prefix-list bogons seq 10 permit 127.0.0.0/8 le 32
ip prefix-list bogons seq 20 permit 172.16.0.0/12 le 32
ip prefix-list bogons seq 25 permit 192.168.0.0/16 le 32
ip prefix-list bogons seq 30 permit 169.254.0.0/16 le 32
ip prefix-list bogons seq 35 permit 224.0.0.0/4 le 32
ip prefix-list bogons seq 40 permit 240.0.0.0/4 le 32
!
! Опишем наш префикс, который мы будем анонсировать
ip prefix-list our-network seq 5 permit 88.88.10.0/23
ip prefix-list our-network seq 10 deny 0.0.0.0/0
!
!
! Настраиваем роут-мапы
! Для резервного линка QWERTY:
! запрещаем приём "левых" префиксов в анонсе
route-map qwerty deny 100
match ip address prefix-list bogons
! Устанавливаем приоритетность маршрутов, т.к дефолт мы всё равно будем получать, и нам
! не надо, чтобы дефолт резервного линка перебил дефолт основного провайдера
route-map qwerty permit 110
set local-preference 200
!
! Аналогично
route-map comstar deny 100
match ip address prefix-list bogons
!
route-map comstar permit 110
set local-preference 100
!
! Мапа для условия NON-EXIST-MAP
route-map NONEXIST_MAP permit 10
match ip address prefix-list NONEXIST
!
! Ну и мапа для анонсирования нашего префикса
route-map ournets permit 100
description Permit our prefixes
match ip address prefix-list our-network
Что при этом происходит?
Основной и резервный провайдер отдают нам себя, в качестве дефолт-гейтвея (основной провайдер дополнительно отдаёт нам ещё свой префикс 10.10.10.0/24). Пока жив рабочий канал, по весу и приоритету он является в таблице маршрутизации главным. И пока в нашей локальной таблице есть его доп.префикс 10.10.10.0/24, мы не будем анонсировать свою сеть 88.88.10.0/23 резервному провайдеру. Но как только происходит разрыв bgp-сессии с основным провайдером, и у нас исчезает роутинг на префикс 10.10.10.0/24, срабатывает условие advertise-map ournets non-exist-map NONEXIST_MAP - и мы отправляем свой анонс в резервный канал (дефолтный маршрут от резерва - у нас уже есть, мы принимаем его всегда.
Вроде бы всё, и на этом, с первым вариантом закончим.
Случай №2: каждому провайдеру отдаётся по одной подсети. В случае падения одного из линков - анонс подсети /24, с упавшего линка, переносится на оставшийся в живых, а при восстановлении канала - анонсы возвращаются к начальному состоянию - по одному в каждый канал
Логические данные оставляем почти те же самые:
* 88.88.10.0/24 - анонсируем в основной канал, 88.88.11.0/24 - в резервный
* помимо дефолтного маршрута, префикс 10.10.10.0/24 получаем дополнительно от первого провайдера, а 20.20.20.0/24 - от второго - по ним будет срабатывать триггер NON-EXIST-MAP
ip forward-protocol nd
! Прописываем локальные роуты наших подсетей
ip route 88.88.10.0 255.255.255.0 Null0
ip route 88.88.11.0 255.255.255.0 Null0
!
router bgp 11111
no synchronization
bgp router-id 10.192.0.10
no bgp enforce-first-as
bgp log-neighbor-changes
! Оба наших префикса по /24
network 88.88.10.0 mask 255.255.255.0
network 88.88.11.0 mask 255.255.255.0
! Первый провайдер
neighbor 10.192.0.200 remote-as 8359
neighbor 10.192.0.200 description ComStar
neighbor 10.192.0.200 next-hop-self
neighbor 10.192.0.200 soft-reconfiguration inbound
! Приоритет на маршруты оставляем за ним
neighbor 10.192.0.200 weight 500
! Фильтруем входящие маршруты
neighbor 10.192.0.200 route-map comstar in
! Фильтруем исходящие маршруты (allournets - разрешаем анонсировать оба наших префикса)
neighbor 10.192.0.200 route-map allournets out
! Пока существует 20.20.20.0/24, получаемый от второго провайдера - мы не анонсируем
! первому провайдеру наш префикс 88.88.11.0/24
neighbor 192.168.1.200 advertise-map ournets11 non-exist-map NONEXIST_MAP2
! Второй провайдер - настраиваем по аналогии
neighbor 192.168.1.200 remote-as 8615
neighbor 192.168.1.200 description QWERTY
neighbor 192.168.1.200 next-hop-self
neighbor 192.168.1.200 soft-reconfiguration inbound
neighbor 192.168.1.200 weight 100
neighbor 192.168.1.200 route-map qwerty in
neighbor 192.168.1.200 route-map allournets out
! Пока существует 10.10.10.0/24, получаемый от первого провайдера - мы не анонсируем
! второму провайдеру наш префикс 88.88.10.0/24
neighbor 192.168.1.200 advertise-map ournets10 non-exist-map NONEXIST_MAP
no auto-summary
!
! Доп.префикс, анонсируемый первым провайдером, для доказательства его живности
ip prefix-list NONEXIST seq 5 permit 10.10.10.0/24
!
! Доп.префикс второго провайдера
ip prefix-list NONEXIST2 seq 5 permit 20.20.20.0/24
!
ip prefix-list bogons description Bad-nets
ip prefix-list bogons seq 10 permit 127.0.0.0/8 le 32
ip prefix-list bogons seq 20 permit 172.16.0.0/12 le 32
ip prefix-list bogons seq 25 permit 192.168.0.0/16 le 32
ip prefix-list bogons seq 30 permit 169.254.0.0/16 le 32
ip prefix-list bogons seq 35 permit 224.0.0.0/4 le 32
ip prefix-list bogons seq 40 permit 240.0.0.0/4 le 32
!
! Описываем оба наших префикса для анонсирования в один канал
ip prefix-list allour-network seq 5 permit 88.88.10.0/24
ip prefix-list allour-network seq 10 permit 88.88.11.0/24
ip prefix-list allour-network seq 15 deny 0.0.0.0/0
!
! Описываем запрещаемый для анонсирования префикс (условие NON-EXIST-MAP)
! для второго канала
ip prefix-list our-network10 seq 5 permit 88.88.10.0/24
ip prefix-list our-network10 seq 10 deny 0.0.0.0/0
!
! Описываем запрещаемый для анонсирования префикс (условие NON-EXIST-MAP)
! для первого канала
ip prefix-list our-network11 seq 5 permit 88.88.11.0/24
ip prefix-list our-network11 seq 10 deny 0.0.0.0/0
!
!
! Настраиваем роут-мапы
route-map qwerty deny 100
match ip address prefix-list bogons
!
route-map qwerty permit 110
set local-preference 200
!
! Роутмапы для отрабатывания NON-EXIST для первого и второго провайдера
route-map NONEXIST_MAP permit 10
match ip address prefix-list NONEXIST
!
route-map NONEXIST_MAP2 permit 10
match ip address prefix-list NONEXIST2
!
! То, что будем разрешать анонсировать при исчезновении доп.префикса провайдера 1 или 2
route-map ournets10 permit 100
description Permit our prefixes
match ip address prefix-list our-network10
!
route-map ournets11 permit 100
description Permit our prefixes
match ip address prefix-list our-network11
!
! Разрешаем анонс обоих префиксов
route-map allournets permit 100
description Permit our prefixes
match ip address prefix-list allour-network
!
route-map comstar deny 100
match ip address prefix-list bogons
!
route-map comstar permit 110
set local-preference 100
Что при этом происходит?
Первый и второй провайдеры отдают нам себя, в качестве дефолт-гейтвея (плюс - отдают нам доп.префиксы: первый провайдер - префикс 10.10.10.0/24, второй - 20.20.20.0/24).
1. Пока живы оба канала, сеть 88.88.10.0/24 анонсируется только первому провайдеру, а сеть 88.88.11.0/24 - анонсируется только второму.
2. Если падает первый канал, из нашей таблицы роутинга исчезает префикс 10.10.10.0/24, срабатывает триггер "neighbor 192.168.1.200 advertise-map ournets10 non-exist-map NONEXIST_MAP", и мы начинаем анонсировать 88.88.10.0/24 во второй канал.
3. Если падает второй канал, из нашей таблицы исчезает префикс 20.20.20.0/24, срабатывает триггер "neighbor 10.192.0.200 advertise-map ournets11 non-exist-map NONEXIST_MAP2", и мы начинаем анонсировать 88.88.11.0/24 в первый канал.
При восстановлении связи с упавшим каналом - всё возвращается к начальной схеме - анонс каждой сети в отдельный канал.
Повторюсь - оба этих варианта можно решить с помощью увеличения препендов и анонсировать все всети во все каналы, но можно попасть на обрезание этих самых препендов, либо на провайдера, который их игнорирует - и тогда получится, что трафик побежит по каналу, который мы не хотим использовать.
Оба эти конфига являются рабочими и благополучно отработали на стендовой виртуалке GNS3.
Один ньюанс - если не использовать vrf-lite, то при текущей настройке трафик будет бегать по дефолтному маршруту.
Т.е на примере второго варианта - сеть 88.88.10.0/24 анонсируется первому провайдеру, 88.88.11.0/24 - второму. Дефолт принимается от первого провайдера. Входящий сигнал в сеть 88.88.11.0/24 пойдёт через второй канал (как и надо), а вот ответ (исходящий трафик) - пойдёт по дефолтному маршруту, через первый канал, что приведёт к ассинхронизации трафика. Чтобы избежать этого, настраивается фича vrf-lite.
Буду весьма благодарен, если кто-то поможет с примерами vrf для второго варианта.
Вариант для распечатки
on 16-Авг-12, 15:14 
