понедельник, 26 декабря 2011 г.

Multihomed BGP

Задача:

Имеются собственные 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/0

CE2:
Практически все то же самое

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

router bgp 100
 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

route-map AddASnumbers permit 10
 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

Проверка дефолта 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


2. Падение интерфейса F0/0 маршрутизатора CE1 

Исходящие пакеты
Виртуальный адрес HSRP будет перехвачен маршрутизатором CE2 и затем уйдут по дефолту на ISP2.

Проверка:
C хоста в локальной сети AS100 
Tracing the route to 66.66.66.66
  1    <1 мс    <1 мс    <1 мс  1.1.1.2
  2    <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 msec
  2 2.2.2.1 4 msec 0 msec 0 msec
  3 1.1.1.112 [AS 100] 4 msec 0 msec 0 msec


3.Падение F0/1  на CE1 или F0/1 на ISP1

Исходящие пакеты
При падении 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




6 комментариев:

  1. Все конечно правильно и хорошо, но в реальной жизни "падение интерфейса" вещь настолько редкая, что можно особо не заморачиваться. Чего бы ему падать до провайдерского свича/модема на твоей площадке. А вот радости типа "линк к провайдеру есть, BGP есть, но не вся таблица", "линк есть, BGP есть, пинга хер", или "все есть, а http не работает" - происходит в разы чаще. Поэтому ко всему вышесказанному нужно еще пачку SLA...

    ОтветитьУдалить
    Ответы
    1. :) И Вам не лень было все это читать? Здорово.
      "Падение интерфейса" может быть и падением провайдерского маршрутизатора. Всяко бывает. За три минуты, которые обеспечивает время сходимости 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

      Удалить
  2. Конечно здорово написано, но еще бы NAT inside-outside сюда бы не мешало добавить и описать SNAT который я думаю понадобится для этого.

    ОтветитьУдалить
    Ответы
    1. Я обычно выкладывала только то, что было трудно найти в требуемом виде в Инете. По НАТу уже тогда были отличные статьи на Хабре:
      http://habrahabr.ru/post/108931/
      http://habrahabr.ru/post/108978/

      Еще вот это очень нравится http://habrahabr.ru/post/147996/

      SNAT не делала - и возможности не было, и такие вещи предпочитаю делать на специально заточенных под это железках (н-р ASA).

      Удалить
  3. Спасибо за статью. Сам начал разбираться с BGP и пока появилась только куча вопросов.
    А если я получаю от двух провайдеров только дефолты? Как сделать выбор основного провайдера? Пробовал через weight, но тогда используется только исходящий трафик, так?

    ОтветитьУдалить
  4. Спасибо, полезная статья.

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.