Имеются собственные PI адреса (1.1.1.0/24), собственная AS (AS100) и подключение к 2-м провайдерам. Один провайдер основной(ISP1), второй резервный(ISP2). Необходимо обеспечить резервирование выхода в интернет на уровне железа.
Ограничения:
Одна железка(CE1) держит BGP full view, другая(CE2) нет. Слабая железка CE2 имеет только 2 интерфейса FastEthernet.
Решение:
Поднимаем eBGP сессии с провайдерами и iBGP между своими маршрутизаторами. Сильный маршрутизатор CE1 получает Full View от основного провайдера, слабый CE2 только дефолт от запасного. Оба маршрутизатора анонсируют свою сеть (1.1.1.0/24) и модифицируют атрибуты так, чтобы обратный трафик с большей вероятностью возвращался через основного провайдера. Между собой маршрутизаторы устанавливают iBGP сессию, CE2 отдает дефолтный маршрут, полученный по eBGP от ISP2, на сильный маршрутизатор CE1. CE1 не отдает на CE2 ничего. Сеанс устанавливаем на реальные адреса, т.к. путь друг до друга у CE1 и CE2 один. Со стороны локальной сети между CE1 и CE2 поднят HSRP с виртуальным адресом 1.1.1.1/24 (на схеме не обозначено). Приоритет HSRP выставлен так, что CE1 является Active.
Настройка
CE1:
interface FastEthernet0/0
ip address 1.1.1.3 255.255.255.0
no ip redirects - Cisco рекомендует выполнять эту команду при использовании BFD, т.к. в противном случае будет грузиться CPU
standby 4 ip 1.1.1.1 - Конфигурируем виртуальный HSRP адрес
standby 4 timers 1 3
standby 4 priority 200 - Делаем этот маршрутизатор Active
standby 4 preempt
bfd interval 50 min_rx 50 multiplier 4 - поднимаем BFD
end
router bgp 100
bgp log-neighbor-changes
bgp dampening
network 1.1.1.0 mask 255.255.255.255
neighbor 1.1.1.2 remote-as 100 - формируем iBGP сессию
neighbor 1.1.1.2 next-hop-self - при пересылке маршрутов на 1.1.1.2 менять значение next-hop на свой адрес. По умолчанию для iBGP сессий этого не происходит.
neighbor 1.1.1.2 soft-reconfiguration inbound - сохраняет все полученные от соседа маршруты в памяти, что позволяет применять различные фильтры на входящие апдейты от соседа без переустановки bgp сессии, а также видеть результаты крайне полезной команды show ip bgp neighbors Х.Х.Х.Х received-routes
neighbor 1.1.1.2 prefix-list DEFAULT_ROUTE in - на вход от CE2 разрешаем только дефолт
neighbor 1.1.1.2 prefix-list NOTHING out - и ничего не отправляем на CE2
neighbor 3.3.3.2 remote-as 300 - формируем eBGP сессию
neighbor 3.3.3.2 fall-over bfd - функция обеспечивает быструю сходимость протокола BGP. Необходимо настраивать на обоих маршрутизаторах, участвующих в сессии. Устанавливается двусторонняя UDP сессия. Поскольку нагрузку на CPU почти не дает, интервалы обмена сообщениями могут быть очень маленькими, от 50 мс. Таким образом, при пропадании доступности соседнего IP hop BGP сессия рвется сразу, не выдерживая таймаута в 3 минуты.
Для настройки BFD сессии между маршрутизаторами, находящимися на расстоянии через 1 и более IP узлов, например, multihop eBGP или iBGP с промежуточным маршрутизатором между соседями, требуется multihop BGP feature, доступная только с версии 15.1(3)S.
neighbor 3.3.3.2 soft-reconfiguration inbound - сохраняет все полученные от соседа маршруты в памяти, что позволяет применять различные фильтры на входящие апдейты от соседа, а также видеть результаты крайне полезной команды show ip bgp neighbors Х.Х.Х.Х received-routes
neighbor 3.3.3.2 prefix-list OUR_PI out - анонсируем только свои PI адреса, дабы не превратиться в транзитную систему.
no auto-summary
ip prefix-list OUR_PI seq 5 permit 1.1.1.0/24
ip prefix-list DEFAULT_ROUTE seq 5 permit 0.0.0.0/0
ip prefix-list NOTHING seq 5 deny 0.0.0.0/0CE2:
Практически все то же самое
interface FastEthernet0/0
ip address 1.1.1.2 255.255.255.0
no ip redirects
bfd interval 50 min_rx 50 multiplier 4
standby 4 ip 1.1.1.1
standby 4 timers msec 500 1
standby 4 preempt
ip address 1.1.1.2 255.255.255.0
no ip redirects
bfd interval 50 min_rx 50 multiplier 4
standby 4 ip 1.1.1.1
standby 4 timers msec 500 1
standby 4 preempt
no synchronization
bgp log-neighbor-changes
bgp dampening
network 1.1.1.0 mask 255.255.255.0
neighbor 1.1.1.3 remote-as 100
neighbor 1.1.1.3 next-hop-self
neighbor 1.1.1.3 soft-reconfiguration inbound
neighbor 1.1.1.3 prefix-list NOTHING in - ничего не берем с CE1
neighbor 1.1.1.3 prefix-list DEFAULT_ROUTE out - отправляем на CE1 только дефолт
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 fall-over bfd
neighbor 2.2.2.2 soft-reconfiguration inbound
neighbor 2.2.2.2 prefix-list DEFAULT_ROUTE in - принимаем от ISP2 только дефолт
neighbor 2.2.2.2 prefix-list OUR_PI out - отправляем только свои PI адреса, чтобы избежать транзита
neighbor 2.2.2.2 route-map AddASnumbers out - добавляем дополнительные экземпляры номера своей AS для того, чтобы сделать этот маршрут менее предпочтительным для обратного трафика
no auto-summary
ip prefix-list OUR_PI seq 5 permit 1.1.1.0/24
ip prefix-list DEFAULT_ROUTE seq 5 permit 0.0.0.0/0
ip prefix-list NOTHING seq 5 deny 0.0.0.0/0
set as-path prepend 100 100 100 100
В тестовых целях на ISP1 подняты Loopback 1-3 (которые анонсируются по BGP) для имитации Full View, Loopback0 (который не анонсируется) для тестирования маршрута по умолчанию. На ISP2 поднят Loopback0(анонсируется). Кроме того, на ISP прописан статикой маршрут до 99.99.99.99. Тестовая рабочая станция в AS100 имеет адрес 1.1.1.112.
1. Нормальный режим.
Исходящие пакеты
В штатном режиме исходящие пакеты будут всегда попадать на CE1 (HSRP Active). При наличии маршрута в full view, они уйдут на ISP1, иначе уйдут через default route, полученный с CE2, на CE2 и оттуда на ISP2.
Основной трафик c хоста в локальной сети AS100
Tracing the route to 66.66.66.66
1 <1 мс <1 мс <1 мс 1.1.1.3
2 <1 мс <1 мс <1 мс 66.66.66.66
2 <1 мс <1 мс <1 мс 66.66.66.66
Проверка дефолта c хоста в локальной сети AS100
Tracing the route to 99.99.99.99
1 <1 мс <1 мс <1 мс 1.1.1.3
2 <1 мс <1 мс <1 мс 1.1.1.2
3 <1 мс <1 мс <1 мс 2.2.2.2
4 <1 мс <1 мс <1 мс 99.99.99.99
Входящие пакеты
Большая часть трафика возвращается через основной канал ISP, поскольку CE2 при анонсе маршрута дополнительно вставляет в атрибут as-path несколько номеров своей AS, таким образом влияя на принятие решения о выборе лучшего маршрута маршрутизаторами за пределами своей AS (AS100). Однако, это влияние не может быть абсолютным и администраторы других AS могут применять политику маршрутизации, не учитывающую длину AS PATH, таким образом некоторая часть трафика может возвращаться через запасного провайдера ISP2.
Большинство пакетов с маршрутизатора ISP2
Tracing the route to 1.1.1.112
1 4.4.4.1 0 msec 4 msec 0 msec
2 3.3.3.1 0 msec 0 msec 0 msec
3 1.1.1.112 [AS 100] 0 msec 0 msec 0 msec
1 4.4.4.1 0 msec 4 msec 0 msec
2 3.3.3.1 0 msec 0 msec 0 msec
3 1.1.1.112 [AS 100] 0 msec 0 msec 0 msec
2. Падение интерфейса F0/0 маршрутизатора CE1
Исходящие пакеты
Виртуальный адрес HSRP будет перехвачен маршрутизатором CE2 и затем уйдут по дефолту на ISP2.
Проверка:
C хоста в локальной сети AS100
Tracing the route to 66.66.66.66
1 <1 мс <1 мс <1 мс 1.1.1.22 <1 мс <1 мс <1 мс 2.2.2.2
3 <1 мс <1 мс <1 мс 66.66.66.66
Входящие пакеты
Проверка:
С маршрутизатора ISP1
ISP1#traceroute 1.1.1.112
1 4.4.4.2 0 msec 0 msec 0 msec2 2.2.2.1 4 msec 0 msec 0 msec
3 1.1.1.112 [AS 100] 4 msec 0 msec 0 msec
Исходящие пакеты
При падении F0/1 на CE1 или F0/1 на ISP1 пакеты приходят сначала на CE1, потом с него на CE2, потом на ISP2. Для ускорения переключения CE1 на дефолтный маршрут между ISP1 и CE1 поднята BFD сессия и BGP настроен реагировать на ее состояние.
Проверка:
C хоста в локальной сети AS100 Tracing the route to 66.66.66.66
1 <1 мс <1 мс <1 мс 1.1.1.3
2 <1 мс <1 мс <1 мс 1.1.1.2
3 1 ms <1 мс <1 мс 2.2.2.2
4 <1 мс <1 мс <1 мс 66.66.66.66
Входящие пакеты
Проверка:
С маршрутизатора ISP1
Tracing the route to 1.1.1.112
1 4.4.4.2 0 msec 4 msec 0 msec
2 2.2.2.1 0 msec 4 msec 0 msec
3 1.1.1.112 [AS 100] 0 msec 4 msec 0 msec
4. Падение F0/0, F9/1 на CE2 или F0/1 на ISP2.
Исходящие пакеты
При падении любого из интерфейсов CE2 или F0/1 на ISP2 начинают теряться только те пакеты, маршрут к которым отсутствует в Full View на CE1.
Проверка:
Основные маршруты с хоста в локальной сети AS100 Tracing the route to 66.66.66.66
1 <1 мс <1 мс <1 мс 1.1.1.3
2 <1 мс <1 мс <1 мс 66.66.66.66
Маршрут по умолчанию с хоста в локальной сети AS100
Tracing the route to 99.99.99.99
1 <1 мс <1 мс <1 мс 1.1.1.3
2 1.1.1.3 сообщает: Заданный узел недоступен.
Входящие пакеты
Проверка:
С маршрутизатора ISP2
Tracing the route to 1.1.1.112
1 4.4.4.1 0 msec 0 msec 4 msec
2 3.3.3.1 0 msec 0 msec 0 msec
3 1.1.1.112 [AS 100] 0 msec 4 msec 0 msec
Troubleshooting
1. Быстро посмотреть настройку BGP в конфиге:
R#show running-config | section bgp
2. Посмотреть состояние BGP сессий:
R#show ip bgp summary
3. Посмотреть на список BGP маршрутов, получаемых от конкретного соседа:
R#show ip bgp neighbors 4.4.4.1 received-routes
4. Посмотреть список маршрутов от конкретного соседа после применения всех фильтров:
R#show ip bgp neighbors 4.4.4.1 routes
5. Посмотреть список маршрутов, анонсируемых конкретному соседу:
R#show ip bgp neighbors 4.4.4.1 advertised-routes
6. Посмотреть таблицу BGP маршрутов на маршрутизаторе
R#show ip bgp
7. Посмотреть таблицу маршрутизации
R#show ip route
8. Посмотреть состояние HSRP
R#show standby
9. Посмотреть состояние BFP
R#show bfd neighbors
Все конечно правильно и хорошо, но в реальной жизни "падение интерфейса" вещь настолько редкая, что можно особо не заморачиваться. Чего бы ему падать до провайдерского свича/модема на твоей площадке. А вот радости типа "линк к провайдеру есть, BGP есть, но не вся таблица", "линк есть, BGP есть, пинга хер", или "все есть, а http не работает" - происходит в разы чаще. Поэтому ко всему вышесказанному нужно еще пачку SLA...
ОтветитьУдалить:) И Вам не лень было все это читать? Здорово.
Удалить"Падение интерфейса" может быть и падением провайдерского маршрутизатора. Всяко бывает. За три минуты, которые обеспечивает время сходимости BGP, вполне можно успеть вынести мозги админу по телефону.
С радостями типа "линк к провайдеру есть, BGP есть, но не вся таблица", "линк есть, BGP есть, пинга хер", или "все есть, а http не работает" борется PfR, что есть отдельная большая тема.
Раскрыта тут http://www.anticisco.ru/blogs/?p=835
и тут http://www.cisco.com/en/US/products/ps8787/products_ios_protocol_option_home.html
Конечно здорово написано, но еще бы NAT inside-outside сюда бы не мешало добавить и описать SNAT который я думаю понадобится для этого.
ОтветитьУдалитьЯ обычно выкладывала только то, что было трудно найти в требуемом виде в Инете. По НАТу уже тогда были отличные статьи на Хабре:
Удалитьhttp://habrahabr.ru/post/108931/
http://habrahabr.ru/post/108978/
Еще вот это очень нравится http://habrahabr.ru/post/147996/
SNAT не делала - и возможности не было, и такие вещи предпочитаю делать на специально заточенных под это железках (н-р ASA).
Спасибо за статью. Сам начал разбираться с BGP и пока появилась только куча вопросов.
ОтветитьУдалитьА если я получаю от двух провайдеров только дефолты? Как сделать выбор основного провайдера? Пробовал через weight, но тогда используется только исходящий трафик, так?
Спасибо, полезная статья.
ОтветитьУдалить