Настройка и тестирование протокола BGP на базе оборудования Cisco
и Gentoo Linux с пакетом Quagga (zebra)
Содержание
* Введение
* Использованные сокращения
* Описание протокола BGP
* Описание тестового стенда
* Настройка Cisco для использования BGP
* Установка и настройка Quagga в Gentoo Linux
* Тестирование работы протокола BGP
* Выводы
* Ссылки
Введение
В настоящей статье детально рассмотрены механизмы функционирования
протокола динамической маршрутизации BGP. Приведены инструкции по
настройке маршрутизаторов Cisco и пакета Quagga на базе Gentoo Linux.
Собран работающий стенд, в котором связность между сетями
осуществляется благодаря маршрутам, анонсированным по протоколу BGP.
На базе этого стенда проведены испытания переключения на резервный
канал при падении основного.
Протокол BGP является основным в Интернете и благодаря ему
осуществляется доступность провайдеров во всем мире. Рано или поздно
каждый серьезный провайдер столкнется с настройкой именно этого
протокола. Надеемся, что изложенный в данной статье материал окажет
хорошую помощь техническим специалистам при настройке динамической
маршрутизации по протоколу BGP.
Внимание! В статье использованы фиктивные адреса сетей, а так же
номера автономных систем. Для использования протокола BGP в реальной
сети Интернет необходимо произвести регистрацию автономной системы и
блока IP-адресов. Для этого можно воспользоваться услугами компании
НетАП по регистрации. Более подробно о данной услуге можно найти по
ссылке - http://www.netup.ru/Autonomous_System_Registration.php
Использованные сокращения
В данной статье использованы следующие сокращения:
* eBGP - Exterior BGP, обмен маршрутами между автономными системами
по протоколу BGP;
* iBGP - Interior BGP, обмен маршрутами внутри автономных систем по
протоколу BGP;
* IGP - Interior Gateway Protocol, протокол внутреннего
маршрутизатора;
* MED - Multi-exit discriminator, атрибут маршрутизаторов Cisco,
используемый в случаях, когда две автономные системы соединяются
несколькими линиями или с помощью нескольких маршрутизаторов;
Описание протокола BGP
Протокол BGP (Border Gateway Protocol;
RFC-1265-1268,1467,1655,1771,1772) разработан компаниями IBM и CISCO.
Пара BGP-соседей устанавливает между собой соединение по протоколу
TCP, порт 179. Соседи, принадлежащие разным AS, должны быть доступны
друг другу непосредственно; для соседей из одной AS такого ограничения
нет, поскольку протокол внутренней маршрутизации обеспечит наличие
всех необходимых маршрутов между узлами одной автономной системы.
BGP-маршрутизаторы обмениваются сообщениями об изменении маршрутов.
Максимальная длина таких сообщений составляет 4096 октетов, а
минимальная 19 октетов. Каждое сообщение имеет заголовок
фиксированного размера. Объем информационных полей зависит от типа
сообщения.
Формат заголовка
Рис. 1. Формат заголовка сообщения BGP.
Поле маркер содержит 16 октетов и его содержимое может легко
интерпретироваться получателем. Маркер может использоваться для
обнаружения потери синхронизации в работе BGP-партнеров. Поле длина
имеет два октета и определяет общую длину сообщения в октетах, включая
заголовок. Значение этого поля должно лежать в пределах 19 - 4096.
Поле тип представляет собой код разновидности сообщения и может
принимать следующие значения:
* OPEN - начало соединения
* UPDATE - обновление данных
* NOTIFICATION - оповещение
* KEEPALIVE - проверка связи
После того как связь на транспортном протокольном уровне установлена,
первое сообщение, которое должно быть послано - это OPEN. При успешном
прохождении этого сообщения партнер должен откликнуться сообщением
KEEPALIVE. После этого возможны любые сообщения. Кроме заголовка
сообщение OPEN содержит следующие поля:
Формат сообщения OPEN
Рис. 2. Формат сообщения OPEN.
Поле версия описывает код версии используемого протокола, на сегодня
для BGP он равен 4. Двух-октетное поле моя автономная система
определяет код AS отправителя. Поле время сохранения характеризует
время в секундах, которое отправитель предлагает занести в таймер
сохранения (после получения сообщения OPEN BGP-маршрутизатор должен
выбрать значение времени сохранения, обычно меньшее из полученного в
сообщении OPEN и значения, определенного при конфигурации системы
(0-3сек); оно определяет максимальное время в секундах между
сообщениями KEEPALIVE и UPDATE или между двумя UPDATE-сообщениями).
Каждому узлу в рамках BGP приписывается 4-октетный идентификатор
(BGP-identifier, задается при инсталляции и идентичен для всех
интерфейсов локальной сети).
Сообщения типа UPDATE используются для передачи маршрутной информации
между BGP-партнерами. Этот тип сообщения позволяет объявить об одном
новом маршруте или о закрытии группы маршрутов, причем объявление об
открытии нового и закрытии старых маршрутов возможно в пределах одного
сообщения. Сообщение UPDATE всегда содержит стандартный заголовок и
может содержать другие поля в соответствии со схемой:
Формат сообщения UPDATE
Рис. 3. Формат сообщения UPDATE.
Если длина списка отмененных маршрутов равна нулю, ни один маршрут не
отменен, а поле отмененные маршруты в сообщении отсутствует. Поле
отмененные маршруты имеет переменную длину и содержит список префиксов
IP-адресов маршрутов, которые стали недоступны: длина префикса (в
битах), равная нулю, означает, что префикс соответствует всем
IP-адресам, а сам имеет нулевой размер.
Предусмотрены следующие разновидности кодов типа атрибута:
* ORIGIN (код 1) - стандартный обязательный атрибут, который
определяет происхождение путевой информации. Генерируется
автономной системой, которая является источником маршрутной
информации.
* AS_PATH (код 2) - также является стандартным обязательным
атрибутом, который составлен из совокупности сегментов пути.
Атрибут определяет автономные системы, через которые доставлена
маршрутная информация. Каждый сегмент AS_PATH состоит из трех
частей: тип сегмента пути, длина сегмента пути и оценка сегмента
пути.
* NEXT_HOP (код 3) - стандартный обязательный атрибут, определяющий
IP-адрес пограничного маршрутизатора, который должен
рассматриваться как цель следующего шага на пути к точке
назначения.
* MULTI_EXIT_DISC (код 4) - представляет собой опциональный
непереходной атрибут, который занимает 4 октета и является
положительным целым числом. Величина этого атрибута может
использоваться при выборе одного из нескольких путей к соседней
автономной системе.
* LOCAL_PREF (код 5) - является опциональным атрибутом, занимающим 4
октета. Он используется BGP-маршрутизатором, чтобы сообщить своим
BGP-партнерам в своей собственной автономной системе степень
предпочтения объявленного маршрута.
* ATOMIC_AGGREGATE (код 6) - представляет собой стандартный атрибут,
который используется для информирования партнеров о выборе
маршрута, обеспечивающего доступ к более широкому списку адресов.
* AGGREGATOR (код 7) - опциональный переходной атрибут с длиной в 6
октетов. Атрибут содержит последний код автономной системы,
который определяет агрегатный маршрут (занимает два октета), и
IP-адрес BGP-маршрутизатора, который сформировал этот маршрут (4
октета).
Информация о работоспособности соседних маршрутизаторов получается из
KEEPALIVE-сообщений, которые должны посылаться настолько часто, чтобы
уложиться во время, отведенное таймером сохранения (hold). Обычно это
время не должно превышать одной трети от времени сохранения, но не
должно быть и меньше 1 секунды. Если выбранное значение времени
сохранения равно нулю, периодическая посылка KEEPALIVE-сообщений не
обязательна.
NOTIFICATION-сообщения посылаются, когда обнаружена ошибка. BGP-связь
при этом немедленно прерывается. Помимо заголовка
NOTIFICATION-сообщение имеет следующие поля:
Формат сообщения NOTIFICATION
Рис. 4. Формат сообщения NOTIFICATION.
Код ошибки представляет собой одно-октетное поле и указывает на тип
данного сообщения. Возможны следующие коды ошибки:
* Ошибка в заголовке сообщения
* Ошибка в сообщении OPEN
* Ошибка в сообщении UPDATE
* Истекло время сохранения
* Ошибка конечного автомата (рассинхронизация)
* Прерывание
Одно-октетное поле cубкод ошибки предоставляет дополнительную
информацию об ошибке. Каждый код ошибки может иметь один или более
субкодов. Если поле содержит нуль, это означает, что никаких субкодов
не определено.
Описание тестового стенда
Для тестирования работы протокола BGP специалистами компании НетАП был
собран тестовый стенд, включающий в себя четыре автономные системы:
* AS 65001, включающая в себя сеть 192.168.100.0/24
* AS 65002, включающая в себя сети 172.16.100.0/24; 172.16.102.0/24; 172.16.103.0/24
* AS 65003, включающая в себя сеть 192.168.200.0/24
* AS 65004, включающая в себя сеть 172.16.101.0/24
В качестве маршрутизаторов было использовано 3 сервера с операционной
системой Gentoo Linux и один маршрутизатор Cisco 3640. Схема стенда
приведена на рисунке:
Схема тестового стенда
Рис. 5. Схема стенда для тестирования работы протокола BGP.
Настройка Cisco для использования BGP
Минимальная конфигурация
Для простой конфигурации маршрутизатора Cisco для работы с протоколом
BGP используются следующие команды:
Команда router bgp [AS] присваивает маршрутизатору номер его
автономной системы и включает обмен BGP-маршрутами между автономными
системами.
Команда neighbor [ip-address] remote-as [AS] добавляет запись в
таблицу соседних BGP-маршрутизаторов с указанием IP-адреса
маршрутизатора и номера автономной системы, к которой он принадлежит.
Команда network [ip-address] указывает маршрутизатору на необходимость
анонсировать указанную сеть как доступную через данный маршрутизатор.
Выбор оптимального маршрута
При выборе наилучшего пути к сети назначения в BGP применяется
несколько критериев, каждый из которых может быть настроен вручную.
Алгоритм выбора маршрута состоит из следующих этапов:
* Для каждой записи в таблице соседних BGP-маршрутизаторов
проверяем, достижим ли соответствующий узел и отбрасываем узлы,
которые недоступны.
* Выбираем путь с наибольшим весом.
* Если вес одинаков, выбираем путь с максимальным значением
параметра LOCAL_PREF.
* Если значения LOCAL_PREF равны и путь инициирован внешним (не
локальным) маршрутизатором, выбираем кратчайший AS_PATH.
* Если длины AS_PATH равны, выбираем наименьший код ORIGIN.
* Если коды атрибута ORIGIN равны, выбираем путь с наименьшим
значением атрибута MED.
* Если атрибуты MED одинаковы, eBGP предпочитается iBGP.
* Если пути одинаковы, выбираем ближайшего соседа IGP.
* Если расстояния одинаковы, выбираем наименьший ID маршрутизатора.
Настройка атрибута Weight
Атрибут Weight (вес) является метрикой и позволяет системному
администратору вручную присваивать определенный вес всем маршрутам,
информация о которых получена от партнеров BGP. Чем больше вес, тем
лучше путь. Данная метрика особенно полезна, когда маршрутизатор
соединен с несколькими автономными системами. Вес остается локальным
параметром для того маршрутизатора, на котором он сконфигурирован.
Когда информация о маршрутах поступает из многих источников, атрибут
может применяться для того, чтобы маршрутизатор предпочитал
определенный интерфейс всем остальным. Атрибут конфигурируется с
помощью команды:
neighbor <IP-адрес> weight <вес>
Допустимые значения веса лежат в диапазоне 0 - 65535. Значение по
умолчанию равно 32768.
Диагностика сети BGP
После настройки протокола BGP можно воспользоваться рядом команд для
проверки конфигурации и диагностики сети. Эти команды также можно
использовать для изучения процесса маршрутизации BGP:
* show ip bgp - отображает всю информацию, относящуюся к
конфигурации BGP для выбранного интерфейса;
* show ip bgp neighbors - выводит информацию обо всех
сконфигурированных соседях BGP, представляет детализированные
статистические данные, относящиеся к каждому соседнему
маршрутизатору;
* show ip bgp paths - отображает всю маршрутную информацию для
локального маршрутизатора;
* show ip bgp summary - отображает состояние всех соединений BGP.
Пример вызова команды show ip bgp:
Router#show ip bgp
BGP table version is 67, local router ID is 172.16.101.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
*> 172.16.100.0/24 172.16.102.1 0 0 65002 i
* 172.16.101.2 0 65004 65002 i
r 172.16.101.0/24 172.16.102.1 0 65002 65004 i
r> 172.16.101.2 0 0 65004 i
r> 172.16.102.0/24 172.16.102.1 0 0 65002 i
r 172.16.101.2 0 65004 65002 i
*> 172.16.103.0/24 172.16.102.1 0 0 65002 i
* 172.16.101.2 0 65004 65002 i
*> 192.168.100.0 172.16.102.1 0 65002 65001 i
* 172.16.101.2 0 65004 65002 65001
i
Установкаи настройка Quagga в Gentoo Linux
Установка Quagga
Quagga - пакет программ, реализующих протоколы маршрутизации,
основанные на TCP/IP. Имеется поддержка таких протоколов, как RIPv1,
RIPv2, RIPng, OSPFv2, OSPFv3, BGP-4 и BGP-4+.В дополнение к
традиционному протоколу IPv4, Quagga также поддерживает протоколы
маршрутизации для IPv6.
Quagga позволяет осуществлять функции маршрутизации на отдельно взятом
компьютере, обмениваясь маршрутной информацией с соседями и
соответствующим образом изменяя таблицу маршрутов ядра. Вы имеете
возможность динамически изменять конфигурацию Quagga и просматривать
информацию о текущей конфигурации.
Для установки пакета Quagga воспользуйтесь следующей командой:
emerge quagga
Пакет quagga включает в себя набор демонов для работы с различными
протоколами маршрутизации (ripd, bgpd, ospfd и др.), а также демон
zebra, который непосредственно служит для формирования таблицы
маршрутизации и перераспределения маршрутов между различными
протоколами. Конфигурационные файлы quagga доступны в папке
/etc/quagga.
Ниже приведены конфигурационные файлы для всех трех маршрутизаторов,
использованных на тестовом стенде.
Сервер amalfi.netup
Пример файла zebra.conf:
hostname amalfi
password zebra
enable password zebra
log file /var/log/zebra.log
interface eth0
interface eth1
ip forwarding
line vty
После завершения настройки необходимо выполнить запуск соответствующих
демонов командами:
/etc/init.d/zebra start
/etc/init.d/bgpd start
Управление демонами возможно по протоколу telnet, аналогично
управлению маршрутизатором cisco. Для этого необходимо подключиться к
порту 2601 (для демона zebra) или к порту 2605 (для демона bgpd) и
ввести соответствующие пароли, которые вы указали в конфигурационных
файлах. Пример выполнения команды show ip route bgp на маршрутизаторе
amalfi:
amalfi# show ip route bgp
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
B>* 172.16.100.0/24 [20/0] via 10.1.2.8, eth0, 00:12:45
B>* 172.16.101.0/24 [20/0] via 10.1.2.8, eth0, 00:12:15
B>* 172.16.102.0/24 [20/0] via 10.1.2.8, eth0, 00:12:45
B>* 172.16.103.0/24 [20/0] via 10.1.2.8, eth0, 00:12:45
amalfi# exit
На показанном примере видно, что маршрутизатор успешно получил по
протоколу BGP список всех доступных ему автономных систем.
Тестирование работы протокола BGP
Простой обмен информацией о маршрутах
Итак, на стенде мы имеем два независимых маршрута от AS 65003 до AS
65001:
* AS 65004 -> AS 65002 -> AS 65001
* AS 65002 -> AS 65001
Первый маршрут доступен через интерфейс Ethernet0/0:
interface Ethernet0/0
ip address 172.16.101.1 255.255.255.0
Второй маршрут, соответственно, через интерфейс Ethernet0/1:
interface Ethernet0/1
ip address 172.16.102.2 255.255.255.0
Изначально оба маршрута работоспособны и, согласно алгоритму выбора
маршрута (см. выше) должен быть выбран маршрут 2 (65002 -> 65001).
Проверим это, воспользовавшись на маршрутизаторе Cisco командной
traceroute:
Router#traceroute 192.168.100.1
Type escape sequence to abort.
Tracing the route to 192.168.100.1
После восстановления основного канала необходимо подождать некоторое
время (около 5-10 секунд), прежде чем Cisco обнаружит, что соединение
восстановилось. Индикатором этого служит следующая запись журнала:
.Jan 2 13:33:15.448: %BGP-5-ADJCHANGE: neighbor 172.16.102.1 Up
Как только маршрутизатор обнаружит восстановление основного канала,
весь трафик снова пойдет по этому, более короткому пути.
Использование "весов" маршрутов
Иногда использование длины маршрута в качестве основного критерия
отбора неприемлимо. Так, например, у вас может быть два канала в
Интернет - дешевый основной и дорогой резервный. При этом, маршрут по
дешевому каналу длиннее. Что делать в этом случае? На помощь придет
возможность указания весов маршрутов.
Зададим длинному пути больший вес, чтобы он использовался в качестве
основного. Для этого введем следующие команды:
Введение ограничений на импорт и экспорт маршрутов
Очень часто возникает необходимость ограничить список маршрутов,
получаемых от того или иного BGP-узла. Действительно, любой узел может
заявить, что через него доступна та или иная подсеть, при этом не
предоставляя реального маршрута до указанной сети. Это делает реальной
угрозу атак типа <<отказ в обслуживании>>, спуфинга и других видов
атак.
Для защиты от этих проблем вам необходимо определить степень доверия к
каждому из соседних BGP-узлов и, в соответствии с этим, ограничить
список маршрутов, которые будут получены от него. Остальные маршруты
будут проигнорированы.
Ограничения по номеру автономной системы задаются с помощью списков
доступа по параметру as-path:
ip as-path access-list <идентификатор> permit <регулярное выражение>
Здесь регулярное выражение задает шаблон, по которому будет
срабатывать правило. Например, для ограничения по автономной системе
65004, выражение будет иметь вид ^65004$.
Кроме того, можно добавить ограничение по адресу сети с помощью
параметра prefix-list:
ip prefix-list <имя> seq <номер> permit <адрес подсети>
Где <имя> название списка адресов, <номер> порядковый номер записи в
списке, < адрес подсети> адрес сети и маска.
Теперь необходимо привязать списки к конкертному BGP-соседу. Ключевое
слово "in" в настройках указывает на то, что правила фильтрации
применяются к адресам анонсированным с данного маршрутизатора. В
случае если указано ключевое слово "out", то фильтры применяются к
адресам анонсируемым нами на данный маршрутизатор.
В режиме редактирования параметров BGP это можно сделать следующими
командами:
! Для ограничения по автономным системам
neighbor <адрес узла> filter-list <ID правила>
! Для ограничения по префиксу сети
neighbor 10.1.2.4 route-map <имя route-map> in
route-map <имя route-map> permit 10
match ip address prefix-list <имя prefix-list>
Посмотрим, как можно реализовать данный пример на нашем стенде. Для
этого на маршрутизаторе streamer.netup введем ограничения на
получаемые сети от маршрутизатора amalfi.netup. Разрешим анонсировать
только сеть 192.168.100.0/24 и для большей наглядности настроим
amalfi.netup на анонсирование новой, фиктивной сети 10.20.30.0/24. Для
этого на streamer.netup изменим конфигурационный файл
/etc/quagga/bgpd.conf следующим образом:
После применения настроек, проверим какие сети были анонсированы с
amalfi.netup. Для этого выполним следующую команду на streamer.netup:
streamer# show ip route bgp
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
B>* 172.16.101.0/24 [20/0] via 172.16.103.2, eth0, 00:02:20
B>* 192.168.100.0/24 [20/0] via 10.1.2.4, eth0, 00:02:24
Как и ожидалось информация о фиктивной сети 10.20.30.0/24 не попала в
маршрутную информацию. При этом информация о сети 192.168.100.0/24
осталась без изменений и доступна в списке маршрутов.
Выводы
Протокол BGP замечательно выполняет задачи по управлению
маршрутизацией в глобальных сетях, таких как Интернет. Тестирование
показало быструю реакцию оборудования на потерю связи по тому или
иному каналу, а также очень гибкие возможности настройки. А такая
возможность как фильтрация принимаемых и отправляемых машрутов
позволяет использовать BGP в качестве инструмента по оптимизации путей
прохождения трафика в Интернете.
Согласно данной статье очень удобно использовать протокол BGP для
обеспечения резервирования Интернет-канала. Переключение между
основным и резервным каналом происходит очень быстро, благодаря чему
задержка в предоставлении услуги будет минимальной и пользователи
провайдера по достоинству оценят качество сервиса.
Vova
