eBGP в ынтерпрайзах
Давайте сфокусируемся на том, как формируется соседство и как происходит обмен топологической информацией которая помещается в BGP таблицу между eBGP соседями. Ну и наконец повеселим себя какой-нибудь практикой, настроив связность с двумя ISP по single multihomed сценарию. Ведь две статьи по 1300+ слов чистой теории в каждой способны превратить даже Хари Кришну в конченного падонка.
Абсолютный минимум, который должна включать в себя настройка соседей состоит из:
- Номера собственной автономной системы маршрутизатора (router bgp asn).
- IP адреса каждого из соседей и их ASN (neighbor ip_addr remote-as remote_asn).
Для успешного формирования соседства должны быть выполнены следующие условия:
- Номер автономной системы локального маршрутизатора должен совпадать с ASN, указанным в команде neighbor … на соседе.
- BGP Router ID не должны быть одинаковыми.
- Если настроена MD5 аутентификация, то она должна завершаться успешно (внезапно!). Настраивается она с помощью команды neighbor ip_addr password key.
- Каждый из соседей должен успешно установить TCP сессию друг с другом на 179 порту, по адресу указанному в команде neighbor ip_addr remote-as remote_asn.
BGP выбирает Router ID так же, как и OSPF:
- Если задан используется RID статически настроенный в процессе BGP с помощью bgp router-id rid.
- Если не задан RID берется IP адрес самого старшего loopback интерфейса в состоянии UP.
- Если нет loopback интерфейсов, берется номер самого старшего физического интерфейса в состоянии UP/UP.,
Еще одна информация к размышлению, которую нужно держать в голове: по умолчанию адресом источником, который маршрутизатор использует для установки TCP соединения с соседом является адрес исходящего интерфейса, который используется для отправления пакетов соседу. Если между соседями только один канал, то такой вариант не представляет из себя проблему, однако если в наличии имеются два или более каналов, то отказ одного из интерфейсов, который используется для формирования соседства может привести к перерывам в работе. Решить эту проблему можно двумя путями:
- Настроить два или более (по количеству IP адресов) соседей. В этом случае обе пары соседей будут обмениваться маршрутной информацией, потребляя ресурсы.
- Настроить loopback интерфейс и использовать его как адрес-источник для установления сессии. Дополнительно нужно будет тем или иным способом рассказать соседям о способах достижения loopback интерфейсов друг друга. Настройка сводится к следующему:
| шаг | действие |
| 1 | Создать loopback интерфейс и задать ему IP адрес на каждом маршрутизаторе. |
| 2 | Заставить BGP использовать этот интерфейс как источник для обмена маршрутной информацией: neighbor ip_addr update_source [ interface interface | ip_addr ] |
| 3 | Настроить соседей таким образом, чтобы они предпочитали использовать loopback адреса друг друга neighbor ip_addr remote-as asn |
| 4 | Убедиться в том, что соседи знают о способах достижения loopback интерфейсов друг друга. |
| 5 | Настроить eBGP multihop, используя команду neighbor … ebgp-multihop hops |
Первые 4 шага должны быть настроены на обоих маршрутизаторах. В шаге 4 для обмена информацией о IP loopback интерфейсов можно испольхзовать IGP или статическую маршрутизацию.
Шаг 5 требует некоторого пояснения. По умолчанию IOS устанавливает в поле TTL заголовка IP значение “1”, что при использовании loopback интерфейсов не дает установится соседству. В случае если используются loopback интерфейсы и соседи directly connected – hop count надо установить в значение 2. Если между ними находятся еще два дополнительных маршрутизатора – 4. И т.д.
BGP формирует соседство в 3 этапа:
- Пытается установить TCP соединение с IP адресом указанным в команде neighbor на 179 порт.
- После 3-way handshake маршрутизатор посылает первое сообщение – BGP Open Message, которое по сути является аналогом Hello пакета, который используют EIGRP и OSPF – это сообщение содержит некоторые параметры, которые должны быть подтверждены перед тем как соседство будет установлено.
- После того, как Open Message отправлено, получено, все параметры совпали, соседи впадают в нирвану переходят в established state. Это если все ок. Если что-то не ок, то соседи будут переходить из одной фазы в другую по кругу:
| фаза | описание |
| idle | BGP процесс или выключен * или ждет истечение таймера, прежде чем предпринять следующую попытку. |
| connect | BGP процесс ожидает завершения процедуры установки TCP соединения. |
| active | TCP соединение установлено, но но BGP сообщения еще не были отправлены. |
| opensent | TCP соединение установлено, BGP Open Message отправлено, но ответ в виде BGP Open Message с подходящими параметрами от соседа еще не пришел. |
| openconfirm | Open Message отправлен и получен. Теперь маршрутизатор ожидает либо Keepalive (все ок, параметры подходят) или Notification (все не ок, соседями мы не будем). |
| established | Все параметры согласованы и соседи могут начинать обмен Update сообщениями. Префиксы, заученные из этих сообщений помещаются в таблицу BGP. После этого BGP анализирует все маршруты и помещает лучшие в таблицу маршрутизации. Update сообщения служат как для помещения маршрутов в таблицу BGP, так и удаления из нее. |
* можно вручную отключить соседа, использовав команду neighbor ip_addr shutdown
Анонсирование маршрутов
Анонсировать маршруты можно двумя способами:
- командой network
- редистрибуцией
Анонсирование маршрутов командой network
Команда network в BGP значительно отличается от используемых в IGP. В EIGRP и OSPF команда network соотносит параметры, которые были переданы в ее теле со всеми активными интерфейсами. В случае совпадения маршрутизатор начинал анонсировать эти сети с этих интерфейсов. BGP не использует команду network, чтобы включить процесс на каком-либо интерфейсе. Фактически BGP вообще не использует концепцию интерфейсов. Вместо этого сравнение происходит между параметрами, введенными в тело команды network и содержимым таблицы маршрутизации: если существует префикс, который в точности совпадает с таковым, указанным в команде network, то такой маршрут можно поместить в BGP table и начинать его анонсы соседям.
Предыдущее утверждение справедливо, если процесс BGP сконфигурирован с no auto-summary, что являет значением по умолчанию начиная с какого-то лохматого IOS.
BGP и auto-summary
После включения автоматического суммирования немного меняется логика работы команды network когда опускается ключ mask. С таким ключем маршрутизатор ведет себя как обычно, но если вы его опустили, то BGP добавит в таблицу маршрутизации классовую сеть в том случае если:
- существует классовый маршрут в таблице маршрутизации
- существует хотя бы один маршрут до подсети, которая входит в классовую сеть
Допустим в таблице маршрутизации существет запись о маршруте 6.6.6.0/24. В случае если вы включите автоматическое суммирование и добавите эту сеть для анонса командой network, то в BGP таблице окажется маршрут до 6.0.0.0/8 сети. На самом деле вся эта богадельня работает от IOS к IOS сильно по разному. Просто следует держать в голове, что суммарные анонсы BGP в таком случае подразумевают классовые сети.
Редистрибуция из IGP
Вместо использования команды network никто не может запретить вам заняться редистрибуцией. В конечном итоге цели преследуются те же:
- Внедрить публичное адресное пространство в BGP таблицу.
- Анонсировать один маршрут до диапазона публичных адресов, вместо отдельных подсетей этого диапазона.
Если с первым вариантов все вроде понятно, то второй я, пожалуй, поясную. Допустим у нас есть 3 маршрута до подсетей, которые являются подмножеством более крупного блока. Если мы хотим вместо трех маршрутов анонсировать суммарный, то нам нужно сделать что-либо из этого списка:
- использовать суммирование маршрутов средствами IGP
- настроить статический null-маршрут (discard route) для целого префикса
- настроить на BGP суммирование маршрутов таким образом, чтобы BGP анонсировал только этот префикс (команда aggregate-address network mask summary-only)
Практика
Схема сети представляет собой следующее:
Мы владеем AS 62211 и PI 15.0.0.0/29. Наша задача выполнить первоначальную настройку этого кусочка “интернетов”, выяснить чем нам грозит подобная конфигурация по умолчанию как владельцу AS и почему делать из себя транзитную AS не всегда хорошо. Плюс хорошо бы настроить ISP1 так, чтобы он нам отдавал маршрут по умолчанию, а ISP2 маршрут по умолчанию с directly connected сетями. ISP3 должен анонсировать суммарные маршруты 1.8.12.0/23, 1.8.14.0/23 вместо более специфичных /24.
CE(config)#int lo1
CE(config-if)#ip address 8.8.8.8 255.255.255.255
CE(config-if)#router ospf 1
CE(config-router)#network 8.8.8.8 0.0.0.0 area 0
CE(config-router)#network 1.1.1.1 0.0.0.0 area 0
CE(config-router)#network 1.1.2.1 0.0.0.0 area 0
CE(config-router)#router id 8.8.8.8
CE(config-router)#do sh ip route ospf
9.0.0.0/32 is subnetted, 1 subnets
O 9.9.9.9 [110/11] via 1.1.2.2, 00:03:37, FastEthernet0/1
[110/11] via 1.1.1.2, 00:03:37, FastEthernet0/0
CE(config)#router bgp 62211
CE(config-router)#neighbor 9.9.9.9 remote-as 31
CE(config-router)#neighbor 9.9.9.9 ebgp-multihop 2
CE(config-router)#neighbor 9.9.9.9 update-source lo1
CE(config-router)#neighbor 2.2.2.2 remote-as 200
CE(config-router)#network 15.0.0.0 mask 255.255.255.248
ISP1(config)#int lo0
ISP1(config-if)#ip address 9.9.9.9 255.255.255.255
ISP1(config-if)#router ospf 1
ISP1(config-router)#network 9.9.9.9 0.0.0.0 area 0
ISP1(config-router)#network 1.1.1.2 0.0.0.0 area 0
ISP1(config-router)#network 1.1.2.2 0.0.0.0 area 0
ISP1(config-router)#router-id 9.9.9.9
ISP1(config)#router bgp 31
ISP1(config-router)#do sh ip route ospf
8.0.0.0/32 is subnetted, 1 subnets
O 8.8.8.8 [110/11] via 1.1.2.1, 00:06:15, FastEthernet0/1
[110/11] via 1.1.1.1, 00:06:15, FastEthernet0/0
ISP1(config-router)#neighbor 8.8.8.8 remote-as 62211
ISP1(config-router)#neighbor 8.8.8.8 ebgp-multihop 2
ISP1(config-router)#neighbor 8.8.8.8 update-source lo0
ISP1(config-router)#neighbor 3.3.3.2 remote-as 80
ISP2(config)#router bgp 200
ISP2(config-router)#neighbor 2.2.2.1 remote-as 62211
ISP2(config-router)#network 185.15.1.0 mask 255.255.255.0
ISP2(config-router)#network 185.16.2.0 mask 255.255.255.0
ISP2(config-router)#neighbor 4.4.4.2 remote-as 80
ISP3(config)#router bgp 80
ISP3(config-router)#neighbor 3.3.3.1 remote-as 31
ISP3(config-router)#neighbor 4.4.4.1 remote-as 200
ISP3(config-router)#network 1.8.12.0 mask 255.255.255.0
ISP3(config-router)#network 1.8.13.0 mask 255.255.255.0
ISP3(config-router)#network 1.8.14.0 mask 255.255.255.0
ISP3(config-router)#network 1.8.15.0 mask 255.255.255.0
Если вы читали данную статью, то не думаю что эта конфигурация требует пояснения. Давайте взглянем на ISP1:
ISP1#sh ip bgp
BGP table version is 10, local router ID is 9.9.9.9
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
* 1.8.12.0/24 8.8.8.8 0 62211 200 80 i
*> 3.3.3.2 0 0 80 i
* 1.8.13.0/24 8.8.8.8 0 62211 200 80 i
*> 3.3.3.2 0 0 80 i
* 1.8.14.0/24 8.8.8.8 0 62211 200 80 i
*> 3.3.3.2 0 0 80 i
* 1.8.15.0/24 8.8.8.8 0 62211 200 80 i
*> 3.3.3.2 0 0 80 i
*> 15.0.0.0/29 8.8.8.8 0 0 62211 i
*> 185.15.1.0/24 3.3.3.2 0 80 200 i
* 8.8.8.8 0 62211 200 i
*> 185.16.2.0/24 3.3.3.2 0 80 200 i
* 8.8.8.8 0 62211 200 i
Обратите внимание на выделенные записи. Альтернативный путь до 185.15.1.0/24, 185.15.2.0/24 сетей лежит через нашу автономную систему. В данный момент они не попадают в таблицу маршрутизации, но если канал между ISP1 и ISP3 пропадет, то мы превратились в транзитную AS. Стоит ли объяснять чем это может грозить в масштабах Интернетов? На самом деле ни чем :) Все провайдеры фильтруют получаемую от вас информацию и в реальной жизни такая ситуация скорее исключение, чем правило. Но ведь лучше перебздеть, чем недобздеть, так?
Route-map, prefix-list, distribute-list, все эти технологии нам знакомы и мы не боимся их использовать:
CE(config)#access-list 1 permit 15.0.0.0 0.0.0.7 CE(config)#route-map localonly CE(config-route-map)#match ip address 1 CE(config)#ip prefix-list local seq 5 permit 15.0.0.0/29 CE(config)#router bgp 62211 CE(config-router)#neighbor 2.2.2.2 prefix-list local out CE(config-router)#neighbor 9.9.9.9 route-map localonly out
Да и вообще наблюдать за тем, что и кому ты анонсируешь – замечательная идея:
CE#sh ip bgp neighbors 2.2.2.2 advertised-routes --- опущено --- Network Next Hop Metric LocPrf Weight Path *> 15.0.0.0/29 0.0.0.0 0 32768 i
По той же схеме провайдеры будут анонсировать нам маршрут по умолчанию в одном случае и маршрут по умолчанию + partial update в другом:
ISP1(config)#ip prefix-list default seq 5 permit 0.0.0.0/0 ISP1(config)#router bgp 31 ISP1(config-router)#neighbor 8.8.8.8 prefix-list default out ISP1(config-router)#neighbor 8.8.8.8 default-originate ISP2(config)#ip prefix-list partial seq 5 permit 185.15.1.0/24 ISP2(config)#ip prefix-list partial seq 10 permit 185.16.2.0/24 ISP2(config)#ip prefix-list partial seq 15 permit 0.0.0.0/0 ISP2(config)#router bgp 200 ISP2(config-router)#neighbor 2.2.2.1 default-originate ISP2(config-router)#neighbor 2.2.2.1 prefix-list partial out
Что в итоге приведет к следующей картине:
CE#sh ip route bgp
185.16.0.0/24 is subnetted, 1 subnets
B 185.16.2.0 [20/0] via 2.2.2.2, 00:01:46
185.15.0.0/24 is subnetted, 1 subnets
B 185.15.1.0 [20/0] via 2.2.2.2, 00:01:46
B* 0.0.0.0/0 [20/0] via 2.2.2.2, 00:01:46
Еще одна замечательная идея смотреть что мы получаем в анонсах от провайдеров:
CE#sh ip bgp neighbors 2.2.2.2 routes
BGP table version is 5, local router ID is 15.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 2.2.2.2 0 0 200 i
*> 185.15.1.0/24 2.2.2.2 0 0 200 i
*> 185.16.2.0/24 2.2.2.2 0 0 200 i
Total number of prefixes 3
CE#sh ip bgp 0.0.0.0 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 2
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Not advertised to any peer
31
9.9.9.9 (metric 11) from 9.9.9.9 (9.9.9.9)
Origin IGP, metric 0, localpref 100, valid, external
200
2.2.2.2 from 2.2.2.2 (185.16.2.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Ну и последним штрихом пусть станет ISP3:
ISP3(config)#router bgp 80 ISP3(config-router)#network 1.8.12.0 mask 255.255.255.0 ISP3(config-router)#network 1.8.13.0 mask 255.255.255.0 ISP3(config-router)#aggregate-address 1.8.12.0 255.255.254.0 summary-only ISP3(config)#ip route 1.8.14.0 255.255.254.0 Null0 ISP3(config)#router bgp 80 ISP3(config-router)#network 1.8.14.0 mask 255.255.254.0 ISP3#sh ip bgp --- опущено --- Network Next Hop Metric LocPrf Weight Path s> 1.8.12.0/24 0.0.0.0 0 32768 i *> 1.8.12.0/23 0.0.0.0 32768 i s> 1.8.13.0/24 0.0.0.0 0 32768 i *> 1.8.14.0/23 0.0.0.0 0 32768 i * 15.0.0.0/29 4.4.4.1 0 200 62211 i *> 3.3.3.1 0 31 62211 i *> 185.15.1.0/24 4.4.4.1 0 0 200 i *> 185.16.2.0/24 4.4.4.1 0 0 200 i *> 200.200.200.0 3.3.3.1 0 0 31 i
Обратите внимание, что при использовании aggregate-address маршруты остаются в BGP таблице, но дальше не передаются (s – suppressed).
На сегодня пока все. Завтра в меню iBGP – не пропустите!