Оглавление
- 1. Введение
- 2. Описание политики маршрутизации BGP
- 3. BGP Wedgies
- 4. Multi-Party BGP Wedgies
- 5. BGP и детерминированность
- 6. Вопросы безопасности
- 7. Литература
1. Введение
Принято считать, что протокол BGP [RFC4271] является средством распространения информации о доступности сетей, обеспечивающим создание детерминированных путей пересылки трафика. В этом документе (problem statement — констатация проблемы) описывается класс конфигураций BGP, для которых может существовать более одного стабильного состояния пересылки. Одним из таких стабильных является предусмотренное (intended) состояние, а остальные стабильные состояния являются непредусмотренными (unintended). Процесс схождения BGP может приводить к недетерминированному выбору стабильного состояния пересылки.
Такие стабильные, но непреднамеренные состояния BGP обозначаются в этом документе термином BGP Wedgies[?] .
2. Описание политики маршрутизации BGP
Политика маршрутизации BGP в общем случае отражает задачи сетевого администратора по оптимизации расходов, производительности и надежности сети.
В части оптимизации расходов принятая по умолчанию локальная политика маршрутизации часто отдает предпочтение маршрутам, полученным от заказчиков по отношению к маршрутам, полученным от центров обмена трафиком. По тем же причинам локальная сеть зачастую настраивается так, чтобы отдавалось предпочтение маршрутам, полученным от заказчиков или партнеров (peer), перед маршрутами, полученными от транзитных upstream-провайдеров. Эти предпочтения могут выражаться через локальные настройки конфигурации, где локальные предпочтения (local preference) имеют более высокий приоритет по сравнению с метрикой AS path length, принятой в BGP.
С точки зрения надежности в общем случае междоменная маршрутизация организована так, что сервис-провайдер имеет каналы к двум или большему количеству вышестоящих (upstream) транзитных провайдеров, передавая маршруты всем этим провайдерам и принимая трафик из всех источников. Если путь к вышестоящему провайдеру рвется, трафик будет передаваться через другие каналы. После восстановления разорванного пути передача трафика по нему возобновляется.
В таких ситуациях для множества upstream-провайдеров также устанавливаются уровни предпочтения так, что одно из соединений является предпочтительным или основным (primary), а остальные рассматриваются как менее предпочтительные или резервные (backup). Смысл этого состоит в том, что резервные соединения используются для передачи трафика только при повреждении основного канала.
Политику «основной-резервный» можно задать с использованием локальных настроек AS path prepending, когда пути (AS path) искусственно удлиняется для резервных провайдеров путем вставки дополнительных значений local AS. Этот алгоритм выбора не является детерминированным, поскольку выбранный в качестве первичного провайдер также может использовать искусственное удлинение пути для своего резервного upstream-провайдера и это может приводить к тому, что в некоторых случаях путь через резервного провайдера может оказаться самым коротким (shortest AS path).
В качестве другого варианта управления политикой маршрутизации используются группы BGP (BGP community) [RFC1997]. В этом случае провайдер публикует набор значений community, который позволяет клиентам выбрать для провайдера локальные параметры предпочтения. Клиент может использовать группу (community) для маркировки как качестве резервного (backup only) маршрута в направлении резервного провайдера и установить primary preferred (предпочтительный) для маршрута в направлении основного провайдера. В этом случае локальные предпочтения будут иметь более высокий приоритет по сравнению с метрикой AS path, поэтому маршрут, помеченный как backup only, будет использоваться только в тех случаях, когда другие маршруты недоступны.