Как работает интернет?
Если на пальцах, то практически у каждого, кто подключен больше, чем к одному провайдеру (а тем более, у самих провайдеров) есть магическая сущность, которая называется автономной системой (AS) или по русски — АСка.
Всем своим соседям (не по дому, разумеется, а тем, с кем есть прямые соединения), владелец AS сообщает: "Чуваки! У меня есть AS номер XXX!" Это называется BGP-Анонсом.
Соседи принимают это во внимание и передают дальше. Вот владелец AS YYY всех оповещает: "чуваки! Через меня доступна ASXXX! Путь до нее: XXX YYY". Постепенно, у каждого участника этой вакханалии складывается маршрутная таблица, в которой всегда видно, что от своей ASZZZ до ASXXX можно дойти по маршруту "ZZZ YYY YYY1 XXX".
Всё это развлекательное мероприятие и называется "протокол BGP".
Радость от него была бы неполной, не будь в BGP возможности выбрать маршрут. От двух свои провайдеров можно получить разные маршруты до ZZZ. Если XXX подключен не только к YYY1, но и напрямую к YYY, то у него будет более выгодный маршрут всего из трех хопов, вместо четырех.
Надеюсь, вы еще не запутались в трех латинских буквах и можно перейти к IP адресам.
У владельца автономной системы есть обычно собственный диапазон IP адресов, которые он может использовать сам, отдавать клиентам, солить, сушить, ну и вообще делать с ними все, что заблагорассудится.
Если компьютер, расположенный на одном краю интернета захочет передать чего нибудь компьютеру на другом конце интернета, он засунет все данные в пакет, лизнет языком клей на конверте, надпишет IP адрес получателя и отдаст своему маршрутизатору. Маршрутизатор отдаст этот пакет другому маршрутизатору внутри своей AS, тот третьему и наконец дело дойдет до самого умного маршрутизатора, знающего протокол BGP. Самый умный маршрутизатор вздохнет, наденет очки, посмотрит на адрес получателя, поковыряется в своих толстенных книгах с таблицами маршрутизации, сопоставит адрес с номером AS, потом найдет, через кого из соседей путь до этой AS ближе всего, отдаст пакет этому соседу и забудет.
Еще надо отметить возможность сделать какой-то из каналов гарантированно запасным. Вот есть у вас два канала и вы хотите, чтобы один из них был резервным и трафик по нему шел только в случае, если основной канал упадет. Чтобы этого добиться нужно сделать, чтобы маршрут по резервному каналу был при любых обстоятельствах длиннее, чем по основному.
Как? А элементарно. Надо соседу, который сидит по ту сторону резервного канала, отдавать не просто свой номер AS, а целый маршрут до нее. Вот так: "XXX XXX XXX XXX XXX". Да-да, просто несколько раз указать свою же AS. Это называется "добавить препенды".
Возвращаясь к нашей картинке, AS XXX подключена к двум провайдерам: YYY1 — кривой, но с безнлимитным трафиком. YYY — устойчивый, но трафик за большое бабло. Владелец XXX предпочитает, чтобы пока работает YYY1, весь трафик гонялся через него. Поэтому специально для YYY сообщаем, что через нас видно "XXX XXX XXX". Поскольку маршрут от XXX до ZZZ напрямую через YYY теперь получается длиннее, то связь будет через YYY.
Главное, чтобы ни из одной точки интернета этот маршрут никогда не стал кратчайшим. Сколько препендов добавить обычно выбирается на глазок — ну 5-10. Более длинные маршруты в интернете встречаются редко.
BGP (англ. Border Gateway Protocol , протокол граничного шлюза) — динамический протокол маршрутизации.
Относится к классу протоколов маршрутизации внешнего шлюза (англ. EGP — External Gateway Protocol).
| BGP | |
|---|---|
| Название | Border Gateway Protocol |
| Семейство | TCP/IP |
| Порт/ID | 179/TCP |
| Назначение протокола | Протокол динамической маршрутизации |
| Спецификация | RFC 4271 |
| Основные реализации (клиенты) | Cisco IOS, Juniper JunOS, Bird, OpenBGPD, Quagga, Huawei VRP, Mikrotik RouterOS, frrouting |
На текущий момент является основным протоколом динамической маршрутизации в сети Интернет.
Протокол BGP предназначен для обмена информацией о достижимости подсетей между автономными системами (АС, англ. AS — autonomous system), то есть группами маршрутизаторов под единым техническим и административным управлением, использующими протокол внутридоменной маршрутизации для определения маршрутов внутри себя и протокол междоменной маршрутизации для определения маршрутов доставки пакетов в другие АС. Передаваемая информация включает в себя список АС, к которым имеется доступ через данную систему. Выбор наилучших маршрутов осуществляется исходя из правил, принятых в сети.
BGP поддерживает бесклассовую адресацию и использует суммирование маршрутов для уменьшения таблиц маршрутизации. С 1994 года действует четвёртая версия протокола, все предыдущие версии являются устаревшими.
BGP, наряду с DNS, является одним из главных механизмов, обеспечивающих функционирование Интернета.
BGP является протоколом прикладного уровня и функционирует поверх протокола транспортного уровня TCP (порт 179). После установки соединения передаётся информация обо всех маршрутах, предназначенных для экспорта. В дальнейшем передаётся только информация об изменениях в таблицах маршрутизации. При закрытии соединения удаляются все маршруты, информация о которых передана противоположной стороной.
Содержание
Формат сообщения [ править | править код ]
Сообщение BGP начинается с заголовка, после которого, в зависимости от типа сообщения, могут следовать данные. Максимальная длина сообщения — 4096 октетов, минимальная — 19 октетов. Заголовок сообщения содержит следующие поля:
- Маркер (16 октетов) — используется для совместимости, должен быть заполнен единицами;
- Длина (2 октета) — длина сообщения в октетах, включая заголовок;
- Тип (1 октет):
- 1 — Открытие;
- 2 — Обновление информации;
- 3 — Оповещение;
- 4 — Сохранение соединения.
Открытие [ править | править код ]
Первое сообщение после установки соединения должно быть «Открытие». Если сообщение успешно обработано, в ответ будет послано «Сохранение соединения». В дополнение к заголовку BGP сообщение «Открытие» содержит следующие поля:
- Версия (1 октет) — версия протокола, текущее значение 4;
- Моя система (2 октета) — номер автономной системы;
- Интервал времени (2 октета) — максимальный интервал времени в секундах между получением сообщений «Обновление информации» или «Сохранение соединения»;
- Идентификатор отправителя (4 октета) — устанавливается равным IP-адресу;
- Длина дополнительных параметров (1 октет);
- Дополнительные параметры:
- Тип параметра (1 октет);
- Длина параметра (1 октет);
- Значение параметра.
Обновление информации [ править | править код ]
Сообщение «Обновление информации» предназначено для передачи информации о маршрутах между АС. Сообщение может указывать новые маршруты и удалять неработающие. Структура сообщения:
| Бит | Значение |
|---|---|
| 0 | 1 – дополнительный, 0 – стандартный |
| 1 | 1 – транзитивный (для стандартных всегда 1) |
| 2 | 1 – информация частичная, 0 – полная |
| 3 | 1 – поле длины атрибута два октета, 0 – один октет |
| 4 | не используются, должны быть 0 |
| 5 | |
| 6 | |
| 7 |
- Длина удаляемых маршрутов (2 октета);
- Удаляемые маршруты:
- Длина (1 октет) — длина в битах префикса IP-адреса;
- Префикс IP-адреса, дополненный минимальным количеством бит до полного октета;
Все атрибуты пути соответствуют всем записям в поле «Информация о достижимости».
Сохранение соединения [ править | править код ]
Сообщение сохранения соединения должно посылаться не реже чем раз в одну третью часть максимального интервала времени между сообщениями, но не чаще чем один раз в секунду. Если интервал времени установлен равным нулю, то сообщение не должно периодически рассылаться. Сообщение не использует дополнительных полей.
Оповещение [ править | править код ]
Оповещение посылается в случае обнаружения ошибки, при этом соединение закрывается. Сообщение содержит следующие поля:
- Код ошибки (1 октет);
- Субкод (1 октет);
- Данные.
Процесс выбора [ править | править код ]
Процесс выбора запускается после обновления информации и служит для отбора маршрутов, предназначенных для использования локально и передачи другим маршрутизаторам, использующим BGP. Процесс использует атрибуты полученных маршрутов для оценки степени предпочтения маршрута или информации о том, что маршрут является неподходящим для занесения в базу маршрутов и должен быть исключён из процесса отбора. Процесс делится на три фазы:
- Вычисление степени предпочтения каждого полученного маршрута;
- Выбор наилучшего маршрута для каждого места назначения и занесение его в базу маршрутов;
- Передача маршрутов на другие маршрутизаторы, при этом может производиться суммирование маршрутов.
Ну-с, приступим? Для начала простое — настройка интерфейсов.
Назначим и Loopback-интерфейсу какой-нибудь адрес, чтобы далее проверить связность:
А теперь самое вкусное — настройка BGP. Будем разбирать каждую строчку.
Сначала поднимаем процесс BGP и назначаем AS Number, именно тот, что выдал нам LIR!
Далее настраиваем пиринг, задаем информацию о соседе:
Командой neighbor мы указываем того, с кем будем поднимать сессию. На указанный адрес 101.0.0.1 наш маршрутизатор последовательно отправит сначала TCP-SYN, а затем OPEN-сообщение. Здесь же указываем номер автономки, с которой у нас намечается пиринг — AS64501.
Абсолютно симметричная конфигурация на противоположной стороне:
В CLI появится сообщение:
Ура? Ура, но проверим состояние процесса.
Одно состояние сменяет другое и вот достигнут Established. Маршрутизатор за это время отправил одно OPEN-сообщение и аналогичное получил, а также получил и принял по два KEEPALIVE.
Проверим о каких сетях знает BGP.
sh ip bgp
Ни-че-го. Смотрим на R2.
И тут тоже самое.
А всё тут просто. До прописанной командой network сети должен быть точный маршрут, в противном случае она не окажется в таблице BGP. А муршрута нет:
А его и вписывать некуда, кроме разве что Loopback-интерфейса. Ну нет нигде этой сети. Исхитримся так:
Маршрут говорит нам, что пакеты идущие в эту сеть будут дропнуты. Но это по плану, так надо. Просто напросто при наличии более конкретных маршрутов (маска больше /23, т.е. /24. /30. /32), то следуя правилу Longest Prefix Match будут выбираться именно они.
Радуемся. В BGP-таблице отобразился локальный маршрут:
Теперь если мы настроим процесс BGP и нужные маршруты на всех устройствах нашей схемы, то таблички BGP и маршрутизации на бордере (border — пограничный маршрутизатор сети) станет такой:
В BGP-таблице, как можно заметить, по два маршрута к некоторым сетям, а вот в таблице маршрутизации он только в одном экземпляре. Просто маршрутизатор выбираем лучший из двух, и именно его закидывает в таблицу маршрутизации.
Ну, вот. Мы настроили BGP в самом первом приближении.
Мимо данной темы в контексте BGP и подключения к прову попросту невозможно пройти. Вот наша уютная компания уже имеет AS Number и вооружилась ворохом PI-адресов. При организации стыка с провайдером Балаган-Телеком нас строго спросят — "будем фулл вью или ограничимся дефолтом?"
Всё, что было у нас выше — это Full View. Маршрутизатор будет изучать все без исключения маршруты Интернета. Наш теоретический случай предусматривает штук пять-шесть маршрутов, но в действительности их более 400000. В итоге нам и один провайдер анонсирует 400 тысяч маршрутов и другой столько же. А вдруг будет еще резервный пров? Получите распишитесь, в итоге больше миллиона маршрутов.
Ну, и чего теперь, отваливать сотни нефти за мощную циску?
Вот так выглядит саммари маршрутной таблицы route-server.ip.att.net, одного публичного сервера. Можно стучаться телнетом.
По факту не всем автономкам нужно курить Full View, даже более-менее крупным компаниям достаточно Default Route и погнали. Идея простая. Вместо вороха точных маршрутов нам приходит по одному маршруту по-умолчанию от каждого из провайдеров. Впрочем, это может происходить не только вместо, но и вместе.
Разберемся в плюсах и минусах обоих случаев.
При работе с Full View вся структура интернета у вас перед глазами. Вы можете посмотреть трассу от себя до любого адреса глобальной сети:
И вы знаете, какие AS ведут к сети назначения, а RIPE позволяет узнать, какие провайдеры обеспечивают передачу. И мы можем без проблем следить за всеми изменениями сети. Даже если где-то далеко на крайних хопах у кого-то что-то отвалится (т.е. не обязательно у вас или одного из ваших провайдеров), BGP обнаружит это и перестроит таблицу маршрутизации в соответствии с изменением топологии, например, пустит трафик через второго провайдера.
И мы вольны гибко рулить маршрутами, тонко настраивая алгоритм выбора наилучшего пути. Допустим, трафик до яндекса мы будем пускать через "Балаган Телеком", а вот уже до гугла — через "Филькин Сертификат". Это будет load balancing — распределение нагрузки.
Сделать это можно, например, путем настройки приоритета маршрутов для определенных префиксов.
Ваш выбор без вариантов Full View, если ваша AS транзитная, т.е. к вам по BGP будут подключены еще клиенты.
Плюсов много, но расплатой здесь будет производительность. Готовьтесь к высокой утилизации оперативки и долгому изучению маршрутной информации после подъема BGP-сессии. Например, даже при кратковременном падении линка до вышестоящего провайдера на полное восстановление уйдет несколько минут.
А теперь Default Route. В первую очередь — это огромная экономия ресурсов нашего оборудования. Обслуживать тоже проще, больше нет задачи гонять тысячи и тысячи маршрутов внутри нашей AS. С другой стороны вы понятия не имеете о состоянии интернетов и доступности конечных узлов — вы тупо шлете трафик на дефолт, прилетевший от провайдера, апстрима (upstream). И если проблема где-то дальше, вы о ней не будете иметь понятия, а как следствие падение части предоставляемых сервисов. В этом месте мы отдаем всё на откуп вышестоящему провайдеру, надеясь, что там BGP быстренько перестроится и снова всё взлетит.
Балансировка и распределение входящего трафика не пострадает, мы этим сможем рулить, а вот управление исходящим накроется.
Давайте резюмировать. Если у вас нет цели гонять через себя транзитный трафик (подключать через себя другие AS) и не требуется гибкое распределение исходящего трафика, то вам дорога к Default Route.
Но вот точно не имеет смысла принимать от одного провайдера анонсы Full View, а от другого Default Route, т.к. один линк всегда будет простаивать и не станет гонять через себя исходящий трафик, ведь выбираться будет более специфический маршрут, который точно найдется среди анонсированного вам Full View.
Но ничего не мешает брать от всех провов Default Route и в нагрузку определенные префиксы (конкретно этого провайдера, например). Тогда до нужных ресурсов у вас будут специфические маршруты, но при этом без Full View.
Взглянем на пример настройки Default Route для линка в нижестоящему маршрутизатору:
Тогда на нашем бордере таблица маршрутов будет такой:
Теперь кроме обычных входящих в Full View маршрутов будет присутствовать и маршрут по-умолчанию.
И еще маленькое отступление перед погружением в пучины маршрутизации. Есть на эту тему годное мозговыносящее чтиво MPLS Enabled Application. Так что там с понятиями в заголовке? Это никакие не уровни сетевой модели, среды или некие моменты передачи данных, а лишь абстрактное деление.
Control Plane — уровень управления, где работают служебные протоколы, которые обеспечивают условия для передачи данных. Вот запускается BGP, следует по всем своим агрегатным состояниям и обменивается маршрутной информацией. Или же когда в MPLS-сетях LDP распределяет метки на префиксы. Таким же макаром обсуждавшийся уже STP обменивается BPDU и строит L2-топологию.
Все эти процессы живут в рамках Control Plane.
А вот Data Plane, передающий уровень — это уже передача полезных данных клиента.
Часто случается, что данные с этих двух уровней ходят в разных направлениях как бы "навстречу друг другу". Таким вот образом маршруты передаются из AS100 в AS200, чтобы в свою очередь AS200 могла передать данные в AS100.
И на разных уровнях могу быть совершенно отличные принципы работы. В том же MPLS на Data Plane создается само соединение, а непосредственно данные передаются посредством заранее определенного пути LSP. Сам же путь определяется по обычному TCP/IP стандарту, т.е. от одного хоста к другому.
Тут нужно понять назначение этих уровней и разницу в них.
Это крайне важный вопрос для BGP. Анонсируя свои маршруты вы одновременно создаете путь для входящего трафика — маршруты исходят от вас, а вот трафик течет к вам.
Нас ждет обширная тема — распределение нагрузки при помощи инструментов BGP. Но чтобы это постичь, нам для начала нужно разобраться каким вообще образом мы можем управлять маршрутами в данном протоколе. А возможностей уйма, именно поэтому протокол является таким гибким, прекрасно подходящим для маршрутизации между несколькими провайдерами, в отличие от любого из представителей IGP.
Можно выделить следующие инструменты:
- AS-Path ACL
- Prefix-list
- Weight
- Local Preference
- MED
Много? Но только два первых могут фильтровать анонсируемые и передаваемые маршруты. Остальное — выставление приоритетов.
Механизм этот очень мощный, но не пользуется особой популярностью. При помощи AS-Path ACL вы можете наглухо запретить прием анонсов от AS200, к примеру. Ну, вот не нужны нам от этой автономки анонсы, пускай будем получать их от другой.
Самое сложное — это запомнить все использующиеся при этом подходе выражения:
Давайте накидаем примеров, чтобы проще было понять.
_200_ Маршруты проходящие через AS 200
До и после номера AS идут знаки “_”, означающие, что в AS-path номер 200 может стоять в начале, середине или конце, главное, чтобы он был.
^200$ Маршруты из соседней AS 200
“^” означает начало списка, а “$” – конец. То есть в AS-path всего лишь один номер AS – это означает, что маршрут был зарождён в AS 200 и оттуда сразу был передан нам.
_200$ Маршруты отправленные из AS 200
“$” означает конец списка, то есть это самая первая AS, из неё маршрут и зародился, знак “_” говорит о том, что неважно, что находится дальше, хоть ничего, хоть 7 других AS.
^200_ Сети находящиеся за AS 200
Знак “^” означает, что ASN 200 была добавлена последней, то есть маршрут к нам пришёл из AS 200, но это не значит, что родился он в ней же – знак “_” говорит о том, что это может быть конец списка, а может пробел перед следующей AS.
^$ Маршруты локальной AS
Список AS-path пуст, значит маршрут локальный, сгенерированный внутри нашей AS.
Пример
Отфильтруем в нашей сети маршруты, появившиеся в AS64501. То есть мы будем получать от этой автономки все "глобальные интернетовские" маршруты, но ни одного её локального.
