По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Сегодня, в этой статье, вы узнаете, как формируются соседства BGP внутри автономной системы, между автономными системами и даже между маршрутизаторами, которые не связаны напрямую. Кроме того, мы рассмотрим аутентификацию BGP.
Предыдущие статьи цикла про BGP:
Основы протокола BGP
Построение маршрута протоколом BGP
Видео: Основы BGP за 7 минут
BGP-пиринг
Учитывая, что BGP является протоколом маршрутизации AS-to-AS, вполне логично, что внешний BGP (т.е. eBGP) является ключевым компонентом в его операциях. Самое первое, что нам нужно учитывать при работе с eBGP, - это то, что стандарты построены таким образом, что требуется прямое подключение. Это требование конечно можно обойти, но этот момент необходимо рассмотреть. Поскольку предполагается прямое соединение, протокол BGP выполняет две вещи:
Он будет проверять значение времени жизни (TTL), и что значение time-to-live установлено в 1. Это означает прямую связь между одноранговыми узлами EBGP.
Осуществляется проверка, что два устройства находятся в одной подсети.
Еще один важный момент рассмотрения пирингов eBGP - это TCP-порты, которые будут использоваться. Это особенно важно для конфигураций брандмауэров, которые защищают автономные системы. Первый спикер BGP, который инициирует изменения состояния, приходящие по мере формирования соседства, будет получать трафик из случайного TCP-порта, а конечным портом будет TCP-порт 179. Отвечающий спикер BGP будет получать трафик с TCP-порта 179, а порт назначения будет случайным портом. Брандмауэры должны быть перенастроены с учетом изменений в коммуникации. На основе этих изменений спикер BGP инициирует сеанс, и это, вносит изменения для будущего сеанса. Некоторые администраторы даже создают механизмы для обеспечения того, чтобы сформированные пиринги были получены из известного направления.
А как насчет IPv6? Ну, как было сказано ранее в предыдущей статье, BGP очень гибок и работает с IPv6, поскольку протокол был изначально спроектирован с учетом IPv6. Вы можете формировать пиринги eBGP (и iBGP) с использованием IPv6- адресации, даже если вы используются префиксы IPv4 для информации о достижимости сетевого уровня.
Чтобы сформировать в нашей сети пиринг eBGP, необходимо выполнить следующие действия:
Запустите процесс маршрутизации для BGP и укажите локальный AS (router bgp local_as_number).
Предоставить удаленному спикеру eBGP IP- адрес и удаленному AS номер (neighbor ip-_of_neighbor remote-as remote_as_number).
Пример 1 демонстрирует конфигурацию и проверку EBGP пиринга между маршрутизаторами TPA1 и ATL.
Пример 1: Настройка пиринга eBGP
ATL#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#router bgp 220
ATL(config-router)#neighbor 30.30.30.1 remote-as 110
ATL(config-router)#end
ATL#
TPAl#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)router bgp 110
TPA1(config-router)#neighbor 30.30.30.2 remote-as 220
TPA1(config-router)#end
TPA1#
TPAl#show ip bgp summary
BGP router identifier 30.30.30.1, local AS number 110
BGP table version is 4, main routing table version 4
1 network entries using 120 bytes of memory
1 path entries using 52 bytes of memory
1/1 BGP path/bestpath attribute entries using 124 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 320 total bytes of memory
BGP activity 2/1 prefixes, 2/1 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
30.30.30.2 4 220 413 414 4 0 0 06:12:46 1
TPA1#
Примечание: чтобы облегчить понимание BGP, вы можете включить функцию debug ip bgp, при настройке пиринга. Это позволит увидеть переходные состояния в соседстве. Кроме того, чтобы получить больше информации о соседствах, вы можете использовать команду show ip bgp neighbors.
Создание eBGP пиринга, на основе IPv6, выполняется также очень просто, как и на основе IPv4. Единственное изменение заключается в том, что мы заменяем адресацию в IPv4 на IPv6 и активируем соседство. Семейства адресов в маршрутизаторах Cisco для BGP позволяют запускать множество различных схем информирования о достижимости сетевого уровня (NLRI) в рамках одного и того же общего процесса BGP. Пример 2 демонстрирует подход к пирингу IPv6.
Пример 2: конфигурация пиринга EBGP с использованием IPv6
ATL#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#router bgp 220
ATL(config-router)#neighbor 2201:1212:1212::2 remote-as 110
ATL(config-router-af)#neighbor 2201:1212:1212::2 activate
ATL(config-router-af)#end
ATL#
iBGP-пиринг
Если вы внимательно посмотрите на топологию, вы можете заметить, что что-то выглядит необычно. Видно, что есть iBGP-пиринг. Почему существует пиринг iBGP, созданный между TPA1 и TPA2? Это выглядит совершенно неуместно. В данном случае, как говорится, внешность может быть обманчива. Главное, что вы должны усвоить относительно BGP, является тот факт, что существует нечто, называемое правилом разделения горизонта (Split Horizon Rule) iBGP. Это правило гласит, что ни один спикер iBGP не может принять обновление и затем отправить это же обновление другому узлу iBGP. Так же в требовании говориться, о полном объединении наших спикеров iBGP для обеспечения полной осведомленности о префиксах.
Еще одним важным аспектом, связанным с iBGP, является избыточность. Мы хотим установить несколько физических связей между устройствами, но что произойдет, если связь, используемая для BGP, прервется? Как мы автоматически переключимся к пирингу, используя альтернативное подключение?
Простой способ решить эту проблему заключается в реализации loopback-адресов и использовании этих адресов для однорангового соединения. Это то, что мы часто делаем с нашими пирингами BGP, и это может потребовать, дополнительной настройки при использовании подключения к провайдеру. Например, в Cisco мы должны специально указать, что источником пиринга является loopback IP- адрес.
Примечание: еще одним важным аспектом при пиринге между петлевыми адресами в iBGP является то, что loopback-адреса фактически доступны между спикерами BGP. Именно здесь очень удобно использовать протокол внутреннего шлюза (IGP), такой как OSPF или EIGRP.
Пример 3 показывает конфигурацию пиринга iBGP между устройствами TPA и TPA1. Обратите внимание, что мы используем петлевой подход в том случае, если мы хотим добавить избыточные связи между устройствами в будущем.
Пример 3: Настройка пиринга iBGP
TPA#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA(config)router bgp 110
TPA(config-router)#neighbor 8.8.8.8 remote-as 110
TPA(config-router)#neighbor 8.8.8.8 update-source loopbackO
TPA(config-router)#end
TPA#
TPAl#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)#router bgp 110
TPA1(config-router)#neighbor 5.5.5.5 remote-as 110
TPA1(config-router)#neighbor 5.5.5.5 update-source loopbackO
TPA1(config-router)#end
TPA1#
eBGP Multihop
В разделе eBGP-пиринг этой статьи, обсуждалось, что ваши соседи будут связаны напрямую. В разделе iBGP мы обсуждали преимущество пиринга между loopback для избыточности. Теперь пришло время ответить на вопрос: Что делать, если ваши спикеры eBGP не подключены напрямую? На самом деле, если мы хотим пиринговать между loopback с eBGP, чтобы воспользоваться потенциальной избыточностью. Как сделать это, поскольку интерфейсы loopback не связаны напрямую друг с другом?
BGP решает эту проблему с помощью опции eBGP multihop. С помощью настройки eBGP multihop вы указываете максимальное количество допустимых прыжков. Это пропускает проверку BGP для TTL на значение равное 1, рассмотренное ранее в этой статье. Но как насчет требования прямого подключения? BGP отключает эту проверку в фоновом режиме автоматически, при использовании функции eBGP multihop. Пример 4 демонстрирует настройку eBGP multihop между TPA1 и ATL. Здесь нужен multihop, потому что мы настраиваем пиринг между loopback устройств.
Пример 4: eBGP Multihop
ATL#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#router bgp 220
ATL(config-router)#neighbor 8.8.8.8 remote-as 110
ATL(config-router)#neighbor 8.8.8.8 update-source loopbackO
ATL(config-router)#neighbor 8.8.8.8 ebgp-multihop 2
ATL(config-router)#end
ATL#
TPAl#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)router bgp 110
TPA1(config-router)#neighbor 7.7.7.7 remote-as 220
TPA1(config-router)#neighbor 7.7.7.7 update-source loopbackO
TPA1(config-router)#neighbor 7.7.7.7 ebgp-multihop 2
TPA1(config-router)#end
TPA1#
BGP аутентификация
Большинство организаций сегодня добавляют аутентификацию в свои настройки BGP, чтобы защитить их от различного рода атак. По общему признанию, аутентификацию немного сложнее настроить на BGP, чем с на других протоколах маршрутизации, поскольку конфигурация — пирингов- это ручной процесс, который должен выполнен на обоих устройствах. Даже с учетом вышесказанного, аутентификация устройств (eBGP или даже iBGP) - отличная идея.
В Cisco настройка аутентификации осуществляется просто. Необходимо задать пароль (т.е. общий секрет) на каждое устройство, настроенное для пиринга. Обязательно усвойте, что этот пароль будет отображаться в открытом виде (по умолчанию) внутри вашей сети. Можно использовать команду service password-encryption для выполнения по крайней мере простого шифрования тех незашифрованных текстовых паролей, которые появляются в конфигурации маршрутизатора.
Аутентификация с шифрованием Message Digest 5 (MD5) – это результат простого задания пароля на устройствах. Пример 5 отображает аутентификацию, добавленную в конфигурации для TPA1 и ATL.
Пример 5. Настройка аутентификации для BGP-пиринга
ATL#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#router bgp 220
ATL(config-router)#neighbor 8.8.8.8 remote-as 110
ATL(config-router)#neighbor 8.8.8.8 update-source loopbackO
ATL(config-router)#neighbor 8.8.8.8 ebgp-multihop 2
ATL(config-router)#neighbor 8.8.8.8 password MySuperSecret121
ATL(config-router)#end
ATL#
TPAl#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)router bgp 110
TPA1(config-router)#neighbor 7.7.7.7 remote-as 220
TPA1(config-router)#neighbor 7.7.7.7 update-source loopbackO
TPA1(config-router)#neighbor 7.7.7.7 ebgp-multihop 2
ATL(config-router)#neighbor 7.7.7.7 password MySuperSecret121
TPA1(config-router)#end
TPA1#
Конфигурация вашей сети Cisco хранится в двух основных местах: одно находится в ОЗУ, а другое - в текущей конфигурации (running configuration). Когда вы вводите команды, они активируются немедленно и сохраняются в текущей конфигурации, которая хранится в ОЗУ.
Поэтому при выключении питания конфигурация теряется. Чтобы сохранить эту конфигурацию, скопируйте ее в загрузочную конфигурацию (startup-configuration), что означает, что она хранится в энергонезависимой ОЗУ (NVRAM), чтобы конфигурация сохранялась при выключении питания.
Вы можете использовать две команды для сохранения вашей конфигурации: команду записи или команду копирования. Команда записи устарела, но будет выглядеть так:
Router#write memory
Building configuration...
[OK]
Более новая версия команды - это команда копирования, которая выглядит как:
Router#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
Команда копирования предлагает больше гибкости и возможностей. Вы можете не только скопировать данные текущей конфигурации в файл начальной конфигурации, но и скопировать их в файл на флэш-памяти или на TFTP-сервер в вашей сети.
Для любой команды вам нужно набрать столько букв, сколько требуется IOS для однозначной идентификации команды. Например:
copy run sta
Для любых интерфейсов 10/100 Мбит/с или 10/100/1000Мбит/с, то есть интерфейсов, которые могут работать на разных скоростях, коммутаторы Cisco по умолчанию устанавливают значение duplex auto и speed auto. В результате эти интерфейсы пытаются автоматически определить скорость и настройку дуплекса. Кроме того, как вы уже знаете, можно настроить большинство устройств, включая интерфейсы коммутатора, для использования определенной скорости и/или дуплекса.
В реальности, использование автосогласования не требует каких либо дополнительных настроек: просто можно выставить параметры скорости и дуплекса по умолчанию, и пусть порт коммутатора определяет, какие настройки использовать автоматически. Однако проблемы могут возникнуть из-за неудачных комбинаций настроек.
Автоматическое согласование в рабочих сетях
Устройства Ethernet, объединенные каналами связи, должны использовать один и тот же стандарт. В противном случае они не смогут корректно передавать данные. Например, старый компьютер с сетевым адаптером стандарта 100BASE-T, который использует двухпарный UTP-кабель со скоростью 100 Мбит /с, не сможет "общаться" с коммутатором, подключенному к ПК, так как порт коммутатора использует стандарт 1000BASE-T. Даже если подключите кабель, работающий по стандарту Gigabit Ethernet, канал не будет работать с оконечным устройством, пытающимся отправить данные со скоростью 100 Мбит /с на порт другого устройства, работающем со скоростью 1000 Мбит /с.
Переход на новые и более быстрые стандарты Ethernet становится проблемой, поскольку обе стороны должны использовать один и тот же стандарт. Например, если вы замените старый компьютер, который поддерживает стандарт передачи данных 100BASE-T , на новый, работающий по стандарту 1000BASE-T, то соответственно порты коммутатора на другом конце линии связи должны также работать по стандарту 1000BASE-T. Поэтому, если у вас коммутатор только с поддержкой технологии 100BASE-T, то вам придется его заменить на новый. Если коммутатор будет иметь порты, которые работают только по технологии 1000BASE-T, то соответственно вам придется заменить все старые компьютеры, подключенные к коммутатору. Таким образом, наличие как сетевых адаптеров ПК (NIC), так и портов коммутатора, поддерживающих несколько стандартов/скоростей, значительно облегчает переход к следующему улучшенному стандарту.
Протокол автосоглосования (IEEE autonegotiation) значительно облегчает работу с локальной сетью, когда сетевые адаптеры и порты коммутатора поддерживают несколько скоростей. IEEE autonegotiation (стандарт IEEE 802.3 u) определяет протокол, который позволяет двум узлам Ethernet, на основе витой пары, договариваться таким образом, чтобы они одновременно использовали одинаковую скорость и параметры дуплекса. Вначале каждый узел сообщает соседям, свои "возможности" по передаче данных. Затем каждый узел выбирает наилучшие варианты, поддерживаемые обоими устройствами: максимальную скорость и лучшую настройку дуплекса (full duplex лучше, чем half duplex) .
Автосогласование основывается на том факте, что стандарт IEEE использует одни и те же выводы кабеля для 10BASE-T и 100BASE-T (можно использовать кабель с двумя витыми парами). И что бы согласование проходило по технологии 1000BASE-T IEEE autonegotiation просто подключает новые две пары в кабеле (необходимо использовать кабель с четырьмя витыми парами).
Большинство сетей работают в режиме автосогласования, особенно между пользовательскими устройствами и коммутаторами локальной сети уровня доступа, как показано на рисунке 1. В организации установлено четыре узла. Узлы соединены кабелем с поддержкой Gigabit Ethernet (1000BASE-T). В результате, линия связи поддерживает скорость 10Мбит /с, 100Мбит /с и 1000Мбит /с. Оба узла на каждом канале посылают друг другу сообщения автосогласования. Коммутатор в нашем случае может работать в одном из трех режимов: 10/100/1000, в то время как сетевые платы ПК поддерживают различные опции. Настроены в ручную
Рисунок отображает концепцию автоматического согласования стандарта IEEE. В результате сетевая карта и порт на коммутаторе работают правильно. На рисунке показаны три ПК - 1, 2 и 3, подключенные к общему коммутатору. Сетевые адаптеры этих узлов имеют характеристики соответственно: 1 ПК 10 Mb/s, 2 ПК - 10/100 Mb/s и 3 ПК - 10/100/1000 Mb/s. ПК подключаются к коммутатору через порт поддерживающий режим работы 10/100/1000 Mb/s.
С обеих сторон автосогласование включено. Результатом во всех трех случаях является: дуплекс включен в режиме FULL, выставлена соответствующая скорость.
Далее разберем логику работы автосоглосования на каждом соединении:
ПК 1: порт коммутатора сообщает, что он может работать на максимальной скорости в 1000 Мбит /с, но сетевая карта компьютера утверждает, что ее максимальная скорость составляет всего 10 Мбит / с. И ПК, и коммутатор выбирают самую быструю скорость, на которой они могут работать совместно (10 Мбит /с), и устанавливают лучший дуплекс (full).
ПК2 сообщает коммутатору, что максимальная скорость передачи данных его сетевой карты составляет 100 Мбит /с. Это означает что ПК2 может работать по стандарту 10BASE-T или 100BASE-T. Порт коммутатора и сетевой адаптер договариваются использовать максимальную скорость в 100 Мбит /с и полный дуплекс (full).
ПК3: сообщает коммутатору, что его сетевая карта может работать в трех режимах: 10/100/1000 Мбит/с, и соответственно поддерживает все три стандарта. Поэтому и сетевая карта, и порт коммутатора выбирают максимальную скорость в 1000 Мбит /с и полный дуплекс (full).
Одностороннее автосогласовние (режим, при котором только один узел использует автоматическое согласование)
На рисунке 1 показано двухстороннее автосогласования IEEE (оба узла используют этот процесс). Однако большинство устройств Ethernet могут отключить автоматическое согласование, и поэтому важно знать, что происходит, когда один из узлов использует автосогласование, а другой нет.
Иногда возникает необходимость отключить автосогласование. Например, многие системные администраторы отключают автосогласование на соединениях между коммутаторами и просто настраивают желаемую скорость и дуплекс. Однако могут возникнуть ошибки, когда одно устройство использует автосогласование, а другое нет. В этом случае связь может не работать вообще, или она может работать нестабильно.
IEEE autonegotiation (автосогласование) определяет некоторые правила (значения по умолчанию), которые узлы должны использовать в качестве значений по умолчанию, когда автосогласование завершается неудачей-то есть когда узел пытается использовать автосогласование, но ничего не слышит от устройства.
Правила:
Скорость: используйте самую низкую поддерживаемую скорость (часто 10 Мбит / с).
Дуплекс: если ваша скорость равна 10 Мбит/, используйте полудуплекс (half duplex); Если 100 Мбит/с используйте полный дуплекс (full duplex) .
Коммутаторы Cisco могут самостоятельно выбирать наилучшие настройки порта по скорости и дуплексу, чем параметры IEEE, установленные по умолчанию (speed default). Это связано с тем, что коммутаторы Cisco могут анализировать скорость, используемую другими узлами, даже без автосогласования IEEE. В результате коммутаторы Cisco используют эту свою возможность для выбора скорости, когда автосогласование не работает:
Скорость: происходит попытка определения скорости (без использования автосогласования), если это не удается, используются настройки по умолчанию (устанавливается самая низкая поддерживаемая скорость, обычно 10 Мбит/с).
Дуплекс: в зависимости от установленной скорости настраиваются параметры дуплекса: если скорость равна 10 Мбит/с назначается полудуплекс (half duplex), если скорость равна 100 Мбит/с, то используется полный дуплекс (full duplex).
Гигабитные интерфейсы (1Gb/s) всегда используют полный дуплекс.
На рисунке 2 показаны три примера, в которых пользователи изменили настройки свих сетевых карт и отключили автоматическое согласование, в то время как коммутатор (на всех портах поддерживается скорость 10/100/1000 Мбит/с) пытается провести автосогласование. То есть, на портах коммутатора выставлены параметры скорости (speed auto) и (duplex auto) дуплекса в режим auto. В верхней части рисунка отображены настроенные параметры каждой сетевой карты компьютеров, а выбор, сделанный коммутатором, указан рядом с каждым портом коммутатора.
На рисунке показаны результаты работы автосогласования IEEE с отключенным режимом автосогласования на одной стороне. На рисунке показаны три компьютера - 1, 2 и 3, подключенные к общему коммутатору. Параметры сетевых адаптеров этих систем следующие: ПК1- 10/100Мбит/с, ПК2 - 10/100/1000 Мбит/с и ПК3 - 10/100Мбит/с. Компьютеры соединены с коммутатором через интерфейсы F0/1, F0/2 и F0/3. На стороне компьютеров автосогласование отключено, и произведены настройки скорости и дуплекса вручную, которые вы можете посмотреть на рисунке 2. На стороне коммутатора включено автосогласование (10/100/1000).
Разберем работу устройств на рисунке:
ПК1: коммутатор не получает сообщений автосогласования, поэтому он автоматически определяет скорость передачи данных ПК1 в 100 Мбит/с. Коммутатор использует дуплекс IEEE по умолчанию, основанный на скорости 100 Мбит/с (полудуплекс).
ПК2: коммутатор использует те же действия, что и при анализе работы с ПК1, за исключением того, что коммутатор выбирает использование полного дуплекса, потому что скорость составляет 1000 Мбит / с.
ПК3: пользователь установил самую низшую скорость (10 Мбит/с) и не самый лучший режим дуплекса (half). Однако коммутатор Cisco определяет скорость без использования автосогласования IEEE и затем использует стандарт IEEE duplex по умолчанию для каналов 10 Мбит / с (half duplex).
ПК1.Итог работы этой связки: дуплексное несоответствие. Оба узла используют скорость 100 Мбит/с, поэтому они могут обмениваться данными. Однако ПК1, используя полный дуплекс, не пытается использовать carrier sense multiple access (CSMA) для обнаружения столкновений (CSMA / CD) и отправляет кадры в любое время. В свою очередь интерфейс коммутатора F0/1 (в режиме half duplex), использует CSMA / CD. Отчего порт коммутатора F0/1 будет считать, что на канале происходят коллизии, даже если физически они не происходят. Порт остановит передачу, очистит канал, повторно отправит кадры и так до бесконечности. В результате связь будет установлена, но работать она будет нестабильно.